Чи є життя на ARM-і — досвід міграції
Привіт, IT спільното! Мене звати Дмитро Сірант, вже 4 роки я працюю на позиції СТО компанії OpsWorksCo. За цей час ми стали AWS Advanced Consulting Partner, суттєво розширили експертизу та зміцнили команду.
Мій попередній досвід DevOps-інженера дає можливість глибоко оцінити проєкт, тісно співпрацювати з командою, бо я і досі долучаюсь до проєктів компанії, щоб удосконалювати технічну експертизу, бути в курсі сучасних тенденцій. Додавайтесь до мене в LinkedIn, буду радий знайомству.
Дана публікація буде корисна DevOps та Cloud-інженерам, а також всім, хто цікавиться сучасними технологіями та прагне постійного розвитку.
Передісторія
Ми займалися міграцією AWS-проєкту, де замовник від самого початку наполягав на тому, що вартість інфраструктури має бути якомога меншою. Якщо подивитися на архітектуру проєкту, ви не помітите нічого особливого:
- фронт на React хоститься на S3 та доступний через CloudFront;
- бекенд на PHP і розгорнутий в EKS;
- трафік до бекенду потрапляє частково через CloudFront, а частково через NLB (у нас є довготривалі запити, які поки не переробили на стороні застосунку і є WebSocket);
- використовуємо RDS Aurora для MySQL та ElasticCache Redis;
- файли зберігаються на S3;
- є додатковий функціонал, який реалізований на Lambda + Athena;
- логи складаються та аналізуються в OpenSearch.
З особливостей проєкту — кількість запитів може короткостроково збільшуватись в шість разів від звичайної.
Які процесори ви знаєте?
В AWS ми маємо обмежену кількість процесорних архітектур, а саме: AMD64, ARM64 та i386. Цікаво дізнатися про ваш досвід використання i386, мені на думку спадає лише legacy застосунки, які не мають підтримки сучасніших архітектур.
Можна пограти у гру «Скажи, які процесорні архітектури або процесори ти знаєш, і я вгадаю твій вік». Більшість молодих спеціалістів мають знати AMD64 (x86_64) та ARM64 (AArch64). Ті, хто трохи доросліші, мають знати про
Якщо ви працювали з 8086, то ви десь мого віку і, скоріш за все, згадаєте про Zilog Z80
На жаль, я не можу нічого сказати про досвід тих колег, хто працював з RISK-процесорами, такими як: DEC Alpha, Atmel AVR, Blackfin, Intel i860, Intel i960, LoongArch, Motorola 88000, MIPS architecture, PA-RISC, Power ISA, RISC-V, SuperH, SPARC.
Свого часу я намагався придбати на eBay сервер з процесором SPARC, щоб погратися з Solaris, але не склалося і в мене зʼявився досвід використання «illumos», а саме NexentaOS, але то вже зовсім інша історія.
Які проблеми довелося вирішувати
Повертаємось до нашого проєкту. З самого початку ми використовували ARM (Graviton процесори власної розробки AWS) для RDS Aurora for MySQL. Це безпрограшне рішення, яке ми типово використовуємо на кожному проєкті, і не мали жодних проблем.
Наші Lambda функції, написані на Python і досить нескладні, відповідають за додатковий функціонал, тому тут теж не було жодних проблем з використанням ARM. Якщо ваш проєкт на Python має багато залежностей, то можуть виникати складнощі з міграцією.
У нас є деякі проєкти, де ми поки не можемо мігрувати на ARM, тому що частина залежностей на ньому не збираються.
Як не дивно, з ElasticCache Redis на інстансах m6g є проблеми, якщо у вас увімкнутий TLS (а я дуже сподіваюсь, що це так). Навіть підтримка AWS рекомендує використовувати m5 інстанси замість цього. У нашому випадку було достатньо використовувати t4g і наразі проблем з TLS немає.
OpenSearch (по суті форк ElasticSearch, допрацьований та підтримуваний AWS) працює на ARM-інстансах без якихось нарікань і не потребує додаткової уваги при створенні.
Що стосується EKS-кластеру, то все дуже залежить від того, які контейнери ви маєте запускати, а саме, чи є Docker імеджи зібрані під ARM64. У нашому випадку треба було перезібрати деякі імеджи — php-fpm_exporter (наразі вже має підтримку ARM64 по замовченню), missing-container-metrics, довелося оновити prometheus-stack та ще декілька додатків до сучасних версій.
Кластер у нас побудований виключно на SPOT інстансах і ми використовуємо Karpenter для створення воркер нод. Мігрували поступово, створили окремі Provisioners для ARM64 та AMD64 і використовували nodeSelector в залежності від того, чи є в нас необхідний імедж для ARM64.
Інструменти на допомогу
З managed services все майже без проблем, вам достатньо обрати тип інстансу, який відповідає потребам та побудований на ARM-архітектурі (сучасні покоління процесорів мають більшу продуктивність, на даний час це процесор Graviton 3, який представлений у c7g, m7g та r7g інстансах).
З міграцією застосунка складніше, він має компілюватися під потрібну архітектуру. Допомогти з міграцією може проєкт, який аналізує ваш код та показує місця, що треба переписати. Наразі є підтримка:
- Python 3+
- Java 8+
- Go 1.11+
- C, C++, Fortran
Якщо код ваш збирається під AMD64 і ви використовуєте контейнери, то вам необхідно подбати про те, щоб docker імеджи були зібрані під необхідну архітектуру (краще одразу під декілька, щоб мати можливість запускати на різних процесорах при необхідності).
Docker підтримує збірку кросплатформних імеджей за допомогою плагіну buildx, але я рекомендую використовувати buildah, який не потребує наявності docker socket файлу, і ви можете не використовувати Docker-in-Docker, а запускати збірку навіть на ранерах в Kubernetes.
Все, що вам потрібно, — це виконати команди, які зберуть вам імеджі під дві архітектури та додадуть їх до registry:
buildah login -u "registry_username" -p "registry_password" registry_url buildah bud --manifest your_image:tag --jobs=2 --platform=linux/arm64/v8,linux/amd64 -f Dockerfile . buildah manifest push your_image:tag docker://registry_url/your_image:tag --all
Якщо ви використовуєте для збірки машину з AMD64, то можете помітити, що контейнер для ARM64 буде збиратися повільніше (якщо виконується компіляція). Це тому, що в такому випадку відбувається емуляція необхідної архітектури. Якщо це критично, і ви хочете зменшити час роботи вашого пайплайну, має сенс розглянути використання ранерів під кожну архітектуру окремо, щоб уникнути емуляції.
Підібʼємо підсумки
На даний час 99% нашого проєкту працює на ARM, і цей один відсоток залишається лише тому, що master ноди EKS (до яких ми не маємо доступу) чомусь працюють на AMD64. Як на мене, це виглядає дивним (гей, AWS, допомогти з міграцією?). Це невеликий проєкт, за який клієнт платить приблизно $6000 на місяць. Попри міграцію кластера, економічна вигода не була настільки великою, оскільки різниця між вартістю SPOT на AMD64 та ARM64 незначна в абсолютних числах. Використання гравітонів для бази та Redis дає в нашому випадку суттєвішу економію.
На жаль, ми не робили аналізу «до та після» міграції, щоб перевірити, чи насправді інстанси на гравітоні надають перевагу в продуктивності порівняно з Intel та AMD процесорами. У нашому випадку було достатньо того, що вона не гірша, і ми можемо використовувати ті самі інстанси за розміром і платити за них меншу ціну.
Як ви бачите, оптимізацію витрат за допомогою переходу на ARM для managed сервісів можна віднести до першочергових, оскільки це не потребує від вас багато зусиль. У разі міграції самих застосунків — тут все залежить від того, чи є у вас певні залежності, які не підтримують компіляцію під ARM. Якщо ні — має сенс витратити декілька днів і спробувати мігрувати.
Безсумнівно, ваша команда розробників в компанії буде цінувати це, оскільки тепер вони зможуть запускати нативні Docker-імеджі на своїх Macbook M1/M2 без потреби у використанні емуляції.
Гайда в коментарі, хочу почути про ваш досвід використання ARM інстансів в AWS та інших хмарах (у мене немає такого досвіду). Ставте запитання, буду радий долучитися до діалогу.
Якщо вам потрібна допомога з міграцією або з модернізації інфраструктури в AWS, наша команда залюбки допоможе. Підписуйтесь на YouTube-канал @DevOpsTalksAtOpsworks та долучайтеся до онлайн-вебінарів, які ми проводимо.
Serhii Tyshchenko
Serhii Tyshchenko
Valentin Nechayev
Serge Loboda
Anton P
Andrii Cherepakha
Anton P
Andrey Ruban
Valentin Nechayev
Pavel Katiushyn
Pavel Katiushyn
Андрій Товстоног
Андрій Товстоног
25 коментарів
Додати коментар Підписатись на коментаріВідписатись від коментарів