Май 25

Архітектура на AWS. Яких помилок ми припустились

Я Руслан Кусов, Senior Solutions Architect у SoftServe і лідер AWS-кластеру. Недавно мій колега писав статтю про топ архітектурних помилок з власного досвіду, і я вирішив теж поділитися кейсами моєї команди. Адже робота над помилками допомагає сформулювати висновки та уникнути схожого в майбутньому. Сподіваюся, наш досвід допоможе ще комусь.

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

У цій статті поділюся з вами чотирма історіями з життя. Це «вивчені уроки», що зміцнили фундамент архітектурного досвіду моєї команди.

Ілюстрація Марії Рибак

Випадок № 1. Неузгоджений план гірше, ніж його відсутність

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

Стейкхолдери (спонсори міграції) на боці клієнта добре розуміли принципи AWS landing zone, вони погодилися з усіма нашими пропозиціями, зауваживши лише те, що у них теоретично може бути VPN з дата-центром і є SD-WAN, який бажано буде налаштувати у майбутньому, але зараз це непринципово, крім того, цим будемо займатися не ми, а їхня інженерна команда. Загалом умови були привабливими: свобода вибору, «правильні» стейкхолдери й обіцяна підтримка інженерів з боку клієнта.

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

Що пішло не за планом

Проблеми з’явилися вже на першому тижні роботи. Ми побудували landing zone і були готові переходити до фінального етапу, коли виявилося, що нам все-таки треба налаштувати SD-WAN і зробити так, щоб через неї можна було збирати дані з віддалених центрів. І що це взагалі головний критерій успіху проєкту. Це стало першим тривожним дзвіночком.

Далі — ще цікавіше. За схемою, запропонованою інженерами клієнта, ми мали б створити конфігурацію і надати їм конфігураційні файли, які вони завантажать на свої пристрої — і все запрацює. Та й ця SD-WAN команда виявилася не інженерами клієнта, а фахівцями двох різних зовнішніх вендорів. З одним з них було складно зв’язатися та отримати всю потрібну інформацію.

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

Зрештою, ми таки налаштували SD-WAN, створили концепт централізованого мережевого акаунту та VPC під кожного SD-WAN вендора й навіть отримали дані з віддалених дата-центрів. І тут клієнт повідомив про появу чергових нових стейкхолдерів.

З’ясувалося, що отримання даних — критерій лише операційної команди, а у неї є ще внутрішні клієнти, які на базі її продуктів розробляють свої рішення. І ці стейкхолдери не можуть користуватися AWS-інфраструктурою і всією організацію в нинішньому вигляді, бо, по-перше, структура акаунтів не відповідає їхній моделі, а по-друге, вони користуються Terraform, а не AWS CloudFormation, і хочуть передавати його операційній команді на підтримку. Це означало, що для нас проєкт значно ускладнюється, бо з’являється ще один інструмент, під який треба повністю підлаштувати продукт. Зрештою нам довелося створити дизайн AWS landing zone 2.0 — несумісний із попередньою версією — із численними кардинальними змінами та додатковими ризиками, пов’язаними з міграцією на цю версію 2.0.

Чого ми навчились

Ось які висновки я зробив із цього непростого досвіду:

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

Випадок № 2. Everybody lies

На перший погляд цей клієнт здавався справжнім експертом: стверджував, що добре обізнаний з технологіями, які ми впроваджували, що має сертифікованих AWS-cloud архітекторів та AWS-девелоперів і використовує best practices від Amazon Web Services, а також переконував, що у нього все на 100% правильно налаштовано. Все за AWS Well-Architected Framework.

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

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

На той момент ми для них виконували роботу, пов’язану лише з одним з їхніх застосунків, до AWS інфраструктури доступу в нас не було і все, що лишалось — повірити їм на слово.

Загалом є два шляхи вирішення такої проблеми:

Cost cut — урізання витрат шляхом відмови від певних сервісів, що впливає на характеристики якості системи (безпека, масштабування, відмовостійкість тощо).
Cost optimization — оптимізація наявних ресурсів, щоб зберегти всі бажані характеристики якості системи.

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

Ось перелік проблем, які ми виявили:

технічний борг, який виник при переході в AWS-хмару з дата-центру за принципом lift&shift без жодної адаптації інфраструктури;
відсутність хмарної моделі витрат;
відсутність контролю за витратами у хмарі та нормального планування;
відсутність контролю за ресурсами та сервісами, що використовуються;
не впроваджені best practices та базові конфігурації безпеки й обмежень — дослідивши звіти з використання reserved instances, ми з’ясували, що на початку вони обрали та придбали попереднє покоління EC2 віртуальних машин (C4), але в якийсь момент команда розробників вирішила, що краще підходить C5 покоління віртуальних машин (тобто вони двічі платили за одне й те саме);
погана внутрішня комунікація;
погана документація: банально не було задокументовано, які ресурси вони купили, а які використовують по факту.

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

Чого ми навчились

З цього кейсу я виніс три основні уроки:

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

Випадок № 3. Kubernetes як срібна куля

Серед деяких інженерів є тенденція будь-яку проблему вирішувати використанням найтрендовіших технологій, таких як Kubernetes. Цей кейс про те, що такий підхід спрацьовує не завжди.

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

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

Зазвичай понад два варіанти краще не давати, оскільки клієнту буде складно визначитися. Тому ми провели й аргументовано запропонували обрати між Kubernetes і Amazon ECS. Нам з самого початку кращим здавався другий варіант, оскільки він дозволив би за короткий час досягти конкретного результату (клієнт зміг би продавати свій продукт кінцевим користувачам). Kubernetes є повноцінною «екосистемою» з низкою додаткових особливостей та можливостей. Все це додає функціоналу, але цьому клієнту він був не потрібен. До того ж на той момент в AWS не був повноцінно доступним Kubernetes як managed service (Amazon EKS працював лише в кількох регіонах і з обмеженим функціоналом). Це ускладнювало процес менеджменту та підтримки цього рішення. Однак клієнт побоявся, що Amazon ECS сильно підв’яже їх під AWS-хмару (vendor lock), і зупинився на Kubernetes.

Що пішло не так

Коротко кажучи, ми просто послухали клієнта, а також зовнішніх експертів, які стверджували, що ECS не перспективна технологія, розвивати яку AWS не буде, і почали робити проєкт на Kubernetes.

Серед перших труднощів, з якими зіткнулися, були:

Рішення повинно було відповідати PCI DSS (Payment Card Industry Data Security Standard). Це обмежувало використання певних managed-сервісів. Так, наприклад, EKS тоді був доступний лише у двох регіонах і не мав цієї сертифікації. ECS, на відміну від нього, підходив.
Managed-сервіси піднімати не могли, але могли використовувати Vanilla Kubernetes. Операційна команда на боці клієнта виявилася не настільки кваліфікованою, щоб його повноцінно підтримувати.
До кластерів були особливі вимоги, оскільки треба було робити безпечну інтеграцію сервісів основної платформи, яка не обробляє платіжні дані, з сервісами, які їх обробляють. З ECS це було б набагато простіше.

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

Результат:

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

Зрештою, коли managed Amazon EKS сервіс став відповідати PCI DSS у потрібних нам регіонах, ми перейшли на нього. Але, звісно, це було не так просто, враховуючи, що треба було переписувати під нього всі конфігураційні скрипти.

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

Чого навчились

Головний урок — важливо об’єктивно оцінювати доречність технологій. Не до всього треба і можна застосувати Kubernetes (є достатньо альтернатив, наприклад, Amazon ECS і HashiCorp Nomad). Хоч у платформи й багато можливостей, але вони далеко не всім доречні, особливо коли йдеться про невеликі проєкти, які потребують швидких і максимально ефективних рішень. Не для всього треба ракети — для дечого досить і повітряних кульок.

Випадок № 4. «Нові фічі — наша мета»

Цьому клієнту була потрібна мікросервісна архітектура з нуля, процес CI/CD, і він погоджувався з використанням IaC для розгортання менеджменту та інфраструктури. Однак у клієнта був обмежений час на ухвалення рішення та реалізацію пілоту (MVP) — йому спершу варто було показати рішення MVP-інтеграції і вже потім рухатись далі. Отримавши широке поле роботи, ми нав’язали клієнту ідею all-in-one-platform з великою кількістю фіч (уявіть незалежні компоненти з можливістю перевикористання, розгортання різних компонентів хмарної інфраструктури, використання різних типів збирання застосунків, використання Golden Image тощо).

Що пішло не так

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

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

Чого навчились

Цей проєкт навчив мене важливих речей про доцільність і необхідність певних сервісів і функціоналу:

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

Замість висновків

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

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