この記事は、Microsoft 商用ソフトウェア エンジニアリング (CSE) チームが銀行の顧客向けソリューションを構築する際に使用した、プロセスとコンポーネントを要約したものです。 匿名性を確保するために、この記事では顧客を Contoso Bank と呼びます。 この国際的な大手金融サービス業界 (FSI) 組織は、金融取引システムの 1 つを刷新することを考えています。
アーキテクチャ
このアーキテクチャの Visio ファイルをダウンロードします。
ソリューションは、主にバックエンド サービス、ロード テスト、イベント自動スケーラーを使用した監視の 3 つのブロックで構成されています。
実際の Contoso マイクロサービス コンテナーは、Docker を通じて Kubernetes クラスターに手動でプッシュされました。 このクラスターは次のとおりです。
以下に対する Kubernetes/OpenShift の水平ポッド自動スケーラー (HPA) の Azure Red Hat OpenShift (ARO):
チャネル ホルダー。
トランザクション シミュレーション成果物のスケーラビリティとパフォーマンス。
チャネル ホルダー用ノード自動スケーラーの Azure Kubernetes Service (AKS)。
CSE チームは、他のマイクロサービスをスタブとして作成して、ソリューションによって Azure Pipelines 経由でプッシュされた他の外部メインフレーム サービスから、実際の Contoso マイクロサービスを明確に分離しました。
ワークフロー
根底では、EFT の発生に必要なロジックがバックエンド サービスによって提供されます。
チャネル ホルダー サービスが受信した HTTP 要求によって、新しい EFT が開始します。
サービスは、"発行-サブスクライブ" パターンを使用して、Azure Cache for Redis を通じて要求者に同期応答を提供し、バックエンドからの応答を待ちます。
ソリューションは、EFT パイロット パスワード サービスを使用して、この最初の要求を検証します。
サービスは、検証を実行するだけでなく、データも強化します。 データ エンリッチメントは、ソリューションによる EFT の処理に従来のマイクロサービス システムを使用するか、新しいものを使用するかを、バックエンドが決定するのを支援します。
次に、チャネル ホルダー サービスが非同期フローを開始します。
サービスによって EFT コントローラーが呼び出されます。このコントローラーは、トランザクション フローを調整するリアクティブなオーケストレーターです。 これを行うために、他のマイクロサービスから Azure Event Hubs/Kafka を介してコマンドが生成され、イベントが使用されます。
これらのサービスの 1 つが EFT プロセッサです。このプロセッサで実際のトランザクションが実行され、クレジットおよびデビット操作が行われます。
CSE チームは、Kubernetes Event-driven Autoscaling (KEDA) を使用しました。 このフレームワークにより、ソリューションが処理したメッセージの負荷に基づいて、アプリケーションが自動的にスケーリングされます。 ソリューションが新しい EFT を処理したときに EFT プロセッサをスケーリングするために、ソリューションでこれが使用されました。
KEDA は AKS と Azure Container Apps でサポートされています
次はロード テストです。 Azure Load Testing は、大規模な負荷を生成できるフル マネージドのロード テスト サービスです。 このサービスは、追加のリソースをデプロイすることなく、アプリケーションのトラフィックをシミュレートします。 また、Azure Load Testing には、既存の Apache JMeter スクリプトを取得し、それを使用してロード テストを実行する機能も用意されています。
最後に、監視機能によって、ロードテストの結果、インフラストラクチャ、およびアプリケーション メトリックを統合する必要があります。
チームは、ストレージおよびコンテナー オーケストレーション レイヤーで、ロード テストの実行と、マイクロサービスに起因する副作用を関連付けました。 これにより、アプリケーション チューニングの迅速なフィードバック サイクルが可能になりました。 この監視および可観測性機能を許可したコア コンポーネントは、Azure Monitor の Prometheus、Grafana、および Application Insights です。 イベント自動スケーラーは、受け取ったメッセージの読み込みに基づいてアプリケーションがスケーリングされるシナリオの検証に対応します。 この動作を実装するために、CSE チームは、KEDA を採用して Java アプリケーションのスケーリングをサポートしました。
ソリューションの機能
このソリューションには主に次の 3 つ機能があります。
チャネル ホルダー用水平ポッド自動スケーラー
チャネル ホルダー用ノード自動スケール
トランザクション シミュレーション成果物のスケーラビリティとパフォーマンス
チャネル ホルダー用水平ポッド自動スケーラー
このソリューションで、チームは Kubernetes/OpenShift HPA メカニズムを使用しました。 ポッドの数は、選択したメトリックに基づいて、HPA によって自動的にスケーリングされます。 これにより、コンテナーの効率的な "スケールインおよびスケールアウト" メカニズムが実現します。 チャネル ホルダー REST API の CPU バインド特性を考慮して、チームは、新しい EFT が発生したときにサービス レプリカを拡張できるように、HPA と CPU を使用することを選択しました。
このコンポーネントにより、Azure Red Hat OpenShift でチャネル ホルダーと呼ばれるサービスが実行されます。 このサービスでは、ポッド自動スケール テストが実行されます。 コンポーネントには、次の処理を実行する機能が求められていました。
オンプレミスから Azure への DevOps パイプラインをチャネル ホルダー サービスに提供する。
Grafana ダッシュボードを使用して OpenShift クラスター監視を提供する。
チャネル ホルダー サービス用 Horizontal Pod Autoscaling テストを実行する。
Prometheus と Grafana を使用してメトリック キャプチャ (使用状況など) をアクティブにすることで、チャネル ホルダーで可観測性を提供する。
実行されたテスト、アプリケーションの動作、および Kafka パーティション分割戦略に関する詳細なレポートを提供する (存在する場合)。
チャネル ホルダー用ノード自動スケール
レプリカは、最初の HPA によって、クラスター インフラストラクチャが飽和状態になるまでスケーリングされます。 その後、ノードのスケールインおよびスケールアウト メカニズムによって、アプリケーションは新しい要求を受信および処理し続けます。 このメカニズムについては、チームは Kubernetes ノード自動スケールを使用しました。これにより、クラスターは、すべてのノードの容量が上限に近い場合でも拡張可能です。
このコンポーネントは、ノード自動スケール テストを許可するために、AKS でチャネル ホルダー サービスを実行することに焦点を当てており、 次の処理を実行する必要がありました。
Grafana ダッシュボードを使用して AKS クラスター監視を提供する。
チャネル ホルダー サービス用ノード自動スケール テストを実行する。
Prometheus と Grafana を使用してメトリック キャプチャをアクティブにすることで、チャネル ホルダーで可観測性を提供する。
実行されたテスト、アプリケーションの動作、および Kafka パーティション分割戦略に関する詳細なレポートを提供する (存在する場合)。
トランザクション シミュレーション成果物のスケーラビリティとパフォーマンス
CSE チームは、ロード テスト フレームワークを使用して、HPA とノード自動スケールの両方のメカニズムをトリガーできるだけの負荷を生成しました。 ソリューションによってコンポーネントがトリガーされると、インフラストラクチャおよびアプリケーション メトリックがチームに対して生成され、高負荷のもと、チャネル ホルダーのスケーリングの応答時間とアプリケーションの動作が検証されます。
このコンポーネントは、ARO と AKS で、チャネル ホルダー、EFT コントローラー、EFT プロセッサの各サービスを実行することに焦点を当てています。 また、すべてのサービスで、ポッドとノードの自動スケール テストとパフォーマンス テストを実行します。 次の処理を実行する必要がありました。
マイクロサービスが 1 秒あたり 2000 トランザクション以上になるまでパフォーマン ステストを実行する。
マイクロサービスに対して水平ポッド/ノード自動スケール テストを実行する。
Prometheus と Grafana を使用してメトリック キャプチャをアクティブにすることで、チャネル ホルダーで可観測性を提供する。
実行されたテスト、アプリケーションの動作、および導入された Kafka パーティション分割戦略に関する詳細なレポートを提供する。
コンポーネント
次の一覧は、CSE チームがこのソリューションを作成するときに使用したテクノロジをまとめたものです。
Azure
サードパーティ
Contoso Bank バックエンド サービス
オープンソース
シナリオの詳細
Contoso Bank は国際的な大手金融サービス業界 (FSI) 組織であり、金融取引システムの 1 つを刷新することを考えています。
Contoso Bank は、シミュレートされた実際のアプリケーションと既存のワークロードを使用して、スケーラビリティとパフォーマンスに対するソリューション インフラストラクチャの反応を監視したいと考えていました。 ソリューションに求められていたのは、既存の支払いシステムの要件に対応していることです。
考えられるユース ケース
Contoso Bank が一連のシミュレーションを使用する目的は次のとおりです。
インフラストラクチャ スケーラビリティの影響を確認する。
特定のメインフレーム ソフトウェアの既存のアーキテクチャ設計が、失敗にどのように反応するかを確認する。
提案されたソリューションにより、機能シナリオが、仮想アプリケーションを使ってシミュレートされます。 その目的は、インフラストラクチャのパフォーマンスとスケーラビリティを監視することで、 この一連のシミュレーションを通じて、メインフレームの電子決済 (EFT) システムのワークロードにおける障害の影響を確認することを目指していました。
オンプレミスからクラウドへの DevOps のスムーズな移行を提案するための要件もありました。 この移行では、Contoso Bank が採用しているプロセスと仕組みを新システムに移行し、この銀行の既存ツールを使用する必要がありました。 既存のテクノロジを使うことで、開発者のスキルアップの負担が軽減されます。 移行は、Contoso Bank による現在および将来の設計上の決定を確認するうえで役立ちます。 また、新しい分散システムをホストするのに十分な堅牢性を、確実に Azure 環境に提供します。
考慮事項
成功の基準
Contoso チームと CSE チームは、このエンゲージメントの成功の基準として以下を定義しました。
一般的な基準
Contoso Bank は、次の一般的なポイントを、すべてのコンポーネントの成功基準と見なしました。
Contoso テクニカル チームが、デジタル変革とクラウド導入を実現できるようにする。 CSE チームが以下を実施した。
Azure に必要なツールとプロセスを提供した。
Contoso テクニカル チームが既存のツールを使用し続けるにはどうすればよいかを説明した。
各コンポーネントに、次について説明するドキュメントが付属している。
スケーラビリティとパフォーマンスのテスト結果。
各テストで考慮されるパラメーターとメトリック。
すべてのコードまたはインフラストラクチャの変更 (各テストで必要な場合)。
各テストでパフォーマンスの微調整、パフォーマンス チューニング、パラメーターを検討する際に学習した教訓。
Kafka のパーティション分割戦略に関する教訓とガイダンス。
成果物からの学習に基づくアーキテクチャに関する一般的な推奨事項/ガイダンス。
成果物の基準
| メトリック | 値 (範囲) |
|---|---|
| チャネル ホルダーでポッド自動スケール テストを実行する機能 | ターゲット:CPU 使用率が 50% に達すると、新しいチャネル ホルダー ポッド レプリカが自動的に作成されます。 |
| チャネル ホルダーに基づいてノード自動スケール テストを実行する機能 | ターゲット:ポッドに対するリソース制約 (CPU 使用率など) のため、新しい Kubernetes ノードが作成されます。 システムが作成できるノード数は、Kubernetes によって制限されます。 ノード制限は 3 ノードです。 |
| EFT シミュレーションでポッド/ノードの自動スケールとパフォーマンス テストを実行する機能 | ターゲット:すべてのサービスに対して新しいポッド レプリカが自動作成されます。 レプリケーションが発生するのは、CPU の使用率が 50% に達し、CPU リソース制約に関連する新しい Kubernetes ノードが作成された後です。 このソリューションは、1 秒あたり 2000 トランザクションをサポートする必要があります。 |
テクニカル ソリューション
チームによって提供されたソリューションには、ターゲット成果物を実現するための横断的な懸念事項と特定の実装が含まれていました。 また、このソリューションは、Contoso Bank のポリシーに基づく設計上の制約に従う必要がありました。
Azure Red Hat OpenShift 3.11 に機能的制約があったことから、ノードを自動スケーリングするシナリオのテストに Azure Kubernetes Service を使用するよう Contoso から依頼があったことは、注目に値します。
CSE チームが検討しなければならない設計上の制約はいくつかありました。
内部的な要件により、Contoso Bank は次のテクノロジを使用するよう要求しました。
コンテナー オーケストレーション プラットフォームとしての OpenShift 3.11。
マイクロサービス開発用の Java と Spring Boot。
Confluent Schema Registry 機能を使用したイベント ストリーミング プラットフォームとしての Kafka。
クラウドに依存しないようにします。
DevOps および監視ツールは、Contoso がオンプレミスの開発環境で既に使用しているものと同じにします。
オンプレミス環境で Contoso がホストするソース コードは、外部環境と共有できません。 Contoso ポリシーによって許可されるのは、オンプレミスから Azure へのコンテナー イメージの移動のみです。
継続的インテグレーション (CI) パイプラインがオンプレミス環境と任意のクラウドの両方の間で動作する機能は、Contoso ポリシーによって制限されます。 Contoso は、オンプレミス環境でホストされているすべてのソース コードを、コンテナー イメージとして、Azure Container Registry に手動でデプロイしました。 オンプレミス側でのデプロイは Contoso 側の責任で行われました。
シミュレートされたテスト シナリオは、フロー参照としてメインフレーム EFT ワークロードのサブセットを使用します。
Contoso Bank は、すべての HPA およびパフォーマンステストを ARO で行う必要があります。
ソリューションの横断的な懸念事項
メッセージ ストリーミング
CSE チームは、 Apache Kafka を、分散メッセージ ストリーミング プラットフォームとしてマイクロサービスに対して使用することにしました。 チームは、スケーラビリティを向上させるために、マイクロサービスごとに 1 つのコンシューマー グループを使用することを検討しました。 この構成では、各マイクロサービス インスタンスが、イベント処理を分割および並列化するためのスケール ユニットです。
チームは数式を使用して、トピックあたりの最適な推定パーティション数を計算し、推定スループットに対応しました。 数式の詳細については、Kafka クラスターのトピックまたはパーティションの数を選択する方法に関するページをご覧ください。
CI/CD ベロシティ
DevOps については、Contoso Bank は既に、GitLab のオンプレミス インスタンスをコード リポジトリに使用していました。 社内で開発した Jenkins ベースのカスタム ソリューションを使って、開発環境用に継続的インテグレーションと継続的デリバリー (CI/CD) パイプラインを作成しました。 最適な DevOps エクスペリエンスは提供されていません。
Azure の DevOps エクスペリエンスを向上させるために、CSE チームは、Azure DevOps で Azure Pipelines を使用して、アプリケーションのライフサイクルを管理することにします。 CI パイプラインはすべての pull request で実行され、CD パイプラインはメイン ブランチへのマージが成功するたびに実行されます。 各サービスのリポジトリとパイプラインの管理を担当していたのは、開発チームの各メンバーです。 コードの見直し、単体テスト、リンティング (静的ソース コード分析) も行う必要がありました。
CSE チームは相互依存していないサービスを同時にデプロイし、Contoso Bank からの要求に応じて Jenkins エージェントを使用します。
チームは、サービスとクラスターを監視するために、ソリューションの一環として Prometheus を組み込みました。 Prometheus を使用することで、ソリューションにとって意味のあるデータを生成する以外に、Contoso Bank が将来的に使用量に基づいて製品を強化できます。 Grafana ダッシュボードには、これらのメトリックが表示されます。
ロールアウト戦略
チームは Azure Pipelines を通じて開発環境にソリューションを展開しました。 サービスごとに独自のビルドとデプロイのパイプラインがあり、 チームは、手動でトリガーできるデプロイ パイプラインを使っていました。 これにより強制的に環境が完全にデプロイされ、コンテナーは特定のブランチ バージョンにデプロイされます。
CSE チームは、デプロイのために安定バージョンを生成したリリース ブランチを作成しました。 メイン ブランチへのブランチのマージは、チームが確実にソリューションをデプロイする準備ができている場合にのみ発生します。 前の安定バージョン以外をデプロイするロールバック戦略は、このエンゲージメントの対象ではありませんでした。 ステージごとに承認ゲートが存在し、 各ゲートがデプロイの承認を要求します。
障害復旧
このソリューションは、すべてのサービスに対して Terraform スクリプトと Azure Pipelines を使用します。 災害が発生した場合、Contoso Bank は、Terraform スクリプトを使用するか、リリース パイプラインを再度実行することで、環境全体を再作成できます。 Terraform によって、環境が変更されたことが認識され、その環境が再作成されます。 Azure 上のインフラストラクチャのプロビジョニングと破棄は、必要に応じてソリューションによって動的に行われます。 ストレージ アカウントは、ゾーン冗長ストレージ (ZRS) です。 バックアップ戦略は、このエンゲージメントの対象外です。
セキュリティとプライバシー
すべてのコンテナー イメージが、プライベート レジストリ (Azure Container Registry) に格納されました。
このソリューションは、ARO および AKS シークレットを使用して、接続文字列やキーなどの機密データをポッドに挿入します。
Kubernetes API サーバーへのアクセスには、ARO と AKS に対する Microsoft Entra ID を介した認証が必要です。
Jenkins へのアクセスには、Microsoft Entra ID を介した認証が必要です。
まとめ
プロジェクトの最後に、CSE チームは次の分析情報を共有しました。
ソリューションとエンゲージメントの結果
チームは、サービス デプロイの AKS と ARO の間に高いレベルの互換性を確認しました。
コード不要の Application Insights を使用すると、可観測性の作成が容易になり、リフトアンドシフト移行におけるクラウド導入での共同作業が可能です。
ロード テストは大規模プロジェクトを意図したソリューションの重要な部分であり、マイクロサービスの特異性を考慮するには、前の分析と計画が必要です。
マイクロサービスの副作用を検出するロード テストのポテンシャルは、お客様によって過小評価されることがよくあります。
テスト環境を作成するには、不要なインフラストラクチャ コストを回避するためのインフラストラクチャ廃棄戦略を必要とする場合があります。
重要な教訓
ARO から AKS へのスムーズなアプリケーション移行があります。
ノード自動スケール機能は、エンゲージメント中に使用された Red Hat OpenShift バージョン 3.11 では使用できませんでした。 そのため CSE チームは、AKS を通じて、ノード自動スケール テスト シナリオを実行しました。
製品の終了時にクリエイティブなカスタマイズが必要になる場合があります。 成功したソリューションをチームが提供するとき、準備フェーズが重要な役割を果たします。
この記事の作成時に、CSE チームは、Azure DevOps パイプラインに Container Instances と JMeter を統合するロード テスト ソリューションを作成しました。 それ以降、Azure Load Testing は、追加のコンピューティング リソースをデプロイする必要なく、フル マネージドのロード テスト サービスとして利用可能となっています。
チームは Kafka に Azure Event Hubs を使用することを推奨しましたが、Contoso Bank にとっては、スキーマ レジストリが重要な機能でした。 要求された時間内に Contoso Bank に参加するために、チームは、別の AKS インスタンスでスキーマ レジストリの使用を検討する必要がありました。
Schema Registry を使用した Kafka プロトコルは、KEDA の Event Hub Scaler ではサポートされていませんでした。
次のステップ
Azure Event Hubs を使用した KEDA での Java アプリケーションの自動スケール: Java 用 KEDA のサンプル
パターン: saga: Microservices.io の saga パターンに関する情報
関連リソース
このソリューションの作成に使用されるプロセスとテクノロジの詳細については、次の記事を参照してください。