G銀行のフルスタッククラウド環境負荷分散サービス機能の実践 - 負荷分散サービスの主要技術の紹介

クラウド コンピューティングとクラウド ネイティブ テクノロジーの発展に伴い、主要なクラウド コンピューティング ベンダーは、クラウド コンピューティング データ センターを導入して、より安全で効率的なコンピューティング、ストレージ、ネットワーク リソース、アプリケーション サービス リソースをユーザーに提供しています。一部の大企業、特に金融業界の企業は、データのセキュリティと制御性を確保するために、独自のプライベート データ センターを設立する必要があります。現在、すべてのデータ センターは、新興テクノロジの開発と急速なビジネス反復のニーズを満たすために、従来のデータ センターからクラウド コンピューティング データ センターへと移行しています。金融業界におけるデジタル変革の探求者および実践者として、G銀行は、1つのスマートブレイン、クラウドコンピューティングとビッグデータという2つの主要なテクノロジープラットフォーム、モバイル、オープン、エコロジカルサービス機能という3つのサービス機能からなる「123+N」デジタル開発システムを提案しました。デジタル開発戦略の要件に従って、クラウド サービスを実現し、急速なビジネス反復のニーズを満たすために、従来のデータ センターのアプリケーション システムをクラウド プラットフォームに徐々に移行する必要があります。同時に、クラウド プラットフォームは、高速で便利なリソース配信およびリソース拡張機能を提供し、リソースの使用率を向上させ、コストの削減と効率の向上という目標を達成できます。

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

1. 負荷分散の定義

負荷分散テクノロジーは、ネットワーク デバイスとサーバーの帯域幅を拡張し、スループットを向上させ、ネットワーク データ処理機能を強化し、ネットワークの柔軟性と可用性を向上させるハードウェアまたはソフトウェア定義の方法です。主な機能は以下の通りです。

1. 高い同時実行性

負荷分散では、負荷アルゴリズムを使用してアプリケーション要求を各バックエンド負荷ノードに可能な限り均等に分散し、アプリケーション クラスターの同時処理機能を向上させます。

2. 高可用性

負荷分散は、ヘルスチェック メカニズムを通じてバックエンドの負荷ノードを監視できます。ロード ノードが使用できない場合、障害のあるノードを自動的に分離し、使用可能なロード ノードに要求を分散して、アプリケーション クラスターの可用性を高めます。

3. 弾力的なスケーラビリティ

負荷ノードの数を動的に追加または削減し、負荷分散を通じて分散を制御することで、アプリケーション クラスターは弾力性と拡張性を備えます。

2. 負荷分散アルゴリズム

負荷分散の機能はトラフィック分散です。つまり、受信したトラフィック要求を特定のアルゴリズム ルールに従ってバックエンド ロード ノードに転送し、バックエンド ロード サーバーのリソースを最大限に活用しながら高い同時実行性を実現します。一般的に使用されるアルゴリズムは次のとおりです。

3. 負荷分散ヘルスチェック

負荷分散システムは、ヘルスチェックを通じてバックエンド ロード インスタンスのサービス可用性を判断します。バックエンド ロード インスタンスのサービスが異常な場合、負荷分散システムはヘルス状態に基づいて異常なノードを自動的に分離し、トラフィックを分散しません。バックエンドのロード ノード サービスが復元されると、負荷分散システムはヘルス ステータスに基づいてノードを自動的にオンラインにし、フロントエンド サービスの全体的な可用性を向上させます。一般的に使用される 2 つのヘルス チェック メカニズムは次のとおりです。

1. レイヤー7 HTTPモニタリングヘルスチェックメカニズム

レイヤー 7 HTTP リスニングの場合、ヘルス チェックは HTTP HEAD 検出を通じてステータス情報を取得します。

図1 HTTPリスニングヘルスチェックメカニズム

ロード バランシング サーバーは、監視対象のヘルス チェック構成に基づいて、バックエンド ロード ノードに「IP + ヘルス チェック ポート + チェック パス」の HTTP HEAD 要求を送信します。バックエンド ロードは、リクエストを受信すると、対応するサービスの動作状態に基づいて HTTP ステータス コードを返します。

負荷分散サーバーが、応答タイムアウト期間内にバックエンド ロード ノードから返された情報を受信しない場合は、サービスが応答していないとみなされ、ヘルス チェックは失敗します。ロード バランシング サーバーがバックエンド ロード ノードから返されたステータス コードを正常に受信し、そのステータス コードが構成されたステータス コードと一致している場合は、ヘルス チェックは成功したと見なされます。それ以外の場合は、ヘルス チェックは失敗します。

2. TCPリスニングヘルスチェックメカニズム

図2 TCPリスニング監視および検査メカニズム

レイヤー 4 TCP 監視の場合、ロード バランシング サーバーは、TCP 3 ウェイ ハンドシェイク メカニズムを介してバックエンド ロード ノードで TCP 検出を実行し、監視対象のヘルス チェック構成に従って、「IP + ヘルス チェック ポート」の TCP SYN パケットをバックエンド ロード ノードに送信します。バックエンド ロード ノードが要求を受信した後、対応するポートが正常にリッスンしている場合は、SYN+ACK パケットを返します。

負荷分散サーバーは、応答タイムアウト期間内にバックエンド ロード ノードから返されたデータ パケットを受信すると、ヘルス チェックが成功したことを判断し、TCP 接続を確立するために ACK パケットを送信します。バックエンド ロード ノードから返されたデータ パケットを受信しない場合、サービスが応答していないと見なし、ヘルス チェックが失敗したと判断し、バックエンド ロード ノードに RST パケットを送信して TCP 接続を終了します。

4. ヘルスチェックサイクル

ヘルス チェック メカニズムにより、ビジネス サービスの可用性が効果的に向上します。ただし、ヘルスチェックを頻繁に実行すると、バックエンドのロードノードへの負荷が増加する一方で、ヘルスチェックの失敗による頻繁な切り替えもシステムの可用性に一定の影響を与えます。そのため、頻繁なチェックや頻繁な切り替えを避けるために、ヘルスチェックのサイクルを設定する必要があります。ヘルスチェックのサイクルは、次の要因によって決まります。

1. 間隔を確認する

健康診断はどのくらいの頻度で受けるべきでしょうか?

2. タイムアウト

ヘルスチェック要求が返されるまで待機する時間。戻りタイムアウトが発生した場合は、チェック失敗とみなされます。

3. 不健康な閾値

ヘルスチェックの連続失敗回数。しきい値に達すると、バックエンド サービスはブロックされます。

4. 健康閾値

ヘルスチェックが連続して成功した回数。しきい値に達すると、バックエンド サービスが復元されます。

ヘルスチェック期間は次のように計算されます。

ヘルスチェック失敗サイクル = タイムアウト期間 × 不健全しきい値 + チェック間隔 × (不健全しきい値 - 1)

ヘルスチェック成功サイクル = (ヘルスチェック成功応答時間 x ヘルスしきい値) + チェック間隔 x (ヘルスしきい値 - 1)

たとえば、ヘルス チェック間隔が 2 秒、タイムアウト期間が 5 秒、異常しきい値と正常しきい値がどちらも 3 であるとします。ヘルス チェックのステータスが成功から失敗に変わるまでには 19 秒かかります (図 3 を参照)。ヘルス チェックの失敗からステータス チェックの成功までの最小時間は 7 秒です (図 3 に示すように、ヘルス チェックの OK 時間は 1 秒と想定されています)。ヘルス チェック成功応答時間とは、ヘルス チェック要求が送信されてから応答されるまでの時間です。 TCP ヘルスチェックを使用する場合、ポートの生存のみが検出されるため、時間は非常に短く、ほとんど無視できます。 HTTP ヘルス チェックを使用する場合、時間はアプリケーション サーバーのパフォーマンスと負荷、および対応するサービス インターフェイスの応答時間によって異なりますが、通常は数秒以内です。

図3 ヘルスチェック周期の計算方法

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

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

V. 結論

一方、フルスタックのクラウド負荷分散サービスは、従来のハードウェア負荷分散デバイスを置き換えて負荷容量を提供できます。一方、クラウド上の負荷分散デバイスはクラウド化されており、俊敏な配信と柔軟な拡張機能を備えています。バックエンド ロード ノードは、仮想マシン デバイスとコンテナ ノードの両方にすることができ、適用範囲が広く、情報技術革新の要件を満たすという利点もあります。銀行のアプリケーション システムのクラウド移行では、負荷分散アーキテクチャ アプリケーション コンポーネントの負荷容量コンポーネントと、コンテナ アプリケーションの統一されたエントリ アドレスの両方として機能し、統一された方法で固定アドレスを外部に公開します。クラウド環境において、ますます重要な役割を果たすことになります。