2023 में, महिमा बस 11MB/सेकंड दूर

 (thmsmlr.com)
2 पॉइंट द्वारा GN⁺ 2024-04-08 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • महीने में 20 करोड़ विज़िट पाने वाली टॉप-1000 श्रेणी की वेबसाइट भी, सिर्फ HTML देखें तो लगभग 30TB/माह, औसतन 11MB/सेकंड ट्रांसफ़र पर चलती है, यानी यह एक सिंगल सर्वर से संभाली जा सकने वाली स्केल है
  • यह गणना Business Insider को आधार बनाकर शुरू होती है: प्रति विज़िटर 2 पेज, महीने के 40 करोड़ HTML दस्तावेज़, compressed HTML लगभग 75KB, और यह मानकर कि JS·CSS·इमेज CDN पर दिए जाते हैं
  • edge execution का फ़ायदा यह है कि सर्वर यूज़र के क़रीब होता है, लेकिन rendering के दौरान अगर database round-trip होता है, तो latency फिर मूल DB लोकेशन तक खिंच जाती है
  • लागत का फ़र्क भी बड़ा है: Hetzner 16-core·64GB RAM·NVMe सर्वर $0.34/घंटा में देता है, 20TB मुफ़्त ट्रांसफ़र के बाद $1.5/TB लेता है, जबकि AWS और Vercel का bandwidth unit price काफ़ी ज़्यादा है
  • अगर काम ऐसा नहीं है जिसमें सचमुच cloud ज़रूरी हो, तो single server+SQLite+Litestream+CDN कॉन्फ़िगरेशन ज़्यादा सरल, सस्ता है, और बेवजह horizontal scaling से बचा सकता है

11MB/सेकंड के नज़रिए से टॉप वेबसाइटों का असली स्केल

  • टॉप-1000 श्रेणी की वेबसाइट के उदाहरण के रूप में Business Insider का उपयोग किया गया है
    • SimilarWeb के अनुसार इसकी वैश्विक रैंक 587 थी और मासिक विज़िटर लगभग 20 करोड़ थे
    • अगर प्रति विज़िटर औसतन 2 पेज मानें, तो महीने में 40 करोड़ HTML दस्तावेज़ सर्व करने होते हैं
    • एक सैंपल लेख के आधार पर standard HTML दस्तावेज़ compressed होने के बाद लगभग 75KB था
    • इसे गुणा करने पर सिर्फ HTML के लिए लगभग 30TB/माह bandwidth चाहिए
  • 30TB/माह को औसत में बदलें तो यह लगभग 11MB/सेकंड है
    • Business Insider के उदाहरण में यह लगभग 150 requests/sec के स्तर का है
    • यह मानकर कि HTML के लिए CDN उपयोग नहीं हो रहा, जबकि JS·CSS·इमेज CDN से सर्व किए जा सकते हैं
    • compressed HTML 75KB काफ़ी बड़ा है, इसलिए implementation के अनुसार HTML size घटाकर या request count बढ़ाकर समायोजन भी किया जा सकता है
  • आधुनिक हार्डवेयर पर application code का 11MB/सेकंड HTML जनरेट करना बहुत ऊँची मांग नहीं है
    • नवीनतम AMD server processor 64-core·128-thread देते हैं
    • Zen 5 Turin server processor के 192-core होने की चर्चा है, और dual-socket server में लगभग 400-core तथा 768-thread तक की कॉन्फ़िगरेशन का भी उल्लेख है
    • इस नज़रिए से Docker, serverless, और horizontal scaling हमेशा ज़रूरी विकल्प नहीं हैं

edge execution हमेशा latency नहीं घटाता

  • पृथ्वी के एक छोर से दूसरे छोर तक round-trip latency की भौतिक न्यूनतम सीमा, प्रकाश की गति के आधार पर, लगभग 200ms है
    • वास्तविकता में, पृथ्वी के दूसरी तरफ़ किसी अच्छे datacenter तक पहुँचने में अक्सर लगभग 300ms लगते हैं
  • अगर JS·CSS·media CDN से दिए जा रहे हों, तो initial rendering में server processing time के 300ms बचाना लगभग उतना ही असर दे सकता है जितना सर्वर को यूज़र के पास ले जाना
  • दूसरी पीढ़ी की serverless तकनीक ने अतीत की उस समस्या को काफ़ी कम किया है जिसमें cold boot आसानी से 300ms का latency budget खा जाता था, लेकिन database round-trip अब भी बना रहता है
  • अगर पेज rendering के लिए एक भी database query चाहिए, तो edge server को फिर us-east-1 जैसी जगह पर मौजूद मूल database तक round-trip करना पड़ता है
    • latency यूज़र-से-मूल-सर्वर के बीच से हटकर edge server-से-मूल-सर्वर के बीच चली जाती है
    • जटिल पेजों में rendering के लिए अक्सर 5 या उससे अधिक database queries की ज़रूरत पड़ती है
    • कई web framework single-threaded ढंग से queries को क्रमवार चलाते हैं, इसलिए datacenter के बीच कई round-trip होने पर यह सीधे origin तक एक बार जाने से भी धीमा हो सकता है
  • एक अनुभवजन्य नियम है कि datacenter-के-बीच communication, datacenter-के-अंदर communication से 10 गुना धीमा होता है, और datacenter-के-अंदर communication, उसी डिवाइस के अंदर communication से 10 गुना धीमा होता है
    • इसी संदर्भ में local SQLite latency कम करने के लिए एक फ़ायदेमंद विकल्प बनकर सामने आता है

Hetzner, AWS, Vercel की लागत का अंतर

  • Hetzner का 16-core server 64GB RAM और NVMe drive के साथ $0.34/घंटा है
  • तुलना के लिए लिया गया समान x86 server, AWS EC2 m5a.4xlarge, $0.68/घंटा का है
  • bandwidth pricing में अंतर और भी बड़ा है
    • Hetzner 20TB ट्रांसफ़र मुफ़्त देता है और उसके बाद $1.5/TB लेता है
    • AWS 100GB मुफ़्त देता है और उसके बाद $90/TB लेता है
    • Vercel के बारे में उदाहरण के तौर पर कहा गया है कि पहले 1TB मुफ़्त के बाद वह $200/TB लेता है
  • cloud vendor की free tier शुरुआत आसान बनाती है, लेकिन स्केल बढ़ने पर यह ऊँची लागत के रूप में वापस आ सकती है

single server कॉन्फ़िगरेशन के साथ सरल संचालन

  • अगर आपका उपयोग-परिदृश्य वीडियो transcoding, अपना AI model चलाना, या सिस्टम पर वास्तव में भारी लोड डालने वाले काम जैसा कोई विशेष cloud use case नहीं है, तो वेबसाइट या SaaS को single server पर चलाया जा सकता है
  • अगर सर्वर Virginia में रखा जाए, तो अंग्रेज़ी-भाषी यूज़रों को 100ms से कम latency दी जा सकती है
  • सुझाया गया सेटअप एक सर्वर के केंद्र में सरल रखा गया है
    • database के लिए उसी मशीन पर SQLite इस्तेमाल करें
    • Litestream से SQLite का निरंतर backup लें
    • CSS, JS, इमेज को CDN में cache करें
    • SQLite के पास server-side rendering करके round-trip घटाएँ और performance बढ़ाएँ
  • deployment को भी अनावश्यक रूप से जटिल बनाने की ज़रूरत नहीं है
    • CI कोड को सर्वर पर SCP कर सकता है
    • NGINX zero-downtime deployment को सपोर्ट करता है
    • Docker और virtualization को code execution और CI/CD को धीमा करने वाले तत्वों के रूप में देखा गया है

कब horizontal scaling चाहिए और कब नहीं

  • horizontal scaling की ज़रूरत होने की बात ज़्यादातर मामलों में बढ़ा-चढ़ाकर कही जाती है
  • इसके पीछे यह मान्यता है कि server performance, इंटरनेट की वृद्धि से भी तेज़ी से बेहतर हो रही है
  • अगर latency सचमुच बहुत महत्वपूर्ण है, तो Germany और California में अतिरिक्त सर्वर जोड़े जा सकते हैं
    • writes को primary पर route करें
    • reads के लिए local read replica इस्तेमाल करें
  • ऐसा सेटअप पर्याप्त रूप से scalable है, management complexity कम रखता है, और लागत भी काफ़ी कम होती है
  • 11MB/सेकंड के स्तर की HTML serving को बेवजह मुश्किल बनाने की ज़रूरत नहीं है

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

1 टिप्पणियां

 
GN⁺ 2024-04-08
Hacker News की राय

  • मेरा पुराना छोटा hosting business ठीक इसी मोड़ पर उठा और गिरा, लेकिन उस समय समझ नहीं आया कि क्या हो रहा था
    2000 के दशक की शुरुआत में जब हम बढ़ रहे थे, बड़ा revenue ज़्यादातर जटिल stacks से आता था, और redundant load balancers व firewalls जैसी ऐसी बहुत-सी configurations थीं जिनकी ग्राहकों को असल में ज़रूरत से ज़्यादा थीं, लेकिन वे उन्हें चाहते थे
    failover में अक्सर operation complexity की लागत, server के intended तरीके से मरने पर मिलने वाले लाभ से ज़्यादा होती थी, और हमने AWS के मुकाबले API-based cloud hosting platform भी बनाया, लेकिन revenue 2012 में peak पर पहुंचा
    ग्राहक ऐसे ज़्यादा जटिल solutions चाहते थे जिनमें AWS का कुछ या पूरा उपयोग हो, जबकि हम सोचते थे कि hardware 10 साल पहले की तुलना में कहीं अधिक ताकतवर हो गया है, इसलिए बड़े ग्राहक भी कम और सरल servers चाहेंगे
    लेकिन यह cleverness बेचना नहीं, कीमत बेचना था, और उस transition के लिए जरूरी financial ambition को हम समझ नहीं पाए। सस्ते single server पर किसी ने भरोसा नहीं किया, और दो server खरीदने पर भी scalability का जवाब अधूरा था
    आखिरकार revenue टिका रहा, लेकिन हम Amazon से तेज़ managed service stack और software ecosystem नहीं बना सके, और नई technical challenges सूख जाने के बाद 2018 में company बेच दी
    bootstrapped तरीके से बढ़े होने के कारण unlimited hosting bill एक पागलपन भरा risk लगता था, इसलिए product design भी उसी सोच से निकला था, लेकिन बाद में दिखा कि हर कोई वह risk ले रहा था
    AWS के जमने की वजह सिर्फ यह नहीं थी कि VC ने महंगे products को संभव बनाया, बल्कि यह भी थी कि उनकी अपनी तरह की cleverness software developers की एक पीढ़ी में built-in हो गई। हालांकि कब cloud की ज़रूरत नहीं है और alternatives क्या हैं, यह जानना अब काफी niche लगता है

    • AWS की complexity और cleverness developers के लिए catnip जैसी है, और resume-driven development को support करने के मामले में उसका मुकाबला बहुत कम है

  • numbers में कुछ समस्याएं हैं
    पहली, traffic समान रूप से नहीं फैलता। लेख का 400 million page loads/month वाला आंकड़ा recursive 80/20 rule के अधीन हो सकता है, और ऐसा मानें तो 5.8 घंटों में करीब 205 million requests आ जाएंगी, यानी लगभग 9.7k requests per second
    single system से भी संभव है, लेकिन अब यह मामूली नहीं रहता, खासकर अगर आप read replicas के बिना single DB भी चाहते हैं। कुल traffic वही हो तो भी peak load के लिए जरूरी bandwidth limit, optimistic average निकाले गए 11MB/s से कहीं ज्यादा हो जाती है
    दूसरी, one-way end-to-end latency सिर्फ streaming data पर लागू होती है। असली cold start में HTTP/3 न हो तो TCP connection के लिए 3 round trips और TLS connection के लिए कम से कम 2 round trips चाहिए, और उसके बाद ही HTTP request और response आते-जाते हैं
    असली लोगों को service देने के लिए observable हर चीज़ 1 second से कम में होनी चाहिए, और उसके बाद users द्वारा system को खराब मानकर tab बंद करने की दर तेजी से बढ़ती है
    पहले मैंने एक betting exchange चलाने में मदद की थी, जहां traffic बेहद spike करता था और latency requirements कड़े थे, और trading volume पूरे event window के बहुत छोटे हिस्से में केंद्रित था। real-time trading में user के action शुरू करने के क्षण से 100ms के अंदर screen पर result दिखना चाहिए था, और network round-trip latency event processing budget को खा जाती थी
    संदर्भ: https://www.nngroup.com/articles/response-times-3-important-...

    • Business Insider clone जैसी service में पहला point मुख्य है। कोई बड़ा Twitter account एक article link कर दे तो पूरे monthly average page loads कुछ ही मिनटों में आ सकते हैं
      ऐसा load भी बड़े single server setup से handle किया जा सकता है, लेकिन तब यह simple web server नहीं रहता, बल्कि built-in web server वाला काफी मजबूत frontend load balancer बनाने जैसा हो जाता है
      AWS महंगा ज़रूर charge करता है, लेकिन load balancers और network infrastructure में जबरदस्त engineering लगी है, जिसकी वजह से बाकी लोगों को stack के उस पूरे area के expert बनने की जरूरत नहीं पड़ती
    • दुनिया-भर वाला उदाहरण connection creation process को ध्यान में नहीं रखता, इसलिए थोड़ा हास्यास्पद है, लेकिन मुख्य तर्क अब भी सही है
      वास्तव में ऐसी कितनी services हैं जिन्हें global reachability चाहिए? क्या आपने multiple languages support भी साथ में बनाया है?
      अगर आप US या EU के भीतर service दे रहे हैं, तो एक अच्छा central server भी पूरे region को 30ms से कम latency दे सकता है
      जब तक सचमुच global requirement न हो और global database भी manage न करना हो, edge कुछ हद तक overhyped है

  • 500 Internal Server Error दिख रहा है, लगता है लेखक को 11MB/s से ज्यादा traffic मिल रहा है। archived version यहां है: https://archive.is/UVpg0

    • PR_END_OF_FILE_ERROR मैंने पहली बार देखा। कई websites कहती हैं कि यह proxy, VPN, DNS-over-HTTPS की वजह से होता है, लेकिन मेरे मामले में ऐसा नहीं है

  • मुझे लगता है यह लेख गलत नजरिए से देख रहा है
    बेहतर approach है कि बहुत जल्दी scale मत करो
    जितनी जरूरत हो उतना बनाओ, और ज्यादातर मामलों में CDN भी अनावश्यक खर्च है। बशर्ते आप cloud provider का excessive bandwidth tax न चुका रहे हों
    performance problems दिखने लगें तो तब handle कर लो, और अगर साधारण workhorse अचानक वह unicorn बन जाए जिसे हर कोई चाहता है, तो यह वैसी problem है जिसे आप रखना चाहेंगे

    • single server से शुरू कर सकते हैं। हम Facebook नहीं हैं, और startup की success पहले साल में महीने में एक बार 15-minute unexpected downtime होने या न होने पर निर्भर नहीं करती
      product ठीक हो तो users एक घंटे बाद फिर try करेंगे, सीधे competitor पर switch नहीं करेंगे। scalability problem आए तो resource-intensive हिस्सों को scalable hybrid model में ले जा सकते हैं
      फिर भी अगर आप शुरुआत से ही webscale, दर्जनों microservices, उनके बीच फटते failure states, और पहले customer से पहले AWS bill में VC का पैसा जलाना चाहते हैं, तो आपकी मर्जी
    • मेरे मामले में DigitalOcean CDN, CI, high availability, Git deploy जैसी सुविधा features $5 per month में देता है, इसलिए वहीं से शुरू किया
      अपना physical server चलाना बाद की problem है, अभी की नहीं। जब AWS bill के $1 million और एक बड़े single server के बीच चुनना पड़ेगा, तब मैं blog post देखकर decision नहीं करूंगा, बल्कि खुद tests चला रहा होऊंगा

  • AWS इस्तेमाल करने का मतलब scapegoat भी साथ खरीदना है। बड़ी cloud service outage को boss या investors को explain करना आसान है, लेकिन team के किसी human error से उतना ही cumulative downtime हुआ, यह explain करना कहीं मुश्किल है

    • human error, cloud trend से पहले और बाद दोनों में, outages की नंबर 1 वजह है
      तो यह cloud को scapegoat कहने वाली interpretation से कैसे जुड़ता है, यह जानना चाहूंगा

  • अगर vertical scaling का लक्ष्य है, तो SQLite क्यों? उसी server पर app के साथ self-hosted Postgres या Supabase चलाने से कोई नहीं रोकता, और setup में ज़्यादा मेहनत के अलावा कोई खास नुकसान याद नहीं आता
    DB के बिना जाकर अगर पूरी global state को एक बड़े server की actual memory में रखा जाए, Redis round-trip के बिना process के अंदर के objects के रूप में maintain किया जाए, कभी-कभी memory को disk पर snapshot किया जाए, और compiled multithreaded language इस्तेमाल की जाए, तो 1Gbit से ज़्यादा NIC को saturate करते हुए एक box से पूरी दुनिया को service किया जा सकता है
    कभी-कभी लगता है कि काश ऐसे architecture का कोई वास्तविक use case होता

    • SQLite क्यों नहीं हो सकता? ज़ाहिर है जवाब हमेशा “यह context पर निर्भर करता है” होता है, लेकिन इन दिनों SQLite असली database नहीं है वाला माहौल लगातार challenge हो रहा है
      standard relational persistence patterns के बाहर feature अंतर बड़ा है, इसलिए Postgres बेहतर हो सकता है, लेकिन कुछ architecture patterns में SQLite आगे भी हो सकता है
      BusinessInsider जैसी content-centric applications में SQLite-आधारित Baked Data pattern cost और latency के लिहाज़ से बेहतर हो सकता है
      simonw(datasette) ने content-centric या data-rich websites में production environment में SQLite इस्तेमाल करने के लिए बहुत से tools और articles बनाए हैं: https://simonwillison.net/2021/Jul/28/baked-data/
    • देखे गए benchmarks के हिसाब से वजह यह है कि SQLite कहीं ज़्यादा तेज़ है, खासकर round-trip time में
      SQLite process के अंदर चलता है और serialization की ज़रूरत नहीं होती, इसलिए यह बात समझ आती है। साथ ही operations को serially process कर पाने का अतिरिक्त फायदा भी है, जिससे testing, reasoning और cache layer बनाना कहीं आसान हो जाता है
      Unix socket न इस्तेमाल करें तो network overhead भी होगा, लेकिन आपने same server कहा है, इसलिए इसे अतिरिक्त point के रूप में छोड़ता हूँ। असल में isolation के लिए Postgres को अलग machine पर रखना बहुत आम है, और यह network DB के मुख्य फायदों में से एक भी है
    • अगर single machine पर चलाना है, तो SQLite Postgres/MySQL से बेहतर है
      ज़रूरी features सब हैं और simplicity व speed भी बेहतर है। SQLite terabyte-scale data, multiple reads, real-time streaming backup संभाल सकता है और overall काफी balanced SQL implementation है
      single box vertical scaling से आगे निकलने पर ही शायद Postgres/MySQL पर विचार करूँगा
    • लेखक का मतलब शायद यह हो सकता है कि edge पर SQLite इस्तेमाल किया जा सकता है
      https://blog.cloudflare.com/introducing-d1

  • लगता है बहुत से लोग, लेखक के latency, bandwidth और cost पर focus करने पर, availability और reliability के नाम पर status quo का बचाव करना ज़रूरी समझ रहे हैं
    मेरा निष्कर्ष यह नहीं है कि trade-offs के सामने cloud के फायदे नकार दिए जाएँ, बल्कि यह है कि अब हर जगह दिखने वाले cloud architecture patterns और उनसे आने वाली dependencies सच में अनिवार्य हैं या नहीं
    this-versus-that वाली तुलना alternatives पेश करने का rhetorical device है, और कौन-सा solution सही है यह use case के अनुसार अनेक factors पर निर्भर करता है। इन्हीं factors की वजह से engineers को jobs भी मिलती हैं
    फिर भी लेखक ने जिस pattern का सुझाव दिया है, उसके अंदर भी SRE concerns हल किए जा सकते हैं। “अगर एक server मर गया तो availability का क्या?” यह बात कुछ हद तक strawman attack जैसी है, क्योंकि availability को उन systems से अलग तरीके से हल किया जा सकता है जिनके हम आदी हैं, और solution को उन चीज़ों के अनुसार होना चाहिए जो सच में महत्वपूर्ण हैं

    • यह strawman क्यों है? on-premises हो या cloud, कोई भी समझदार व्यक्ति design review में स्वाभाविक रूप से यही पूछेगा

  • frugal budget में सिर्फ एक कदम जोड़कर कहीं ज़्यादा हासिल करने का तरीका है: API और SQLite DB को साथ रखना
    आदर्श रूप से API low-overhead binary serialization format और persistent connections इस्तेमाल करे, और web serving के लिए पैसे जलाने वाली VC-backed edge services के free tier का फायदा उठाया जाए। अभी Cloudflare Workers काफी generous है और egress traffic भी free है
    core point यह है कि SQLite single thread में भी प्रति second बहुत बड़ी संख्या में queries संभाल सकता है। कई operations को serially push किया जा सकता है, जिससे reasoning आसान होती है, और API-side memory caching व invalidation भी simple हो जाते हैं
    web serving को अलग रखने से handshake की edge performance का फायदा मिलता है और static pages में DB को पूरी तरह skip किया जा सकता है। लेख ने round-trip time की समस्या को कम आंका है, जबकि real apps को उम्मीद से ज़्यादा round-trips चाहिए होते हैं, इसलिए यह problem काफी वास्तविक है
    DB के बाहर CPU usage का बड़ा हिस्सा parsing, deserialization, data copying और TLS से आता है, इसलिए बड़े chunks हटाने पर commodity machine पर भी प्रति second tens of thousands writes आसानी से मिल सकते हैं, और reads उससे भी तेज़ होते हैं
    फिर भी typical bottlenecks, खासकर I/O, को benchmark करना हमेशा worthwhile है। providers अक्सर बढ़ा-चढ़ाकर बताते हैं या misleading होते हैं, इसलिए free tier पर खुद चला कर देखना चाहिए। migrate करने की नौबत आए तो integration tests और benchmarks भी तैयार रखना अच्छा है

    • इसी तरह के concept पर experiment कर रहा हूँ। PostgreSQL query results को JSON में output कर सकता है, इसलिए अगर API client को भेजे जाने वाले shape से इसे बिल्कुल match करा दे, तो पहले parse करने की ज़रूरत नहीं होती
      result बड़ा हो तो यह काफी अच्छा है, लेकिन उम्मीद है कि PostgreSQL खुद बड़े datasets को JSON में बनाने के दौरान bottleneck में न फँसे

  • लोग कहते हैं कि edge पर होना चाहिए, users के करीब होना चाहिए, और latency कम करनी चाहिए
    असल में latency कितनी बड़ी समस्या है?
    जर्मनी के server से चलने वाला book recommendation project Gnooks इसका उदाहरण है: https://www.gnooks.com
    उत्सुकता है कि क्या यह किसी को बहुत धीमा लगता है
    पिछले कुछ वर्षों में इस project पर users से हजारों suggestions मिले, लेकिन याद के मुताबिक किसी ने latency को मुद्दा नहीं बनाया। जबकि सबसे बड़ा user group अमेरिका में है

    • इस site में ज़्यादातर logic backend में है, और हर user interaction पर server तक सिर्फ एक round trip होता है
      इसलिए यह आजकल की उन PWA की तुलना में latency की समस्या बहुत कम झेलती है, जिनमें ज़्यादातर logic frontend में implement किया जाता है और फिर ज़रूरी data लाने के लिए backend को कई queries भेजी जाती हैं
    • ऑस्ट्रेलिया से देखने पर महसूस होता है कि यह कोई तेज़ local site नहीं है। यह धीमी local site या तेज़ overseas site जैसी लग सकती है, और ping लगभग 300ms है, जो अपेक्षित है
      फिर भी site अपने आप में ठीक है। अगर site पहले से ही धीमी हो, तब यह समस्या बनती है
    • ऑस्ट्रेलिया में VPN के ज़रिए internet इस्तेमाल करके देखा जा सकता है
      यूरोप में ऐसा करने पर ऑस्ट्रेलियाई user को दिखने वाली latency से लगभग 2 गुना मिलती है, जिससे worst-case experience का अंदाज़ा लगाने में मदद मिलती है
    • Hanoi में यह उम्मीद से बेहतर है। शुरुआती DNS+TLS से page load तक अभी भी 1 सेकंड से ज़्यादा लगता है, लेकिन उसके बाद की requests उम्मीद के मुताबिक बेहतर हैं और कम-से-कम 1 सेकंड से कम हैं
    • पुराने सवालों की तरह, यह भी situation पर निर्भर करता है
      अच्छी बात यह है कि इसे reliably test करके देखा जा सकता है कि यह वास्तव में महत्वपूर्ण है या नहीं। तब ठोस जवाब मिल जाता है

  • लेख availability पर बिल्कुल बात नहीं करता। single box पर चलने वाली service में planned downtime और unexpected downtime, दोनों होंगे
    RPO/RTO के बारे में भी सोचना चाहिए। जब box फटता है—या कहें फट जाए—तो recovery में कितना समय लगेगा और कितना data खोएगा, यह देखना होगा
    “अगर page rendering में एक भी database query है, तो us-east-1 के DB तक वापस जाना पड़ेगा” वाली बात के लिए ये options भी हैं:
    https://aws.amazon.com/rds/aurora/global-database/
    https://aws.amazon.com/dynamodb/global-tables/
    https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Conce...
    https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/...
    ऐसी और भी कई चीज़ें हैं, और वही सब खुद जोड़-तोड़ कर बनाने में काफ़ी मेहनत लगेगी

    • आजकल मुझे लगता है availability कुछ ज़्यादा ही overvalued है
      10–20 साल पहले होता तो मैं सहमत होता। internet नया था, और site down होने पर लोग site को दोष देते थे और हालात जल्दी बिगड़ जाते थे। लेकिन अब लोग पहले internet provider को दोष देने या बाद में फिर try करने की ज्यादा संभावना रखते हैं
      हर कोई Google नहीं है, और simpler systems के fail होने की संभावना भी शुरुआत से कम होती है। backups बनाए रखें और अगर सच में चिंता है तो DB को cold disaster recovery site पर replicate कर दें। FAANG न होने वाली अधिकतर companies और situations के लिए यह काफ़ी है
      अगर data न खोए, तो कई companies के लिए यह बस छोटी-सी झपकी जैसा रहता है। PR अच्छा हो और घटना बहुत दुर्लभ हो तो कुछ दिनों का downtime भी झेला जा सकता है, और कुछ cases में data loss भी सहा जा सकता है
      कहा जाता था कि reliability में हर एक 9 जोड़ने पर cost दोगुनी हो जाती है, और ROI निकालते समय इसे ज़रूर शामिल करना चाहिए। business को वास्तव में कितनी reliability चाहिए, यह target market पर निर्भर करता है, और IT का default जवाब यानी automatically 100% मेरे हिसाब से गलत है
    • सीधे physical server पर चलाने से linked products की तुलना में latency बहुत घट सकती है और I/O bandwidth बढ़ सकती है
      single-server या dual-server model में complexity भी बहुत कम होती है, और इसी वजह से LetsEncrypt जैसी operations team ने भी worldwide service को web-scale पर चलाने के लिए यह dual physical server architecture चुना: https://letsencrypt.org/2021/01/21/next-gen-database-servers...
      server के अंदर वाले DB या बिल्कुल पास वाले DB की बहुत कम internal latency के कारण software DB queries को कई orders of magnitude तेज़ चला सकता है, प्रति user कम resources इस्तेमाल करता है, और managed DB service की तुलना में भी ज्यादा responsive user experience दे सकता है
    • AWS या मिलती-जुलती जगहों पर चलने वाली services में भी downtime होता है
      complexity अपने traps बनाती है, और मुझे नहीं लगता कि कोई web service ऐसी है जिसने कभी इसे बिगाड़ा न हो। कभी-कभी AWS खुद भी incident कर देता है
    • AWS में भी बड़े availability issues होते हैं
      VPS को यहाँ ज़्यादा खराब नहीं कहा जा सकता