Prozorro Case

Історія успіху Prozorro.Sale:

Міграція на AWS

Замовник

Prozorro.Sale – це цифрова аукціонна система, яка допомагає отримувати дохід державі через відкриті та чесні торги.

Prozorro.Sale створено завдяки співпраці Міністерства економічного розвитку і торгівлі України, Transparency International Україна, Державного фонду гарантування вкладів фізичних осіб, Національного банку України та українських електронних майданчиків. Система Prozorro.Sale є обов’язковою на законодавчому рівні для реалізації державного, комунального майна в Україні. Цільовими групами є органи державної влади, місцевого самоврядування, Фонд державного майна України, а також підприємства та громадяни, які беруть участь в онлайн-аукціонах.

Потреби бізнесу

Для Prozorro.Sale необхідно було забезпечити безперебійний доступ до ресурсу.
Тобто, щоб при виникненні будь-якої з проблем, як то:

  • фізична втрата центру обробки даних,
  • втрата з’єднання з Інтернетом,
  • втрата доступу адміністратора та подальші наслідки,
  • логічні помилки програми або пошкодження даних через зовнішні впливи не повинні перешкоджати використанню послуги користувачами 24/7.

Складність проекту

Розпочато проект резервної інфраструктури (Disaster Recovery) на основі хмари AWS.

Проект складався з 4 етапів:

  1. Підготовка архітектури сайту та міграція несинхронізованих сервісів у хмару AWS.
  2. Копіювання інфраструктурних послуг.
  3. Синхронізація даних і тестування в реальному часі.
  4. Фінальні доопрацювання, загальне тестування системи, складання документації.

Війна в Україні застала проект на етапі №3 – Синхронізація та тестування даних у реальному часі.

У ситуації, що склалася, Disaster Recovery взяла на себе роль основної, продакшн-платформи.
Концентрація зусиль проекту була перенаправлена ​​на проектування нової інфраструктури для продуктового середовища та модифікації платформи IaC, щоб забезпечити надійність і доступність, а також вибірку даних і міграцію.

Етапи проектування нової інфраструктури:

  • Визначення типів ресурсів для оптимізації вартості, доступності та надійності.
  • Визначення параметрів ідентичності для  Kubernetes StatefulSet із PVC для підтримки кількох зон доступності на основі класу зберігання gp2.
  • Міграція VPN-ів інших сторін за допомогою інструментів експорту/імпорту AWS.

 

Етапи модифікації IaC платформи:

  • Модифікація коду Terraform.
  • Модифікація GitLab CI/CD для IaC.

 

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

  • ELK, журнали Opendistro розміром понад 10 ТБ.
  • Дані MongoDB.
  • Дані зі сховища Swift до S3.

Рішення

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

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

Ми також обмежили використання всіх фірмових сервісів, крім EKS: це був баланс незалежності та оптимальних витрат на підтримку.

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

Було прийнято свідоме рішення «втратити» логи разом з основним ресурсом: синхронізація була надто трудомісткою порівняно з запланованим результатом (насправді логи відтворювалися не на один робочий день, оскільки резервне копіювання було щоденним).

Оскільки мета полягала в тому, щоб перемикати ARI-клієнти максимально плавно (шляхом переписування записів DNS), необхідно було синхронізувати ключі між сайтами. Ключі складалися з ключів ARI, а також профілів VPN. З ключами ARI рішення було аналогічним за кодом – розширенням SI. З доступом до VPN рішення не було.

Результат

Команда Triangu повністю підготувала інфраструктуру для переходу на хмарний сервіс AWS. У процесі міграції IaC було переформовано та сформовано нову платформу для продуктового середовища.

Prozorro.Sale успішно мігрував і стабільно працює на хмарних сервісах AWS вже понад 3 місяці.

Залиште свої дані і ми з вами зв'яжемось

* Triangu потрібна контактна інформація, яку ви надаєте нам, щоб зв’язатися з вами щодо наших продуктів і послуг. Ви можете будь-коли скасувати підписку на ці повідомлення.