Azure上でのTrueFoundryのアーキテクチャ：コントロールプレーンとコンピューティングの統合

生成AIプラットフォームを Microsoft Azure 上に構築するということは、個別のコンピューティング、ID、AIのプリミティブを組み合わせることを意味します。Azure Kubernetes Service (AKS) とスポットVMを介して生のキャパシティをプロビジョニングし、Entra IDを介してIDを処理し、Azure OpenAIにリクエストをルーティングします。新しいモデルをデプロイするたびに、インフラチームがこれらの接続を手動でオーケストレーションしなければならない場合、摩擦が生じます。

TrueFoundryは、お客様のAzureサブスクリプション内にインフラストラクチャオーバーレイとしてデプロイされます。デプロイライフサイクル、IDフェデレーション、オートスケーリングを当社が担当します。この記事では、TrueFoundryとAzureを接続するために使用する正確な統合パターンを、スプリットプレーンデプロイメント、ネットワーク境界、ワークロードIDの仕組みを含めて詳しく解説します。

デプロイモデル：スプリットプレーンアーキテクチャ

ワークロードの実行をプラットフォーム管理から分離するために、スプリットプレーンアーキテクチャを使用しています。もしあなたがプラットフォームを Amazon EKS上に構築しているなら、このモデルは馴染みがあるでしょう。コントロールプレーンとデータプレーンを分離します。

• コントロールプレーン： APIサーバーおよびメタデータストアとして機能します。デプロイマニフェスト、RBAC構成、テレメトリーデータを保持します。
• コンピュートプレーン： お客様のAKSクラスター内で実行されます。TrueFoundryエージェント、ローカルコントローラー、および実際のモデルウェイトとGPUで構成されます。

2つのプレーンは、セキュアなアウトバウンド専用の gRPC ストリームまたはWebSocketを使用して接続されます。クラスター側のエージェントがコントロールプレーンへの接続を開始し、マニフェストをプルし、ログをプッシュします。お客様のVNETネットワークセキュリティグループでインバウンドポートを開く必要はありません。お客様のVNETは、デフォルトでインターネットからの外部イングレスを拒否します。

‍

図1：スプリットプレーンアーキテクチャは、顧客VNET内でデータ処理を分離します。

ネットワークトポロジーとトラフィックフロー

ポッドレベルのIPアドレスを直接割り当てるためにAzure CNIを使用して、コンピュートプレーンのネットワークを構成します。お客様のコンピュートリソースはプライベートサブネット内に保持されます。

イングレスとイーグレス

• 受信トラフィック： アプリケーションのトラフィックはAzure Application Gatewayまたは標準の内部ロードバランサーに到達します。ゲートウェイはTLSを終端し、トラフィックを Istio Ingress Gateway AKS内で稼働しているものに転送します。
• 送信トラフィック： AKSワーカーノードは、Azure NAT Gatewayを介してアウトバウンドコールをルーティングします。この経路を使用して、Azure Container Registryからイメージをプルし、コントロールプレーンをポーリングします。

プライベートエンドポイント統合

厳格なコンプライアンス境界のため、Azure Private Linkを介してトラフィックをルーティングします。推論ポッドからAzure OpenAI、Key Vault、Blob Storageへの接続は、完全にMicrosoftのバックボーンを介してルーティングされます。

‍

図2：Azure PaaSへのイングレスとプライベート接続を詳述するネットワークトラフィックフロー。

IDフェデレーション：Entra Workload ID

ハードコードされた静的シークレットとサービスプリンシパルは、深刻なローテーションオーバーヘッドを引き起こします。Microsoft Entra Workload IDを使用して、ワークロードを動的に認証します。AWS環境を管理している場合、これはAzureにおける AWS IAM Roles for Service Accounts (IRSA)に相当します。

パイプラインをデプロイすると、以下のシーケンスを実行します。

1. サービスアカウントの作成： 私たちは Kubernetesサービスアカウントをプロビジョニングします。 ワークロードの名前空間内で。
2. フェデレーション: このサービスアカウントを、Entra ID のユーザー割り当てマネージドIDにリンクします。
3. トークン交換: ポッドはAKSから署名付きトークンを要求します OIDC発行者。Azure SDKは、このトークンをEntraアクセストークンと交換します。その際、 OpenID Connect エンドポイントを使用します。
4. リソースアクセス: ポッドはこのトークンを使用して、Blob Storageからモデルをプルしたり、Azure OpenAIにアクセスしたりします。

アプリケーションコードではDefaultAzureCredentialを使用します。これにより、影響範囲は、その特定のマネージドIDに付与されたRBAC権限に厳密に限定されます。

‍

図3：Entra Workload ID認証フロー。

コンピューティングオーケストレーション：スポットVM統合

オンデマンドVMで定常状態の推論を実行すると、ベースラインコストが高くなる傾向があります。当社はAKSノードプールと直接統合し、 Azure スポット仮想マシン （ Amazon EC2 スポットインスタンスを利用するのと同様に）オーケストレーションします。

スポット容量は以下のロジックを用いて管理しています。

• プロビジョニング： priority=Spot および eviction-policy=Delete を設定したセカンダリノードプールを構築します。
• エビクション処理： 当社のコントローラーはAzure Instance Metadata Serviceをポーリングします。エビクション通知（30秒の警告）を検知すると、ノードを隔離し、 Kubernetes Cluster Autoscaler をトリガーして、ポッドをオンデマンドのフォールバックノードへ再スケジュールします。

バッチ推論やフォールトトレラントなAPIサービスを実行しているチームにとって、この設定は、 Karpenter をAWS上で実行するのと同様に、ワークロードの柔軟性に応じてコンピューティングインスタンスのコストを最大80%削減できます。

AIゲートウェイ：モデルの統合

複数のAzureリージョンにわたる個別のAPIキーとToken-Per-Minute (TPM) 制限の管理は、運用上の負担を生み出します。TrueFoundry AIゲートウェイはこれを抽象化します。 Amazon Bedrockを介してリクエストをルーティングするのと同様に、開発者は単一の内部APIエンドポイントにアクセスします。

• スマートルーティング： Azureリージョン間でリクエストをロードバランスします。East USがリクエストをレート制限した場合、ゲートウェイはWest Europeに対して再試行します。
• フェイルオーバー： Azure PaaSの障害が発生した場合、ゲートウェイはトラフィックを、AKSコンピュートプレーン上に直接ホストされているLlama 3またはMistralインスタンスへフェイルオーバーできます。

Infrastructure as Codeとの互換性

当社は標準的なGitOpsおよびIaCプラクティスに準拠しています。お客様は、当社が保守する Terraform モジュール。

お客様のTerraformステートは、VNET、AKSクラスター、OIDC発行者、および基盤となるPostgreSQLデータベースを管理します。TrueFoundryのオーバーレイは、これらのネイティブなリソースにシンプルにマッピングされ、お客様のインフラストラクチャの監査可能性とコンプライアンスを維持します。

運用比較

概要

AzureにTrueFoundryをデプロイすることで、当社がアプリケーションのライフサイクルを管理しつつ、お客様のコンピューティングとデータ実行を分離します。お客様は、VNET、NSG、およびデータレジデンシーの境界を直接管理できます。オーケストレーションは当社が担当します。AKS、Entra ID、Azure OpenAI間の複雑な連携を抽象化することで、お客様のエンジニアリングチームはインフラストラクチャとの格闘ではなく、モデルのデプロイに集中できるようになります。

‍