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

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

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

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

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

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

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

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

セッションの種類

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

コード インタープリター

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

カスタム コンテナー

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

概念

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

セッション プール

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

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

セッション

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

セッション識別子

プール内のセッションを操作するときは、各セッションを管理するためのセッション識別子を定義する必要があります。 セッション識別子は自由形式の文字列です。つまり、アプリケーションのニーズに合わせて任意の方法で定義できます。 この識別子は、セッションの動作を決定する際の重要な要素です。

• 既存のセッションの再利用: 識別子が一致する実行中のセッションが既にある場合、このセッションは再利用されます。
• 新しいセッションの割り当て: 識別子が一致する実行中のセッションがない場合、プールから新しいセッションが自動的に割り当てられます。

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

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

セッションに要求を行うときは、URL で identifier という名前のクエリ パラメーターを使ってセッション識別子を渡します。

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

セッション識別子の保護

セッション識別子は、その値を作成して管理する際に安全なプロセスを必要とする機密情報です。 この値を保護するために、アプリケーションでは各ユーザーまたはテナントがアクセスできるのはそれ自身のセッションだけであることを確認する必要があります。

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

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

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

認証

認証は、Microsoft Entra (旧称 Azure Active Directory) トークンを使用して処理されます。 有効な Microsoft Entra トークンは、セッション プール上の Azure ContainerApps Session Executor および "共同作成者" ロールに属する ID によって生成されます。

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

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

az role assignment create \
    --role "Contributor" \
    --assignee <PRINCIPAL_ID> \
    --scope <SESSION_POOL_RESOURCE_ID>

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

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

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

dotnet add package Azure.Identity

using Azure.Identity;

var credential = new DefaultAzureCredential();
var token = credential.GetToken(new TokenRequestContext(new[] { "https://dynamicsessions.io/.default" }));
var accessToken = token.Token;

npm install @azure/identity

const { DefaultAzureCredential } = require("@azure/identity");
const { TokenCredential } = require("@azure/core-auth");

const credential = new DefaultAzureCredential();
const token = await credential.getToken("https://dynamicsessions.io/.default");
const accessToken = token.token;

pip install azure-identity

from azure.identity import DefaultAzureCredential

credential = DefaultAzureCredential()
token = credential.get_token("https://dynamicsessions.io/.default")
access_token = token.token

ライフサイクル

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

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

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

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

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

セキュリティ

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

プレビューの制限事項

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

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

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

• ログはサポートされていません。 アプリケーションは、セッション プール管理 API とその応答に対する要求をログに記録できます。

次のステップ