EC2 बूट समय कम करना

 (depot.dev)
14 पॉइंट द्वारा GN⁺ 2024-05-28 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • EC2 इंस्टेंस के बूट समय को 40 सेकंड से 5 सेकंड तक घटाना संभव है
  • यह तब बहुत महत्वपूर्ण होता है जब किसी खास काम को प्रोसेस करने के लिए नया EC2 इंस्टेंस चाहिए होता है

बूट समय लंबा होने के कारण

  • नया EC2 इंस्टेंस रिक्वेस्ट करने पर AWS कई काम करता है:
    • चुने गए AMI से root EBS volume बनाना
    • इंस्टेंस को private IP address असाइन करना
    • इंस्टेंस के लिए host चुनना
    • वास्तव में मशीन को बूट करना
  • हार्डवेयर चालू होने के बाद भी bootloader, kernel और user space process शुरू होने होते हैं.

समस्या से बचने का तरीका

  • standby compute pool चलाकर build request को पहले से चल रहे EC2 इंस्टेंस की ओर रूट किया जाता है.
  • लेकिन यह हर काम के लिए आर्थिक रूप से व्यावहारिक नहीं है.
  • GitHub Actions runner के मामले में हर job को एक समर्पित EC2 इंस्टेंस की ओर रूट किया जाता है.
  • 50 समानांतर jobs संभालने के लिए 50 EC2 इंस्टेंस को online रखना अव्यावहारिक है.

और तेज बूट समय

  • किसी खास काम के लिए अनावश्यक चरण न करना हमेशा तेज होता है.
  • EC2 इंस्टेंस बनाना, बूट करना और application शुरू करने के हर चरण को व्यवस्थित रूप से optimize किया गया.
  • तरीका यह है कि इंस्टेंस को एक बार बूट करें, बंद करें, और जरूरत पड़ने पर फिर से शुरू करें.

EBS root volume streaming

  • EBS root volume की तैयारी EC2 इंस्टेंस के बूट समय और application performance पर बड़ा असर डालती है.
  • AMI से EBS volume बनाते समय data block को पहली बार access होने पर S3 से लाना पड़ता है.
  • AWS सभी data block को पहले से load करने की सिफारिश करता है.

इंस्टेंस को एक बार बूट करना

  • EBS-backed इंस्टेंस को stop करने के बाद फिर से start किया जा सकता है.
  • stopped इंस्टेंस सिर्फ configuration बनाए रखता है, और केवल root EBS volume की लागत देनी पड़ती है.
  • इंस्टेंस को एक बार बूट करके initialization काम करने के बाद stop करने से "warmed" EBS root volume बन जाता है.

Auto Scaling warming pool

  • AWS EC2 Auto Scaling के लिए warming pool प्रदान करता है.
  • लेकिन Auto Scaling group को request पर प्रतिक्रिया देने में समय लगता है.
  • सबसे अच्छे performance के लिए LaunchInstances और StartInstances API call का उपयोग करके EC2 इंस्टेंस सीधे शुरू किए जाते हैं.

इंस्टेंस आकार समायोजन

  • warmed इंस्टेंस का प्रकार बदलकर बूट समय को optimize किया जाता है.
  • initialization काम के लिए सस्ता इंस्टेंस प्रकार इस्तेमाल किया जाता है, और वास्तविक काम के समय इसे अधिक performance वाले इंस्टेंस प्रकार में बदला जाता है.

पूरा flow

  • GitHub Actions runner इंस्टेंस निम्न flow से गुजरता है:
    • t3.large इंस्टेंस के रूप में बनाया जाता है
    • target VPC में private IP address असाइन किया जाता है
    • kernel और user space process एक बार शुरू होते हैं
    • इंस्टेंस stop किया जाता है
    • job request आने पर इंस्टेंस प्रकार को m7a में update करके start किया जाता है
    • अगर m7a इंस्टेंस capacity उपलब्ध न हो, तो backup type में update करके फिर start किया जाता है
  • इस flow से job के लिए इंस्टेंस तैयार करने का समय 40 सेकंड से 5 सेकंड तक घट जाता है.

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-05-28
Hacker News टिप्पणियाँ

सारांश

  • बूट समय: ऑटो स्केलिंग की सफलता का एक मुख्य तत्व है; बूट समय जितना कम होगा, prediction window उतनी छोटी होगी और prediction accuracy उतनी अधिक होगी। लागत बचाने के लिए EBS volume पहले से तैयार रखना तर्कसंगत हो सकता है।
  • Amazon का optimization: Amazon ने Firecracker जैसी तकनीकों से ultra-fast boot लागू किया है, और संभव है कि EC2 में भी इसी तरह की सुविधाएँ उपलब्ध हों।
  • immutable configuration: immutable/atomic configuration के ज़रिए EBS volume साझा किए जा सकते हैं, और minimal boot AMI का उपयोग करके optimization किया जा सकता है।
  • बूट समय मापन: EC2 instance के बूट समय में bimodal pattern दिखता है, जो 15-20 सेकंड या 80 सेकंड पर वितरित है। इसके कारण की पहचान ज़रूरी है।
  • GitHub Actions: GitHub Actions runner के boot optimization के बावजूद, job delivery time लंबा हो रहा है, इसलिए further optimization की ज़रूरत है।
  • AWS से तुलना: AWS और अन्य cloud providers के boot time की तुलना। Hetzner कुछ ही सेकंड में instance बना देता है।
  • EC2 ऑटो स्केलर: EC2 auto scaler की सीमाएँ और सुधार की ज़रूरत का उल्लेख। AWS का दिया हुआ auto scaler धीमा और सीमित है।
  • EBS इस्तेमाल करने का कारण: EBS durability के लिए cost और performance का त्याग करता है। network-attached volume होने के कारण यह धीमा है। minimal Linux install और तेज local storage का उपयोग अधिक उपयुक्त है।
  • EBS में Copy-On-Write support की कमी: EBS Copy-On-Write को support नहीं करता, और snapshot S3 में store होने के कारण IOPS allocation में देरी होती है।
  • on-premises hardware की ओर जाना: Depot on-premises hardware पर जाकर performance optimize कर सकता है और cost कम कर सकता है। ग्राहक के CI jobs को सीधे hypervisor पर boot करना बेहतर approach हो सकता है।