【Microsoft Azure】エージェントによるコード実行を安全に。Azure Container Apps Dynamic Sessionsの紹介

こんにちは、MS開発部の渋谷です。

ソフトウェア開発の世界は、生成AIと大規模言語モデル（LLM）の登場に伴い大きな変化が起こっています。「AIエージェント」とよばれるものもその変化の1つだと思います。

AIエージェントが持つ3つのコアコンポーネントはモデル・インストラクション・ツールであり、一般的なチャットAIと異なり、AIエージェント自身が持つツールを使って何かしらアクションを起こせるところがAIエージェントの大きな特徴の一つです。

※AI Foundry Agent Service 公式ドキュメントより引用。

そして、数あるツールの中でも最も強力なものの一つが「コードインタプリタ」です。しかし、コードインタープリタには巨大なセキュリティとパフォーマンスの懸念が考えられ、モデルによって生成されたコード、あるいはさらにリスクの高い、エンドユーザーから提供されたコードを、一体どうすれば安全に実行可能かを検討する必要があります。

それに対する1つの解決策として、今回はAzure Container Apps Dynamic Sessionsをご紹介します。これは、安全で、短命（エフェメラル）で、スケーラブルなサンドボックス化されたコンピューティング環境を提供するサービスです。はじめに Azure Container Appsの概要をおさらいしてからDynamic Sessionsの紹介をしていきます。

Azure Container Apps概要

Dynamic Sessionsがどのような環境で動作するのかを理解するために、まずはその土台となるAzure Container Apps (ACA)について見ていきましょう。ACAは、一言で言えば「Kubernetesのパワーを、Kubernetesの苦労なしに」享受できるサービスです。Kubernetesをベースに構築されていますが、その複雑さを完全に抽象化し、開発者がインフラ管理ではなくアプリケーション開発に集中できるように設計された、フルマネージドのサーバーレスコンテナサービスです 。

• マイクロサービスへの注力: オープンソースのDapr (Distributed Application Runtime)とのネイティブな統合により、サービス間呼び出し、状態管理、Pub/Subといった複雑な分散アプリケーションのパターンを驚くほど簡単に実装できます 。これは、ACAが洗練されたマルチパートアプリケーションのために設計されていることを示しています。
• イベント駆動のスケーリング: KEDA (Kubernetes Event-driven Autoscaling)をネイティブでサポートしており、HTTPトラフィック、キューの長さ、CPU負荷など、多種多様なトリガーに基づいてアプリケーションを動的にスケールさせることができます。コスト効率を最大化するゼロへのスケールダウンも可能です 。
• マネージド環境: ACAは「環境」と呼ばれる安全な境界を提供します。この環境内では、複数のコンテナアプリがネットワークやロギングを共有し、管理とセキュリティが簡素化されます 。

Dynamic Sessionsについて

次にDynamic Sessionsについてみていきます。公式には「安全なサンドボックス環境への高速アクセス」を提供するものと定義されており、その特徴は以下の通りです。

• 強力な分離 (Strong Isolation): 各セッションは、他のセッションやホスト環境から完全に分離されます。
• シンプルなアクセス (Simple Access): REST APIを通じて簡単にアクセスできます。
• フルマネージド (Fully Managed): ライフサイクルはプラットフォームが自動で管理します。
• 高速な起動 (Fast Startup): 新しいセッションはミリ秒単位で割り当てられます。
• 高いスケーラビリティ (Scalable): 何百、何千ものセッションを同時に実行できます 。

次にDynamic Sessionsを支える要素についてみていきましょう。

Hyper-Vサンドボックス

Dynamic Sessionsのセキュリティの根幹をなすのが、Hyper-Vによるサンドボックス化です。各セッションは、それぞれが独立したHyper-Vサンドボックス内で実行されます。これは、コンテナレベルの分離よりもはるかに強力な、ハードウェアレベルの分離を提供します。これにより、あるセッションで実行されたコードが、ホストOSや他のセッションに影響を与えることは原理的に不可能となり、エンタープライズグレードのセキュリティが保証されます。

セッションプール

強力な分離には、通常「起動が遅い」というトレードオフが伴います。Dynamic Sessionsは、この「コールドスタート」問題を「セッションプール」という仕組みで解決します。プラットフォームは、あらかじめ起動された（pre-warmed）「準備完了だが未割り当て」のセッションのプールを常に維持しています。新しいセッションへのリクエストが来ると、待つことなくプールから一つがミリ秒単位で割り当てられます。そして、その裏ではすぐに新しいセッションが準備され、プールが補充されるような動きをとります。

 

従来、信頼できないコードを実行するには、専用VMのセットアップ、複雑なコンテナの堅牢化、リソース管理など、多大なエンジニアリングコストが必要でした。Dynamic Sessionsは、この問題を抽象化し、実績のある仮想化技術であるHyper-V が強固なセキュリティ境界を提供し、セッションプール がその主な欠点である起動遅延を克服します。結果として、どんな開発者でも、簡単なAPIコール一つで、VMのセキュリティと軽量コンテナの起動速度を両立した、高性能なセキュアサンドボックスにアクセスできるようになりました。

サンドボックスの選択

Dynamic Sessionsには、ユースケースに応じて選択できる2つの環境があります。

• コードインタプリタセッション：これは、最も一般的なAIのユースケース向けに用意された「ターンキー（すぐに使える）」ソリューションです。NumPyやpandasなど、データサイエンスでよく使われる人気のPythonライブラリがプリインストールされた、フルマネージドの実行環境です 。LLMが生成したPythonコードを実行するのに最適で、課金モデルはセッションごとの従量課金制（Consumption-based）のため、突発的なワークロードに対してコスト効率よく利用できます 。（Nodeの環境もプレビューで提供中）
• カスタムコンテナセッション：こちらは「Bring-Your-Own-Container（自前のコンテナを持ち込む）」オプションです。開発者が用意した任意のLinuxベースのコンテナイメージを、コードインタプリタセッションと同じ、安全で分離されたサンドボックス内で実行できます 。これにより、Pythonインタプリタのモデルには収まらないが強力なテナント分離が必要なアプリケーションワークロードを実行したりすることが可能になります 。このオプションを利用するには、Container Appsの専用プラン（Dedicated Plan）が必要です 。

実際に作成する方法

通常、Container Apps関連のリソースは「コンテナー アプリ」メニューから作成しますが、ダイナミックセッションは「Container Apps Session Pools」という別のメニューから作成します。これは、ダイナミックセッションが個々のコンテナーアプリとは独立した、再利用可能なサンドボックスインスタンスの「プール」を管理するリソースだからです。実際のAzure Portalの画面は以下の通りです。

基本的に、サブスクリプションのリソースグループ、プールの名前を決めたあと、どのコンテナ環境を準備するか、セッションに関するインフラ面の設定を行うだけでデプロイの準備は完了です。

デプロイが完了した後は、実際にPortal上のプレイグラウンドから動作確認が可能となります。実際にアプリケーション側で利用する際も、上記画像にある「セッション識別子」をリクエストに含めることで識別子ごとにセッションを張ることができます。つまり、セッション識別子が同じであれば同じコンテナへ、異なる識別子であれば異なるコンテナへ、ルーティングされるような動きになります。

まとめ