AWSコンテナサービスによるAWS Gravitonへの移行

Pulisher : Cloud Technology Center イ・ヨンジン
Description：Gravitonを利用し、containerサービスの構成とマイグレーション方法の紹介及びサムスンTVのGraviton適用事例の紹介セッション

はじめに

エネルギー対性能に優れ、炭素排出量においてもIntel/AMDなどのx86 CPUとは比較にならないほど地球に優しいCPUであるGravitonを利用して、containerサービスをどのように構成し、マイグレーションが可能なのか知りたいと思いました。 また、サムスンTVのGraviton活用事例を通じて、他のお客様にマイグレーションジャーニーにおける方向性を提示するために本セッションを申し込みました。

セッションの概要紹介

AWS Gravitonでコンテナを実行する方法についてのセッションでした。AWS Gravitonは、64ビットARMプロセッサコアを使用するAWSのカスタムシリコンです。 このセッションでは、AWS Gravitonへの移行の様々な側面、特にコスト削減、コストパフォーマンスの向上、持続可能な目標の達成に役立つエネルギー使用量の削減などの利点について説明しました。

また、x86とGravitonベースのインスタンスの両方にデプロイできるように、マルチアーキテクチャをサポートするためのコンテナイメージの構築プロセスも紹介されました。 また、Gravitonの主要なコンテナオーケストレーターとランタイムがGravitonをサポートしているため、さまざまなワークロードにカスタマイズして適用できることがわかりました。

Gravitonは64bit ARM architectureを持つCPUです。チップの設計において、顧客のフィードバックと開発者の協力により、継続的に発展しているそうです。

Gravitonを利用する理由は様々ありますが、要約すると以下のスライドのようになります。 仮想化ではなく、実際のcoreであり、汎用的な活用においては最も優れた性能を保証してくれます。 また、AWSの自社生産CPUであるため、Intel/AMDのように高価に購入する必要がなく、ARMの特徴である低消費電力設計により、他のCPUと比較して最大60%以上のエネルギー対効率を誇ります。

すでにGravitonは、メインのcontainer / orchestratorでサポートしており、環境が成熟しています。

CPU instanceで駆動されるAWSサービス – EC2, ECS, Fargate, Lambdaなどは、すでにGravitonが問題なく駆動できるように検証済みです。

Gravitonのバージョンは初期バージョン以降、2 > 3 > 3Eと発展してきており、今回の2023 re:Invent KeynoteでGravitonの最新型である4が発表されました。 様々な活用度によって各バージョンでも用途が分かれています。

特に、containerサービスでは、簡単に適用できるように、Graviton用の画像も作成できます。

Graviton用のコンテナイメージを作成し、アプリケーションが最適化された状態で回すことができます。

Gravitonインスタンス上でイメージを作成することができます。ARM系であるMacも同じです。

BuildKitを利用してx86ホストインスタンスでもarm64/aarch64イメージも生成できます。この方式はエミュレーション方式だと考えてください。

まだx86であるコンテナと、新しく開発されたARM系コンテナが混在して使用される場合、Multi-architecture方式を利用することで、同時に二つのCPUアーキテクチャで作られたコンテナ環境も制御することができます。

まず必要なのは、各CPU architectureに使用するイメージを登録します。 そして、multi-arch manifestを作成します。

ARMネイティブホストではなく、x86でビルドを構成する時は、必ずarm64オプションを入れなければ、二つのバージョンでビルドが行われます。

画像登録において重要なのは、画像の名前にpostfix形式でCPU architectureを明示する必要があります。

最後にMulti-archマニフェストファイルを使って、image buildが実行されると、それぞれのimageが自動生成されます。

全体的なDevOpsの流れは次のようになります。EKSではCodePipeline parameterを利用して区分して配布できるようにオプションが用意されています。CPU architectureだけが違うだけなので、既存に活用されている色んなパイプラインサービスをそのまま活用することができます。

DevOps分野で活用されるほぼすべてのサービスは、すでにGravitonをサポートしています。

ECSおよびEKSでGraviton containerを活用することは、ネイティブAWSで最も簡単な方法です。

特に、ECS > Fargateを利用した方法は、Graviton containerを活用する上で、最もアクセスしやすい方法です。 また、クラスター構成において、x86とGravitonを同時に選択することができます。

Fargateの設定におけるARM64の設定方法です。

最終的にcpu-architectureにおいてarm64であることを定義します。

Fargateの場合はECSを通して設定すればいいし、EKSの場合はKarpenterを活用するのが一番簡単に活用できるそうです。EKSを使うと良い点はx86とGravitonを同時に設定することができます。

もしかしたら、参考になるようにEKSでGravitonの設定を入れる章表を共有します。 nodeSelectorの部分です。

EKSでnodeAffinityを設定する部分です。

Karpendter上でarm64とamd64を区別してMulti-architectureを実装しました。

ECSとEKSを活用した場合、ディストリビューションコントローラをどのようにするかを示す長表になります。

最後に、サムスン電子のサムスンTVプラットフォームをGravitonに移行した事例です。

サムスン電子は、サムスンのスマートフォン連動のGalaxy Storeだけでなく、TVとGaming Hubを通じたエンターテイメント事業があります。

サムスンのデバイスを持っていれば、テレビやモバイルデバイスで無料で利用できるそうです。

では、なぜサムスンTVがGravitonを選んだのでしょうか？他のお客様と同じように、コスト最適化、コスト対性能の最適化、そして最新技術の導入がその理由だそうです。 さらに、ARMを選択することで、炭素排出抑制にも参加することができます。

AWS nativeサービスはすでにGraviton readyな状態です。そのようなmanaged serviceはすぐに移行が可能で、残りのEC2 instanceやEKS/ECS系列の変更計画を立てて、段階的に移行する必要があります。

Migration 順序は、Gravitonでもアプリケーションがうまく動作することを確認し、必要に応じてコードを修正する過程を持ち、Intel/AMD系列と混用して活用される場合、Multi-arch manifestを利用した配布計画を立てる過程が必要です。 その後は、実際に配布してみながらトラブルシューティングをする全体のプロセスになります。

前述したように、すでにOpen Source陣営ではARMが普及しているので、ARMベースのOSを使う上で特別なことはなく、updateなども一般的なyum/apt-getコマンドで可能です。 特定のCPU architectureに依存性がある場合は、その部分については別途検証が必要です。

Docker buildxやQEMUなどを利用して、マルチプラットフォーム用のイメージをビルドします。

マイグレーション自体は、一般的なマイグレーションと同じように、blue/greenまたはweighted routingなどのテクニックを使用します。

Applicationマイグレーション進行時、CPU100%の問題があったそうです。 一般的に取れるJavaのバージョンを最新に少しずつ上げてみて、rebootingで解決しましたが、この方法も定期的にやらなければならないので、完全な解決にはならなかったそうです。

結局、Java machine関連のparameterから”-XX:+useContainerSupport”を削除した後、安定的に動作できるようになったそうですね。 このように、まだ広く知られていない部分も存在し、troubleshootingが必要であることを認識する必要がありそうです。

Gravitonへの移行後、その効果は飛躍的で、APIでは48.2%の反応速度向上と15%のコスト最適化を、その結果として実現したそうです！

一度Gravitonの効果を見た後、サムスンTVに限らず、Gaming Hubも徐々にGraviton migrationを計画しているそうです。

セッションを終えて

AWS Gravitonを利用してコンテナイメージをデプロイする方法 – EKSも可能であり、特にAWS Fargateを使用して、より簡単で効率的な経験を提供する方法についても取り上げられました。 このセッションでは、サムスン電子の事例も含まれており、Gravitonに移行することで得られた経験と利点が語られました。 その利点は、コストに対して高性能を得ることができたというのが主な骨子です。

この発表では、会社の各組織がAWS Gravitonにコンテナワークロードを移行する過程において、技術的な詳細 – ベストプラクティスや実際の事例などを提示することで、決して難しいことではないことを示しました。

ちなみに、サムスンTVはこのすべての過程を経て、今はAll Gravitonシステムと呼ばれています！

参考
・Build multi-arch images with GitLab Runners with Amazon EKS
・https://aws.amazon.com/ko/blogs/devops/unlock-the-power-of-ec2-graviton-with-gitlab-ci-cd-and-eks-runners/
・Run containers with AWS Graviton on AWS Fargate
・https://aws.amazon.com/ko/blogs/aws/announcing-aws-graviton2-support-for-aws-fargate-get-up-to-40-better-price-performance-for-your-serverless-containers/
・Build multi-arch containers and save with Graviton and Spot instances on Amazon ECS
・https://aws.amazon.com/ko/blogs/containers/how-to-build-your-containers-for-arm-and-save-with-graviton-and-spot-instances-on-amazon-ecs/
・Create multi-architecture Docker images to support Graviton using AWS CodeBuild and AWS CodePipeline
・https://aws.amazon.com/ko/blogs/devops/creating-multi-architecture-docker-images-to-support-graviton2-using-aws-codebuild-and-aws-codepipeline/