Налаштування GeoDNS для маршрутизації трафіку за регіонами

Чому при одній адресі для всіх регіонів потрібен GeoDNS

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

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

Деградація вимірювана: довше встановлюється з'єднання, повільніше надходять перші відповіді, зростає частка повторних спроб у мобільних клієнтів. На довгих маршрутах вищі втрати на проміжних вузлах, і доступність сервісу починає залежати від ділянок мережі, якими ви не керуєте.

Другий ефект — крихкість. Одна адреса означає, що падіння майданчика або каналу в окремому регіоні обвалює сервіс цілком, поки запис у кеші резолверів не сплине.

Перемикання в цей момент робиться руками, а короткий TTL — не безкоштовне рішення: він збільшує кількість запитів до авторитетних серверів домену.

GeoDNS закриває це на рівні розв'язання імені. Клієнт отримує адресу найближчого до нього майданчика, тому маршрутизація трафіку за регіонами відбувається до першого запиту, а не після.

Кожній зоні зіставляється свій пул адрес, а відмову майданчика обробляють зміною ваг і виведенням його з відповіді — не чекаючи, поки кеш сплине в усіх.

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

Що дає GeoDNS: час відповіді, стійкість і розвантаження каналів

GeoDNS віддає клієнту адресу того регіону, з якого надійшов запит, а не єдину адресу центрального майданчика. Запит обслуговує найближчий регіон: сторінка та виклики програмного інтерфейсу йдуть коротким маршрутом, а не перетинають півконтиненту.

На практиці час відповіді скорочується в рази, і виграш видно на кожному запиті, а не лише на першому завантаженні.

Другий ефект — стійкість. Відповіді роздаються лише для живих майданчиків: якщо регіон перестає відповідати на перевірки, його адреси виводяться з видачі, і трафік іде в резервний контур.

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

Третій ефект — розвантаження каналів. Без регіональної маршрутизації всі користувачі тягнуть дані з центру, і магістраль працює на транзит між містами замість корисного навантаження.

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

Що міряємо до і після: частку запитів, що потрапили в локальний контур, розподіл часу відповіді за регіонами, обсяг транзиту між майданчиками та час перемикання під час планового виведення регіону з видачі. Останнє перевіряється навчаннями — вимикаємо майданчик і дивимося, чи помітив це клієнт.

Варіанти маршрутизації трафіку за регіонами та їх обмеження

Вибір схеми впирається у два питання: наскільки точно потрібно розділяти трафік за регіонами і чим ми готові платити за цю точність.

Географічна прив'язка на рівні записів розводить клієнтів за пулами без проміжної ланки, але помилка в базі адрес веде запит не туди, а проміжні кешувальні вузли тримають стару відповідь довше, ніж живе сама зміна.

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

Обмеження схеми важливіші за її переваги: майже завжди вибір зводиться до того, який клас відмов для вас дешевший — неправильний регіон, простій центральної ланки або розсинхрон правил між шарами. Далі розбираємо, як ми перевіряємо ці сценарії до перемикання живого трафіку.

Як ми впроваджуємо геомаршрутизацію: етапи робіт

Геомаршрутизація починається не з правки зони, а з розуміння того, звідки реально приходять користувачі та як на це відповідають резолвери в кожному регіоні. Нижче — послідовність, за якою ми ведемо впровадження: від аудиту інфраструктури до передачі робочої схеми вашій команді.

1. Аудит інфраструктури та інвентаризація регіонів. Збираємо поточні зони, записи, делегування, список провайдерів і точок присутності. Уточнюємо, які регіони потрібно розділяти і за якою ознакою — країна, оператор, континент.
2. Вимірювання на реальних резолверах. З різних точок знімаємо, які сервери імен віддають відповідь і наскільки стабільно визначається джерело запиту. Це показує, де геоприв'язка працює надійно, а де потрібна додаткова ознака.
3. Проєктування схеми маршрутизації. Фіксуємо матрицю «регіон → набір адрес», пріоритети, значення TTL і поведінку в разі недоступності вузла. Схему погоджуємо до правок у робочій зоні, щоб зміни були передбачувані.
4. Налаштування та перевірки доступності вузлів. Розгортаємо прив'язки й контролі доступності: у разі відмови вузла трафік іде на резервний, а не залишається на адресі, що не відповідає. Задаємо цільовий час збіжності й стежимо за ним.
5. Перевірка перемикання. Проводимо контрольовані відмови: вимикаємо вузол, підміняємо ознаку регіону, дивимося фактичні відповіді та поведінку кешів у різних провайдерів.
6. Передача в експлуатацію. Віддаємо конфігурації, схему, регламент змін і порядок відкату. Ваша команда бачить, що і де змінюється під час додавання регіону, і далі править схему сама.

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

Що залишається у вас: конфігурації, схеми та регламенти

Розробка не закінчується перемиканням трафіку — замовник отримує набір артефактів, за якими система живе й змінюється без нас. Нижче перелік того, що передається команді замовника: файли, схеми та порядок роботи з ними. Усе зберігається у вашому репозиторії, а не в чиїйсь особистій папці.

• Конфігурації зон і правил: прив'язка регіонів до пулів адрес, час життя записів у кеші резолверів, окремі набори для основного й резервного контурів. Будь-яка зміна проходить рев'ю до застосування.
• Карта регіонів і контурів: який регіон на який контур ведемо, де живе резервний майданчик, як трафік розподіляється за часткової недоступності. Схема відображає факт, а не початковий задум.
• Правила перемикання: умови зняття вузла з обслуговування, пороги деградації, затримка перед зміною відповіді, поведінка в разі відмови одного з каналів зв'язку. Формулюються так, щоб їх можна було перевірити на стенді, а не лише прочитати.
• Схема маршрутизації запиту: шлях від звернення користувача до цільового сервера, точки, де ухвалюється рішення про регіон, і місця, де відповідь кешується.
• Регламент змін: хто погоджує правку карти регіонів, у якому порядку вона викочується, як виконується відкат на попередню версію і за який час. Плюс розподіл прав на тестовий і робочий контури.
• Документація: опис зон і їхніх власників, контакти чергових, типові сценарії — додати регіон, вивести майданчик на обслуговування, розібрати розбіжність у відповідях.
• Спостережуваність: набір метрик за резолверами та частка відповідей, що пішли на резервний контур, із налаштованими сповіщеннями.

Такий комплект дає змогу змінювати маршрутизацію своїми силами, не запускаючи проєкт заново, і розуміти, що саме сталося, коли трафік повівся не за планом.

Кейс: від спільної точки входу до регіональних контурів

Спочатку всі регіони дивилися на один спільний запис: єдиний вузол приймав і локальний, і транзитний трафік.

Коли майданчик ставав недоступним, черговий вручну правив зону і чекав, поки в резолверів сплине час життя запису — на це йшло від півгодини до сорока хвилин, і весь цей час користувачі бачили помилку.

Розбір почали з вимірювань: зняли час відповіді за регіонами, порахували частку запитів, що йшли через дальній вузол, і зафіксували час ручного перемикання як базову метрику. Гіпотеза підтвердилася — помітну частину затримки давав не код, а маршрут до єдиної точки входу.

Далі розвели регіональні контури: авторитетні зони винесли в Cloudflare, для кожного регіону описали свій набір адрес, увімкнули перевірки доступності та автоматичне відведення трафіку в разі падіння майданчика.

Час життя запису для службових імен знизили, щоб перемикання вкладалося в хвилини, а не в десятки хвилин.

Метрики після: перемикання — близько хвилини і без участі чергового, час відповіді у віддалених регіонах нижче на 38%, частка транзитного трафіку через чужий контур упала з 46% до 7%.

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

Окремо закріпили регламент: як підключається новий регіон, за якими порогами перевірки визнають майданчик неробочим, як відкочується конфігурація зони. Це і є перехід від однієї точки входу до набору незалежних регіональних контурів.

Що робити, якщо маршрутизація вже налаштована у провайдера

Ситуація, коли частина гео-правил уже лежить у зовнішнього постачальника, трапляється частіше, ніж «чистий» переїзд: у провайдера залишаються домени верхнього рівня, частина піддоменів, окремі регіональні гілки.

Починаємо з інвентаризації правил: вивантажуємо всі записи, зіставляємо їх із реальним трафіком із логів і фіксуємо, які регіони справді обслуговують гео-логіку, а які залишилися «на пам'ять» з минулих експериментів.

Без цього кроку будь-яке перемикання перетворюється на перекладання чужої конфігурації разом із її помилками.

Далі визначаємо межі й робимо часткове делегування: зони, де маршрутизація критична для продукту, забираємо під свій контроль, а периферійні піддомени спокійно залишаємо у постачальника — йому делегується гілка цілком, і ми в неї не втручаємося.

Так зона відповідальності стає явною: у нас — правила розподілу за регіонами, перевірки доступності та журнали відповідей, у провайдера — те, що ми свідомо не чіпаємо.

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

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

Окремо фіксуємо, що залишається у постачальника після переходу: аварійний контур на випадок відмови нашої інфраструктури або захист периметра. Це не компроміс, а усвідомлений резерв — у разі збою трафік можна повернути до попередньої схеми. Далі розбираємо, як така гібридна схема обслуговується без ручних правок.

Технічні сумніви перед стартом

Інженерні команди перед стартом ставлять приблизно один і той самий набір питань: як швидко схема почне перемикати трафік, чи не зачіпаємо ми активних клієнтів, чим перевіряємо коректність і хто супроводжує її далі. Нижче — прямі відповіді на п'ять найчастіших, без загальних слів.

Що побачать активні клієнти в момент зміни маршруту?

Уже відкриті сесії не розриваються — вони живуть на боці сервісів, а не в маршрутизації. Нові запити йдуть у цільовий регіон, тому користувач у найгіршому разі отримає відповідь від попереднього майданчика ще один цикл.

Чи можна перевірити схему до виходу на робочий трафік?

Так, піднімаємо тестовий контур: окрема зона, той самий набір правил і опитування з кількох точок. Проганяємо сценарії відмови регіону, недоступності перевірки працездатності та корекції геоданих — і лише потім переносимо конфігурацію.

Як переконатися, що маршрути видаються правильно?

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

Хто супроводжує схему після запуску?

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

Обговоримо ваше завдання: що надіслати для оцінки

Точність оцінки робіт із GeoDNS визначається вхідними даними: склад робіт для однієї зони з двома регіонами й для десяти точок присутності з автоматичним виведенням вузлів із видачі відрізняється в рази.

Щоб повернутися з планом упровадження та строками, а не з вилкою «від і до», нам достатньо описати завдання й надіслати такі дані.

• Список доменів і піддоменів, яким потрібна регіональна маршрутизація, із зазначенням, де зараз делеговані зони та хто керує записами.
• Карта регіонів: які країни або групи країн обслуговуються, чи є вимоги щодо локальної присутності та зберігання даних на території.
• Інфраструктура за регіонами: точки присутності, адресні пули, який сервіс приймає трафік і як він розподіляється зараз.
• Критерій вибору регіону: затримка відповіді, доступність вузлів або вартість вихідного трафіку — що вважаємо пріоритетом у разі конфлікту.
• Вимоги до відмовостійкості: допустимий час перемикання в разі відмови вузла, чи потрібне автоматичне виведення регіону з видачі.
• Обмеження: корпоративні політики, зовнішній прискорювач доставки контенту, наявні записи, які не можна ламати під час міграції.

За цими вхідними даними ми описуємо склад робіт: аудит поточної зони, схему розбиття на регіони та пули, правила перемикання, порядок викочування з перевіркою на тестовому домені.

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