コントロールとデータの分離：グローバルAI/MLデータレジデンシーのためのTrueFoundryの戦略

グローバルなMLデプロイメントに関して、情報セキュリティチームや法務チームとの会議に参加したことがある方なら、場の雰囲気が一変する瞬間をご存知でしょう。それは、「ちょっと待って、ドイツのお客様の推論ログは実際どこにあるの？」と誰かが尋ねたときです。

データレジデンシーはかつてデータベースの問題でした。しかし今や、トレーニング、サービング、モニタリング、特徴量ストアにまたがるMLパイプラインにより、インフラスタック全体に広がる複雑な問題となっています。GDPR、CCPA、アジア各国のデータ主権法は、単なる推奨事項ではありません。誤った対応は巨額の罰金、あるいはさらに悪いことに、稼働中のデプロイメントを停止せざるを得ない状況を招きます。

私たちはMLインフラの管理にTrueFoundryを利用していますが、率直に言って、データレジデンシーに対する彼らのアプローチは、私たちが彼らを選び続けた主な理由の一つです。データがどこに存在し、どこで管理されるかという私たちの考え方を根本的に変えました。

実際にどのように機能するのか、そしてなぜ一般的なSaaS MLOpsプラットフォームとは異なるのかを見ていきましょう。

コアコンセプト：コントロールとデータの分離

多くのマネージドMLOpsプラットフォームにおける最大の問題は、そのツールの利便性を得るために、データ（モデルアーティファクト、トレーニングスニペット、ログなど）をプラットフォーム提供者のクラウドに送信する必要がある点です。これは、規制の厳しい業界にとっては受け入れがたいことです。

TrueFoundryは異なる方法で運用されます。彼らは厳密な分離を採用しています。 コントロールプレーン （彼らのSaaS管理インターフェース）と データプレーン （お客様のクラウドアカウント）の間で。

このように考えてみてください。TrueFoundryは航空管制官です。彼らは飛行機にどこへ行き、いつ着陸するかを指示します。しかし、空港、格納庫、そして飛行機そのものはあなたが所有しています。TrueFoundryが飛行機内の貨物を実際に所有することはありません。

Kubernetesクラスター（EKS、GKE、AKS）をTrueFoundryに接続すると、実質的にエージェントをインストールすることになります。そのエージェントはTrueFoundryのコントロールプレーンに指示を求めますが、実際のデータ処理とストレージはすべて、お客様が事前に定義したネットワーク境界内で実行されます。

その関係性の概要を以下に示します。

図1：コントロールプレーンとデータプレーンの分離のワークフロー

上記の通り、「重い処理」と実際のデータI/Oは、すべてお客様のクラウド環境境界内に留まります。TrueFoundryに送られるのは、ジョブステータス、リソース使用率メトリクス、構成仕様といったメタデータのみです。

実践的な実装：ワークスペースとリージョン

EUにチームがあり、法的に顧客データが米国に触れることが許されないような現実世界のセットアップでは、これはどのように適用されるのでしょうか？

TrueFoundryは「ワークスペース」という概念を使用しています。ワークスペースとは、特定の下層コンピューティングクラスターとアーティファクトストレージ統合に紐付けられた、リソースの論理的なグループです。

データレジデンシーを強制するため、必要な地理的リージョンに個別のクラスターをセットアップします。

1. eu-central-1（フランクフルト）にEKSクラスターを立ち上げます。
2. eu-central-1にアーティファクト用のS3バケットを作成します。
3. TrueFoundryでは、「EU-Prod」ワークスペースを作成し、その特定のクラスターとバケットに紐付けます。

us-east-1についても、「US-Prod」ワークスペースを使用してこのプロセスを繰り返します。

EUのデータサイエンティストがモデルをデプロイしたい場合、「EU-Prod」ワークスペースのみへのアクセスが許可されます。トレーニングジョブをトリガーしたり、サービスをデプロイしたりすると、TrueFoundryのコントロールプレーンは、コンピューティングがフランクフルトのクラスターで行われ、結果として得られるモデルの重みはフランクフルトのS3バケットに保存されることを保証します。そのワークスペースは他のインフラストラクチャの存在を知らないため、プラットフォームは物理的にデータを他の場所に置くことはできません。

以下は、一般的なマネージドML SaaSとこのアーキテクチャにおけるデータの処理方法の比較です。

表1：データ処理モデルの比較

マルチリージョンの現実

成熟した組織では、ハブアンドスポークモデルに行き着きます。一元化されたTrueFoundryコントロールプレーンがプラットフォームエンジニアリングチームに管理の容易さのためのシングルペインオブグラスを提供しますが、実際の実行は地理的にシャーディングされます。

この分離は非常に重要です。これは、開発者が誤ってジョブを不適切に設定しようとした場合でも、インフラストラクチャの制約により、リージョン間のデータ漏洩が防止されることを意味します。

図2：ワークスペースを使用したマルチリージョン分離の図

夜も安心して眠るために

データレジデンシーはめったに刺激的な仕事ではありませんが、それは基盤となるものです。それを間違えれば、他のすべてが無意味になります。

TrueFoundryのアーキテクチャの素晴らしい点は、それ自体が「セキュアなデータバンカー」になろうとしないことです。その代わりに、AWS、Azure、GCPで既に構築したバンカーを尊重します。これにより、情報セキュリティチームと例外について常に争うことなく、データサイエンティストにモダンなHerokuのようなデプロイメントエクスペリエンスを提供できます。一度境界を定義し、TrueFoundryをそれに接続すれば、偶発的なデータ流出について心配する必要がなくなります。

‍