Виміряйте, перш ніж повертатися з хмари: розрахунок виходу за реальним використанням

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

Проблема: рахунок описує те, що ви орендуєте, а не те, що використовуєте

Хмарний рахунок перелічує типи інстансів, розміри томів і рівні сервісів. Нічого з цього не каже, скільки CPU ваш застосунок спожив у найзавантаженішу годину, скільки IOPS насправді виконала база даних чи скільки пам’яті насправді тримає кеш. Саме ці числа потрібні для дизайну фізичної або private cloud інфраструктури, і хмарний провайдер увесь цей час записував більшість із них для вас.

Крок перший: інвентаризуйте все, а не лише сервери

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

for r in $(aws ec2 describe-regions --query 'Regions[].RegionName' --output text); do
  aws resourcegroupstaggingapi get-resources --region "$r" \
    --query 'ResourceTagMappingList[].ResourceARN' --output text
done | tr '\t' '\n' | sort > inventory.txt

Потім згрупуйте за сервісом. Сервери зазвичай є легкою частиною. Робота в тому, що їх оточує: managed бази даних, кеші, балансувальники, зони DNS, черги, об’єктні bucket, сертифікати, заплановані функції, а також ролі IAM і security groups, що пов’язують їх разом. Кожен потребує власника і рішення: перенести, замінити, залишити або вивести з експлуатації.

Крок другий: читайте перцентилі, а не середні

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

aws cloudwatch get-metric-statistics \
  --namespace AWS/EC2 --metric-name CPUUtilization \
  --dimensions Name=InstanceId,Value=<instance-id> \
  --start-time "$(date -u -d '-30 days' +%FT%TZ)" --end-time "$(date -u +%FT%TZ)" \
  --period 3600 --extended-statistics p95 \
  --query 'Datapoints[].ExtendedStatistics.p95' --output text \
  | tr '\t' '\n' | sort -n | tail -1

Пам’ять є прогалиною: метрики гіпервізора не бачать усередину гостьової системи. Якщо встановлений агент CloudWatch, його метрики пам’яті є у просторі імен CWAgent. Якщо ні, збирайте зсередини інстансів пару тижнів за допомогою sar або вашого наявного моніторингу, перш ніж щось розраховувати. Вгадування пам’яті є способом, яким дизайни виходять або голодними, або марнотратними.

Зробіть те саме для сховища: VolumeReadOps і VolumeWriteOps на том дають вам реальні IOPS, а VolumeReadBytes і VolumeWriteBytes пропускну здатність. Для managed баз даних читайте CPUUtilization, FreeableMemory, ReadIOPS і WriteIOPS. Для кешів фактично використану пам’ять і кількість підключень. Для трафіку NetworkOut на інстанс показує, звідки насправді йде вихідний трафік, що важливо для дизайну мережі, а не лише для рахунку.

Крок третій: складіть таблицю розрахунку

Зведіть вимірювання в одну таблицю, один рядок на навантаження:

Навантаження	CPU p95	Використана пам’ять p95	IOPS p95	Частка egress	Очікуване зростання

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

• Ніколи не давайте віртуальній машині більше vCPU, ніж фізичних ядер має один сокет CPU, і не більше пам’яті, ніж обслуговує один вузол NUMA. VM, розтягнута між сокетами, платить штраф за віддалену пам’ять при кожному зверненні і часто працює повільніше за меншу. Якщо навантаженню потрібно більше за сокет, воно має масштабуватися горизонтально або переходити на bare metal.
• Підберіть правильний розмір і зупиніться. Хмарні інфраструктури регулярно завищені в розмірі, бо зміна розміру була ризикованою. На виділеній інфраструктурі правильний розмір дешевший і часто швидший.

Крок четвертий: зіставте кожен managed-сервіс з чимось власним

Для кожного managed-сервісу запишіть, що його замінює і що змінюється для застосунку:

Managed-сервіс	Власна заміна	Що помічає застосунок
Managed MySQL або MariaDB	Percona XtraDB Cluster або реплікована MariaDB за ProxySQL	новий endpoint; більше нічого
Managed Redis	Valkey або Redis із Sentinel	підключення через Sentinel
Балансувальник застосунків	Пара HAProxy з плаваючими адресами	нічого
Managed DNS	ваша власна інфраструктура PowerDNS	нічого, якщо перехід послідовний
Managed Kubernetes	OpenShift або OKD на bare metal	ті самі маніфести, з переглянутими storage classes

Деякі сервіси не мають розумного еквівалента у вашому новому домі або дешеві та зручні там, де є. Гібрид є легітимною відповіддю: залиште їх у хмарі і з’єднайте обидві сторони приватно. План повернення, який намагається перенести все, часто є тим, що застрягає.

Крок п’ятий: проєктуйте для доменів відмов, які залишаєте позаду

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

Крок шостий: плануйте перенесення DNS як критичний шлях, яким воно є

DNS зазвичай переноситься останнім і є тим, що може зламати все одразу. Якщо зона підписана DNSSEC, вибудуйте послідовність зміни ключа і запису DS так, щоб резолвери з валідацією ніколи не бачили розірваного ланцюга. Повний перехід одного клієнта з AWS DNS ми описуємо на нашій сторінці managed DNS.

Ваш контрольний список

• Повна інвентаризація в усіх регіонах, з власником і рішенням для кожного ресурсу.
• Щонайменше місяць даних p95 і пікового використання для CPU, пам’яті, IOPS і egress.
• Пам’ять, виміряна зсередини гостьових систем, а не вгадана.
• Таблиця розрахунку, що розраховує за виміряними піками, з VM у межах одного сокета.
• Кожен managed-сервіс зіставлений із заміною або свідомо залишений.
• Домени відмов спроєктовані явно, а перенесення DNS вибудуване послідовно.

Якщо ви зважуєте повернення на власну інфраструктуру, ми радо почнемо з вимірювання.

cta: Поговоріть з інженером

Related

• /what-we-do/data-web/cloud-repatriation/
• /what-we-do/data-web/datacenter-migrations/
• /what-we-do/data-web/high-availability-platforms/