Amazon Web Services ブログ

Kubernetes および Amazon Elastic Inference を使用した TensorFlow モデルの最適化

この記事では、Amazon Elastic Inference を Amazon Elastic Kubernetes Service と共に使用する方法について詳しく説明します。Elastic Inference と EKS を組み合わせると、お好みのコンテナオーケストレーションシステムで低コストでスケーラブルな推論ワークロードを実行できます。

Elastic Inference は、AWS で低コストの推論ワークロードを実行するますます一般的な方法になりつつあります。低コストの GPU を搭載したアクセラレーションを Amazon EC2 および Amazon SageMaker インスタンスに追加して、深層学習推論の実行コストを最大 75% 削減できます。また、Amazon EKS も、AWS でコンテナを実行するスタートアップ企業から大企業まで、あらゆる規模の企業にとって重要性が高まっています。管理された Kubernetes 環境で推論ワークロードを実行したい場合、Elastic Inference と EKS を共に使用すると、高速ながら低コストのコンピューティングリソースでこれらのワークロードを実行することができます。

この記事の例は、Elastic Inference と EKS を併用して、ビデオフレームで物体検出を実行するためのコスト最適化されたスケーラブルなソリューションを提供する方法を示しています。具体的には、以下を行います。

  • Amazon S3 からビデオを読み取る EKS でポッドを実行する
  • ビデオフレームを前処理する
  • Elastic Inference で動作するように変更された TensorFlow Serving ポッドに物体検出用のフレームを送信する。

このコンピューティング集約型のユースケースは、Elastic Inference と EKS を使用して、スケーラブルなコンテナ化されたアーキテクチャ内で低コストで推論を加速する利点を示しています。このコードの詳細については、GitHub にある Amazon Elastic Inference と Amazon EKS を使用したスケーラブルな ML 推論ワークロードの最適化を参照してください。

Elastic Inference の概要

AWS の調査によると、推論は機械学習ワークロードの実行コストの最大 90% にも上り、トレーニングモデルよりもはるかに高い割合を占めます。ただし、通常、インスタンスを完全に利用していないため、GPU インスタンスを推論に使用することは多くの場合無駄です。

Elastic Inference は、Amazon EC2 または Amazon SageMaker CPU ベースのインスタンスに、適切な量の低コスト GPU を搭載したアクセラレーションをアタッチできるようにすることで、これを解決します。これにより、推論のために GPU コンピューティングをオーバープロビジョニングする必要がなくなるため、推論コストが最大 75% 削減されます。

AWS マネジメントコンソール、AWS CLI、AWS SDK、AWS CloudFormation、または Terraform を使用して、Elastic Inference アクセラレータで EC2 インスタンスまたは Amazon SageMaker エンドポイントを設定できます。Elastic Inference を使用してインスタンスを起動すると、VPC エンドポイントの背後にある同じアベイラビリティーゾーンにアクセラレータがプロビジョニングされます。次に、アクセラレータはネットワーク経由でインスタンスに接続します。次の 2 つの前提条件があります。

  • 最初に、アクセラレータを起動する予定のサブネット用に AWS PrivateLink VPC エンドポイントをプロビジョニングします。
  • 次に、Elastic Inference アクセラレータでのアクションを許可するポリシーをインスタンスロールに提供します。

また、VPC エンドポイントとインスタンスとの間でのトラフィックを許可するようにセキュリティグループが適切に設定されていることを確認する必要があります。詳細については、Elastic Inference を使用して Amazon EC2 を起動するための設定を参照してください。

Elastic Inference に対応した深層学習ツールとフレームワークは、適切なモデル計算を自動的に検出し、アタッチされたアクセラレータにオフロードできます。Elastic Inference は TensorFlow、Apache MXNet、ONNX モデルをサポートしており、さらに多くのフレームワークが近日中に提供される予定です。PyTorch ユーザーの場合、モデルを ONNX 形式に変換して、Elastic Inference を使用できるようにすることができます。この記事の例では、TensorFlow を使用しています。

EKS の概要

Kubernetes は、コンテナ化されたアプリケーションを大規模にデプロイおよび管理できるオープンソースソフトウェアです。Kubernetes は、管理と検出を容易にするために、コンテナを論理的なグループにグループ化し、それらを EC2 インスタンスのクラスターで起動します。EKS を使用すると、AWS で Kubernetes を使用して、コンテナ化されたアプリケーションを簡単にデプロイ、管理、スケーリングできます。

より具体的には、EKS はユーザーのために Kubernetes コントロールプレーンをプロビジョニング、管理、スケーリングします。高レベルでは、Kubernetes は 2 つの主要なコンポーネントで構成されます。コンテナを実行するワーカーノードのクラスターと、クラスターでコンテナが開始するタイミングと場所を管理し、そのステータスを監視するコントロールプレーンです。

EKS がなければ、Kubernetes コントロールプレーンとワーカーノードのクラスターの両方をユーザーが自分で実行する必要があります。コントロールプレーンを処理することで、EKS は Kubernetes を実行するための実質的な運用上の負担を取り除き、インフラストラクチャの管理ではなくアプリケーションの構築に集中できるようにします。

さらに、EKS はデフォルトで安全であり、複数のアベイラビリティーゾーンにわたって Kubernetes 管理インフラストラクチャを実行することで、単一障害点を排除します。EKS は Kubernetes に準拠しているため、パートナーや Kubernetes コミュニティの既存のツールやプラグインを利用できます。標準の Kubernetes 環境で実行されるアプリケーションは完全に互換性があり、EKS に簡単に移行できます。

Elastic Inference と EKS の統合

この記事の例では、ビデオフレームで物体検出を実行します。これらのフレームは、S3 に保存されたビデオから抽出されています。次の図は、全体的なアーキテクチャを示しています。

TensorFlow Serving および Elastic Inference をサポートする推論ノードコンテナ

TensorFlow Serving (TFS) は、TensorFlow モデルを提供するための推奨される方法です。したがって、このソリューションの最初のステップは、TFS と Elastic Inference サポートを備えた推論コンテナを構築することです。AWS は、Elastic Inference 用に変更された TFS バイナリを提供しています。バイナリのバージョンは、TFTP のいくつかの異なるバージョンと Apache MXNet で利用できます。詳細およびバイナリへのリンクについては、Amazon Elastic Inference ベーシックを参照してください。

このソリューションでは、推論 Dockerfile は変更されたTFSバイナリを S3から取得し、物体検出モデルと共にインストールします。このモデルは、COCO データセットでトレーニングされた MobileNet のバリアントであり、Tensorflow 検出モデルzoo で公開されています。完全な Dockerfile は、/Dockerfile_tf_serving ディレクトリの下の amazon-elastic-inference-eks GitHub リポジトリにあります。

標準ノードコンテナ

Elastic Inference 対応の TFS と物体検出モデルを備えた推論コンテナに加えて、アプリケーションタスクの大部分を実行し、推論コンテナから予測を取得する別の標準ノードコンテナも必要です。トップレベルの要約として、この標準ノードコンテナは以下のタスクを実行します。

  • ビデオの可用性に関するメッセージの Amazon SQS キューをポーリングします。
  • S3 から、次に利用可能なビデオを取得します。
  • ビデオを個々のフレームに変換します。
  • いくつかのフレームをまとめてバッチ処理し、バッチ処理したフレームを推論のためにモデルサーバーコンテナに送信します。
  • 返された予測を処理します。

次のコード例に示すように、簡単ではないコードの唯一の側面は、ワーカーがビデオを処理している間に EC2 インスタンスの終了保護を有効にする必要があることです。

ec2.modify_instance_attribute(
    InstanceId=instance_id,
    DisableApiTermination={ 'Value': True },
)

ジョブの処理後、同様の API 呼び出しが終了保護を無効にします。このサンプルアプリケーションでは、ジョブが長時間実行されるため、終了保護を使用します。ビデオを処理している場合、スケールインイベント中に EC2 インスタンスを終了させたくありません。

推論コードを簡単に変更し、ユースケースに合わせて最適化できるため、この記事ではそれ以上の調査に時間を費やしません。推論コードについてDockerfileを確認するには、/Dockerfile ディレクトリの下の amazon-elastic-inference-eks GitHub リポジトリを参照してください。コード自体は test.py ファイルにあります。

Kubernetes クラスターの詳細

サンプルの CloudFormation テンプレートにデプロイされた EKS クラスターには、デフォルトで 2 つの異なるノードグループが含まれています。1 つのノードグループには、現在最新世代の汎用インスタンスである M5 インスタンスが含まれ、もう 1 つのノードグループには、現在、最新世代の計算最適化インスタンスである C5 インスタンスが含まれています。C5 ノードグループのインスタンスには、それぞれ単一の Elastic Inference アクセラレータがアタッチされています。

現在、Kubernetes は Elastic Inference アクセラレータを使用してポッドをスケジュールしません。したがって、この例では Kubernetes のラベルおよびセレクタを使用して、Elastic Inference アクセラレータがアタッチされているクラスター内のリソースに推論ワークロードを分散します。

より具体的には、Elastic Inference アクセラレーターへのアクセスのスケジューリングの複雑さを最小限に抑えるために、アプリケーションおよび推論ポッドはセレクターを備えた DaemonSet としてデプロイされます。これにより、定義されたラベルを持つ各ノードがアプリケーションの 1 つのコピーを実行し、インスタンスで推論します。サンプルアプリケーションは SQS キューからジョブメタデータを取得し、それぞれを順番に処理するため、Elastic Inference アクセラレーターと相互作用する複数のプロセスについて心配する必要はありません。

さらに、デプロイされたクラスターには、SQSキューのおおよその深さに基づいて、推論グループ内のノードのイン/アウトをスケーリングする Auto Scaling グループが含まれます。自動スケーリングにより、推論ノードグループのサイズを適切に維持し、コストを可能な限り低く抑えることができます。ワークロードに応じて、コストを低く抑えるためにスポットインスタンスの使用を検討することもできます。

現在、SQS メトリクスは 5 分ごとに更新されるため、CloudWatch Events を使用して 1 分間に 1 回 AWS Lambda 関数をトリガーして、キューの深さを直接照会し、カスタム CloudWatch メトリクスを更新できます。

AWS CloudFormation による起動

この記事で説明されているリソースを作成するには、いくつかの AWS CLI コマンドを実行する必要があります。これらのリソースの実行と起動の詳細については、GitHub にある関連する Makefile を参照してください。CloudFormation テンプレートを使用してこれらのリソースを作成する手順については、GitHub リポジトリの README ファイルを参照してください。

コストの比較

最後に、GPU インスタンス全体ではなく Elastic Inference を使用することで、コストをどれだけ節約したかを確認できます。

デフォルトでは、このソリューションは、推論ノードに eia1.medium タイプのアクセラレーターがアタッチされた c5.large タイプの CPU インスタンスを使用します。これらのリソースの現在のオンデマンド料金は、1 時間あたり 0.085 USD に 1 時間あたり 0.130 USD を加えたもので、1 時間あたり合計 0.215 USD になります。現在の最小世代 GPU インスタンスの料金と比較した総コストは以下のとおりです。

  • Elastic Inference ソリューション – 0.215 USD/1 時間
  • GPU インスタンス p3.2xlarge – 3.06 USD/1 時間

要約すると、Elastic Inference ソリューションのコストは、フル GPU インスタンスを使用するコストの 10% 未満です。

はるかに低いコストにもかかわらず、これらのテストの Elastic Inference ソリューションはリアルタイム推論を実行し、1 秒あたりほぼ 30 フレームの速度でビデオを処理できます。特にコードをさらに最適化する余地があることを考えると、この結果は印象的です。Elastic Inference と GPU インスタンスのコスト比較の詳細については、TensorFlow を使用した Amazon Elastic Inference でのコストの最適化を参照してください。さらに大きなコスト削減を達成するために、CPU インスタンスにスポットインスタンスを使用すると、そうしたインスタンスではオンデマンド料金と比較して最大 90% 削減できます。

まとめ

Elastic Inference を使用すると低コストの高速推論が可能になり、EKS を使用すると AWS で Kubernetes を簡単に実行できます。この 2 つを組み合わせて、管理されたスケーラブルで可用性の高い Kubernetes クラスターで安価な高速推論ワークロードを実行するための強力でロータッチなソリューションを作成できます。

AWS では、このソリューションの多くのバリエーションが可能です。たとえば、EKS を使用する代わりに、AWS 上の別のマネージドコンテナオーケストレーションサービスである Amazon ECS を使用できます。または、自分で EC2 で Kubernetes コントロールプレーンを直接実行するか、Kubernetes なしで EC2 でコンテナを直接実行することもできます。選択はあなた次第です。AWS を使用すると、ユースケース、ツール、ワークフローの設定に最適なアーキテクチャを構築できます。

開始するには、CloudFormation コンソールに移動し、このブログ記事のソリューション例の CloudFormation テンプレートを使用してスタックを作成します。詳細については、上記の AWS CloudFormation を使用した起動セクションと、そこにリンクされている関連 GitHub リポジトリをご覧ください。

著者について

Ryan Nitz は、スタートアップソリューションアーキテクチャチームで働くソフトウェアエンジニアおよびアーキテクトです。

 

 

 

 

Brent Rabowsky は AWS のデータサイエンスに焦点を当てており、彼の専門知識を活用して AWS のお客様が独自のデータサイエンスプロジェクトを実行できるようにサポートしています。