AB180 डेवलपमेंट टीम की AWS लागत प्रबंधन यात्रा: बिल जांच से लेकर FinOps संस्कृति तक

Gemini से सारांशित।

--

बड़ी मात्रा में डेटा को प्रोसेस करने वाले मार्केटिंग परफॉर्मेंस मेज़रमेंट सॉल्यूशन 'Airbridge' को संचालित करते हुए, हमने एक व्यवस्थित AWS लागत प्रबंधन (FinOps) संस्कृति बनाई है। इस प्रक्रिया में मिले अनुभव और जानकारी साझा कर रहे हैं।

AB180 की लागत प्रबंधन संचालन पद्धति:
हम लागत को 'प्रबंधित' करने के लिए निम्नलिखित प्रक्रियाएँ चलाते हैं।

• Google Sheets आधारित डैशबोर्ड: डेटा को आसानी से प्रोसेस और साझा करने के लिए Google Sheets का उपयोग कर हमने डैशबोर्ड बनाया। इसमें टैग के अनुसार लागत की स्थिति के साथ-साथ लागत को सीधे प्रभावित करने वाली डेटा कलेक्शन मात्रा भी दिखाई जाती है, जिससे बदलाव के कारणों को सहज रूप से समझा जा सके। साथ ही, Savings Plan coverage की स्थिति को विज़ुअलाइज़ किया जाता है और कॉन्ट्रैक्ट में बदलाव होने पर उसके परिणामों का पहले से सिम्युलेशन कर तर्कसंगत निर्णय लेने में मदद मिलती है।
• नियमित और स्वचालित लागत निरीक्षण: हर 2 हफ्ते में एक बार, लगभग 30 मिनट की छोटी मीटिंग के जरिए लागत में हुए बदलावों की समीक्षा की जाती है। मीटिंग सामग्री बनाना, Slack अलर्ट, मीटिंग मिनट्स लिखना जैसी दोहराव वाली गतिविधियों को अधिकतम हद तक ऑटोमेट किया गया है ताकि दक्षता बढ़े। यदि लागत में बड़ा बदलाव हो, तो जिम्मेदार व्यक्ति Google Sheets कमेंट के जरिए कारणों का विश्लेषण कर साझा करता है, जिससे पारदर्शिता बनी रहती है।
• डेवलपमेंट से पहले अनुमानित लागत निकालना: नई फीचर डेवलपमेंट या आर्किटेक्चर में बदलाव के समय, 'Tech Spec' दस्तावेज़ में अनुमानित लागत लिखना अनिवार्य किया गया है। इससे डेवलपमेंट चरण से ही लागत को ध्यान में रखकर बेहतर तकनीकी निर्णय लिए जा सकते हैं।

लागत प्रबंधन प्रणाली के उन्नयन की प्रक्रिया:
आज की यह प्रणाली एक दिन में नहीं बनी। यह निम्नलिखित चरणों से विकसित हुई है।

• Phase 0 (बिल जांच): शुरुआत में यह सिर्फ हर महीने बिल चेक करने तक सीमित था।
• Phase 1 (न्यूनतम वर्गीकरण): Name टैग का उपयोग कर हमने resources का न्यूनतम स्तर पर वर्गीकरण शुरू किया।
• Phase 2 (टैग रणनीति का उन्नयन): Team, Service आदि स्पष्ट नीतियों पर आधारित टैग रणनीति बनाई गई। सिर्फ गाइड वितरित करना पर्याप्त नहीं था, इसलिए IAM policy के साथ जोड़कर टैग सेटिंग को अनिवार्य किया गया, और बिना टैग वाले resources के लिए Slack bot के माध्यम से ऑटोमेटेड अलर्ट भेजने की व्यवस्था बनाई गई। इसके परिणामस्वरूप, बिना टैग वाले resources की लागत को कुल का 1% से कम स्तर पर प्रबंधित किया जा सका।

इस यात्रा से मिले 5 सबक:

• स्थिति के अनुसार engineering महत्वपूर्ण है। लागत नियंत्रण के लिए परफेक्ट सिस्टम का पीछा करने के बजाय, कंपनी के आकार और परिस्थिति के अनुरूप 'उपयुक्त' स्तर की प्रबंधन व्यवस्था को क्रमिक रूप से बनाना अधिक समझदारी है।
• लागत 'नियंत्रण' और 'ऑप्टिमाइज़ेशन' अलग चीज़ें हैं। लागत की पूर्वानुमेयता बढ़ाने वाला 'नियंत्रण' और लागत को वास्तव में कम करने वाला 'ऑप्टिमाइज़ेशन' स्पष्ट रूप से अलग हैं। परिस्थितियों की प्राथमिकता के अनुसार तय करना चाहिए कि किस पर ध्यान देना है।
• साहसपूर्वक ऑटोमेशन करना चाहिए। केवल साधारण दोहराव वाले कामों को ऑटोमेट करना ही नहीं, बल्कि ऐसा 'self-serve' वातावरण बनाना चाहिए जिसमें सहकर्मी स्वयं डेटा देख सकें और समस्याएँ पहचान सकें; इससे उत्पादकता अधिकतम होती है।
• 'mechanism' बनाना चाहिए। "टैग ठीक से लगाएँ" कहने के बजाय, ऐसी 'व्यवस्था (mechanism)' डिज़ाइन करना अधिक प्रभावी है जिसमें टैग न होने पर resource permission ही न मिले, यानी नीति का पालन करना अनिवार्य हो।
• FinOps अंततः एक 'संस्कृति' है। यह सबसे महत्वपूर्ण है कि लागत प्रबंधन को किसी एक व्यक्ति की जिम्मेदारी नहीं, बल्कि उत्पाद बनाने वाले सभी लोगों की साझा जिम्मेदारी के रूप में स्थापित करने के लिए लगातार प्रयास किए जाएँ और संस्कृति विकसित की जाए।

[tujuc]

ओहो.. अगर कम से कम सबसे बुनियादी Tag ही लगा दें, तो भी कुछ हद तक काम चल जाएगा.. :)

लेकिन RI या SP जैसी चीज़ों का इस्तेमाल करके लागत कम करना क्या बुनियादी रूप से शामिल माना जाता है....
हमारे इंफ्रास्ट्रक्चर में किस हद तक किस size का उपयोग होगा, यह काफ़ी सोचने वाला हिस्सा है...

[dongho42]

यह बात मुख्य लेख में भी कही गई है, लेकिन मैंने अलग से एक SP simulator बनाया था, जो पिछले n दिनों के workload के आधार पर यह गणना करता था कि यहाँ कितना अतिरिक्त SP खरीदना चाहिए ताकि "मौजूदा लागत + Covered होने से कम होने वाली लागत + Recurring होने की वजह से बेकार जाने वाली लागत" सबसे कम हो, और उसी के आधार पर मैंने निर्णय लिया था।

[slave4salary]

मैं वर्तमान में AWS Korea में कार्यरत हूँ।

जॉइन करने के बाद जो सबसे महत्वपूर्ण ट्रेनिंग सुनाई जाती है, उनमें से एक यह होती है कि ग्राहकों को cloud cost कम खर्च करने के तरीके पर विचार करें, और सबसे प्रभावी तरीकों में से एक के रूप में RI & SP की सलाह दी जाती है.

[cocofather]

कृपया शुल्क कम कर दीजिए..

[toughrogrammer]

RI के बारे में तो नहीं कह सकता, लेकिन SP के मामले में यह कई workloads पर लागू हो सकता है, इसलिए अगर कुछ fixed cost लगातार जा रही हो तो इसे पर्याप्त रूप से consider करना चाहिए। यहाँ तक कि हमने expected optimization timing को ध्यान में रखकर भी खरीदारी की थी... हाहा उदाहरण के लिए, अगर लगे कि 9 महीने बाद optimization पूरा हो जाएगा और server cost आधी रह जाएगी, तब भी 1 साल का खरीद लेना ज़्यादा फ़ायदेमंद हो तो हम उसी तरह खरीदते थे।