Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 5
×

Назад в хмари: як Prozorro.Sale неочікувано повернувся в AWS

Вітаю, мене звати Гріша, я СТО «Прозорро.Продажі». Півтора року тому вийшла стаття, в якій описано докорінне оновлення нашої системи онлайн-аукціонів. А от вже декілька тижнів як нами разом із Raccoon Gang та Triangu виконане перенесення усіх оточень нашої торгової системи в AWS.

В цій статті поділюсь деталями того, як планувався та виконувався цей переїзд. Досвід, сподіваюсь, стане цікавим та корисним спільноті DOU.

Який був план

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

Однак перелік ризиків, які планувалось зменшити, виявився валідним і для воєнного стану:

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

Ресурси на цей проєкт були суттєво обмежені (скажіть, що в когось бувало інакше!), зате не було якогось жорсткого дедлайну, тож домовились з командою розділити все на сім етапів з проміжними результатами не рідше, ніж раз у квартал.

Етапність вийшла приблизно такою:

  1. Підготовка цільової архітектури.
  2. Підготовка IaC для первинної інфраструктури (сервери, мережі, сховища тощо).
  3. Написання скриптів автоматичного розгортання сторонніх сервісів (k8s, ELK, HAProxy, mongo, різне).
  4. Налаштування синхронного деплойменту бізнес-застосунків.
  5. Побудова реплікації баз даних та файлів з об’єктного сховища.
  6. Налаштування моніторингу і логування.
  7. Запуск та бейбісіттінг.

Архітектура та перші рішення

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

Але зрештою від цього відмовились на користь AWS: команда мала непоганий досвід роботи з Amazon, плюс на їхню користь був вже існуючий контракт та можливість використання ресурсів для пілотного проєкту (деталі можна знайти на їх сайті або запитати у свого реселлера). Користь фізичного розташування дата-центру за межами України ми повністю оцінили лише в березні.

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

Як цільовий показник було обрано одну годину. Це значення значною мірою вплинуло на інші рішення, які ми приймали надалі. Зокрема:

  • резервний майданчик мав лишатись увімкненим весь час. Підняти інфраструктуру та розгорнути сервіси за одну годину від початку виглядало нереалістичним, навіть якщо для цього потрібно було б запустити один-єдиний скріпт;
  • бази даних так само мали бути «теплими». Розмір наших баз не надто великий (декілька сотень гігабайт), але просте розгортання бекапу взяло б більше часу, ніж ми мали на відновлення. Виникали певні сумніви щодо ситуації, коли наші дані виявились би логічно пошкодженими (тоді навпаки актуальність бази зіграла би проти нас), але рішення, що робити з таким сценарієм, ми вирішили відкласти «на потім»;
  • також «теплими» мали бути файли в об’єктному сховищі: там вже йдеться про терабайти, і ні про яку «одну годину» мови не може бути (забігаючи наперед, йшлося врешті про майже 10 діб міграції);
  • перемикання мало відбуватись прозоро для АРі-клієнта, оскільки тільки авторизованих клієнтів було понад сорок, а з користувачами відкритих даних могла вийти і сотня. Організовано навіть просто змінити адреси — ми в це не вірили.

Ці та інші міркування привели нас до наступних рішень:

  • вирішили тримати єдиний екземпляр GitLab в резервному дата-центрі. Інструментом розгортання зробили GitLab CI, розширивши вже існуючі пайплайни так, щоб при оновленні продуктивної версії коду на основному майданчику синхронно оновлювався і резервний. Фактичний розрив версій очікувався в декілька хвилин, що для нашого бізнес-процесу не мало б жодних наслідків;
  • в проєкті вирішили обмежити використання відверто пропрієтарних сервісів, зробивши виключення тільки для EKS: так було означено баланс незалежності та оптимальності витрат на підтримку;
  • вирішили також змінити логіку роботи сервісу, який опікувався файлами. Нова версія при отриманні файлу на вхід мала його кешувати і паралельно записувати в 2 сховища: основне та резервне. Тобто з точки зору клієнта АРІ файл вважався б отриманим відразу після кешування, але всередині логічна транзакція закривалась би тільки після отримання підтвердження від обох сховищ;
  • а ось що робити з базами ми не вигадали:) Можете написати в коментарях свій правильний варіант!
  • додатково було прийняте вольове рішення втрачати разом з основним майданчиком і його логи: синхронізація opendistro виглядала надто трудомісткою у порівнянні з очікуваним результатом (насправді ми б втрачали тільки логи за останній робочий день, оскільки щоночі ми вже робили їх бекапи).
  • Оскільки ми мали на меті зробити перемикання клієнтів АРІ максимально безшовним (шляхом переписування ДНС-записів), то з’явилась потреба в синхронізації ключів між майданчиками. Ключі складаються з безпосередньо ключів АРІ, а також VPN-профілів. З ключами АРІ рішення було аналогічне до коду — розширення СІ. Що робити з доступом до VPN ми також на той момент не вирішили.

«Все йшло за планом»

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

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

Рішення вийшло сумнівним, але своєї мети ми мали досягати ось такими діями:

  • Одноразова ручна заливка staging-оточення з документуванням всього шляху і нюансів. На додачу до цього домовились «притримати» найближчі релізи на продуктив. Так ми отримували одне робоче оточення, на яке, в разі чого, можна було розгорнути живі дані
  • Підвищення пріоритету для задачі з керування файлами: без цього ми втрачали б файли зі сховища.

Перший пункт було виконано за 17.02. Другий виконати ми не встигли.

Коли почалось

Останні дні лютого роботу над проєктом було перервано: частина команди знаходилась в Харкові, Ірпені та Чернігові, тому будь-які дії відклали допоки всі, хто мав виїхати, не дістались безпечніших місць.

Єдине, що ми зробили відразу, — дозволили користувачам АРІ працювати без VPN, оскільки у частини хостинг-провайдерів почали виникати незрозумілі досі проблеми з підключенням, а аукціони продовжували йти, попри воєнний стан (за цим простим «дозволили» стоять визначні дії одного з інженерів: лишившись єдиним, хто мав і доступ, і інтернет, він міняв налаштування, знаходячись прямо на позиціях ТРО. Друже, ти справжній герой!)

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

З такою трансформацією на початку були певні питання: як державне підприємство, ми мали зберігати наші дані на території України. Але поки ми займались технікою, Кабінет Міністрів дозволив (і навіть рекомендував!) перенести цифрові активи в хмари за кордон. Сподіваюсь, це рішення діятиме і після завершення війни.

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

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

За наступні три тижні команда налаштувала сервіси, яких не вистачало, а також переробила СІ так, щоб нові версії потрапляли вже на нові оточення. Окрім цього провели повне тестування.

Як і очікувалось, функціональних проблем не знайшлось, але був інфраструктурний нюанс. В аукціонах є фіча, яка повідомляє користувача про розрив інтернет-з’єднання. Виявилось, що європейський AWS знаходиться достатньо далеко, щоб клієнт періодично вбачав розриви. Ми вигадали простий обхідний маневр (виводити повідомлення тільки після 2-3 спроб перепідключення), але на практиці навіть це не знадобилось, оскільки зрештою на продуктиві помилка не відтворювалась.

Також вчасно помітили обмеження, на яке спочатку не звернули уваги. AWS не дозволяє мігрувати диски між різними Availability Zones, а лишати всі ресурси в одній зоні ми собі вирішили не дозволяти. Зрештою рішення було знайдено в тонкому налаштуванні affinity та anti-affinity політик.

Сам собою переїзд вийшов доволі рутинним: оскільки в нас є чіткий час, коли система має приймати ставки, ми змогли собі дозволити вимкнути write-доступ до АРІ вночі перед вихідними, зробити консистентні бекапи, спокійно їх розгорнути й запустити копію системи, паралельно лишивши стару систему увімкненою. Після переключення було успішно пройдено smoke-тестування, і ми констатували, що переїзд відбувся успішно.

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

Зрештою стало зрозуміло, що частина клієнтів два місяці тому вирішила не скористатись можливістю працювати без VPN. Ми ж зі свого боку були впевнені, що жодного такого клієнта немає. Ситуацію дозволило швидко виправити те, що ще під час виконання плану з побудови резервного дата-центру були написані скрипти для інсталяції VPN-сервера, тож нам достатньо було їх запустити та оновити секрети. Звідси винесли відразу два уроки: по-перше, треба перевіряти навіть те, чого не може бути, а по-друге — ніколи не знаєш, що в житті знадобиться!

Післямова

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

Ну і, звісно, продати ту саму марку з автографом автора того самого вислову. Вже з AWS.

👍ПодобаєтьсяСподобалось5
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Нетривале дослідження показало, що частина клієнтів потрапляє на старий сайт

Надо ставить прокси/редирект и проверять логи — тк есть rfc ingorant ISP.

Підписатись на коментарі