マルチ環境のCPUアーキテクチャ・ドリフト: Intelに戻すかGravitonに前進するか

まとめ

• マネージドサービスのエンジンパッチ識別子が arm と intel に割れていたのが発端。これはインスタンスタイプ（node_type）のCPUアーキの写像で、AWSとしては正常挙動だった
• 本当の問題はパッチではなく、環境間でCPUアーキと世代がずれていたこと。しかも本番だけが数世代前のIntel系に据え置かれていた
• 揃える方向は「本番をGravitonに前進させる」が正解。検証を旧世代Intelに戻すのは退化で、コスト・性能・将来の移行工数すべてで損をする
• 本番と検証でアーキが割れている間は、検証は本番の忠実なリハーサルにならない

発端はパッチ識別子の食い違い

マネージドキャッシュのメンテナンスパッチを見ていて、同じ日付のパッチなのに、検証環境では ...-arm、本番では ...-intel という別の識別子が当たっているのに気づいた。同じサービスの同じ日のパッチが割れているのはおかしい、自分が何か作業でやらかしたのでは、と思って調べ始めた。

結論から言うと、これはミスではなかった。ElastiCacheやRDSのようなマネージドサービスは、エンジンのパッチをインスタンスのCPUアーキ別にビルドしている。node_typeがGraviton（t4g系＝ARM）ならARMビルド、Intel系（t2/m5など）ならIntelビルドが当たる。つまりパッチ識別子のarm/intelは、既にnode_typeが環境間で食い違っていたことを映しているだけだった。

パッチが割れたのは症状であって原因ではない。原因は、環境ごとにCPUアーキと世代がバラバラになっていたことにある。

3環境の実態を並べる

マネージドDB・キャッシュ・ドキュメントDBの定義を3環境ぶん突き合わせると、こうなっていた。

リソース	本番	検証(staging)	開発(dev)
DB(MySQL)	m5系 (Intel)	t3系 (Intel)	t4g系 (ARM)
キャッシュ(Redis)	t2系 (Intel)	t4g系 (ARM)	t4g系 (ARM)
ドキュメントDB	r5系 (Intel)	t4g系 (ARM)	定義なし

本番はDB・キャッシュ・ドキュメントDBのすべてが数世代前のIntel系（t2/m5/r5）で揃っている。逆に言えば、本番だけが近代化から取り残されていた。検証・開発は作り直しやアップデートのたびに現行世代のGravitonへ寄っていた。

割れは移行作業で持ち込まれたものでもなかった。キャッシュのARM化は環境の作り直しより前から既にそうなっていて、移行はアーキを変えていない。近代化された環境が先に現行世代へ動いていて、本番だけが据え置かれていた、という話だった。

Intelに戻すべきだったのか

ここが本題。「検証が次世代のアーキだったとしても、本番のIntelに揃えるべきだったのか？」

答えはNo。揃える方向が逆で、「本番をGravitonに前進させて揃える」が正しい。

観点	検証をIntelに戻す	本番をARMに上げる
方向	退化（現行世代→旧世代）	前進（旧世代→現行世代）
コスト	Gravitonの割安を捨てる	同等スペックで安くなる
性能・世代	EOLが近い世代に逆戻り	現行世代の性能・機能
将来	どうせいつかARM移行が要る＝二度手間	一度で終わる

RDS・ElastiCache・ドキュメントDBのようなマネージドサービスはGravitonを正式サポートしているので、Intelに留める技術的な必然がない。managedである以上、アプリのバイナリ互換を気にする必要も薄い。だからわざわざ旧世代のIntelに寄せる理由がない。

Intelに揃えるのが正解になるのは、本番をARMにできないハードな阻害があるときだけだ。ARMビルドのないネイティブ依存があるとか、x86前提のライセンスやベンダーアプライアンスに縛られているとか、検証コストに見合わないほど寿命の短いアプリだとか。マネージドDB/キャッシュはこれに当たらない。

「検証は本番のミラー」を取り違えない

「検証環境は本番の忠実なミニチュアであるべき」という原則はある。ただしこれは「古い方に合わせろ」ではなく「単一のtargetに収束させろ」という意味だ。targetは前向き（Graviton）に取り、本番を追随させてズレている期間を短くするのが筋になる。

正しい運用は、検証を次世代のパイロットにして、検証が済んだら速やかに本番も同じアーキへ動かし、split期間を最小化すること。アンチパターンは、検証を先行更新したまま本番を放置して、split（食い違い）を長期間ぶら下げてしまうこと。今回はまさに後者で、キャッシュのアーキが1年以上ずっとt2(Intel) vs t4g(ARM)のままだった。

split期間中は本番と検証でCPUアーキが違うので、検証が本番の忠実なリハーサルにならない。x86とARMでは、ネイティブ拡張を持つ言語パッケージのビルド、ドライバのバイナリ、性能特性、稀なアーキ固有バグなどで差が出うる。「検証でOKだったから本番もOK」が成立しない期間が生まれる。これがsplitを放置する本当のコストだった。

一般化した教訓

• パッチや設定の食い違いを見つけたら、まずそれが症状か原因かを切り分ける。今回のarm/intelは症状で、原因は上流のアーキ・ドリフトだった
• 環境の作り直しや世代アップは、ドリフトの発生点になりやすい。作り直すたびに他環境との差分を必ず取る
• アーキを揃えるときは「古い方に合わせる」ではなく「現行世代に前進させて収束」を選ぶ。退化は将来の二度手間を生む
• 本番と検証でアーキが割れている間は、検証は本番の完全なリハーサルにならないと意識しておく

最初は自分の作業でアーキを割ってしまったのかと焦ったが、割れは移行より前からあって、むしろ本番だけが更新されずに置いてけぼりになっていた、というのが実態だった。ヒヤッとした分、次に環境を作り直すときは本番との差分を最初に取る、というのは体に染みたと思う。