Виберіть доступність між зонами та регіонами

Почніть з операції користувача

Висока доступність (HA) має зберігати придатність сервісу до використання попри відмови компонентів. Визначте цю придатність до вибору архітектури. Сторінка бронювання, яка завантажується, коли всі запити на бронювання завершуються невдало, не є доступним сервісом бронювання.

Установіть цільовий рівень сервісу (SLO) для важливої операції. Визначте, які запити враховуються, що означає успіх і за який період його вимірюють. SLA хмарного сервісу описує зобов’язання його постачальника. Воно не встановлює виміряну доступність вашого застосунку.

Для прикладу: доступність 99,9% за часом допускає 43,2 хвилини недоступності за 30-денний місяць. SLO на основі запитів має інший знаменник. Жоден із показників не визначає, скільки даних можна втратити, і не гарантує максимальної тривалості окремого збою.

Зрозумійте межі відмов

AWS Availability Zone (AZ) — це ізольоване розташування інфраструктури в межах Region. Region містить кілька AZ. Багаторегіональна архітектура розподіляє компоненти навантаження між Region. Інші постачальники мають власні межі й поведінку сервісів; дослідіть вибраний сервіс.

Це архітектурні можливості, а не гарантії доступності. Назва не доводить, що кожен потрібний компонент використовує заплановану межу.

Простежте повний шлях запиту

Розгляньмо вигаданий сервіс бронювання. Вебрепліки працюють у двох AZ. Обидві використовують одну базу даних і один вихідний шлюз в AZ A. Шлюз потрібен для виклику платіжного постачальника.

Якщо AZ A відмовить, вебрепліка в AZ B може залишатися справною, але бронювання все одно не працюватиме. Команда має оцінити базу даних, мережевий шлях, постачальника ідентичностей, платіжну залежність і маршрутизацію. Дослідіть фактичний режим керованої бази даних: реплікація, перемикання після відмови та поведінка читання залежать від продукту й конфігурації.

Також перевірте потужність. Ресурси, що залишилися, мають витримувати потрібне навантаження. Архітектура, що покладається на створення потужності під час інциденту, залежить від квот, доступних ресурсів і операцій площини керування.

Проведіть контрольовану вправу з визначеними межами, умовами зупинки та відповідальним. Перевірте повне бронювання, включно зі звірянням платежів. Запишіть невдалі запити й час відновлення корисної роботи.

Визначте, чи інший Region розв’язує проблему

Багаторегіональна експлуатація додає передачу даних, дубльовані ресурси, узгодження розгортань і операційну роботу. Active/passive тримає одне середовище готовим приймати трафік. Active/active обслуговує трафік у кількох середовищах. Потрібна готовність і поведінка даних відрізняються.

Для сервісу бронювання одночасні записи створюють питання: чи можуть два Region продати те саме місце? Визначте, хто має остаточні повноваження підтвердити бронювання та якою буде поведінка під час перерваної реплікації. «Реплікувати базу даних» — неповна відповідь.

Перевірте дозволені розташування даних, ключі шифрування, сертифікати, DNS, секрети та зовнішні сервіси. Збій спільного сервісу ідентичностей або невдалий випуск може вплинути на кілька Region. Більше розташувань не усуває всіх спільних причин.

Поєднайте доступність із відновленням

HA обробляє визначені відмови під час експлуатації. Аварійне відновлення повертає придатний до використання сервіс і його дані після руйнівної події. Багаторегіональний сервіс усе ще потребує плану відновлення після видалення або пошкодження даних.

Документуйте вибрані сценарії відмов і ті, ризик яких бізнес приймає. Узгоджуйте тести та визначення інфраструктури зі змінами застосунку. Продовжіть із RTO, RPO та аварійного відновлення.