निरंतर नवाचार: AWS block storage का एक संक्षिप्त इतिहास

 (allthingsdistributed.com)
2 पॉइंट द्वारा GN⁺ 2024-08-23 | 1 टिप्पणियां | WhatsApp पर शेयर करें

निरंतर नवाचार: AWS block storage का एक संक्षिप्त इतिहास

  • परिचय

    • Marc Olson ने Elastic Block Store(EBS) टीम में 10 साल से अधिक समय तक काम किया है.
    • EBS एक साधारण block storage service से विकसित होकर एक बड़े पैमाने की network storage system बन गया है, जो प्रतिदिन 140 ट्रिलियन से अधिक operations संभालता है.
    • यह लेख EBS के विकासक्रम और उससे मिले महत्वपूर्ण सबक साझा करता है.

  • EBS का शुरुआती इतिहास

    • EBS को 20 अगस्त 2008 को लॉन्च किया गया था, और इसकी शुरुआत EC2 instances के लिए network-attached block storage देने के एक सरल विचार से हुई थी.
    • शुरुआती दिनों में यह shared hard disk drives(HDD) का उपयोग करता था, जबकि आज यह एक ही EC2 instance को सैकड़ों हजार IOPS तक प्रदान कर सकता है.
    • आज EBS distributed SSD fleet के माध्यम से प्रतिदिन 140 ट्रिलियन से अधिक operations संभालता है.

  • Queuing theory

    • storage के साथ interaction करने का computer systems का तरीका मूल रूप से नहीं बदला है.
    • CPU requests को queue में डालता है, और storage device CPU memory से data लेकर उसे durable media पर लिखता है, या उल्टा data को CPU memory तक भेजता है.
    • इस प्रक्रिया को समझने में queuing theory महत्वपूर्ण भूमिका निभाती है.

  • HDD से SSD की ओर बदलाव

    • शुरुआती EBS में HDD का उपयोग होता था, जिसकी performance भौतिक सीमाओं के कारण सीमित थी.
    • SSD आने के बाद random requests को भी लगभग sequential requests जितनी तेजी से प्रोसेस करना संभव हो गया.
    • 2012 में SSD का उपयोग करने वाला एक नया storage server type और Provisioned IOPS नाम का नया EBS volume type लॉन्च किया गया.

  • मापन और प्रबंधन

    • 2012 के समय EBS के पास केवल बुनियादी telemetry थी.
    • system performance सुधारने के लिए यह पता लगाना जरूरी था कि समस्या कहाँ है, और फिर प्राथमिकता के अनुसार उसे हल किया जाए.
    • कई subsystems में IO को मापने के तरीके बनाए गए, और निरंतर monitoring के जरिए बदलावों का पता लगाया गया.

  • संगठन का divide and conquer

    • EBS storage server team को छोटे-छोटे teams में पुनर्गठित किया गया, जो data replication, durability, snapshot hydration जैसे विशिष्ट क्षेत्रों पर केंद्रित थीं.
    • हर team स्वतंत्र रूप से बदलावों पर iteration कर सकती थी और उन्हें commit कर सकती थी.

  • मान्यताओं को चुनौती देना

    • यह पता चला कि Xen hypervisor की default settings performance को सीमित कर रही थीं.
    • Nitro offload cards का उपयोग करके network और storage processing tasks को hardware पर offload किया गया.

  • Network tuning के प्रयोग

    • EBS को Nitro पर ले जाने के दौरान network का अपना overhead बढ़ गया.
    • network performance सुधारने के लिए TCP की जगह SRD(Scalable Relatable Diagram) protocol विकसित किया गया.

  • constraints नवाचार को बढ़ावा देते हैं

    • सभी customers को SSD के फायदे देने के लिए मौजूदा hardware को बदले बिना SSD जोड़े गए.
    • servers में SSD को हाथ से जोड़ा गया, नई writes को पहले SSD पर स्टोर किया गया, और फिर उन्हें asynchronously HDD पर flush किया गया.

  • performance scaling पर चिंतन

    • व्यक्तिगत विकास की कहानी: छोटी कंपनी की संस्कृति से बड़े संगठन में बदलाव.
    • साथियों के साथ debugging sessions के जरिए समस्याएँ हल की गईं और team की efficiency बढ़ाई गई.

  • निष्कर्ष

    • EBS किसी एक बड़े बदलाव से नहीं, बल्कि क्रमिक सुधारों की एक श्रृंखला के जरिए विकसित हुआ है.
    • customers की मांग लगातार बढ़ती रहेगी, और यही निरंतर innovation और iteration की प्रेरणा बनी रहेगी.

# GN⁺ की संक्षिप्त टिप्पणी

  • यह लेख AWS के EBS के विकास पर एक insider perspective देता है.
  • इसमें queuing theory, SSD adoption, network tuning जैसी कई तकनीकी चुनौतियों और उनके समाधानों पर चर्चा की गई है.
  • performance सुधार के लिए निरंतर measurement और management के महत्व पर जोर दिया गया है.
  • समान कार्यक्षमता वाले उत्पादों में Google Cloud Persistent Disk और Microsoft Azure Disk Storage शामिल हैं.

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

1 टिप्पणियां

 
GN⁺ 2024-08-23
Hacker News राय

  • अगर आपको बड़े सिस्टम्स में दिलचस्पी है, तो यह लेख पढ़ना अच्छा रहेगा

    • हार्ड ड्राइव का performance queue में मौजूद दूसरे transactions पर निर्भर करता है
    • random 4kB workloads में performance काफ़ी गिर सकता है
    • queuing और scheduling मदद करते हैं, लेकिन वास्तविक performance workload के अनुसार 100x से भी ज़्यादा बदल सकता है
    • multi-tenant systems में, खासकर read operations में, कठिनाइयाँ होती हैं

  • समस्या हल करने के लिए यह जानना ज़रूरी है कि गड़बड़ी कहाँ है

    • Marc से सीखा सबसे बड़ा सबक यह था कि visualization के ज़रिए टीम का नज़रिया बदला जा सकता है
    • performance data को कई तरीकों से analyze करने पर छिपी हुई efficiency और opportunities दिखाई दे सकती हैं

  • 2013 में EBS servers में SSD लगाने वाला प्रोजेक्ट AWS की दिलचस्प कहानियों में से एक था

    • सिस्टम को शुरू से ही non-destructive maintenance events को ध्यान में रखकर design किया गया था
    • distributed systems बनाने से बड़े पैमाने पर operations संभव हो जाते हैं

  • AWS का लगभग 4 दिन का outage EBS की वजह से हुआ था, और इससे AWS पर भरोसा हिल गया था

    • इसके बाद EBS में investment बढ़ा
    • यह उसी समय के आसपास हुआ जब Apple customer बन रहा था

  • Reddit, 2008 में EBS के शुरुआती users में से एक था

    • उसने software RAID का इस्तेमाल करके IOPS बढ़ाने की कोशिश की, लेकिन performance consistent नहीं था
    • RAID की समस्याओं को हल करने में समय लगा
    • Netflix ने EBS का इस्तेमाल नहीं किया

  • random latency जोड़ने से average latency और outliers दोनों कम हो सकते हैं

  • बड़े internet companies में काम करते हुए कई सबक मिले

    • apprenticeship के ज़रिए अहम knowledge और skills जल्दी सीखी जा सकती हैं
    • interviews के दौरान experience और mentors की recommendation बहुत काम आती है

  • 2013 में सभी EBS units में SSD को manually install करने वाला हिस्सा दिलचस्प लगा

    • 2010-2012 के बीच I/O performance एक अहम मुद्दा था

  • 2009 में Amazon S3 के internals पर एक talk दी गई थी

    • इस talk का EBS development पर असर पड़ा

  • cloud के शुरुआती दौर में general-purpose hardware इस्तेमाल होता था, लेकिन अब हर service के लिए specialized hardware इस्तेमाल होता है

    • AWS, Graviton, Inferentia, Tranium chips का इस्तेमाल करता है
    • Google, TPU और Titan security cards का इस्तेमाल करता है
    • Azure, FPGA और Sphere का इस्तेमाल करता है

  • पहला diagram गलत या पुराना है

    • modern computers में ज़्यादातर PCIe lanes सीधे CPU से जुड़े होते हैं
    • यह I/O throughput और latency के लिए एक अहम प्रगति है

  • मैं नए EC2 instances को तेज़ 256GB dataset directory देने का सबसे अच्छा तरीका ढूँढ रहा हूँ

    • EBS volumes इस्तेमाल कर रहा हूँ, लेकिन updates झंझट भरे हैं
    • EFS बहुत धीमा है
    • instance storage SSD अस्थायी है
    • FSx Lustre अभी तक आज़माया नहीं है