TrueFoundryがAWSとどのように統合されるか：コントロールプレーンのアーキテクチャ

クラウドアーキテクトやDevOpsエンジニアにとって、生成AIをスケールさせる上での主な課題は、コンピューティングリソースの可用性ではなく、それらのリソースのオーケストレーションにあることがよくあります。AWSは強力なプリミティブを提供していますが、 Amazon EKS、 スポットインスタンス、 IAMロール、そして Amazon Bedrock。しかし、これらを統合された社内開発者プラットフォームにまとめるには、複雑な設定と継続的なメンテナンスが必要となることがよくあります。

TrueFoundryは、お客様のAWSアカウント内に直接インフラストラクチャオーバーレイとして配置され、そのオーケストレーションレイヤーとして機能します。以下では、セキュリティ境界、IDフェデレーション、ネットワーキング、コンピューティングの最適化について触れながら、このプラットフォームがAWSとどのように統合されるかを詳しく解説します。

デプロイモデル：コントロールプレーン vs. コンピュートプレーン

当社は、管理と実行を分離するためにスプリットプレーンアーキテクチャを採用しています。

• コントロールプレーン： これは管理レイヤー（APIとダッシュボード）です。メタデータ、ユーザー認証（RBAC）、ジョブスケジューリングを処理します。
• コンピュートプレーン： ここで実際の作業が行われます。エージェントとコントローラーで構成されており、 お客様の Amazon EKSクラスター上で動作し、モデルの重み、顧客データ、GPU処理を扱います。

接続には、安全なアウトバウンド専用のWebSocketまたはgRPCストリームが使用されます。クラスター内で実行されているエージェントがコントロールプレーンへの接続を開始し、新しいデプロイマニフェストの取得やステータス更新（Podの健全性など）のプッシュを行います。トラフィックはアウトバウンド専用であるため、VPCセキュリティグループでインバウンドポートを開く必要がなく、VPCを完全にプライベートに保つことができます。

‍

アーキテクチャ図：スプリットプレーンセキュリティ

‍

図1：スプリットプレーンアーキテクチャにより、データレジデンシーは顧客のVPC内に維持されます。

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

TrueFoundryをAWS環境にデプロイする際、ネットワーク構成では AWS VPC CNI プラグインを利用します。コンピューティングリソースはプライベートサブネット内で動作し、推論エンドポイントがデフォルトでパブリックインターネットに公開されないようにします。

イングレスとイーグレスのパターン

• インバウンドトラフィック（推論リクエスト）： アプリケーショントラフィックは AWS Application Load Balancer (ALB)を介してVPCに入ります。ALBはAWS Load Balancer Controllerによって管理され、TLS接続を終端し、EKSクラスター内で実行されているIstio Ingress Gatewayにリクエストを転送します。
• アウトバウンドトラフィック（レジストリとAPI）： EKSワーカーノードは、 Amazon ECR からコンテナイメージをプルし、コントロールプレーンAPIと通信するためにアウトバウンドネットワークアクセスを必要とします。このトラフィックは、プライベートサブネットに関連付けられたNAT Gatewayを介してルーティングされます。

サービスメッシュ統合

TrueFoundryはデプロイします Istio マイクロサービス間の東西トラフィックを管理します。例えば、埋め込みサービスがベクトルデータベースと通信するRAGパイプラインでは、Istioがルーティングを管理し、相互TLS (mTLS) を強制します。これにより、アプリケーションレベルの変更を必要とせずに、クラスター内部のトラフィックが転送中に暗号化されることが保証されます。

図2：推論のためのイングレスと依存関係のためのイグレスを示すネットワークトラフィックの流れ。

IDフェデレーションとセキュリティ

エンタープライズAWS環境における主要なセキュリティ目標は、静的認証情報の排除です。TrueFoundryは、これを実装することで対応しています。 IAM Roles for Service Accounts (IRSA)。

認証フロー

ユーザーがファインチューニングジョブや推論サービスなどのワークロードをデプロイすると、プラットフォームは以下のワークフローを実行します。

1. サービスアカウントの作成： TrueFoundryは、ワークロードの名前空間にKubernetesサービスアカウントを作成します。
2. ロールの関連付け： サービスアカウントには、事前プロビジョニングされたAWS IAMロールのARNがアノテーションとして付与されます。
3. トークンの交換： 「 EKS OIDCプロバイダー 」は、クラスターからポッドに発行されたJSON Web Token (JWT) を検証します。
4. 認証情報の発行： ポッドは、このOIDCトークンをAWS STS (Security Token Service) と交換し、一時的でローテーションされるAWS認証情報を受け取ります。

このメカニズムにより、アプリケーションコードはハードコードされたシークレットなしで標準のAWS SDK (例: boto3) を使用することが保証されます。ポッドが侵害された場合でも、潜在的な影響はそのIAMロールに付与された特定の権限に限定され、認証情報は自動的に期限切れになります。

図3：TrueFoundryのワークロードで使用されるIRSA認証フロー

コンピューティングエンジン：EKS、Karpenter、およびスポット最適化

オンデマンドインスタンスで大規模言語モデル（LLM）を実行することは、費用面で大きな課題を提示します。TrueFoundryは、 Karpenter、オープンソースのKubernetesノードプロビジョニングシステムであるKarpenterをオーケストレーションし、コンピューティングリソースの利用率を最適化します。

スポットインスタンスのオーケストレーション

TrueFoundryは、管理するための特殊なロジックを提供します EC2スポットインスタンス：

• キャパシティプロビジョニング： デプロイがリソース（例：24GB VRAM）を要求すると、プラットフォームはKarpenterに対し、制約を満たす最も費用対効果の高いインスタンスタイプをプロビジョニングするよう指示します。これにより、AWSリージョンにおける現在の可用性に応じて、g5.2xlarge、g5.4xlarge、またはp3.2xlargeがプロビジョニングされる可能性があります。
• 中断処理： システムは、 EC2スポットインスタンス終了通知、インスタンスの回収前に2分間の警告を提供するものを監視します。
• プロアクティブな置換： AWS Node Termination Handlerを介して終了シグナルを検出すると、プラットフォームは影響を受けるノードを隔離し、接続をドレインし、Karpenterに直ちに代替をプロビジョニングするようトリガーします。

このオーケストレーションにより、本番推論ワークロード向けにスポットインスタンスを信頼性高く使用できるようになり、通常、 最大70% スポット耐性のあるワークロードの場合、オンデマンド料金と比較してコスト削減を実現します。

AIゲートウェイ：BedrockとSageMakerを統合

独自のモデルを利用する組織にとって、TrueFoundryは統一されたAPIインターフェースとして機能します。 Amazon Bedrock および Amazon SageMaker。

Bedrock連携パターン

アプリケーションコードに直接AWS SDK呼び出しを埋め込むのではなく、開発者はTrueFoundry Gatewayを介してリクエストをルーティングします。Gatewayは以下の処理を実行します。

• 認証： 内部APIキーをControl Planeレジストリに対して検証します。
• テレメトリー： 詳細なコスト配分と監査証跡のために、入力および出力トークン数をログに記録します。
• プロキシ処理： Gateway自身のIAMロールを使用してリクエストに署名し、Bedrock InvokeModelエンドポイントに転送します。

この一元化により、管理者はIAMポリシーを常に変更したり、AWS認証情報をローテーションしたりすることなく、Gatewayレベルでアクセスポリシーを管理できます。

SageMaker連携パターン

TrueFoundryは、SageMakerエンドポイントへのモデルデプロイをサポートしています。しかし、このプラットフォームは、モデルをEC2/EKSに直接デプロイする機能も提供します。この代替手段により、組織はフルマネージド推論エンドポイントに通常伴う追加費用を回避しながら、開発者にとって一貫したデプロイエクスペリエンスを維持できます。

Infrastructure as Code (IaC) 互換性

TrueFoundryは、既存のInfrastructure as Codeワークフローと統合するように設計されています。このプラットフォームは、検証済みの Terraformモジュール 必要な基盤インフラストラクチャをプロビジョニングするため：

• VPCとネットワーキング： AWSのベストプラクティスに従って、プライベートサブネット、NATゲートウェイ、セキュリティグループを設定します。
• EKSクラスター： Kubernetesコントロールプレーン、マネージドノードグループ、およびVPC CNIやEBS CSIドライバーなどの必須アドオンをプロビジョニングします。
• データベース： プロビジョニングします Amazon RDS コントロールプレーンがセルフホスト型の場合、メタデータストレージ用のインスタンス。

これにより、環境がお客様のTerraformステートファイルで定義された標準的なAWSリソースで構成され、完全に監査可能であることが保証されます。

比較：AWSネイティブ vs. AWS + TrueFoundry

以下の表は、生のAWSプリミティブを使用してプラットフォームを構築する場合と、TrueFoundryオーバーレイを使用する場合の運用上の違いをまとめたものです。

結論：アーキテクチャの整合性

TrueFoundryとAWSの統合は、インフラストラクチャの信頼性のためにハイパースケーラーを利用しつつ、アプリケーション固有の管理のために専門のコントロールプレーンを実装するというアーキテクチャパターンに合致しています。

AWSに投資している組織にとって、このモデルは既存のデータレジデンシーとセキュリティ境界を維持しながら、AI運用を最新化するメカニズムを提供します。お客様はVPCとセキュリティ境界に対する制御を維持し、TrueFoundryを利用してAIアプリケーションライフサイクルの複雑さを合理化できます。

‍