前置き
私の問い
なぜ、インシデント時の復旧業務などのSRE文脈には、イベントソーシングのような実装がされているケースが少ないのでしょうか？ これはずっと思っていることです。
インシデント対応は、いかに素早くかつ正確な運用業務であるはずです。
にもかかわらず、ドキュメントは整備されていないし、ノリで経験則的にやられてしまいがちな印象を多く受けます。
本来、属人化を排除し、一定水準以上の素早い復旧を実現するためには、復旧シナリオ中の
「誰がいつ何をし、その結果システムの状態はどう変化したのか？」
という唯一の真実を、アプリ層でも、インフラ層でもログとして残す
ことで、再現性の高いポストモーテムが実現でき、組織は文化も含めてインシデントに強い状態を作り上げられるようになるのではないでしょうか？
今回の最大の論点
SREが目指す理想とイベントソーシングの原則には、確かに重なる部分が多くあります。
インシデントの再現性を高め、属人性を排除するという目的は、まさにSREの中心的な価値観です。
それにもかかわらず、インシデント復旧の文脈で「イベントソーシング」というアーキテクチャパターンで実装されるケースが少ないのはなぜなのか？
💡 理想と現実のギャップ：なぜイベントソーシング的に実装されないのか？
これを今回の論点にします。
先に結論
結論から言うと、SREはイベントソーシングの「思想」を別の形で実現しているため、
アプリケーションアーキテクチャとしてのイベントソーシングを直接導入する必要性が低いからです。
1. 目的と粒度の違い
イベントソーシングが直接採用されにくい主な理由は、コストと複雑性、そしてより現実的な代替手段の存在にあります。
イベントソーシング
主にアプリケーションのビジネスロジックの状態をイベントの連続として記録・再構築するためのアーキテクチャパターンです。
「商品がカートに追加された」「送金が完了した」 といったドメインイベントを扱います。
SREのインシデント対応
インフラ、アプリケーション、ネットワークなど、システム全体の運用上の状態変化を追跡します。
「デプロイが実行された」「CPU使用率が90%を超えた」「設定ファイルが変更された」
といった、より広範で多様なイベントが扱う対象です。
課題点
インシデント対応で求められるのは、ビジネスドメインのイベントログではなく、システム全体の運用イベントの相関関係です。
これを単一のイベントソーシングシステムで実現しようとすると、設計が極めて複雑になります。
2. 高い実装・運用コスト
イベントソーシングは強力なパターンですが、その導入は正直簡単ではありません。
その理由として、以下が主に上げられます。
専門知識
イベントストアの選定、イベントのバージョン管理、スナップショット戦略、CQRS（コマンド・クエリ責任分離）パターンの導入など、専門的な知識と設計が必要です。
しかも、通常のRDBからの移行も結構骨の折れる作業です。
新たな障害点
イベントストア自体が障害点になる可能性があり、その運用・監視コストもかかります。
即時性の欠如
インシデントの最中に、過去の全イベントをリプレイして現在の状態を正確に把握するのは、時間がかかりすぎて現実的ではありません。
インシデント対応中に復旧作業者に求められるのは、
「今、何が起きているか」を即座に把握できる
ことです。
3. 「十分な代替手段」の存在
SREの実践では、イベントソーシングが目指す「唯一の真実」や「再現性」を、複数のツールやプラクティスを組み合わせることで、より現実的に実現しています。これらが事実上の「運用イベントソース」として機能しています。
🔍 可観測性 (Observability) の三本柱
ログ
構造化ログとして「何が起きたか」を記録します。
「いつ、どのサービスで、どんなエラーが発生したか」 を詳細に追跡できます。
メトリクス
「システムの状態がどう変化したか」 を時系列データで定量的に記録します。
CPU使用率、レイテンシ、エラーレートなどがこれにあたります。
トレース
リクエストがシステム内の各サービスをどのように伝播したかを記録し、
「なぜそうなったか」 の因果関係を追跡します。
⚙️ Infrastructure as Code と GitOps
TerraformやAnsibleなどの構成ファイルと、その変更履歴（Gitのコミットログ）が、
「誰が、いつ、インフラにどんな変更を加えたか」という唯一の真実 として機能します。
Pull Requestのレビュー履歴やコメントも、なぜその変更が行われたのかを知るための重要な文脈情報となります。
☁️ クラウドサービスの監査ログ
AWS CloudTrailやGoogle Cloud Audit Logsなどは、コンソールやAPI経由で行われた操作をすべて記録します。これもまた、強力な「イベントソース」です。
結論：思想は同じ、実現方法が違う
「唯一の真実を記録し、再現性の高いポストモーテムを実現する」という理想は、現代のSREプラクティスの核心です。
多様なソースの組み合わせ
しかしSREは、単一の壮大なイベントソーシングシステムを構築するのではなく、
「Gitのコミットログ」
「各種ツールの監査ログ」
「構造化されたアプリケーションログ」
「メトリクス」
といった、それぞれの領域に特化した「イベントソース」を複数持ち、それらをインシデント時に横断的に分析・相関させることで、より迅速かつ現実的に問題解決を図ります。
インシデント後のポストモーテムでは、これらの多様なデータソースを合わせることで、
「誰がいつ何をし、その結果システムの状態がどう変化したのか」 を再構築し、再現性の高い学びを得ています。
思想のベースは同じ
つまり、SREはイベントソーシングの「思想」を、より分散的かつプラグマティックなアプローチで実現していると言えます。