アプリケーションのスケーリングとパフォーマンス - Amazon EKS
ML アーティファクト、サービングフレームワーク、スタートアップ最適化の管理コンテナイメージの事前キャッシュkubelet および containerd ストレージに NVMe を使用する

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

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

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

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

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

起動時にコンテナイメージのサイズを減らすことも、イメージを小さくする方法の 1 つです。コンテナイメージのビルドプロセスの各ステップで削減できます。開始するには、必要な依存関係の数が最も少ないベースイメージを選択します。イメージの構築中に、必要な必須ライブラリとアーティファクトのみを含めます。イメージを構築するときは、複数の RUNまたは COPY コマンドを組み合わせて、より多数の大きなレイヤーを作成してみてください。AI/ML フレームワークの場合、マルチステージビルドを使用してビルドとランタイムを分離し、必要なアーティファクトのみをコピーし (レジストリやローカルコンテキストCOPY —from=の場合は を介して）、ランタイム専用イメージなどのバリアントを選択します (例: 3.03 GBpytorch/pytorch:2.7.1-cuda11.8-cudnn9-runtime、6.66 GB で開発）。詳細については、「AI on EKS ワークショップ」の「コンテナイメージサイズの縮小」を参照してください。

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

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

  • モデルをコンテナイメージにベイキングする: イメージ構築中にモデルファイル (.safetensors、.pth、.h5 など) をコンテナイメージ (Dockerfile など) にコピーします。モデルはイミュータブルイメージの一部です。更新頻度の低い小規模なモデルには、このアプローチを使用することをお勧めします。これにより、一貫性と再現性が確保され、ロードの遅延がなく、依存関係管理が簡素化されますが、イメージサイズが大きくなり、ビルドとプッシュが遅くなり、モデルの更新に再構築と再デプロイが必要になり、レジストリのプルスループットのために大規模なモデルには適していません。

  • 実行時にモデルをダウンロードする: アプリケーションは、init コンテナまたはエントリポイントのスクリプトを介して、外部ストレージ (S3 CSI ドライバー用の Mountpoint、Amazon S3 S3 など) からモデルをダウンロードします。 S3 S3 更新が頻繁な大規模モデルでは、このアプローチから始めることをお勧めします。これにより、コンテナイメージがコード/ランタイムに集中し、再構築なしでモデルを簡単に更新でき、ストレージメタデータを介したバージョニングがサポートされますが、潜在的なネットワーク障害 (再試行ロジックが必要) が発生し、認証とキャッシュが必要になります。

詳細については、「AI on EKS Workshop」の「Accelerating pull process」を参照してください。

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

SOCI スナップショットターを使用してイメージをプリプルする

簡単に最小化できない非常に大きなイメージでは、並列プルおよびアンパックモードで設定されたオープンソースの Seekable OCI (SOCI) スナップショットターを使用できます。このソリューションでは、ビルドパイプラインを再構築または変更することなく、既存のイメージを使用できます。このオプションは、非常に大きなイメージを持つワークロードを高性能 EC2 コンピューティングインスタンスにデプロイする場合に特に効果的です。スケールされた AI/ML ワークロードでよく見られるように、高スループットのネットワーキングと高性能ストレージ設定に適しています。

SOCI 並列プル/アンパックモードは、設定可能な並列化戦略を通じてend-to-endのイメージプルパフォーマンスを向上させます。イメージのプルと準備を高速化すると、新しいワークロードをデプロイし、クラスターを効率的にスケールできる速度に直接影響します。イメージプルには主に 2 つのフェーズがあります。

1. レジストリからノードへのレイヤーの取得

レイヤーフェッチの最適化のために、SOCI はレイヤーごとに複数の同時 HTTP 接続を作成し、単一接続の制限を超えてダウンロードスループットを乗算します。大きなレイヤーをチャンクに分割し、複数の接続で同時にダウンロードします。このアプローチは、利用可能なネットワーク帯域幅を飽和させ、ダウンロード時間を大幅に短縮するのに役立ちます。これは、1 つのレイヤーを数ギガバイトにできる AI/ML ワークロードに特に役立ちます。

2。これらのレイヤーを解凍して準備し、コンテナを作成する

レイヤーの解凍を最適化するために、SOCI は複数のレイヤーを同時に処理します。次のレイヤーを開始する前に、各レイヤーが完全に解凍されるのを待つ代わりに、使用可能な CPU コアを使用して複数のレイヤーを同時に解凍および抽出します。この並列処理は、従来の I/O バインド解凍フェーズを、使用可能なコアに合わせてスケールする CPU 最適化オペレーションに変換します。システムは、スループットを最大化しながらファイルシステムの一貫性を維持するために、この並列化を慎重に調整します。

SOCI 並列プルモードは、ダウンロードの同時実行と並列処理の解凍の両方を設定可能なパラメータを持つデュアルしきい値の管理システムを使用します。このきめ細かな制御により、特定のパフォーマンス要件と環境条件に合わせて SOCI の動作を微調整できます。これらのパラメータを理解することで、最適なプルパフォーマンスを得るためにランタイムを最適化できます。

リファレンス

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/

詳細については、「AI on EKS Workshop」の「Using containerd snapshotter and Preload container images into Bottlerocket data volumes with EBS Snapshots」を参照してください。

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

Kubernetes リソース (DaemonSet や Deployment など) を使用して、ノードにコンテナイメージをプリプルして、ノードのコンテナランタイムキャッシュに入力できます。コンテナランタイムキャッシュは、コンテナランタイムによって管理されるローカルストレージです (例: レジストリからプルされた後にイメージが保存される containerd。 プル前により、イメージがローカルで使用可能になり、ポッドの起動時のダウンロード遅延を回避できます。 このアプローチは、イメージが頻繁に変更される場合 (頻繁な更新など）、EBS スナップショットが事前設定されていない場合、EBS ボリュームの構築にコンテナレジストリから直接プルするよりも時間がかかる場合、またはノードがすでにクラスターにあり、複数のイメージのいずれかを使用してオンデマンドでポッドをスピンアップする必要がある場合に特に役立ちます。

すべてのバリアントをプリプルすることで、必要なイメージに関係なく、起動時間を短縮できます。例えば、10 の異なる手法を使用して構築された 100,000 個の小型モデルを必要とする超並列 ML ワークロードでは、大規模なクラスター (数千のノードなど) 全体で DaemonSet を介して 10 個のイメージをプリプルすることで、ポッドの起動時間が最小限に抑えられ、オンデマンドプルを回避することで 10 秒未満で完了できます。コンテナランタイムキャッシュアプローチを使用すると、EBS スナップショットを管理する必要がなくなり、DaemonSets で常に最新のコンテナイメージバージョンを取得できますが、ノードがスケールイン/スケールアウトするリアルタイム推論ワークロードの場合、Cluster Autoscaler などのツールによって追加された新しいノードは、プル前の DaemonSet がイメージプルを完了する前にワークロードポッドをスケジュールする場合があります。これにより、新しいノードの最初のポッドがプルをトリガーし、起動が遅れ、低レイテンシーの要件に影響を与える可能性があります。さらに、kubelet イメージガベージコレクションは、ディスク使用量が特定のしきい値を超えた場合、または設定された最大未使用期間を超えた場合に、未使用のイメージを削除することで、プル済みイメージに影響を与える可能性があります。スケールイン/アウトパターンでは、アイドル状態のノード上のイメージが削除される可能性があるため、その後のスケールアップ中に再プルし、バーストワークロードのキャッシュの信頼性を低下させる必要があります。

コンテナランタイムキャッシュにイメージをプルする例については、AWS GitHub リポジトリを参照してください。

kubelet および containerd ストレージに NVMe を使用する

エフェメラル NVMe インスタンスストレージディスクを使用してディスクパフォーマンスを向上させるcontainerdには、 kubeletと の設定を検討してください。コンテナプルプロセスでは、レジストリからコンテナイメージをダウンロードし、そのレイヤーを使用可能な形式に解凍します。解凍中に I/O オペレーションを最適化するには、コンテナホストのインスタンスタイプにより高いレベルの I/O パフォーマンスとスループットを提供するものを評価する必要があります。ローカルストレージを使用する NVMe バックドインスタンスと EBS ボリューム IOPS/スループットです。NVMe ローカルストレージを使用する EC2 インスタンスの場合、ノードの基盤となるファイルシステムを kubelet (/var/lib/kubelet）、containerd (/var/lib/containerd）、Pod ログ (/var/log/pods) に設定して、エフェメラル NVMe インスタンスストレージディスクを使用して I/O パフォーマンスとスループットを向上させることを検討してください。

ノードのエフェメラルストレージは、ノードにダウンロードされるエフェメラルストレージとコンテナイメージをリクエストするポッド間で共有できます。Bottlerocket または AL2023 EKS 最適化 AMIs で Karpenter を使用する場合、これを EC2NodeClass で設定するには、instanceStorePolicy を RAID0 に設定するか、マネージドノードグループを使用する場合は、ユーザーデータの一部として NodeConfig の localStoragePolicy を設定します。