S3 नामक विशाल स्टोरेज सिस्टम का निर्माण और संचालन
(allthingsdistributed.com)- Amazon S3 की शुरुआत 14 मार्च 2006 को लॉन्च हुए HTTP REST API आधारित object storage के रूप में हुई थी, और यह सैकड़ों microservices तथा कई dedicated teams द्वारा साथ मिलकर संचालित किए जाने वाले बड़े पैमाने के service में विकसित हो गया
- S3 का scale केवल code से नहीं समझाया जा सकता; hard disks, firmware, data centers, operations organization, और customer workloads लगातार एक-दूसरे से जुड़कर बदलने वाला system हैं
- HDD की capacity और cost efficiency बहुत बेहतर हुई है, लेकिन random access performance अभी भी mechanical सीमाओं में बंधी है, इसलिए S3 लाखों disks की I/O heat management और data placement को मुख्य समस्या के रूप में देखता है
- Replication और Reed-Solomon आधारित erasure coding न केवल durability बढ़ाते हैं, बल्कि overloaded disks से बचकर requests को route करने में मदद करते हैं, जिससे performance और tail latency management में भी योगदान मिलता है
- S3 operations को durability reviews, Rust आधारित ShardStore, lightweight formal verification, और team-level ownership के जरिए तेज development और ऊंचे durability standards दोनों को साथ बनाए रखने के लिए design किया गया है
S3 को एक विशाल service system के रूप में देखना
- S3 एक object storage service है और यह HTTP REST API, frontend fleet, namespace service, hard disk आधारित storage fleet, और background job fleet से बना है
- हर बड़े component के लिए S3 organization के अंदर अलग area, leader, और कई teams होती हैं; अंदर के components भी अपनी fleet और team के साथ operate होते हैं
- आज S3 सैकड़ों microservices से बना है, और teams के बीच interactions लगभग API-level contracts जैसे हैं
- अगर modularity गलत design हो जाए, तो teams के बीच interaction भी inefficient और awkward हो सकता है; इसे ठीक करना भी software और teams को साथ design करने की प्रक्रिया में शामिल है
सिर्फ software नहीं, पूरा service ही system है
- S3 customers packaged software नहीं, बल्कि service experience खरीदते हैं, और वे लगातार तथा predictable quality की अपेक्षा रखते हैं
- S3 की system boundary केवल code तक सीमित नहीं है
- disks के पास चलने वाला code
- data center में नए storage racks install करने वाले technicians
- performance tune करने वाली customer applications
- hardware, finance, और engineering organizations
- S3 software, hardware, और लोगों के साथ लगातार बढ़ने और बदलने वाले living system के ज्यादा करीब है
- एक simple whiteboard architecture diagram हर box के अंदर मौजूद विस्तारित services और scale को छिपा देता है, इसलिए वास्तविक system को कम करके आंकने पर मजबूर करता है
HDD की physical limits S3 design को कैसे प्रभावित करती हैं
- S3 लाखों hard disks का उपयोग करने वाला बहुत बड़ा system है, और HDD की विशेषताएं design की central constraints में से एक हैं
- 1956 के IBM 350 disk storage unit के बाद HDD में बहुत विकास हुआ है
- वर्तमान में उल्लेखित सबसे बड़ा HDD Western Digital Ultrastar DC HC670 26TB है
- RAMAC के बाद capacity 72 लाख गुना बेहतर हुई है
- physical size 5,000 गुना छोटा हुआ है
- inflation-adjusted आधार पर प्रति byte cost 6 अरब गुना सस्ती हुई है
- लेकिन seek time केवल 150 गुना सुधरा है, और random read/write performance लगभग 120 operations per second के स्तर पर ही रहती है
- यह performance figure 2006 में S3 के लॉन्च के समय भी लगभग समान था, और उससे 10 साल पहले से भी बहुत अलग नहीं था
- HDD mechanical devices हैं, इसलिए arm के move करने और platter के rotate होने का इंतजार करना पड़ता है; capacity growth जितनी तेज है, random access performance उतनी बेहतर नहीं होती
- industry roadmap अगले 10 वर्षों में 200TB HDD तक पहुंचने का रास्ता दिखाता है, और उस स्तर पर, अगर पूरे data पर fair random access माना जाए, तो disk data के हर 2TB के लिए प्रति second केवल 1 I/O ही उपलब्ध होगा
- S3 अभी 200TB drives का उपयोग नहीं करता, लेकिन ऐसी drives और इनके बीच की सभी drive sizes का उपयोग करने की उम्मीद रखता है
Heat management: data placement और performance
- S3 में heat का अर्थ है किसी खास समय पर एक disk में आने वाली requests की संख्या
- Heat management गलत होने पर requests किसी खास disk पर जमा हो जाती हैं और hotspot बनता है, जिससे उस disk पर निर्भर requests की overall performance खराब होती है
- Hotspot system को तुरंत बंद करने के बजाय request queues बनाता है और customer experience को खराब करता है
- busy disk का इंतजार कर रही requests delay होती हैं
- delay metadata lookup या erasure coding जैसे dependent I/O के जरिए storage stack की ऊपरी layers तक amplify होता है
- कुछ requests में high latency, यानी straggler, पैदा होते हैं
- individual HDD के hotspot से tail latency आती है, और अगर इसे न संभाला जाए तो यह overall request latency को भी प्रभावित करता है
- S3 जब data लिखा जाता है, उस समय यह नहीं जान सकता कि भविष्य में उसे कब और कैसे access किया जाएगा, इसलिए write time पर data placement decisions कठिन होते हैं
- छोटे scale पर I/O heat prediction और management बहुत कठिन है, लेकिन S3 के scale और multitenancy में अलग characteristics दिखती हैं
- Individual workloads ज्यादातर समय idle रहती हैं और अचानक peak दिखाती हैं, लेकिन लाखों workloads को मिलाने पर total demand smooth और predictable हो जाती है
- एक निश्चित scale से आगे individual workload के लिए overall peak को प्रभावित करना कठिन या असंभव हो जाता है
Replication और erasure coding durability और performance दोनों को संभालते हैं
- Storage systems में redundancy के तरीके data को hardware failures से बचाने के साथ-साथ heat distribution में भी मदद करते हैं
- Replication कई disks पर copies रखता है ताकि disk failures झेले जा सकें, और read requests को कई copies में से किसी से भी serve किया जा सके
- Replication capacity के नजरिए से महंगा है, लेकिन read I/O के नजरिए से efficient है
- S3 सभी data पर replication overhead न चुकाने के लिए erasure coding भी इस्तेमाल करता है
- उदाहरण के तौर पर तरीका Reed-Solomon जैसे algorithms का उपयोग करता है
- object को k identity shards में बांटता है
- m parity shards अतिरिक्त बनाता है
- कुल k+m shards में से अगर केवल k उपलब्ध हों, तो object पढ़ा जा सकता है
- यह approach समान संख्या के failures झेलते हुए भी capacity overhead घटाता है
Data placement strategy और customer workload isolation
- Redundancy का तरीका data को required reads की संख्या से अधिक pieces में बांटता है, जिससे overloaded disks से बचकर requests भेजी जा सकती हैं
- S3 नए objects को पूरी disk fleet में व्यापक रूप से place करके heat को और कम करता है
- Individual objects दर्जनों drives में encoded हो सकते हैं, और अलग-अलग objects अलग-अलग drive sets पर place किए जाते हैं
- हर bucket के अंदर objects को कई disks में फैलाने से दो फायदे होते हैं
- किसी एक disk में customer data का हिस्सा बहुत छोटा हो जाता है, जिससे individual workload के लिए किसी खास disk पर hotspot बनाना कठिन हो जाता है
- individual workload disk scale के उस स्तर तक burst कर सकता है जिसे independent system के रूप में बनाना कठिन और महंगा होता
- Genome analysis customers द्वारा हजारों Lambda functions से parallel analysis करने वाला burst 10 लाख से अधिक individual disks द्वारा handle किया जा सकता है
- आज S3 में ऐसे हजारों customers हैं जिनकी buckets लाखों drives में distributed हैं
- S3 की खासियत केवल storage system के scale में नहीं है, बल्कि इस बात में भी है कि customers और workloads के aggregation का scale system के स्वभाव तक को बदल सकता है
Durability review और guardrails
- Amazon engineers और teams को तेज, सुरक्षित तरीके से fail करने में सक्षम बनाना महत्वपूर्ण मानता है
- S3 high-durability storage प्रदान करते हुए भी तेजी से आगे बढ़ने के लिए durability review प्रक्रिया का उपयोग करता है
- Durability review statistical 11 9s model में शामिल mechanism नहीं है, लेकिन S3 operations में इसे महत्वपूर्ण माना जाता है
- अगर किसी engineer का change durability state को प्रभावित कर सकता है, तो durability review किया जाता है
- यह process security research के threat model idea से लिया गया है
- change summary लिखी जाती है
- comprehensive threat list बनाई जाती है
- change उन threats को कैसे withstand करता है, यह organize किया जाता है
- Durability review दो भूमिकाएं निभाता है
- author और reviewers को उन risks पर critical thinking करने के लिए प्रेरित करता है जिनसे protection चाहिए
- risks और countermeasures को अलग करके प्रत्येक पर अलग चर्चा करने देता है
- Countermeasures खोजते समय, हर detailed risk के लिए अलग mitigation लगाने के बजाय, wide risk classes को रोकने वाले simple और मजबूत guardrail को प्राथमिकता दी जाती है
ShardStore, Rust, lightweight formal verification
- S3 ने कुछ साल पहले storage stack की सबसे निचली layer, यानी individual disks के data को manage करने वाले हिस्से को scratch से फिर से लिखने का project शुरू किया
- नई storage layer का नाम ShardStore है
- ShardStore को फिर से बनाते समय अपनाए गए guardrails में से एक lightweight formal verification था
- Team ने bugs को जल्दी पकड़ने के लिए implementation language को Rust में shift किया
- type safety का उपयोग किया
- structured language support का उपयोग किया
- on-disk structures तक type safety extend करने वाली library लिखी
- Verification के मामले में, ShardStore logic का simplified model Rust में लिखा गया और actual production ShardStore implementation के साथ same repository में रखा गया
- यह model actual on-disk storage layer और HDD की complexity हटाकर executable specification की तरह काम करता है
- Model का size actual system का लगभग 1% था, लेकिन इसने 120 IOPS hard drive के मुकाबले अवास्तविक स्तर की testing संभव बनाई
- यह काम SOSP paper Using lightweight formal methods to validate a key-value storage node in Amazon S3 के रूप में भी प्रकाशित हुआ
- बाद में tools और property-based testing जैसी existing techniques का उपयोग करके verify किया गया कि implementation behavior specification से match करता है
- मुख्य बात यह है कि formal verification research techniques को ऐसे code और tools के रूप में industrialize किया गया जिन्हें general engineers maintain कर सकें और जो हर commit पर लागू हों
- Verification guardrail ने team को अधिक तेजी से develop करने का confidence दिया, और नए engineers के जुड़ने के बाद भी यह जारी रहा
Ownership से teams और individuals की scaling problem संभालना
- Amazon में ownership का अर्थ है किसी specific task या service को सफल बनाने की end-to-end responsibility किसी एक individual या team के लिए स्पष्ट करना
- S3 में तेजी से आगे बढ़ते हुए high quality bar बनाए रखने के लिए teams को owners बनना पड़ता है
- अन्य systems के साथ API contracts own करना
- durability, performance, availability की जिम्मेदारी लेना
- unexpected bug availability को प्रभावित करे तो सुबह 3 बजे भी उसे ठीक करना
- bug fix के बाद system को सुधारना ताकि वही चीज दोबारा न हो
- Ownership बड़ी responsibility के साथ trust भी मांगता है
- किसी individual या team को service own करनी हो, तो उसे यह तय करने की गुंजाइश चाहिए कि उसे कैसे deliver करना है
- Graduate research project के अनुभव में भी, जब student किसी idea को अपना मानता है और उसे खुद आगे बढ़ा सकता है, तो वह उसमें गहराई से invest करता है
- बहुत senior engineer role में, solution को सीधे deploy करने जैसा प्रस्तुत करने के बजाय problem को अच्छी तरह define करना और team को solution own करने में मदद करना अधिक effective होता है
- जिन problems के कई solutions हो सकते हैं, उनमें उचित solution चुनने देना किसी को solution ownership देने का तरीका बनता है
S3 से मिली सीख
- S3 का technical scale छोटे systems से केवल ज्यादा बड़ा नहीं है; workloads, structure, और operations model खुद fundamentally अलग हैं
- “System” में केवल software नहीं, बल्कि service operations, operations organization, और उस service के साथ चलने वाला customer code भी शामिल है
- Organization भी system का हिस्सा है, इसलिए उसकी अपनी scaling problems और innovation opportunities होती हैं
- Individual role में सफल होने के लिए solution से अधिक problem को स्पष्ट रूप से व्यक्त करना और strong engineering teams को solutions वास्तव में own करने में support करना जरूरी है
2 टिप्पणियां
Hacker News की राय
AWS में रहते हुए जो बातचीत याद है, उनमें से एक यह थी कि अरब में एक बार होने वाली घटना भी S3 के पैमाने पर रोज़ होती है
आम तौर पर जिन चीज़ों को इतनी दुर्लभ मानकर चिंता के लायक नहीं समझा जाता, उन्हें भी ज़रूर ध्यान में रखकर संभालना पड़ता है
ShardStore, खासकर formal verification और property-based testing जैसे तरीकों को देखकर अच्छा लगा। पिछली पीढ़ी की सेवाओं में organic growth के खतरे साफ़ दिखाने जितने bug थे, लेकिन कम-से-कम उन्हें इस तरह design किया गया था कि failures “safe” तरीके से हों, ताकि data loss रोका जा सके, और S3 engineers इस बात को लेकर बेहद जुनूनी थे
सिर्फ S3 ही ऐसा नहीं है। उदाहरण के लिए, Prime Day 2022 पर DynamoDB अकेले Amazon workloads से ही हर सेकंड 10.5 करोड़ से ज़्यादा तक पहुँच गया था: https://aws.amazon.com/blogs/aws/amazon-prime-day-2022-aws-f...
लेख में Andy lightweight formal methods और टीम द्वारा Rust अपनाने की बात भी करते हैं; ऐसे पैमाने पर, जहाँ बेहद कम probability वाली घटनाएँ भी आम हो जाती हैं, correctness के लिए tools और processes की कई layers में निवेश करना पड़ता है
मैंने समझाया कि अगर हम target 500k TPS तक पहुँचे, तो यह मिनट में 30 बार होगा, और पूछा, “उस हफ़्ते on-call रहना चाहोगे?” उस stack में “highest standards पर टिके रहना” का मतलब ज़्यादातर संगठनों से बिल्कुल अलग हो जाता है
शुक्र है algorithm अच्छा था, और आज का hardware भी कहीं ज़्यादा stable है
दिमाग में एक थोड़ी तिरछी आवाज़ भी है जो पहले बड़े cryptographic hash collision के फूटने पर उसका असर देखने का मौका मिले तो popcorn लेकर देखने को तैयार है
Genomics में काम करते हुए पिछले 10 सालों में मैंने petabyte-scale data stores बहुत संभाले हैं
AWS S3, GCP GCS, और colocation hardware के लिए storage systems (Ceph, Gluster, और वह HP system जिसका नाम मैंने याद से मिटा दिया है) इस्तेमाल करके, ऐसे systems चलाने में लगने वाली मेहनत के लिए बहुत सम्मान पैदा हुआ
कई दूसरे customers के साथ disk I/O share करने के फायदे को भी कम करके नहीं आँका जा सकता। लेख में आया “heat” शब्द मैंने पहली बार सुना, लेकिन किसी single system में इसे कम करना सच में बहुत कठिन है। हमारे colocation cluster में बड़े jobs के बीच I/O ठीक से manage करने के लिए हमें batch system बदलना पड़ा, ताकि I/O को RAM या CPU की तरह allocatable resource माना जाए। S3 और GCP बहुत महंगे हैं, लेकिन कई बार performance उस कीमत को सही ठहराती है
ऐसे लेख ही HN का सबसे अच्छा पहलू लगते हैं
cloud storage के नज़रिए से सबसे अच्छे customers वे हैं जो बहुत सारा data store करते हैं लेकिन उसे शायद ही कभी पढ़ते हैं। यह hard disk rent करने जैसा है, लेकिन अगर हर disk का सिर्फ कुछ हिस्सा “cold” data से भरा हो, तो उसी disk की पूरी I/O capacity को hot workloads संभालने में लगातार इस्तेमाल किया जा सकता है
कौन-सा data किस drive पर रखना है, इसे बहुत सावधानी से balance किया जाए, तो ज़्यादातर data इस्तेमाल न होने पर भी सभी drives का उपयोग जारी रखा जा सकता है। इसलिए storage अपेक्षाकृत सस्ता और reads अपेक्षाकृत महंगे होते हैं
S3 support करने पर भी performance अक्सर उससे कहीं धीमी होती है जितनी हो सकती है
यह कठिन है, और read availability सिर्फ करीब 99.95% होने के लिए माफ़ी
अगर S3 ने read/write access delegation के लिए कोई सरल OAuth2-आधारित protocol परिभाषित किया होता, तो उससे बहुत कुछ बनाया जा सकता था
दुनिया को एक HTTP-आधारित protocol की ज़रूरत है जिससे apps, users की ओर से data access कर सकें। Google Drive इसके सबसे करीब है, लेकिन provider सिर्फ एक है और दूसरी समस्याएँ भी हैं[0]। अफसोस है कि remoteStorage जगह नहीं बना पाया। उम्मीद है Solid सफल होगा, लेकिन मुझे यह बहुत जटिल लगता है। इस समस्या पर मेरा तरीका https://gemdrive.io/ है, लेकिन अभी self-hosting stack के दूसरे हिस्सों पर ध्यान देने की वजह से यह लगभग रुका हुआ है
[0]: https://gdrivemusic.com/help
अभी इसे सही ढंग से करना बेहद कठिन है। “सिर्फ इस खास bucket तक access कर सकने वाले AWS credentials जारी करना” वाली समस्या हल करने के लिए मैंने पूरा एक CLI app बना दिया, लेकिन users से इसे install और run करने को कहना नहीं चाहता: https://s3-credentials.readthedocs.io/en/stable/
असल में, एक ऐसी library होनी चाहिए जो local directory mount करे जो असल में user का S3 bucket हो, और client-side dependency न्यूनतम हो
क्योंकि competitor कभी भी adversarial interoperability के जरिए हमला कर सकता है
user data sovereignty बनाने की कोशिश कर चुके या कर रहे सारे projects का अजीब cryptocurrency दिशा में बह जाना सच में अफसोसजनक है
https://docs.aws.amazon.com/cognito/latest/developerguide/co...
Edit: लगता है मैंने comment गलत पढ़ा। मैंने समझा था कि app user data को client को delegate करना चाहता है, जबकि असल में शायद user अपना data app को delegate करना चाहता है। ये अलग-अलग use cases हैं
IBM RAMAC की specification में storage capacity 3.75MB, लगभग 9,200 dollars per terabyte लिखा है, लेकिन यह सही हो ही नहीं सकता
cost को storage capacity से multiply करें तो drive की कीमत 3 cents निकलती है
यह site[1] कहती है कि यह “लगभग 2,000 bits per square inch store करता था और purchase price लगभग 10,000 dollars per megabyte” थी
इसलिए शायद specification 9,200 dollars per megabyte होनी चाहिए। तब drive की कीमत 34,500 dollars बनती है, जो ज़्यादा plausible है
[1]: https://www.historyofinformation.com/detail.php?entryid=952
यह 30 million bits था, और parity हटाकर सिर्फ 6 data bits इस्तेमाल किए गए थे। लेकिन इसे 3,000 dollars per month पर lease किया जाता था, इसलिए physical drive को एकमुश्त खरीदने जैसी fixed cost नहीं थी। उस मायने में यह S3 model से भी काफी मिलता-जुलता है
ज्यादातर लोग यह नहीं समझते कि magic system को खुद संभालने में नहीं, बल्कि authorization को ऐसा दिखाने में है जैसे उसकी कोई cost नहीं है
distributed systems में authorization बेहद कठिन है। AWS के scale पर यह असल में magic जैसा है। AWS के पास rich permission model है, और permission changes शायद trillions requests handle करते हुए भी पूरी infrastructure में sub-millisecond speed से propagate होते हैं
यह हिस्सा और billing के लिए logging/settlement, AWS के वे दो जादुई पहलू हैं जिनके बारे में मैं लिखित रूप में पढ़ना चाहूंगा
S3 access control को दूसरी services से अलग तरीके से handle करता है, permissions resource से जुड़ी होती हैं। शायद speed की वजह से ऐसा है
bucket/key approach के खास होने की एक वजह यह है कि IAM आने तक वह model पहले से स्थापित हो चुका था
बाद में भी यह इसलिए बना रहा होगा कि पुराने model को हटाना कई customers की settings तोड़ सकता था, इसलिए यह मुश्किल काम होता
“कंपनी में एक बहुत senior engineer के तौर पर, स्वाभाविक रूप से मेरे मजबूत विचार भी हैं और technical agenda भी है। लेकिन engineers के साथ interact करते समय अगर आप बस अपने ideas बांटने की कोशिश करें, तो सबके लिए सफल होना मुश्किल हो जाता है। जिस idea का मालिकाना आपका नहीं है, उसमें गहराई से जुड़ना कहीं ज्यादा मुश्किल होता है। इसलिए teams के साथ काम करते हुए मैंने यह strategy अपनाई है कि मेरे सबसे अच्छे ideas मेरे नहीं, बल्कि दूसरे लोगों के ideas बन जाएं। solution बेचने की बजाय, मैं जानबूझकर समस्या को विकसित करने और उसे बहुत अच्छे से व्यक्त करने में कहीं ज्यादा समय लगाता हूं। किसी समस्या को हल करने के तरीके अक्सर कई होते हैं, और सही तरीका चुनने का मतलब है कि कोई उस solution का ownership ले।”
“मैंने सीखा है कि अपनी भूमिका में सचमुच सफल होने के लिए मुझे solution नहीं, बल्कि समस्या को साफ़-साफ़ व्यक्त करने पर focus करना चाहिए, और ऐसे तरीके खोजने चाहिए जिनसे एक मजबूत engineering team उस solution का सचमुच ownership ले सके।”
यह हिस्सा सच में बहुत अच्छा लगा। कुछ हद तक Ikea effect की याद दिलाता है। अगर आप चाहते हैं कि कोई अपने काम को लेकर passionate हो, तो ownership की भावना को बढ़ावा देना चाहिए, और अच्छा तरीका यह है कि वह काम “उस व्यक्ति का idea” बन जाए
आखिर लोग अक्सर इस बात पर ही अलग-अलग राय रखते हैं कि “समस्या” क्या है
अच्छी बात है कि हर समस्या ऐसी नहीं होती। लेकिन उदाहरण के लिए Python की “packaging problem” वाली चर्चाओं को देखें, तो असल में करीब 6 अलग-अलग समस्याएं हैं जिन्हें लोग बहुत अलग तरीकों से describe कर रहे हैं, और यह phenomenon काफी खराब तरीके से सामने आता है
अगर Andy Warfield पढ़ रहे हैं—और शायद पढ़ रहे होंगे—तो मेरा एक सवाल है। समस्या को विकसित करते समय संभावित solutions का sketch बनाना कितना valuable है? समस्या को साफ़ तौर पर व्यक्त करने पर कुछ संभावित solutions स्वाभाविक रूप से दिमाग में आएंगे; क्या potential owners की सोच शुरू कराने के लिए उन solutions को share करना worthwhile है? या सिर्फ समस्या पर focus करना और solution space को पूरी तरह खुला छोड़ देना बेहतर है?
इसके अलावा, ऐसे बहुत senior individual contributor के काम करने के तरीके के बारे में और पढ़ने लायक कोई सामग्री है?
मुझे यह ऐसा सुनाई देता है जैसे, “ओ साधारण इंसान! मेरे पास तुम्हारी समस्या पर ध्यान देने का समय नहीं है। अगर तुम सिर्फ समस्या लाओगे तो तुम्हारे काम से मेरा promotion कैसे होगा”
किसी समस्या को हल कर सकने के लिए पहले उसे समझना और उसके अस्तित्व को स्वीकार करना जरूरी है
ऐसी स्थितियों में जहां पहले से मान्यता प्राप्त authority या expertise नहीं होती—यानी ज्यादातर रोजमर्रा की समस्याएं जिन contexts में सामने आती हैं—अगर आप लंबा, detail में और सोच-समझकर तैयार किया गया problem description देकर दो-तरफा बातचीत का channel अकेले घेर लेते हैं, तो आसानी से ऐसे लग सकते हैं जैसे आप सिर्फ बातें करना चाहते हैं, काम नहीं, या जैसे आप दूसरों के साथ मिलकर solution ढूंढना नहीं चाहते
यह देखकर अच्छा लगा कि Amazon employees अब S3 की internal working के बारे में सार्वजनिक रूप से बात कर पा रहे हैं
Glacier कैसे काम करता है, इसके बारे में भी और सुनना चाहूंगा। मेरी जानकारी में उन्होंने कभी यह publicly नहीं बताया कि underlying storage medium क्या है, इसलिए tape है, offline HDD है, custom HDD है—हर तरह की speculation होती रही है
लेकिन कुछ लोग इससे सहमत नहीं हैं। यह अभी भी अज्ञात है
काश AWS उस पर और उसकी पूरी journey पर सब कुछ बताए। यह सच में बेहद दिलचस्प चीज है
बस किसी एक engineer का नशे में बक देना ही काफी होता। कहीं ज्यादा गंभीर क्षेत्र में, Massachusetts के एक soldier ने अपने gamer friends को cool दिखने के लिए Discord पर national security information leak कर दी और अब लंबी jail term का सामना कर रहा है। मुझे लगा था कि Glacier की details अब तक बाहर आ चुकी होंगी
“Hard disk head की कल्पना एक 747 के रूप में करें जो lawn के ऊपर 75 miles per hour की रफ्तार से उड़ रहा है। airplane के bottom और grass की tips के बीच air gap दो sheets of paper जितना है। अगर disk के bits को grass blades से मापा जाए, तो track width 4.6 grass blades जितनी चौड़ी है और bit length एक grass blade है। जब airplane grass के ऊपर उड़ते हुए grass blades गिनता है, तो वह पृथ्वी के 25,000 चक्कर लगाने पर सिर्फ एक grass blade miss करता है।”
load balancing वाला हिस्सा देखकर S3 KeyMap के दिनों और early implementation से उस पर migrate करने की कोशिशों की याद आ गई
सीखी गई बात यह थी कि सबसे hot object/partition/bucket को identify कर लेने के बाद भी आप उसे बस move करके काम खत्म नहीं कर सकते। सब कुछ sort करना पड़ता था। असल solution था sort करना, फिर host के partition load को quartiles में बांटना, और second-quartile partition को सबसे कम load वाले host पर move करना
अगर सबसे hot bucket, यानी first quartile, को move करने की कोशिश करते, तो बाकी members पर और load आ जाता और failure चलता रहता
एक और side effect के रूप में error rate स्थिर करीब 1% से बदलकर कई दिनों तक zero errors हो गया, और नतीजे में alerting thresholds को काफी ज्यादा strict update किया गया। यह लगभग 2009 के आसपास की बात थी
मेरा भी UM का academic background था, लेकिन PhD program की बजाय S3 join किया। तुक भी मिलती है
S3 storage से बढ़कर है; यह एक standard है
कई जगहों पर S3-compatible storage इस्तेमाल कर पाना अच्छा है, आम तौर पर कुछ caveats के साथ। पता नहीं standard कितना open है, और “S3 compatible” कहने के लिए Amazon को पैसे देने पड़ते हैं या नहीं, लेकिन यह काफी बढ़िया है
उदाहरण के तौर पर iDrive का E2, Digital Ocean Object Storage, Cloudflare R2, Vultr Object Storage, Backblaze B2 हैं
edit: देखकर लगता है Azure में सच में नहीं है :-/
Hacker News राय
Genomics क्षेत्र में काम करते हुए, पिछले 10 सालों में मैंने कई petabyte data stores संभाले हैं।
अगर S3 OAuth2-आधारित protocol का उपयोग करके read/write access delegate कर सके, तो हम कितनी चीज़ें बना सकते हैं।
Distributed systems में authentication संभालना बहुत कठिन है।
Amazon कर्मचारियों को S3 के internal workings के बारे में खुलकर बात करते देखना अच्छा लगता है।
वह हिस्सा जहाँ hard drive head को 747 airplane से तुलना करके समझाया गया है।
S3 KeyMap के दिनों में वापस जाएँ तो, सबसे hot objects/partitions/buckets पहचान लेने के बाद भी यह सीखा कि सिर्फ़ उन्हें move कर देने से समस्या हल नहीं होती।
S3 सिर्फ़ एक storage नहीं, बल्कि एक standard है।