「AWS上でクラウドネイティブなフェデレーテッドラーニングアーキテクチャを再発明する」

「AWS上でクラウドネイティブなフェデレーテッドラーニングアーキテクチャの再構築」

機械学習（ML）、特に深層学習は、モデルの性能を向上させるために大量のデータを必要とします。顧客はしばしば異なる地域、組織、またはAWSアカウントからデータを使用してモデルをトレーニングする必要があります。プライバシーの要件、データ転送の高コスト、またはオペレーションの複雑さにより、MLのためのこのようなデータを集中管理することは困難です。

フェデレーテッドラーニング（FL）は、分散データセット上でMLモデルをトレーニングする分散型MLアプローチです。FLの目標は、データの量を増やし、同時に分散データセットのプライバシーとローカリティを保護しながら、MLモデルの精度を向上させることです。FLは、特にレアなイベントや新しいイベントに関連するデータを使用してMLモデルのトレーニングに利用できるデータ量を増やし、より一般的なMLモデルを実現します。AWS上での既存のパートナーオープンソースFLソリューションには、FedML と NVIDIA FLARE が含まれます。これらのオープンソースパッケージは、AWSで利用可能なクラウドネイティブサービスを使用せずに仮想マシンで実行されるクラウドに展開されます。

このブログでは、AWS上でクラウドネイティブなFLアーキテクチャを構築する方法について学びます。AWSのインフラストラクチャをコードとして使用することで、簡単にFLアーキテクチャを展開することができます。さらに、クラウドネイティブアーキテクチャは、セキュリティと運用の優れた証明を持つさまざまなAWSサービスを最大限に活用しており、FLの開発を簡素化しています。

まず、FLの異なるアプローチと課題について説明します。その後、AWS上でクラウドネイティブなFLアーキテクチャを構築する方法をデモンストレーションします。このアーキテクチャを構築するためのサンプルコードは、GitHub で入手できます。このサンプルコードでは、サーバーとすべてのクライアントが同じ組織（同じAWSアカウント）に所属していますが、データのローカライゼーション要件によりデータを集中管理することはできません。このサンプルコードでは、水平および同期FLをサポートし、ニューラルネットワークモデルのトレーニングを行います。FLクライアントで使用されるMLフレームワークはTensorFlowです。

• 「Amazon SageMaker JumpStartで利用可能な自動音声認識のWhisperモデル」
• 新しい – Amazon SageMaker Canvasで利用可能なノーコード生成AI機能が追加されました
• 「メタのMusicGenを使用してColabで音楽を生成する」

フェデレーテッドラーニングの概要

FLは通常、中央のFLサーバーとクライアントのグループから構成されます。クライアントは、ローカルなトレーニングを実行する計算ノードです。FLのトレーニングラウンドでは、中央サーバーはまず共通のグローバルモデルをクライアントのグループに送信します。クライアントはローカルデータでグローバルモデルをトレーニングし、その後ローカルモデルをサーバーに返します。サーバーはローカルモデルを新しいグローバルモデルに集約し、新しいトレーニングラウンドを開始します。グローバルモデルが収束するか、トレーニングラウンドの数が閾値に達するまで、トレーニングラウンドは数十回続くことがあります。したがって、FLはトレーニングデータを中央の場所に移動せずに、中央のFLサーバーとクライアントの間でMLモデルを交換します。

FLのクライアントタイプによって、主に2つのカテゴリに分けられます：クロスデバイスとクロスシロ。クロスデバイスFLは、大量のデバイス（モバイル電話やIoTデバイスなど）にローカルにすべてのトレーニングデータを保持して共通のグローバルモデルをトレーニングしますが、ネットワーク接続が限られており不安定です。そのため、クロスデバイスFLの設計では、頻繁なクライアントの参加やドロップアウトを考慮する必要があります。

クロスシロFLは、異なる組織およびジオ分散データセンターに分散されたデータセット上でグローバルモデルをトレーニングします。これらのデータセットは、データ保護法規制、データの重複と同期などのオペレーション上の課題、高コストのために組織やデータセンターリージョンから移動することが禁じられています。クロスシロFLは、クロスデバイスFLとは異なり、組織やデータセンターが信頼性のあるネットワーク接続、強力なコンピューティングリソース、およびアドレス可能なデータセットを持っていることを前提としています。

FLは、プライバシーの保護が重要であるか、データのローカライゼーションが必要な金融、医療、医学、および通信など、さまざまな産業に適用されています。FLは、複数の金融機関間で金融犯罪検出のためのグローバルモデルのトレーニングに使用されています。そのグローバルモデルは、ローカルデータセットだけを使用してトレーニングされたモデルよりも20％優れています。医療分野では、複数の病院からの電子健康記録に基づいて入院患者の死亡率を予測するためにFLが使用されています。参加病院のすべてでローカルモデルよりも優れた予測性能を持つグローバルモデルが得られます。FLはまた、脳腫瘍のセグメンテーションにも使用されています。脳腫瘍セグメンテーションのためのグローバルモデルは、分散データセットを中央の場所で収集してトレーニングしたモデルと同様の性能を発揮します。通信分野では、FLはエッジコンピューティング、無線スペクトル管理、および5Gコアネットワークに適用することができます。

FLの分類方法は他にも多くあります：

• 水平または垂直 – 分散データセット内の特徴のパーティションに応じて、FLは水平または垂直に分類されます。水平FLでは、すべての分散データセットが同じ特徴セットを持っています。垂直FLでは、データセットは異なる特徴のグループを持っており、重複する特徴に基づいてサンプルを整列させるために追加の通信パターンが必要です。
• 同期または非同期 – FLサーバーの集約戦略に応じて、FLは同期または非同期に分類されます。同期FLサーバーは、選択されたクライアントからのローカルモデルをグローバルモデルに集約します。非同期FLサーバーは、クライアントからローカルモデルを受け取った後、直ちにグローバルモデルを更新し、待ち時間を短縮し、トレーニング効率を向上させます。
• 中央集権型またはピアツーピア – 典型的なFLのトポロジーは中央集権型のハブアンドスポークです。ここでは、中央のFLサーバーが一連のクライアントを調整します。もう一つのFLのトポロジーは、中央集権型のFLサーバーを持たないピアツーピアです。ここでは、FLクライアントは近隣のクライアントから情報を集約してモデルを学習します。

FLにおける課題

一般的なFLアーキテクチャにおいて、FLサーバーとクライアントで実行されるアルゴリズムを使用して、次のような課題に対処することができます：

• データの異質性 – FLクライアントのローカルデータは、特定の地理的位置、組織、または時間ウィンドウにより異なる場合があります（つまり、データの異質性）。データの異質性は、グローバルモデルの精度に影響を与え、より多くのトレーニングイテレーションとより長いトレーニング時間を要します。データの異質性の影響を軽減するために、最適化アルゴリズム、クライアント間の部分データ共有、およびドメイン適応など、多くの解決策が提案されています。
• プライバシーの保護 – ローカルおよびグローバルモデルは、敵対的な攻撃によってプライベート情報を漏洩する可能性があります。FLのためには、多くのプライバシー保護手法が提案されています。セキュアな集約アプローチを使用することで、FLサーバーとクライアント間で交換されるローカルモデルのプライバシーを保護することができます。ローカルまたはグローバルモデルにノイズを追加することでプライバシーロスを制限するローカルおよびグローバルの差分プライバシー手法は、プライバシーとモデルの精度の間の制御可能なトレードオフを提供します。プライバシー要件に応じて、異なるプライバシー保護手法の組み合わせを使用できます。
• フェデレーテッドアナリティクス – フェデレーテッドアナリティクスは、プライバシー要件を侵害することなく、分散データセットの統計的な測定を提供します。フェデレーテッドアナリティクスは、トレーニング前の分散データセットにおけるデータ分析だけでなく、推論時のモデルモニタリングにも重要です。

これらのFLアルゴリズムの課題にもかかわらず、エンドツーエンドのFLオペレーションを提供する安全なアーキテクチャを構築することが重要です。そのようなアーキテクチャを構築するための重要な課題の一つは、展開の容易さを可能にすることです。アーキテクチャは、FLサーバーとクライアントを調整し、FLモデルの構築、トレーニング、デプロイメント、クライアント間の継続的インテグレーションおよび継続的開発（CI / CD）、トレーサビリティ、およびFLサーバーとクライアントの認証とアクセス制御を含める必要があります。これらの機能は、集中型のMLオペレーション（ML Ops）に似ていますが、関与する参加者がより多いため、実装がより困難です。アーキテクチャは、さまざまなFLトポロジと同期または非同期の集約を実装するために柔軟である必要もあります。

ソリューションの概要

私たちは、以下の図に示すようなAWS上のクラウドネイティブなFLアーキテクチャを提案します。このアーキテクチャは、中央のFLサーバーと2つのFLクライアントを含んでいます。実際には、クロスシロクライアントの場合、FLクライアントの数は数百に達することがあります。FLサーバーはAWS Cloud上にある必要があります。なぜなら、AWS Cloud上にはクラウドで提供される一連のマイクロサービスが存在するからです。FLクライアントはAWS上または顧客の場所に配置することができます。FLクライアントは、独自のローカルデータセットをホストし、トレーニングMLモデルのための独自のITおよびMLシステムを所有しています。

FLモデルのトレーニング中、FLサーバーと一組のクライアントがMLモデルを交換します。つまり、クライアントはサーバーからグローバルなMLモデルをダウンロードし、ローカルでトレーニングを実行し、ローカルモデルをサーバーにアップロードします。サーバーはローカルモデルをダウンロードし、ローカルモデルを新しいグローバルモデルに集約します。このモデルの交換手順は、単一のFLトレーニングラウンドです。グローバルモデルが所定の精度に到達するか、トレーニングラウンドの数が閾値に達するまで、FLトレーニングラウンドが繰り返されます。

図1 – FLサーバーとFLクライアント間のモデルトレーニングのためのクラウドネイティブFLアーキテクチャ。

前提条件

このソリューションを実装するには、AWSアカウントが必要です。中央のFLサーバーと2つのクライアントのサービスを起動するためです。オンプレミスのFLクライアントは、AWSコマンドラインインターフェース（AWS CLI）をインストールする必要があります。これにより、FLサーバー上のAWSサービス（Amazon Simple Queue Service（Amazon SQS）、Amazon Simple Storage Service（Amazon S3）、Amazon DynamoDBなど）にアクセスできます。

フェデレーテッドラーニングのステップ

このセクションでは、図1に示す提案されたアーキテクチャについて説明します。FLサーバーでは、AWS Step Functionsステートマシンが図2に表示されるワークフローを実行します。このステートマシンは、図1のステップ0、1、および5を実行します。ステートマシンはサーバー上のAWSサービスを初期化します（ステップ0）。

そして、FLトレーニングラウンドを繰り返します。各トレーニングラウンドでは、ステートマシンはglobal_model_readyトピックにタスクトークンとともにAmazon Simple Notification Service（Amazon SNS）通知を送信します（ステップ1）。その後、ステートマシンは一時停止して、コールバックを待ちます。SQSキューはglobal_model_readyトピックにサブスクライブしています。各SQSキューはFLクライアントに対応し、サーバーからクライアントへ送信された通知をキューイングします。

図2 – Step Functionsステートマシンのワークフロー

各クライアントは、割り当てられたSQSキューからメッセージを取得し続けます。 global_model_ready通知が受信されると、クライアントはAmazon S3からグローバルモデルをダウンロードし（ステップ2）、ローカルトレーニングを開始します（ステップ3）。ローカルトレーニングはローカルモデルを生成します。クライアントはその後、ローカルモデルをAmazon S3にアップロードし、受信したタスクトークンとともにローカルモデル情報をDynamoDBテーブルに書き込みます（ステップ4）。

Amazon S3とDynamoDBを使用してFLモデルレジストリを実装します。グローバルモデルとローカルモデルを保存するためにAmazon S3を使用します。ローカルモデル情報を保存するためにDynamoDBテーブルを使用します。ローカルモデル情報はFLアルゴリズムによって異なる場合がありますので、DynamoDBテーブルによってサポートされる柔軟なスキーマが必要です。

DynamoDBストリームを有効にしてLambda関数をトリガーするように設定することもできます。これにより、DynamoDBテーブルにレコードが書き込まれるたびに（新しいローカルモデルが受信される場合）、Lambda関数がトリガーされて必要なローカルモデルが収集されているかどうかを確認します（ステップ5）。収集されている場合、Lambda関数はローカルモデルをグローバルモデルに集約する集約関数を実行します。結果のグローバルモデルはAmazon S3に書き込まれます。関数はまた、DynamoDBテーブルから取得したタスクトークンとともにコールバックをStep Functionsステートマシンに送信します。ステートマシンは、FLトレーニングを新しいトレーニングラウンドで継続するか、あるいは条件に基づいて停止するかを決定します。

各FLクライアントは、サンプルコードを使用してFLサーバーと連携します。FLクライアントでのローカルトレーニングをカスタマイズする場合は、localTraining()関数を変更できます。ただし、返される値はFLサーバーにアップロードするためのlocal_model_nameとlocal_model_infoである必要があります。すべてのクライアントが同じMLフレームワークを使用する限り、FLクライアントでのローカルモデルのトレーニングには任意のMLフレームワークを選択できます。

# ステップ2：通知とモデルファイル名をSQSキューから受信する
client.receiveNotificationsFromServer(sqs_region, client_queue_name)
# ステップ3：グローバルモデルをダウンロードしてローカルでトレーニングする
local_model_name, local_model_info = client.localTraining(global_model_name, s3_fl_model_registry)
# ステップ4：ローカルモデルとローカルモデル情報をFLサーバーにアップロードする
client.uploadToFLServer(s3_fl_model_registry, local_model_name, dynamodb_table_model_info, local_model_info)

サーバーで集計関数を実行するためのLambda関数には、次のサンプルコードがあります。集計アルゴリズムをカスタマイズしたい場合は、fedAvg()関数と出力を変更する必要があります。

# ステップ5：Lambda関数でローカルモデルを集計する
def lambda_handler(event, context):
  # DynamoDB Streamでトリガーされたイベントからtask_nameを取得する
  task_name = event['Records'][0]['dynamodb']['Keys']['taskName']['S']
  # DynamoDBテーブルからトランザクションを取得する
  transactions = readFromFLServerTaskTable(os.environ['TASKS_TABLE_NAME'], task_name)
  # 必要なクライアントからローカルモデル情報を取得する（tokenはStep Functionsステートマシンからのコールバックトークン）
  local_model_info, round_id, token = receiveUpdatedModelsFromClients(transactions, task_name)
  # fedAvg関数でローカルモデルをグローバルモデルに集計し、グローバルモデルをS3に保存する
  global_model_name, avg_train_acc, avg_test_acc, avg_train_loss, avg_test_loss = fedAvg(local_model_info, round_id)
  # Step Functionステートマシンに送信する出力
  output = {
    'taskName': task_name,
    'roundId': str(round_id),
    'trainAcc': str(avg_train_acc),
    'testAcc': str(avg_test_acc),
    'trainLoss': str(avg_train_loss),
    'testLoss': str(avg_test_loss),
    'weightsFile': str(global_model_name)
  }
  # Step Functionsステートマシンにコールバックを送信してタスクが正常に完了したことを報告する
  step_client = boto3.client('stepfunctions')
  out_str = json.dumps(output)
  step_client.send_task_success(taskToken=token, output=out_str)

このアーキテクチャには2つの革新的なデザインがあります。まず、FLサーバーはStep FunctionsやLambdaなどのサーバーレスサービスを使用しています。そのため、FLサーバーのために実行中のコンピューティングインスタンスがなく、コンピューティングコストを最小限に抑えることができます。また、FLクライアントはそれぞれ割り当てられたSQSキューからメッセージを取得し、モデルや情報をFLサーバーのサービスにアップロードまたはダウンロードします。この設計により、FLサーバーがクライアントのリソースに直接アクセスすることを避けています。これは、FLクライアントにプライベートで柔軟なITおよびML環境（オンプレミスまたはAWSクラウド上）を提供するために重要です。

クラウドネイティブの利点

このアーキテクチャはクラウドネイティブであり、AWSのセキュリティと運用の優れたサービスを使用してエンドツーエンドのトランスペアレンシーを提供します。例えば、クロスアカウントのクライアントは、FLサーバーのリソースにアクセスするためにロールを仮定することができます。オンプレミスクライアントの場合、クライアントのAWS CLIとAWS SDK for Python (Boto3)は、FLサーバーとクライアント間の安全なネットワーク接続を自動的に提供します。AWSクラウド上のクライアントでは、データ保護のためにAWS PrivateLinkとデータの転送中および静止中のデータ暗号化を使用することができます。FLサーバーとクライアントの認証とアクセス制御にはAmazon CognitoおよびAWS Identity and Access Management（IAM）を使用することができます。トレーニングされたグローバルモデルを展開するには、Amazon SageMakerのML Ops機能を使用することができます。

クラウドネイティブアーキテクチャは、カスタマイズされたMLフレームワークやフェデレーテッドラーニングアルゴリズムおよびプロトコルとの統合も可能にします。例えば、FLクライアントではMLフレームワークを選択してローカルモデルのトレーニングを行い、サーバーでLambda関数として実行されるさまざまな集計アルゴリズムをカスタマイズすることができます。また、サーバーとクライアント間のさまざまな通信プロトコルに対応するために、Step Functionsのワークフローを変更することもできます。

クラウドネイティブアーキテクチャのもう一つの利点は、クラウド向けに提供されるIaCツールを使用してのデプロイの容易さです。AWS Cloud Development Kit（AWS CDK）やAWS CloudFormationを利用して、ワンクリックでデプロイすることができます。AWS Cloud Development Kit（AWS CDK）とAWS CloudFormationを使用して、ワンクリックデプロイが可能です。

結論

世界中で新しいプライバシー法が続々と実施されており、技術インフラストラクチャは複数の地域に急速に拡大し、ネットワークエッジにまで拡張しています。フェデレーテッドラーニングは、クラウドの顧客が分散データセットを使用して、プライバシーを保護しながら正確なMLモデルをトレーニングするのに役立ちます。フェデレーテッドラーニングは、データの移動や共有に大量の生データを必要としないため、データローカライゼーションをサポートし、コストを節約することができます。

自分のユースケースに対してクラウドネイティブなフェデレーテッドラーニングアーキテクチャを試したり構築したりすることができます。TensorFlowやPyTorchなどのさまざまなMLフレームワークをサポートするために、アーキテクチャをカスタマイズすることもできます。また、非同期フェデレーテッドラーニング、集約アルゴリズム、および差分プライバシーアルゴリズムなど、さまざまなFLアルゴリズムをサポートするようにカスタマイズすることもできます。また、Amazon SageMakerのML Ops機能を使用してFL Ops機能を備えたこのアーキテクチャを有効にすることができます。

We will continue to update VoAGI; if you have any questions or suggestions, please contact us!