AWS Gravitonは、AWSが独自に開発したArm系プロセッサです。Graviton2 (2019年)、Graviton3 (2021年)、Graviton4 (2023年) と世代を重ね、現在では多くのインスタンスファミリーで選択可能となっております。

「Gravitonに移行するとコストが20%下がる」という記述はよく目にしますが、実際の移行で得られる効果は、ワークロードの特性により大きく異なります。本記事では、当社が直近一年間でご支援した複数のGraviton移行プロジェクトから、現実的な数値感を共有いたします。

01. 計測対象としたワークロード

本記事で扱う実測値は、以下の四つのワークロードを対象としております。すべて本番環境または本番相当の負荷条件下での観測値です。

02. 性能の実測値

x86系の同等インスタンス (m6i, c6i, r6i) からGraviton3系 (m7g, c7g, r7g) へ移行した際の処理性能を計測いたしました。同一の負荷条件下で、リクエストスループットまたはバッチ完了時間を比較しております。

JavaやNode.jsなどのマネージドランタイムを使うワークロードでは、おおむね10%から20%の性能向上が見られました。一方、CPU依存度の高い数値計算系ワークロードでは、性能改善が限定的なケースもございます。

機械学習推論については、フレームワーク側のArm対応の成熟度が結果に大きく影響します。PyTorchはArm向け最適化が進んでいる一方、特殊なライブラリを使う場合、x86系の方が高速なケースもございます。事前の性能計測は必須です。

03. コストの実測値

同等性能・同等可用性を確保するために必要なインスタンス費用の比較です。スループット改善分を含めた実効コストとしての値です。

カタログ単価が約20%低いことに加え、性能向上分が乗算されるため、ワークロードによっては30%以上のコスト削減を達成しております。

04. 運用面で実際に直面した課題

性能とコストの観点では明確な優位性があるGravitonですが、移行プロジェクトの現場では、いくつかの運用課題に直面しました。

ベースイメージのマルチアーキ対応

独自のDockerベースイメージを使用している場合、これをマルチアーキ (linux/amd64 + linux/arm64) でビルドする必要があります。CIパイプラインの修正が必要であり、ビルド時間も増加します。docker buildxと --platform オプションを使用した二重ビルドの整備が必要です。

サードパーティ製ライブラリの互換性

ネイティブバイナリを含むライブラリ (例: 一部のデータベースドライバ、画像処理ライブラリ) では、Arm版が提供されていない、または最新版のみがArm対応というケースがございます。依存ライブラリの棚卸しを移行計画の最初に行うことを強くお勧めいたします。

パフォーマンスプロファイリングツールの再習熟

x86系で使い慣れたプロファイリングツール (perf, flamegraph等) は、Arm環境でも動作はいたしますが、解釈のノウハウは別途必要となります。アーキテクチャ固有のパフォーマンス特性 (キャッシュ階層、SIMD命令等) を理解した上での分析が求められます。

05. 移行の進め方の推奨

当社がお勧めする移行ステップは以下の通りです。

  1. 互換性調査: 依存ライブラリのArm対応状況の調査(数日〜1週間)
  2. パイロット選定: ステートレスで影響範囲の小さいサービスを一つ選定
  3. マルチアーキビルド整備: CIパイプラインを修正し、両アーキのイメージを生成可能にする
  4. パイロット移行: 段階的なトラフィック移行 (10% → 50% → 100%) と監視
  5. 本番ワークロード展開: パイロットで得られた知見を横展開

パイロット選定から本番完了まで、典型的な期間は2ヶ月から4ヶ月です。技術的な難易度よりも、組織内の合意形成と検証期間の確保が時間を要するケースが多いと感じております。

まとめ

AWS Gravitonへの移行は、多くのワークロードで明確なコスト削減効果が期待できる選択肢です。ただし、ライブラリ互換性とビルド体制の整備という前提条件が必要であり、これらを軽視するとプロジェクトが長期化いたします。

Graviton移行のPoCご支援、依存関係の調査、ビルド基盤の整備につきましては、お問い合わせフォームよりお気軽にご連絡くださいませ。

中
中島 慎一
CEO / Founding Engineer