※ 本記事は、Lilian Quanによる”OCI network load balancer enhancements for backends support“を翻訳したものです。

2024年6月19日

Oracle Cloud Infrastructure (OCI) Network Load Balancerサービスは、導入以来、急速に普及しています。ネットワーク・ロード・バランサは、ネットワーク・アーキテクチャの重要なコンポーネントです。これは、受信したネットワーク・トラフィック・ロードおよびクライアント・リクエストを複数のバックエンド・サーバーまたはリソースに効率的に分散するように設計されており、その容量使用率を最適化し、バックエンド機能の集合的な信頼性と高可用性を確保します。

創業以来、OCI Network Load Balancerはローカル・リージョンでバックエンドをサポートしてきました。バックエンドは、ネットワーク・ロード・バランサと同じ仮想クラウド・ネットワーク(VCN)内、またはローカル・ピアリング・ゲートウェイ(LPG)によってネットワーク・ロード・バランサVCNに接続された別のVCN内に存在できます。本日、OCI動的ルーティング・ゲートウェイ(DRG)を介してネットワーク・ロード・バランサからアクセス可能な場所にネットワーク・ロード・バランサ・バックエンドのサポートを拡張したことをお知らせします。次のようなシナリオがあります:

  • クロスVCN接続: 異なるVCN内のネットワーク・ロード・バランサとバックエンドがDRGを介して接続できるようになり、OCIネットワーク・ロード・バランサを使用したネットワーク設計でLPGが不要になりました。

  • クロス・リージョンのサポート: ネットワーク・ロード・バランサは、リモート・ピアリング接続(RPC)を介してアクセス可能なリモート・リージョンにバックエンドを持ち、そのVCNがアタッチされているDRGを持つことができるようになりました。

  • オンプレミス・バックエンド: ネットワーク・ロード・バランサは、FastConnect仮想回線またはIPsecトンネルを介してDRGに接続されたオンプレミス・ネットワークにバックエンドを持つことができるようになりました。

これらの拡張機能により、ネットワーク・ロード・バランサ・バックエンドをDRGの背後にある任意のネットワークに効果的にデプロイできます。ネットワーク・ロード・バランサがDRGを介してバックエンドに到達できる場合、バックエンドの距離に実際的な制限はありません。これらの新しく追加された柔軟性により、OCIネットワーク・ロード・バランサで顧客のネットワーク設計が簡素化され、OCIネットワーク・ロード・バランサの使用がより多様なシナリオに拡大されます。

このブログ投稿の後続の項では、ネットワーク・ロード・バランサ・バックエンドを追加してこれらの拡張機能を利用し、ロック解除された設計シナリオに関する詳細なインサイトを、重要なネットワーク構成を示す例とともに提供する方法について説明します。

IPアドレスを使用したネットワーク・ロード・バランサ・バックエンドの追加

通常、お客様は、新しいバックエンドをネットワーク・ロード・バランサ・バックエンド・セットに追加するときに、OCIコンピュート・インスタンスを新しいバックエンドとして直接選択するか、IPアドレスを指定できます。オンプレミス・インスタンスやリモートVCN内のインスタンスなど、DRGを介してネットワーク・ロード・バランサから到達可能なリモート・バックエンドを追加する場合、後者の方法のみを使用できます。新しいバックエンドは、そのIPアドレスを使用して追加する必要があります。

次のサンプル・コンソール画面は、ネットワーク・ロード・バランサ・バックエンド・セットにリモート・バックエンドを追加する方法を示しています。この例では、バックエンド・タイプがIPアドレスに設定され、リモート・インスタンスのIPアドレスが入力されます。

Adding an IP-based backend in the Oracle Cloud Console.

IPアドレスベースのバックエンドを追加する必要がある場合は、バックエンド・セットのソース保存を無効にする必要があります。このバックエンドをOracle Cloudコンソールに追加すると、例のようなリマインダ・メッセージが表示されます。バックエンド・セットでソース保持が有効になっている場合、IPアドレス・バックエンド・タイプのオプションは使用できなくなります。IPアドレスベースのバックエンドを追加する前に、まずバックエンド・セットに対して無効化するアクションを実行する必要があります。ソースの保持が無効になっている場合、ネットワーク・ロード・バランサは、クライアントからバックエンドにトラフィックを転送する前に、ソースIPアドレスを独自のプライベートIPアドレスに置き換えます。その結果、バックエンドでは、ネットワーク・ロード・バランサのプライベートIPがトラフィックのソースとして認識されます。設計で、バックエンドが元のソースIPアドレスを知る必要がある場合は、代替ソリューションについてOracleアカウント・チームに連絡してください。

DRGを介した別のVCN内のバックエンドを含むOCIネットワーク・ロード・バランサ

多くのお客様は、OCIネットワーク・ロード・バランサとそのバックエンドを別々のSCNにデプロイすることを戦略的に選択しています。たとえば、パブリック・ネットワーク・ロード・バランサは、インターネットに直接接続されている一元化されたVCNにデプロイでき、バックエンド・インスタンスは内部専用のVCNに保持されます。以前は、この設計では、LPGを介してネットワーク・ロード・バランサとバックエンドVCNを接続する必要がありました。この要件により、顧客はDRGとの簡略化されたVCN間接続を利用できなくなります。仮想ネットワークがより多くのVCN、ネットワーク・ロード・バランサ、およびバックエンド・セットで拡張されると、ローカル・ピアリング設計が複雑になるか、さらなるスケーリングのボトルネックになる可能性があります。最新の拡張により、この障害が解消され、お客様はネットワーク・ロード・バランサとバックエンドVCN間を含むすべてのVCN間接続にDRGを使用することで、ネットワーク設計を合理化できます。

次の図は、DRGによって接続された個別の内部VCNに存在するバックエンドを使用したパブリック・ネットワーク・ロード・バランサの設定を示しています。ネットワーク・ロード・バランサとバックエンド側の両方で重要なルーティングとセキュリティ構成が強調表示され、IPルーティングとそれらの間のヘルス・チェック・トラフィックの許可に不可欠です。

Backends in another VCN connected by DRG

ルーティングの場合、ネットワーク・ロード・バランサ・サブネットのVCNルート表には、DRGをネクスト・ホップ・ターゲットとして使用して、バックエンド・サブネット(またはそのVCN)へのルートが必要です。逆に、バックエンド・サブネットのルート表には、DRGをネクスト・ホップ・ターゲットとして使用して、ネットワーク・ロード・バランサ・サブネット(またはそのVCN)へのルートが必要です。DRGでは、両方のVCNアタッチメントで、自動生成されたDRGルート表をVCNアタッチメントに使用できます。これら間の動的ルーティングが可能になります。

セキュリティに関して、ヘルス・チェック・プロセスは、ヘルス・チェック・リクエストをバックエンドに送信するネットワーク・ロード・バランサによって開始されるため、ネットワーク・ロード・バランサ・サブネットでは、バックエンドへのヘルス・チェック・リクエストを許可するために、ネットワーク・セキュリティ・リストに明示的なエグレス・ルールが必要です。または、サブネット・セキュリティ・リストではなく、ネットワーク・ロード・バランサのネットワーク・セキュリティ・グループ(NSG)をセキュリティ・ポリシーに使用する場合は、同じエグレス・ルールをNSGに追加する必要があります。エグレス・ルールがステートフルである場合、バックエンドからのヘルス・チェック・レスポンスを許可する明示的なイングレス・ルールは必要ありません。

同様に、バックエンド・サブネットまたはバックエンドのNSGのセキュリティ・リストには、ネットワーク・ロード・バランサからのヘルス・チェック・リクエストを許可する明示的なイングレス・ルールが必要です。このイングレス・ルールがステートフルである場合、ヘルス・チェック・レスポンス・トラフィックがネットワーク・ロード・バランサに戻ることを許可するために、明示的なエグレス・ルールが不要になります。この例では、ヘルス・チェックはTCPポート80で実行されます。そのため、ネットワーク・ロード・バランサ・サブネットには、TCP宛先ポート80のバックエンド・サブネットへのトラフィックを許可するステートフル・エグレス・ルールがあり、バックエンド・サブネットには、ネットワーク・ロード・バランサ・サブネットからTCP宛先ポート80へのトラフィックを許可するステートフル・イングレス・ルールがあります。また、ネットワーク・ロード・バランサとバックエンド・サブネットの両方に、ネットワーク・ロード・バランサがロードする本番トラフィックをバックエンドに共有できるように、適切なセキュリティ・ポリシーが必要です。

リモート・リージョンにバックエンドがあるOCIネットワーク・ロード・バランサ

OCIネットワーク・ロード・バランサは、リモート・リージョンにデプロイされたバックエンドをサポートするようになりました。この柔軟性は、創造的なネットワーク設計のロックを解除することができます。たとえば、お客様は、ローカル・インスタンスまたはネットワーク障害をカバーするために、バックエンドのサブセットをリモート・リージョンにデプロイできます。

次の例は、OCIリージョンUS-Westのネットワーク・ロード・バランサと、リモート・リージョンUS-Eastのバックエンドを示しています。バックエンド・セットのヘルス・チェックは、TCPポート80で実行されます。前回の設計シナリオで説明したVCNルーティングおよびセキュリティ・リスト・ルールの要件、DRGを介したVCN内のバックエンドもここに適用されます。また、2つのリージョンのDRGをリモート・ピアリング接続(RPC)で接続する必要があります。VCNおよびRPCアタッチメントに対して自動生成されたDRGルート表をそのまま使用すると、両方のリージョンのVCNルートは自動的に反対側に伝播され、VCNアタッチメントのDRGルート表にインポートされます。自動生成された DRGルート表のインポート・ディストリビューション・ポリシーを変更した場合、またはVCNアタッチメントや RPCアタッチメントに独自のDRGルート表を使用している場合は、VCNのDRGルート表がRPCアタッチメントからルートをインポートするように、必要な分散ポリシーがDRGルート表に設定されていることを確認してください。

Diagram A: Routing and security configuration for the network load balancer and backend subnets

Diagram B: DRG route tables with the needed routes

オンプレミス・バックエンドを使用するOCIネットワーク・ロード・バランサ

オンプレミス・バックエンドのサポートは、OCIネットワーク・ロード・バランサに対して頻繁に要求される拡張であり、お客様はOCI管理のネットワーク・ロード・バランサを使用して、オンプレミス・ネットワークでホストされているアプリケーションやサービスをスケールアウトしたいと考えています。この機能の一般的なユース・ケースは、OCIネットワーク・ロード・バランサを使用して、オンプレミスのDNSサーバーのクラスタをフロントエンドし、容量を管理し、冗長性を確保することです。

次の図は、この概念の動作を示しています。これは、オンプレミスDNSサーバーがOCIネットワーク・ロード・バランサのバックエンドであるプライベートDNS設定を示しています。オンプレミス・ネットワークは、FastConnect仮想回線を介してOCIリージョンに接続されます。

An on-premises deployment of backends.

この例のルーティング構成では、ネットワーク・ロード・バランサ・サブネットのルート表にオンプレミス・バックエンド・サブネットの静的ルートを追加することが重要です。このルートのネクストホップ・ターゲットはDRGです。

この図は、ネットワーク・ロード・バランサのVCNアタッチメントとFastConnect仮想回線アタッチメントの両方について、DRG表内の必要なルートも強調表示しています。ネットワーク・ロード・バランサVCNアタッチメントのルート表には、次ホップとしてFastConnect仮想回線アタッチメントを持つオンプレミス・バックエンド・サブネットのルートが必要ですが、FastConnect仮想回線アタッチメントのルート表には、ネットワーク・ロード・バランサVCNアタッチメントがネクストホップであるネットワーク・ロード・バランサ・サブネットまたはVCN CIDRのルートが必要です。これらの2つのアタッチメントに、デフォルトのインポート・ディストリビューション・ポリシーで自動生成されたDRGルート表を使用する場合、これらのルートはDRGの動的ルーティング機能によって自動的に移入されます。これらの自動生成されたルート表のインポート・ディストリビューション・ポリシーを変更した場合、または独自のDRGルート表を使用する場合は、FastConnectアタッチメント・ルート表がネットワーク・ロード・バランサのVCNアタッチメントからルートをインポートするなど、ルートを相互に正しくインポートするように、適切なインポート・ディストリビューション・ポリシーがあることを確認してください。DRGは、顧客のオンプレミス機器(CPE)からBGPまでのオンプレミス・ネットワーク・ルートを学習するため、オンプレミス・バックエンド・サブネットをDRGにアドバタイズするようにCPE上のBGPルーティングが正しく構成されていることも確認する必要があります。

この例の健全性検査では、次の図に示すように、DNSプロトコルと UDPポート53を使用します:

A DNS health check

DNSヘルス・チェックは、OCI Network Load Balancerで新しく追加された機能です。同僚のTim Sammut氏が、DNSの冗長性とフェイルオーバーにOCI Network Load Balancerを使用する素晴らしいブログを発表しました(こちら)。OCI Network Load BalancerによるDNSのユース・ケースの詳細については、こちらをご覧ください。

DNSサービスは、クライアントとDNSサーバー間のDNS問合せおよびレスポンスに対して、非常に多くの短期間接続を生成する傾向があります。1秒当たり数万または数百万のリクエストまたは接続(CPS)が可能です。この高いCPS率でDNSトラフィックにステートフル・セキュリティ・リスト・ルールを使用すると、ステートフル・ルールの施行に使用されるネットワーク・ロード・バランサまたはバックエンド・コンピュート・ホスト上の接続トラッキング表リソースを使い果たすことができます。したがって、DNSサービスやCPSレートが類似したその他のサービスのベスト・プラクティスは、ステートレス・セキュリティ・ポリシーを使用することです。このポリシーでは、イングレス方向とエグレス方向の両方に明示的な許可ルールを作成する必要があります。次のイメージは、この例で、ネットワーク・ロード・バランサ・サブネットまたはネットワーク・ロード・バランサのNSGに対して推奨されるステートレス・セキュリティ・リスト・ルールを示しています:

Security policies for on-premises DNS backends

まとめ

この記事の機能拡張により、OCIネットワーク・ロード・バランサ・バックエンドに関連する履歴制約が正常に削除され、デプロイメントの可能性および接続オプションが拡張されました。DNSヘルス・チェックなど、最近導入された他のNetwork Load Balancer機能とともに、これらの改善により、お客様はOCI Network Load Balancerアプリケーションの範囲を広げ、新しいユース・ケースを実現できます。これらの機能強化は、OCIでのお客様のネットワーク設計の簡素化に貢献しています。近いうちに、当社のチームによるさらなる開発と新しい機能についてご期待ください。

Oracle Cloud Infrastructure Network Load Balancerおよびクラウド・ネットワーキングの詳細は、次のリソースを参照してください: