CPUとは比較にならないほど地球に優しいCPUであるGravitonを利用して、containerサービスをどのように構成し、マイグレーションが可能なのか知りたいと思いました。サムスンTVのGraviton活用事例を通じて、他のお客様にマイグレーションジャーニーにおける方向性を提示するために本セッションを申し込みました。Gravitonでコンテナを実行する方法についてのセッションでした。Gravitonは、64ビットARMプロセッサコアを使用するAWSのカスタムシリコンです。Gravitonへの移行の様々な側面、特にコスト削減、コストパフォーマンスの向上、持続可能な目標の達成に役立つエネルギー使用量の削減などの利点について説明しました。x86とGravitonベースのインスタンスの両方にデプロイできるように、マルチアーキテクチャをサポートするためのコンテナイメージの構築プロセスも紹介されました。Gravitonの主要なコンテナオーケストレーターとランタイムがGravitonをサポートしているため、さまざまなワークロードにカスタマイズして適用できることがわかりました。architectureを持つCPUです。チップの設計において、顧客のフィードバックと開発者の協力により、継続的に発展しているそうです。Gravitonを利用する理由は様々ありますが、要約すると以下のスライドのようになります。仮想化ではなく、実際のcoreであり、汎用的な活用においては最も優れた性能を保証してくれます。AWSの自社生産CPUであるため、Intel/AMDのように高価に購入する必要がなく、ARMの特徴である低消費電力設計により、他のCPUと比較して最大60%以上のエネルギー対効率を誇ります。orchestratorでサポートしており、環境が成熟しています。Lambdaなどは、すでにGravitonが問題なく駆動できるように検証済みです。KeynoteでGravitonの最新型である4が発表されました。様々な活用度によって各バージョンでも用途が分かれています。containerサービスでは、簡単に適用できるように、Graviton用の画像も作成できます。Graviton用のコンテナイメージを作成し、アプリケーションが最適化された状態で回すことができます。Gravitonインスタンス上でイメージを作成することができます。ARM系であるMacも同じです。BuildKitを利用してx86ホストインスタンスでもarm64/aarch64イメージも生成できます。この方式はエミュレーション方式だと考えてください。x86であるコンテナと、新しく開発されたARM系コンテナが混在して使用される場合、Multi-architecture方式を利用することで、同時に二つのCPUアーキテクチャで作られたコンテナ環境も制御することができます。architectureに使用するイメージを登録します。manifestを作成します。ARMネイティブホストではなく、x86でビルドを構成する時は、必ずarm64オプションを入れなければ、二つのバージョンでビルドが行われます。architectureを明示する必要があります。buildが実行されると、それぞれのimageが自動生成されます。全体的なDevOpsの流れは次のようになります。parameterを利用して区分して配布できるようにオプションが用意されています。architectureだけが違うだけなので、既存に活用されている色んなパイプラインサービスをそのまま活用することができます。DevOps分野で活用されるほぼすべてのサービスは、すでにGravitonをサポートしています。containerを活用することは、ネイティブAWSで最も簡単な方法です。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に移行した事例です。Hubを通じたエンターテイメント事業があります。サムスンのデバイスを持っていれば、テレビやモバイルデバイスで無料で利用できるそうです。サムスンTVがGravitonを選んだのでしょうか?他のお客様と同じように、コスト最適化、コスト対性能の最適化、そして最新技術の導入がその理由だそうです。ARMを選択することで、炭素排出抑制にも参加することができます。readyな状態です。instanceやEKS/ECS系列の変更計画を立てて、段階的に移行する必要があります。manifestを利用した配布計画を立てる過程が必要です。その後は、実際に配布してみながらトラブルシューティングをする全体のプロセスになります。Source陣営ではARMが普及しているので、ARMベースのOSを使う上で特別なことはなく、updateなども一般的なyum/apt-getコマンドで可能です。architectureに依存性がある場合は、その部分については別途検証が必要です。buildxやQEMUなどを利用して、マルチプラットフォーム用のイメージをビルドします。routingなどのテクニックを使用します。Applicationマイグレーション進行時、CPU100%の問題があったそうです。一般的に取れるJavaのバージョンを最新に少しずつ上げてみて、rebootingで解決しましたが、この方法も定期的にやらなければならないので、完全な解決にはならなかったそうです。machine関連のparameterから”-XX:+useContainerSupport”を削除した後、安定的に動作できるようになったそうですね。このように、まだ広く知られていない部分も存在し、troubleshootingが必要であることを認識する必要がありそうです。migrationを計画しているそうです。Fargateを使用して、より簡単で効率的な経験を提供する方法についても取り上げられました。このセッションでは、サムスン電子の事例も含まれており、Gravitonに移行することで得られた経験と利点が語られました。その利点は、コストに対して高性能を得ることができたというのが主な骨子です。ベストプラクティスや実際の事例などを提示することで、決して難しいことではないことを示しました。