Чому ваші витрати на хмару занадто високі: прихована сила AWS Graviton

коли витрати на хмарні сервіси виходять з-під контролю, більшість організацій звертаються до стандартних рішень: резервовані інстанції, спотові інстанції або вимкнення невикористовуваних ресурсів. Але існує ще один шлях — потужний, але недооцінений підхід, який не тільки знижує ваші рахунки за AWS, але й покращує продуктивність: процесори AWS Graviton. Ці ARM-базовані процесори, розроблені AWS, встановлюють новий стандарт для економії коштів і продуктивності в хмарі.

https://www.mgt-commerce.com/blog/amazon-ec2-r8g-instances-with-aws-graviton4-processors/

Що таке інстанції Graviton?

Процесори AWS Graviton — це спеціально розроблені ARM-базовані процесори, створені для забезпечення виняткових переваг щодо співвідношення ціни та продуктивності. Інстанції Graviton доступні в кількох варіантах, зокрема Graviton2 та передові Graviton3, кожен з яких оптимізований для різних хмарних навантажень.

Чому вам це важливо? Інстанції Graviton на 20–40% дешевші за їх x86 аналоги, часто забезпечуючи кращу продуктивність. Для бізнесів, які борються з високими витратами на хмарні сервіси, перехід на Graviton — це очевидне рішення.

Дивіться порівняння продуктивності для аналогічних інстанцій EC2 на архітектурах x86 і ARM (AMD, Graviton)

Чому Graviton? Основні переваги для вашого бюджету

1. Економія коштів, яка має значення Інстанції Graviton створені для того, щоб забезпечити значне зниження витрат. Ось деякі цифри:

• m6g.large (Graviton2): $0.077 за годину
• m5.large (x86): $0.096 за годину

1. Це означає на 20% нижчі витрати на годину роботи інстанції. Якщо масштабувати ці заощадження на сотні або тисячі інстанцій, це може значно знизити ваші витрати.
2. Продуктивність, яка зрівняється або перевищить x86 Процесори Graviton відзначаються в роботі з багатонитковими навантаженнями, часто перевершуючи x86 у багатьох випадках. Останні моделі Graviton3 пропонують до 25% кращу продуктивність порівняно з Graviton2, що робить їх ідеальними для ресурсомістких додатків.
3. Масштабованість і гнучкість Завдяки широкому вибору сімейств інстанцій (наприклад, T4g, M6g, C7g), Graviton може масштабуватися відповідно до ваших вимог до навантаження — від легких мікросервісів до важких обробок даних.
4. Екологічний вплив Інстанції на базі Graviton використовують на 60% менше енергії для досягнення такої ж продуктивності, як традиційні інстанції EC2. Зниження споживання енергії означає не лише економію коштів, а й зменшення вуглецевого сліду — виграш для вашого бюджету та цілей сталого розвитку.

Навантаження, які отримують найбільшу вигоду

Інстанції Graviton показують відмінні результати в різних варіантах використання, таких як:

• Контейнеризовані додатки: Навантаження Kubernetes або ECS досягають безперебійної масштабованості та економії витрат за допомогою Graviton.
• Веб-додатки: Веб-сервери з високим пропуском і REST API працюють надзвичайно ефективно на інстанціях Graviton.
• Обробка даних: Великі дані, такі як Apache Spark або ETL пайплайни, виграють від економічної продуктивності Graviton.
• Мікросервіси: Легкі, масштабовані сервіси процвітають завдяки балансуванню ціни та швидкості на Graviton.
• CI/CD пайплайни: Зменшуйте витрати на збірку та тестування, використовуючи Graviton для CI/CD навантажень.

Мій досвід: міграція SaaS платформи на Graviton

https://www.linkedin.com/pulse/navigating-shift-migrating-graviton-enhanced-aws-cloud-taiwal-llzkc/

Під час нещодавнього проєкту я мав можливість очолити міграцію бекенд-систем SaaS компанії на інстанції AWS Graviton. Компанія використовувала API бекенди на комбінації інстанцій m5.large, m5.xlarge та r5.large, які були надійними, але дорогими. На той час компанія працювала з близько 120 інстанціями m5.large в продуктивному середовищі разом з кількома m5.xlarge та r5.large інстанціями.
Крім того, для деяких некритичних навантажень використовувалися Spot Instances, а для рівня бази даних — Reserved Instances.

Крок 1: Оцінка навантажень

Ми почали з аналізу бекенд-навантажень за допомогою AWS Compute Optimizer. Результати показали, що ARM-базована архітектура Graviton є чудовим варіантом для наших API-навантажень і мікросервісів.

Крок 2: Тестування сумісності

Оскільки стік API був побудований на Node.js і Java, сумісність не викликала проблем — обидва мають відмінну підтримку ARM64. Використовуючи Docker, ми оновили наші образи контейнерів до версій, сумісних з ARM64, і протестували їх локально та в тестових середовищах.

Тестування міграції: на що звертати увагу

Правильне тестування під час міграції на інстанції Graviton є критичним для забезпечення продуктивності та сумісності. Ось ключові напрямки для тестування:

1. Функціональна сумісність:

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

1. Оцінка продуктивності:

• Порівняйте час відгуку, пропускну здатність і затримку між інстанціями x86 та Graviton.
• Моніторте використання CPU, пам'яті та пропускну здатність мережі під час пікових навантажень.
• Імітуйте трафік продуктивного середовища за допомогою інструментів для навантажувального тестування, таких як Apache JMeter або Locust.

1. Оптимізація ресурсів:

• Оцініть розмір інстанцій. Інстанції Graviton можуть вимагати налаштування обсягів пам'яті чи CPU для досягнення оптимальної продуктивності.
• Переконайтеся, що поведінка Spot Instance передбачувана для некритичних навантажень.

1. Сумісність контейнерів:

• Переконайтеся, що образи контейнерів створені для архітектури ARM64.
• Використовуйте інструменти, такі як Docker Buildx, для створення мультиархітектурних образів для легшого відкату.

1. Тестування баз даних і зберігання:

• Перевірте, чи працюють Reserved Instances для баз даних (наприклад, RDS) без проблем при доступі з додатків на базі Graviton.
• Тестуйте продуктивність зберігання, особливо для навантажень, чутливих до IOPS.

1. Моніторинг і сповіщення:

• Налаштуйте розширений моніторинг за допомогою Amazon CloudWatch або сторонніх інструментів.
• Визначте сповіщення для непередбачуваної поведінки, такої як сплески CPU, витоки пам'яті чи мережеві помилки.

1. Стратегія розгортання:

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

Крок 3: Бенчмаркінг і порівняння

Щоб підтвердити успішність міграції, ми провели паралельне тестування інстанцій m5.large(x86), m5.xlarge і r5.large з їхніми аналогами на Graviton (m6g.large, m6g.xlarge, r6g.large). Результати були обнадійливими:

• Покращення продуктивності: час відгуку API покращився на 15%.
• Зниження витрат: витрати на інстанції знизилися на 20–30%, залежно від навантаження та типу інстанції.

Крок 4: Поступове розгортання

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

Крок 5: Моніторинг і оптимізація

Після міграції ми використовували Amazon CloudWatch для моніторингу продуктивності і переконалися, що все працює без збоїв. Тонка настройка розподілу ресурсів дозволила нам максимізувати економію коштів.

Результати: Перемога для витрат і продуктивності

Міграція дала чудові результати:

• Економія витрат на 20–30%: витрати на EC2 значно знизилися, що звільнило бюджет для інновацій.
• Покращення продуктивності на 15%: швидші часи відгуку API покращили користувацький досвід.
• Безперебійний перехід: мінімальні зміни, і команда швидко адаптувалася до нової конфігурації.

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

1. Несумісність з застарілим програмним забезпеченням або архітектурами

Причина: Деякі додатки або залежності програмного забезпечення можуть бути побудовані спеціально для архітектур x86 і не підтримувати ARM64.

Ризики:

• Додатки з застарілими бібліотеками або власними бінарниками можуть не працювати на процесорах на базі ARM.
• Переписування або перекомпіляція цих додатків може бути трудомістким і дорогим процесом.

Мітегування:

• Аудит вашого програмного стеку для виявлення сумісності з ARM64.
• Використання емуляції (наприклад, QEMU), але слід враховувати можливі витрати на продуктивність.

2. Відсутність підтримки деяких сторонніх інструментів або сервісів

Причина: Деякі сторонні програмні засоби або інструменти, що використовуються у вашій інфраструктурі, можуть не підтримувати ARM64.

Ризики:

• Ключові інструменти або моніторингові агенти (наприклад, власні рішення APM, агенти безпеки) можуть не працювати належним чином на Graviton.
• Обмежена підтримка від сторонніх постачальників для середовищ на базі ARM.

Мітегування:

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

3. Специфічні вимоги до продуктивності або затримки

Причина: Деякі навантаження можуть не працювати так ефективно на Graviton через специфічні вимоги до оптимізації.

Ризики:

• Високо оптимізовані x86 навантаження можуть втратити продуктивність при виконанні на ARM-архітектурі.
• Додатки, що залежать від специфічних можливостей Intel (наприклад, AVX512), можуть не мати еквівалентів для ARM.

Мітегування:

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

4. Залежності від власного програмного забезпечення без підтримки ARM

Причина: Власне програмне забезпечення від сторонніх постачальників може не надавати ARM-будови або підтримки.

Ризики:

• Відсутність версій, сумісних з ARM, може завадити міграції.
• Затримки в оновленнях від постачальників можуть затримати процес міграції.

Мітегування:

• Підтримуйте гібридне середовище з обома типами інстанцій x86 і ARM до того часу, поки програмне забезпечення не буде підтримувати ARM.

5. Проблеми з мультиархітектурними збірками

Причина: Додатки, що потребують одночасної підтримки як x86, так і ARM середовищ, можуть ускладнити процеси CI/CD.

Ризики:

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

Мітегування:

• Використовуйте Docker Buildx для мультиархітектурних образів контейнерів.
• Встановіть автоматизовані CI/CD конвеєри для безперешкодної підтримки між архітектурами.

6. Несумісності з базами даних або сховищами

Причина: Деякі бази даних або рішення для зберігання даних можуть бути не оптимізовані для ARM-систем.

Ризики:

• Погіршення продуктивності для навантажень, чутливих до IOPS.
• Несумісність з певними розширеннями баз даних або драйверами.

Мітегування:

• Ретельно тестуйте продуктивність бази даних на інстанціях на базі ARM.
• Залиште рішення для баз даних на x86, якщо це необхідно, одночасно мігруючи інші компоненти на Graviton.

7. Мінімальні заощадження для короткострокових навантажень

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

Ризики:

• Попередні зусилля на міграцію можуть не виправдати довгострокових знижок.

Мітегування:

• Зосередьтеся на довгострокових, стабільних навантаженнях, де міграція дасть найбільшу віддачу.
• Використовуйте Spot Instances або Reserved Instances для короткострокових x86 навантажень для мінімізації витрат.

Висновок

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

Перекладено з: Why Your Cloud Costs Are Too High: The Secret Power of AWS Graviton