OCIネットワーキングのリソースごとのルーティングの発表 (2025/03/01)

https://blogs.oracle.com/cloud-infrastructure/post/perresource-routing-for-oci-networking

投稿者： Brandon Beck | Consulting Member of Technical Staff

ルーティングは、あらゆるクラウド環境におけるネットワーキングの基本的な側面です。Oracle Cloud Infrastructure(OCI)内では、仮想クラウド・ネットワーク(VCN)は、サブネット、インターネット・ゲートウェイ、オンプレミス・ネットワーク、その他のOCIリソース間でトラフィックを転送する強力なフレームワークを提供します。このコア・ネットワーキング機能(リソースごとのルーティング)の極めて重要な更新を発表できることを嬉しく思います。

宛先のみに基づいて決定を行う従来のルーティングとは異なり、リソースごとのルーティングでは、仮想ネットワーク・インタフェース・カード(VNIC)や割り当てられたIPv4/IPv6アドレスなどのソース・リソースに基づいてルーティングに影響を与えることができます。ルート表をVNICまたはIPアドレスに関連付けることで、同じサブネット内のワークロードに対してトラフィックを異なる方法でルーティングできます。このブログ投稿は、リソースごとのルーティングを導入している理由、その仕組み、および既存のネットワーク・アーキテクチャにシームレスに統合する方法を理解するのに役立ちます。

リソースごとのルーティングが必要な理由

ネットワーク・ルーティングのニーズがより多様化すると、サブネット内のトラフィック・ルーティングをより詳細に制御するための需要が高まることがわかります。たとえば、特定のワークロードをモニタリングまたは侵入防止システムに転送する必要がある場合、ネットワーク仮想アプライアンスを使用してハブVCNを設定できます。各インタフェースに個別のルーティング構成が必要な場合や、個別のルーティング・ニーズを持つノード・ポートに複数のアドレスを割り当てる必要があるベア・メタル・インスタンス上でKubernetes環境が実行されている場合があります。

以前は、特定のルーティング要件に合せた複数のサブネットを作成することで、これらのニーズに対処していました。リソースごとのルーティングにより、必要なサブネットの数を減らすことでアーキテクチャを簡素化できます。特定のルートテーブルをVNICまたはIPアドレスに直接関連付けることができるため、設計の複雑さを増すことなく、より正確なトラフィック制御が可能になります。セキュリティ・セグメンテーションはネットワーク・セキュリティ・グループ(NSG)を通じてそのまま維持されるため、セキュリティを損なうことなく設計を合理化できます。

リソース単位ルーティングの利点

VNICのユースケース

リージョン内の共通ネットワーク・アーキテクチャは、プライベート・サブネット、パブリック・サブネット、ルート表、および様々なルート・ターゲット(インターネット・ゲートウェイ、NATゲートウェイ、サービス・ゲートウェイ、動的ルーティング・ゲートウェイ(DRG)など)の形式のゲートウェイの組合せで構成されます。次の図は、単純なトポロジ例を示しています。

このトポロジのルーティングは、サブネット、ゲートウェイおよびDRGアタッチメントに関連付けられたルート表に基づきます。たとえば、PrivSubnet1という名前のプライベート・サブネット内にデプロイされたすべてのインスタンスは、関連付けられたルート表PrivRouteTableに基づいてルーティングされます。

次に、ファイアウォールなどのネットワーク仮想アプライアンス(NVA)を、特定のアプリケーションをNATゲートウェイに移動する前に移動させるVCNに導入します。この投稿では、NATゲートウェイではリターン・トラフィックを処理するために変更が必要になるため、NVAを介したルーティング・トラフィックのエグレス部分のみをカバーしています。イングレス・ルーティングの構成方法など、より包括的な説明は、「OCI Intra-VCNルーティングおよびVCNゲートウェイ・イングレス・ルーティングの機能拡張の発表」を参照してください。

このNVAを介してトラフィックをルーティングするには、プライベート・ネットワークの既存のルート表PrivRouteTblを変更できますが、VM-Cのみなど、このNVAを介してルーティングされる内容を選択的にする場合はどうなりますか。NVAを指すデフォルト・ルートを含む新しいルート表を使用してプライベート・サブネットを作成し、VM-Cをこの新しいサブネットに移動または再デプロイできます。ただし、リソースごとのルーティングでは、新しいルート表をVM-Cの既存のVNICに関連付けて、新しいサブネットの必要性をなくし、インスタンスのIPアドレスを変更することで、このプロセスをさらに簡略化できます。

リソース単位のルーティングでは、ルート検索は、IPアドレス、VNIC、最後にサブネットから始めて、特定性に基づく階層に従います。この例では、ルート表がVM-C VNICに関連付けられているため、サブネット・レベルのPrivRouteTblルートは適用されません。その結果、VM-C VNICにリンクされたルート表には、NVAへのルートのみでなく、必要なすべてのルートを含める必要があります。

IPアドレスのユースケース

VNICユース・ケースのトポロジ例を使用して、別のユース・ケースを見てみましょう。ここでは、2つの個別のデフォルト・ルート(オンプレミス・ネットワークへのルートとNATゲートウェイへのルート)を持つ単一インスタンス(VM-B)があります。

この構造を実現するには、インスタンスに2番目のVNICを追加し、その2番目のVNICを個別のルート表に関連付けられた個別のサブネットに配置します。前の項の例に従い、同じサブネットを使用することもできますが、離散ルート表を2番目のVNICに関連付けることもできます。

デュアル・ゲートウェイ・トポロジの実現のみを目的として、この2番目のVNICをアタッチすると、インスタンスに不要なオーバーヘッドが追加される可能性があります。1つのインスタンスでサポートされているVNICの合計数は、そのコンピュート・シェイプ内に構成されているシェイプおよびOCPUによって異なります。

リソースごとのルーティングでは、より効率的なアプローチが可能です。PrivSubNet1の既存のVNICにセカンダリIPアドレスを割り当て、そのセカンダリIPに個別のルート表を関連付けます。

まとめ

リソース当たりのルーティングは、Oracle Cloud Infrastructureでのネットワーキングの管理方法に大きなアップグレードをもたらします。ソース・リソースに基づくルーティングの決定を有効にすることで、ルーティングの変更をネットワーク内にどのようにデプロイするかを簡素化できるため、柔軟性が向上し、操作が簡素化されます。

ハブ・アンド・スポーク設計の合理化、ネットワーク仮想アプライアンスの統合、特定のワークロードのダイレクト・トラフィックなど、リソースごとのルーティングにより、スケーラブルで効率的なソリューションが提供されます。この機能を使用すると、ビジネス・ニーズにあわせて進化するセキュアで適応性の高いクラウド環境を構築できます。この機能の実装方法の詳細は、VNICまたはVNIC IPアドレスのカスタム・ルート表を参照してください。