データクエリパターン
MSAソフトウェアアーキテクチャを設計する際に発生するデータクエリの課題を解決するためのパターン
-
API Aggregation パターン
必要なデータを取得するために、分離された各サービスに対してドメインごとのデータをリクエストし、それを必要に応じて Aggregation (組み合わせ) します。 -
CQRS パターン
Command (書き込み、更新、削除) の作業と Query (読み取り) のエンドポイントを分離し、Commandで発生したデータの変更をイベント発行を通じて、必要な形式で Query専用のデータ構造を作成します。そしてQueryを適切にリクエストする仕組みです。
可視性パターン (Visibility, Observability)
MSAソフトウェアアーキテクチャを設計する際、ロギングやモニタリングの課題 (可視性の欠如) を解決するためのパターン
- ログおよびメトリクスの中央集約やフィルタリングを通じて、一箇所でモニタリングできるようにする。
- 一つのトランザクションに対する複数サービス間のリクエストを一つのリクエストのように見られるようにするトレーシング機能。
ロギングとメトリクスの違い:
- ロギング: トラブルシューティングを目的とし、欠落してはならない情報。
- メトリクス: サーバーやアプリケーションの指標を時系列で保存し、時間に応じた増減をアラートとして受け取るために使用。データが欠落しても大きな問題ではなく、データの全体的な傾向や推移が重要。
「具体的に、ログやメトリクスをどのように保存し、インデックス付けして検索を行うかに集中するパターン」
信頼性パターン (Reliability)
MSAソフトウェアアーキテクチャによるサービス分離/分解により低下した信頼性を解決するためのパターン
障害復旧、自己修復、無停止デプロイなどを実現するためのパターンが含まれます。
サーキットブレーカー (Circuit Breaker)
信頼性を向上させるためのパターンの一つで、分散システムでの障害伝播を防ぎ、被害を最小限に抑えるためのパターンです。
例:
A → B → Cの順にサービスが呼び出される場合、Cで問題が発生しBが障害を起こすことがあります。この時、「100回以上500エラーが発生する」という条件を持つサーキットブレーカーは、その条件が満たされた場合、Cへのリクエストをすべて遮断します。そして、B→Cへのリクエストを行っていたAサービスに対して、HTTPコードとメッセージを送ります。
しかし、サーキットブレーカーの役割はここで終わりではありません。定期的にCに状態を問い合わせ、問題が解決された場合、Cへのリクエスト遮断を解除します。
外部APIパターン
サービス間の通信における実装と関連する依存性を解決するためのパターン
あるサービスが他の特定のサービスを呼び出す際、直接呼び出すのではなく、リバースプロキシの役割を果たすインターフェースサービスを提供することで、マイクロサービス間の内部実装に依存せず柔軟性を持つことができるパターンです。