Як ми на проєкті розгортали інфраструктуру платіжного процесингу в AWS

Усі статті, обговорення, новини про DevOps — в одному місці. Підписуйтеся на DOU | DevOps!

Добрий день! Мене звати Дмитро Дзюбенко, я співзасновник та CTO компанії Corefy — white label SaaS платформи, яка дозволяє запустити власну платіжну систему в кілька кліків. Зараз на базі нашої платформи функціонують платіжні провайдери та компанії, які успішно закривають внутрішні потреби з прийому платежів. Основна цінність платформи для клієнтів — усунення складнощів інтеграції платіжних провайдерів. Ми інтегруємо платіжних провайдерів та еквайрів з усього світу, тому клієнтам достатньо однієї інтеграції з нашою платформою, щоб мати можливість підключити будь-який платіжний метод.

У цій статті я розкажу про наш досвід розгортання інфраструктури платіжного процесингу в Amazon Web Services (AWS). Cтаття написана за мотивами моєї доповіді 2021 року на вебінарі AWS Cloud for Financial Services, тож я розповім про наш досвід, виходячи з того часу.

2018: перехід на AWS за місяць

У 2018 році наш продукт складався з:

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

Шлюзу виплат. Його основна функціональність (розщеплення суми, робота з P2P-платежами) значних змін з того часу не зазнала.

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

Цих можливостей було достатньо для деяких наших клієнтів, тож на цих «трьох стовпах» ми запустилися у 2018 році.

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

Чому швидко? Так склалося, що перший клієнт з’явився неочікувано. Ми довго працювали над платформою, а потім нам пощастило — нарешті з’явився клієнт, якого потрібно було якнайшвидше запустити в production. За місяць ми повинні були перейти на Amazon Web Services з наших самопальних кластерів, які були розгорнуті на OVH VPS за допомогою Kontena. На той момент досвіду роботи з AWS у нас було зовсім трохи, але завдяки розширенню команди нам вдалося завершити проєкт вчасно.

Ода сервісам AWS

Інфраструктура була зроблена методом наклікування (ClickOps) у консолі управління Amazon, без жодної автоматизації. Оскільки у нас на той момент був лише один клієнт, трафіку було небагато. З появою нових клієнтів навантаження потроху збільшувалося, проте не різко.

Ключовими сервісами, які ми використовували, були ElastiCache, RDS та ECS.

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

RDS — це мій улюблений сервіс, який дає можливість працювати із різними СУБД (MySQL, PostgreSQL, Oracle) і не перейматися стосовно фізичних проблем. Його можна розгортати як на Provisioned storage, так і в звичайному режимі. Він відкидає потреби в організації кастомних бекапів, бо для більшості потреб буде достатньо снапшотів, які не впливають на швидкодію вашого серверу БД. Ще одна із можливостей — розгортання вашої бази даних зі снапшота, який був зроблений у певний момент часу (point in time recovery).

ECS — це оркестратор docker-контейнерів від AWS, що був базовим для нас довгий час — в ньому крутяться практично всі наші ресурси. На той момент EKS тільки з’явився на AWS і мав обмежений інструментарій, який підтримує його, тому ми не могли навіть почати роботу із ним. Сам AWS доволі багато зусиль вкладає в розвиток ECS. Щоправда, більшість направлені на інтеграцію з внутрішніми сервісами — FireLens (логи), App Mesh, Blue-green deployment (CodeDeploy), Container Insights (CloudWatch), SecretManagement (SSM), Serverless (Fargate). Є і комічні моменти. Наприклад, лише нещодавно у них з’явилася можливість видаляти task definition. Зауважу, що платити за control plane ноди, як у випадку із EKS, тут не потрібно.

У результаті роботи в 2018 році ми отримали наступну архітектуру: у нас було 2 зони доступності, кілька дрібних сервісів, база даних (primary/secondary), а також Redis. Але через ClickOps, брак часу та досвіду ми запустились на одному NAT у двох зонах доступності.

Основними проблемами, з якими ми зіткнулися за цей час, були кредити EBS та інстансів T2. EBS має ліміт на кількість вводів-виводів в секунду в залежності від об’єму диска, і при запуску інстанса цей ліміт дуже маленький. Якщо ви почнете інтенсивно використовувати диск з новим EBS, швидше за все, ви скоро досягнете ліміту і всі операції стануть дуже повільними. Ми використовуємо в роботі фреймворк Symfony, який прогріває кеш свого ядра перед стартом. Ось він нам тоді і поставив задачку із зірочкою — ми навіть на tmpfs пробували переходити.

2019: проходження сертифікації PCI DSS

На початок 2019 року карткового процесингу у нас ще не було, але ми його спроєктували і були готові починати розробку. Постав вибір: залишитися в Amazon, де у нас було трохи більше півроку досвіду, або повернутися в OVH. Оскільки ніхто з команди не мав практичного досвіду проходження сертифікації Payment Card Industry Data Security Standard (PCI DSS), питання вибору провайдера інфраструктури для нас було дуже важливим. Ми провели великий SWOT-аналіз, щоб відповісти на нього.

У провайдера OVH є пакети для полегшення проходження PCI DSS. Вони надають кластер на виділених серверах та забирають на себе частину відповідальності при проходженні сертифікації. Але, як ми і припускали, менеджити це не так-то і просто, адже для цього теж потрібен досвід. Оскільки увесь світ іде в «хмарки», переходити на виділений сервер для нас було б не дуже правильно, тож ми вирішили залишатися в AWS. Ми зважували, як пройти сертифікацію, як масштабуватися. Також хотілося обрати популярну технологію, а не якийсь андеграунд типу OpenStack. Тим паче, нам потрібна була можливість знайти спеціалістів для підтримки.

AWS не був би AWS, якби не мав рецепта розгортання інфраструктури, сумісної з PCI DSS. Для цього вони зробили прекрасний CloudFormation. Він активно підтримується і туди з часом додаються нові модулі, певні покращення. Силами однієї людини за тиждень ми підняли staging оточення. Це також дало нам можливість розгорнути production за один день.

Для проходження сертифікації PCI DSS ми вирішили робити все в окремому обліковому записі. У результаті всіх цих дій ми отримали вже дві інфраструктури. Я вважаю, що на той час це було правильним рішенням, хоча в майбутньому воно принесло нам купу додаткової роботи та болю. Там була невелика кількість ресурсів, вони були всі описані в коді, всі вимоги PCI DSS були дотримані, і до цієї інфраструктури мали доступ лише два оператори. Ця інфраструктура працювала в трьох зонах доступності, зі своїми ключами KMS. Комунікації із preprocessing були реалізовані по HTTP API та SQS, щоб не ускладнювати нашу інфраструктуру внутрішніми пірингами. Це дало нам можливість заявити, що процесинг карткових транзакцій — це окрема система з власним API, і єдиним клієнтом цього API є наш продукт Corefy.

Протягом 2019 року ми отримали багато нового досвіду. У першу чергу, це проходження сертифікації PCI DSS. Також ми навчилися працювати з EBS та зрозуміли, що capacity planning проводити обов’язково, адже щойно ми запустили карткову інфраструктуру, наші партнери почали направляти трафік, а об’єми цього трафіку інколи були неочікуваними. Сьогодні ми обробляємо 3000 операцій на день, завтра 30000, післязавтра — 300000. Іноді про такі зміни ми дізнавалися через алерти або візуальний моніторинг трафіку.

Як робити не треба

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

Цікава історія склалася із базою даних. На той час вона жила на сімействі інстансів T з дефолтними дисками. Коли ви бачите, що кредити EBS вже підходять до мітки нижче 100, і не очікуєте на зменшення трафіку, апгрейдити екземпляр типу T — погане рішення. Щойно ви це зробите, у вас не буде запасу кредитів на EBS, вони починаються з нуля, і база даних банально «вижере» burst rate при старті і не зможе стабільно працювати. Простіше кажучи, захлинеться від навантаження. Це був перший серйозний інцидент при роботі з базою даних, який навчив нас закладати достатньо запасу потужності. До нас прийшло розуміння того, що у нашому випадку екземпляри сімейства T підходять тільки для інфраструктури PoC.

2020: міграція з RDS на виділені сервери

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

Ми навчилися працювати з суттєвими змінами трафіку (x3-x5), зберігати і обробляти десятки гігабайтів даних в день. Під час експлуатації на таких навантаженнях проявилися нові типи проблем. Наприклад, не було реконектів до Redis в деяких процесах, або відбувалося неправильне перепідключення у роботі з базою даних. Інколи це створювало паразитний трафік і ми «забивали» connection pool Postgres.

Вартість інфраструктури, кількість дрібних інцидентів та відсутність розуміння capacity RDS інстансів відносно роботи нашого процесинга призвели до того, що ми прийняли рішення про міграцію з RDS на виділені сервери. Протягом декількох місяців ми опановували нові інструменти та планували переїзд. Вибір пав на Patroni, де ми побудували майже класичну схему: у нас був Haproxy, через NLB трафік йшов на інстанси з PostgreSQL, де стояв Patroni. etcd було 5 інстансів у трьох зонах доступності, тож при падінні одного з них у нас точно залишався кворум. Це рішення, запущене на трьох серверах, дало нам змогу обробляти більше даних за менші гроші. Чим не щастя для бізнесу? Для початку ми взяли i3en екземпляри, а потім проапгрейдили їх до i3en.2xlarge.

Проблеми, з якими ми зіткнулися

1. Спочатку розсипався кластер etcd, а через це розсипався кластер Patroni. Кворум не допоміг. Переключення мастера відбувалося самостійно, а ми довго не могли зрозуміти в чому справа. Як виявилося, проблема була в синхронізації часу. Пізніше ми вирішили її за допомогою chrony.

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

3. NLB скидав підключення на порт 5432, якщо ми оновлюємо target на 5433. В нашій архітектурі на одному балансері було розділення по портах на writer та reader. Про цю проблему ми повідомили службу підтримки. Нам запропонували надіслати все повністю для того, щоб це можна було відтворити. У нас не було бажання витрачати на це час і зусилля, тому ми просто «забили». Майте на увазі, що досвід комунікації з службою підтримки може бути не найкращим.

4. Wraparound. Це проблема, з якою я не бажаю зіштовхнутися нікому. 2 листопада 2020 року о 08:58 наш сервер почав відхиляти всі спроби щось у нього записати. Це був початок найбільшого інциденту з базою даних за весь час. Ми мали фізичні копії в бекапах, і потрібно було розгортатися з бекапа в аварійному режимі, але не виходило через проблему на фізичному рівні із лічильниками XID. Ми вирішили транкейтити топові таблиці, робити дамп мінімальної кількості даних, і тоді з нього розгортати процесинг, а потім додавати дані уже в процесі роботи.

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

У підсумку року ми мали більше 10 кластерів ECS і 100 черг. Ще у нас було 4 кластера PostgreSQL, preprocessing, картковий процесинг і портал мерчанта (окремий застосунок зі своїм кластером бази даних, який ми надаємо клієнтам-платіжним системам для перепродажу своїх каналів). Також було чотири публічні балансувальники навантаження на всього один продукт. Завершили злиття двох акаунтів AWS в один. Через систему проходило більше 10 мільйонів транзакцій на місяць, тож у нас було по 2,5 ТБ в двох БД.

Ми вже розуміли профіль навантаження та могли планувати його на довгі періоди. Ми взяли Savings Plans на EC2 Instance i3n для наших баз даних на рік і зекономили близько 35% на них. Тюнінг скейлінга кластерів та насиченість їх spot-ами теж дозволили суттєво зекономити та закупити Savings Plans для критичних кластерів на C5.

2021: переїзд на AWS Aurora

Кількість інцидентів, чергувань і нестабільності в роботі сервісу призвели до того, що ми перевезли картковий процесинг на AWS Aurora. Вирішили спробувати з меншого проєкту, а при успішній експлуатації мігрувати інші. Поступовість була необхідна для оцінки вартості експлуатації, бо прогнозувати кількість read та write IOPS було важко.

Ми почали активно оцифровувати в Terraform усю розгорнуту інфраструктуру. Звісно, це не зовсім приємний процес, коли треба проводити багато import та працювати з production, який не весь описаний в коді.

Ретроспектива

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

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

Пріоретизуйте та переглядайте цілі на період. Наприклад, якщо є бажання економити — це одне, а якщо падіння обходиться дуже дорого — це зовсім інше. Наша міграція з AWS RDS на Aurora пройшла через наш виділений самокерований інстанс. За 2020 рік ми отримали купу негативу і поганий досвід користувачів саме через базу даних. Звісно, як команда ми виросли у плані

архітектури й інфраструктури. Але якщо порівнювати збитки та репутаційні втрати з сумою, яку ми могли витратити на Aurora, то обрати Aurora було б раціональніше. Є така ментальна пастка: коли рахуєш вартість сервісу, іноді здається, що простіше самим все побудувати. Але потрібно також враховувати вартість обслуговування системи, роботи людей, засобів моніторингу, бекапів і всього іншого, що Amazon дає «з коробки».

Робіть cost planning, щоб уникнути неприємних сюрпризів. Планування зростання тісно пов’язане з плануванням витрат. Тобто, ви можете брати Savings Plans, які дозволять вам рости органічніше та дешевше. Не нехтуйте цією можливістю.

Проєктуйте свої застосунки одразу таким чином, щоб вони працювали на spot clusters. Інстанс може «вмерти» в будь-який момент, і ваш застосунок повинен вміти справлятися з цим.

Не допускайте розростання ресурсів в одному акаунті. Ми не розпланували розвиток наших облікових записів, тож певний час в одному акаунті у нас жили development, production та ще якісь ресурси компанії, які не стосуються процесингу. Саме тому, коли прийшов час розгортати PCI DSS-інфраструктуру, ми робили це в окремому акаунті, бо просто не могли зробити це в основному, наповненому купою сторонніх ресурсів. Зараз ми прийшли до того, що розділяти акаунти дійсно необхідно. Ми переносимо їх в інший root-акаунт, щоб зробити SSO і розділити ворклоади за типами (development, production), виділити окремі акаунти для ресурсів, логів і усього того, що не стосується процесингу.

Маленька подяка AWS

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

З позитивних аспектів хотів би відзначити роботу акаунт менеджерів та архітекторів, які з’являються автоматично при чеку $5k+. Багато роботи було проведено із ними для оптимізації використання сервісів AWS, щоб зменшити загальний чек.

Існує безліч програм, націлених на те, щоб підсадити вас на «голку» і збільшити ваш чек в AWS. Проте для освоєння певних сервісів вони пропонують credits, дозволяючи вам зекономити. Наприклад, якщо ви будете розвивати компанію чи продукт в напрямку Machine Learning, то це прекрасна можливість отримати декілька сотень, а то й тисяч доларів для ваших PoC.

Плани

Ми прийняли стратегічне рішення перейти на K8s, побудувати data warehouse та реорганізувати наші AWS акаунти. Про все це розповім детально в наступних статтях.

👍ПодобаєтьсяСподобалось33
До обраногоВ обраному13
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

Дмитро, дуже дякую за гарну статтю та що знайшли час поділитися своїм досвідом! Це дуже цінно.
З нетерпінням чекатиму на нові статті з продовженням про побудову data warehouse. Можливо зможете розглянути ще й medallion architecture на базі delta lake з використанням data quality та поділитися своїми враженнями та досвідом. Було б дуже цікаво.

Дякую за статтю. Яким додатком переносили схема даних та самі дані в RDS ?

Гарне питання, дякую! За цей час встигли використати майже все: raw postgres logical replication, AWS DMS, debezium. Про деталі планую розкрити в окремій статті, бо намудохалися ми знатно. Так, як ваше місце роботи вказано AWS, то зауважу, що коли ми використали DMS, то просрали витратили 3к USD на трафік та IOPS, бо сервіс впав пару разів без зрозумілої помилки в процесі вичитки даних з source database. Тоді зробили на debezium і все пройшло гарно.

Чому не Microsoft Azure?

Для чого обирати гірше з кращих?

-

Дякую за статтю! Дуже цікаво!

> Ми почали активно оцифровувати в Terraform усю розгорнуту інфраструктуру.

поділіться будь-ласка досвідом, як ви оцифровували в Terraform бд?
цікаво, як ви оцифровувати прод бд без down time?

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

Щоб покласти бд в проді, має бути натиснуто як мінімум кілька кнопок, наприклад пароль і написати shutdown :) рекомендую цей підхід

як варіант окремий тераформ на пильному лептопі який ніхто не бачив і не знає де він лежить

Якщо не мою бд і платять за те щоб оцифрувати, то не протестую, ну тоді все як по доках, сторедж, снепшоти й дампи з pitr, резервний інстанс, якщо не managed, то зверху pyinfra чи на крайняк ansible. Що регулярно — пихається в окремий прод дженкінс

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

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

Все це в одному ДЦ чи зоні де сервіси, якщо ж щось типу типу hybrid, там залежить може бути все те саме, а може бути разів в 10 складніше

Дуже класне питання! Якщо ви ставите обмеження без downtime, то це практично нереально зробити. Доведеться точно вкручувати щось, щоб ігнорувати зміну стейту яку показує TF, щоб уникнути рестарту сервера БД для «застосування» змін. Також немаловажливу ролі грає якість стейту. З паролями доведеться помудохатися теж вручну.

Як написав Олексій, то розгортання нового кластера БД і міграція на нього є універсальним рішенням, який заміняє ваш import на нормальний стейт із максимальним контролем та мінімізацією ризику покласти/видалити prod базу. Саме таким шляхом ми і рухалися.

Дякую за статтю

Мені стало цікаво, як у вас живуть не-продакшен енаваєрменти? Мабуть, стейджинг/пре-прод — це повна копія по інфраструктурі? Чи на чомусь економите?

А умовний DEV/QA енваєрменти як у вас виглядають?

Дякую за питання! Історія із дев і прод оточеннями довгий час у нас виглядала так, що якесь із них завжди було зроблене краще. В нашому випадку дев пройшов декілька ітерацій IaC, а прод ще жив на 50% IaC, 50% ClickOps. Наразі ми живемо в кубері, тому оточення є максимально близькі по архітектурі, проте dev/qa використовують shared database, більше spot instance, простіші політики масштабування, мінімальну кількість екземплярів застосунку, шарять між собою певні сервіси.

автор, дякую, дуже крута стаття

Людоньки рідні, ви подивіться що коїться. Друга технічна стаття за цей місяц. Чому модератори таке пропускпють?!
Це ж форум де обговорюють релокацію та зп і податки ))))

Вообще-то сейчас в тредне феминизм и равенство)

P.S. За статью лайк

А чи можна запитати, що мається на увазі під транзакцією (тобто що саме відбувається)? Тому що «10 мільйонів транзакцій на місяць» звучить солідно, але ж це 4 транзакції в секунду і для цього 10 кластерів ECS виглядає забагато

Відповім із кінця. Кластер в ECS може складатися із 0 або більше EC2 інстансів, якщо ми обрали такий спосіб capacity provider’а. Так-що в цьому випадку 10 — логічна сегрегація нашого процесингу.

Платіжна транзакція != HTTP запит. Навантаження на процесинг складається не лише із зовнішніх запитів, а і від трафіку який ми продукуємо назовні.

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

Так, стаття на цю тему була-б потрібна, чи хоч би верхньорівнева схема, мені це було б цікаво.
1. я розумію, що таке ECS (маю відповідну сертифікацію :) )
2. я доволі давно працюю в фінтех і наприклад найбільше навантаження може бути від використання ЕЦП (CPU та БД для визначення схем підпису) та роутингу (БД). Зовнішні запити це більш питання IO waiting, тобто їх можна паралелити.

Але я не знаю, що саме у вас відбувається, тому і цікаво

Все ж не можу зрозуміти, чому ви відмовилися від виділених серверів (ВС). Так, були проблеми, але вони б були скрізь. Якщо зараз переходили з Aurora на ВС, можливо, з попереднім досвідом, уникнули б проблем.
З власного досвіду — перешли в non-prod на виділені сервери EC2 після року користування AWS Aurora і RDS Postgres/Oracle. Здивувались, на скільки впала cost of ownership. Цікаво, що EC2 по performance налаштуванням можна підігнати краще ніж RDS Postgres або AWS Aurora (з одним інстас у кластером). За моїми порівняннями на приблизно однакових конфігурації (cpu class, core count, memory, storage class), класичний EC2 у середьому до 10% швидший. Можна змінювати EBS volume type (VT), підключати різні EBS, наприклад, якщо є розділення табличного простіру по типу default-archive, EBS під default можна робити швидшим (наприклад Gp3), під archive-звичайним. На працюючий БД на EC2 можно з 0 downtime змінювати VT, збільшувати volume size. Можна робити multi-volume snapshots — майже те саме що і RDS snapshots.

Взагалі, деякі аспекти цінової політики Amazon викликають здивування. Те що RDS автостартують через тиждень, це лише бажання заробити. А з AWS Aurora — це плата за IOPS, яку я не знаю як спрогнозувати.

Дякую за детальний коментар! Продавати виділені сервери мені не потрібно, бо я був ініціатором міграції на них :). Як зазначено в коментарі, то із отриманим досвідом ми б це зробили набагато якісніше. В моїх фантазіях ми маємо 3 EBS, один для основного навантаження із provisioned IOPS, інший щось попростіше для переміщення старих партицій і окремо для даних WAL. Свобода на EC2 дає зможу ставити будь-які extensions та працювати на останній версії Postgres, як тільки вона вийде, а не чекати місяцями на RDS, або рік на Aurora. RDS вже пару років, як завезли storage autoscaling, а в Aurora це by design.

Стосовно цінової політики — це так. Вона легко підкупляє на старті, проте без експлуатації важко спрогнозувати вартість певних послуг.

>

Ми почали активно оцифровувати в Terraform усю розгорнуту інфраструктуру. Звісно, це не зовсім приємний процес, коли треба проводити багато import та працювати з production, який не весь описаний в коді.

Рекомендую ознакомиться с Terraformer — github.com/...​CloudPlatform/terraformer
помогает сгенерировать Terraform scripts для вручную созданной инфраструктуры

Дякую за згадку цього інструменту! Точно пам’ятаю що якийсь інструмент розглядали, але точної причини чому не пішли цим шляхом не згадаю.

Крута стаття!

Наскільки ви оцінюєте майбутнє в AWS і клаудах? Очевидно що на старті вам сподобалось, що в принципі очікувано, але видно що вас турбує чек, і чим далі тим звісно стабільніше й передбачуваніше вам буде. Останніми місяцями проскакує про репатріації. Наскільки імовірним ви це бачите для себе, враховуючи PCI DSS звісно?

Дякую за коментар! Очевидним є те, що старт в клауді має доступ до більшої кількості можливостей, як на залізі, тому я б рекомендував усім хто запускає стартапи починати з клауда, а не сервера в Хетцнері чи деінде. Конкретно в AWS є програми які дозволяють отримати суттєву суму на покриття витрат для стартапів. При зростанні вартості інфраструктури потрібно постійно дивитися на абсолютний та відносний показник витрат в P&L. При певних розмірах вашої конкретної інфраструктури може виникнути непереборне бажання з’їхати на залізні серваки, бо «буде дешевше». Це дійсно так, коли ми дивимося на вартість інфри в 3,627$ на OVH і аналогічну вартість в клауді — 6-8k$. В такому випадку я б рекомендував прорахувати TCO (en.wikipedia.org/...​i/Total_cost_of_ownership), врахувати потреби бізнесу не лише фінансові, а по стабільності, доступності, плану найму і т.д.

Якщо під питанням малося на увазі розгортання нашого софту в Україні, то це неможливо для нас наразі з декількох причин: фізичні ризики, наявність України в складі ЄС (важливо для клієнтів), робота із фізичними серверами (застосунок все-ще не на 100% готовий до життя без AWS).

Я загалом цікавлюсь як від неbiased cto, що ще не відірвався від клавіатури і одночасно дивиться на чек.

Так я розумію про ЄС, і про комплайенс, я з тим варюся багато, включно з платежами

Хотілося просто почути ваше бачення

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

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

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

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

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

Мотивація AWS — підсадтити на свої сервіси зі стадії MVP, навіть кредитів дадуть безкоштовних. Бо якщо ваш стартап злетить, ви по інерції будете платити і чеки по мірі зростання сервісу теж ростуть. Тому тут все логічно.

Чому існуючи бізнеси переносять інфраструктуру в клауд — спитайте ПриватБанк наприклад. Бо клауд це надійність і безпека. За це і переплата.

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

Мотивацію клаудів я розумію, підсадити, голка, тут без питань

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

А мене цікавлять мотивації саме західних бізнес-акторів

Крута стаття, поки переглянув, але буду точно перечитувати, буду чекати наступні ваші статті.

Дуже детальна і структурована стаття.
Цікавий момент помітив:

RDS — це мій улюблений сервіс, який дає можливість працювати із різними СУБД (MySQL, PostgreSQL, Oracle) і не перейматися стосовно фізичних проблем.
2020: міграція з RDS на виділені сервери

))

Дякую! Потрібно було ще трішки дочитати до

2021: переїзд на AWS Aurora

Дочитав одразу, та Aurora не є частиною RDS 🤷

AWS не згоден — aws.amazon.com/rds/aurora. Плюс в самому інтерфейсі AWS ви не оперуєте Aurora поза контекстом RDS. Ну і ще є артефакти які кажуть, що “Aurora — це RDS” registry.terraform.io/...​les/rds-aurora/aws/latest та docs.aws.amazon.com/...​source-rds-dbcluster.html

AWS::RDS::DBCluster — це інтерфейс створення кластерів баз даних. Те що з його допомогою можна створити кластер Aurora чи RDS ще не означає, що Aurora є частиною RDS

imgur.com/a/Dlpz3K2
в меню Amazon RDS та Amazon Aurora знаходяться на одному рівні

в самому інтерфейсі AWS ви не оперуєте Aurora поза контекстом
RDS

це зроблено для того, щоб не збивати користувача, бо всі ці сервіси в решті створені для роботи з базами даних.

чому я вважаю, що це трохи різні сервіси, хоча і дуже схожі за функціоналом — бо в них зовсім різна архітектура. RDS — це по суті EC2 з інстальованим db engine, в той час як Aurora це cloud-first architecture з розділенням computation та сторедж.

Тому ні, Aurora це не RDS )

Я абсолютно згоден, що це різні сервіси в плані реалізації архітектури. З точки зору AWS — Aurora is a part of RDS.

Amazon Relational Database Service (Amazon RDS) is a collection of managed services that makes it simple to set up, operate, and scale databases in the cloud. Choose from seven popular engines — Amazon Aurora with MySQL compatibility, Amazon Aurora with PostgreSQL compatibility, MySQL, MariaDB, PostgreSQL, Oracle, and SQL Server — and deploy on-premises with Amazon RDS on AWS Outposts.

Сам по собі Aurora engine є окремим продуктом, який розроблюється в AWS. Продавати його як Aurora standalone вони не можуть. Тому запакували через RDS, для уніфікації UX, бо це майже не відрізняється від звичайного postgresql/mysql окрім деяких особливостей і лага версій.

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