Netflix डेटा इन्फ्रास्ट्रक्चर लागत को अधिक कुशल कैसे बनाता है
(netflixtechblog.com)Netflix की वितरित इन्फ्रास्ट्रक्चर संरचना और कंपनी के भीतर की "freedom and responsibility" संस्कृति के कारण optimization काफ़ी कठिन काम था, इसलिए लागत पारदर्शिता देने और optimization से जुड़ा context निर्णय लेने वालों के और करीब रखने के लिए एक custom dashboard विकसित किया गया।
यह "Data Efficiency Dashboard" कैसे बनाया गया और उससे क्या सीख मिली
- Netflix का data platform environment: इसे दो भागों में वर्गीकृत किया जा सकता है
-
Data at Rest : Snowflake, S3, Hive, RDS, ElasticSearch, Cassandra, Druid
-
Data in Motion : Keystone, Flink, Mantis, Spark, Kafka, Presto
** उपयोग और लागत की विज़िबिलिटी एक नज़र में **
सभी platforms की लागत को एक जगह जोड़ा गया, और इस तरह जोड़ा गया कि हर लागत को अर्थपूर्ण units में तोड़ने वाली जानकारी भी साथ रहे
→ units: table, index, column family, job आदि
इस लागत जानकारी का स्रोत मूल रूप से AWS billing data था, जिसे service और tag के आधार पर वर्गीकृत किया गया था, लेकिन केवल इससे resource/team के हिसाब से विभाजन संभव नहीं था, इसलिए नीचे दिए गए तरीकों का उपयोग किया गया
- EC2-आधारित platform
→ platform के अनुसार bottleneck metrics को परिभाषित किया गया
→ उदाहरण के लिए, Kafka network-bound है, जबकि Spark CPU और memory-bound है।
→ Atlas, platform logs, और Rest API का उपयोग करके प्रत्येक resource के metrics को अलग किया गया और लागत आवंटित की गई
- S3-आधारित platform
→ प्रत्येक resource को S3 prefix दिया गया, और storage pricing के आधार पर प्रति resource लागत की गणना की गई
- Dashboard View
Apache Druid-आधारित custom dashboard का उपयोग करके हर लागत को टीमों को आवंटित किया गया।
इस लागत जानकारी के मुख्य उपभोक्ता engineering और data teams थे। उन्हें इस जानकारी के आधार पर action लेने लायक बनाया गया
इसके अलावा, engineering leaders को इसे एक higher-level view में देखने की सुविधा दी गई।
use case के अनुसार इसे data asset unit या organizational unit के हिसाब से group करके देखा जा सकता था, और snapshot तथा time series दोनों रूपों में data देखना संभव था
** Automated storage recommendations - Time to Live (TTL) **
कुछ scenarios में केवल पारदर्शिता देना ही नहीं, बल्कि optimization recommendations भी दी गईं।
data storage का उपयोग बहुत अधिक होता है, और इसमें cost momentum भी काफ़ी होता है (जैसे data store करने के बाद उसे भूल जाना),
इसलिए data usage patterns के आधार पर optimal storage period (TTL) तय करने वाले analysis को automate किया गया।
S3 के big data warehouse tables के लिए TTL recommendations लागू की गईं
- लागत गणना और business logic
सबसे बड़ी S3 लागत transaction tables से आती है, जिन्हें आमतौर पर तारीख़ के आधार पर partition किया जाता है
S3 access logs और S3 prefix-to-table-partition mapping का उपयोग करके यह तय किया जा सकता है कि किन date partitions को access किया गया।
पिछले 180 दिनों की access activity (read/write) देखकर maximum lookback दिनों की पहचान की गई।
इसी lookback अवधि के आधार पर उस table का TTL value तय किया गया।
इस गणना किए गए TTL के आधार पर संभावित annual savings की गणना की गई
- Dashboard View
data owners विस्तृत data access patterns देख सकते थे, recommended TTL बनाम current TTL की तुलना कर सकते थे, और संभावित लागत बचत भी देख सकते थे
** कम्युनिकेशन और उपयोगकर्ताओं को सूचित करना **
data cost की निगरानी tech teams का रोज़मर्रा का काम नहीं बनना चाहिए, खासकर तब जब वे अर्थहीन data costs हों।
इसलिए data cost के प्रति जागरूकता बढ़ाने के लिए केवल उन teams को email push notifications भेजने की सुविधा विकसित की गई जिनका data usage अधिक था।
साथ ही, केवल उन tables के लिए जिनमें cost savings की संभावना थी, TTL recommendation values अपने आप भेजी गईं।
वर्तमान में, ऐसे emails हर महीने भेजे जा रहे हैं
** सीख और चुनौतियाँ **
- प्रत्येक asset के metadata की पहचान करना और उसे बनाए रखना cost allocation के लिए महत्वपूर्ण है
→ इसके लिए Netflix Data Catalog (NDC) नाम का metadata repository बनाया गया
→ इससे data access और search आसान हुआ, इसलिए existing और new data दोनों का प्रबंधन संभव हुआ
→ NDC को cost calculation के शुरुआती बिंदु के रूप में उपयोग किया गया
- time trend data चुनौतीपूर्ण होता है
→ trend data, snapshot data की तुलना में प्रबंधन का बोझ कहीं अधिक बढ़ा देता है
→ data inconsistency और processing latency के कारण consistent view देना कठिन है
→ दो तरह की चुनौतियों को हल करना पड़ा
→ - resources की ownership change: snapshot view में ownership changes अपने आप reflect होने चाहिए, और time series view के मामले में उन changes को metadata में भी reflect करना ज़रूरी है
→ - data issues होने पर state loss: resources का metadata API के ज़रिए कई sources से निकाला जाता है, इसलिए collection के दौरान failure होने पर state loss हो सकता है। ऐसा data अस्थायी होता है, इसलिए केवल API extraction से काम नहीं चलता। Keystone की ओर data pump करने जैसे alternatives खोजने पड़ते हैं
** निष्कर्ष **
यदि आपके पास अत्यधिक वितरित data platform है, तो ऐसे dashboards के ज़रिए feedback loop बनाकर, usage और cost context को एकीकृत करके efficiency को काफ़ी बढ़ाया जा सकता है।
जहाँ संभव हो, automated recommendations के माध्यम से efficiency बढ़ानी चाहिए।
Netflix के मामले में data retention period recommend करना high ROI साबित हुआ।
इस dashboard और TTL recommendations के माध्यम से पूरे data warehouse storage footprint को 10% से अधिक कम किया जा सका।
2 टिप्पणियां
लगता है recommendation फीचर सिर्फ दर्शकों के लिए ही नहीं था.
अच्छा है। मैंने कहीं एक शोध देखा था कि अगर आप real-time monitoring मशीन को देख सकें, तो involuntary muscles भी हिलाई जा सकती हैं, वह बात अचानक याद आ गई।