前置き
同期通信かつ結果整合性のマイクロサービスを、徐々に非同期かつ結果整合なマイクロサービスへ分割
その後一定期間を経て、
インフラ基盤も完全に分離し、サービスメッシュ上で疎に連携し合うシステムオブシステムズにする
までの一連の移行のステップをフレームワーク化してみました。
前回の記事で深堀できなかった部分、とくに
「どんなメトリクスを見て判断すべきか？」
「カオス実験やポストモーテムがどう絡むのか？」
という部分を絡めて深ぼっていきたいと思います。
フェーズ0：準備と現状分析
移行を開始する前に、現状を正確に把握し、客観的なベースラインを確立します。
目的
現在の同期通信ベースのアーキテクチャが抱える課題を、データで定量的に証明する。
具体的なステップ
①. 分散トレーシング、メトリクス、ログ収集といったオブザーバビリティ（可観測性）基盤を導入・整備します。
②. 主要なビジネスプロセスにおける、サービス間の同期呼び出しの依存関係とパフォーマンスを可視化します。
判断指標となる運用メトリクス
レイテンシー (P99)
サービス間の同期APIコールの応答時間。特に遅延が大きい、あるいは不安定な連携経路を特定します。
エラーレート
特定のサービスがダウンした際に、それを呼び出している他のサービスで連鎖的に発生するエラー率。
依存関係マップ
どのサービスが他の多くのサービスから同期的に呼び出されているか（＝ボトルネックや単一障害点になりやすいか）を特定します。
プロアクティブな障害予防活動
カオス実験
・仮説
「我々のオブザーバビリティ基盤は、単一インスタンスの障害を正確に検知できる」
・実験内容
Kubernetes環境で特定のPodを意図的に停止させ、監視システムがそれを検知し、自動復旧（自己修復）が働くまでの時間を計測します。
これは、今後の全ての実験の安全性を担保するベースライン実験です。
ポストモーテム文化の醸成
この段階で発生したインシデントのポストモーテムでは、
「なぜ我々はこの障害を事前に検知できなかったのか？」
という問いに焦点を当てます。
現在の監視の限界を明らかにすることが、次のフェーズへの移行の正当な理由となります。
フェーズ1：非同期化への移行（論理的な分離）
ベースライン分析に基づき、最も課題の大きい部分から段階的に非同期化を進めます。
インフラはまだ物理的には共有のままです。
目的
サービス間の時間的な結合をなくし、耐障害性とスループットを向上させる。
具体的なステップ
①. メッセージブローカー（Kafka, SQSなど）を導入します。
②. フェーズ0で特定した最も問題のある同期連携から、ストラングラー・フィグ・パターンを使って非同期連携に切り替えます。
（例：注文サービスが在庫サービスを直接呼び出すのをやめ、注文作成イベントを発行し、在庫サービスがそれを購読する形に変更する）
③. このプロセスを、他の連携にも少しずつ広げていきます。
判断指標となる運用メトリクス
API応答時間 (P99)
非同期化されたサービス（例: 注文サービス）のAPI応答時間が劇的に短縮・安定したことを確認します。
エラーレートの改善
依存先サービス（例: 在庫サービス）が一時的にダウンしても、注文サービスのエラーレートが上昇しない（＝疎結合になっている）ことを確認します。
キューの深さ/処理遅延
メッセージブローカーのキューが定常的に増え続けていないか、コンシューマーが十分に処理できているかを確認します。
プロアクティブな障害予防活動:
カオス実験
・仮説①
「メッセージブローカーが一時的に高遅延になっても、メッセージの生産者（Producer）は影響を受けない」
・実験内容①
ネットワーク遅延注入ツールを使い、生産者とブローカー間の通信に数百ミリ秒の遅延を注入します。生産者側のエラーレートやパフォーマンスに変化がないことを確認します。
・仮説②
「メッセージの消費者（Consumer）がダウンしても、生産者は正常に稼働し続け、メッセージは失われない」
・実験内容②
消費者サービスを数分間停止させます。
生産者が正常稼働を続けること、キューの深さが増加すること、そして消費者サービス復旧後にメッセージが処理されることを確認します。
ポストモーテム文化の醸成
このフェーズのインシデントでは、
「メッセージの処理遅延やデータ不整合を、分散トレーシングを使って迅速に追跡できたか？」
を分析します。
非同期システム特有のデバッグの難しさをチームが克服できているかを確認します。
フェーズ2：安定化と観測
アーキテクチャが大きく変わったため、インフラ分離という次の大きなステップに進む前に、現状の非同期アーキテクチャを安定稼働させ、その特性を深く理解します。
目的
新しい非同期アーキテクチャでの運用に習熟し、安定性を証明する。
具体的なステップ
①. 非同期通信を前提としたアラートやダッシュボードを整備します。
②. 少なくとも数回のビジネスサイクル（例: 月次処理、セール期間など）を経験し、高負荷時の挙動を観測します。
判断指標となる運用メトリクス
SLO/エラーバジェット
各サービスが、新しいアーキテクチャの下でSLOを安定して達成できていることを確認します。
MTTR (平均修復時間)
非同期システムで問題が発生した際に、分散トレーシングなどを活用して、以前と同等かそれ以下の時間で問題を解決できるかを確認します。
リソース使用率の分析
共有インフラ上で、特定のサービスが他のサービスのリソース（CPU, メモリ, I/O）を食いつぶす「ノイジーネイバー問題」が発生していないかを分析します。
この問題の発生が、次のインフラ分離の強力な動機となります。
プロアクティブな障害予防活動
カオス実験
・仮説
「特定のサービスに意図的に高負荷をかけると、共有インフラ（同一ノード/クラスター）上の他のサービスのパフォーマンスに影響が出るはずだ」
・実験内容
負荷試験ツールを使い、あるサービスにCPUやメモリを大量に消費させます。
同居している他のサービスのレイテンシーやエラーレートが悪化することを観測し、
インフラ分離の必要性をデータで証明します。
もちろん、批判的に「分離しなくていい」と示すデータも必ず集めてください。
ポストモーテム文化の醸成
「ノイジーネイバー問題」によって引き起こされたインシデントを分析します。
ポストモーテムのアクションアイテムとして、
「インフラ分離のアーキテクチャ設計を開始する」
が挙がることが、このフェーズの成功の証です。
# フェーズ3：インフラ分離とサービスメッシュ導入
論理的な分離が完了し、運用も安定した最終段階として、物理的な分離に着手します。
そして、完全に無法地帯の中で運用されることを防ぐために、サービスメッシュで一定の統制をかけます。
目的
完全な障害影響範囲の分離（フォルトアイソレーション）を実現し、統一されたガバナンスを適用する。
具体的なステップ
①. サービスごと（あるいはサービス群ごと）に、独立したインフラ基盤（新しいK8sクラスターなど）を構築します。
②. これらのインフラを横断して管理できるサービスメッシュのコントロールプレーンを導入します。
③. フェーズ2で安定稼働させたサービスを、サイドカーと共に新しいインフラに移行します。
④. サービスメッシュ上で、mTLSによる暗号化やアクセス制御といった、共通の運用ポリシーを適用します。
判断指標となる運用メトリクス
Blast Radius（影響範囲）の検証
カオスエンジニアリングを実践し、あるインフラ基盤を意図的に停止させても、他のインフラ上で稼働するサービスには全く影響がないことを確認します。
ポリシー準拠率
サービスメッシュのテレメトリを使い、全てのサービス間通信がセキュリティポリシー
（例: mTLS）に準拠していることを証明します。
プロアクティブな障害予防活動
カオス実験
・仮説①
「サービスメッシュの制御プレーンがダウンしても、既存のサービス間通信（データプレーン）には影響がない」
・実験内容①
IstiodなどのコントロールプレーンのPodを停止させ、サービス間の通信が継続することを確認します。
・仮説②
「あるインフラクラスター全体へのネットワークが遮断されても、他のクラスター上のサービスは正常に稼働し続ける」
・実験内容②
ネットワークポリシーやクラウドの機能を使って、クラスター間の通信を遮断し、障害の影響が完全に分離されていることを実証します。
ポストモーテム文化の醸成
この段階でのインシデントは、サービスメッシュの複雑な設定ミスや、広域ネットワークの問題などが原因となります。
ポストモーテムの成果は、
・全社共通のガバナンスポリシーの改善
・より安全な設定変更プロセスの標準化
へと繋がっていきます。