Multi-Region Architecture Vocabulary: Active-Active, Data Residency, and Geo-Routing (англійською)
Освоєння англійської мови для багаторегіональної хмарної архітектури — активна-активна, активна-пасивна, гео-маршрутизація, резиденція даних, глобальні балансувальники навантаження і стратегії відключення.
Архітектура багаторівневої мережі: складність і словник
Розгортання послуг у багатьох географічних регіонах є одним з найбільш архітектурно складних викликів в хмарній інфраструктурі. Вона включає в себе компроміси між послідовністю і доступністю, вартістю і затримкою, простотою і стійкістю. Словниковий запас щільний, і точність важлива — плутанина «активно-активний» з «активно-пасивний», наприклад, призводить до невідповідних очікувань між архітекторами, інженерами і бізнес-зацікавленими сторонами.
Цей посібник містить основні слова, що використовуються у перегляді проекту англійською мовою, документації про хмарного провайдера і інтерв’ ю щодо проектування системи.
Топологія розгортання
Активно-активно
У ** активна-активна ** архітектура, декілька регіонів одночасно обслуговують живий трафік. Кожен регіон може обробляти будь- який запит користувача. Ця топологія забезпечує найвищу доступність і найнижчу затримку, оскільки запити маршрутизуються до найближчого здорового регіону.
«Ми працюємо з активною-активною конфігурацією в трьох регіонах — Лондоні, Франкфурті і Дубліні. Кожен регіон незалежно обслуговує свою локальну базу користувачів, і запити автоматично маршрутизуються до альтернативного регіону, якщо один стає нездоровим. ”
** Конфлікт запису ** — це проблема, унікальна для активних- активних: якщо дві області можуть приймати записи до одних і тих самих даних, вам слід розробити стратегію для обробки конфліктних оновлень. Саме тому активний- активний режим значно складніше реалізувати, ніж активний- пасивний. « Записи активний- активний з декількома регіонами вимагають стратегії розв’ язання конфліктів — ми використовуємо last- write- wins з векторними годинниками для даних про настройки користувача »
Активно-пасивний
У активно-пасивних архітектурах, один регіон (основний) обслуговує весь живий трафік. Одна або декілька ** резервних ** областей отримують репліковані дані, але не обслуговують запити користувачів до події відключення.
“Наш рівень бази даних працює активно-пасивно між Лондоном (основний) і Франкфуртом (резервний). У випадку невдачі лондонського регіону, ми підвищуємо репліку Франкфурта до первинної і оновлюємо записи DNS. ”
** Гаряча черга ** — пасивна область, яка частково забезпечена і може швидко приймати трафік після відключення, але не обслуговує поточні запити. « Франкфуртська гаряча черга може приймати трафік протягом п’ яти хвилин після події відключення. »
** Холодний режим очікування ** — пасивна область, де ресурси буде забезпечено з нуля під час відновлення, що триває довше. « Холодний режим очікування використовується лише для відновлення після аварії — RTO становить чотири години. »
** RTO (Recovery Time Objective) ** — максимально допустимий час перерви під час відновлення. « Наш RTO для платіжної служби становить 15 хвилин. »
** RPO (Recovery Point Objective) ** — максимально допустима втрата даних за часом під час відновлення. « Наш RPO становить дві хвилини, це означає, що затримка реплікації не повинна перевищувати дві хвилини у стабільному стані. »
Транспортні маршрути
Глобальний балансувальник навантаження
** Глобальний балансувальник навантаження ** (GLB) розподіляє вхідні запити між регіонами на основі таких правил, як географічна близькість, перевірки стану та затримка. Хмарні провайдери пропонують управляні GLB: Google Cloud’s Global External Application Load Balancer, AWS CloudFront з походженням і Azure Front Door.
«Глобальний балансувальник навантаження маршрутизує кожного користувача до найближчого здорового регіону на основі геолокації DNS і зондів затримки»
Географічні маршрути
** Гео- маршрутизація ** направляє трафік до певного регіону на основі географічного походження запиту — зазвичай, визначається за IP- адресою клієнта. Це ключовий механізм як для оптимізації затримки, так і для відповідності резиденції даних.
«Наша політика гео-маршрутизації відсилає всі запити, що походять з IP-адрес ЄС до нашого Франкфуртського кластера, забезпечуючи відповідність вимогам щодо резиденції даних»
** Маршрутизація за затримкою** — маршрутизація трафіку до регіону, який може найшвидше відповісти на запит, незалежно від географічного розташування. « Маршрутизація за затримкою іноді надсилає європейських користувачів до нашого східного регіону США у не найшвидші години, коли трансатлантична затримка нижча за внутрішньоєвропейську затримку. »
** Вважене маршрутизування ** — розподіл трафіку між регіонами у визначених пропорціях, використовується для поступового регіонального розгортання або балансування навантаження. « Ми використовуємо вагане маршрутизування для відсилання 10% трафіку до нового регіону під час фази перевірки. »
Релігія і держава
** Резиденція даних ** стосується вимоги, щоб дані зберігалися і оброблялися в межах певної географічної межі — зазвичай, країни або юрисдикції. Це законне і регулятивне вимога для багатьох категорій даних.
«Наші клієнти-підприємства в Німеччині вимагають резиденції даних в ЄС. Всі їхні дані зберігаються у Франкфуртському регіоні і ніколи не залишають кордонів ЄС»
** Суверенітет даних ** є ширшою концепцією: принцип, що дані підлягають законам і управлінню країни, в якій вони зберігаються. Резиденція даних є технічною реалізацією вимог суверенітету даних.
«Ми реалізували контроль суверенітету даних, забезпечуючи, що ключі шифрування для даних клієнтів ЄС управляються виключно в рамках нашого сервісу управління ключами ЄС і ніколи не експортуються до регіонів США»
** Ізоляція на рівні клієнта ** — можливість обмежити дані конкретного клієнта до певного регіону, навіть у межах архітектури з декількома клієнтами. “Наша платформа підтримує ізоляцію регіону на рівні клієнта, що дозволяє корпоративним клієнтам вказати, в якому регіоні хмари знаходяться їхні дані.”
Failover
** Відновлення після аварії ** — це процес перемикання трафіку з пошкодженої або погіршеної первинної області на резервну область. Відновлення може бути:
** Автоматичний відновлювальний режим ** — запускається за допомогою спостереження без втручання людини, на основі помилок перевірки стану. « Автоматичний відновлювальний режим налаштовано з порогом трьох послідовних невдалих перевірок стану перед перенаправленням трафіку. »
** Ручне відключення з причини відмови ** — вимагає, щоб оператор ініціював комутатор, що надає більше можливостей керування, але повільніше відповідає. « Для рівня бази даних ми вимагаємо ручного рішення щодо відключення з причини відмови, щоб уникнути хибно позитивних автоматичних відключень під час перехідних подій мережі. »
** Відновлення після аварії ** — повернення трафіку до початкової первинної області після його відновлення. « Відновлення після аварії вимагає 30 хвилин безперебійної роботи у первинній області перед поступовим поверненням трафіку назад. »
Транспортні розв’язки
Багаторегіональні архітектури вводять складність затримки, яка не існує в однорегіональних розгортаннях.
** Затримка реплікації між регіонами ** — затримка між записом, який було виконано у головному регіоні, і записом, який буде доступним у регіоні реплікації. « Затримка реплікації у середньому становить 180 мс між Лондоном і Сіднеєм — це відповідає нашому RPO, але означає, що читання з Сіднея може трохи відставати від читання з Лондона. »
** Послідовність читання- запису- вами ** — гарантія того, що після запису даних користувачем, він негайно побачить свій запис, навіть у розподіленій системі. Важко підтримувати у багаторегіональних налаштуваннях. « Ми досягаємо послідовності читання- запису шляхом маршрутизації читання користувача до того ж регіону, що і його запису, протягом налаштованого часу після кожного запису. »
** Послідовність можливих результатів ** — модель послідовності, за якої, якщо дати достатньо часу без нових записів, всі репліки збігатимуться до одного і того ж значення. Широко використовується у системах з декількома регіонами з причини швидкодії. « Налаштування профілю користувача використовують послідовність — невелике затримання між регіонами є прийнятним для цього типу даних. »
П’ять прикладів висловлювань
- «Ми обрали активно-пасивну над активно-активною для бази даних транзакцій, тому що складність конфлікту запису активно-активної не була виправдана нашими вимогами доступності»
- «Geo-routing забезпечує, що всі дані від наших французьких клієнтів обробляються і зберігаються виключно в нашому регіоні Парижа, задовольняючи наші договірні зобов’язання щодо резиденції даних»
- «Політика автоматичного відключення була викликана, коли перевірки стану первинного регіону не вдалися протягом трьох хвилин поспіль, і Франкфурт був підвищений до первинного з загальним RTO сім хвилин»
- «Затримка реплікації між Лондоном і Сіднеєм в середньому становить 200 мс — це в межах нашого RPO в дві хвилини, але наш прикладний шар повинен обробляти можливість застарілих читання в регіоні Австралії»
- «Ми реалізуємо резиденцію даних на рівні орендаря, присвоюючи кожному клієнту підприємства домашній регіон при вступі; всі їхні дані записуються, зберігаються і обробляються тільки в цьому призначеному регіоні»
Summary
Архітектура з декількома регіонами — це область, де неточність мови може призвести до реальних технічних помилок. « У нас є резервний регіон » не має сенсу, якщо не вказати, чи є він у режимі очікування або у режимі очікування без обмеження, якими є RTO і RPO, чи є відключення автоматичним або вручну, і яку стратегію реплікації даних ви використовуєте. Точний словник змушує до точного мислення — і точне мислення виробляє системи, які поводяться так, як очікується, коли вони найбільше потрібні.