次の方法で共有

Azure Container Apps の動的セッションの概要

  • [アーティクル]

Azure Container Apps の動的セッションを使用すると、セキュリティで保護されたサンドボックス環境にすばやくアクセスできます。これは、他のワークロードからの強力な分離を必要とするコードやアプリケーションの実行に最適です。

セッションには、次の属性があります。

  • 強力な分離: セッションは相互に、そしてホスト環境から分離されます。 各セッションは独自の Hyper-V サンドボックス内で実行され、エンタープライズ レベルのセキュリティと分離が提供されます。 必要に応じて、ネットワーク分離を有効にして、セキュリティをさらに強化できます。

  • 簡単なアクセス: セッションは REST API を介してアクセスされます。 一意の識別子によって各セッションがマークされます。 特定の識別子を持つセッションが存在しない場合は、新しいセッションが自動的に割り当てられます。

  • フル マネージド: プラットフォームがセッションのライフサイクルを完全に管理します。 セッションは、使われなくなると自動的にクリーンアップされます。

  • 高速スタートアップ: 新しいセッションはミリ秒単位で割り当てられます。 迅速なスタートアップは、準備はできていても未割り当てのセッションのプールを自動的に維持することで実現されます。

  • スケーラブル: セッションを大規模に実行できます。 数百または数千のセッションを同時に実行できます。

Note

Azure Container Apps の動的セッションは現在プレビューの段階です。

セッションの種類

Azure Container Apps では、2 種類のセッションがサポートされています。

型 説明 課金モデル
コード インタープリター フル マネージド コード インタープリター セッションごと (従量課金)
カスタム コンテナー 独自のコンテナーを使用する Container Apps 専用プラン

コード インタープリター

コード インタープリター セッションを使用すると、一般的なライブラリと共にプレインストールされているサンドボックスでコードを実行できます。 これは、アプリケーションのユーザーによって提供されるコードや、大規模言語モデル (LLM) によって生成されたコードなど、信頼されないコードを実行するのに最適です。 詳しくは、コード インタープリター セッションに関する記事をご覧ください。

カスタム コンテナー

カスタム コンテナー セッションを使用すると、セキュリティ保護されて分離されたサンドボックス内で独自のコンテナー イメージを実行できます。 これらを使用して、既定ではサポートされていない言語のカスタム コード インタープリターを実行したり、強力な分離を必要とするワークロードを実行したりできます。 詳しくは、カスタム コンテナー セッションに関する記事をご覧ください。

概念

Azure Container Apps の動的セッションの主な概念は、セッション プールとセッションです。

セッション プール

1 秒未満でセッションを割り当てるため、Azure Container Apps では、準備済みでも未割り当てのセッションのプールが維持されます。 新しいセッションに要求を送信すると、プラットフォームによってプールからセッションが割り当てられます。 セッションが割り当てられると、プラットフォームはプールを自動的に補充して、一定の数の準備済みセッションを維持します。

ユーザーは、maxConcurrentSessions プロパティを使って、同時に割り当てることができるセッションの最大数を設定するようにプールを構成できます。 最後の要求からセッションが削除されるまでの待機時間を設定するには、cooldownPeriodInSeconds プロパティを使用します。 カスタム コンテナー セッションの場合は、プール内のセッションに使用するコンテナー イメージと設定を指定することもできます。これには、readySessionInstances で指定する、プールで維持する準備済みセッションのターゲット数も含まれます。

セッション

セッションは、コードまたはアプリケーションを実行するサンドボックス環境です。 各セッションは、Hyper-V サンドボックスによって、他のセッションやホスト環境から分離されます。 必要に応じて、ネットワーク分離を有効にして、セキュリティをさらに強化できます。

HTTP 要求を送信して、セッション プール内のセッションを操作します。 各セッション プールには、一意のプール管理エンドポイントがあります。

コード インタープリター セッションの場合、LLM フレームワークとの統合を使用することもできます。

セッション識別子

セッションに HTTP 要求を送信するには、要求内でセッション識別子を指定する必要があります。 セッションに要求を行うときは、URL で identifier という名前のクエリ パラメーターを使ってセッション識別子を渡します。

  • その識別子を持つセッションが既に存在する場合、要求は既存のセッションに送信されます。
  • その識別子を持つセッションが存在しない場合、要求が送信される前に新しいセッションが自動的に割り当てられます。

セッション プールとセッションの使用状況のスクリーンショット。

識別子の形式

セッション識別子は自由形式の文字列です。つまり、アプリケーションのニーズに合わせて任意の方法で定義できます。

セッション識別子は、セッション プール内で一意である定義した文字列です。 Web アプリケーションを構築する場合は、ユーザーの ID をセッション識別子として使用できます。 チャットボットを構築している場合は、会話 ID を使用できます。

識別子は、4 文字から 128 文字の文字列である必要があり、この一覧 (|、-、&、^、%、$、#、(、)、{、}、[、]、;、<、>) の英数字と特殊文字のみを含められます。

セッション識別子の保護

セッション識別子は機密情報であり、安全に管理する必要があります。 アプリケーションでは、各ユーザーまたはテナントが自身のセッションのみにアクセスできるようにする必要があります。

セッション識別子の誤用を防ぐ具体的な戦略は、アプリの設計とアーキテクチャによって異なります。 ただし、悪意のあるユーザーが別のユーザーのセッションにアクセスできないようにするために、アプリは常にセッション識別子の作成と使用を完全に制御する必要があります。

戦略の例を以下に示します。

  • ユーザーごとに 1 つのセッション: アプリでユーザーごとに 1 つのセッションを使用する場合は、各ユーザーを安全に認証し、アプリではログインされた各ユーザーに対して一意のセッション識別子を使用する必要があります。
  • エージェントの会話ごとに 1 つのセッション: アプリで AI エージェントの会話ごとに 1 つのセッションを使用する場合は、アプリが各会話ごとにエンド ユーザーが変更できない一意のセッション識別子を使用していることを確認します。

重要

セッションへのアクセスをセキュリティで保護しないと、ユーザーのセッション内に保存されているデータの誤用または未承認のアクセスが発生する可能性があります。

認証と権限承認

プール管理 API を使用してセッションに要求を送信すると、認証は Microsoft Entra (旧称 Azure Active Directory) トークンを使用して処理されます。 Azure ContainerApps Session Executor ロールに属する ID からの Microsoft Entra トークンのみが、プール管理 API を呼び出す権限を持ちます。

ロールを ID に割り当てるには、次の Azure CLI コマンドを使用します。

az role assignment create \
    --role "Azure ContainerApps Session Executor" \
    --assignee <PRINCIPAL_ID> \
    --scope <SESSION_POOL_RESOURCE_ID>

LLM フレームワーク統合を使用している場合、フレームワークはトークンの生成と管理を自動的に処理します。 アプリケーションが、セッション プールで必要なロールの割り当てを持つマネージド ID で構成されていることを確認します。

プールの管理 API エンドポイントを直接使用している場合は、トークンを生成し、それを HTTP 要求の Authorization ヘッダーに含める必要があります。 前述のロールの割り当てに加えて、トークンには、値 https://dynamicsessions.io を持つ対象者 (aud) クレームが含まれている必要があります。

Azure CLI を使用してトークンを生成するには、次のコマンドを実行します。

az account get-access-token --resource https://dynamicsessions.io

重要

有効なトークンを使用して、プール内の任意のセッションを作成してアクセスできます。 トークンはセキュリティで保護し、信頼されていない相手と共有しないでください。 エンド ユーザーは、セッションにアクセスするために、直接でなく、アプリケーションを介する必要があります。 セッション プールに対する要求の認証に使用されるトークンへのアクセス権を持つべきではありません。

ライフサイクル

Container Apps ランタイムは、セッション プール内の各セッションのライフサイクルを自動的に管理します。

  • 保留中: 開始中のセッションは、保留中状態になります。 セッションが保留中の状態で費やす時間は、コンテナー イメージとユーザーによるセッション プールの設定の指定によって異なります。 保留中セッションは、準備済みセッションのプールに追加されません。

  • 準備完了: セッションは、開始が完了して準備ができると、プールに追加されます。 この状態のセッションは割り当てに使用できます。 カスタム コンテナー セッションの場合は、プールで維持する準備済みセッションのターゲット数を指定できます。 プールが補充されるよりも速くセッションが割り当てられている場合は、この数を増やします。

  • 割り当て済み: ユーザーが実行中でないセッションに要求を送信すると、プールは新しいセッションを提供して、割り当て済み状態にします。 同じセッション識別子を持つ後続の要求は、同じセッションにルーティングされます。

  • 削除: cooldownPeriodInSeconds 設定で定義されている時間内にセッションが要求の受信を停止すると、セッションとその Hyper-V サンドボックスは完全かつ安全に削除されます。

セキュリティ

Azure Container Apps の動的セッションは、信頼されないコードとアプリケーションをセキュリティ保護されて分離された環境で実行するために構築されています。 セッションは互いに分離されますが、ファイルや環境変数など、1 つのセッション内のものであれば何でも、セッションのユーザーはアクセスできます。 セッションのユーザーを信頼している場合にのみ、機密データを構成したり、セッションにアップロードしたり必要があります。

既定では、セッションは送信ネットワーク要求を行うことができなくなっています。 セッション プールでネットワーク状態の設定を構成することで、ネットワーク アクセスを制御できます。

さらに、[認証と承認] セクションのガイダンスに従って、承認されたユーザーのみがセッションにアクセスできることを確認し、また、[保護セッション識別子] セクションではセッション識別子がセキュリティで保護されるようにします。

プレビューの制限事項

Azure Container Apps の動的セッションは現在プレビューの段階です。 次の制限事項が適用されます。

  • 以下のリージョンでのみ使用できます。

    リージョン コード インタープリター カスタム コンテナー
    東アジア ✔ ✔
    米国東部 ✔ ✔
    ドイツ中西部 ✔ ✔
    イタリア北部 ✔ ✔
    ポーランド中部 ✔ ✔
    米国中北部 ✔ -
    北ヨーロッパ ✔ ✔
    米国西部 2 ✔ ✔

次のステップ

コード インタープリター セッション