パフォーマンス - Amazon EKS
アプリケーションのスケーリングとパフォーマンス

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

パフォーマンス

アプリケーションのスケーリングとパフォーマンス

ML アーティファクト、サービングフレームワーク、スタートアップ最適化の管理

Amazon EKS に機械学習 (ML) モデルをデプロイするには、モデルをコンテナイメージとランタイム環境に統合する方法を慎重に検討する必要があります。これにより、スケーラビリティ、再現性、効率的なリソース使用率が確保されます。このトピックでは、ML モデルアーティファクトの処理、フレームワークの提供の選択、事前キャッシュなどの手法によるコンテナの起動時間の最適化に関するさまざまなアプローチについて説明します。これらはすべて、コンテナの起動時間を短縮するように調整されています。

コンテナイメージサイズの縮小

  • 起動時にコンテナイメージのサイズを減らすことも、イメージを小さくする方法の 1 つです。コンテナイメージのビルドプロセスの各ステップで削減できます。開始するには、必要な依存関係の数が最も少ないベースイメージを選択します。イメージの構築中に、必要な必須ライブラリとアーティファクトのみを含めます。イメージを構築するときは、複数の RUN コマンドまたは COPY コマンドを組み合わせて、より多数の大きなレイヤーを作成してみてください。小さなイメージを構築するには、次の長所と短所があります。

  • メリット:

    • イメージのプルは高速で、全体的に必要なストレージが少なくなります。

    • イメージが小さいほど、攻撃ベクトルが少なくなります。

  • デメリット:

    • コンテナイメージの効率化に伴い、さまざまな環境での実行ニーズを満たすために複数のイメージを作成する必要があります。

    • コマンドを組み合わせることでサイズ節約はごくわずかになる場合があるため、さまざまなビルドアプローチをテストして、何が最良の結果をもたらすかを確認する必要があります。AI/ML フレームワークでは、ランタイム専用イメージ (例: 3.03 GB pytorch/pytorch:2.7.1-cuda11.8-cudnn9-runtime で、6.66 GB で開発) などのバリアントを選択しますが、小さいイメージとしてワークロードをベンチマークすると JIT コンパイルがスキップされ、コードパスが遅くなる可能性があります。マルチステージビルドを使用してビルドとランタイムを分離し、必要なアーティファクトのみをコピーします (たとえば、レジストリまたはローカルコンテキストの場合は COPY —from= 経由）。アセンブリステージで COPY を組み合わせることでレイヤーを最適化し、レイヤー数を減らします。ただし、キャッシュ効率の低下とビルド時間の長期化には重みを付けます。

デプロイでの ML モデルアーティファクトの処理

重要な決定は、ML モデルアーティファクト (重み、設定など) を自分で処理する方法です。この選択は、イメージサイズ、デプロイ速度、モデル更新頻度、運用オーバーヘッドに影響します。「モデル」の保存を参照する場合、モデルアーティファクト (トレーニングされたパラメータ、モデルの重みなど) を参照しているわけではありません。Amazon EKS で ML モデルアーティファクトを処理するには、3 つのアプローチがあります。各 にはトレードオフがあり、最適なものはモデルのサイズ、更新頻度、インフラストラクチャのニーズによって異なります。これらは、最も推奨されていないものから最も推奨されているものまでリストされています。

モデルをコンテナイメージにベイキング イメージ構築中にモデルファイル (.safetensors、.pth、.h5 など) をコンテナイメージ (Dockerfile など) にコピーします。モデルはイミュータブルイメージの一部です。更新頻度の低い小規模なモデルには、このアプローチを使用することをお勧めします。

  • 長所: 一貫性と再現性を確保し、ロードの遅延なしで、依存関係の管理を簡素化します。

  • 欠点: イメージサイズが大きくなり、ビルドとプッシュが遅くなるため、モデルの更新には再構築と再デプロイが必要であり、レジストリのプルスループットが原因で大規模なモデルには適していません。さらに、セットアップがより複雑なため、実験、デバッグ、テストのフィードバックループが長くなる可能性があります。また、異なるイメージ間で共同配置すると、ストレージコストが増加する可能性があります。

実行時にモデルをダウンロードする コンテナの起動時に、アプリケーションは、init コンテナまたはエントリポイントのスクリプトを介して、Mountpoint for S3 CSI ドライバー、Amazon S3 S3 など) からモデルをダウンロードします。 S3 更新が頻繁な大規模モデルでは、このアプローチから始めることをお勧めします。

  • 長所: コンテナイメージをコード/ランタイムに集中させ、再構築なしでモデルを簡単に更新できるようにし、ストレージメタデータを介したバージョニングをサポートします。また、コンテナイメージサイズを増やすことなく A/B テスト、ホットスワップ、モデルのロールバックが可能になり、すべてのコンテナイメージにパッケージ化することなく、さまざまなアプリケーション間でモデルを共有できます。さらに、ML またはアプリケーションチームのワークフローに最小限の変更を導入し、コンテナ構築を高速化して実験とテストを支援します。AWS CLI、s5cmd、Mountpoint S3 CSI ドライバーなどの S3 S3CRT-backed ツールを使用すると、ダウンロードレイテンシーが大幅に短縮され、大きなファイルのパフォーマンスが向上します。多くの場合、ネットワークやレジストリのパフォーマンスに応じて、ECR などのレジストリから大きなベイクドコンテナイメージをプルするよりも、全体的なポッドの起動時間が短縮されます。

  • 長所: 潜在的なネットワーク障害 (再試行ロジックが必要) を紹介し、認証とキャッシュが必要です。再試行、エラー処理、バックオフなどのダウンロードプロセスの処理と、ECR 機能をレプリケートする追加のストレージとクリーンアップ管理によって、運用の複雑さが増します。

永続的ボリュームによるモデルのマウント モデルを外部ストレージ (Amazon EFS、EBS、FSx for NetApp ONTAP、FSx for Lustre、FSx for OpenZFS、Mountpoint S3 CSI ドライバーによる S3S3 など) に保存し、Kubernetes PersistentVolume (PV) としてマウントします。これらは、モデルのトレーニングプロセス中に生成されたファイルとデータであり、予測や推論を行うことができます。このアプローチは、ポッドまたはクラスター間で共有モデルに使用することをお勧めします。

  • 長所: 共有アクセスのためにモデルをイメージから切り離し、再起動なしで更新を容易にし (フレームワークでサポートされている場合）、大規模なデータセットを効率的に処理します。また、クローン作成、共有、スナップショットなどの機能を介した Kubernetes 主導のプロビジョニングとアクセスコントロールが可能になり、モデルをコピーして新しいオペレーションを作成する必要がなくなります。モデルへの POSIX ベースのアクセスコントロールが可能で、コンテナイメージを再構築することなく、アプリケーションとは別にモデルバージョンを更新したり、実験やテストのためのコンテナ構築を高速化したりできます。アーティファクトをメモリに読み込む AI/ML 推論アプリケーションの場合、ノードのローカルディスクにデータを中間的に保存することなく、外部ファイルシステムから直接データをロードできるため、ロードパフォーマンスが向上します。さらに、大規模なモデルを大規模に保存するために、FSx for NetApp ONTAP、FSx for Lustre などのサービスでは、ストレージ最適化手法 (重複排除、圧縮、シンプロビジョニングなど）、スナップショットによるバージョニング、ストレージ領域を浪費することなく同じファイルの再利用をサポートできます。S3 などの他の サービスは、ネイティブバージョニングを提供します。このアプローチは、レプリケーション設定 (FSx での非同期レプリケーションや S3 および EFS でのクロスリージョンレプリケーションなど) に応じて、クラスターやリージョンにまたがる可能性もあります。

  • 短所: ネットワーク接続の場合は I/O レイテンシーを追加し、ストレージのプロビジョニングとアクセスコントロールが必要になり、ストレージがクラスター固有の場合は移植性が低下する (EBS など) 可能性があります。トレードオフには、CI/CD の変更とローダープロセスの維持に伴う運用の複雑さ、ストレージコストを削減するためのカスタム TTL/保持メカニズムの必要性、より複雑なクロスリージョンレプリケーションが含まれます。モデルアーティファクトの読み取りパフォーマンスは、コンテナイメージのダウンロード時間に対して測定する必要があります。

ML モデルの提供

Amazon EKS で機械学習 (ML) モデルをデプロイして提供するには、レイテンシー、スループット、スケーラビリティ、運用の簡素化を最適化するための適切なモデル提供アプローチを選択する必要があります。選択は、モデルタイプ (言語、ビジョンモデルなど）、ワークロードの需要 (リアルタイム推論など）、チームの専門知識によって異なります。一般的なアプローチには、プロトタイプ作成用の Python ベースのセットアップ、本番稼働用機能専用のモデルサーバー、高パフォーマンスと効率のための特殊な推論エンジンなどがあります。各方法には、セットアップの複雑さ、パフォーマンス、リソース使用率のトレードオフが含まれます。フレームワークを提供すると、依存関係が原因でコンテナイメージサイズ (複数 GBs) が増加し、起動時間に影響する可能性があることに注意してください。これを軽減するには、アーティファクト処理手法を使用したデカップリングを検討してください。オプションは、最小から最も推奨される順に一覧表示されます。

Python フレームワークを使用する (FastAPI、HuggingFace Transformers with PyTorch など） Python フレームワークを使用してカスタムアプリケーションを開発し、モデルファイル (重み、設定、トークナイザー) をコンテナ化されたノード設定に埋め込みます。

  • 長所: 簡単なプロトタイピング、追加のインフラストラクチャのない Python のみ、すべての HuggingFace モデルと互換性がある、簡単な Kubernetes デプロイ。

  • 短所: 単一のリクエスト/簡易バッチ処理、遅いトークン生成 (最適化されたカーネルなし）、メモリ非効率、スケーリング/モニタリングの欠如に制限され、起動時間が長くなります。

  • 推奨事項: カスタムロジック統合を必要とする初期プロトタイピングまたは単一ノードタスクに使用します。

専用モデル提供フレームワーク (TensorRT-LLM、TGI など) の使用 ML 推論に TensorRT-LLM や TGI などの専用サーバーを採用し、モデルのロード、ルーティング、最適化を管理します。これらの は、セーフテンソルなどの形式と、オプションのコンパイルまたはプラグインをサポートしています。

  • 長所: バッチ処理 (静的/進行中または継続的）、量子化 (INT8、FP8、GPTQ)、ハードウェア最適化 (NVIDIA、AMD、Intel、Inferentia)、マルチ GPU サポート (Tensor/Pipeline Parallelism) を提供します。TensorRT-LLM は多様なモデル (LLMs、エンコーダーデコーダー) をサポートし、TGI は HuggingFace 統合を活用します。

  • 短所: TensorRT-LLM はコンパイルが必要で NVIDIA 専用です。TGI はバッチ処理の効率が低い場合があります。どちらも設定オーバーヘッドを追加し、すべてのモデルタイプ (非トランスフォーマーなど) に合わない場合があります。

  • 推奨事項: A/B テストや互換性のあるハードウェアを使用した高スループットなどの本稼働機能を必要とする PyTorch/TensorFlow モデルに適しています。

特殊な高スループット推論エンジン (vLLM など） の使用 vLLM などの高度な推論エンジンを使用し、PagedAttention、インフライトバッチ処理、量子化 (INT8、FP8-KV、AWQ) を使用して LLM サービスを最適化し、EKS 自動スケーリングと統合できます。

  • 長所: 高スループットとメモリ効率 (40～60% の VRAM 削減）、動的リクエスト処理、トークンストリーミング、単一ノードの Tensor Parallel マルチ GPU サポート、幅広いハードウェア互換性。

  • 短所: デコーダーのみのトランスフォーマー (LLaMA など) 用に最適化され、トランスフォーマー以外のモデルでは効果が低く、互換性のあるハードウェア (NVIDIA GPUs など) とセットアップ作業が必要です。

  • 推奨事項: EKS でのハイボリュームで低レイテンシーの LLM 推論に最適な選択肢であり、スケーラビリティとパフォーマンスを最大化します。

コンテナイメージの事前キャッシュ

大きなコンテナイメージ (PyTorch などのモデルなど) は、レイテンシーに影響を与えるコールドスタートの遅延を引き起こす可能性があります。リアルタイム推論ワークロードを水平方向にスケールする場合や、ポッドの迅速な起動が重要な場合など、レイテンシーの影響を受けやすいワークロードでは、初期化の遅延を最小限に抑えるためにコンテナイメージを事前にロードすることをお勧めします。最小から最も推奨されるアプローチを次に示します。

コンテナランタイムキャッシュを使用したイメージのプリプル

  • Kubernetes リソース (DaemonSet や Deployment など) を使用して、コンテナイメージをノードにプリプルして、ノードのコンテナランタイムキャッシュに入力できます。コンテナランタイムキャッシュは、コンテナランタイムによって管理されるローカルストレージ ([containerd](https://containerd.io/) など) であり、レジストリからプルされた後にイメージが保存されます。プル前により、イメージがローカルで使用可能になり、ポッドの起動時のダウンロード遅延を回避できます。このアプローチは、EBS スナップショットが事前設定されていない場合や、イメージのプリプルが優先される場合に便利です。プリプルイメージの例については、[AWS Samples GitHub repository](https://github.com/aws-samples/aws-do-eks/tree/main/Container-Root/eks/deployment/prepull) を参照してください。[SOCI Snapshotter](https://github.com/awslabs/soci-snapshotter) (部分的なイメージプル用のコンテナプラグイン) を使用した遅延ロードなどの代替手段は、これらのメソッドを補完できますが、カスタムセットアップが必要であり、すべてのシナリオに適しているとは限りません。コンテナランタイムキャッシュの使用には、次の長所と短所があります。

  • メリット:

    • EBS スナップショットを管理する必要はありません。

    • DaemonSets では、常に最新のコンテナイメージバージョンを取得します。

    • スナップショットを再作成しなくてもイメージを更新できるため、柔軟性が向上します。

    • イメージがすでにノードにあることを確認することで、ポッドの起動時間を短縮します。

  • デメリット:

    • 大きなイメージの初回のプルには時間がかかる場合がありますが、事前に行われます。

    • 非常に大きなイメージ (10 GB 以上) の EBS スナップショットほど効率的ではない場合があります。ポッドの起動時ではありませんが、プルは依然として必要であるためです。

    • DaemonSets では、イメージはポッドが実行されるすべてのノードに事前にプルされます。たとえば、1000 ノードがポッドの 1 つのインスタンスのみを実行していた場合、1 つのノードで 1 つのインスタンスを実行するためだけに、1000 ノードすべてでスペースが消費されます。

    • ノードがスケールイン/スケールアウトするリアルタイム推論ワークロードの場合、Cluster Autoscaler などのツールによって追加された新しいノードは、プル前の DaemonSet がイメージプルを完了する前にワークロードポッドをスケジュールする場合があります。これにより、新しいノードの最初のポッドがプルをトリガーし、起動が遅れ、低レイテンシーの要件に影響を与える可能性があります。

    • Kubelet イメージガベージコレクションは、ディスク使用量が特定のしきい値を超えた場合、または設定された最大未使用期間を超えた場合に、未使用のイメージを削除することで、プル済みイメージに影響を与える可能性があります。スケールイン/アウトパターンでは、アイドル状態のノード上のイメージが削除される可能性があるため、その後のスケールアップ中に再プルし、バーストワークロードのキャッシュの信頼性を低下させる必要があります。

EBS スナップショットの使用

  • キャッシュされたコンテナイメージの Amazon Elastic Block Store (EBS) スナップショットを作成し、このスナップショットを EKS ワーカーノードに再利用できます。これにより、ノードの起動時にイメージがローカルでプリフェッチされ、ポッドの初期化時間が短縮されます。Karpenter とマネージド型ノードグループのこの EKS Terraform ブループリントを使用して、Bottlerocket データボリュームで Amazon EKS のコンテナ起動時間を短縮https://aws-ia.github.io/terraform-aws-eks-blueprints/patterns/machine-learning/ml-container-cache/するを参照してください。CI/CD パイプラインの一部として EBS スナップショットの作成を自動化して、最新のコンテナイメージバージョンでup-to-date状態に保つことをお勧めします。EBS スナップショットの使用には、以下の長所と短所があります。

  • メリット:

    • ポッドの起動時に大きなコンテナイメージをプルする必要がなくなり、起動時間が大幅に短縮されます (たとえば、10 GB を超えるイメージの場合は 10～15 分から秒）。

    • ノードの起動時にイメージがローカルで使用可能であることを確認します。

    • 大きなコンテナイメージを持つ推論ワークロードに特に有益です。

  • デメリット:

    • イメージまたはバージョンのアップグレードごとに EBS スナップショットを維持および更新する必要があります。

    • すべてのワークロードが最新のコンテナイメージバージョンを使用していることを確認するには、追加のステップが必要です。

    • スナップショットを作成および管理するための追加の運用アクティビティが含まれます。

    • 適切に管理されていない場合、不要なイメージが含まれることがありますが、これは適切なノードプール設定で軽減できます。

イメージプルパフォーマンスの最適化

AI/ML ワークロードを実行している Amazon EKS クラスターのコンテナイメージのプルパフォーマンスを最適化することを強くお勧めします。最適化されていない大きなベースイメージや非効率的なレイヤーの順序付けを使用すると、ポッドの起動時間が遅くなり、リソースの消費が増加し、推論レイテンシーが低下する可能性があります。これに対処するには、ワークロードに合わせてカスタマイズされた、最小限の依存関係で小型で軽量なベースイメージを採用します。一般的な深層学習フレームワーク (PyTorch や TensorFlow など) の実行を容易にする、構築済みのコンテナイメージである AWS Deep Learning Containers (DLCs) を検討することもできます。 PyTorch TensorFlow カスタムイメージの構築の詳細については、「深層学習コンテナのカスタマイズ」を参照してください。カスタムイメージを構築するときは、軽量のベースイメージを検討し、イメージをクリーンに保つために必要なライブラリのみを追加します。マルチステージビルドを使用してレイヤーのサイズを減らし、効率的なキャッシュのためにレイヤーの順序を最適化します。詳細については、Docker Best Practices for Building Image を参照してください。

コンテナイメージをデータボリュームに事前ロードすることで、コンテナの起動時間を短縮する

リアルタイム推論など、ポッドの起動レイテンシーが低い機械学習ワークロードでは、初期化の遅延を最小限に抑えるためにコンテナイメージを事前にロードすることをお勧めします。大きなコンテナイメージは、特に帯域幅が限られているノードでは、ポッドの起動を遅らせる可能性があります。最小限のベースイメージ、マルチステージビルド、レイジーロード手法を使用するだけでなく、Amazon EKS でイメージをプリロードするには、次のアプローチを検討してください。最小限のベースイメージ、マルチステージビルド、レイジーロード手法の使用に加えて、次のオプションを検討してください。

  • EBS スナップショットを使用してイメージをプリロードする: キャッシュされたコンテナイメージの Amazon Elastic Block Store (EBS) スナップショットを作成し、このスナップショットを EKS ワーカーノードに再利用します。これにより運用アクティビティが追加されますが、ノードの起動時にイメージがローカルでプリフェッチされるため、ポッドの初期化時間が短縮されます。Karpenter とマネージド型ノードグループのこの EKS Terraform ブループリントを使用して、Bottlerocket データボリュームで Amazon EKS のコンテナ起動時間を短縮https://aws-ia.github.io/terraform-aws-eks-blueprints/patterns/machine-learning/ml-container-cache/するを参照してください。

  • イメージをコンテナランタイムキャッシュにプルする: Kubernetes リソース (DaemonSet や Deployment など) を使用してコンテナイメージをノードにプルし、ノードのコンテナランタイムキャッシュを入力します。コンテナランタイムキャッシュは、レジストリからプルされた後にイメージが保存されるコンテナランタイム (containerd など) によって管理されるローカルストレージです。プリプルにより、イメージがローカルで使用可能になり、ポッドの起動時のダウンロード遅延を回避できます。このアプローチは、EBS スナップショットが事前設定されていない場合や、イメージのプリプルが優先される場合に便利です。このアプローチをステージング環境でテストして、レイテンシーの改善を検証します。プリプルイメージの例については、AWS Samples GitHub リポジトリを参照してください。