今日は読書感想文
第５章：How to Manage Eventual Consistency
要約
結果整合性の課題と対処法についていくつかのパターンを紹介
前提
分散システムではモノリスで実現できていた強いトランザクションは実現できない。なので、最終的に整合させる結果整合性という考えを受け入れる
結果整合性の課題
- 最終的に整合する状態になるまでの間は不整合な状態が存在する
- その不整合な状態のときをどのように受け入れて対応するか検討必要
対策いろいろ
※AI使わないといいながらCopilotにまとめてもらいました。。
| 対処法 | 概要 | 実例 | メリット | デメリット |
|---|---|---|---|---|
| イベントスキーマの工夫 | イベントに必要な情報を含めて、他サービスへの依存を減らす | 在庫イベントに全サイズの在庫情報を含めて通知 | 外部呼び出し不要で高速・高可用性 消費者側の実装が簡単 |
イベントサイズが大きくなる 情報が取得できない場合は複雑化 |
| ドメイン境界の適用 | サービスを明確なドメインに分割し、整合性の問題を内部で閉じ込める | 在庫管理と通知サービスを別ドメインに分離 | 境界内で整合性を担保できる 外部への影響を最小化 |
境界間の連携が複雑化 処理時間が増加する可能性 |
| イベントバージョン管理 | イベントにバージョンやタイムスタンプを持たせ、整合性の判定に使う | APIのレスポンスとイベントのバージョンを比較して再試行判断 | 実装が簡単 整合性の遅延を検知しやすい |
再試行の失敗時に補償処理が必要 パフォーマンスに影響 |
| 状態の保存（ローカルキャッシュ） | 他サービスの情報をローカルに保存して参照 | 通知サービスが在庫情報を自前で保持 | 外部依存がなく高可用性 高速なレスポンス |
ストレージコスト増 データの同期が必要 冗長なデータ管理 |
| メモリへのバッファリング | 一時的にイベント情報をメモリに保持して参照 | 通知サービスが在庫イベントを一定時間メモリに保持 | 高速処理 永続化不要で管理が簡単 |
大規模データには不向き メモリ消費が増加 |
| エンドツーエンド原則の活用 | 中間サービスの整合性を犠牲にし、最終的なビジネスルールで整合性を担保 | 商品購入時に在庫を最終確認して注文処理 | 柔軟な設計が可能 中間サービスの負荷軽減 |
最終処理に同期が必要 UIと整合性のズレが発生する可能性 |
| 高速処理による見かけ上の整合性 | 処理速度を上げて整合性のズレ時間を短縮 | Kafka + Kubernetes + Prometheus によるオートスケーリング | ユーザーにとっては整合性が保たれているように見える UX向上 |
高速化のためのインフラ整備が必要 ピーク時の対応が難しい場合もある |
Claudeで生成した画像
イベントスキーマの工夫 - 全サイズ情報を含めた在庫イベントの流れ
ドメイン境界の適用 - 在庫管理と通知の明確な分離
イベントバージョン管理 - バージョン比較による整合性判定
状態の保存 - ローカルDBによる高速アクセス
メモリバッファリング - TTL付きメモリキャッシュ
エンドツーエンド原則 - 購入時の最終確認フロー
高速処理 - Kafka + Kubernetes + Prometheusの構成
おわりに
結果整合性を実現する方法について意外とたくさんの選択肢があってメモメモでした。方法論：ドメイン境界の適用がよくわかんなかったので３章と４章を読んでから改めて５章を見たいと思います！