プライベート・パス・サービスについて

プライベート・パス・サービスは、 IBM Cloud とサードパーティ・サービスのためのプライベート接続を提供する。 Private Path サービスには、 IBM Cloud 上にサービスを展開するための Private Path ネットワーク・ロード・バランサー（NLB）と、コンシューマーがサービスに接続するための Virtual Private Endpoint（VPE）ゲートウェイが必要です。 トラフィックはインターネットを横断することなく、 IBM のバックボーンに留まる。

プロバイダーと消費者間のプライベート接続を確立する典型的なプロセスは以下の通りです

  1. プロバイダーはプライベート・パス・サービスを作成します。
  2. プロバイダーは、プライベート・パス・サービスをプライベート・パス NLB に関連付けます。
  3. プロバイダーは、固有のプライベート・パス・サービス・クラウド・リソース名 (CRN) などの関連情報をサービス・コンシューマーと共有します。
  4. コンシューマーは、プライベート・パス・サービスの CRN を構成する VPE ゲートウェイを作成します。 次に、接続リクエストがサービスプロバイダに送信されます。
  5. プロバイダーは、必要に応じて、コンシューマーの要求を許可または拒否し、アカウント・ポリシーをセットアップします (あるいは、コンシューマー要求を自動的に許可または拒否するようにアカウント・ポリシーをセットアップすることもできます)。
  6. コンシューマーには、接続要求の状況が通知されます。 許可されている場合、コンシューマーはサービスにアクセスできます。拒否されている場合、コンシューマーはプロバイダーに連絡して詳細を確認できます。

詳しくは、「 プライベート・パス・ソリューション・ガイド」を参照してください。

以下のアクションを実行できるかどうかは、 IBM Cloud アカウントに関連付けられている IAM 権限のレベルによって異なります。 詳しくは、 必要な許可 を参照してください。

プライベート・パス・サービスの概要

サービス・プロバイダーとして開始するには、以下の手順を実行します。

  1. 仮想プライベートクラウド（VPC）と、選択したVPC内に少なくとも1つのサブネットが存在することを確認してください。

  2. プライベート・パス・サービスを作成します。

    • アカウントに特定のポリシーが割り当てられていない場合のデフォルト・ポリシーを設定します。 デフォルト・ポリシー (「レビュー」) では、各要求を許可または拒否できますが、 「許可」 および 「拒否」 では、特定のアカウント・ポリシーを持たない接続要求のプロセスが自動化されます。
    • 特定のアカウント ID のアカウント・ポリシーを今すぐ作成するか、後で作成します。 これらのポリシーは、プロバイダーが特定のアカウントから要求を受け取ったときに実行するアクションを決定し、デフォルト・ポリシーよりも優先されます。

  3. プライベートパス NLB を作成します。

    • プライベート・パス・サービスの作成時にプライベート・パス NLB を作成することも、 「Load balancer for VPC」 プロビジョニング・ページを使用してプライベート・パス NLB を作成することもできます。 プライベート・パス・サービスとは別のプライベート・パス・ロード・バランサーを作成するには、 プライベート・パス・ネットワーク・ロード・バランサーの作成 を参照してください。
    • プライベートパス NLB およびプライベートパス サービスについては、同じ VPC リージョン内のアカウントを使用する必要があります。

プライベート・パス・サービスのユース・ケース

以下の使用例は、プライベート・パス・サービスを使用する様々な方法を示しています。

すべてのプライベート・パスのユースケースにおいて、ALBポリシー機能を使用してプライベート・パスのサービス・トラフィックを誘導することができる。

ユース・ケース 1: 単一のコンシューマーへのサービスの接続

プロバイダーとしては、インターネット経由のトラフィックを発生させず、またVPC全体へのアクセス権を与えずに、自社のサービスを消費者と接続したいと考えるでしょう。 あなたの消費者とは、顧客、社内の他部署、またはその他の何かである可能性があります。

この図は、プライベートパスサービスの確立方法を説明しています。 プライベート・パス・サービスを確立すると、サービスをプライベートに顧客に公開することができます。

まず、消費者のアプリケーションが、消費者のVPC内のVPEゲートウェイに接続します。 次に、VPEゲートウェイはプロバイダーのVPC内のプライベートパスNLBに接続します。 一方、プライベートパスNLBはプロバイダーのサービスに接続します。 プロバイダーのサービスは、ダイレクト・サーバー・リターン（DSR）を通じて、消費者のリクエストに応答します。 このプライベート・パス・サービス・アクティビティーは、 IBM Cloud プライベート・ネットワーク内の単一リージョン (米国南部) に完全に含まれています。

顧客にサービスを公開するプライベート・パス
公衆インターネット
を使わずに顧客にサービスを公開するプライベート・パス

ユースケース2：サービスを複数の消費者に接続する

この図は、複数の消費者VPEゲートウェイへの接続を持つプライベートパスサービスの確立方法を示しています。

まず、消費者のアプリケーションが、その消費者の VPC 内の VPE ゲートウェイに接続します。 次に、VPEゲートウェイはプロバイダーのVPC内のプライベートパスNLBに接続します。 一方、プライベートパスNLBはプロバイダーのサービスに接続します。 プロバイダーのサービスは、DSRを通じて消費者のリクエストに応答します。 このプライベート・パス・サービス・アクティビティーは、 IBM Cloud プライベート・ネットワーク内の単一リージョン (米国南部) に完全に含まれています。

複数の顧客にサービスを公開するプライベート・パス
公衆インターネット
を使用せずに複数の顧客にサービスを公開するプライベート・パス

ユース・ケース 3: VPC 内の顧客へのサービスの接続

この図は、VPC内の消費者によるVPEゲートウェイへの接続を持つプライベートパスサービスの確立方法を示しています。

プライベートパスのネットワークロードバランサーのパフォーマンスとスケーラビリティを強化する必要がある場合は、単一のVPC内でプライベートパスのサービスを使用します。

まず、消費者のアプリケーションがプロバイダーの VPC 内の消費者の VPE ゲートウェイに接続します。 次に、VPEゲートウェイはプロバイダーのVPC内のプライベートパスNLBに接続します。 一方、プライベートパスNLBはプロバイダーのサービスに接続します。 プロバイダーのサービスは、DSRを通じて消費者のリクエストに応答します。 このプライベート・パス・サービス・アクティビティーは、 IBM Cloud プライベート・ネットワーク内の単一リージョン (米国南部) に完全に含まれています。

同一VPC内の顧客にサービスを公開するプライベート・パス
同一VPC内の顧客にサービスを公開するプライベート・パス* パブリック・
を使用しないプライベート・パス

ユースケース4 IBM CloudをプロバイダーのVPCに接続可能にする

プライベート・パスは、IBM Cloud Code EngineのようなIBM Cloudサービスと VPC の間の接続を可能にします。 Code Engine は、ソースコードまたはコンテナ化されたワークロードを実行するマルチテナント型コンピュート・サービスです。 その動的なスケーリング機能により、アプリケーションは、入ってくるリクエストに基づいて、自動的にスケールアップしたり、スケールダウンしたりすることができます。 従量課金モデルにより、 Code Engine、実際に使用した計算容量に対してのみ課金される。 詳細については、IBM Cloud Code Engine を参照してください。

この図は、 Code Engine アプリケーションのVPEゲートウェイとお客様のVPCへの接続を持つプライベートパスサービスの確立方法を示しています。 まず、 Code Engine アプリケーションは、 Code Engine のVPC内のVPEゲートウェイに接続します。 次に、VPEゲートウェイはプロバイダーのVPC内のプライベートパスNLBに接続します。 一方、プライベートパスNLBはプロバイダーのアプリケーションに接続します。 すると、プロバイダーのアプリケーションがリクエストに応答します。 このプライベートパスサービス活動は、 IBM Cloud プライベートネットワーク内の単一の地域（us-south ）に完全に含まれています。

Code Engine とプライベート・パスを使用して、動的および静的なスケーリングが必要な複雑なアーキテクチャを展開する とプライベート・パスを使用して、動的および静的なスケーリングが必要な複雑なアーキテクチャを展開する とプライベート・パスを使用して、動的および静的なスケーリングが必要な複雑なアーキテクチャを展開する
Code Engine

ユースケース5：プライベートパスNLBでALBを使用してVPC外のサービスをホストする

次の図は、コンシューマーのサービスをプロバイダーのエンドポイントに接続するためのプライベート・パス・サービスの設定プロセスを示している：

  1. コンシューマのアプリケーションやサービスは、コンシューマのVPC内の仮想プライベート・エンドポイント（VPE）ゲートウェイに接続する。

    コンシューマのVPCは、 MQ as a Serviceや Code Engine のようなプライベート・パスをサポートする IBM。 これにより、オンクラウドの MQ Queue ManagerとオンプレミスのQueue Managerをリンクしたり、 Code Engine プロジェクトとオンプレミスのリソースを接続したりすることができます。

  2. そしてVPEゲートウェイは、プロバイダーのVPCにあるプライベートパスのネットワークロードバランサー（NLB）にリンクする。

  3. プライベートパスNLBがオンプレミスのエンドポイントに到達できるように、プロバイダーはアプリケーションロードバランサー（ALB）をプライベートパスNLBのメンバーとして追加する。

  4. プロバイダーは、オンプレミスのエンドポイントをALBプール・メンバーとして構成する。

  5. 最後に、プロバイダーは IBM Cloud Direct Link を使ってオンプレミスのエンドポイントを ALB に接続する。

プロバイダーは、さらにALBポリシー機能を活用して、トラフィックを関連するALBプールとメンバーに誘導することができる。 詳しくは、 ポリシーベースのロードバランシングを 参照。

クライアントから VPE ゲートウェイへのトラフィックが、同じゾーン内のプライベート・パス NLB および ALB に確実に誘導されるように、プライベート・パス・サービスでゾーン・アフィニティを有効にすることを推奨します（利用可能な場合）。

caption-side=bottom"

ユースケース6： Direct Link 、サービスを消費者に接続する。 Transit Gateway

以下の図は、 Direct Link または Transit Gateway を使用して、コンシューマーが複数の環境からどのようにプライベート・パス・サービスにアクセスできるかを示しています。

コンシューマーはあるVPCでアプリケーションをホストし、別のVPCのエンドポイント・ゲートウェイに接続することができる。 例えば、 Consumer VPC 1 のアプリケーションは、 Transit Gateway経由して Consumer VPC 2 のエンドポイント・ゲートウェイに到達できます。 同様に、オンプレミス・アプリケーションは、 Direct Link を介してコンシューマーVPC 2のエンドポイント・ゲートウェイに接続できます。

エンドポイント・ゲートウェイは、 プロバイダーVPC 内のプライベート・パス・ネットワーク・ロードバランサー（NLB）に接続することで、プライベート・パス・サービスへのアクセスを提供します。 その後、プライベート・パスNLBはプロバイダーのサービスにトラフィックをルーティングする。 詳細は VPEへの高可用性アクセスは、 Transit Gateway または Direct Link を参照。

Direct Link または Transit Gateway
を介してコンシューマーVPEに接続するコンシューマーサービス 「コンシューマーアプリケーションは、 Direct Link および Transit Gateway が基盤となる接続性を提供するプライベートパスを使用してプロバイダーサービスにアクセスする。