次の方法で共有

セルフホステッド ゲートウェイの概要

  • [アーティクル]

適用対象: 開発者 | プレミアム

セルフホステッド ゲートウェイは、すべての API Management サービスに含まれる既定のマネージド ゲートウェイの、オプションのコンテナー化されたバージョンです。 これは、API をホストするのと同じ環境にゲートウェイを配置する場合などのシナリオで役立ちます。 セルフホステッド ゲートウェイを使用して API トラフィック フローを改善し、API のセキュリティとコンプライアンスの要件に対処します。

この記事では、Azure API Management のセルフホステッド ゲートウェイ機能を使ってハイブリッドおよびマルチクラウドの API 管理を実現する方法について説明します。また、その大まかなアーキテクチャを紹介し、機能を取り上げます。

さまざまなゲートウェイ オファリングの機能の概要については、API Management の API ゲートウェイに関するページを参照してください。

ハイブリッドおよびマルチクラウドでの API 管理

セルフホステッド ゲートウェイ機能は、ハイブリッド環境とマルチクラウド環境に対する API Management サポートを拡張し、オンプレミスや複数のクラウドにわたってホストされている API を、組織が Azure の単一 API Management サービスから効率的かつ安全に管理できるようにします。

セルフホステッド ゲートウェイを使用すると、お客様は、コンテナー化されたバージョンの API Management ゲートウェイ コンポーネントを、API をホストしているのと同じ環境に柔軟にデプロイできるようになります。 すべてのセルフホステッド ゲートウェイは、フェデレーションされている API Management サービスから管理されます。これによりお客様には、内部と外部のすべての API にわたる可視性と統合された管理エクスペリエンスが提供されます。

それぞれの API Management サービスは、以下の主なコンポーネントで構成されています。

  • API として公開される管理プレーン。Azure portal、PowerShell、およびその他のサポートされているメカニズムによってサービスを構成するために使用されます。
  • API 要求のプロキシ処理、ポリシーの適用、テレメトリの収集を行うゲートウェイ (またはデータ プレーン)
  • API を利用するための検索、学習、およびオンボードのために開発者によって使用される開発者ポータル

既定では、これらのすべてのコンポーネントが Azure にデプロイされ、API を実装しているバックエンドがホストされている場所に関係なく、すべての API トラフィック (下図では実線の黒い矢印として示されています) が Azure 経由で流れるようになります。 このモデルの運用上のシンプルさは、待機時間の増加やコンプライアンスの問題という代償によって実現されており、場合によっては追加のデータ転送料金が発生します。

セルフホステッド ゲートウェイを使用しない場合の API トラフィック フロー

セルフホステッド ゲートウェイをバックエンド API 実装がホストされているのと同じ環境にデプロイすると、API トラフィックがバックエンド API に直接流れることができます。これにより、待機時間が短縮されて、データ転送コストが最適化され、コンプライアンスを実現でき、同時に、実装がホストされている場所に関係なく、組織内のすべての API を 1 か所で管理、監視、検出するというメリットも維持されます。

セルフホステッド ゲートウェイを使用する場合の API トラフィック フロー

梱包

セルフホステッド ゲートウェイは、Microsoft Artifact Registry から Linux ベースの Docker コンテナー イメージとして入手できます。 オンプレミスのサーバー クラスターで実行されている Docker、Kubernetes などのコンテナー オーケストレーション ソリューション、クラウド インフラストラクチャ、または評価と開発が目的の場合はパーソナル コンピューター上にデプロイできます。 また、セルフホステッド ゲートウェイをクラスター拡張機能として、Azure Arc 対応 Kubernetes クラスターにデプロイすることもできます。

コンテナー イメージ

セルフホステッド ゲートウェイには、お客様のニーズを満たすさまざまなコンテナー イメージが用意されています。

タグ表記規則 推奨 例 ローリング タグ 運用での推奨可否
{major}.{minor}.{patch} 常に同じバージョンのゲートウェイを実行するには、このタグを使用します 2.0.0 ❌ ✔️
v{major} このタグを使用すると、すべての新機能とパッチで常にメジャー バージョンのゲートウェイが実行されます。 v2 ✔️ ❌
v{major}-preview 常に最新のプレビュー コンテナー イメージを実行する場合は、このタグを使用します。 v2-preview ✔️ ❌
latest セルフホステッド ゲートウェイを評価する場合は、このタグを使用します。 latest ✔️ ❌
beta1 セルフホステッド ゲートウェイのプレビュー バージョンを評価する場合は、このタグを使用します。 beta ✔️ ❌

使用可能なすべてのタグの一覧は、こちらでご覧いただけます。

1プレビュー バージョンは公式にはサポートされておらず、試験的な目的でのみ使用されます。 「セルフホステッド ゲートウェイのサポート ポリシー」をご覧ください。

公式のデプロイ オプションでのタグの使用

Azure portal における Microsoft のデプロイ オプションでは v2 タグが使用されます。お客様は、すべての機能更新プログラムとパッチを含んだ最新バージョンのセルフホステッド ゲートウェイ v2 コンテナー イメージを使用できます。

Note

参考としてコマンドと YAML スニペットを用意しています。必要に応じて、より具体的なタグを自由にご使用ください。

Helm チャートでインストールすると、イメージのタグ付けが自動的に最適化されます。 Helm チャートのアプリケーション バージョンでは、ゲートウェイは特定のバージョンに固定され、latest に依存しません。

Helm で Kubernetes に API Management セルフホステッド ゲートウェイをインストールする方法の詳細を確認してください。

ローリング タグを使用するリスク

ローリング タグは、新しいバージョンのコンテナー イメージがリリースされたときに更新される可能性のあるタグです。 これによってコンテナー ユーザーは、デプロイを更新しなくても、コンテナー イメージの更新を受け取ることができます。

これは、複数の異なるバージョンが並列に実行される可能性があることを意味します。たとえば、v2 タグが更新された後でスケーリング アクションを実行した場合、バージョンが切り替わっても気付かない可能性があります。

たとえば、v2 タグが 2.0.0 コンテナー イメージでリリースされ、その後、2.1.0 がリリースされると、v2 タグは 2.1.0 イメージに関連付けられます。

重要

新しいバージョンへの意図しないアップグレードを避けるために、運用環境で特定のバージョン タグを使用することを検討してください。

Azure への接続性

セルフホステッド ゲートウェイには、ポート 443 での Azure への送信 TCP/IP 接続が必要です。 各セルフホステッド ゲートウェイは、1 つの API Management サービスに関連付けられている必要があり、管理プレーンを介して構成されます。 セルフホステッド ゲートウェイは、以下の場合に Azure への接続を使用します。

  • 1 分ごとのハートビート メッセージ送信による状態の報告
  • 構成の更新の、定期的チェック (10 秒ごと) と、入手可能な場合は常に実行する適用
  • メトリックの Azure Monitor への送信 (これを行うよう構成されている場合)
  • Application Insights へのイベントの送信 (これを行うよう設定されている場合)

FQDN の依存関係

適切に動作するには、各セルフホステッド ゲートウェイは、クラウドベースの API Management インスタンスに関連付けられている次のエンドポイントに、ポート 443 での送信接続を必要とします。

説明 v1 に必須 v2 に必須 Notes
構成エンドポイントのホスト名 <apim-service-name>.management.azure-api.net <apim-service-name>.configuration.azure-api.net1 カスタム ホスト名もサポートされており、既定のホスト名の代わりに使用できます。
API Management インスタンスのパブリック IP アドレス ✔️ ✔️ プライマリ ロケーションの IP アドレスは要件を満たしています。
Azure Storage サービス タグのパブリック IP アドレス ✔️ 省略可能2 IP アドレスは、API Management インスタンスのプライマリの場所に対応している必要があります。
Azure Blob Storage アカウントのホスト名 ✔️ 省略可能2 インスタンスに関連付けられているアカウント (<blob-storage-account-name>.blob.core.windows.net)
Azure Table Storage アカウントのホスト名 ✔️ 省略可能2 インスタンスに関連付けられているアカウント (<table-storage-account-name>.table.core.windows.net)
Azure Resource Manager 用エンドポイント ✔️ オプション3 必要なエンドポイントは management.azure.com です。
Microsoft Entra 統合のエンドポイント ✔️ 省略可能4 必要なエンドポイントは <region>.login.microsoft.com と login.microsoftonline.com です。
Azure Application Insights 統合のエンドポイント 省略可能5 省略可能5 最低限必要なエンドポイントは次のとおりです。
  • rt.services.visualstudio.com:443
  • dc.services.visualstudio.com:443
  • {region}.livediagnostics.monitor.azure.com:443
Azure Monitor のドキュメントで詳細を確認する
Event Hubs 統合のエンドポイント 省略可能5 省略可能5 Azure Event Hubs のドキュメントで詳細を確認する
外部キャッシュ統合のエンドポイント 省略可能5 省略可能5 この要件は、使用されている外部キャッシュによって異なります

1内部仮想ネットワーク内の API Management インスタンスについては、「内部仮想ネットワークの接続性」を参照してください。
2API インスペクターまたはクォータがポリシーで使用されているときに、v2 でのみ必要です。
3Microsoft Entra 認証を使用して RBAC のアクセス許可を確認する場合にのみ必要です。
4Microsoft Entra 認証または Microsoft Entra 関連のポリシーを使用する場合にのみ必要です。
5機能が使用され、パブリック IP アドレス、ポート、ホスト名の情報が必要な場合にのみ必要です。

重要

  • DNS ホスト名は IP アドレスに解決できる必要があり、対応する IP アドレスは到達可能である必要があります。
  • 関連付けられているストレージ アカウントの名前は、Azure portal のサービスの「ネットワーク接続の状態」ページに一覧表示されます。
  • 関連付けられているストレージ アカウントの基になるパブリック IP アドレスは動的であり、予告なしに変更することができます。

内部仮想ネットワークの接続性

  • プライベート接続 - セルフホステッド ゲートウェイが仮想ネットワークにデプロイされている場合は、セルフホステッド ゲートウェイの場所から v2 構成エンドポイントへのプライベート接続を有効にします。たとえば、ピアリングされたネットワークでプライベート DNS を使用します。

  • インターネット接続 - セルフホステッド ゲートウェイがインターネット経由で v2 構成エンドポイントに接続する必要がある場合は、構成エンドポイントのカスタム ホスト名を構成し、Application Gateway を使用してエンドポイントを公開します。

認証オプション

セルフホステッド ゲートウェイとクラウドベースの API Management インスタンスの構成エンドポイントの間の接続を認証するには、ゲートウェイ コンテナの構成設定に次のオプションがあります。

オプション 考慮事項
Microsoft Entra 認証 ゲートウェイにアクセスするために 1 つ以上の Microsoft Entra アプリを構成する

アプリごとに個別にアクセスを管理する

組織のポリシーに従って、シークレットの有効期限を長く設定する

標準の Microsoft Entra 手順を使用して、アプリに対するユーザーまたはグループのアクセス許可を割り当てまたは取り消し、シークレットをローテーションする
ゲートウェイ アクセス トークン (認証キーとも呼ばれます) トークンは最大 30 日ごとに期限切れになり、コンテナ内で更新する必要があります

独立してローテーションできるゲートウェイ キーによって裏付けられています(アクセスを取り消すためなど)

ゲートウェイ キーを再生成すると、そのキーで作成されたすべてのアクセス トークンが無効になります

接続エラー

Azure への接続性が失われると、セルフホステッド ゲートウェイは構成の更新の受信、状態の報告、テレメトリのアップロードができません。

セルフホステッド ゲートウェイは、"静的に失敗する" ように設計されており、Azure への接続が一時的に失われても問題は生じません。 これは、ローカル構成のバックアップの有無にかかわらずデプロイできます。 構成のバックアップが有効な場合、セルフホステッド ゲートウェイでは定期的に、コンテナーまたはポッドに接続された永続的ボリュームに最新のダウンロードされた構成のバックアップ コピーが保存されます。

構成のバックアップがオフになっていて、Azure への接続が断たれると、以下のようになります。

  • セルフホステッド ゲートウェイの実行は、構成のメモリ内コピーを使用して機能し続けます
  • 停止されていたセルフホステッド ゲートウェイは起動できなくなります

構成のバックアップがオンになっていて、Azure への接続が断たれると、以下のようになります。

  • セルフホステッド ゲートウェイの実行は、構成のメモリ内コピーを使用して機能し続けます
  • 停止されていたセルフホステッド ゲートウェイは、構成のバックアップ コピーの使用を開始できるようになります

接続が復元されると、停止の影響を受けた各セルフホステッド ゲートウェイは、関連付けられている API Management サービスに自動的に再接続し、ゲートウェイが "オフライン" になっていた間に発生したすべての構成の更新をダウンロードします。

Security

制限事項

マネージ ゲートウェイにある次の機能は、セルフホステッド ゲートウェイでは使用できません。

  • TLS セッションの再開。
  • クライアント証明書の再ネゴシエーション。 クライアント証明書の認証を使用するには、API コンシューマーが初期 TLS ハンドシェイクの一部として証明書を提示する必要があります。 この動作を保証するには、セルフホステッド ゲートウェイのカスタム ホスト名 (ドメイン名) を構成するときに、クライアント証明書のネゴシエート設定を有効にします。

トランスポート層セキュリティ (TLS)

重要

この概要は、セルフホステッド ゲートウェイ v1 および v2 にのみ適用されます。

サポートされるプロトコル

セルフホステッド ゲートウェイでは、既定で TLS v1.2 がサポートされます。

カスタム ドメインを使用しているお客様は、コントロール プレーンで TLS v1.0 または v1.1 (あるいはその両方) を有効にすることができます。

使用可能な暗号スイート

重要

この概要は、セルフホステッド ゲートウェイ v2 にのみ適用されます。

セルフホステッド ゲートウェイは、クライアントとサーバーの両方の接続に次の暗号スイートを使用します。

  • TLS_AES_256_GCM_SHA384
  • TLS_CHACHA20_POLY1305_SHA256
  • TLS_AES_128_GCM_SHA256
  • TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
  • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
  • TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
  • TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
  • TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
  • TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256
  • TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
  • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
  • TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
  • TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
  • TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
  • TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
  • TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
  • TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
  • TLS_DHE_RSA_WITH_AES_256_CBC_SHA
  • TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
  • TLS_DHE_RSA_WITH_AES_128_CBC_SHA
  • TLS_RSA_WITH_AES_256_GCM_SHA384
  • TLS_RSA_WITH_AES_128_GCM_SHA256
  • TLS_RSA_WITH_AES_256_CBC_SHA256
  • TLS_RSA_WITH_AES_128_CBC_SHA256
  • TLS_RSA_WITH_AES_256_CBC_SHA
  • TLS_RSA_WITH_AES_128_CBC_SHA

暗号スイートの管理

v2.1.1 以降では、構成によって使用中の暗号を管理できます。

  • net.server.tls.ciphers.allowed-suites では、API クライアントとセルフホステッド ゲートウェイ間の TLS 接続に使用する暗号のコンマ区切りの一覧を定義できます。
  • net.client.tls.ciphers.allowed-suites では、セルフホステッド ゲートウェイとバックエンド間の TLS 接続に使用する暗号のコンマ区切りの一覧を定義できます。

次のステップ