Не повторюй ці факапи при роботі з AWS. 2 частина
Багато сервісів AWS створюють гнучкість і сотні варіантів, як можна кастомізувати свою інфраструктуру. Але хто сказав, що в них неможливо загубитись?
У першій частині цієї статті ми вже розповіли про виклики з безпекою, управлінням витрат та порушенням вимог при роботі з AWS. Прочитай її зараз чи повернись пізніше: «Не повторюй ці факапи при роботі з AWS. 1 частина»
Зараз настала черга недоліків в архітектурі, розробці та неефективному збереженні ресурсів. Гортай нижче.
Недоліки архітектури
1. Неправильний вибір екземплярів для робочого навантаження
Часто обирають інстанси, які не відповідають реальним потребам. У підсумку ресурси простоюють, а рахунки ростуть.
Як правильно: аналізуй навантаження через CloudWatch, тестуй різні типи інстансів і не забувай про Auto Scaling.
2. Відсутність автоматичного масштабування
Без Auto Scaling будь-який сплеск трафіку може покласти застосунок.
Як правильно: налаштуй масштабування за CPU, пам’яттю або кастомним CloudWatch-метриками.
3. Відсутність планування високої доступності
Розміщення всіх ресурсів в одній Availability Zone створює єдину точку відмови. Якщо ця зона виходить із ладу через збій чи оновлення, сервіс перестає працювати повністю.
Як правильно: розгорни інфраструктуру мінімум у двох AZ і продумай можливість відновлення.
4. Невдале налаштування балансувальників
Неправильні правила маршрутизації або тайм-аути збивають продуктивність і створюють вузькі місця в системі.
Як правильно: регулярно перевіряй конфігурації ELB, тестуй різні режими балансування.
5. Ігнорування реплік читання у базах даних
Основна база отримує забагато запитів на читання й починає гальмувати. Коли вся робота проходить через один інстанс, система швидко втрачає продуктивність.
Як правильно: додавай Read Replicas у RDS або Aurora для великих проєктів.
6. Відсутність кешування
Коли дані щоразу вантажаться напряму з бази чи застосунку, навантаження різко зростає. Без кешування система витрачає сили на повторювані запити й помітно повільнішає.
Як правильно: використовуй кешування часто запитуваних даних — від статичних об’єктів і сторінок до результатів API. Це зменшує навантаження на сервер і пришвидшує відгук застосунку. Для цього можна застосовувати ElastiCache, CloudFront, кешування на стороні клієнта або у власному застосунку.
7. Моноліт там, де мали б бути мікросервіси
Моноліт швидше написати, але важче масштабувати та підтримувати.
Як правильно: розділи застосунок за доменами, коли навантаження починає різко рости.
8. Ігнорування безсерверних рішень
Традиційні сервери постійно працюють навіть для дрібних або подієво-керованих задач. Через це витрачаються ресурси і гроші, а система стає складнішою для підтримки.
Як правильно: використовуй безсерверні сервіси, як-от AWS Lambda, для обробки подій, черг, легких API або тригерів.
9. Розгортання в одному регіоні
Це веде до великих затримок і зниженої стійкості.
Як правильно: продумай multi-region архітектуру з Route 53, якщо продукт глобальний.
Контроль за розробкою
1. Харди у коді
Якщо облікові дані AWS зберігати прямо в коді чи репозиторіях, вони легко потрапляють до сторонніх.
Як правильно: зберігай секрети в AWS Secrets Manager, Parameter Store або в змінних середовища. Це гарантує контроль доступу, автоматичну ротацію ключів і безпечне використання у коді та скриптах.
2. Відсутність IaC
Якщо інфраструктуру створювати вручну, складно відстежити, хто що налаштував, як змінювались ресурси і як відтворити середовище. Це підвищує ризик помилок, дублювання та простою.
Як правильно: використовуй Infrastructure as Code через CloudFormation або Terraform.
3. Ігнорування контролю версій шаблонів
Якщо шаблони CloudFormation змінюються без контролю версій, легко випадково зламати продакшн. Ти не знаєш, яка версія зараз актуальна і хто що змінив.
Як правильно: тримай всі шаблони в Git, роби рев’ю змін і зберігай історію. Так можна безпечно повертати попередні версії та відстежувати, хто що зробив.
4. Розгортання нетестованого коду
Якщо перенести код у продакшн без перевірки, ризик багів і простоїв зростає в рази.
Як правильно: впровадь автоматизоване тестування і конвеєри CI/CD. Код проходить перевірки перед релізом, і продакшн не зламається від дрібних помилок.
5. Недостатній моніторинг під час розробки
Код може виглядати ідеально локально, але на реальних навантаженнях виникають приховані проблеми. Без метрик і логів ти не бачиш, що реально відбувається.
Як правильно: інтегруй CloudWatch, X-Ray і логування на ранніх етапах. Так проблеми видно ще до продакшну, і їх легше виправити.
6. Відсутність CI/CD
Розгортання вручну = високий ризик помилок, затримки і залежність від конкретних людей.
Як правильно: використовуй CodePipeline, GitHub Actions або Jenkins для автоматизації розгортання. Код потрапляє на продакшн лише після перевірок, процес стає передбачуваним і безпечним.
7. Ігнорування AWS SDK
Робити інтеграції вручну замість офіційних бібліотек — це більше коду, більше помилок і складніше підтримувати.
Як правильно: використовуй офіційні SDK AWS для своєї мови програмування. Вони вже враховують усі нюанси API, а оновлення та безпека автоматично підтримуються.
8. Ігнорування керованих сервісів
Підіймати EC2 для всього підряд замість готових сервісів означає зайві витрати часу та грошей, і ти самостійно стаєш оператором всього стеку.
Як правильно: перед тим як запускати власний сервер, дивись на керовані сервіси: SQS для черг, SNS для повідомлень, DynamoDB для БД, EKS/ECS для контейнерів. Вони скорочують рутину і зменшують ризики.
9. Недооцінка контейнеризації
Без контейнерів масштабувати застосунок складно, а при зростанні навантаження з’являються вузькі місця і хаос у деплойменті.
Як правильно: переводь застосунки на Docker + ECS/EKS, коли зростає трафік або кількість сервісів. Контейнери полегшують масштабування, автоматизацію і контроль залежностей.
Неефективність зберігання
1. Високовартісне сховище для рідко використовуваних даних
Дані лежать на EBS або у стандартному S3, хоч вони майже ніколи не потрібні. Ти платиш за простір, який не приносить користі.
Як правильно: перенеси архівні дані у S3 Glacier/Glacier Deep Archive або інші холодні рівні, де зберігання дешевше.
2. Забуті AMI та старі знімки
Створили AMI чи знімок для тесту, а він висить місяцями та споживає бюджет.
Як правильно: регулярно перевіряй і видаляй непотрібні AMI та старі знімки EBS.
3. Неефективне зберігання логів та резервних копій
Логи, бекапи, великі файли лежать у гарячому сховищі, хоча рідко використовуються.
Як правильно: вмикай версіонування, політики життєвого циклу та стиснення файлів.
4. Перевантажені таблиці DynamoDB
Запити починають працювати повільніше, бо дані розподілені нерівномірно: одні розділи перевантажені, інші — пустують. У результаті росте і затримка, і вартість запитів.
Як правильно: проєктуй таблиці так, щоб ключі розподіляли навантаження рівномірно, або розбивай дані на кілька секцій відповідно до обсягу й характеру трафіку.
5. Надлишкові резервні копії RDS
Бекапи накопичуються, займають місце й непомітно з’їдають бюджет, хоча більшість із них не потрібна.
Як правильно: визнач чіткі правила зберігання й видалення копій, автоматизуй їх через політики retention і регулярно перевіряй, чи не лишилось зайвого.
6. Неконтрольовані квоти та дозволи EFS
Файлова система збільшується, бо ніхто не стежить, хто і скільки туди пише. У найгіршому випадку великий викид файлів забиває простір і ламає робочі процеси.
Як правильно: встанови квоти, чіткі дозволи й моніторинг використання, щоб уникати переповнення та випадкових помилок.
7. Ігнорування альтернативних сервісів
S3 або EFS використовують автоматично, навіть для робочих навантажень, де вони слабко підходять — і система працює повільніше або дорожче, ніж могла б.
Як правильно: підбирай сховище під задачу: FSx for Lustre, FSx for Windows, FSx for ONTAP, S3 з різними класами або спеціалізовані опції — це часто швидше й економніше.
Висновок
Більшість фейлів, які ми описали — це банальні шкідливі звички. В команді їх можна вловити по фразах «та нехай працює, потім оптимізуємо». І саме з цих дрібниць народжуються великі рахунки, повільні сервіси та невловимі баги.
Якщо хочеш не тільки вміти працювати з сервісами, а й мислити як інженер, тоді запрошуємо на навчання. 8 занять, ключові інструменти від AWS та максимум практики піднесуть тебе на новий рівень.