ECS Express ModeがARM64に対応
Amazon ECS Express Modeで、サービスのCPUアーキテクチャとしてARM64を指定できるようになりました。これにより、ARMベースのコンテナイメージをAWS Gravitonプロセッサ上で実行できます。
ECS Express Modeは、コンテナイメージを指定するだけで、コンテナ化したWebアプリケーションやAPIに必要なクラウド構成をまとめて用意する機能です。ネットワーク、ロードバランシング、オートスケーリング、デプロイ設定などを管理し、アプリケーションには自動生成URLが提供されます。
今回のARM64対応により、開発者は既存のx86環境を使い続けるだけでなく、Gravitonを選択してコストと性能のバランスを見直せるようになりました。AWSの発表では、x86ベースのインスタンスと比較して、最大40%の価格性能向上が示されています。ただし、実際の効果はアプリケーションの負荷、利用するAWSサービス、コンテナイメージ、ライセンス費用などによって変わります。
まず理解したいARM64とx86の違い
コンテナはアプリケーションを隔離して実行しますが、CPUアーキテクチャまで吸収するものではありません。x86向けにビルドされたバイナリやネイティブライブラリは、ARM64環境ではそのまま実行できない場合があります。
特に注意が必要なのは、次のような構成です。
- CやC++でビルドされたネイティブライブラリを利用しているアプリケーション
- データベースドライバや画像処理ライブラリなど、OS依存のバイナリを含むイメージ
- 起動時に外部コマンドを呼び出すアプリケーション
- x86_64専用の監視エージェントやセキュリティエージェント
- 実行環境を固定したサードパーティ製のコンテナイメージ
- Java Native Interface（JNI）や独自のネイティブ拡張を利用するアプリケーション
一方、JavaやGo、Node.js、Pythonなどのアプリケーションでも、実行時に利用するライブラリやベースイメージにネイティブコードが含まれることがあります。プログラミング言語だけを見て互換性を判断するのではなく、コンテナの中身全体を確認することが重要です。
ARM64対応コンテナイメージをビルドする
Docker Buildxを利用すると、ARM64向けのイメージをビルドできます。ARM64環境で直接ビルドできる場合は、次のように指定します。
docker buildx build \\
--platform linux/arm64 \\
-t <registry>/<repository>:arm64 \\
--push .
x86環境からARM64向けイメージを作成する場合、Buildxのエミュレーションを利用する構成もあります。ただし、ネイティブビルドと比べてビルド時間や、ビルド対象によっては互換性に差が出る可能性があります。CI/CDパイプラインでは、ARM64のビルドランナーを利用する方法も選択肢になります。
x86とARM64の両方で同じイメージ名を使いたい場合は、マルチアーキテクチャイメージを作成できます。
docker buildx build \\
--platform linux/amd64,linux/arm64 \\
-t <registry>/<repository>:latest \\
--push .
マルチアーキテクチャイメージでは、実行環境に応じて対応するイメージが選択されます。x86とARM64のサービスを並行して運用したい場合や、開発環境と本番環境のCPU構成が異なる場合に適しています。
ただし、単に--platformを追加するだけでは不十分です。Dockerfile内で取得するバイナリ、パッケージマネージャーがインストールする依存関係、ビルドスクリプトが生成する成果物も、対象アーキテクチャに対応している必要があります。
Spring BootやJava APIで確認するポイント
Spring BootのようなJavaアプリケーションは、JVMと依存ライブラリがARM64に対応していれば、比較的移行しやすいワークロードです。一般的なWeb APIでは、次のような構成を確認します。
- ARM64対応のJDKを含むベースイメージを利用する
- JDBCドライバなどの依存関係がARM64実行を妨げないことを確認する
- JNIを使うライブラリがある場合はARM64版の提供状況を確認する
- 起動オプションやヒープサイズを新しい実行環境で再評価する
- 負荷試験でレイテンシー、スループット、コンテナのCPU使用率を比較する
たとえば、アプリケーションコードが純粋なJavaで構成され、標準的なHTTP処理とデータベースアクセスを中心とするAPIであれば、ARM64化の主な作業はイメージのビルドとテストになる可能性があります。一方、画像変換、暗号処理、機械学習推論、圧縮処理などCPUやネイティブライブラリに依存する処理では、性能と互換性を個別に評価すべきです。
ECS Express ModeでARM64を選ぶ流れ
ECS Express Modeの新規サービスおよび既存サービスでは、CPUアーキテクチャを設定できます。設定手段は次のとおりです。
- AWS Management Console
- AWS CLI
- AWS SDK
- Infrastructure as Code（IaC）ツール
実際の導入では、次の順序で進めると安全です。
- ARM64向け、またはARM64を含むマルチアーキテクチャのイメージを作成する
- 開発・検証用のECS Express ModeサービスでARM64を指定する
- アプリケーションの起動、ヘルスチェック、外部接続を確認する
- x86環境と同じ条件で負荷試験を実施する
- ログ、メトリクス、エラー率、レイテンシーを比較する
- 問題がなければ本番サービスの切り替え計画を立てる
設定をIaCで管理している場合は、CPUアーキテクチャをコードに明示し、レビューや変更履歴を残せるようにすることが重要です。コンソール上で変更した内容がIaCの定義とずれると、次回のデプロイで意図せず設定が戻る可能性があります。
既存サービスを移行するときの注意点
既存のx86サービスをARM64へ移行する場合、アプリケーションの変更だけでなく、デプロイと切り戻しの設計も必要です。
イメージタグを分ける
最初から既存のタグを上書きするのではなく、検証用にARM64専用タグを用意すると、問題が発生した際に切り戻しやすくなります。マルチアーキテクチャイメージを利用する場合でも、リリース単位で不変のタグやダイジェストを管理すると、実行イメージを追跡しやすくなります。
依存サービスとの境界を確認する
アプリケーションがARM64で動作しても、周辺の処理がx86専用とは限りません。バッチ、ワーカー、監視エージェント、CI/CDのビルド環境などを含めて、システム全体のアーキテクチャを確認します。
特に、APIと非同期ワーカーで異なるイメージを使っている場合、一方だけをARM64化すると、キュー処理やイベント連携の部分で問題が発生することがあります。
性能をCPU使用率だけで判断しない
Graviton移行の効果は、単純なCPU使用率だけでは評価できません。次の指標をx86環境と比較します。
- リクエストあたりのレイテンシー
- 1秒あたりの処理件数
- コンテナの再起動回数
- メモリ使用量とガベージコレクションの状況
- エラー率とタイムアウト率
- リクエストまたは処理件数あたりのコスト
アプリケーションがCPU処理を多く消費するほど、価格性能差が効果として表れやすい傾向があります。一方、外部APIやデータベースの待ち時間が支配的なアプリケーションでは、CPUアーキテクチャを変更しても全体の性能改善が限定的になる可能性があります。
Graviton化と相性がよいワークロード
ARM64への移行効果を検討しやすいのは、次のようなワークロードです。
- コンテナ化されたREST APIやバックエンドAPI
- ステートレスなWebアプリケーション
- 高い同時実行数が必要なHTTPサービス
- キューからメッセージを取り出して処理するワーカー
- 定期的に実行するバッチ処理
- Java、Go、Node.jsなどで構成された標準的なアプリケーション
反対に、ARM64対応が難しい可能性があるのは、x86専用のバイナリやドライバに依存するシステムです。移行を急ぐよりも、まずコンテナイメージの依存関係を整理し、マルチアーキテクチャ化できる部分から段階的に進める方が現実的です。
ECS Express Modeとの組み合わせで得られる価値
ECS Express Modeのメリットは、コンテナ基盤の設定を簡略化しながら、実行アーキテクチャを選択できる点にあります。ネットワーク、ロードバランシング、オートスケーリングなどを個別に構築する負担を抑えつつ、ワークロードに応じてx86とARM64を使い分けられます。
特に、次のようなチームでは検討しやすい機能です。
- インフラ構築よりもアプリケーション開発に集中したいチーム
- 小規模なAPIを短期間で公開したいチーム
- 既存サービスの一部だけでGravitonの効果を検証したいチーム
- IaCやCLIで環境を再現可能に管理しているチーム
ただし、Express Modeを利用していても、コンテナイメージの互換性やアプリケーションの性能検証まで自動化されるわけではありません。抽象化されたインフラ設定と、アプリケーション側の移行作業を分けて考える必要があります。
まとめ
ECS Express ModeのARM64対応によって、コンテナイメージを用意できる開発者は、より少ないインフラ設定でAWS Gravitonを試せるようになりました。AWSが示す最大40%の価格性能向上は魅力的ですが、移行の成否を決めるのは、ARM64対応イメージの準備と実ワークロードでの検証です。
実務では、次の方針が有効です。
- Docker BuildxでARM64またはマルチアーキテクチャイメージを作成する
- ネイティブライブラリや外部エージェントの対応状況を確認する
- 検証環境でx86とARM64の性能・安定性を比較する
- IaCにCPUアーキテクチャを明示する
- タグやダイジェストを管理し、切り戻し手順を用意する
- CPUだけでなく、レイテンシーと処理単価で効果を評価する
まずはステートレスなWeb APIや標準的なJavaアプリケーションなど、移行リスクの低いサービスから試すのがよいでしょう。ECS Express Modeの簡便さとGravitonの価格性能を組み合わせることで、コンテナ基盤の運用負担と実行コストの両方を見直すきっかけになります。
出典： AWS What’s New