次の方法で共有

Azure Container Apps 環境のイングレスを構成する

Azure Container Apps は、独自の仮想ネットワーク (VNet) を使用して、環境のコンテキストで実行されます。 この VNet により、Azure Container Apps 環境の周囲にセキュリティで保護された境界が作成されます。

Azure Container Apps のイングレス構成によって、外部ネットワーク トラフィックがアプリケーションに到達する方法が決まります。 イングレスを構成すると、トラフィック ルーティングを制御し、アプリケーションのパフォーマンスを向上させ、高度なデプロイ戦略を実装できます。 この記事では、Azure Container Apps で使用できるイングレス構成オプションについて説明し、ワークロードに適した設定を選択するのに役立ちます。

Azure Container Apps 環境には、次の機能を担当するスケーラブルなエッジ イングレス プロキシが含まれています。

次の図は、イングレス プロキシがトラフィックを 2 つのコンテナー アプリにルーティングする環境の例を示しています。

イングレス プロキシがコンテナー アプリにトラフィックをルーティングする方法の図。

既定では、Azure Container Apps は、既定のイングレス モードでコンテナー アプリ環境を作成します。 アプリケーションを高スケール レベルで動作させる必要がある場合は、イングレス モードを Premium に設定できます。

既定のイングレス モード

既定のイングレス モードでは、Container Apps 環境に 2 つのイングレス プロキシ インスタンスがあります。 コンテナー アプリは、必要に応じて最大 10 個まで、より多くのインスタンスを作成します。 各インスタンスには、最大 1 つの vCPU コアと 2 GB のメモリが割り当てられます。

既定のイングレス モードでは、イングレス プロキシのスケーリングや、vCPU コアと割り当てられたメモリに対する課金は適用されません。

Premium イングレス モード

既定のイングレス モードは、大規模な環境でボトルネックになる可能性があります。 代替手段として、Premium イングレス モードには、イングレスがトラフィックの需要に確実に対応するための高度な機能が含まれています。

次のような機能があります。

  • ワークロード プロファイルのサポート: イングレス プロキシ インスタンスは、任意の ワークロード プロファイル で実行されます。 プロキシで使用できる vCPU コアとメモリ リソースの数を制御できます。

  • 構成可能なスケール範囲ルール: プロキシ スケール範囲ルールは構成可能であるため、アプリケーションで必要な数のインスタンスがあることを確認できます。

  • 詳細設定: イングレス プロキシ インスタンスのアイドル タイムアウトなどの詳細設定を構成できます。

既定のイングレス モードと Premium イングレス モードのどちらを使用するかを決定するには、提供された要求を考慮して、プロキシ インスタンスによって消費されるリソースを評価します。 まず、プロキシ インスタンスによって使用される vCPU コアとメモリ リソースを確認します。 ご利用の環境で、任意の期間にわたって最大イングレス プロキシ数 (既定値 10) が維持される場合は、Premium イングレス モードに切り替えることを検討してください。 詳細については、 メトリックを参照してください。 Premium イングレス モードを構成する方法については、「 Azure Container Apps で Premium イングレスを使用する」を参照してください。

ワークロード プロファイル

ワークロード プロファイルを選択して、ニーズに合わせてスケーリングするイングレス プロキシ インスタンス用の専用ノードを提供できます。 D4-D32 ワークロード プロファイルの種類をお勧めします。 各イングレス プロキシ インスタンスには、1 つの vCPU コアが割り当てられます。 詳細については、「Azure Container Apps のワークロード プロファイル」を参照してください。

ワークロード プロファイル:

  • 従量課金ワークロード プロファイルにすることはできません。
  • コンテナー アプリまたはジョブと共有することはできません。
  • イングレス プロキシに使用している間は削除しないでください。

ワークロード プロファイルでイングレス プロキシを実行すると、そのワークロード プロファイルのレートで課金されます。 詳細については、「課金」を参照してください。

ワークロード プロファイル ノードの数を構成することもできます。 ワークロード プロファイルは、ノードのスケーラブルなプールです。 各ノードには、複数のイングレス プロキシ インスタンスが含まれています。 ノードの数は、vCPU とメモリ使用率に基づいてスケーリングされます。 ノード インスタンスの最小数は 2 です。

スケーリング

イングレス プロキシは、コンテナー アプリのスケーリングとは別にスケーリングされます。

イングレス プロキシが高い vCPU またはメモリ使用率に達すると、Container Apps は、より多くのイングレス プロキシ インスタンスを作成します。 使用率が低下すると、追加のイングレス プロキシ インスタンスが削除されます。

最小および最大イングレス プロキシ インスタンスは、次のように決定されます。

  • 最小: 少なくとも 2 つのノード インスタンスがあります。

  • 最大: 最大ノード インスタンスに vCPU コアを乗算します。 たとえば、最大ノード インスタンスが 50 個、vCPU コアが 4 個の場合、最大 200 個のイングレス プロキシ インスタンスがあります。

イングレス プロキシ インスタンスは、使用可能なワークロード プロファイル ノードに分散されます。

詳細イングレス設定

Premium イングレス モードを有効にすると、次の設定を構成することもできます。

設定 説明 最小値 最大値 既定値
終了猶予期間 コンテナー アプリがシャットダウン中に取り消されるまでの要求の処理が完了するまでの時間 (秒単位)。 0 3,600 500
アイドル要求タイムアウト アイドル要求タイムアウト (分単位)。 4 30 4
要求ヘッダーの数 多数の要求ヘッダーを送信するクライアントがある場合は、この設定を増やします。 1 なし 100

これらの設定は、必要に応じて増やす必要があります。この設定を上げると、イングレス プロキシ インスタンスが長時間にわたってより多くのリソースを消費し、リソースの枯渇やサービス拒否攻撃に対して脆弱になる可能性があるためです。

イングレスを設定する

環境のイングレスは、作成後に構成できます。

  1. Azure portal で環境を参照します。

  2. [ネットワーク] を選択します。

  3. [イングレス設定] を選択します。

  4. 次のようにイングレス設定を構成します。

    設定 価値
    イングレス モード [既定] または [Premium] を選択します。
    ワークロード プロファイルのサイズ D4 から D32 までのサイズを選択します。
    最小ノード インスタンス数 最小ワークロード プロファイル ノード インスタンスを入力します。
    最大ノード インスタンス数 最大ワークロード プロファイル ノード インスタンスを入力します。
    終了猶予期間 終了猶 予期間を分単位で入力します。
    アイドル要求タイムアウト アイドル状態の要求タイムアウトを分単位で入力します。
    要求ヘッダーの数 要求ヘッダーの数を入力します。

  5. を選択してを適用します。

ルールベースのルーティング

ルールベースのルーティングでは、コンテナー アプリ環境に完全修飾ドメイン名 (FQDN) を作成します。 その後、ルールを使用して、各要求のパスに応じて、この FQDN に要求を異なるコンテナー アプリにルーティングします。 これには、次の利点があります。

  • 分離: 異なるパスを異なるコンテナー アプリにルーティングすることで、アプリケーション全体に影響を与えることなく、個々のコンポーネントをデプロイおよび更新できます。

  • スケーラビリティ: ルールベースのルーティングを使用すると、各コンテナー アプリが受信するトラフィックに基づいて個々のコンテナー アプリを個別にスケーリングできます。

  • カスタム ルーティング規則: たとえば、ユーザーをさまざまなバージョンのアプリケーションにリダイレクトしたり、A/B テストを実装したりできます。

  • セキュリティ: 各コンテナー アプリに合わせたセキュリティ対策を実装できます。 これにより、アプリケーションの攻撃対象領域を減らすことができます。

コンテナー アプリ環境でルールベースのルーティングを構成する方法については、「 ルールベースのルーティングを使用する」を参照してください。

Azure Container Apps 環境でのピアツーピア暗号化

Azure Container Apps では、環境内のピアツーピア TLS 暗号化がサポートされています。 この機能を有効にすると、Azure Container Apps 環境スコープ内で有効なプライベート証明書を使用して、環境内のすべてのネットワーク トラフィックが暗号化されます。 これらの証明書は、Azure Container Apps によって自動的に管理されます。

注

既定では、ピアツーピア暗号化は無効になっています。 アプリケーションに対してピアツーピア暗号化を有効にすると、高負荷のシナリオで応答の待機時間が長くなり、最大スループットが低下する可能性があります。

次の例は、ピアツーピア暗号化が有効になっている環境を示しています。 ピアツーピア暗号化を有効にしてトラフィックを暗号化/復号化する方法を示す図。

1 受信 TLS トラフィックは、環境のエッジにあるイングレス プロキシで終了します。

2 環境内のイングレス プロキシとの間のトラフィックは、プライベート証明書で TLS 暗号化され、受信側で復号化されます。

3 アプリ A からアプリ B の FQDN への呼び出しは、まずエッジ イングレス プロキシに送信され、TLS で暗号化されます。

4 アプリ B のアプリ名を使用してアプリ A からアプリ B に対して行われた呼び出しは、アプリ B に直接送信され、TLS で暗号化されます。 アプリと Java コンポーネント間の呼び出しは、アプリ間通信と同じ方法で処理され、TLS で暗号化されます。

Container Apps 環境内のアプリケーションは自動的に認証されます。 ただし、Container Apps ランタイムでは、組み込みのピアツーピア暗号化を使用したアプリケーション間のアクセス制御の認可はサポートされていません。

アプリが環境外のクライアントと通信している場合は、mTLS を使用した双方向認証がサポートされます。 詳細については、「クライアント証明書の構成」に関するページを参照してください。

ピアツーピア暗号化は、次のコマンドを使用して有効にすることができます。

作成時:

az containerapp env create \
    --name <ENVIRONMENT_NAME> \
    --resource-group <RESOURCE_GROUP> \
    --location <LOCATION> \
    --enable-peer-to-peer-encryption

既存のコンテナー アプリの場合:

az containerapp env update \
    --name <ENVIRONMENT_NAME> \
    --resource-group <RESOURCE_GROUP> \
    --enable-peer-to-peer-encryption

関連コンテンツ

  • Last updated on