CQRSトレードオフガイド
CQRSにおける一貫性・可用性・スケーラビリティのトレードオフを分析し、設計判断を支援する。
CAP定理に基づく評価軸
CQRSが一貫性と可用性を重要な評価軸として採用する理由は、CAP定理に基づいている。
分散システムでは、ネットワークの分断や障害が発生した場合、一貫性と可用性の間でトレードオフが生じることが避けられない。CQRSはこのトレードオフを巧みに活用する。
| モデル | 重視する特性 | 理由 |
|---|---|---|
| 書き込みモデル | 一貫性 | 現在の状態に基づく意思決定・計算を行うため |
| 読み込みモデル | 可用性 | 最新の状態でなくても十分な場合が多いため |
この分離により、一貫性と可用性を同時に追求するのではなく、各モデルで最適な戦略を選択できる。
CQRSの2つの形態
シンプルなCQRS（イベントソーシングなし）
- 非CQRSベースのシステムと同様の一貫性を保証
- 読み書きモデルの論理的な分離
- 既存のRDBMS上でも実装可能
CQRS + イベントソーシング（CQRS/ES）
- 読み込みモデルと書き込みモデルで一貫性レベルを独立して制御
- 書き込みモデル: 強い一貫性
- 読み込みモデル: 結果整合性
- システムの柔軟性が大幅に向上
3つの評価軸
1. 一貫性への影響
書き込みモデル: システムの現在の状態に基づいて意思決定や計算を行うため、強い一貫性が求められる。
読み込みモデル: 最新の状態ではなくても十分な場合が多く、結果整合性が適用される。これにより、パフォーマンスと応答速度の向上が期待できる。
| 形態 | 書き込みモデルの一貫性 | 読み込みモデルの一貫性 |
|---|---|---|
| シンプルなCQRS | 従来と同等 | 従来と同等 |
| CQRS/ES | 強い一貫性 | 結果整合性 |
2. 可用性への影響
CQRS/ESでは、書き込みモデルが強い一貫性を必要とする一方、読み込みモデルの結果整合性により高い可用性を実現できる。
障害時の振る舞い:
- 書き込みを一時停止しても、読み込み操作は継続可能
- システムの全面的なダウンを回避できる
- キャッシュやレプリケーション機能により、障害発生時でもサービスの可用性を維持
3. スケーラビリティへの影響
読み込みモデルと書き込みモデルを分離して独立にスケールさせることができる。
読み込みモデル:
- 多くのアプリケーションが読み込み重視
- キャッシュやレプリケーションを活用して高いスケーラビリティを実現
- 異なるマイクロサービスが異なるプロジェクションをホストし、特定のクエリに特化
書き込みモデル:
- シャーディングや他の分散技術を活用
- 書き込み負荷に応じた独立スケーリング
RDB構成との本質的類似性
CQRSのトレードオフは、RDBの1台ライター / N台リードレプリカ構成と本質的に同じである。
| 観点 | CQRS/ES | RDB 1W/NR構成 |
|---|---|---|
| 書き込み | 強い一貫性 | マスターへの書き込み |
| 読み込み | 結果整合性 | レプリカからの読み込み |
| 障害時 | 読み込み継続可 | レプリカで読み込み継続可 |
| スケーリング | 読み書き独立 | レプリカ追加で読み込みスケール |
どちらもCAP定理に基づくトレードオフが生じるため、同じ考え方が適用される。この類似性を理解することで、CQRSの導入ハードルを下げることができる。
設計判断フロー
CQRSの採用判断
1. 読み込みと書き込みの負荷特性が異なるか？
→ No: シンプルなCRUDで十分な可能性
→ Yes: 次へ
2. 読み込みと書き込みで異なるモデルが有利か？
→ No: 単一モデルで対応可能
→ Yes: シンプルなCQRSを検討 → 次へ
3. 読み込みモデルで結果整合性を許容できるか？
→ No: シンプルなCQRS（同一DB）を検討
→ Yes: CQRS/ESを検討 → 次へ
4. 高い可用性・スケーラビリティが要求されるか？
→ No: シンプルなCQRSで十分
→ Yes: CQRS/ES + 読み書きモデルの物理分離を検討イベントソーシング併用の判断
| 要件 | ES不要 | ES検討 |
|---|---|---|
| 一貫性レベル | 読み書き同一で可 | 読み書きで独立制御が必要 |
| 監査証跡 | 不要 | 必要 |
| 時間軸での状態再現 | 不要 | 必要 |
| 複雑なプロジェクション | 1〜2種類 | 多数のビューが必要 |
結果整合性の許容判断
| ドメイン特性 | 結果整合性 | 強い一貫性 |
|---|---|---|
| SNSフィード表示 | 許容可 | 不要 |
| 商品カタログ検索 | 許容可 | 不要 |
| 金融取引の残高 | 不可 | 必須 |
| 在庫の引当判定 | 不可 | 必須 |
| ダッシュボード集計 | 許容可 | 不要 |
| 決済処理 | 不可 | 必須 |
判断基準: 数秒〜数分の遅延がビジネス上の損害を生むか？
レビューチェックリスト
アーキテクチャ判断
- 読み書きの負荷特性を分析したか
- CQRSが必要な理由（シンプルなCRUDでは不十分な理由）を明確にしたか
- イベントソーシングの要否を判断したか
一貫性設計
- 書き込みモデルで強い一貫性が担保されているか
- 読み込みモデルの結果整合性がビジネス要件に合致しているか
- 結果整合性の遅延許容範囲を定義したか
可用性設計
- 書き込み障害時に読み込みが継続できる設計か
- 読み込みモデルのキャッシュ・レプリケーション戦略が定義されているか
- 障害発生時のフォールバック戦略が明確か
スケーラビリティ設計
- 読み込みモデルと書き込みモデルが独立にスケール可能か
- 読み込み負荷に対するスケーリング戦略（レプリケーション、キャッシュ等）があるか
- 書き込み負荷に対するスケーリング戦略（シャーディング等）があるか
- プロジェクション戦略（マイクロサービスごとの特化ビュー等）が定義されているか
関連スキル（併読推奨）
このスキルを使用する際は、以下のスキルも併せて参照すること：
cqrs-to-event-sourcing: CQRSがイベントソーシングを必然的に要求する理由cqrs-aggregate-modeling: CQRS/ESが集約の境界定義とモデリングに与える影響aggregate-design: CQRS適用前の集約設計ルール