はじめに
Azureクラウドアプリケーションアーキテクチャガイドより、7つあるアーキテクチャスタイルの一つ、CQRSに関してまとめます。
連載目次
Azureアーキテクチャガイドまとめ 1 【はじめに】
Azureアーキテクチャガイドまとめ 2【N層】
Azureアーキテクチャガイドまとめ 3 【Webキューワーカー】
Azureアーキテクチャガイドまとめ 4 【マイクロサービス】
Azureアーキテクチャガイドまとめ 5 【CQRS】 → 本記事
Azureアーキテクチャガイドまとめ 6 【イベントドリブンアーキテクチャ】
Azureアーキテクチャガイドまとめ 7 【ビッグデータアーキテクチャ】
Azureアーキテクチャガイドまとめ 8 【ビッグコンピューティングアーキテクチャ】
概要
Command > 状態を変更するコマンド > Write処理
Query > 状態を読み込むクエリ > Read処理
Responsibility > 責任
Segregation > 分離
で、CQRS です。
つまり、Write処理とRead処理を適切に切り分けてパフォーマンスを上げよう、というアーキテクチャです。
具体的には、タスクの属性を考慮し、クエリとコマンドに以下のような役割を持たせます。
| クエリ | コマンド |
|---|---|
| 読み取り専用 | 書き込み専用 (非同期処理) |
| 結果のみ返す | 状態の変更のみ行う |
| 状態の変更は行わない | 結果は返さない |
適用条件
読み取りと書き込みが発生する箇所すべてにこれを適用してしまうと、アーキテクチャ全体が過度に複雑になってしまいます。
よって、書き込みと読み取りの分離に明確な利点があるとみなされた場合にのみ採用します。例えば以下のようなケース。
読み取りと書き込みでパフォーマンスやスケールの要件が大きく異なる
読み取りが極端に多い
多くのユーザーが同じデータにアクセスする (共同ドメインなど)
構成例
マネージドサービスを活用し、それぞれの処理がスムーズにいくように構築します。
例えばAzure FunctionsとCosmos DBを書き込み側に、App ServiceとSQL DBを読み込み側に配置した、以下のような構成です。
※ こちらのスライドを参考にさせていただきました。
利点
-
独立した拡張性
- 読み取りと書き込みのワークロードを独立に拡張
- ロックの競合を減らせる可能性
-
最適化されたデータスキーマ
- 読み取り側ではクエリに最適化されたスキーマ
- 書き込み側では更新に最適化されたスキーマ
-
セキュリティ
- 適切なドメインエンティティ以外がデータを書き込めないようにできる
-
懸念事項を分離し、保守性と柔軟性を向上できる
- 複雑なビジネスロジックのほとんどは書き込み側に存在
- 読み取りモデルは比較的単純にできる
クエリを単純化できる
課題
アプリの設計が複雑になる場合も
高頻度の処理や更新イベントの発生にメッセージングを用いることが多く、メッセージのエラーや重複に対処する必要あり
データベースを分離した場合、読み取りデータが古くなる可能性あり (CQRSは基本的に結果整合性)
ベストプラクティス
実装の詳細
更新の競合を避ける
読み取りモデルのスキーマ最適化
まとめ
CQRSアーキテクチャの特徴と、構成例ついて見ていきました。次回はイベントドリブンアーキテクチャについてまとめます。お楽しみに！
参考リンク
Azureアーキテクチャセンター
Azureクラウドアプリケーションアーキテクチャガイド ダウンロードページ
Azure Cosmos DB と Databricks を使ったCQRSパターンとラムダアーキテクチャ