AWS Compute Vol2 — Graviton4/最新世代EC2/arm64移行

1. 最新世代コンピュート選定の課題とGraviton4全体像

1-1. 本番現場での最新世代移行課題

クラウドインフラの設計において、EC2インスタンスの世代選定は性能・コスト・保守性を左右する重要な意思決定です。多くの本番環境では、c5やm5などの旧世代インスタンスが依然として稼働し続けており、その背景には世代移行を阻む3つの課題があります。

x86アーキテクチャの技術的負債

2010年代前半から稼働するx86ベースのワークロードは、OS設定・ミドルウェア依存・コンパイル済みバイナリなど、アーキテクチャに強く依存した構成を持っていることがあります。特に、SSE4.2やAVX2などのx86固有の命令セットを直接活用するライブラリや、C言語で記述された拡張モジュールを持つアプリケーションでは、arm64への移行前に動作検証と再ビルドが不可欠です。この「見えない依存」が移行計画を複雑にしています。

RubyやPythonのネイティブ拡張（gem/Cextension）、Javaのネイティブライブラリ（JNI）、古いバージョンのMySQLクライアントライブラリなど、アーキテクチャ固有のバイナリが混入しているケースでは、ビルド環境の整備から着手する必要があります。依存ライブラリのarm64対応状況を一括スキャンするには、後述のGraviton Porting Advisorが有効です。

arm64互換性の不確かさ

arm64（AArch64）への移行に際して、依存するOSS・ライブラリ・内製コードがarm64でビルドできるかどうかを事前に確認するコストが発生します。Javaなど仮想マシン上で動作する言語は比較的互換性が高い一方、ネイティブ拡張を持つPython CextensionやC言語で実装されたデータベースドライバは、arm64向けのビルドが提供されていない場合もあります。AWS Graviton Porting Advisorなどのツールでスキャンできるものの、最終的には実環境でのテストが判断基準となります。

パッケージリポジトリがarm64バイナリを提供していない場合は、ソースからビルドするか、コンテナイメージをマルチアーキテクチャ対応に切り替える必要があります。このような互換性の不確かさが、移行判断を先送りにする主要因のひとつとなっています。

移行コストと人的リスク

x86からarm64へのCI/CDパイプラインの整備、Dockerイメージのマルチアーキテクチャ対応、本番テスト環境の構築など、移行に伴う一時的なエンジニアリングコストは無視できません。「性能が上がる」「単価が下がる」という期待効果が見えていても、移行作業の工数見積もりが難しいため、現状維持を選択する組織が多く存在します。

また、移行後の本番稼働において性能劣化やエラーが発生したときのロールバック計画が不明確なままでは、リスクを取りにくい状況が続きます。本記事では、段階移行とロールバック設計を含む安全な移行手順を§6で詳述します。

1-2. Graviton4と最新世代EC2が提供する解決アプローチ

AWSは2024年末から2025年にかけて、Graviton4プロセッサを搭載した第8世代インスタンスファミリー（C8g/M8g/R8g/X8g）を順次リリースしました。これらのインスタンスは、Graviton3世代と比較して最大30%の性能向上を実現し、東京リージョン（ap-northeast-1）でも以下のとおり提供されています。

Graviton4の性能向上は、コア数の増加・LLC（Last Level Cache）の大幅拡張・メモリ帯域幅の強化によって実現されています。特にR8gは、メモリ集約型ワークロードにおいてGraviton3比で顕著な性能改善が期待でき、Amazon RDS for PostgreSQLやElasticsearchなどの本番DBワークロードに適しています。

最新Nitro Systemとの組み合わせにより、これらのインスタンスはハイパーバイザーのオーバーヘッドを排除した直接ハードウェアアクセスを実現し、ネットワーク・ストレージ性能においても大幅な向上をもたらしています。

1-3. 主要な解決技術の概要

本Vol2では、x86→arm64移行の課題に対して、以下の技術的アプローチを体系的に解説します。

docker buildxによるマルチアーキテクチャビルド

docker buildx build --platform linux/amd64,linux/arm64によるマルチプラットフォームイメージのビルドは、x86環境とarm64環境を並行運用する移行期間中に有効なアプローチです。既存のCI/CDパイプラインにplatformフラグを追加するだけで、単一のDockerfileから両アーキテクチャ向けのイメージを生成でき、ECRへのプッシュもDockerマニフェストとして一元管理できます。コンテナ化が進んでいる組織では、これが最も迅速に移行効果を得られる手段のひとつです。

AWS Graviton Porting Advisorによる事前評価

Porting Advisorは、移行対象のコードベースをスキャンし、arm64に対応していない依存関係や、移行に注意が必要なコードパターンを事前に特定します。Python・Java・C/C++・Go・.NETプロジェクトに対応しており、移行の工数見積もりに活用できます。GitHubのaws/aws-graviton-getting-startedリポジトリで公開されており、Dockerコンテナとして実行可能です。

EKS KarpenterによるGravitonノード管理

EKSクラスター上でGravitonノードを効率的に活用するには、Karpenterのノードプール設定でarm64アーキテクチャを指定することが有効です。x86とarm64の混在クラスターを構成することで、Graviton非対応のワークロードはx86ノードへ、対応済みのワークロードはGravitonノードへとスケジューリングを自動化できます。段階移行においても、Karpenterのweightパラメーターを調整するだけで比率を柔軟に制御できます。

1-4. 東京リージョンでの利用可否

日本のユーザーが本番環境でGraviton4を活用できるかどうかは、東京リージョン（ap-northeast-1）でのGA状況に依存します。本記事執筆時点での確認情報は以下のとおりです。

• R8g: 2024年12月に東京リージョンでGA。メモリ最適化ワークロード向けに本番利用可能です。
• C8g: 2025年3月に東京リージョンでGA。コンピュート最適化ワークロード向けに本番利用可能です。
• M8g/X8g: 2025年以降に順次展開予定。最新の提供状況はAWS公式ドキュメントで確認してください。

東京リージョンでのGA確認には、AWS Management Consoleのインスタンスタイプ一覧か、AWS CLIのec2 describe-instance-typesコマンドを利用すると確実です。

aws ec2 describe-instance-types \
  --filters "Name=instance-type,Values=r8g.*" \
  --query "InstanceTypes[].{Type:InstanceType,Arch:ProcessorInfo.SupportedArchitectures}" \
  --region ap-northeast-1

上記コマンドで結果が返ればそのインスタンスタイプは当該リージョンで利用可能です。結果が空の場合は、まだ提供されていないか、インスタンスタイプ名の確認が必要です。提供リージョンは随時拡大されているため、定期的な確認をお勧めします。

1-5. 本記事の構成（8セクション概要）

本記事は以下の8セクションで構成されており、Graviton4と最新世代EC2の活用を体系的に習得できる構成となっています。

Vol2の位置づけは「最新世代の技術選定と移行」です。EC2の基礎概念やAutoScalingの設計パターンについては、コンピュート本番運用Vol1を参照してください。また、Savings PlansやRI最適化などコスト管理の手法については、コスト最適化Vol2で体系的に解説しています。本記事はこれら2記事の先にある「最新世代をどう選び、どう移行するか」という技術選定と移行実践に特化しています。

1-6. 本記事の対象読者

本記事は以下の読者を対象としています。

主な対象読者

• AWSの本番環境でEC2を運用しており、旧世代インスタンスからの移行を検討しているインフラエンジニア
• コンテナ（EKS/ECS）ワークロードをGraviton4に最適化したいSREエンジニア
• Graviton4の性能を社内で評価・提案したいアーキテクト
• arm64移行の工数見積もりと段階的な移行計画を立てたいプロジェクトマネージャー

本記事を読み終えると、Graviton4の東京リージョン対応状況の確認方法・マルチアーキテクチャビルドの実装・段階移行手順とロールバック設計・CloudWatchを活用した監視設計が実践できるようになります。

前提知識

EC2インスタンスの基本（インスタンスタイプ選定・起動テンプレート・AutoScaling）を理解していることを前提とします。Dockerビルドの基礎知識があると、§3・§5の内容をよりスムーズに理解できます。Kubernetes/EKSの経験がある場合は§5のKarpenter設定がそのまま活用できます。

1-7. Graviton4移行の期待効果と注意点

Graviton4移行の期待効果は以下のとおりです。

期待効果

• 性能向上: Graviton3比最大30%の性能向上（ワークロードにより異なります）
• 電力効率: arm64アーキテクチャはx86と比べてワット当たり性能が高く、同等の処理量を少ない消費電力で実現します
• コスト効率: Graviton世代のインスタンスは同等のx86インスタンスと比べてコスト効率に優れる場合があります（公式料金ページで最新単価を確認してください）
• エコシステムの充実: Graviton3以降、多くのOSSがarm64ビルドを公式サポートしており、移行の障壁は低下し続けています

注意点

• 「最大30%向上」はすべてのワークロードに適用されるわけではありません。x86固有の最適化が施されたコードやx86専用バイナリが含まれる環境では、性能が期待を下回る場合があります。
• arm64に対応していない商用ソフトウェア（ライセンス版のデータベースエンジンや独自コーデックなど）は移行対象外となります。事前の互換性調査が不可欠です。
• 移行後は性能ベンチマークを取得し、x86との比較結果を記録してください。継続的な測定が移行効果の定量評価につながります。

2. Graviton4インスタンスファミリー

2-1. Graviton世代の歴史と進化

AWSが独自設計したGravitonプロセッサは、2018年の初代リリースから継続的に進化を重ねてきました。各世代の主要仕様と改善ポイントを整理します。

Graviton1 (2018年)

AWS初のカスタムARMプロセッサです。16コアのArmv8-Aアーキテクチャを採用し、A1インスタンスとして提供されました。主にWebサーバーやコンテナ環境のワークロードをターゲットとしており、AWSが独自シリコンを本格展開する上での重要な第一歩となりました。

Graviton2 (2020年)

Graviton2ではコア数が64コアに大幅増加し、Armv8.2-Aアーキテクチャへと進化しました。C6g/M6g/R6g/T4gといった主要インスタンスファミリーに搭載され、同価格帯のx86インスタンスと比較してコストパフォーマンスが最大40%向上しました。DDR4メモリとPCIe 4.0をサポートし、本格的な本番ワークロードへの採用が広がりました。Java・Python・Goといったランタイムのarm64最適化が進んだことで、ソフトウェアエコシステムの対応が充実し始めました。

Graviton3 (2022年)

Graviton3では64コアを維持しながらSVE (Scalable Vector Extension) をサポートしました。C7g/M7g/R7gとして提供され、DDR5メモリもサポートしています。機械学習推論やHPC系ワークロードの性能が向上し、Graviton2比で最大25%の性能向上を達成しています。ハイパフォーマンスコンピューティング向けのGraviton3Eというバリアントも登場しました。

Graviton4 (2024年)

Graviton4は96コアへとコア数が増加し、SVE2 (Scalable Vector Extension 2) をサポートしました。C8g/M8g/R8g/X8gといった第8世代のインスタンスファミリーに搭載されています。前世代のGraviton3に比べて最大30%の性能向上が謳われています。ただしこの「最大30%」はAWSの公式リファレンスベンチマークでの参考値であり、実際の改善幅はワークロードの特性によって大きく異なります。自社のワークロードで必ず実測して判断することが重要です。

2-2. Graviton4のアーキテクチャ革新とarm64特性

Graviton4ではGraviton3からいくつかの革新的な変更が加えられています。

コア数の拡大

Graviton3の64コアからGraviton4では96コアへと増加しています。マルチスレッドの並列処理に強みを持つサーバーワークロードでは、このコア数増加が実性能に直結します。シングルスレッド性能を重視するワークロードではコア数増加の恩恵は限定的です。

SVE2 (Scalable Vector Extension 2) のサポート

Neon SIMDよりも柔軟なベクトル演算が可能なSVE2をサポートしています。コンパイラがSVE2向けの最適化コードを生成すると、数値演算や画像処理系のワークロードで大幅な高速化が見込めます。ClangやGCCの最新版ではSVE2最適化が有効になりつつあります。

L3キャッシュの拡大とDDR5メモリ

Graviton4では大容量のL3キャッシュを搭載しています。データベースのワーキングセットがキャッシュに収まりやすくなるため、メモリアクセスが多い処理でレイテンシの低減が期待できます。また、DDR5メモリをサポートしており、メモリ帯域幅がGraviton3から大きく向上しています。インメモリデータベースや機械学習推論のような大量データを扱うワークロードで恩恵を受けやすい設計です。

固定クロック動作による安定したレイテンシ

GravitonはAWSのNitro Systemと密接に統合されています。固定クロック動作による安定したレイテンシ特性もGravitonの特徴であり、一般的なx86 CPUに見られるようなターボクロックによる性能の揺れが生じにくい設計になっています。これはレイテンシの安定性を重視するオンライントランザクション処理などに有利です。

arm64アーキテクチャのNEON/SVE2 SIMD

AWSカスタムコアであるGravitonは、ArmのNEON (128-bit SIMD) とSVE2の両方をサポートしています。NEONは動画エンコード・暗号処理・音声処理など幅広い用途で活用されており、SVE2はより大きなベクトル幅を可変長で処理できるため、HPC向けのスパースベクトル演算や機械学習の行列演算に向いています。

2-3. インスタンスファミリー別の特性と選定

Graviton4世代の主なインスタンスファミリーはC8g/M8g/R8g/X8gの4種類です。それぞれの特性と選定の考え方を解説します。

C8g (コンピュート最適化)

C8gはGraviton4の高コア密度を活かしたコンピュート最適化ファミリーです。vCPUとメモリの比率が高く計算密度に優れており、Webサーバー・APIサーバー・バッチ処理・CI/CDビルドなど計算量が多いワークロードに適しています。東京リージョン (ap-northeast-1) では2025年3月にGAとなりました。

主な活用シーン:
– 高スループットWebアプリケーションサーバー
– マイクロサービスAPIサーバー
– コンパイル・ビルド処理
– CPU推論型の機械学習ワークロード

M8g (汎用)

M8gはバランス型の汎用ファミリーです。vCPUとメモリが均等な比率で提供されるため、特定のリソースに偏りのないワークロードに適しています。開発環境・ミドルウェアサーバー・中小規模のデータベースなど幅広い用途に対応します。

主な活用シーン:
– アプリケーションサーバー全般
– 小中規模のデータベース
– 開発・ステージング環境
– 一般的なWebサービスバックエンド

R8g (メモリ最適化)

R8gはGraviton4の高メモリ帯域幅の恩恵を最大限に受けられるメモリ最適化ファミリーです。vCPU 1コアあたり8GB以上のメモリを搭載しており、大容量データをメモリ上で保持する処理に適しています。東京リージョンでは2024年12月にGAとなっており、Graviton4世代では最も早く東京で利用可能になったファミリーです。

主な活用シーン:
– 高メモリ要件のデータベース (MySQL、PostgreSQL)
– インメモリキャッシュ (Redis、Memcached)
– データ分析・集計処理
– 大容量ワーキングセットを持つアプリ

X8g (超大容量メモリ)

X8gはさらに大きなメモリ容量を必要とするエンタープライズワークロード向けです。SAP HANAのような大規模インメモリデータベースや、大規模モデルを使用した推論処理などに対応します。提供状況はAWS公式ドキュメントで最新情報を確認してください。

主な活用シーン:
– SAP HANAおよびエンタープライズ向け大規模DB
– 大規模インメモリ分析
– 3TiBを超えるメモリが必要なワークロード

2-4. Graviton採用判断軸とワークロード互換性チェック

Graviton4への移行を検討する際には、以下のチェックリストで互換性を事前評価します。

互換性確認チェックリスト

1. OS対応確認: Amazon Linux 2023・Ubuntu 20.04以降・RHEL 8以降などarm64対応OSを利用しているか
2. 言語ランタイム確認: Java 17以降・Python 3.8以降・Go 1.16以降・Node.js 16以降などarm64対応バージョンか
3. ライブラリ確認: 使用しているネイティブライブラリ (JNIライブラリ・ctypes等) がarm64バイナリを提供しているか
4. コンテナイメージ確認: Dockerイメージがlinux/arm64プラットフォームをサポートしているか
5. x86専用バイナリ確認: サードパーティ製のバイナリや商用ソフトウェアにarm64版があるか
6. AWS Graviton Ready確認: 使用しているAWSサービスやマーケットプレイスのAMIがGraviton対応か

AWS Graviton Porting Advisorの活用

AWSが提供するGraviton Porting Advisorは、コードベースに含まれるarm64非互換な箇所を自動検出するツールです。C/C++のソースコードやJavaのバイトコードをスキャンし、移行に際して対処が必要な箇所を重要度別に報告します。

# Porting Advisorのインストールと実行例
pip install graviton-porting-advisor
graviton-porting-advisor scan /path/to/project

移行候補ワークロードの優先付け

一般的にGravitonへ容易に移行でき、効果を得やすいワークロードの例です。

• JavaやGoで実装されたWebサービス (言語ランタイムがarm64を完全サポート)
• コンテナ化されたマイクロサービス (マルチアーキテクチャビルドで容易に対応)
• PythonのWebアプリ・スクリプト処理
• nginx/Apache等のOSS Webサーバー
• MySQLやPostgreSQL等のOSSデータベース

慎重に検証が必要なワークロードの例です。

• x86_64向けにコンパイルされたネイティブバイナリが含まれるアプリ
• arm64未対応の商用ライセンスソフトウェア
• Intel/AMD固有命令セット (AVX-512等) を使用するHPCアプリ

2-5. 公式ベンチマーク結果の正しい読み方

AWSはGraviton4について「Graviton3比最大30%高性能」という数値を公表しています。この数値を正しく理解して活用するためのポイントを解説します。

「最大30%」は特定条件下での参考値

AWSが公表するベンチマーク数値はCPU集約型のワークロード (SPEC CPU 2017等) での測定結果です。実際のワークロードの特性によって改善幅は大きく変わります。メモリI/Oがボトルネックのワークロードでは、メモリ帯域幅向上の恩恵を受けやすい傾向があります。一方でレイテンシがネットワークやディスクI/Oに依存するワークロードでは、CPU性能向上の恩恵が限定的になります。

自社ワークロードでの実測が必須

Graviton4への移行効果を見積もる際は、必ず本番同等のベンチマーク環境を構築して実測することを推奨します。同じAPIを処理するWebサーバーでも、利用するフレームワーク・JVMのチューニング状態・コンパイルフラグによって結果が異なります。

コンパイルフラグの最適化効果

GCCやClangでコンパイルする際に-march=armv9-aなどのGraviton向け最適化フラグを指定することで、汎用ARMビルドよりも高い性能を引き出せる場合があります。JVMではJava 17以降でARM向け最適化が自動適用されます。Pythonの数値計算ライブラリ (numpy等) はarm64最適化版のインストールを確認してください。

2-6. 対応リージョンと東京GA状況

各Graviton4インスタンスファミリーの東京リージョン (ap-northeast-1) での提供状況を整理します。

東京リージョンでの利用開始時には必ずAWS公式ドキュメントでGA状況を確認してください。GA前のプレビュー段階ではSLAや機能制約の内容が異なります。また東京以外のリージョン (バージニア北部等) ではより早くGAしているケースが多いため、開発・テスト目的であれば別リージョンで先行評価することも有効です。

# 東京リージョンでのインスタンスタイプ提供確認
aws ec2 describe-instance-type-offerings \
  --region ap-northeast-1 \
  --filters "Name=instance-type,Values=r8g.*,c8g.*,m8g.*,x8g.*" \
  --query "InstanceTypeOfferings[].{Type:InstanceType,Location:Location}" \
  --output table

3. x86からarm64への移行

Graviton4世代（R8g/C8g/M8g/X8g）への移行は、x86ベースのインスタンスからarm64アーキテクチャへの切り替えを伴います。Graviton3比最大30%の性能向上を実現するには、移行前の事前評価から本番適用まで計画的に進めることが重要です。東京リージョン（ap-northeast-1）ではR8gが2024年12月に、C8gが2025年3月に一般提供を開始しており、国内本番ワークロードでもすぐに移行を開始できる環境が整っています。

3-1. 移行の事前評価

x86からarm64への移行を成功させるためには、まず移行対象ワークロードの互換性を正確に評価することが重要です。

ワークロード互換性の確認

arm64移行に際して最初に確認すべきは、ランタイムやライブラリのarm64対応状況です。主要な言語ランタイムの対応状況は以下のとおりです。

ネイティブコードを含むライブラリ（特にSSE/AVX命令を使用するもの）はarm64向けに再コンパイルが必要です。Pure Javaや純粋なスクリプト言語ではほとんど問題が発生しません。

Graviton4インスタンスファミリー選定フロー

移行先インスタンスの選定は、ワークロードの特性に基づいて行います。

R8g（メモリ最適化）

メモリ集約型ワークロードに最適なインスタンスファミリーです。Graviton4プロセッサと大容量DDR5メモリを組み合わせており、インメモリデータベースやリアルタイム分析に適しています。東京リージョン（ap-northeast-1）では2024年12月に一般提供が開始されています。

代表的なサイズ（r8g.48xlarge）の主な仕様:
– vCPU: 192
– メモリ: 1,536 GiB
– ネットワーク帯域: 50 Gbps
– EBS帯域: 60 Gbps
– 代表的なユースケース: 大規模インメモリキャッシュ、ElastiCache代替、高メモリデータベース

C8g（コンピュート最適化）

CPUバウンドなワークロードに最適なインスタンスファミリーです。Graviton4の高いクロック性能とコア密度を活かし、演算集約型処理に適しています。東京リージョン（ap-northeast-1）では2025年3月に一般提供が開始されています。

代表的なサイズ（c8g.48xlarge）の主な仕様:
– vCPU: 192
– メモリ: 384 GiB
– ネットワーク帯域: 50 Gbps
– EBS帯域: 60 Gbps
– 代表的なユースケース: ウェブサーバー、バッチ処理、メディアエンコード、科学計算

M8g（汎用）

コンピュートとメモリのバランスが取れた汎用インスタンスファミリーです。多様なワークロードに柔軟に対応し、アプリケーションサーバーや中規模データベースに適しています。

代表的なサイズ（m8g.48xlarge）の主な仕様:
– vCPU: 192
– メモリ: 768 GiB
– ネットワーク帯域: 50 Gbps
– EBS帯域: 60 Gbps
– 代表的なユースケース: アプリケーションサーバー、汎用Webバックエンド、小〜中規模データベース

X8g（超高メモリ）

極めてメモリ集約型のワークロード向けインスタンスファミリーです。超大規模インメモリデータベースやHPCアプリケーションに適しています。

代表的なサイズ（x8g.48xlarge）の主な仕様:
– vCPU: 192
– メモリ: 3,072 GiB
– 代表的なユースケース: SAP HANA、大規模分析エンジン、超大容量インメモリ処理

選定フロー

以下の手順で移行先インスタンスファミリーを決定します。

1. ワークロード計測: CloudWatch Metricsで現行インスタンスのCPU使用率・メモリ使用量・ネットワーク帯域を1〜2週間計測します
2. ボトルネック特定:
3. 平均CPU使用率 > 60% → C8g（コンピュート最適化）を優先検討
4. メモリ使用率 > 70% → R8g（メモリ最適化）を優先検討
5. バランス型 → M8g（汎用）から開始
6. ダウンサイズ検討: Graviton3比最大30%の性能向上があるため、同等性能を維持しながら1〜2ランクのダウンサイズを検討します
7. 東京リージョン対応確認: R8g（ap-northeast-1 GA: 2024-12）・C8g（ap-northeast-1 GA: 2025-03）・M8g・X8gの提供状況を公式ページで最新確認します

3-2. マルチアーキテクチャビルド

x86とarm64の両方に対応するマルチアーキテクチャイメージを構築することで、段階的な移行と既存x86環境との共存が可能になります。

docker buildxによるマルチプラットフォームビルド

Docker BuildKitのbuildx機能を使用すると、単一のDockerfileから複数アーキテクチャ向けのイメージを一度にビルドできます。

# マルチアーキテクチャビルダーの作成
docker buildx create --name multiarch-builder --use

# ビルダーの動作確認
docker buildx inspect --bootstrap

# amd64とarm64の両方向けにビルドしてECRへプッシュ
docker buildx build \
  --platform linux/amd64,linux/arm64 \
  -t 123456789012.dkr.ecr.ap-northeast-1.amazonaws.com/myapp:latest \
  --push \
  .

このコマンドを実行すると、ECRにはlinux/amd64とlinux/arm64の両マニフェストを持つマルチアーキテクチャイメージが登録されます。Graviton4ノード（arm64）はarm64マニフェストを、x86ノードはamd64マニフェストを自動的に取得します。

Dockerfileのクロスコンパイル対応

Go言語のような静的コンパイル言語では、ビルドプラットフォームとターゲットプラットフォームを分離することで、高速なクロスコンパイルが可能です。

FROM --platform=${BUILDPLATFORM} golang:1.21 AS builder
ARG TARGETOS
ARG TARGETARCH

WORKDIR /app
COPY go.mod go.sum ./
RUN go mod download

COPY . .
RUN CGO_ENABLED=0 GOOS=${TARGETOS} GOARCH=${TARGETARCH} \
 go build -ldflags="-s -w" -o myapp .

FROM --platform=${TARGETPLATFORM} public.ecr.aws/amazonlinux/amazonlinux:2023
COPY --from=builder /app/myapp /usr/local/bin/myapp
ENTRYPOINT ["/usr/local/bin/myapp"]

GitHub ActionsによるCI/CDパイプライン

マルチアーキテクチャビルドをCI/CDに組み込む例です。

name: Multi-arch Build and Push

on:
  push:
 branches: [main]

jobs:
  build:
 runs-on: ubuntu-latest
 permissions:
id-token: write
contents: read
 steps:
- uses: actions/checkout@v4

- name: Configure AWS credentials
  uses: aws-actions/configure-aws-credentials@v4
  with:
 role-to-assume: arn:aws:iam::123456789012:role/github-actions-ecr
 aws-region: ap-northeast-1

- name: Login to Amazon ECR
  id: login-ecr
  uses: aws-actions/amazon-ecr-login@v2

- name: Set up QEMU
  uses: docker/setup-qemu-action@v3

- name: Set up Docker Buildx
  uses: docker/setup-buildx-action@v3

- name: Build and push
  uses: docker/build-push-action@v5
  with:
 platforms: linux/amd64,linux/arm64
 push: true
 tags: ${{ steps.login-ecr.outputs.registry }}/myapp:${{ github.sha }}
 cache-from: type=gha
 cache-to: type=gha,mode=max

3-3. 移行支援ツールの活用

AWSが提供する移行支援ツールを活用することで、互換性問題を事前に検出し、移行リスクを最小化できます。

AWS Graviton Porting Advisor

AWS Graviton Porting Advisor（GitHubで公開されているオープンソースツール）は、ソースコードを静的解析してarm64移行における潜在的な問題を特定します。

# pipでインストール
pip install porting-advisor-for-graviton

# プロジェクトのスキャン
porting-advisor --source-dir ./myapp --target=graviton

# 特定言語のみスキャン（例: Python）
porting-advisor --source-dir ./myapp --target=graviton --language=python

# JSON形式で出力（CI/CDに組み込む場合）
porting-advisor --source-dir ./myapp --target=graviton --output=report.json

検出されるおもな問題は以下のとおりです。

• x86専用アセンブリコードの使用（インラインASMなど）
• arm64非対応のSSE/AVX命令の使用
• アーキテクチャ依存のバイトオーダー処理
• arm64ビルドが未確認のネイティブ拡張モジュール

arm64対応ライブラリの活用

主要なオープンソースライブラリのarm64最適化版を利用することで、追加のチューニングなしに性能向上を得られます。

段階的ブルーグリーン移行

本番環境への影響を最小化するため、ブルーグリーンデプロイメント方式での段階的移行を推奨します。

1. フェーズ1（開発環境での検証）: arm64インスタンスでアプリケーションを起動し、機能テストと性能計測を実施します
2. フェーズ2（ステージング環境での検証）: 本番相当のデータとトラフィックパターンで動作確認を行います
3. フェーズ3（本番への段階移行）: ALBの重みつきルーティングで5%→20%→50%→100%と段階的に切り替えます
4. フェーズ4（安定確認と撤収）: CloudWatchアラームが発生しないことを確認後、旧x86インスタンスを削除します

# ALBの重みつきルーティングで段階移行（20% arm64）
aws elbv2 modify-listener \
  --listener-arn arn:aws:elasticloadbalancing:ap-northeast-1:123456789012:listener/app/my-alb/xxx \
  --default-actions '[
 {"Type": "forward", "ForwardConfig": {
"TargetGroups": [
  {"TargetGroupArn": "arn:aws:elasticloadbalancing:ap-northeast-1:123456789012:targetgroup/x86-tg/aaa", "Weight": 80},
  {"TargetGroupArn": "arn:aws:elasticloadbalancing:ap-northeast-1:123456789012:targetgroup/arm64-tg/bbb", "Weight": 20}
]
 }}
  ]'

4. 最新Nitro System

Nitro SystemはAWSが設計・開発したカスタムハードウェアとソフトウェアの統合プラットフォームです。EC2の仮想化基盤として2017年に初公開されて以来、世代を重ねながら進化を続け、現在の最新世代EC2インスタンス(Graviton4/C7i/M7i/R7i等)すべての基盤となっています。従来のハイパーバイザーが抱えていた「ホストCPUがI/O処理で消費される」問題を根本から解消し、仮想インスタンスにおいてベアメタルに近い性能を実現しました。

4-1. Nitro Systemの構成とカスタムASIC

Nitro Systemは主に次の3要素から構成されます。

Nitro Card(カスタムASIC)

AWSが2015年に買収したAnnapurna Labsが設計したカスタムシリコンです。機能別に専用カードが用意されており、それぞれがホストCPUから独立してI/O処理をオフロードします。

• Nitro Card for VPC: VPCネットワーキング処理(パケット転送・セキュリティグループ・NATなど)をオフロード
• Nitro Card for EBS: EBS I/O処理をオフロードし、EBS専用帯域を確保
• Nitro Card for Instance Storage: NVMe SSDへの直接アクセスを管理
• Nitro Controller: 全Nitro Cardを統括し、ホスト全体のI/Oを調停

これらのカードがI/O処理を担うことで、ホストCPUのほぼ全リソースを顧客インスタンスに割り当てられます。従来の仮想化環境では10〜30%程度のCPU資源がハイパーバイザーのオーバーヘッドに使われていましたが、Nitro Systemではそのオーバーヘッドが事実上ゼロに近づきます。

Nitro Hypervisor

Nitro HypervisorはKVMをベースに軽量化されたAWS独自のハイパーバイザーです。CPUとメモリの割り当てのみを担い、I/O処理はNitro Cardが一手に引き受けます。この設計により、ハイパーバイザー自体のフットプリントは最小化され、顧客ワークロードへのリソース割当率が最大化されます。

Graviton4世代では、Nitro HypervisorとGraviton4プロセッサの緊密な連携により、メモリアクセスのレイテンシ削減とNUMA境界の最適化が実現されています。r8gインスタンスではDDR5-5600メモリとNitroの組み合わせで大容量メモリワークロード向けに特化した最適化が施されています。

Nitro Security Chip

ホストのファームウェアとハードウェア構成を管理するセキュリティチップです。起動時のセキュアブートを強制し、ファームウェアの改ざんを検知します。AWSオペレーターもこのチップで制御されたアクセス以外ではホストに触れられません。

4-2. Nitro Hypervisorの最新世代仕様

最新世代のNitro Hypervisorは、Graviton4・Intel第5世代(Emerald Rapids)・AMD第4世代(Genoa)の各プロセッサと最適化されています。

ベアメタルに近い仮想化性能

Nitro Hypervisorを使用するインスタンスでは、単純なCPU演算・メモリ帯域幅・ネットワークスループットのいずれにおいても、同世代のベアメタルインスタンスと比較して95〜99%以上の性能を発揮します。これはNitro CardによるI/Oオフロードが機能しているためです。

SR-IOV(Single Root I/O Virtualization)

Nitro Systemの内部ではSR-IOV技術を活用して、単一の物理デバイスを複数の仮想インスタンスに高効率で共有します。物理NICやNVMeコントローラーへの直接アクセスに近いパスを確保することで、ゲストドライバーとハードウェアの間の仮想化レイヤーを最小化しています。

Enhanced Networking

Elastic Network Adapter(ENA)はNitro専用に設計されたネットワークアダプターです。最新世代インスタンスではENA Expressをサポートしており、単一フローで最大25Gbpsのスループットと100マイクロ秒未満のネットワークレイテンシを実現します。従来のENAは複数フロー合計でのスループット最大化を重視していましたが、ENA Expressは単一TCP/UDPフローでも高帯域を確保できます。

4-3. Nitro Enclaves — 分離された機密データ処理環境

Nitro EnclavesはEC2インスタンス内に「さらに分離された実行環境」を作成する機能です。2020年にGAとなり、機密性の高いデータ処理に活用されています。

Nitro Enclavesの仕組み

通常のEC2インスタンス(親インスタンス)のvCPUとメモリの一部を切り出し、独立した実行環境(Enclave)を作成します。Enclaveは以下の特徴を持ちます。

• 永続ストレージなし(ディスクへのアクセス不可)
• 外部ネットワーク接続なし(インターネット・VPCへのアクセス不可)
• SSH等のインタラクティブアクセスなし
• 親インスタンスとはvsock(仮想ソケット)経由でのみ通信

この設計により、Enclave内のデータは親インスタンスのOSからも隔離されます。親インスタンスが侵害されても、Enclave内で処理中の機密データへのアクセスはできません。

Cryptographic Attestation(暗号証明)

Nitro EnclavesはAWS KMSと連携した暗号証明機能を持ちます。Enclaveは起動時に自身のコードとプラットフォームの測定値(PCRs: Platform Configuration Registers)を含む証明書を生成します。KMSはこの証明書を検証し、事前に登録されたEnclaveイメージと一致する場合のみ暗号鍵のアンロックを許可します。

これにより「正規のEnclaveコードのみが機密データを復号できる」という信頼チェーンが構築されます。

主要ユースケース

# Nitro Enclavesユースケース例
- 秘密鍵の保護: HSM代替として秘密鍵をEnclave内で管理
- 機械学習モデルの保護: モデルをEnclave内でのみロード・推論
- 医療データ処理: 患者データをEnclave内でのみ復号・分析
- 決済処理: カード番号等をEnclave内でのみ処理
- 認証情報管理: 短期クレデンシャルをEnclave内で生成・配布

Nitro Enclaves対応インスタンス

Nitro Hypervisorを搭載するほぼすべてのインスタンスがNitro Enclavesをサポートします。Graviton4ベースのr8g/c8g/m8gも対応しており、arm64ネイティブコンテナイメージをEnclave内で実行できます。Enclaveの作成にはEnclaveOS(AWS提供のLinuxベースミニマルOS)を使用します。

4-4. ベアメタルインスタンスとNitro

Nitro Systemはベアメタルインスタンスにおいても同様の機能を提供します。ベアメタルインスタンスでは顧客が物理ホストのCPUとメモリに直接アクセスできますが、VPCネットワークやEBS等のAWSサービスはNitro Cardが引き続き処理します。

ベアメタルインスタンスの主要用途

ベアメタルインスタンスは以下のユースケースに適しています。

• ライセンス依存ソフトウェア: OracleやSAP HANAなどのライセンスが物理ソケット数に依存する製品
• 独自ハイパーバイザーの実行: VMware Cloud on AWSのように顧客独自のハイパーバイザーを動かす
• ハードウェアアクセスが必要なアプリケーション: CPUの特定命令セットや機能フラグへの直接アクセスが必要なケース
• セキュリティ要件: 別テナントとのCPU共有を避けるコンプライアンス要件

Graviton4ベアメタルインスタンス

m8g/c8g/r8gシリーズにはベアメタルバリアントが用意されています(metal-24xl/metal-48xlサフィックス)。最大192 vCPU相当のGraviton4コアと最大3TBのDDR5メモリへの直接アクセスが可能です。リージョン対応状況は公式ドキュメントを確認してください。

4-5. Nitroセキュリティ — 攻撃面の縮小設計

Nitro Systemのセキュリティ設計は「攻撃面を縮小する」という哲学に基づいています。

AWSオペレーターによるホストアクセスの排除

従来のクラウド仮想化では、インフラ管理のためにAWSオペレーターがホストにSSH等でアクセスできる経路が存在していました。Nitro Systemではこの経路を設計上排除しています。ホストへのすべての管理操作はNitro Security Chipで制御され、インタラクティブアクセスは存在しません。AWSが提供するセキュリティホワイトペーパーでも、この「運用者アクセスの排除」が重要なセキュリティ保証として明記されています。

VPCネットワークの暗号化とアイソレーション

Nitro CardはVPCのすべてのネットワークトラフィックを物理レイヤーで処理します。インスタンス間の通信はNitro CardによってVPCの論理境界で制御され、別テナントのインスタンスへのアクセスはハードウェアレベルで遮断されます。

EBSの暗号化とセキュアパス

EBSボリュームは転送中の暗号化をサポートしており、ホストとEBSストレージサーバー間のデータは自動的に暗号化されます(インスタンスタイプによって自動有効化)。Nitro Cardが暗号化/復号を処理するため、顧客インスタンスのCPU負荷は発生しません。

リモートコード実行攻撃面の縮小

Nitro HypervisorはKVMをベースとしながらも、通常のLinuxホストOSとは切り離された最小限のコードベースで動作します。ホストでLinuxカーネルの脆弱性が発見されても、Nitro Hypervisorが動作するドメインとゲストインスタンスの間の攻撃面は最小化されます。Nitro Cardはハードウェアで処理するため、ソフトウェアの脆弱性による攻撃経路がありません。

Nitro TPM(vTPM)

最新のNitro世代ではvTPM 2.0(Trusted Platform Module)をサポートしています。WindowsインスタンスでのセキュアブートやTPMベースのディスク暗号化(BitLocker等)に活用できます。LinuxではUEFI(Unified Extensible Firmware Interface)とSecure Bootの組み合わせで対応します。

4-6. NVMe SSD直接アクセスとEBS最適化の最新仕様

インスタンスストア(NVMe SSD)の直接アクセス

Nitro CardはインスタンスストアのNVMe SSDへの直接アクセスを管理します。インスタンスストアは物理ホストに搭載されたSSDで、EBSとは異なりネットワーク経由ではなくローカルバスで接続されています。

# インスタンスストアの特性
超低レイテンシ  : マイクロ秒単位(EBSは数百マイクロ秒〜)
高IOPS  : ローカル接続による高密度I/O
揮発性  : インスタンス停止/終了でデータ消失
用途 : 一時キャッシュ/バッファ/リードレプリカ/Hadoopノード

c8g/r8g/m8g系インスタンスの一部バリアントにはNVMeインスタンスストアが搭載されています。Nitro Cardが処理することで、ゲストドライバーからはNVMe標準プロトコルで直接アクセスでき、追加のアブストラクションレイヤーがありません。

EBS最適化の最新仕様

Nitro世代のすべてのインスタンスはデフォルトでEBS最適化が有効になっています。EBSトラフィックは専用のNitro Cardが処理するため、インスタンスのネットワーク帯域をEBS I/Oが消費しません。

最新世代インスタンスのEBS最大帯域幅は代表的な値として以下が公開されています(詳細は公式ドキュメントを参照してください)。

# EBS帯域幅の目安(代表例)
m8g.16xlarge: 約20 Gbps
r8g.16xlarge: 約20 Gbps
c8g.16xlarge: 約20 Gbps
m8g.metal-48xl : 約60 Gbps

io2 Block Expressとの組み合わせ

最新Nitro世代インスタンスはio2 Block Expressボリュームをサポートし、単一ボリュームで最大256,000 IOPS・最大4,000 MB/sのスループットを実現できます(インスタンス側のEBS帯域上限内)。ミッションクリティカルなデータベースワークロードに適した組み合わせです。

gp3の独立チューニング

gp3ボリュームはIOPSとスループットをベースライン(3,000 IOPS/125 MB/s)から独立してプロビジョニングできます。Nitro世代インスタンスでの活用では、EBS帯域をNitro Cardが保証するため、ワークロード特性に合わせた細かなIOPS/スループット設定が安定して機能します。

5. コンテナ環境でのGraviton活用

コンテナワークロードはGraviton4移行の効果が最も出やすい領域です。
EKSではKarpenterによるノード自動選択、ECSではタスク定義のcpuArchitecture指定と、
いずれもクラスター全体を止めずに段階的にarm64へ切り替えられます。
本セクションでは、マルチアーキテクチャイメージのビルドから実際のクラスター統合、
そして障害時のロールバックまでを一気通貫で解説します。

5-1. EKSでのGraviton活用

Karpenterを使ったGraviton4ノードの自動選択

EKS上でGraviton4インスタンス(R8g/C8g/M8g)を活用する最も効率的な方法は、
Karpenterを組み合わせたノードプロビジョニングです。
Karpenterは待機中のPodのリソース要求とNodePoolの定義に基づいて最適なインスタンスを自動選択します。

NodePoolにarm64アーキテクチャを追加すると、Graviton4インスタンスが候補に入ります。

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: graviton4-pool
spec:
  template:
 spec:
requirements:
  - key: kubernetes.io/arch
 operator: In
 values: ["arm64"]
  - key: karpenter.k8s.aws/instance-family
 operator: In
 values: ["r8g", "c8g", "m8g"]
  - key: karpenter.sh/capacity-type
 operator: In
 values: ["on-demand", "spot"]
nodeClassRef:
  group: karpenter.k8s.aws
  kind: EC2NodeClass
  name: graviton4-class
  limits:
 cpu: "200"
 memory: 400Gi
  disruption:
 consolidationPolicy: WhenEmptyOrUnderutilized
 consolidateAfter: 30s

NodeClassではarm64対応のAMI IDを指定します。
EKS Optimized AMI (Amazon Linux 2023) はarm64版が東京リージョン(ap-northeast-1)でも提供されています。

apiVersion: karpenter.k8s.aws/v1
kind: EC2NodeClass
metadata:
  name: graviton4-class
spec:
  amiFamily: AL2023
  amiSelectorTerms:
 - alias: al2023@latest
  subnetSelectorTerms:
 - tags:
  karpenter.sh/discovery: my-cluster
  securityGroupSelectorTerms:
 - tags:
  karpenter.sh/discovery: my-cluster
  role: KarpenterNodeRole-my-cluster

PodにNodeSelectorまたはaffinityを設定することで、
特定のDeploymentをGraviton4ノードに誘導できます。

affinity:
  nodeAffinity:
 preferredDuringSchedulingIgnoredDuringExecution:
- weight: 80
  preference:
 matchExpressions:
- key: kubernetes.io/arch
  operator: In
  values: ["arm64"]

preferredDuring...を使うと、arm64が利用できない場合はx86ノードにフォールバックします。
段階移行中はpreferredDuring...で開始し、検証完了後にrequiredDuring...へ昇格させる進め方が安全です。

マルチアーキテクチャイメージのビルド

Graviton4対応のコンテナイメージを用意するには、
linux/amd64とlinux/arm64の両プラットフォームに対応したマルチアーキテクチャイメージが必要です。
Docker BuildKitとbuildxを使うと、1コマンドで両アーキテクチャのイメージをビルドしてプッシュできます。

# BuildKit有効化 (Docker 23.0以降はデフォルト)
export DOCKER_BUILDKIT=1

# マルチアーキテクチャ対応のbuildxインスタンス作成
docker buildx create --name multiarch-builder --use --bootstrap

# amd64/arm64両対応イメージをビルドしてECRへプッシュ
docker buildx build \
  --platform linux/amd64,linux/arm64 \
  --tag 123456789012.dkr.ecr.ap-northeast-1.amazonaws.com/my-app:latest \
  --push \
  .

ECRはマルチアーキテクチャマニフェストをそのままサポートしており、
プル時にノードのアーキテクチャに合ったイメージレイヤーが自動的に選択されます。

ビルドしたイメージのマニフェスト構成はdocker buildx imagetools inspectで確認できます。

docker buildx imagetools inspect \
  123456789012.dkr.ecr.ap-northeast-1.amazonaws.com/my-app:latest
# MediaType: application/vnd.docker.distribution.manifest.list.v2+json
# Platforms: linux/amd64, linux/arm64

DockerfileのFROMベースイメージも両アーキテクチャ対応のものを選ぶことが重要です。
Amazon Linux 2023、Ubuntu 22.04 LTS、Alpine 3.18以降はいずれもarm64版を提供しています。

AWS Graviton Porting Advisor for Python

PythonアプリケーションのC拡張モジュールがarm64に対応しているかどうかを事前に確認するには、
AWS Graviton Porting Advisor for Pythonが有効です。
このツールはpipで管理されたパッケージを静的解析し、arm64対応状況を一覧出力します。

pip install graviton-porting-advisor
graviton-porting-advisor /path/to/project

出力例:

Package  Version  arm64 Support
numpy 1.24.3Supported (wheels available)
scipy 1.11.2Supported (wheels available)
lxml  4.9.3 Supported (wheels available)
proprietary-x  2.1.0 Unknown (no arm64 wheel on PyPI)

UnknownやNot Supportedと出たパッケージについては、
ソースコードからのビルドが可能かどうか個別に確認します。
多くのC拡張は現在arm64ビルドを提供していますが、
プロプライエタリなバイナリパッケージは例外となる場合があります。

Node.js/Go/Rustなど他のランタイムについては、
公式のarm64バイナリが提供されているかどうかをリリースノートで確認します。
Go 1.16以降、Node.js 16以降、Rust (stableツールチェーン) はいずれもarm64をファーストクラスサポートしています。

5-2. ECSでのGraviton活用

タスク定義でのcpuArchitecture指定

ECSでGravitonインスタンスを活用する場合、
タスク定義のruntimePlatformセクションでcpuArchitectureを明示します。

{
  "family": "my-app",
  "networkMode": "awsvpc",
  "runtimePlatform": {
 "operatingSystemFamily": "LINUX",
 "cpuArchitecture": "ARM64"
  },
  "containerDefinitions": [
 {
"name": "my-app",
"image": "123456789012.dkr.ecr.ap-northeast-1.amazonaws.com/my-app:latest",
"cpu": 512,
"memory": 1024
 }
  ],
  "requiresCompatibilities": ["EC2"],
  "cpu": "512",
  "memory": "1024"
}

cpuArchitecture: ARM64を指定したタスクは、
ARM64対応のコンテナインスタンス(Graviton系EC2またはFargate arm64)にのみスケジュールされます。
Fargate arm64は東京リージョンでも利用可能で、サーバーレスコンテナ実行環境としてGraviton4の性能を享受できます。

主要ランタイムとライブラリのarm64対応確認

ECSで稼働させるアプリケーションに使用するベースイメージとライブラリのarm64対応を確認します。

JVMワークロードはGraviton3比でGraviton4が最大30%高性能であるため、
スループット重視のSpring Bootアプリケーションでは特に移行効果が現れます。

5-3. x86とarm64の混在運用

段階移行戦略

本番環境全体を一度にarm64へ切り替えるのはリスクが高いため、
x86/arm64混在の段階的なFleetで移行することが推奨されます。

フェーズ1: 互換性確認 (1〜2週間)
– ステージング環境でGraviton4インスタンスを起動し、動作確認を実施します。
– マルチアーキテクチャイメージをビルドし、ECRにプッシュします。
– アプリケーションの機能テストおよびパフォーマンステストを実施します。
– Graviton Porting Advisorで依存ライブラリの互換性を確認します。

フェーズ2: カナリアデプロイ (1〜2週間)
– 本番EKSクラスターにGraviton4 NodePoolを少数追加します (全体の10〜20%程度)。
– Karpenterのweightを低めに設定し、既存のx86 NodeGroupへの影響を最小化します。
– メトリクス (レイテンシ/エラーレート/CPU使用率) をCloudWatchで監視します。
– 問題がなければGraviton4比率を徐々に引き上げます (20% → 50% → 80%)。

フェーズ3: 完全移行 (要件に応じて)
– x86 NodeGroupのmin-sizeを0に設定し、Graviton4に完全移行します。
– レガシー対応が必要なワークロードのみx86を残し、その他は全てarm64に統一します。
– コスト試算と性能ベンチマーク結果を経営層に報告します。

移行ロールバック手順

Graviton4移行後に重大な問題が発生した場合のロールバック手順を事前に定義しておくことが重要です。

EKSでのロールバック手順

1. Karpenterのarm64 NodePoolのlimits.cpuを0に設定してGraviton4への新規スケジュールを停止します。

kubectl patch nodepool graviton4-pool \
  --type merge \
  -p '{"spec":{"limits":{"cpu":"0"}}}'

1. Deploymentのafinityをx86へ戻します。

kubectl set env deployment/my-app \
  NODE_ARCH=amd64
# または affinity を kubectl patch で更新

1. 既存のx86 NodeGroupのCapacityを引き上げ、Podがx86ノードへ再スケジュールされることを確認します。

2. Graviton4ノードはKarpenterのdisruptionポリシーにより自動的にドレインおよびターミネートされます。

ECSでのロールバック手順

1. タスク定義のcpuArchitectureをX86_64に変更した新しいリビジョンを作成します。

aws ecs register-task-definition \
  --cli-input-json file://task-def-x86.json

1. ECSサービスのtask-definitionを新しいリビジョンに更新してローリングアップデートを実施します。

aws ecs update-service \
  --cluster my-cluster \
  --service my-service \
  --task-definition my-app:NEW_REVISION

1. ECSサービスのローリングアップデートが完了し、全タスクがx86に戻ったことを確認します。

ロールバック判断基準

以下の条件が1つでも発生した場合は即時ロールバックを検討します。

• エラーレートが移行前比較で10%以上増加
• P99レイテンシが移行前比較で20%以上悪化
• JVMのSegmentation FaultやSIGSEGVが継続発生
• arm64非対応のネイティブライブラリによるプロセスクラッシュ

ロールバック後は問題の根本原因を特定し、修正してから再移行を計画します。
原因の多くはarm64非対応のC拡張ライブラリやベースイメージの問題であるため、
Graviton Porting AdvisorやDockerのビルドログを起点に調査します。

6. 性能評価とベンチマーク

6-1. 性能測定の考え方と測定ツール

Graviton4への移行判断において、性能ベンチマークの結果は重要な根拠となります。ただし、「Graviton4はGraviton3比最大30%高性能」という公式ベンチマーク数値は、特定のワークロードで計測された参考値です。自社のワークロードが同様の性能向上を得られるかどうかは、実際の本番相当のワークロードで計測して初めて確認できます。

ベンチマーク前提の整理

性能測定を開始する前に、以下を明確にしてください。

• 測定対象のワークロード（CPUバウンド/メモリバウンド/I/Oバウンド の分類）
• ベースラインとする比較対象インスタンス（例：c6g vs c8g、c5 vs c8g）
• 測定環境（インスタンスサイズを揃えること。xlarge vs xlarge のように同等のvCPU/メモリで比較）
• 測定指標（スループット・レイテンシ・p99/p999分位数・コストあたりの処理量）

主要ベンチマークツール

arm64向けのツールは、ほぼすべての主要ベンチマークソフトウェアで対応済みですが、パッケージマネージャで入手できるバージョンがarm64向けにコンパイルされているかを確認してください。file /usr/bin/sysbenchなどで確認できます。

6-2. sysbenchを用いた基本性能測定

以下にGraviton4（R8g）でのsysbench計測例を示します。

# CPUベンチマーク（素数計算・スレッド数はvCPU数に合わせる）
sysbench cpu --cpu-max-prime=20000 --threads=4 run

# メモリ帯域幅ベンチマーク
sysbench memory --memory-block-size=1K --memory-total-size=100G \
  --threads=4 run

# スレッドスケーラビリティ確認（1/2/4/8スレッドで計測）
for t in 1 2 4 8; do
  echo "Threads: $t"
  sysbench cpu --threads=$t run 2>&1 | grep "events per second"
done

Graviton4はGraviton3と比べてLLCキャッシュを大幅に拡大しているため、メモリ帯域幅の測定ではGraviton3比で顕著な改善を示すケースが多くあります。一方、シングルスレッドのCPUクロック性能については、ワークロードの種類によって結果が異なります。

6-3. Graviton4 vs Graviton3 vs x86 比較方法

公平に比較するには、以下の手順を推奨します。

比較インスタンスの選定例

同一ワークロードに対して複数のインスタンスタイプで並列計測し、コストあたりの性能（性能/時間料金）を算出することで、コスト効率の観点での比較ができます。公式料金ページで最新の時間単価を確認し、「コストあたりスループット」の指標で評価してください。インスタンス料金はリージョンや時期によって変動するため、断定的な料金比較は避け、計測時点の料金をもとに試算する形を推奨します。

6-4. 段階移行手順（Shadow mode → 小規模Fleet → 本番展開）

Graviton4への移行は、次の3段階で安全に進めることを推奨します。

Step1: Shadow mode（影トラフィック検証）

本番トラフィックのコピーをGravitonインスタンスに送り、アプリケーションの動作を本番に影響を与えずに検証します。ALBの加重ルーティングを活用し、Gravitonターゲットグループへのトラフィック比率を0%（ミラーリング専用）から開始します。

# Gravitonターゲットグループを作成（重み0で開始）
aws elbv2 modify-rule \
  --rule-arn ${LISTENER_RULE_ARN} \
  --actions '[{
 "Type": "forward",
 "ForwardConfig": {
"TargetGroups": [
  {"TargetGroupArn": "'${ARM_TG_ARN}'", "Weight": 0},
  {"TargetGroupArn": "'${X86_TG_ARN}'", "Weight": 100}
]
 }
  }]'

Shadow modeでは、実際の本番リクエストと同等の負荷をGravitonインスタンスに流せるため、性能・エラー率・レイテンシを本番相当の条件で計測できます。CloudWatch Container Insightsを活用して、x86とGravitonの応答時間を並べて確認してください。

Step2: 小規模Fleetへの段階展開

Shadow modeで問題がないことを確認したら、本番トラフィックの5〜10%をGravitonインスタンスへ移行します。ALBの重み付きターゲットグループで比率を調整します。

# トラフィックの10%をGravitonへ移行
aws elbv2 modify-rule \
  --rule-arn ${LISTENER_RULE_ARN} \
  --actions '[{
 "Type": "forward",
 "ForwardConfig": {
"TargetGroups": [
  {"TargetGroupArn": "'${ARM_TG_ARN}'", "Weight": 10},
  {"TargetGroupArn": "'${X86_TG_ARN}'", "Weight": 90}
]
 }
  }]'

1週間程度の運用でメトリクスを監視し、エラー率・p99レイテンシが許容範囲内であることを確認します。問題がなければ比率を25%→50%と引き上げます。

Step3: 本番展開（フルGraviton化）

小規模Fleet検証が完了したら、段階的に比率を引き上げ（50% → 100%）、最終的にフルGraviton構成へ切り替えます。AutoScalingグループのlaunchTemplateをGravitonインスタンスタイプに変更し、既存のx86インスタンスを段階的に入れ替えます。

# AutoScaling起動テンプレートをGraviton4に更新
aws ec2 create-launch-template-version \
  --launch-template-id ${LT_ID} \
  --source-version '$Latest' \
  --launch-template-data '{"InstanceType": "m8g.xlarge"}'

# AutoScalingグループを新テンプレートバージョンへ更新
aws autoscaling update-auto-scaling-group \
  --auto-scaling-group-name ${ASG_NAME} \
  --launch-template "LaunchTemplateId=${LT_ID},Version=\$Latest"

6-5. ロールバック設計

Graviton移行後に性能劣化や互換性の問題が発覚した場合に備えて、迅速にロールバックできる設計を事前に用意しておくことが重要です。

起動テンプレートのバージョン管理

AutoScaling起動テンプレートは必ずバージョン管理します。Graviton4移行前のx86バージョンを$Defaultに設定しておくことで、問題発生時は即座にロールバックできます。

# 旧x86バージョンをデフォルトに設定してロールバック
aws ec2 modify-launch-template \
  --launch-template-id ${LT_ID} \
  --default-version 1

# AutoScalingグループをデフォルトバージョンへ戻す
aws autoscaling update-auto-scaling-group \
  --auto-scaling-group-name ${ASG_NAME} \
  --launch-template "LaunchTemplateId=${LT_ID},Version=\$Default"

ロールバック判断基準

以下の条件が1つでも発生した場合は即時ロールバックを検討します。

• エラーレートが移行前比較で10%以上増加した場合
• p99レイテンシが移行前比較で20%以上悪化した場合
• JVMのSegmentation FaultやSIGSEGVが継続発生している場合
• arm64非対応のネイティブライブラリによるプロセスクラッシュが発生した場合

ロールバック後は問題の根本原因を特定し、修正してから再移行を計画します。原因の多くはarm64非対応のC拡張ライブラリやベースイメージの問題であるため、Graviton Porting AdvisorやDockerのビルドログを起点に調査します。

ロールバック手順をRunbookとして事前に文書化し、インシデント発生時は即座に実行できる状態を維持してください。GitOpsベースの構成管理を採用している場合は、起動テンプレートの設定変更をコードとして管理し、バージョン間の差分を明確にしておくことを推奨します。

6-6. CloudWatch監視設計（arm64固有メトリクス）

GravitonインスタンスはCPUアーキテクチャが異なるため、監視設計においていくつかの注意点があります。

標準CloudWatchメトリクスの活用

CPU使用率・ネットワークスループット・EBSスループットなどの標準メトリクスはx86と同様に取得できます。ただし、CPU Stealなどのアーキテクチャ差異が出やすいメトリクスについては、x86ベースラインと直接比較して、アラート閾値を再調整することをお勧めします。

CloudWatch Agentによる詳細メトリクス

arm64環境でもCloudWatch Agentは動作します。procstatプラグインを活用することで、個別プロセスのCPU・メモリ使用量を細かく監視できます。

{
  "metrics": {
 "append_dimensions": {
"InstanceId": "${aws:InstanceId}",
"Architecture": "arm64"
 },
 "metrics_collected": {
"cpu": {
  "measurement": ["cpu_usage_idle", "cpu_usage_user", "cpu_usage_system"],
  "metrics_collection_interval": 60
},
"mem": {
  "measurement": ["mem_used_percent"],
  "metrics_collection_interval": 60
}
 }
  }
}

Architecture: arm64というカスタムディメンションを追加することで、CloudWatchダッシュボード上でx86とarm64のメトリクスを並べて比較できます。段階移行中は両アーキテクチャのメトリクスを同一ダッシュボードで可視化し、差分がないことを確認してから比率を引き上げる運用を推奨します。

アラート設定の推奨

• CPU使用率: 80%超を5分持続でアラート（Graviton4はマルチスレッドスケーラビリティが高いため、x86より高いCPU使用率まで安定動作することがあります）
• メモリ使用量: 90%超でアラート（arm64環境のOOMは突然発生するため早めのアラート設定を推奨）
• ネットワークエラーレート: 0.1%超でアラート

CloudWatch AlarmはTreatMissingData: notBreachingを設定しておくことで、インスタンス停止直後の誤報を防止できます。

6-7. コスト追跡（Cost Explorerでアーキテクチャ別分析）

Graviton移行後のコスト効果を定量的に測定するには、Cost ExplorerでアーキテクチャごとにEC2コストを分析します。

タグ戦略によるコスト分離

移行前にGravitonインスタンス専用のコスト配分タグを設計します。

# Gravitonインスタンスに識別タグを付与
aws ec2 create-tags \
  --resources ${INSTANCE_ID} \
  --tags \
 Key=Arch,Value=arm64 \
 Key=Generation,Value=graviton4 \
 Key=Environment,Value=production

このタグをCost Explorerの「タグ」でグループ化することで、アーキテクチャ別のEC2コストが可視化されます。移行前後のコストを比較する際は、インスタンス台数の変化も考慮した「総コスト」での比較が重要です。

コスト効率の計算指標

コスト効率 = 処理量（TPS/RPS）/ 時間あたりインスタンスコスト

Graviton4はGraviton3より性能が高い一方、インスタンス料金も異なります。「処理量あたりコスト」で評価することで、純粋なコスト効率を判断できます。最新の料金は公式ページを参照し、自社のワークロードに合わせて計算してください。コスト試算の結果は経営層向けのロードマップ報告にも活用できます。

Cost Explorerでの分析手順

1. コスト配分タグを有効化します（AWS Billing設定 → コスト配分タグ）。
2. Cost Explorerを開き、「グループ化」でタグArchを選択します。
3. 日付範囲を移行前後に設定し、x86とarm64のコストを比較します。
4. 移行完了後は、週次/月次でコストトレンドをレビューし、想定外のコスト増加がないかを確認します。

7. 実戦統合パターン

本セクションでは、既存のコンピュート基盤からGraviton4世代へ移行する際の実践的な統合パターンを解説します。コンピュート本番運用Vol1（EC2/AutoScaling/Spot基礎）で確立した設計をベースに、Graviton4への移行とコスト最適化との連携まで一連のフローを示します。

7-1. 段階的移行のエンドツーエンド設計

Vol1からの発展パターン

コンピュート本番運用Vol1では、EC2の基本選定・Auto Scaling・Spot活用・Graviton概要を扱いました。Vol2では、その基礎の上でGraviton4世代の最新インスタンスへの移行設計を行います。

既存Auto ScalingグループへのGraviton4混在導入

既存のAuto ScalingグループにGraviton4インスタンスを混在導入することで、段階的な移行が可能です。Mixed Instances Policyを活用します。

{
  "MixedInstancesPolicy": {
 "InstancesDistribution": {
"OnDemandBaseCapacity": 2,
"OnDemandPercentageAboveBaseCapacity": 30,
"SpotAllocationStrategy": "price-capacity-optimized"
 },
 "LaunchTemplate": {
"LaunchTemplateSpecification": {
  "LaunchTemplateId": "lt-xxxxxxxxxxxxxxxxx",
  "Version": "$Latest"
},
"Overrides": [
  {"InstanceType": "m8g.xlarge"},
  {"InstanceType": "m8g.2xlarge"},
  {"InstanceType": "c8g.xlarge"},
  {"InstanceType": "m7g.xlarge"}
]
 }
  }
}

このMixed Instances Policyでは、Graviton4（m8g、c8g）とGraviton3（m7g）を並列で使用し、Spotの価格と容量に基づいて最適なインスタンスを自動選択します。

EKS KarpenterによるGraviton4ノード管理

EKSでKarpenterを活用すると、ポッドのリソース要求に基づいてGraviton4インスタンスを自動的にプロビジョニングできます。

apiVersion: karpenter.k8s.aws/v1beta1
kind: NodePool
metadata:
  name: graviton4-nodepool
spec:
  template:
 metadata:
labels:
  arch: arm64
 spec:
nodeClassRef:
  apiVersion: karpenter.k8s.aws/v1beta1
  kind: EC2NodeClass
  name: graviton4-nodeclass
requirements:
  - key: kubernetes.io/arch
 operator: In
 values: [arm64]
  - key: karpenter.k8s.aws/instance-family
 operator: In
 values: [m8g, c8g, r8g]
  - key: karpenter.sh/capacity-type
 operator: In
 values: [spot, on-demand]
  - key: topology.kubernetes.io/zone
 operator: In
 values: [ap-northeast-1a, ap-northeast-1c, ap-northeast-1d]
  limits:
 cpu: "1000"
 memory: 2000Gi
  disruption:
 consolidationPolicy: WhenUnderutilized
 consolidateAfter: 30s

ポッドにはノードセレクターでGraviton4ノードを指定します。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
spec:
  template:
 spec:
nodeSelector:
  kubernetes.io/arch: arm64
containers:
  - name: myapp
 image: 123456789012.dkr.ecr.ap-northeast-1.amazonaws.com/myapp:latest

ECS FargateでのGraviton活用

ECS Fargateでは、タスク定義でarm64アーキテクチャを指定するだけでGraviton（arm64）上で実行できます。

{
  "family": "myapp-graviton",
  "cpu": "1024",
  "memory": "2048",
  "networkMode": "awsvpc",
  "runtimePlatform": {
 "operatingSystemFamily": "LINUX",
 "cpuArchitecture": "ARM64"
  },
  "containerDefinitions": [
 {
"name": "myapp",
"image": "123456789012.dkr.ecr.ap-northeast-1.amazonaws.com/myapp:latest",
"essential": true,
"portMappings": [
  {"containerPort": 8080, "protocol": "tcp"}
]
 }
  ]
}

Fargate arm64はx86比でコストが約20%低く、Graviton4の性能向上と組み合わせることで高い価格性能比を実現します。

Lambda arm64の活用

Lambda関数でもarm64（Graviton）アーキテクチャを選択できます。コンピュート集約型の関数でコスト削減と性能向上を期待できます。

# Lambda arm64関数の作成（CLI）
aws lambda create-function \
  --function-name myapp-handler \
  --runtime python3.12 \
  --role arn:aws:iam::123456789012:role/lambda-role \
  --handler main.handler \
  --zip-file fileb://function.zip \
  --architectures arm64 \
  --memory-size 512 \
  --timeout 30 \
  --region ap-northeast-1

Lambda arm64はx86比でDuration課金が約20%安価です。また、コールドスタートの短縮効果も報告されています。

マルチアーキテクチャ対応CI/CDパイプライン

Graviton4（arm64）への移行後は、すべての新しいコードがarm64で動作することをCI/CDパイプラインで保証します。

version: 0.2
phases:
  pre_build:
 commands:
- aws ecr get-login-password --region ap-northeast-1 | docker login --username AWS --password-stdin $ECR_REGISTRY
- docker buildx create --name builder --use
- docker buildx inspect --bootstrap

  build:
 commands:
- docker buildx build
 --platform linux/amd64,linux/arm64
 -t $ECR_REGISTRY/$IMAGE_NAME:$CODEBUILD_RESOLVED_SOURCE_VERSION
 -t $ECR_REGISTRY/$IMAGE_NAME:latest
 --push
 .

  post_build:
 commands:
- echo Build completed on `date`
- printf '[{"name":"myapp","imageUri":"%s"}]'
 $ECR_REGISTRY/$IMAGE_NAME:$CODEBUILD_RESOLVED_SOURCE_VERSION
 > imagedefinitions.json

artifacts:
  files:
 - imagedefinitions.json

7-2. コスト最適化との連携

Graviton4移行後のコスト最適化フロー

Graviton4への移行で性能向上を確認した後、コスト最適化（RI/Spot/right-sizing）と連携してコスト削減を最大化します。

Step 1: Graviton4へ移行（性能検証フェーズ）
  ↓ CloudWatchでのレイテンシ・エラー率監視（1〜2週間）
Step 2: 性能確認（Graviton3比最大30%向上を実測）
  ↓ 同等性能を維持しながら小サイズへのダウンサイズ検討
Step 3: ダウンサイズ（AWS Compute Optimizerの推奨確認）
  ↓ 新しいインスタンスサイズでSavings Plans適用
Step 4: Savings Plans / RI適用
  ↓ Graviton4のCompute Savings Plansを選択
Step 5: Spot混在比率の最適化
  ↓ price-capacity-optimized戦略で安定調達
Step 6: 定期レビュー（四半期ごと）

AWS Compute Optimizerとの連携

AWS Compute Optimizerは、CloudWatchメトリクスに基づいてGraviton4インスタンスへの移行推奨と適切なサイズを自動的に提案します。

# Compute Optimizerの推奨確認
aws compute-optimizer get-ec2-instance-recommendations \
  --filters name=finding,values=Underprovisioned,Overprovisioned \
  --region ap-northeast-1

# 特定インスタンスの推奨確認
aws compute-optimizer get-ec2-instance-recommendations \
  --instance-arns arn:aws:ec2:ap-northeast-1:123456789012:instance/i-xxxxxxxxxxxxxxxxx

Compute Optimizerはx86からarm64（Graviton）への移行推奨も出力します。推奨に従って移行することで、手動でのサイズ選定の手間を省けます。

Graviton4 Spot活用のベストプラクティス

Graviton4世代のインスタンスをSpotで活用することで、さらなるコスト削減が可能です。

# Spot価格履歴の確認（m8gファミリー）
aws ec2 describe-spot-price-history \
  --instance-types m8g.xlarge m8g.2xlarge c8g.xlarge \
  --product-descriptions "Linux/UNIX" \
  --region ap-northeast-1 \
  --start-time 2025-01-01T00:00:00

Spot中断リスクを軽減するため、複数AZ・複数インスタンスタイプを組み合わせたMulti-AZ構成を推奨します。コスト削減の実際の効果は、インスタンスタイプ・リージョン・時期によって異なります。公式料金ページの最新価格で計算してください。

7-3. 運用への定着

CloudWatchによる移行後のモニタリング

arm64移行後は、x86環境との性能差異を継続的にモニタリングします。

監視すべき主要メトリクスは以下のとおりです。

# CloudWatchアラームの設定（CPUUtilization例）
aws cloudwatch put-metric-alarm \
  --alarm-name "arm64-cpu-high" \
  --alarm-description "Graviton4 CPU利用率アラーム" \
  --metric-name CPUUtilization \
  --namespace AWS/EC2 \
  --statistic Average \
  --period 300 \
  --threshold 80 \
  --comparison-operator GreaterThanThreshold \
  --evaluation-periods 2 \
  --alarm-actions arn:aws:sns:ap-northeast-1:123456789012:ops-alert \
  --dimensions Name=AutoScalingGroupName,Value=myapp-arm64

運用チームへの展開とナレッジ共有

Graviton4移行を組織に定着させるためのベストプラクティスです。

1. アーキテクチャ判断ドキュメントの整備: なぜGraviton4を選択したか、どのファミリーを選ぶかの判断基準をRunbookにまとめます
2. 新規ワークロードのデフォルトarm64化: 新規サービスのインスタンスタイプデフォルトをM8gに設定し、x86採用時は理由を記録します
3. 定期的な移行可否レビュー: 四半期ごとにまだx86で動いているワークロードを棚卸しし、移行の優先順位を更新します
4. コスト削減レポート: 移行前後のコスト比較を月次で経営層に報告し、継続投資の根拠とします
5. インシデント対応フロー: arm64固有の問題が発生した場合のエスカレーションパスをRunbookに定義します

Graviton4移行進捗の可視化

移行進捗の可視化にはタグとAWS CLIを活用します。

# arm64インスタンスの一覧確認
aws ec2 describe-instances \
  --filters "Name=instance-state-name,Values=running" \
  --query 'Reservations[].Instances[?Architecture==`arm64`].[InstanceId,InstanceType,Tags[?Key==`Name`].Value|[0]]' \
  --region ap-northeast-1

# x86インスタンスの一覧確認（移行対象の確認）
aws ec2 describe-instances \
  --filters "Name=instance-state-name,Values=running" \
  --query 'Reservations[].Instances[?Architecture==`x86_64`].[InstanceId,InstanceType,Tags[?Key==`Name`].Value|[0]]' \
  --region ap-northeast-1

この一覧から移行済み率（arm64 / 全インスタンス数）を算出し、四半期ごとの移行目標と照合することで、組織全体での移行進捗を管理できます。

8. 詰まりポイント・アンチパターン・まとめ

8-1. よくある詰まりポイントと解決策

Graviton4世代のインスタンスへの移行や本番運用で遭遇しやすいポイントを整理します。

① arm64移行時にCIパイプラインが壊れる

最も頻繁に報告される問題の一つです。既存のCIパイプライン (GitHub Actions・Jenkins・CodeBuild等) がx86環境を前提に構成されており、arm64向けビルドに対応していないケースです。

症状: Dockerイメージのビルドがx86専用ベースイメージをpullして失敗する、またはビルドは成功してもarm64環境で実行時にクラッシュする。

原因と対処:

# Docker BuildxでMulti-platformビルドを有効化
docker buildx create --name multiarch --use
docker buildx build \
  --platform linux/amd64,linux/arm64 \
  --push \
  -t your-registry/app:latest .

GitHub Actionsでarm64ネイティブビルドを行う場合はAWS Graviton (self-hosted runner) またはarm64対応のGitHub-hostedランナーを活用します。CodeBuildではARM_CONTAINERビルド環境を指定することでGravitonネイティブビルドが可能です。

② x86専用バイナリがGraviton4で動作しない

x86_64向けにコンパイルされたネイティブバイナリ (C/C++バイナリ・JNIネイティブライブラリ等) はarm64環境では直接実行できません。

症状: SIGILL (Illegal instruction) や exec format error、Segmentation Faultが発生する。

対処: AWS Graviton Porting Advisorで事前スキャンを行い、x86依存箇所を特定します。ポータブルなコードへの書き換え、またはarm64向けのビルドを追加します。サードパーティ製ライブラリは公式サイトでarm64版の提供を確認してください。

③ Graviton Porting Advisorの出力件数が多すぎて優先順位がつけられない

Porting Advisorを実行すると数十から数百件の指摘が出て、どこから手をつけるべきか分からなくなるケースです。

対処: Porting AdvisorのレポートはPriority別にフィルタリングできます。まずPriority: HIGHのみに絞って対処し、MEDIUMはその後で対応します。LOWは実際の影響は軽微なため、後回しまたは対応不要なケースが多いです。また既知の誤検知パターンはPRスコープから除外するリストを作成して管理します。

④ EKSクラスターでx86とarm64の混在Nodeにおけるスケジューリング競合

x86とarm64の両方のNodeGroupを持つEKSクラスターで、arm64非対応コンテナがarm64 Nodeにスケジュールされてクラッシュするケースです。

症状: PodがErrorやCrashLoopBackOffになる。exec format errorがコンテナログに出力される。

対処: nodeSelectorまたはnodeAffinityでNodeのアーキテクチャを明示的に指定します。

spec:
  affinity:
 nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
  nodeSelectorTerms:
  - matchExpressions:
 - key: kubernetes.io/arch
operator: In
values:
- arm64

Karpenterを使用している場合は、NodeclaimのNodeSelectorClassでアーキテクチャを指定します。全コンテナイメージがマルチアーキテクチャ対応になれば、スケジューリング競合自体を回避できます。

⑤ ベンチマーク結果が想定より改善しない

「Graviton3比30%改善」という数値を期待して移行したものの、実際の改善幅が数%程度にとどまるケースです。

原因と対処のパターン:

• コンパイルフラグ未最適化: デフォルトの汎用arm64フラグでビルドされており、Graviton4固有の最適化が効いていない。-march=armv9-a+crypto等のフラグを指定してリビルドする。
• JVMチューニング不足: HeapサイズやGCアルゴリズムの最適化が行われていない。Graviton向けにJVMフラグを再調整する。
• ボトルネックがCPU以外: レイテンシのボトルネックがネットワークやディスクI/Oにある場合、CPU性能向上の恩恵は限定的になる。プロファイリングでボトルネックを特定してから移行効果を評価する。
• シングルスレッド主体のワークロード: 並列化が難しいワークロードはコア数増加の恩恵を受けにくい。

⑥ コスト最適化設定 (RI/Savings Plans) がGraviton4インスタンスに適用されない

Graviton3世代 (C7g等) 向けに購入したReserved InstanceやSavings Plansが、Graviton4 (C8g等) に自動適用されないケースです。

原因: RI/SPのスコープはインスタンスファミリーに紐付いており、C7gとC8gは異なるファミリーとして扱われます。

対処: Graviton4インスタンスへの移行タイミングに合わせて、新たにGraviton4ファミリー向けのRI/SPを購入する計画を立てます。移行期間中はオンデマンドで利用しつつ、安定稼働が確認できたら予約購入に切り替えます。

⑦ 移行後に性能劣化が発生した場合のロールバックが難しい

Graviton4へ完全に切り替えた後で性能劣化や想定外の動作が発覚した場合のロールバックに手間取るケースです。

対処: 本番環境への適用前に、EC2 Fleetの混在構成 (x86とarm64を並走) でカナリアテストを実施します。Auto Scaling GroupのMixed Instances Policyを利用することで、段階的にGraviton4の比率を増やしながら移行できます。

{
  "MixedInstancesPolicy": {
 "LaunchTemplate": {
"Overrides": [
  { "InstanceType": "c8g.2xlarge" },
  { "InstanceType": "c7i.2xlarge" }
]
 },
 "InstancesDistribution": {
"OnDemandPercentageAboveBaseCapacity": 50
 }
  }
}

問題が発生した際にGravitonのOverrideを削除することで即座にx86へ戻せます。

⑧ 東京リージョンでのGraviton4 GA時期をインスタンスファミリー別に誤認

東京リージョンでのGraviton4 GA時期がインスタンスファミリーによって異なることを見落とすケースです。R8gは2024年12月に東京GA、C8gは2025年3月に東京GAとなっています。GA前のインスタンスを指定したAuto Scaling設定やCloudFormationテンプレートがエラーになります。

対処: インスタンスタイプを変更する前に、AWS公式ドキュメントまたはEC2コンソールでそのリージョンでのインスタンスタイプの利用可否を確認します。

# 東京リージョンでのインスタンスタイプ確認
aws ec2 describe-instance-type-offerings \
  --region ap-northeast-1 \
  --filters "Name=instance-type,Values=c8g.*" \
  --query "InstanceTypeOfferings[].InstanceType"

8-2. アンチパターンと正解

本番運用でよく見られるアンチパターンとその正解をまとめます。

アンチパターン1: 全ワークロードを一括でGraviton4に移行する

❌ アンチパターン: 「Gravitonに変えればコスト削減になる」という認識のもと、互換性検証をせずにすべてのEC2インスタンスタイプをx86からarm64へ一括で変更する。

✅ 正解: まず影響範囲が小さく、かつarm64対応が確認しやすいWebサーバーやステートレスなAPIサーバーからパイロット移行を開始します。Porting Advisorと実際のテスト実行を組み合わせて互換性を確認してから、段階的に移行範囲を広げます。

アンチパターン2: 公式ベンチマークの「最大30%」をそのまま採用計画に組み込む

❌ アンチパターン: AWSが公表するGraviton3比最大30%改善という数値を根拠に、予算計画や性能改善ロードマップを策定する。

✅ 正解: 「最大30%」はCPU集約型ベンチマークでの参考値です。自社の本番同等ワークロードを使ったベンチマークを事前に実施し、実測値を根拠として計画を立てます。

アンチパターン3: EKSでx86とarm64のNodeを区別せずに運用する

❌ アンチパターン: EKSにGraviton4 NodeGroupを追加したが、NodeAffinityやNodeSelectorを設定せずにPodをデプロイしたため、arm64非対応コンテナがGraviton Nodeにスケジュールされてクラッシュする。

✅ 正解: NodeAffinity/NodeSelectorを適切に設定し、コンテナイメージのアーキテクチャとNodeのアーキテクチャを一致させます。理想的にはすべてのコンテナイメージをマルチアーキテクチャ対応にすることで、スケジューリングの複雑さを解消できます。

アンチパターン4: Graviton4に移行後もx86向けのコンパイル設定のまま

❌ アンチパターン: arm64向けのDockerイメージを作成したが、CFLAGSやcmakeの設定がデフォルトのままでGraviton4固有の最適化が効いていない。

✅ 正解: ネイティブコードのコンパイル時に-march=armv9-a等のGraviton向けフラグを指定します。JavaアプリはJava 17以降を使用し、JVMのARM向け最適化が自動適用されることを確認します。Pythonのnumpy・scipy等の数値計算ライブラリはarm64最適化版をインストールします。

アンチパターン5: Porting Advisorの全出力をそのまま修正しようとする

❌ アンチパターン: Graviton Porting Advisorの出力が200件あり、すべてを修正しようとして工数が膨大になり、移行プロジェクトが停滞する。

✅ 正解: Priority: HIGHに絞って対処し、MEDIUMは移行後の安定化フェーズで対応します。LOWは基本的に無視しても、実行時への影響は軽微なケースがほとんどです。また、誤検知のパターンを除外リストに登録して管理します。

アンチパターン6: 本番移行前にロールバック計画を策定しない

❌ アンチパターン: コスト削減を急ぐあまり、ロールバック手順を用意せずにすべての本番インスタンスをGraviton4に切り替える。問題が発覚した際、復旧に時間がかかる。

✅ 正解: Auto Scaling GroupのMixed Instances Policyを活用し、Graviton4とx86インスタンスを並走させる期間を設けます。問題発覚時はGravitonのOverrideを削除するだけで、即座にx86へ戻せる構成としておきます。

8-3. まとめ

本記事ではGraviton4世代のEC2インスタンスファミリー (C8g/M8g/R8g/X8g) の特性と、arm64移行の実践的なアプローチについて解説しました。

Graviton4はGraviton3比で最大30%の性能向上を提供しますが、この数値は特定のCPU集約型ベンチマークでの参考値です。実際の移行効果は自社のワークロードで実測して判断することが重要です。

移行の第一歩として推奨するのは、まずGraviton Porting Advisorで互換性を評価し、Priority: HIGHの問題を解消することです。次に、ステートレスなWebサーバーやAPIサーバーを対象としたパイロット移行でリスクを限定しながら検証します。コンテナ環境ではマルチアーキテクチャビルドを活用することで、x86とarm64を並走させた段階的移行が実現しやすくなります。

EKSではKarpenterのNodePoolにarm64アーキテクチャを追加し、nodeAffinityで誘導しつつ段階的に比率を引き上げる手順が安全です。ECSではタスク定義のcpuArchitectureをARM64に設定するだけで、FargateでもGraviton4の性能を利用できます。

移行チェックリスト

Graviton4への移行を進める際の最終確認リストです。

• 互換性評価: Porting Advisorを実行してPriority: HIGHの問題を解消済みか
• マルチアーキテクチャビルド: linux/amd64,linux/arm64の両プラットフォームに対応したイメージを用意済みか
• ステージング検証: Graviton4インスタンスで機能テスト・性能テストを実施済みか
• 監視設定: CloudWatchでエラーレート・レイテンシ・CPU使用率を監視する設定が整っているか
• ロールバック計画: Mixed Instances PolicyやKarpenterのweight調整でロールバックできる構成になっているか
• コスト計画: Graviton4向けのRI/Savings Plans購入タイミングを計画済みか

本記事の位置づけ

本記事はGraviton4インスタンスのアーキテクチャ特性と移行技術に焦点を当てています。EC2の基礎概念・AutoScalingの設計パターン・Spot活用はコンピュート本番運用Vol1で詳説しています。Spot/RI/Savings Plansといったコスト最適化の手法はコスト最適化Vol2をご参照ください。

Graviton4への移行は、互換性評価・マルチアーキテクチャビルド・段階的なノード移行という3つの工程を着実に進めることで、性能向上とコスト効率の両立につながります。まずは影響範囲の小さいステートレスなワークロードから着手し、検証を重ねながら適用範囲を広げていくアプローチが、本番環境での安全な移行を支えます。最新世代インスタンスの選定は一度きりの判断ではなく、新しいファミリーの登場やリージョン展開にあわせて継続的に見直していくものとして捉えることが重要です。

8-4. 関連記事