Zones और Regions में availability चुनें

उपयोगकर्ता के काम से शुरू करें

High availability (HA) का लक्ष्य component failures के बावजूद service को उपयोग योग्य रखना है। Architecture चुनने से पहले उपयोग योग्य होने का अर्थ तय करें। Booking page load हो, लेकिन सभी booking requests fail हों, तो booking service उपलब्ध नहीं है।

महत्वपूर्ण operation के लिए service level objective (SLO) तय करें। कौन-सी requests गिनी जाएँगी, सफलता का क्या अर्थ है और मापन की अवधि क्या है, यह बताएँ। Cloud service का SLA उस provider की प्रतिबद्धता बताता है। वह आपके application की मापी गई availability सिद्ध नहीं करता।

उदाहरण के लिए, 30 दिन के महीने में 99.9% समय-आधारित availability, 43.2 मिनट की unavailability स्वीकार करती है। Request-आधारित SLO का आधार अलग है। इनमें से कोई माप यह नहीं बताता कि कितना डेटा खो सकता है या किसी अकेले outage की अधिकतम अवधि की गारंटी देता है।

Failure boundaries समझें

AWS Availability Zone (AZ), Region के अंदर अलग infrastructure location है। Region में कई AZs होते हैं। Multi-region design workload components को Regions में बाँटता है। दूसरे providers की अपनी सीमाएँ और service behavior होते हैं; चुनी service जाँचें।

ये design की संभावनाएँ हैं, availability की guarantees नहीं। Label से यह सिद्ध नहीं होता कि हर जरूरी component इच्छित सीमा इस्तेमाल करता है।

पूरा request path trace करें

काल्पनिक booking service लें। Web replicas दो AZs में चलते हैं। दोनों AZ A में एक database और एक outbound gateway इस्तेमाल करते हैं। Payment provider को call करने के लिए gateway जरूरी है।

AZ A fail हो, तो AZ B का web replica healthy रह सकता है, जबकि booking फिर भी fail हो। Team को database, network path, identity provider, payment dependency और routing का आकलन करना है। Managed database का वास्तविक mode देखें: replication, failover और readers का व्यवहार product व configuration के अनुसार बदलता है।

Capacity भी जाँचें। बचे resources को जरूरी load सँभालना चाहिए। Incident के दौरान capacity बनाने पर निर्भर design quotas, उपलब्ध resources और control-plane operations पर निर्भर है।

तय सीमा, stop conditions और जिम्मेदार व्यक्ति के साथ नियंत्रित अभ्यास करें। Payment records के मिलान समेत पूरी booking जाँचें। Failed requests और उपयोगी संचालन बहाल होने का समय दर्ज करें।

तय करें कि दूसरा Region समस्या हल करता है या नहीं

Multi-region संचालन में data transfer, duplicate resources, deployment का समन्वय और संचालन का काम बढ़ता है। Active/passive में एक environment traffic लेने के लिए तैयार रहता है। Active/active में एक से अधिक environments traffic सँभालते हैं। जरूरी तैयारी और डेटा का व्यवहार अलग होते हैं।

Booking service में concurrent writes एक प्रश्न लाती हैं: क्या दो Regions एक ही seat बेच सकते हैं? Booking का अधिकार और replication रुकने पर व्यवहार तय करें। “Database replicate करें” पूरा उत्तर नहीं है।

स्वीकार्य data locations, encryption keys, certificates, DNS, secrets और external services जाँचें। साझा identity outage या खराब release कई Regions को प्रभावित कर सकता है। अधिक जगहें हर साझा कारण नहीं हटातीं।

Availability को recovery से जोड़ें

HA संचालन के दौरान तय विफलताएँ सँभालता है। Disaster recovery बाधा डालने वाली घटना के बाद उपयोगी service और उसका डेटा बहाल करती है। Multi-region service को भी deletion या corrupted data के लिए recovery plan चाहिए।

चुने failure scenarios और business द्वारा स्वीकार किए गए scenarios दर्ज करें। Application बदलने पर tests और infrastructure definitions को मेल खाता रखें। आगे RTO, RPO और disaster recovery पढ़ें।