autoscaling असल में काम कैसे करती है, और आप उसे tune कैसे करते हैं?

एक scaling policy किसी metric पर नजर रखती है और capacity को target की तरफ खिसकाती है, तो target tracking औसत CPU या प्रति instance requests को एक तय बिंदु के आसपास रखती है। tuning का मतलब है ऐसा metric चुनना जो सचमुच load दिखाता हो, नई capacity को गिनने से पहले instance के warm up का वक्त देना, तेजी से बाहर बढ़ना और धीरे धीरे अंदर घटना, और ऐसा minimum रखना जिससे हर availability zone ढका रहे। जो spike पहले से पता हों उनके लिए scheduled capacity जोड़ें, क्योंकि प्रतिक्रिया वाली scaling हमेशा पीछे रहती है।

यह एक feedback loop है। आप उसे एक metric और एक target देते हैं, वह तुलना करके फासला भरने के लिए capacity जोड़ता या घटाता है। पहला फैसला metric का है, और CPU वह डिफॉल्ट है जो अक्सर गलत होता है, क्योंकि कोई IO bound service तीस प्रतिशत CPU पर हो सकती है जबकि उसका connection pool खत्म हो चुका हो। प्रति instance requests या queue depth आमतौर पर load का ज्यादा सच्चा संकेत है। दूसरी चीज देरी है, और यहीं लोग चोट खाते हैं। अगर किसी instance को boot होकर health check पास करने में तीन मिनट लगते हैं, तो साठ सेकंड में आने वाला spike मदद पहुंचने से पहले ही खत्म हो जाता है, इसलिए मैं warm up period सेट करता हूं ताकि नए instance तैयार होने से पहले गिने न जाएं, और सुबह नौ बजे के login rush जैसे पहले से पता चलने वाले पैटर्न के लिए schedule से पहले ही scale कर देता हूं। मैं scale out को आक्रामक और scale in को नरम रखता हूं, क्योंकि थोड़ी देर के लिए ज्यादा capacity रखना outage से कहीं सस्ता है, और flapping दोनों से बुरा है। और scale in के साथ connection draining चाहिए, वरना आप किसी instance को request के बीच में बंद कर देते हैं और यूजर को ऐसी error दिखती हैं जो bug जैसी लगती हैं।