Graviton5 in Production at Honeycomb: Per-service Results From the m8g to m9g Migration

これは2021年以来執筆しているGraviton振り返りシリーズの第4弾です。使用している方法論はいつも同じで、ワークロードを一定に保ち、両世代を同じKubernetes名前空間で同時に実行し、Podごとの数値に語らせるというものです。

TL;DR

Honeycombは、本番環境の共有コンピュートプールの一部をm8g.8xlarge（AWS Graviton4）からm9g.8xlarge（AWS Graviton5）へ移行しました。両世代を60日間並行して運用した結果、すべての測定対象サービスで、Graviton5の方が同一ワークロードに対して11〜26%少ないCPUを使用しました。IngestのP99レイテンシは28%低下し、メトリクスIngestパイプラインのP99は半減し、テールベースサンプリングのキューはP95で44〜73%短くなりました。フリート全体でリグレッションは一切ありませんでした。

Play with the data yourself

About this post

上記に埋め込まれたCanvasは、m8g/m9g A/Bテストの評価に実際に使用した調査内容を読み取り専用かつ公開状態にしたものです。クエリをクリックしたり、データと対話したりできるので、スクリーンショットの数字を読むのではなく自分で確認できます。隅にあるmake fullscreenボタンを押して適切な表示にし、ライト/ダークモードの切り替えも試してみてください。

このシリーズのGraviton4版は手作業で作成し、スクリーンショットを文章に貼り付けていました。今回は、CanvasがGraviton4の記事の手法とグラフをエージェント的に再現し、shepherdのIngestレイテンシ部分を生成しました。ブログ記事を取得し、画像を解析してクエリを再作成・再実行するのに約3分かかりました。これがCanvasのエージェント機能が実際に価値を発揮する部分です。数値と結論は筆者のものですが、以前は午後がかりだった作業の大部分がツールの成果物になりました。

What was measured

このフリートで実行されている5つの主要なステートレスサービスは以下の通りです：shepherd（OpenTelemetry Ingest）、refinery（テールベースサンプリング）、beagle（SLO評価）、newf（サービスマップ）、kelpie（異常検知）。比較期間は2月20日から4月21日までで、m8g.8xlargeとm9g.8xlargeのPodが同じ名前空間で同時に実行されていたため、すべての比較は同一ワークロードにおけるPod単位のものです。

Honeycombのpoodle（API/クエリ）サービスは比較対象に含めていません。CPU負荷が比較的低いため、古い世代に優先的にスケジュールし、最新のシリコンは実際に恩恵を受けられるサービスに割り当てています。これが、複数のGraviton世代にまたがるフリートから価値を抽出する方法であり、世代ごとにすべてを置き換えるわけではありません。

Per-service CPU efficiency (60 days, honeycomb-production namespace)

newfはGraviton4でP99時にCPUリクエスト割り当てを142%超過してバーストしていました。Graviton5では114%まで改善し、依然としてリクエストを超過していますが、かなり圧力が軽減されています。beagleのP99が同一スループットで94%から65%に低下したことは、同一の作業がより速く完了していることを示す、フリート内で最も明確な証左です。

Ingest pipeline: where the latency came from

ネットワーク受信は両世代でほぼ横ばいです（トレースでAVG 8.18ms対8.02ms。ログとメトリクスでも実質的に同一）。ネットワークレイテンシは制御できないクライアント側のばらつきが支配的であるため、シリコン世代間でこれらの数値が同一に見えます。改善はすべてCPUバウンドの処理にあり、シリコンだけが変わったことを考えると当然の結果です。

パイプライン別のTotal root-span duration P99：

handle_batched_event内（Kafkaへの書き込み段階、パイプライン別P99）：

メトリクスパイプラインが最も恩恵を受けました。Kafkaへの書き込み全体のP99が880µsから440µsへ、50%削減されています。メトリクスはターゲットフィールドを共有するイベントを積極的にコンパクト化・正規化するため、元々CPU負荷の高いパイプラインでした。Graviton5はその最も痛かった箇所に改善をもたらしました。

Tail-based sampling: queue depths are the clearest signal

Refineryのスループットは、Podがバッファされた作業をどれだけ速く処理できるかに依存します。2026年4月18〜20日、約15台のm8g Podと並行して3台のm9g Podを運用し、Refinery 3.2.0を使用し、ラウンドロビンで同一ワークロードを処理した結果：

同一ワークロード・同一負荷で、キューが劇的に短くなりました。Refineryを運用する場合、キュー深度はバースト負荷時にスパンをドロップするかどうかを決める指標です。受信キューP95を約4分の3削減することは、見せかけの数値ではなく実質的な余裕を生み出します。

Streaming services: same work, less CPU

beagle、newf、kelpieはいずれもKafkaコンシューマーであるため、スループットはパーティションに依存し、CPUには依存しません。これらのサービスのスパン継続時間は、rawな処理速度ではなくティック間隔やパーティション割り当てを反映します。

beagle（SLO評価、1分に1回ティック）：1ティックあたりのデータセット数は2,347対2,322、評価したSLO数は6,113対6,147。スループットは同一。AVG CPUは11%低下、P99 CPUは31%低下。

newf（サービスマップ）：1回の実行あたりの処理スパン数は92.4対91.6。スループットは同一。AVG CPUは23%低下、AVG processing lag P50は0.04sから0.02sへ半減。

kelpie（異常検知）：AVGおよびP99 CPUが26%低下。小規模なローカル操作（loadDatasetEntry、Make Schemas List）のP99レイテンシは25〜55%低下し、CPU効率の改善と一致しています。

A floor—not a ceiling—on savings

これらの数値は、Pod数を固定した状態でのパフォーマンスを測定したものです。両世代で同一の作業を行う混合フリートを運用しましたが、インスタンスを削除したり、CPUリクエストを引き上げたり、Graviton5に負荷をかけたりしてレイテンシが悪化するポイントを探したわけではありません。したがって11〜26%のCPU効率向上は、等価なワークロードで期待できるインスタンス数削減の下限であり、上限ではありません。Graviton5の各ボックスにより多くの作業を詰め込む容量チューニングを行えば、ここに示したパフォーマンス向上に加えてさらなる節約が得られるはずです。

re:Inventの直前にshepherdだけでそのようなチューニングを実施しました。それが36%というコアあたりのスループット数値の出所です。本記事の数値は、単一サービスを限界までチューニングしたものではなく、ワークロードの全範囲をカバーする長期的なパッシブ実験から得られたものです。

参考：4年前にGraviton2で同等の検証を行った際には、最終的にサービスあたり20%少ないワーカー数で運用できました。そのコスト効果は、以降のEnterprise Discount Program更新やCompute Savings Plansを通じてさらに積み重なりました。Graviton5も同様の機会であり、各世代が当初のarm64移行による節約の上に積み重なっていきます。

Bottom line

コンピュートバウンドのサービスでは、Graviton5でGraviton4比でCPUが16〜22%低く、P99レイテンシが16〜28%低くなりました。サンプリングキューの深度は同一ワークロードでP95時に44〜73%低下しました。Kafkaバウンドのストリーミングサービスは、11〜26%少ないCPUで同一の作業を行いました。フリート全体でリグレッションはありませんでした。

Graviton5は、以前のGraviton世代を使用している場合でも、x86からの移行を検討している場合でも魅力的です。

How to evaluate this for your own fleet

サービスごとの改善は、単一の見出し数値よりも重要です。コンピュートバウンドと入力キューバウンドのどちらに位置するかによって、改善がレイテンシ、余裕、またはキュー深度のいずれとして現れるかが決まり、それに応じて測定方法も変わります。「平均改善率は？」から始めないでください。各サービスのボトルネックに合わせて計装し、ワークロードのばらつきが平準化されるのに十分な期間、混合フリートを運用し、Podごとのデータがどのサービスを最初に移行すべきかを示すようにしてください。