オンプレからクラウドへ移行したあと、本番障害が起きて初めて監視の穴に気づく、という経験をしたインフラ担当者は少なくないはずです。今回はNASAの火星探査機Curiosity（キュリオシティ）のソフトウェア検証事例を手がかりに、クラウド運用における監視設計と障害対応の落とし穴を整理します。
宇宙探査機のソフトウェアと業務システムは別世界に見えますが、検証の考え方には共通点があります。地上のシステムは障害が起きても再起動やロールバックで復旧できますが、火星探査機は一度不具合を出すと物理的に修正に行けません。この「後戻りできない」制約のもとで、NASAのMSL（Mission Data System、コンポーネント指向の状態管理フレームワーク）チームがどう検証を設計したかを見ると、クラウド移行時に見落としがちな監視の弱点が浮かび上がります。
何が起きるか：ステージング検証をすり抜ける障害
クラウド移行プロジェクトでよくあるのは、ステージング環境でのテストは通過したのに本番で障害が出るパターンです。
典型例は、オートスケーリングによるインスタンス増減のタイミングで発生する競合状態（レースコンディション、複数の処理が同時に同じリソースを奪い合う不具合）です。ステージングでは負荷が低く並行処理が発生しにくいため、この種の不具合は再現しません。
本番相当のトラフィックがかかって初めて、非同期処理の順序が崩れてデータ不整合が起きる、といった形で顕在化します。監視ダッシュボードにはCPU使用率やレイテンシは表示されていても、こうした状態遷移の異常は最初はエラー率の微増としてしか見えないため、対応が遅れがちです。
なぜ起きるか：検証手法の限界を段階的に見る
従来型の検証手法には、大きく分けて4つのアプローチがあります。テスト（決められた入力に対する出力の確認）、デモンストレーション（インターフェースの応答確認など観測可能な性質の確認）、インスペクション（設計書やコードの人手レビュー）、分析（統計的・数理的なデータ処理による整合性評価）です。
これらはいずれも有効な手法ですが、並行処理や分散アーキテクチャに対しては構造的な限界があります。人手によるレビューでは、マルチスレッドの競合状態や割り込みのタイミングによる遅延を見抜くことはほぼ不可能です。
さらに重要なのは、実行テストは「不具合の存在」は証明できても「不具合の不在」は証明できないという点です。テストで確認できるのは、実際に実行された経路だけです。分散システムが取りうる非同期の状態の組み合わせは膨大で、テストで網羅しきれない部分に競合状態が潜みます。
クラウド環境ではこの問題がさらに増幅されます。マネージドサービス側のスケーリング判断、ネットワークの揺らぎ、複数リージョンにまたがる整合性など、オンプレのテスト環境では再現しにくい要素が本番にだけ存在するためです。監視設計がメトリクス収集だけに寄っていると、この「テストで踏めなかった経路」の異常を検知する仕組みが抜け落ちます。
加えて、要求仕様の曖昧さが後工程で複利的に膨らむ問題も見逃せません。移行初期の「とりあえずクラウドに乗せる」という要求定義が曖昧なまま進むと、後工程の統合テストで矛盾が発覚し、スケジュール圧縮によって検証工程がさらに削られる、という悪循環に陥ります。
自分のプロジェクトが該当するか確認する
以下の観点で、現在の監視・検証体制を点検してみてください。
- ステージング環境の負荷パターンが本番のトラフィック特性（ピーク時の同時接続数、リクエスト間隔のばらつき）と近いか
- オートスケーリングやマネージドサービスの内部挙動（スケールイン・アウトのタイミング）を監視対象に含めているか
- メトリクス監視だけでなく、分散トレーシング（リクエストがサービス間をどう通過したかを追跡する仕組み）を導入しているか
- 障害の再現手順が「本番でしか再現しない」で終わっていないか、根本原因分析の記録が残っているか
- 移行時の要求定義書やアーキテクチャ設計書が、統合テストの直前まで頻繁に変更されていないか
確認コマンドの例として、AWSであればCloudWatchのメトリクス保持期間と収集間隔を見直すことができます。
aws cloudwatch list-metrics --namespace AWS/EC2 --dimensions Name=AutoScalingGroupName,Value=your-asg-name
aws cloudwatch get-metric-statistics --namespace AWS/EC2 --metric-name CPUUtilization --statistics Average --period 60 --start-time 2024-01-01T00:00:00Z --end-time 2024-01-01T01:00:00Z --dimensions Name=AutoScalingGroupName,Value=your-asg-nameこのコマンドで、スケーリングイベントの前後でメトリクスの粒度が粗すぎないか確認できます。1分間隔の標準メトリクスでは、数秒単位で起きる競合状態を捉えられないことがあります。
対策の手順
具体的な対策は次の順で進めることをおすすめします。
1. 本番トラフィックのレプリカ（複製）をステージングに流すシャドーテストを導入し、負荷パターンの差を埋めます。
2. 分散トレーシングツール（OpenTelemetryなど）を導入し、サービス間のリクエスト経路と処理時間を可視化します。
3. アラートのしきい値を「絶対値」だけでなく「前週比・前日比の変化率」でも設定し、微増の異常を早期検知します。
4. 障害発生時のポストモーテム（事後検証報告）で、根本原因を「なぜ検証工程で見つからなかったか」まで掘り下げて記録します。
5. マネージドサービスのバージョンや設定変更履歴を、IaC（Infrastructure as Code、構成をコードで管理する手法）のコミットログで追跡できる状態にします。
特に4番目のポストモーテムは軽視されがちですが、NASAの事例が示すように、検証手法の限界を認識せずに同じ手法を繰り返すと、同種の不具合が形を変えて再発します。「テストは通ったのになぜ本番で起きたか」を毎回言語化する習慣が、監視設計の改善サイクルを回す起点になります。
移行前後で確認しておきたいこと
クラウド移行における監視の落とし穴は、多くの場合「テストの限界を意識していないこと」から生まれます。
要点を整理すると次の3点です。
- ステージングと本番のトラフィック特性の差が、競合状態を隠す最大の要因になる
- メトリクス監視だけでは非同期処理の異常を見抜けないため、分散トレーシングと変化率アラートを併用する
- 障害対応はポストモーテムで「検証工程のどこに穴があったか」まで掘り下げて初めて次に活きる
まずは自分のプロジェクトのCloudWatchやDatadogなどの監視設定を開き、メトリクスの収集間隔とアラートのしきい値を見直すところから始めてみてください。