Внедрение AWS Graviton3 в ESW Capital


Авторы: Эрманно Аттардо, Стивен Барр, Паван Кумар ТВ, Иржи Пик, Али Саиди

В этой статье мы хотели бы поделиться опытом компании ESW Capital по миграции одного из наших ключевых продуктов для разработки программного обеспечения — DevSpaces — на Graviton3.

1. Гравитон3

Для облачных вычислений AWS предлагает несколько типов и размеров экземпляров EC2 с различными архитектурами процессоров, скоростями процессоров и размерами, что позволяет выбрать для каждой конкретной рабочей нагрузки наиболее подходящий вариант экземпляра.

EC2 предлагает несколько поколений процессоров x86 от Intel и AMD. AWS также создает свои собственные чипы для центров обработки данных. Они начали с чипов для карт Nitro и расширили эту сферу до чипов машинного обучения Inferentia и Tranium, а также хост-вычислений Graviton. Процессоры Graviton используют набор инструкций Arm, который также используется в телефонах, последнем поколении компьютеров Apple Mac и самом быстром суперкомпьютере в мире. Второе поколение Graviton2 было выпущено в декабре 2019 года, и теперь на его базе работают 12 типов инстансов, которые обеспечивают общее улучшение цены и производительности на 40% по сравнению с инстансами на базе x86.

AWS быстро совершенствует процессоры Graviton, и в конце 2021 года они анонсировали Graviton3. По словам AWS, третье поколение Graviton повысило производительность общего назначения на 25% и расширило возможности процессоров Graviton для машинного обучения (до 3-кратного повышения производительности) и высокопроизводительных вычислений (до 2-кратного повышения производительности). Процессоры Graviton также более энергоэффективны: AWS утверждает, что процессоры Graviton3 потребляют на 60% меньше энергии по сравнению с другими типами экземпляров при аналогичной производительности.

2. ESW Capital

ESW Capital — это портфель из более чем ста компаний, занимающихся разработкой программного обеспечения для предприятий.

В 2008 году компания ESW сделала стратегический выбор в пользу AWS благодаря быстрому темпу инноваций, надежности и экономически эффективной производительности. За прошедшие годы компания ESW получила выгоду от роста услуг AWS, что позволило ей преобразовать свой корпоративный портфель в современные облачно-нативные решения. Выпуск AWS Graviton3 позволяет ESW Capital значительно сократить расходы без ущерба для производительности вычислительных рабочих нагрузок.

Централизованное управление техническими продуктами и инженерный подход ESW Capital, направленный на превращение AWS в основное ядро всех продуктов, позволяет компании использовать подавляющее большинство управляемых сервисов AWS в согласованных архитектурах в масштабе.

Как только экземпляры Гравитон2 были выпущены в общую доступность, мы начали переносить рабочие нагрузки на Гравитон2 как по причинам стоимости, так и по причинам производительности, включая контейнеры Kubernetes, функции AWS Lambda и все поддерживаемые Гравитон2 управляемые сервисы AWS во всех его продуктах.

Переход на Гравитон на AWS OpenSearch заключался в простой смене типа экземпляра без изменения каких-либо внешних интерфейсов в большинстве продуктов, что позволило получить немедленную экономическую выгоду.

Выбор языка действительно имеет значение при переходе на процессоры Arm. Для JavaScript/Node.js и не-нод-гип модулей это был просто вопрос запуска этих контейнеров на новой архитектуре, поскольку их базовые среды выполнения уже были совместимы с Arm. Для таких языков, как Go, нам пришлось перекомпилировать код с GOARCH в качестве дополнительного параметра сборки (Примечание: мы настоятельно рекомендуем использовать GO версии 1.18, поскольку она передает аргументы в реестре, а не в стеке, повышая производительность на 15%).

Наш флагманский продукт для оптимизации затрат, CloudFix, используемый в более чем 45 тыс. аккаунтов AWS, предлагает автоматический переход на Гравитон2 для ElasticSearch / OpenSearch, ElastiCache, RDS, включая RDS Aurora, и предложит перейти на Гравитон3, как только он станет общедоступным.

3. DevSpaces

DevSpaces — это веб-среда Visual Studio Code Experience, построенная на базе Gitpod с широкими возможностями совместной работы для всех основных языков программирования, позволяющая быстро докеризировать ваши приложения. Она поддерживает разработку как на базе x86, так и на базе Arm.

Как только мы поняли, что наши приложения переходят на Graviton, мы обнаружили, что в нашем процессе разработки есть большой пробел. Большинство наших разработчиков все еще использовали машины для разработки на базе X86. Нам нужна была среда разработки, которая была бы идентична среде, в которой будут развернуты приложения. DevSpaces для разработки на базе Graviton был создан для устранения этого пробела.

С помощью DevSpaces разработчики могут мгновенно создать стандартизированную среду разработки команды и начать работу всего за несколько минут. Он поддерживает репозитории кода в GitHub, BitBucket или GitLab, а также развертывание в AWS ECS одним щелчком мыши. DevSpaces внутренне использует EKS и отдельные dev-среды как pods — каждому разработчику выделяется один pod в качестве рабочего пространства.

В отличие от vscode.dev, DevSpaces является полноценной заменой рабочего стола, а не просто IDE, и DevSpaces позволяет определить пользовательскую среду разработки со всеми зависимыми пакетами.

Архитектура AWS для DevSpaces выглядит следующим образом:

Базовая архитектура опирается на решение с открытым исходным кодом, которое подключается к существующим системам контроля исходных кодов, адаптированным для AWS:

  • На мета-узле размещаются все службы, необходимые для маршрутизации запросов, аутентификации и выбора ОС.
  • Фактические удаленные среды создаются на рабочих узлах.
  • Для Linux каждая среда разработки получает k8s pod, а для windows — выделенную виртуальную машину. Капсулы для x86, Graviton2, Graviton3 имеют 1 vCPU 2G Ram, максимальное увеличение до 5vCPU 12GB RAM. Это максимальная спецификация, которую выделит kubernetes.
  • Детектор нагрузки проактивно и динамически предсказывает оптимальное количество узлов и масштабирует их по мере необходимости.

4. Миграция DevSpaces на Гравитон

Главный вопрос для тех, кто планирует переход с x86 на Гравитон, заключается в том, будет ли экономия от использования более дешевых экземпляров Гравитон больше, чем инженерные затраты на выполнение перехода.

Как правило, чем большее количество экземпляров x86, подлежащих миграции на Гравитон, тем больше экономия — например, возможно, не стоит переносить приложение, работающее только на одном экземпляре EC2. С другой стороны, чем выше сложность решения, тем больше усилий необходимо приложить для миграции и тем меньше экономия — например, если ваше решение зависит от вручную закодированного ассемблера, внутренних компонентов или нечасто используемых библиотек, затраты на миграцию, скорее всего, будут значительно выше, чем при миграции стандартного приложения на Python, практически не требующего усилий по миграции.

В случае с ESW Capital мы являемся новаторами, поэтому, естественно, мы хотели быть одними из первых, кто попробовал Graviton3. Мы поняли, что количество экземпляров EC2 под управлением x86 было настолько значительным, что миграция большинства наших рабочих нагрузок на «Гравитон» финансово окупилась — экономия составила от 15% до 25% от стоимости экземпляров Intel. В дополнение к очевидным преимуществам в стоимости, удовлетворенность пользователей нашими рабочими нагрузками значительно улучшилась — vCPU Гравитона, являясь физическим ядром, по сравнению с SMT, обеспечивает изоляцию и позволяет избежать распространенных проблем «шумных соседей» в общей инфраструктуре. Обычные жалобы на случайную медлительность в пиковое время никогда не наблюдались в кластерах Гравитон.

4.1. Путешествие миграции в Гравитон2

DevSpaces были переведены на Graviton2, как только он был выпущен в общую доступность и как только мы смогли обеспечить достаточное количество экземпляров Graviton2.

Нашей первоначальной архитектурой был тип экземпляра r5.8xlarge, а целевым экземпляром Graviton был r6gd.8xlarge с настройками 1 vCPU с возможностью увеличения до 5 и 2G RAM с возможностью увеличения до 16G.

Поскольку мы были впереди кривой внедрения Graviton2, мы столкнулись со следующими проблемами, решениями которых мы поделились:

1. Не все компоненты с открытым исходным кодом, от которых мы зависим, имеют сборки Arm.

Например, компонент gRPC в Node.js не имел и все еще не имеет сборки Arm. Поэтому мы портировали его сами и сделали порт с открытым исходным кодом.

2. GitHub Actions, используемые для автоматизации сборок, не поддерживают управляемый Arm.

Чтобы преодолеть это ограничение, есть два возможных решения:

a. Мы можем использовать QEMU for Arm build для сборок C++ или Node-gyp — сравните с этой статьей.

b. Мы можем использовать self-hosted runners для создания сборок.

Мы выбрали второе решение, и наш выбор оказался правильным — сборки стали значительно быстрее.

3. Многоархитектурные сборки Docker

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

4. Создавайте совместимые с Kubernetes (K8S) AMI Ubuntu Arm

Когда мы переносили наши рабочие нагрузки на Graviton2, не было совместимых образов Ubuntu для K8S. Мы предпочитаем Ubuntu, а не Amazon Linux, потому что наше решение использует модуль ядра shifts, отвечающий за uid/gid-shifting для контейнеров. Поэтому мы создали пользовательские AMI Ubuntu, чтобы включить в них изменения shifts. Мы также добавили поддержку contained в docker по умолчанию. Позже AWS добавила этот параметр в качестве опционального.

5. Распараллельте код как можно больше — производительность Graviton3 больше всего проявляется в многопоточном коде.

4.2. Путешествие миграции Гравитон3

Все, что нам действительно нужно было сделать, это изменить типы экземпляров — AMI и образы Docker, созданные для Гравитон2, работали без каких-либо изменений.

5. Бенчмаркинг DevSpaces

DevSpaces очень ценен для бенчмаркинга. Отдельные DevSpaces заключены в контейнеры с жесткими ограничениями на использование вычислительных ресурсов, памяти и хранилища, поэтому если мы протестируем один на Graviton, а другой на x86, мы не сможем уловить системный шум и корректно сравнить архитектуры.

С точки зрения пользователей DevSpaces, единственным значимым показателем является время, сэкономленное на каждой отдельной сборке — чисто процессорные бенчмарки не измеряют улучшения общей производительности. Сэкономленное время имеет существенное значение, поскольку оно выражается в часах в неделю.

Мы измерили время сборки, а также время, необходимое для выполнения ключевых модульных тестов для некоторых из наших наиболее сложных программных решений:

5.1. Sococo

Sococo Backend, приложение на Node.js, представляет собой виртуальную рабочую среду онлайн для распределенных команд.

Общее время сборки решения

  • примерно на 30-35% быстрее на c7g, чем на соответствующем c6g, что приводит к снижению стоимости сборки на 25-30%
  • примерно на 10-20% быстрее на c7g, чем на соответствующем c6i, что на 22-30% дешевле.

Стоимость/производительность

  • 25-30% лучше на c7g по сравнению с соответствующим c6g
  • 22-30% лучше на c7g по сравнению с соответствующим c6i

Заключение: Для приложений Node.js мы рекомендуем использовать инстансы Graviton3 во всех отношениях.

5.2. DevSpaces

DevSpaces, приложение на Go, представляет собой рабочее пространство для разработки программного обеспечения в веб-браузере — обратите внимание, в этом тесте мы использовали DevSpaces для сборки DevSpaces!

Общее время сборки решения

  • примерно на 25-35% быстрее на c7g, чем на соответствующем c6g, что приводит к снижению стоимости сборки на 22-30%
  • примерно на 5-20% быстрее на c7g, чем на соответствующем c6i, что на 18-35% дешевле.

Стоимость/производительность

  • 22-30% лучше на c7g по сравнению с соответствующим c6g
  • 18-35% лучше на c7g по сравнению с соответствующим c6i

Выводы: Для приложений Go мы рекомендуем использовать инстансы Graviton3 во всех отношениях.

Мы не рекомендуем использовать самые крупные экземпляры для создания больших приложений Go, так как время сборки демонстрирует U-образную кривую, вызванную, скорее всего.

  • тем, как Go работает с параллельными сборками
  • тем, как большие экземпляры c7g обрабатывают пропускную способность сети и EBS — экземпляры c7g.medium до c7g.4xlarge имеют базовую пропускную способность для сети и EBS I/O и могут использовать механизм кредита сети / EBS I/O для выхода за пределы базовой пропускной способности на основе наилучших усилий.

6. Извлеченные уроки

  • Обновление с новой версии Гравитона было таким же простым, как и предыдущие обновления, которые мы делали на x86. Как и ожидалось, новые функции и инструкции доступны в новых операционных системах, поэтому при возможности следует перейти на новую версию, например, Ubuntu 22.04, чтобы обеспечить полное использование Гравитон3 во всех рабочих процессах.
  • Хотя Гравитон3 значительно повысил производительность однопоточных приложений по сравнению с Гравитон2, он лучше всего проявляет себя в сильно распараллеленных приложениях. Максимальный уровень распараллеливания определяет оптимальный размер экземпляра — см. кривую Go U, описанную выше.
  • Переход
    — с Гравитон2 на Гравитон3 обеспечивает мгновенное повышение скорости на 20-35% при увеличении стоимости всего на 6%.
    — с c6i на Гравитон 3 обеспечивает мгновенное улучшение скорости на 5-20% и стоит на 20-35% меньше.

  • Соотношение цена/производительность
    — для Гравитон3 по сравнению с Гравитон2 на 22-30% лучше
    — для Гравитон3 по сравнению с c6i на 18-35% лучше.

7. Резюме

Основной ценностью DevSpaces является предоставление наилучшей среды разработки для создания и тестирования сложных программных решений, работающих в AWS. Мы получили самые глубокие знания обо всех различных компиляторах, используемых в DevSpaces, чтобы направить каждый конкретный язык в капсулу с наиболее оптимальным типом процессора.

После более чем четырех месяцев всестороннего тестирования инстансы c7g положительно потрясли нас отзывчивостью и производительностью DevSpaces.

Мы собираемся перевести все наши производственные системы на c7g, как только он станет общедоступным».

Оцените статью
Procodings.ru
Добавить комментарий