連携コンピューティング(FC)サーバーは、オンデバイス パーソナライズ(ODP)によって提供される連携学習の一部です。このドキュメントの目的は、連携コンピューティング サーバー(FC サーバー)、そのコンポーネント、使用されるテクノロジーについて説明することです。このドキュメントでは、アーキテクチャの概要を説明した後、各コンポーネントについて詳しく説明します。また、コンポーネントが連携してフェデレーション ラーニング環境を提供する方法についても説明します。さらに、ワークロードのスケーリングとシャーディングに関する戦略も紹介します。
トレーニング フロー
トレーニングは、FC クライアントと FC サーバー間のデータフローで構成されます。FC クライアントは、デバイス上で ML モデルをトレーニングし、FC サーバーとやり取りするコア Android モジュールです。FC サーバーは、FC クライアントからの結果を高信頼実行環境(TEE)で安全に処理して集約します。
トレーニングは次のステップで構成されます。
- デバイスの FC クライアントが、Key Services から公開暗号鍵をダウンロードします。
- FC クライアントは FC サーバーとチェックインし、トレーニング タスクを取得します。
- FC クライアントは、トレーニング プランと、モデルの最新バージョン(バージョン N)をダウンロードします。
- FC クライアントは、ローカルデータとプランを使用してトレーニングを行います。
- FC クライアントは、ステップ 0 で取得した公開鍵を使用してこのデバイスの投稿を暗号化し、FC サーバーにアップロードします。
- FC クライアントは、トレーニングが完了したことを FC サーバーに通知します。
- FC サーバーは、十分な数のクライアントがコントリビューションを送信するまで待ちます。
- 集計ラウンドがトリガーされます。
- 暗号化された拠出金は、アグリゲータによって高信頼実行環境(TEE)に読み込まれます。
- アグリゲータは、NIST の RFC 9334 Remote ATtestation procedureS(RATS)Architecture に従って、コーディネータに対して自己認証を行います。構成証明が成功すると、Key Services は復号鍵を付与します。これらの鍵は、シャミール秘密共有スキームで複数の鍵プロバイダに分割できます。
- アグリゲータは、適切な差分プライバシー(DP)メカニズムに基づいてクロスデバイス集計、クリップ、ノイズ追加を行い、ノイズが追加された結果を出力します。
- Aggregator が Model Updater をトリガーします。
- Model Updater は、集計された貢献を読み込み、モデル バージョン N に適用してモデル バージョン N + 1 を作成します。新しいモデルがモデル ストレージに push されます。
FC サーバーは、TEE と関連するセキュリティ機能をサポートする任意のクラウドサービスにデプロイできます。Google はパブリック クラウド プロバイダと基盤となるテクノロジーを評価中ですが、現時点では、次のセクションで Confidential Space を使用した Google Cloud の実装例を紹介します。
アーキテクチャの概要
FC サーバーは、Google Cloud に次のコンポーネントをデプロイします。
コンポーネント | 説明 |
タスク管理サービス | トレーニング タスクを管理するためのウェブサービス。パートナーは、Task Management API を使用してトレーニング タスクを作成、既存のトレーニング タスクをすべて一覧表示、タスクをキャンセル、すべてのトレーニング ステータスを取得する必要があります。 |
タスク割り当てサービス | HTTPS ベースのウェブサービス。クライアント デバイスが定期的にチェックインしてトレーニング タスクを取得し、トレーニング ステータスを報告します。 |
アグリゲータ | Confidential Space で実行されるバックグラウンド サービス。ODP で作成されたワークロードを実行します。復号鍵へのアクセスをガードレールするコーディネーターに証明する必要があります。クライアント デバイスから送信されたコントリビューションを復号し、クロスデバイス集計を実行できるのは、適切に構成されたアグリゲータのみです。 |
Model Updater | Confidential Space で実行され、集計された勾配をモデルに適用するバックグラウンド サービス。 |
コンポーネントの詳細
以降のセクションでは、アーキテクチャの概要を詳しく説明します。
タスク管理サービス
Task Management Service には、Task Management Web Service と Task Scheduler Service の 2 つのサブコンポーネントが含まれます。どちらも GKE にデプロイされます。
タスク管理
これは、HTTPS リクエストを受け取り、タスク データベースからタスクを作成または取得する一連のフロントエンド ウェブサービスです。
タスク スケジューラ
タスクデータベースを継続的にスキャンするバックグラウンド サービス。新しいトレーニング ラウンドや反復処理の作成など、トレーニング フローを管理します。
タスク データベース
タスク、反復処理、割り当て情報を保存する ANSI SQL 準拠のデータベース。この実装では、基盤となるデータベース サービスとして Google Cloud Spanner が使用されます。
タスク割り当てサービス
タスク割り当てサービスは、GKE でホストされるフロントエンド ウェブサービスです。FC クライアントからのリクエストを受け取り、必要に応じてトレーニング タスクを分散します。
ここでのタスクデータベースは、タスク管理サービスのタスクデータベースと同じデータベース インスタンスです。
アグリゲータ サービス
アグリゲータとモデル アップデータ
Aggregator と Model Updater は類似しています。これらは、Confidential Space でデータを安全に処理するバックグラウンド サービスです。オフライン ジョブ間の通信は PubSub を介して行われます。
勾配、集計勾配、モデル、プラン
- クライアント デバイスからアップロードされた(暗号化された)グラデーション用のグラデーション ストレージ。
- 集約、クリップ、ノイズ追加されたグラデーション用の集約グラデーション ストレージ。
- トレーニング プラン、モデル、重み用のモデルとプランのストレージ。
コレクタ
Collector は、トレーニング ラウンド中にクライアント デバイスの送信を定期的にカウントするバックグラウンド サービスです。十分な数の送信が利用可能になったら、集計を開始するようアグリゲータに通知します。
サービスホスト
機密情報にアクセスできないサービスはすべて GKE でホストされます。
機密情報にアクセスする可能性があるすべてのサービスは、Confidential Space でホストされます。
機密データはすべて、複数の当事者が所有する鍵サービスによって管理される暗号鍵で暗号化されます。復号鍵にアクセスできるのは、正常な 機密コンピューティング対応バージョンの Confidential Space で実行され、ODP によって作成されたオープンソース コードのみです。
1 つのサービス単位のコンピューティング リソースは次のようになります。
スケーラビリティ
前述のインフラストラクチャは 1 つのサービス単位に焦点を当てています。
1 つのサービス単位は 1 つの Cloud Spanner を使用します。主な制限事項については、Spanner の割り当てと上限をご覧ください。
このアーキテクチャの各コンポーネントは個別にスケーリングできます。これは、標準のスケーリング メカニズムを使用して、Confidential Space 内または GKE クラスタ内で容量をスケーリングすることで行われます。処理能力を増やすには、次のインスタンスを追加します。
- タスク割り当てウェブサービス
- タスク管理ウェブサービス
- アグリゲータ インスタンス
- Model Updater インスタンス
復元力
FC サーバーの復元力は、複製されたストレージを使用した障害復旧によって処理されます。障害復旧を検討している場合は、クロスリージョン データ レプリケーションを有効にする必要があります。これにより、災害が発生した場合(天候の悪化でデータセンターが中断された場合など)、サービスは最後のトレーニング ラウンドから再開されます。
Spanner
FC サーバーのデフォルト実装では、トレーニング フローの制御に使用されるタスクのステータスを保存するデータベースとして Google Cloud Spanner を使用します。マルチリージョン構成を選択する前に、ビジネスニーズに応じて整合性と可用性のトレードオフを評価する必要があります。
どの Spanner インスタンスにも、ユーザーデータやその派生物(未加工または暗号化されたもの)は保存されません。Spanner で提供されている障害復旧機能のいずれかを使用できます。
Spanner は変更履歴を記録します。Aggregator と Model Updater は、トレーニング ラウンドごとにデータを保存します。各ラウンドの結果は、互いに上書きされることなく個別に保存されます。このため、障害が発生した場合、サービスは最後のトレーニング ラウンドから再開できます。
Google Cloud Storage
FC サーバーのデフォルト実装では、Google Cloud Storage を使用して、モデル、トレーニング プラン、暗号化されたデバイスの貢献などの BLOB データを保存します。
この設計には 3 つの GCS インスタンスがあります。
- デバイスからの投稿: デバイスからアップロードされた暗号化されたデバイス投稿。
- モデル: トレーニング プラン、モデル、重み。
- 集約勾配: アグリゲータによって生成された集約勾配。
GCS に保存されるデータは次のいずれかです。
- デベロッパー提供のデータ(トレーニング プランなど)
- デバイスにアップロードされた勾配や集計された勾配などのユーザー シグナル(複数のコーディネーターがサポートする暗号化で保護されている)から派生するため、機密データである可能性がある
- 差分プライバシーの適用後にユーザー シグナルから得られた非機密データ(モデル重みなど)。
整合性と可用性のトレードオフを評価し、適切な GCS データの可用性と耐久性機能を選択する必要があります。独自のデータ保持ポリシーを指定する必要があります。
レプリケーションとバックアップ
Google Cloud が提供するデータ レプリケーション メカニズム以外に、Spanner と GCS でデータを定期的にバックアップすることもできます。たとえば、クロスクラウド レプリケーション サービスやサービスを使用すると、これらの構成はビジネスニーズに大きく依存するため、ODP にはサンプルが用意されていません。現在の設計では、このようなレプリケーションとバックアップに対するデベロッパーの潜在的なニーズが考慮されています。そのため、サードパーティが提供するレプリケーション サービスやバックアップ サービス、プロダクトと互換性があります。