次の方法で共有

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

適用対象: Developer | Premium

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

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

マネージド ゲートウェイとセルフホステッド ゲートウェイの違いの概要については、 API Management の API ゲートウェイに関するページを参照してください。

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

セルフホステッド ゲートウェイ機能により、ハイブリッド環境とマルチクラウド環境に対する API Management のサポートが拡張され、Azure 上の単一の API Management インスタンスから、オンプレミスおよびクラウド間でホストされている API を効率的かつ安全に管理できます。

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

各 API Management インスタンスは、次の主要なコンポーネントで構成されます。

  • AZURE portal、PowerShell、およびその他のサポートされているテクノロジを使用してサービスを構成するために使用される、API として公開される管理プレーン
  • API 要求のプロキシ、ポリシーの適用、テレメトリの収集を担当するゲートウェイ (またはデータ プレーン)
  • 開発者が API を使用するための検出、学習、オンボードに使用する開発者ポータル

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

セルフホステッド ゲートウェイのない API トラフィック フロー

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

セルフホステッド ゲートウェイを使用した 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 ✔️ ❌
beta 1 セルフホステッド ゲートウェイのプレビュー バージョンを評価する場合は、このタグを使用します。 beta ✔️ ❌

使用可能なタグの完全な一覧については、こちらをご覧ください。

1プレビュー バージョンは正式にはサポートされておらず、試験的な使用のみを目的としています。 セルフホステッド ゲートウェイのサポート ポリシーに関するページを参照してください。

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

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

注

コマンドスニペットと 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 への接続を使用します。

  • ハートビート メッセージを毎分送信して、その状態を報告します。
  • 構成の更新プログラムが使用可能な場合は、定期的に (10 秒ごとに) 確認し、適用します。
  • メトリックを Azure Monitor に送信する (構成されている場合)。
  • Application Insights にイベントを送信する (構成されている場合)。

FQDN の依存関係

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

エンドポイント 必須ですか？ 注意
構成エンドポイントのホスト名 <api-management-service-name>.configuration.azure-api.net 1 カスタム ホスト名もサポートされており、既定のホスト名の代わりに使用できます。
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 最低限必要なエンドポイントは、 rt.services.visualstudio.com:443、 dc.services.visualstudio.com:443、および {region}.livediagnostics.monitor.azure.com:443です。 詳細については、Azure Monitor のドキュメントを参照してください。
Event Hubs 統合のエンドポイント オプション5 詳細については、Azure Event Hubs のドキュメントをご覧ください。
外部キャッシュ統合のエンドポイント オプション5 この要件は、使用されている外部キャッシュによって異なります。

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

重要

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

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

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

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

認証オプション

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

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

アプリごとに個別にアクセスを管理します。

組織のポリシーに従ってシークレットの有効期限を長く構成します。

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

(たとえば、アクセスを取り消すために) 個別にローテーションできるゲートウェイ キーによってサポートされます。

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

ヒント

ゲートウェイ アクセス トークンの有効期限が近づいているか期限切れになったときにセルフホステッド ゲートウェイによって生成される Event Grid イベントについては、 Event Grid ソースとしての Azure API Management を参照してください。 これらのイベントを使用して、デプロイされたゲートウェイが、関連付けられている API Management インスタンスで常に認証できることを確認します。

接続エラー

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

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

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

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

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

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

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

セキュリティ

制限事項

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

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

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

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

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

カスタム ドメインを使用する場合は、 コントロール プレーンで TLS v1.0 または v1.1 を有効にすることができます。

使用可能な暗号スイート

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

  • 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 接続に使用する暗号のコンマ区切りの一覧を定義できます。

関連コンテンツ

  • Last updated on