วิธีที่ Netflix เพิ่มประสิทธิภาพต้นทุนโครงสร้างพื้นฐานข้อมูล
(netflixtechblog.com)เนื่องจากโครงสร้างพื้นฐานของ Netflix กระจายตัวสูง และวัฒนธรรมองค์กรแบบ "อิสระและความรับผิดชอบ" ทำให้การเพิ่มประสิทธิภาพเป็นเรื่องค่อนข้างยาก จึงได้พัฒนาแดชบอร์ดแบบกำหนดเองเพื่อให้เห็นต้นทุนอย่างโปร่งใส และวางบริบทที่เกี่ยวข้องกับการเพิ่มประสิทธิภาพไว้ใกล้กับผู้ตัดสินใจมากที่สุด
วิธีสร้าง "แดชบอร์ดประสิทธิภาพข้อมูล" นี้ และบทเรียนที่ได้
- สภาพแวดล้อมแพลตฟอร์มข้อมูลของ Netflix: แบ่งได้เป็น 2 ประเภท
-
Data at Rest : Snowflake, S3, Hive, RDS, ElasticSearch, Cassandra, Druid
-
Data in Motion : Keystone, Flink, Mantis, Spark, Kafka, Presto
** มองเห็นการใช้งานและต้นทุนได้ในภาพเดียว **
รวบรวมต้นทุนของทุกแพลตฟอร์ม โดยรวบรวมพร้อมข้อมูลที่สามารถแยกต้นทุนออกเป็นหน่วยที่มีความหมายได้
→ หน่วย: ตาราง, ดัชนี, column family, งาน เป็นต้น
แหล่งข้อมูลของต้นทุนนี้โดยพื้นฐานอาศัยข้อมูลการเรียกเก็บเงินของ AWS ที่จัดหมวดตามบริการและแท็ก แต่เพียงเท่านี้ยังไม่สามารถแยกตามทรัพยากร/ทีมได้ จึงใช้วิธีดังต่อไปนี้
- แพลตฟอร์มที่อิง EC2
→ กำหนดเมตริกคอขวด (bottleneck metric) สำหรับแต่ละแพลตฟอร์ม
→ ตัวอย่างเช่น Kafka ติดข้อจำกัดด้านเครือข่าย ขณะที่ Spark ติดข้อจำกัดด้าน CPU และหน่วยความจำ
→ ใช้ Atlas, ล็อกของแพลตฟอร์ม และ Rest API เพื่อแยกเมตริกต่อทรัพยากรและจัดสรรต้นทุน
- แพลตฟอร์มที่อิง S3
→ กำหนด S3 Prefix ให้แต่ละทรัพยากร และคำนวณต้นทุนต่อทรัพยากรตามราคา storage
- Dashboard View
ใช้แดชบอร์ดแบบกำหนดเองบน Apache Druid เพื่อจัดสรรต้นทุนให้แต่ละทีม
ลูกค้าหลักของข้อมูลต้นทุนนี้คือทีมวิศวกรรมและทีมข้อมูล เพื่อให้พวกเขาลงมือทำตามข้อมูลดังกล่าวได้
นอกจากนี้ยังให้มุมมองระดับที่สูงขึ้นสำหรับผู้นำฝ่ายวิศวกรรมด้วย
สามารถดูแบบจัดกลุ่มตามหน่วยทรัพยากรข้อมูลหรือหน่วยองค์กรตาม use case และดูข้อมูลได้ทั้งแบบ snapshot และ time series
** คำแนะนำด้าน storage แบบอัตโนมัติ - Time to Live (TTL) **
ในบางสถานการณ์ ไม่ได้หยุดแค่การทำให้โปร่งใส แต่ยังให้คำแนะนำในการเพิ่มประสิทธิภาพด้วย
เนื่องจาก data storage มีทั้งปริมาณการใช้งานสูงและมีแรงเฉื่อยด้านต้นทุนสูง (เก็บไว้แล้วมักลืม)
จึงทำให้การวิเคราะห์เพื่อกำหนดระยะเวลาการเก็บข้อมูลที่เหมาะสมที่สุด (TTL) ตามรูปแบบการใช้งานข้อมูลเป็นแบบอัตโนมัติ
มีการใช้คำแนะนำ TTL กับตารางสำหรับคลังข้อมูลขนาดใหญ่บน S3
- การคำนวณต้นทุนและ business logic
ต้นทุน S3 ก้อนใหญ่ที่สุดเกิดจาก transaction table ซึ่งโดยทั่วไปจะ partition ตามวันที่
สามารถระบุ date partition ที่มีการเข้าถึงได้โดยใช้ S3 access log และการแมป S3 prefix-to-table-partition
ดูการเข้าถึง (อ่าน/เขียน) ในช่วง 180 วันที่ผ่านมา แล้วตรวจสอบจำนวนวัน Lookback สูงสุด
จำนวนวัน Lookback นี้เป็นตัวกำหนดค่า TTL ของตารางนั้น
จาก TTL ที่คำนวณได้ จึงคำนวณมูลค่าการประหยัดต่อปีที่ทำได้จริง
- Dashboard View
เจ้าของข้อมูลสามารถดูรูปแบบการเข้าถึงข้อมูลแบบละเอียด และดูค่าแนะนำของ TTL เทียบกับค่าปัจจุบัน พร้อมทั้งตรวจสอบมูลค่าการประหยัดต้นทุนที่เป็นไปได้
** การสื่อสารและการแจ้งให้ผู้ใช้ทราบ **
การตรวจสอบต้นทุนข้อมูลไม่ควรกลายเป็นงานประจำวันของทีมเทคนิค โดยเฉพาะอย่างยิ่งหากเป็นต้นทุนข้อมูลที่ไม่มีความหมาย
จึงพัฒนาฟังก์ชันส่งการแจ้งเตือนทางอีเมลแบบ push เฉพาะให้กับทีมที่มีการใช้งานข้อมูลสูง เพื่อเพิ่มการรับรู้เรื่องต้นทุนข้อมูล
และยังส่งค่า TTL ที่แนะนำโดยอัตโนมัติเฉพาะกับตารางที่มีโอกาสลดต้นทุนได้เท่านั้น
ปัจจุบัน อีเมลเหล่านี้ถูกส่งทุกเดือน
** บทเรียนและความท้าทาย **
- การระบุและดูแล metadata ของแต่ละ asset มีความสำคัญต่อการจัดสรรต้นทุน
→ เพื่อการนี้ จึงสร้างที่เก็บ metadata ชื่อ Netflix Data Catalog (NDC)
→ ทำให้เข้าถึงและค้นหาข้อมูลได้ง่าย จึงสามารถจัดการได้ทั้งข้อมูลเดิมและข้อมูลใหม่
→ ใช้ NDC เป็นจุดเริ่มต้นของการคำนวณต้นทุน
- ข้อมูลแนวโน้มตามเวลาเป็นเรื่องท้าทาย
→ ข้อมูลแนวโน้มมีภาระในการจัดการสูงกว่าภาพ snapshot มาก
→ เป็นเรื่องยากที่จะให้มุมมองที่สอดคล้องกัน เนื่องจากความไม่สอดคล้องของข้อมูลและ latency ในการประมวลผล
→ ต้องแก้ 2 ปัญหา
→ - การเปลี่ยนเจ้าของทรัพยากร: สำหรับ snapshot ต้องสะท้อนการเปลี่ยนเจ้าของโดยอัตโนมัติ และสำหรับมุมมอง time series แม้แต่การเปลี่ยนแปลงนั้นเองก็ต้องสะท้อนใน metadata ด้วย
→ - การสูญเสียสถานะเมื่อเกิดปัญหาด้านข้อมูล: metadata ของทรัพยากรถูกดึงจากหลายแหล่งผ่าน API ดังนั้นหากล้มเหลวระหว่างการเก็บรวบรวม สถานะอาจสูญหายได้ ข้อมูลเหล่านี้มีลักษณะชั่วคราว จึงมีข้อจำกัดหากพึ่งพาเพียงการดึงผ่าน API จำเป็นต้องหาทางเลือก เช่น การ pump ข้อมูลเข้าไปทาง Keystone
** บทสรุป **
หากมีแพลตฟอร์มข้อมูลที่กระจายตัวสูง การสร้าง feedback loop ผ่านแดชบอร์ดลักษณะนี้ และการรวมบริบทของการใช้งานกับต้นทุนเข้าด้วยกัน สามารถเพิ่มประสิทธิภาพได้อย่างมาก
หากเป็นไปได้ ควรเพิ่มประสิทธิภาพด้วยคำแนะนำแบบอัตโนมัติ
ในกรณีของ Netflix การแนะนำระยะเวลาการเก็บรักษาข้อมูลให้ผลตอบแทน ROI สูงมาก
ผ่านแดชบอร์ดนี้และคำแนะนำ TTL ทำให้ลดพื้นที่จัดเก็บของ data warehouse ทั้งหมดลงได้มากกว่า 10%
2 ความคิดเห็น
ดูเหมือนว่าฟีเจอร์แนะนำจะไม่ได้มีไว้เพื่อผู้ชมเท่านั้น
ดีนะครับ ผมนึกขึ้นมาได้กะทันหันว่าเคยเห็นงานวิจัยที่ไหนสักแห่งบอกว่า หากมองเห็นเครื่องมือมอนิเตอร์แบบเรียลไทม์ได้ ก็อาจขยับกล้ามเนื้อที่ไม่อยู่ใต้อำนาจจิตใจได้ด้วย