Оптимізація витрат на мережу в AWS EKS: Управління трафіком між AZ для баз даних

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

Нещодавно ми зіткнулися з серйозною проблемою в нашій конфігурації AWS EKS, де витрати на мережу значно зросли через трафік між різними зонами доступності (AZ).

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

Додаток взаємодіє з Redis, MySQL та MongoDB, усі ці бази даних розгорнуті в Stateful Sets з PV та PVC. Вони розподілені між трьома AZ для забезпечення високої доступності та відмовостійкості.

Однак часті запити з додатка разом з трафіком баз даних, що перетинає кордони AZ, значно збільшили витрати на мережу.

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

Розбір витрат EKS

При використанні AWS EKS, є кілька складових витрат:

1. Плата за управління EKS:

AWS стягує фіксовану плату $0.10 за годину за кластер, що становить приблизно $73 на місяць за кластер, незалежно від його розміру. Ця плата покриває керовану контрольну площину, яка включає такі компоненти, як сервер API Kubernetes та etcd для управління станом кластера.

2. Витрати на EC2 вузли:

EKS потребує робочих вузлів (екземплярів EC2) для запуску ваших робочих навантажень. Вартість цих вузлів залежить від:

• Типу екземпляра (наприклад, t2.medium, m5.large).
• Кількості вузлів у вашому кластері.
• Часу роботи цих вузлів.
  Також витрати можуть збільшитись, якщо ви ввімкнете автоматичне масштабування, оскільки кластер додає вузли в залежності від попиту на ресурси.

3. Витрати на мережу:

Мережа є однією з найбільших складових витрат EKS, особливо в налаштуваннях з кількома AZ. Основні фактори:

• Між-AZ передача даних: AWS стягує $0.01 за ГБ за передачу даних між AZ. Ці витрати можуть швидко зростати, якщо ви використовуєте сервіси, як-от бази даних, які часто взаємодіють через межі AZ.
• Трафік між VPC: Якщо ваш кластер EKS взаємодіє з іншими VPC або зовнішніми сервісами, ви понесете додаткові витрати.
• Elastic Load Balancer (ELB): Будь-який вхідний трафік в кластер через ELB також стягується окремо за передачу даних.

4. Витрати на постійну пам'ять:

Для Stateful робочих навантажень, таких як бази даних, використовується сховище, наприклад, Amazon EBS (Elastic Block Store), для збереження даних. Вартість залежить від:

• Розміру та типу об’єму (наприклад, SSD загального призначення, Provisioned IOPS).
• Зберігання знімків для резервного копіювання.
• Платежі за IOPS для високопродуктивних робочих навантажень.

5. Додаткові послуги:

• CloudWatch: Для ведення журналів та моніторингу AWS стягує плату за прийом журналів, зберігання та отримання даних.
• Передача даних назовні: Трафік, що покидає AWS (наприклад, в інтернет чи зовнішні системи), стягується за $0.09 за ГБ для перших 10 ТБ кожного місяця.

Порада: Для керування конфігураціями DNS у вашому AWS EKS можна ознайомитись із нашою статтею про Розгортання зовнішнього DNS з AWS EKS, яка досліджує ефективні стратегії інтеграції для управління великими обсягами DNS.

Розглянуті рішення

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

1. Топологічно обізнаний маршрутинг сервісів

• Мета: Забезпечити, щоб трафік залишався в межах однієї AZ, коли це можливо.
• Реалізація: Увімкнути Service Topology у Kubernetes, додаючи анотації сервісів для маршрутизації трафіку до подів в межах однієї AZ.

Переваги:

• Зменшення між-AZ трафіку для запитів до баз даних.
• Поліпшена латентність завдяки локальному трафіку в межах AZ.

2.

Кешування часто запитуваних даних

• Мета: Зменшити частоту повторюваних запитів до бази даних.
• Реалізація:
  • Інтеграція Redis як шару кешу для операцій з високим навантаженням на читання.
  • Використання кешування на рівні додатка з TTL для частих запитів.

Переваги:

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

3. Конфігурація Read Replica

• Мета: Перенаправити трафік на читання до реплік, розгорнутих в кожній AZ.

Реалізація:

• Налаштування read replica для MySQL та MongoDB в усіх AZ.
• Оновлення додатка для маршрутизації запитів на читання до найближчої репліки.

Переваги:

• Розподілений трафік на читання.
• Мінімізація між-AZ читань для додатків.

4. Моніторинг і аналіз трафіку

• Мета: Визначити патерни трафіку з високими витратами та оптимізувати їх.

Реалізація:

• Використання інструментів, таких як eBPF (через Cilium або подібні рішення), для моніторингу трафіку на рівні подів.
• Візуалізація патернів трафіку з Prometheus і Grafana.

Переваги:

• Поглиблене розуміння джерел між-AZ трафіку.
• Краще інформовані рішення щодо оптимізації.

5. Автоматичне масштабування з резервованими екземплярами

• Використано Reserved Instances для передбачуваних робочих навантажень для зниження витрат на EC2.
• Для динамічного масштабування використано Spot Instances з резервом на On-Demand Instances для балансування витрат і доступності.

6. Моніторинг та аналіз трафіку

• Розгорнуті інструменти, як-от Prometheus і Grafana, для моніторингу між-AZ трафіку.
• Використано eBPF-based інструменти для аналізу мережевих потоків і визначення дорогих маршрутів трафіку.
• Оптимізовано патерни запитів Node.js і PHP на основі отриманих інсайтів.

7. Ефективне управління об'ємами EBS

• Перехід на GP3 volumes для кращого балансу вартості і продуктивності.
• Зменшено частоту знімків для економії на витратах на зберігання, зберігаючи при цьому достатні інтервали для резервного копіювання.

Приклад реалізації: Топологічно обізнаний маршрутизатор

Ось швидка реалізація топологічно обізнаного маршрутування для Stateful Set MySQL:

1. Додати анотації до сервісу Kubernetes:

apiVersion: v1  
kind: Service  
metadata:  
 name: mysql  
 annotations:  
 topology.kubernetes.io/zone: "true"  
spec:  
 selector:  
 app: mysql  
 ports:  
 - protocol: TCP  
 port: 3306

2. Розгортання подів з Node Affinity:

apiVersion: apps/v1  
kind: StatefulSet  
metadata:  
 name: mysql  
spec:  
 template:  
 spec:  
 affinity:  
 nodeAffinity:  
 requiredDuringSchedulingIgnoredDuringExecution:  
 nodeSelectorTerms:  
 - matchExpressions:  
 - key: topology.kubernetes.io/zone  
 operator: In  
 values:  
 - us-east-1a

3. Міграція архітектури на 2 AZ:

Як частина нашої стратегії оптимізації, ми вирішили зменшити кількість реплік розгортання з трьох AZ до двох AZ.
Це архітектурне перероблення було викликано необхідністю:

• Зменшити витрати на між-AZ мережеві з'єднання: Коли використовувалися три AZ, додатки та інстанси бази даних часто взаємодіяли між зонами, що призводило до значних витрат на передачу даних між AZ.
• Спрощення операційного навантаження: Управління ресурсами через три AZ створювало складнощі у моніторингу, масштабуванні та забезпеченні узгодженості.

Кроки, вжиті під час міграції:

Вирівнювання бекенд-додатків і баз даних в одних AZ:

• Ми згрупували pods додатків Node.js і PHP та їхні асоційовані Redis, MySQL і MongoDB бази даних в одній AZ.
• Це забезпечило, щоб більшість трафіку між pods додатками і базами даних залишалася в межах однієї AZ, мінімізуючи між-AZ трафік.

Переналаштування StatefulSets для обізнаності про зони:

• StatefulSets для MySQL і MongoDB були переналаштовані з правилами affinity для вузлів для обмеження розміщення pods в обраних двох AZ.
• Наприклад, конфігурація affinity гарантувала, що репліки MySQL в us-east-1a будуть переважно доступні для pods додатків, що працюють в us-east-1a.

Перерозподіл трафіку:

• Патерни трафіку були налаштовані для маршрутизації запитів до бекенд-подів, які знаходяться в тій же AZ, що й база даних.
• Це було досягнуто за допомогою Service Topology і DNS-розв'язування для пріоритету локальних інстансів AZ.

Використання Read Replicas для високої доступності:

• Для забезпечення доступності та стійкості після скорочення кількості AZ, read replicas були розгорнуті в обох AZ.
• Ця конфігурація гарантувала, що кожна AZ може незалежно обробляти трафік на читання у разі відмови однієї з AZ.

Досягнуті переваги:

1. Значне зниження витрат на мережу:

• Забезпечивши розміщення бекенд-подів і інстансів бази даних в одній AZ, ми зменшили між-AZ передачу даних більш ніж на 60%. Залишковий між-AZ трафік стосувався в основному реплікації записів між вузлами баз даних.

2. Покращення продуктивності додатка:

• Затримка зменшилась, оскільки трафік між pods додатків і базами даних більше не перетинав межі AZ, що призвело до швидшого виконання запитів.

3. Оптимізація використання ресурсів:

• Консолідація ресурсів в двох AZ дозволила краще використовувати EC2 інстанси і горизонтально масштабувати їх у межах цих зон без надмірного використання ресурсів.

4. Стійка архітектура:

• Незважаючи на зменшення кількості AZ до двох, використання read реплік і розподілених сервісів гарантувало, що додаток все одно може ефективно працювати в разі відмови однієї з AZ.

Ключові зауваження:

• Компроміс між доступністю та витратами: Хоча міграція до двох AZ зменшила витрати, ми ретельно проаналізували ризики зниження стійкості до відмов у порівнянні з трьома AZ. Для нашого робочого навантаження переваги переважили ризики, оскільки наша архітектура все одно відповідала вимогам високої доступності AWS.
• Трафік реплікації записів в базі даних: Оскільки операції запису в базі даних все ще вимагали між-AZ реплікації для підтримки узгодженості, ми оцінювали і оптимізували інтервали реплікації та обсяги.

Перевірка патернів трафіку:

Після міграції ми використовували Prometheus і Grafana для моніторингу основних метрик, таких як:

• network_tx_bytes: Вимірювали загальний трафік між pods і визначали залишковий між-AZ трафік.
• request_latency: Переконалися, що час відповіді додатка покращився після міграції.
• Індивідуальні панелі приладів: Створили панелі для візуалізації патернів трафіку, що допомогло нам переконатися, що більшість комунікацій тепер локальні для AZ.

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

Дайте знати, якщо вам потрібні додаткові уточнення!

Результати

Після впровадження цих рішень:

• Між-AZ трафік знизився на 40%, що значно зменшило витрати.
• Час відгуку додатка покращився на 20% завдяки зменшенню затримки.
• Кешуючий шар зняв 60% навантаження від операцій на читання з баз даних.

Підсумок

У цій статті ми розглянули виклики, пов'язані з управлінням витратами на між-AZ трафік у кластері AWS EKS. Впровадивши маршрутизацію з урахуванням топології, кешування часто використовуваних даних та оптимізацію конфігурацій баз даних, ми зменшили витрати на мережу та покращили продуктивність додатка.

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

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

Партнерство з досвідченими інженерами DevOps дає змогу отримати комплексний набір послуг з хмарної та бекенд-розробки, застосовувати гнучкі методології та впроваджувати передові методи оптимізації, адаптовані до потреб вашого бізнесу.

Якщо ви стикаєтеся з подібними проблемами або маєте питання, не соромтеся поділитися своїм досвідом у коментарях!

Перекладено з: Optimizing Networking Costs in AWS EKS: Managing Cross-AZ Database Traffic