コンテンツに移動
ネットワーキング

ネットワーク負荷分散のリージョン バックエンド サービスへの移行

2021年2月25日
https://storage.googleapis.com/gweb-cloudblog-publish/images/GCP-networking-01.max-2600x2600.jpg
Google Cloud Japan Team

※この投稿は米国時間 2021 年 2 月 13 日に、Google Cloud blog に投稿されたものの抄訳です。

Google Cloud のお客様は、ネットワーク負荷分散により、Google Cloud リージョン内の仮想マシン全体に外部 TCP および UDP トラフィックを効率的に分散できます。お客様がより簡単に受信トラフィックを管理し、ロードバランサの動作を制御できるように、ネットワーク負荷分散に新しくバックエンド サービスのサポートを追加しました。これにより、お客様のデプロイのスケーリング、速度、パフォーマンス、復元性が改善されます。しかも、管理が簡単です。

初期から Cloud Load Balancing ファミリーの一機能として存在していたネットワーク負荷分散は、ソースと宛先の IP アドレス、プロトコル、ソースと宛先のポートからなる 5 タプルハッシュを使用します。ネットワーク ロードバランサは、Google 独自の Maglev を使用して構築されています。このロードバランサは、データセンターやネットワーク エッジのフロントエンド エンジンに到着するすべてのトラフィックを負荷分散し、1 秒あたり数百万のリクエストにスケールします。そして Direct Server Return などの機能によってレイテンシとパフォーマンスを最適化し、接続指向プロトコルで発生した予期せぬエラーの影響を最小限に抑えます。つまり、ネットワーク負荷分散は、クライアント IP アドレスをバックエンド インスタンスまで保持し、インスタンスで TLS 終端を実行する場合に、優れたレイヤ 4 負荷分散ソリューションとなります。

Google は現在、ネットワーク負荷分散でバックエンド サービスをサポートしています。これは、以前のアプローチであるターゲット プールに比べて、はるかに進化した手法です。バックエンド サービスは、ロードバランサがどのように受信トラフィックをアタッチされたバックエンドに分散し、ロードバランサの動作を細かく制御するかを定義します。これは現在、負荷分散ファミリーの全機能に共通の統合データモデルとなっており、ネットワーク負荷分散に優れた機能を迅速に提供するうえで役立っています。

リージョン サービスであるネットワーク ロードバランサのリージョン バックエンド サービスは 1 つです。本ブログ投稿では、リージョン バックエンド サービスの新機能とメリット、およびこのサービスに移行する方法についてご説明します。今後のブログで、ネットワーク負荷分散の新たな活用方法、リリース予定の機能、リージョン バックエンド サービスのトラブルシューティング方法をご紹介しますので、ぜひご注目ください。

リージョン バックエンド サービスがもたらすメリット

ロードバランサとしてリージョン バックエンド サービスを選択することで、ご利用の環境に数々のメリットがもたらされます。

リージョン バックエンド サービスを導入してすぐに次のようなメリットを得られます。

  • 統合ヘルスチェックによる高精度のヘルスチェック - リージョン バックエンド サービスを使用すると、負荷分散のヘルスチェック機能をフル活用でき、旧式の HTTP ヘルスチェックによる制約を回避できます。ネットワーク負荷分散のお客様は、コンプライアンス上の理由から、カスタム リクエストおよびレスポンス文字列または HTTPS をサポートする TCP ヘルスチェックを希望することが一般的でした。

  • フェイルオーバー グループによる復元性の改善 - フェイルオーバー グループを使用することで、あるインスタンス グループをプライマリに、別のグループをセカンダリに指定し、アクティブ グループのインスタンスの状態が特定のしきい値を下回った場合にトラフィックをフェイルオーバーできます。このフェイルオーバー メカニズムをより細かく制御するには、keepalivedpacemaker などのエージェントを使用し、バックエンド インスタンスの状態の変化に応じて、正常ヘルスチェックまたは失敗ヘルスチェックを公開します。

  • マネージド インスタンス グループによるスケーラビリティと高可用性 - リージョン バックエンド サービスはバックエンドとしてマネージド インスタンス グループをサポートします。バックエンドの仮想マシン インスタンス用にテンプレートを指定し、CPU の利用率やその他のモニタリング指標に基づいて、自動スケーリングを利用できるようになります。

前述の点に加えて、コネクション ドレインを利用することで接続指向プロトコル(TCP)に対応し、大規模デプロイのプロブラミング時間を短縮できます。

リージョン バックエンド サービスへの移行

5 つの簡単な手順でターゲット プールからリージョン バックエンド サービスに移行できます。

1. バックエンド サービスの統合ヘルスチェックを作成します。

読み込んでいます...

2. ターゲット プールの既存のインスタンスからインスタンス グループを作成します。

読み込んでいます...

読み込んでいます...

3. バックエンド サービスを作成し、新しく作成したヘルスチェックと関連付けます。

読み込んでいます...

4. バックエンド サービスを構成し、インスタンス グループを追加します。

読み込んでいます...

読み込んでいます...

5. 構成したバックエンド サービスで get-health を実行し、一連のバックエンドが正確であり、ヘルス ステータスが決定されていることを確認します。その後、set-target API を使用して、既存の転送ルールを新しく作成したバックエンド サービスに更新します。

読み込んでいます...

UDP とリージョン バックエンド サービス 

Google Cloud ネットワークは、UDP フラグメントが到達するとその都度転送します。パケットの UDP フラグメントを同じインスタンスに転送して再構成するには、セッション アフィニティを「なし(NONE)」に設定します。この場合、アフィニティを維持する必要がないため、ロードバランサは 5 タプルハッシュを使用してフラグメント化されていないパケット用のバックエンドを選択しますが、フラグメント化されたパケットについては 3 タプルハッシュを使用します。

次のステップ

ネットワーク負荷分散でリージョン バックエンド サービスがサポートされるようになったため、TCP を含む高精度のヘルスチェックを使用でき、プログラミング時のパフォーマンスが向上します。また、ネットワーク レイヤ負荷分散かその他かにかかわらず、負荷分散バックエンドの構成に均一のデータモデルを使用できます。さらに、コネクション ドレインとフェイルオーバー グループのサポートにより、レイヤ 4 の内部負荷分散で同等の機能を利用できます。

リージョン バックエンド サービスの詳細についてこちらをご覧のうえ、ぜひ移行をご検討ください。ネットワーク負荷分散に関して魅力的なロードマップを用意しておりますので、今後の最新情報にご注目ください。

-負荷分散担当プロダクト マネージャー Babi Seal

-Cloud ソリューション アーキテクト Jens Kuehlers

投稿先