この記事では、商用ソフトウェア エンジニア (CSE) チームが Azure で銀行取引システムのクラウド変換を作成したときに使用した、パターンと実装について詳しく説明します。
アーキテクチャ
sega アーキテクチャ
このアーキテクチャの Visio ファイルをダウンロードします。
データフロー
Contoso Bank には、オーケストレーション ベースの saga がオンプレミスで実装されていました。 この実装のオーケストレーターは Finite State Machine (FSM) です。 CSE チームは、アーキテクチャ設計に次の課題があることを特定しました。
障害シナリオで状態管理、タイムアウト、および再起動を処理する、ステートフル オーケストレーターの実装に伴うオーバーヘッドと複雑さ。
トランザクション要求ごとに saga ワークフローの状態を追跡する可観測性メカニズム。
提案されたソリューションが、Azure のサーバーレス アーキテクチャを使用したオーケストレーション アプローチによる saga パターンの実装です。 このソリューションは、以下を使用して課題に対処します。
saga 参加者に対応するための Azure Functions。
ワークフロー プログラミング モデルと状態管理を提供するように設計された、オーケストレーション用 Azure Durable Functions。
データ ストリーミング プラットフォームとしての Azure Event Hubs。
データ モデルを格納するデータベース サービスとしての Azure Cosmos DB。
詳細については、「Pattern: Sega」(Microservices.io) を参照してください。
saga パターン
saga は、金融サービスに一般的に適用される分散トランザクション管理に適したパターンです。 アプリケーションとデータベース全体に操作が分散される新しいシナリオが登場しました。 この新しいシナリオでは、財務トランザクションにおけるデータの一貫性を確保するために、新しいアーキテクチャと実装の設計が必要になります。
従来の "原子性、一貫性、分離性、および持続性 (ACID) " プロパティのアプローチは、もはや適切とは言えません。 その理由は、操作データが、分離されたデータベースにまたがるようになったためです。 saga パターンを使用すると、メッセージ ドリブンのローカル トランザクション シーケンスを使用してワークフローを調整することでこの課題に対処でき、データの一貫性が確保されます。
KEDA のアーキテクチャ
このアーキテクチャの Visio ファイルをダウンロードします。
KEDA スケーラーの詳細については、次の KEDA ドキュメントを参照してください。
Azure Event Hubs トリガー: Java アプリケーション用の Azure blob storage URI を読み取るための互換性。 イベント プロセッサ ホスト SDK を使用して、Event Hubs から Advanced Message Queueing Protocol (AMQP) プロトコル メッセージを読み取る Java コンシューマーをスケーリングできるようにします。 以前は、Event Hubs スケーラーは Azure Functions でのみ動作しました。
Apache Kafka トピック トリガー: SASL_SSL プレーン認証のサポート。Event Hubs から Kafka プロトコル メッセージを読み取る Java コンシューマーをスケーリングできます。
ワークフロー
CSE チームは Azure Kubernetes Service (AKS) クラスターにアプリケーションをデプロイしました。 ソリューションは、アプリケーションを、受信メッセージ数に基づいて自動的にスケールアウトする必要がありました。 CSE チームは、Kafka スケーラーを使用して、ソリューションがアプリケーションのデプロイをアクティブ化または非アクティブ化する必要があるかどうかを検出していました。 Kafka スケーラーは、特定のイベント ソースのカスタム メトリックもフィードします。 この例のイベント ソースは、Azure イベント ハブです。
Azure イベント ハブのメッセージ数がしきい値を超えると、KEDA がポッドをトリガーしてスケールアウトし、アプリケーションによって処理されるメッセージの数を増やします。 ポッドの自動スケールダウンは、イベント ソース内のメッセージの数がしきい値を下回ると発生します。
CSE チームは、Apache Kafka トピック トリガーを使用していました。 これにより、ある期間で消費されたメッセージの最大数をプロセスが超えた場合に、ソリューションが EFT プロセッサ サービスをスケーリングできるようになります。
Java 対応 KEDA
Kubernetes イベント ドリブン自動スケーラー (KEDA) によって、ソリューションによる Kubernetes 内の任意のコンテナーのスケーリング方法が決まります。 この決定は、処理が必要なイベントの数に基づきます。 KEDA にはさまざまな種類のスケーラーがあり、ワークロードの種類が複数サポートされています。また、Azure Functions 対応で、ベンダーに依存しません。 実際のサンプルについては、Azure Event Hubs を使用した KEDA での Java アプリケーションの自動スケールに関するページをご覧ください。
ロード テスト アーキテクチャ
このアーキテクチャの Visio ファイルをダウンロードします。
このソリューションでは、JMeter (JMX) スクリプトを使用した Azure Load Testing を使用します。 Azure Load Testing は、大規模な負荷を生成できるフル マネージドのロード テスト サービスです。 このサービスは、アプリケーションがホストされている場所に関係なく、アプリケーションのトラフィックをシミュレートし、既存の JMeter スクリプトを利用できます。
ワークフロー
Azure Load Testing では、Azure portal または Azure CLI を使用してロード テストを手動で作成できます。 または、Azure Load Testing と統合するように CI/CD パイプラインを構成することもできます。 これにより、ロード テストを自動化して、CI/CD ワークフローの一部としてアプリケーションのパフォーマンスと安定性を継続的に検証できます。
- ロード テストを作成して実行することで 、Azure Load Testing のしくみを理解します。
- 新規または既存の JMeter スクリプトを使用し、ロード テストを実行するための CI/CD ワークフローを構成します。
シナリオの詳細
このシナリオは、クラウドに移行する際の銀行業界の全体像のパターンと実装について理解を深めるのに役立ちます。
次のステップ
コンポーネント テクノロジの詳細については、次を参照してください。
- Azure Functions の概要
- Durable Functions とは
- Azure Event Hubs - ビッグ データのストリーミング プラットフォームとなるイベント インジェスト サービス
- Azure Cosmos DB へようこそ
関連リソース
次の関連するアーキテクチャを確認してください。