G銀行のフルスタッククラウド環境負荷分散サービス機能の実践 - G銀行における負荷分散サービスの実践

序文

金融業界におけるデジタル変革の探求者および実践者として、G銀行は「123+N」デジタル開発システムを提案しました。つまり、1つのインテリジェントブレイン、2つの主要なテクノロジープラットフォーム（クラウドコンピューティングプラットフォームとビッグデータプラットフォーム）、3つのサービス機能（モバイル、オープン、エコロジカルサービス機能）、Nつのデジタル製品（データマイニングモデルシステム、隋信ローン、専用カスタマーサービス、モバイルバンキングなど）です。デジタル開発戦略の要件に従って、従来のデータセンターのアプリケーションシステムをクラウドプラットフォームに徐々に移行して、クラウドサービスを実現し、ビジネスニーズの急速な反復に対応する必要があります。同時に、クラウド プラットフォームは、高速で便利なリソース配信およびリソース拡張機能を提供し、リソースの使用率を向上させ、コストの削減と効率の向上という目標を達成できます。

アプリケーションをクラウドに移行するために、G 銀行はコンテナ化された展開の優先順位を重視した適切なクラウド移行戦略を策定しました。コンテナに変換できない製品コンポーネントは、さまざまなデプロイメント形式を使用して、仮想マシンまたはベアメタルを通じてクラウドに移行し、アプリケーションのクラウド移行の要件を満たすことができます。従来の環境とクラウド アプリケーションで使用されるビジネス トラフィック負荷方法は異なります。従来の環境では主にハードウェア F5 ロード バランシングが使用されていますが、これは優れたパフォーマンスと強力な機能という利点がありますが、コストが高く、スケーラビリティが低く、情報技術革新の要件に準拠していないという欠点があります。クラウド環境では、クラウド プラットフォームによって提供されるサービス コンポーネントである Elastic Load Balancing サービスが使用されます。その利点は、低コスト、優れたスケーラビリティ、および情報技術要件への準拠です。欠点は、ハードウェア負荷分散よりもパフォーマンスがわずかに低いことです。前回の記事では、負荷分散サービスの主要技術について紹介しました。この記事では、G 銀行における負荷分散サービスの実践に焦点を当てます。

G 銀行の弾性負荷分散の実践

アプリケーションをクラウドに移行するプロセスにおいて、G 銀行はクラウド導入アーキテクチャを標準化するためのクラウド移行モデルを開発しました。クラウド移行モデルは、主に仮想マシンアーキテクチャクラウド移行、コンテナ化クラウド移行、ベアメタルクラウド移行、およびさまざまな形式のハイブリッドクラウド移行展開モデルに分けられます。これらのモデルのうち、弾性負荷分散は主にトラフィック負荷容量を提供し、主に仮想マシン アプリケーションやコンテナ アプリケーションで使用されます。

図 1. クラウド上の仮想マシンとコンテナの負荷分散図。

仮想マシンアプリケーション向けの弾性負荷分散サービス機能の実践

同じ都市内の複数のアクティブ/アクティブ サイトの要件を満たすために、アプリケーション サービスは 3 つのデータ センター (AZ1、AZ2、AZ3) に論理的に展開されます。データ レイヤーは、3 つのセンターにまたがって DB および Redis サービス インスタンスを展開し、3 つのセンターのアプリケーション サービス レイヤーに統合されたデータベース サービスとキャッシュ サービスを提供します。データベース サービスは主に構造化データの永続的な保存に使用され、キャッシュ サービスは主にセッション永続データの保存や、ステートレス アプリケーションを実現するためのその他のキャッシュ使用シナリオに使用されます。

アプリケーション層は、各データセンターに対応するフロントエンド Web アプリケーションとバックエンド アプリ サービスを展開します。 Web サービスとアプリ サービスの両方が負荷分散アーキテクチャに展開されます。フロントエンド負荷分散 ELB は、要求トラフィックを対応するバックエンド サービス ノードに転送し、システムの高可用性設計を確保しながら負荷容量を向上させます。また、サービスの容量要件に応じて容量を動的に拡張および縮小することもできます。負荷分散システムは、TCP および HTTP ヘルスチェックを通じてバックエンド負荷の生存状態を検出し、障害のあるノードの自動分離と障害の自己修復および回復機能を実現します。

アプリケーション アクセス層の設計に関して言えば、フルスタック クラウドには 3 層のネットワーク アーキテクチャがあります。各データセンターは、データセンターのアプリケーション入口として ELB アドレスを使用します。外部リクエストは、DNS サービスによって構成されたドメイン名解決戦略を通じて、3 つのデータセンターの Web サービス フロントエンドの ELB アドレスにトラフィックを転送します。次に、ELB はリクエストを対応する Web サービスに転送し、そのリクエストは App サービス フロントエンドの ELB を介して App サービスにロードされ、最終的にデータベース サービスにロードされます。

上記のアーキテクチャでは、3 つのデータセンターで 3 つの ELB をアプリケーションのエントリ アドレスとして使用するため、従来の環境のように、統合されたロード バランシング インスタンスをエントリ アドレスとして使用し、ロード バランシングのセッション永続性機能を使用してセッション永続性を実現することはできません。そのため、アプリケーション層を介してセッション情報 Session を Redis サービスに保存する必要があります。外部要求がシステムに再度入ると、実際の要求がどのサービス ノードからのものかに関係なく、セッション情報が読み取られ、セッション情報が取得されます。これはアプリケーションに対して透過的であるため、フルスタック アプリケーションのセッション保持機能が実現されます。

図2 G行仮想マシンアプリケーション弾性負荷分散サービスアーキテクチャの概略図

コンテナアプリケーション向けの弾性負荷分散サービス機能の実践

フロントエンドとバックエンドが分離されたモノリシック アプリケーションを例にとると、アプリケーション要求は引き続き DNS サービスを介して Web サービスに対応する ELB アドレスに転送されます。次に、Web サービスは、App サービスのサービスにアクセスしてトラフィックを実際の App サービス ポッドに転送し、最後にデータベース サービスにアクセスします。

このアプリケーション アーキテクチャには、特別な説明が必要な 2 つの主なポイントがあります。まず、ロード バランシング ELB は、コンテナ アプリケーションによって公開されるポートの固定アドレスとして使用されます。 3 センター アーキテクチャでは、DNS ドメイン名を通じて 3 つのセンターの ELB アドレスにアドレスを解決します。 ELB アドレスは、k8s クラスター内に Loadbalance サービスを作成し、アプリケーション サービスを外部に公開します。 2 番目に、k8s クラスター内では、サービスは Service サービスを通じてアクセスされ、ELB の Loadbalance サービスの使用は固く禁止されています。アプリケーション Web サービスは、クラスターへの内部アクセスである App サービスにアクセスします。 Web サービスは、サービス サービスを通じてアプリにアクセスする必要があります。このとき、Service サービスは k8s 内でロードバランサーの役割を果たします。

アプリのサービスに関しては、ここでのロード バランサーは理論的には弾性ロード バランシング ELB を介して固定アドレスを公開することもでき、アクセス リンクは DNS --> ELB --> Web Pod --> サービス --> アプリ ポッド --> EverDB から DNS --> ELB --> Web Pod --> ELB --> アプリ ポッド --> EverDB へと進化します。アクセスに問題はありませんが、ELB インスタンスのサービスオーバーヘッドが増加します。同時に、内部サービスアクセス用のコンテナネットワークトラフィックは、コンテナネットワークとELBネットワーク間のクロストラフィックに変換されるため、サービス間のアクセス効率が低下し、ネットワークリンクの複雑さが増します。

図3 G行コンテナアプリケーション弾性負荷分散サービスアーキテクチャの概略図

要約する

フルスタック クラウド アプリケーションは、負荷分散 ELB を通じてバックエンドの複数の仮想マシンまたはコンテナ アプリケーションに負荷トラフィックを転送し、TCP および HTTP ヘルス チェックを通じてバックエンド負荷の生存ステータスを検出します。 TCP ヘルス チェックでは、対応するアプリケーション ポートが存在するかどうかのみを検出します。設定が簡単で、応答も速いです。 HTTP 検査では、提供されたポートと URL パスに基づいてアプリケーションの健全性状態を正確に判断できます。検査の精度は高く、より包括的な範囲をカバーします。具体的な使用方法は、ビジネスシナリオに応じて構成されます。トラフィック転送アルゴリズムに関しては、一般的な負荷分散デバイスのバックエンドの負荷ノードは同じ構成になっており、ポーリングアルゴリズムを使用して負荷トラフィックを転送できます。

さまざまなクラウド展開方法では、仮想マシン アプリケーションの弾性負荷分散に特別な要件はありません。コンテナ アプリケーションの場合、Elastic Load Balancing (ELB) は、サービス ポートを外部に公開する必要があるサービスにのみ使用できます。 Loadbalance サービスを作成することで、ELB とコンテナ Pod が関連付けられ、Service サービスを使用して内部サービス アクセスが均一にアクセスされるようになります。​