From Spikes to Savings: Kubernetes Cost Optimization
এক কোয়ার্টারে আমাদের AWS বিল ৩৪% বেড়ে গিয়েছিল। প্রোডাক্ট রোডম্যাপে কোনো পরিবর্তন ছিল না। কারণটি ছিল সহজ: আমাদের Kubernetes ক্লাস্টারগুলো অর্থ অপচয় করছিল।
ইঞ্জিনিয়াররা প্রায়শই অনুমান করেন যে একটি সার্ভিসের কতটুকু CPU এবং মেমরি প্রয়োজন। নিরাপদ থাকার জন্য তারা সংখ্যাটি বাড়িয়ে দেন (round up)। এটি একটি কাল্পনিক বা 'ফ্যান্টম' ক্যাপাসিটি তৈরি করে। আপনি এমন সব রিসোর্সের জন্য টাকা দিচ্ছেন যা আপনার অ্যাপ্লিকেশনগুলো কখনোই ব্যবহার করে না।
আমরা যেভাবে এটি সমাধান করেছি এবং মাসিক খরচ ৩৪% সাশ্রয় করেছি তা নিচে দেওয়া হলো।
The Core Problem: Requests vs Limits
Requests হলো যা আপনি গ্যারান্টি দেন। Kubernetes আপনার পডকে (pod) একটি নোডে স্থাপন করতে এই সংখ্যাটি ব্যবহার করে। এই সংখ্যাটিই আপনার বিল নির্ধারণ করে।
Limits হলো সর্বোচ্চ সীমা। যদি একটি পড CPU limit-এ পৌঁছে যায়, তবে এটি ধীর হয়ে যায়। যদি এটি memory limit-এ পৌঁছে যায়, তবে এটি বন্ধ হয়ে যায়।
অনেক টিম requests এবং limits সমান করে সেট করে। এর মানে হলো আপনার সার্ভিসটি যখন অলস (idle) থাকে তখনও আপনি ২৪/৭ পিক ক্যাপাসিটির জন্য টাকা দিচ্ছেন।
Our Strategy for Savings
- পদক্ষেপ নেওয়ার আগে পরিমাপ করুন: প্রকৃত ব্যবহার দেখার জন্য Prometheus এবং Grafana ব্যবহার করুন।
- Percentiles ব্যবহার করুন: ৪ সপ্তাহের p95 ব্যবহার দেখুন। গড় (averages) ব্যবহার করবেন না। গড় ব্যবহারের ফলে স্পাইকগুলো ঢাকা পড়ে যায়।
- Requests-এর সঠিক মাপ নির্ধারণ করুন: p95 ব্যবহারের সাথে ২০% বাফার যোগ করে requests সেট করুন।
- CPU limits পরিচালনা করুন: থ্রটলিং (throttling) এড়াতে সং