Дуже класне питання! Якщо ви ставите обмеження без downtime, то це практично нереально зробити. Доведеться точно вкручувати щось, щоб ігнорувати зміну стейту яку показує TF, щоб уникнути рестарту сервера БД для «застосування» змін. Також немаловажливу ролі грає якість стейту. З паролями доведеться помудохатися теж вручну.
Як написав Олексій, то розгортання нового кластера БД і міграція на нього є універсальним рішенням, який заміняє ваш import на нормальний стейт із максимальним контролем та мінімізацією ризику покласти/видалити prod базу. Саме таким шляхом ми і рухалися.
Для чого обирати гірше з кращих?
Дякую за питання! Історія із дев і прод оточеннями довгий час у нас виглядала так, що якесь із них завжди було зроблене краще. В нашому випадку дев пройшов декілька ітерацій IaC, а прод ще жив на 50% IaC, 50% ClickOps. Наразі ми живемо в кубері, тому оточення є максимально близькі по архітектурі, проте dev/qa використовують shared database, більше spot instance, простіші політики масштабування, мінімальну кількість екземплярів застосунку, шарять між собою певні сервіси.
Сам по собі Aurora engine є окремим продуктом, який розроблюється в AWS. Продавати його як Aurora standalone вони не можуть. Тому запакували через RDS, для уніфікації UX, бо це майже не відрізняється від звичайного postgresql/mysql окрім деяких особливостей і лага версій.
Я абсолютно згоден, що це різні сервіси в плані реалізації архітектури. З точки зору 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.
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
Відповім із кінця. Кластер в ECS може складатися із 0 або більше EC2 інстансів, якщо ми обрали такий спосіб capacity provider’а. Так-що в цьому випадку 10 — логічна сегрегація нашого процесингу.
Платіжна транзакція != HTTP запит. Навантаження на процесинг складається не лише із зовнішніх запитів, а і від трафіку який ми продукуємо назовні.
Почав писати про процес того, як відбувається платіж, але зрозумів, що це вже тема для окремої статті.
Дякую за згадку цього інструменту! Точно пам’ятаю що якийсь інструмент розглядали, але точної причини чому не пішли цим шляхом не згадаю.
Дякую за детальний коментар! Продавати виділені сервери мені не потрібно, бо я був ініціатором міграції на них :). Як зазначено в коментарі, то із отриманим досвідом ми б це зробили набагато якісніше. В моїх фантазіях ми маємо 3 EBS, один для основного навантаження із provisioned IOPS, інший щось попростіше для переміщення старих партицій і окремо для даних WAL. Свобода на EC2 дає зможу ставити будь-які extensions та працювати на останній версії Postgres, як тільки вона вийде, а не чекати місяцями на RDS, або рік на Aurora. RDS вже пару років, як завезли storage autoscaling, а в Aurora це by design.
Стосовно цінової політики — це так. Вона легко підкупляє на старті, проте без експлуатації важко спрогнозувати вартість певних послуг.
Дякую за коментар! Очевидним є те, що старт в клауді має доступ до більшої кількості можливостей, як на залізі, тому я б рекомендував усім хто запускає стартапи починати з клауда, а не сервера в Хетцнері чи деінде. Конкретно в AWS є програми які дозволяють отримати суттєву суму на покриття витрат для стартапів. При зростанні вартості інфраструктури потрібно постійно дивитися на абсолютний та відносний показник витрат в P&L. При певних розмірах вашої конкретної інфраструктури може виникнути непереборне бажання з’їхати на залізні серваки, бо «буде дешевше». Це дійсно так, коли ми дивимося на вартість інфри в 3,627$ на OVH і аналогічну вартість в клауді — 6-8k$. В такому випадку я б рекомендував прорахувати TCO (en.wikipedia.org/...i/Total_cost_of_ownership), врахувати потреби бізнесу не лише фінансові, а по стабільності, доступності, плану найму і т.д.
Якщо під питанням малося на увазі розгортання нашого софту в Україні, то це неможливо для нас наразі з декількох причин: фізичні ризики, наявність України в складі ЄС (важливо для клієнтів), робота із фізичними серверами (застосунок все-ще не на 100% готовий до життя без AWS).
Дякую! Потрібно було ще трішки дочитати до
2021: переїзд на AWS Aurora
Здійснив декілька успішних продажів в телеграмі після оголошення на olx. Основне — зберігати інформаційну гігієну.
Ціль статті — вчергове підсвітити проблему яка є. Якщо вона допоможе хоча б 1 людині побачити маркери які можуть привести її до страти коштів, то я вже буду радий. Також є люди старшого віку для яких треба проводити курси інтернет гігієни і ця проблема стоїть особливо гостро. Мені гидко згадувати це відчуття, коли із того боку екрану люди думають, що ти лох і зараз вони тебе розведуть на певну суму. Притому, що я розумів, що мені нічого не загрожує.
Хостинг був російським справді, але ініціатор конкретно цього випадку з славного міста під Києвом — Фастів. Маючи трохи більше наполегливості можна було б ім’я реальне знайти. Маю групу його класу вк, старі оголошення на певних майданчиках і акаунт телеграму. Стосовно imgur.com — цікавий момент, дякую.
Це було б прекрасно і можна було б взяти когось за яйки. На жаль, в такій схемі інфи немає, бо дані карти йдуть на їхній сервер, і там вже «оператор» ручками проходить 3DS допоки користувачу малюється фейкова сторінка із 3DS. Тобто мерчантських даних ніде не видно.
Гарне питання, дякую! За цей час встигли використати майже все: raw postgres logical replication, AWS DMS, debezium. Про деталі планую розкрити в окремій статті, бо намудохалися ми знатно. Так, як ваше місце роботи вказано AWS, то зауважу, що коли ми використали DMS, то
просраливитратили 3к USD на трафік та IOPS, бо сервіс впав пару разів без зрозумілої помилки в процесі вичитки даних з source database. Тоді зробили на debezium і все пройшло гарно.