※本記事は、AWS re:Invent 2024のセッション「High-performance generative AI on Amazon EKS (KUB314)」の内容を基に作成されています。セッション動画は https://www.youtube.com/watch?v=25tRVE2xq1I でご覧いただけます。本記事では、セッションの内容を忠実に要約し、登壇者の発言を元に構成しております。

なお、本記事の内容は登壇者の見解を正確に反映するよう努めていますが、要約や解釈による誤りがある可能性もありますので、正確な情報や文脈については、オリジナルのセッション動画をご視聴いただくことをお勧めいたします。

登壇者紹介：

Mike（マイク） AWSのEKSチームに所属。本セッションでは、EKSがどのようにしてGen AIやML（機械学習）ワークロードの実行を容易にしているのかについて説明を行う。特にスケーラビリティ、コスト最適化、新機能の技術的進展について深い知見を持つ。

Rama Ponnuswami（ラマ・ポンヌスワミ） AWSにおいて、EKSのワールドワイドGoToMarketを担当。MLワークロードに対するEKSとKubernetesの適合性について、豊富な実践経験を持つ。特にオープンソースツールの統合とコスト最適化の分野で専門性を有する。

Cas Starak（キャス・スタラク） Eli Lilly and Companyのプロダクトマネージャーリーダー。研究開発とAI製品を担当。EKS上でのGen AI機能の構築について、実際の導入経験に基づく知見を持つ。医薬品業界における技術革新とAI活用の第一人者。

AWSのイベント情報は https://go.aws/3kss9CP で、より多くのAWS関連動画は http://bit.ly/2O3zS75 でご覧いただけます。また、AWS re:Inventの詳細情報は https://go.aws/reinvent でご確認ください。

本セッションの内容は2024年1月時点のものであり、サービスの仕様や機能は予告なく変更される可能性があります。最新の情報については、AWS公式ドキュメントをご参照ください。

1. イントロダクション

1.1. セッションの概要と登壇者紹介

Mike：おはようございます。KUB314へようこそ。我々はEKS上でのGen AIワークロードの実行について話し合います。先日のキーノートでは、Peter、Mattが登壇し、機械学習に関するキーノートも同時進行で行われています。Graviton4、Trainium2 UltraServersなど、新しい機械学習、生成AI機能について多くの発表がありました。

しかし、私は会場の多くの方々が「EKSで動作しない限り使えない」と考えていることを認識しています。実際、最大規模の基盤モデルの多くがKubernetes上でトレーニングされています。そこで本日は、EKSがどのようにして機械学習ワークロードの実行を容易にしているのかについて説明します。

Rama：私は、なぜEKSとKubernetesがML（機械学習）ワークロードに適しているのかについてお話しします。

Cas：私はEli Lilly and Companyのプロダクトマネージャーリーダーとして、研究開発とAI製品を担当しています。EKS上でのGen AI機能の構築に関する顧客体験を共有させていただきます。

このセッションは、特にEKSを活用してGen AIワークロードを実行したい開発者やアーキテクト、また大規模な機械学習基盤の構築を検討している方々を対象としています。本日のディスカッションを通じて、EKSがどのようにしてGen AIの課題を解決し、本番環境での実装を支援できるのかを具体的に理解していただければと思います。

1.2. Generative AIの基本概念と重要性

Mike：Generative AIの重要な特徴について説明させてください。Generative AIは、人間が作成したコンテンツと見分けがつかないほどの品質のコンテンツを生成できる技術です。これは数百億のパラメータを持つ基盤モデルによって実現されており、2024年には1兆パラメータに迫るモデルも登場すると予測しています。

Rama：その通りですね。私が特に注目しているのは、Generative AIによってML（機械学習）アプリケーションの開発時間が大幅に短縮された点です。これまでは一からモデルを構築する必要がありましたが、今では大規模な基盤モデルを出発点として、特定のタスクに対して少量のトレーニングデータでファインチューニングするだけで済むようになりました。

Mike：2023年がGenerative AIのPOC（概念実証）の年だったとすれば、2024年は本番環境への移行の年になると考えています。この移行に伴い、単なる技術実証から、収益化やコスト削減といったビジネス価値の創出へと焦点が移っています。

Rama：その通りです。本番環境への移行においては、スケールでの推論コストやレイテンシーの最適化が重要になってきます。最高性能のモデルを選ぶだけでなく、本番環境での運用コストや、ユーザーエクスペリエンスへの影響も考慮する必要があります。

Mike：また、本番環境では、セキュリティ、コンプライアンス、倫理的な制約なども考慮しなければなりません。2024年に向けて、これらの要素を総合的に考慮したプロダクション環境の構築が重要なトレンドとなっていくでしょう。

Cas：Eli Lillyでの経験からも、その認識に強く同意します。私たちも2023年にPOCを開始し、2024年には本格的な本番環境への移行を進めています。特に医療分野では、セキュリティやコンプライアンスの要件が厳格であり、これらを満たしながら効率的な運用を実現することが重要な課題となっています。

1.3. Generative AIの主要ユースケース

Mike：Generative AIの主要なユースケースは、大きく4つのカテゴリーに分類できます。まず最も皆さんに馴染み深いのが、カスタマーエクスペリエンスの向上です。昨日のAndy Jassyのキーノートでも紹介されたように、amazon.comでのショッピングをサポートする新しいAIエージェント「Rufus」は、その代表的な例といえます。

Rama：従業員の生産性向上も重要なユースケースですね。特に開発者向けのコード移行ツールは大きな成果を上げています。具体的には、Java 11からJava 17への移行支援や、Windowsのモダナイゼーションコード移行などで、開発者の作業時間を大幅に削減することに成功しています。

Mike：その通りです。また、この2日間の顧客との対話で特に興味深かったのは、多くの企業が既にGen AIを実践的に活用し始めているという点です。例えば、より迅速なトラブルシューティングのためのログ分析や、開発者の効率的なプラットフォームへのオンボーディングなど、実務的なユースケースで成果を上げています。

Cas：Eli Lillyでの経験を共有させていただくと、私たちは特にコンテンツ生成の分野で成果を上げています。画像生成や動画生成は魅力的ですが、より重要なのはビジネスオペレーションでの活用です。具体的には、研究データの分析や、臨床試験のドキュメント作成支援などで、大きな効率化を実現しています。

Mike：興味深い点は、これらのユースケースが単独で機能するのではなく、より複雑なワークフローの一部として統合されていることです。例えば、エージェント同士が対話を行ったり、本番環境でのモデル運用にガードレールが必要になったりするなど、より高度な実装が求められています。AWSは、Bedrock、Amazon Q、その他様々なツールを提供していますが、EKSはこのスタックの基盤層として、最大の柔軟性とカスタマイズ性、そして高いスケーラビリティを提供しています。大規模企業では、EKS、Bedrock、Q、その他のツールを組み合わせて使用するケースが増えていると認識しています。

2. Generative AI本番環境での課題

2.1. スケーリングと運用の課題

Rama：本番環境でGenerative AIを展開する際の課題は、主に3つの側面から考える必要があります。まず、組織内の異なるチームには異なるニーズがあり、1つのモデルですべてのニーズを満たすことは不可能です。必然的に、複数のモデルを運用し、それぞれのチームの要件に合わせてカスタマイズする必要が出てきます。

Mike：その通りですね。複数モデルの運用は、Day 2オペレーションの負担を大きく増加させます。モデルのバージョン管理、新しいモデルが登場した際のアップグレード戦略、そしてモデルに対するガードレールの実装など、考慮すべき要素が多岐にわたります。

Cas：Eli Lillyでの経験から補足させていただくと、特に製薬業界では規制要件も厳しく、モデルの出力に対する厳格な管理が必要です。そのため、各モデルに対して適切なガードレールを実装し、出力を常にモニタリングする体制が不可欠です。

Rama：さらに、モデルのカスタマイズには特定のドメインに特化した、適切にキュレーションされたデータが必要です。これは単なるデータ収集の問題ではなく、データの品質管理やバージョン管理も含めた包括的な課題となります。複数のデータソースを統合しながら、データセキュリティ要件を満たし続けることは、特に大規模な組織では大きな課題となっています。

Mike：我々が見てきた顧客事例では、本番環境でのスケールに達すると、インフラストラクチャの制御をより直接的に行いたいというニーズが強まる傾向があります。インフラストラクチャの制御を委任することで、パラメータの制御能力が低下してしまうことへの懸念が大きいのです。このような課題に対して、EKSは必要な制御能力を提供しながら、運用の効率化を実現する解決策となっています。

2.2. データセキュリティとアクセス管理

Rama：データセキュリティとアクセス管理は、特に大規模組織でのGenerative AI導入において重要な課題となっています。モデルのカスタマイズには、ドメイン固有の適切にキュレーションされたデータが必要不可欠ですが、それらのデータの管理と保護は複雑な課題を伴います。

Cas：その通りですね。Eli Lillyでの経験から言うと、製薬業界特有の機密データや患者データの取り扱いには特に慎重な対応が求められます。複数の臨床試験データや研究データを統合する際には、データの機密性を保持しながら、必要な部門やチームに適切なアクセス権を付与する必要があります。

Mike：興味深い点は、データセキュリティの要件が組織によって大きく異なることです。例えば、防衛技術スタートアップのVannevar Labsでは、国家情報機関や国防省向けに非従来型の情報を提供しているため、最高レベルの機密性と厳格なデータセキュリティ対策が求められています。

Rama：そうですね。また、データソースの統合においては、単にデータを集めるだけでなく、そのデータの品質管理やバージョン管理も重要です。特に、モデルのファインチューニングに使用するデータは、ドメイン固有の要件を満たしながら、セキュリティ基準も遵守する必要があります。

Cas：私たちの場合、データセキュリティの課題に対して、多層的なアプローチを採用しています。まず、データへのアクセスを厳密に制御し、監査可能な形でログを記録します。さらに、データの使用目的や範囲を明確に定義し、必要最小限のアクセス権限のみを付与する原則を徹底しています。この approach は、規制要件への適合性を確保しながら、効率的なデータ活用を可能にしています。

Mike：EKSでは、これらの要件に対応するため、きめ細かなアクセス制御と監査機能を提供しています。特に、マルチテナンシー環境での安全なリソース分離や、データアクセスの監視・制御機能は、顧客から高い評価を得ている点です。

2.3. インフラストラクチャの最適化

Rama：私たちが顧客との対話で特に注目しているのは、Gen AIワークロードが本番環境で重要な規模に達した際の課題です。この段階で多くの顧客は、インフラストラクチャの制御をより直接的に行う必要性を感じ始めます。インフラストラクチャの委任管理では、これらのパラメータを効果的に制御することが難しくなってきているのです。

Mike：その通りですね。我々が観察してきた傾向として、本番環境での規模が拡大するにつれて、インフラストラクチャの制御をより詳細に行いたいというニーズが高まっています。これは特に、コスト最適化やROI目標を達成する必要がある場合に顕著です。

Cas：Eli Lillyでの経験からも、それは非常に重要な点です。私たちの場合、グローバルな展開においてインフラストラクチャの制御は特に重要でした。複数の地域で異なる規制要件に対応しながら、一貫した性能とセキュリティを確保する必要がありました。

Rama：そのような状況で、多くの顧客がEKSを選択する理由は明確です。EKSを使用することで、必要なインフラストラクチャの制御を維持しながら、MLモデルやML環境をカスタマイズする柔軟性を確保できます。これにより、ROI目標を達成するためのコスト最適化も可能になります。

Mike：特筆すべきは、EKSが提供する制御レベルです。インスタンスレベルまでの詳細な制御が可能で、環境を特定のニーズに合わせて柔軟に構成できます。これは、管理サービスによる制約を受けることなく、MLワークロードを最適化できることを意味します。

Rama：また、KubernetesのネイティブなマルチテナンシーとEKSの組み合わせにより、限られたGPUリソースを組織内の複数のチーム間で安全に共有することも可能になります。これにより、GPUの利用率を向上させ、さらなるコスト最適化を実現できるのです。

2.4. コスト最適化の必要性

Rama：本番環境でのGenerative AI導入において、コスト最適化は極めて重要な課題です。特に、組織が重要な規模に達した際、ROI目標を達成するためには、インフラストラクチャのコストを効果的に管理する必要があります。

Mike：その通りですね。2024年に向けて、単なるPOCから本番環境への移行を進める中で、コストとパフォーマンスのバランスが重要になっています。必ずしも最高性能のモデルが最適な選択とは限りません。本番環境での運用コストやユーザーエクスペリエンスへの影響を総合的に考慮する必要があります。

Cas：Eli Lillyでの経験から補足させていただくと、推論コストの最適化は特に重要です。私たちの場合、グローバルな展開において、異なる地域での推論コストと性能要件のバランスを取る必要がありました。例えば、臨床試験データの分析では、高い精度が要求される一方で、コスト効率も考慮する必要があります。

Rama：その点について、具体例を共有させていただきます。例えば、防衛技術スタートアップのVannevar Labsは、RayとKarpenterを組み合わせることで、推論コストを45%削減することに成功しました。彼らは、GPU インスタンス内の未使用CPUリソースを活用してCPU重視のワークロードを実行することで、GPU利用率を大幅に向上させました。

Mike：また、Informaticaの事例も興味深いですね。彼らはEKS上でLLMオプスプラットフォームを構築し、以前使用していた管理サービスと比較して約30%のコスト削減を達成しました。これは、インフラストラクチャの詳細な制御とカスタマイズが可能になったことによる成果です。

Rama：さらに、Hugging Faceの事例も注目に値します。彼らは無料枠のある三層価格モデルを実現するため、EKS上で何百万ものモデルの推論を効率的に処理する必要がありました。複数のEKSクラスターと2000以上のノードを活用し、GPUの時分割共有により、数秒ごとにモデルを入れ替えることで、コストを最適化しています。

3. EKSによるソリューション

3.1. インフラストラクチャの柔軟性

Rama：EKSが提供するインフラストラクチャの柔軟性について、特筆すべき点があります。多くの顧客が既にKubernetesを標準的なアプリケーション開発プラットフォームとして採用しています。このような環境では、ロギング、モニタリング、災害復旧、スケールでのセキュリティなど、基盤となる機能がすでに構築されています。

Mike：その通りですね。私たちが注目しているのは、MLワークロードに関して、顧客は既存の課題を再度解決する必要がないという点です。既存のプラットフォームの基盤機能を活用しながら、ML固有の機能を追加していくことができます。

Cas：Eli Lillyでの経験からも、その利点は明確です。我々は既存のKubernetesプラットフォームを活用することで、新たなインフラストラクチャを一から構築することなく、ML機能を効率的に統合することができました。

Rama：もう一つの重要な利点は、オンプレミス、エッジ、クラウドなど、すべての環境でKubernetesを標準レイヤーとして使用できることです。先週日曜日にリリースしたEKS Hybrid Nodesは、この統合をさらに容易にします。単一のEKS管理コントロールプレーンに、クラウド、オンプレミス、エッジのノードを接続でき、Kubernetesコントロールプレーンの管理を完全にオフロードできます。

Mike：この柔軟性は、特にMLワークロードにおいて重要です。というのも、MLの分野は急速に進化しており、多くのイノベーションがオープンソース領域で発生しているからです。これらのオープンソースツールの多くは、Kubernetesとの統合を標準で提供しています。

Cas：その点について補足させていただくと、我々は環境に応じてワークロードを適切に配置し、コストとROIのバランスを最適化できています。例えば、特定のワークロードは規制要件に基づいてオンプレミスで実行し、他のワークロードはクラウドでスケールするといった柔軟な運用が可能です。

Rama：まさにそのような柔軟性が、EKSが多くの顧客に選ばれている理由の一つです。Kubernetesにインフラストラクチャのオーケストレーションを任せ、その上にMLに特化したOSSソリューションを統合することで、それぞれのツールの長所を最大限に活用できるのです。

3.2. コスト最適化機能

Rama：EKSでのコスト最適化は、実質的に3つのレイヤーで実現されています。まず、インスタンスレベルでの最適化について説明させていただきます。EKSはすべてのEC2インスタンスタイプをサポートしています。これにはNVIDIAベースのGPUインスタンス、Trainium、Inferentia、Intelベースのインスタンスなど、AWSで利用可能なすべてのEC2インスタンスが含まれます。これにより、ワークロードの要件に基づいて最適なインスタンスを柔軟に選択できます。

Mike：しかし、この柔軟性だけでは不十分です。新しいワークロードがスケジューリングされるたびに、手動でこれらの選択を行うのは非効率です。ここでKarpenterの重要性が際立ちます。

Rama：その通りです。Karpenterは、特定のインスタンスをプロビジョニングするためのパラメータを設定し、それに基づいて入力ワークロードを評価し、適切なインスタンスを選択するプロセスを自動化します。これはワークロードが新たにスケジューリングされるたびに繰り返し実行されます。

Cas：Eli Lillyでの経験から、Karpenterの価値は計り知れません。特に、EKS最適化AMIと組み合わせることで、必要な依存関係がすべて事前に組み込まれた環境を迅速にスピンアップできることが大きな利点です。

Rama：さらに、Karpenterは需要が増加した際の迅速なスケーリングと、より重要なことには、需要が減少した際の効率的なスケールダウンを実現します。また、GPUの共有メカニズムと、EKSの組み込みマルチテナンシー機能を活用することで、制約のあるGPUリソースを組織内の複数のチーム間で安全に共有し、GPU利用率をさらに向上させることができます。

Mike：実際の成功事例として、Vannevar Labsは、CPUの重いワークロードをGPUインスタンスにスケジュールすることで、GPUインスタンス内の未使用CPUを活用し、45%のコスト削減を達成しました。また、Informaticaは管理サービスと比較して30%のコスト削減を実現しています。これらはKarpenterと適切なインスタンス選択の組み合わせによる成果です。

3.3. オープンソースツールとの統合

Mike：EKSの強みの一つは、オープンソースツールとのシームレスな統合です。特に、この2日間の顧客との対話で最も頻繁に言及されたのが、RayとVLLMという二つのプロジェクトです。これらのツールは、デバイスプラグイン、EFA、NVIDIAやNeuronのアクセラレーテッドドライバーなど、EKSの基盤インフラストラクチャスタックと組み合わせて、本番環境での推論ワークロードを実行するための一般的な構成となっています。

Rama：その通りですね。オープンソースのML特化ソリューションをEKSと統合することで、Kubernetesにインフラストラクチャのオーケストレーションを任せつつ、MLに特化した機能を実現できます。例えば、VLLMとEKSを組み合わせることで、メモリとモデルの最適化、マルチモーダル管理、リクエストバッチング、クエリキューイングなど、推論インフラストラクチャに必要な多くの機能を実現できます。

Cas：Eli Lillyでの経験から補足させていただくと、このアプローチは非常に効果的です。データサイエンティストは即座にモデルをデプロイし、エンドポイントを取得して推論を実行できます。プラットフォームとしてのインフラストラクチャの複雑さを隠蔽しながら、必要な機能を提供できる点が大きな利点です。

Mike：さらに重要なのは、これがフライホイール効果を生み出していることです。新しい機械学習ツールを開発する際、開発者は幅広い採用を目指してKubernetesでの動作を最優先で確保しようとします。その結果、多くのフレームワークやツールがKubernetesとの優れた統合を提供しているのです。

Rama：また、AWSとしても特定のオープンソースプロジェクトに積極的に貢献しています。例えば、Rayプロジェクトでは、Neuronフレームワークとの連携を改善するための貢献を行っています。この相乗効果により、EKS上でのML開発効率が継続的に向上しています。

Mike：また、推論スタックとして、RayとVLLMを組み合わせた構成が一般的になってきています。Karpenterが標準的なCPUインスタンスでヘッドポッドとKube-Rayオペレータを実行し、Inferentialインスタンスで実際の推論ワークロードを実行するという構成です。この組み合わせにより、効率的なリソース利用と柔軟なスケーリングが実現できています。

3.4. スケーラビリティと性能最適化

Mike：EKSにおけるスケーラビリティと性能最適化について、最近の重要な進展を共有したいと思います。特に、EFA（Elastic Fabric Adapter）に関する2つの重要な機能強化があります。まず、EFAがクロスサブネット通信をサポートするようになりました。これまでEFAは単一のサブネットに制限されていましたが、今では同一AZ内の異なるサブネット間での通信が可能になっています。

Rama：それは興味深い進展ですね。IPアドレスの枯渇は多くの顧客が直面している課題ですが、このクロスサブネット通信のサポートにより、その問題が大幅に緩和されることが期待できます。

Mike：さらに、MLトレーニングワークロードに特化した最適化も実施しています。多くの場合、トレーニングワークロードはインターネットとの通信を必要とせず、クラスター内の他のノードとの通信のみで完結します。このため、EFAのみのENI（Elastic Network Interface）サポートを導入し、EFAデバイスに実際のIPアドレスを割り当てる必要をなくしました。

Cas：Eli Lillyでの経験からすると、これは大きな改善ですね。特に大規模なトレーニングジョブを実行する際に、IPアドレス管理の負担が大幅に軽減されることが期待できます。

Mike：そうですね。この最適化は、S3との統合も含めて考える必要があります。トレーニングジョブには大規模なストレージバックエンドが必要で、S3はその理想的な選択肢です。昨年、S3はMountPointというテクノロジーをオープンソース化し、EC2インスタンスにS3バケットをマウントして、ファイルシステムコマンドを使用できるようになりました。

Rama：これらの最適化は、特に大規模なトレーニングクラスターを運用する顧客にとって重要です。例えば、数百から数千のノードを持つクラスターでは、IPアドレス管理とネットワーク最適化が重要な課題となっていました。EFAの改善とS3 MountPointの組み合わせにより、これらの課題に効果的に対応できるようになっています。

4. 新機能と技術的進展

4.1. コントロールプレーンのスケーラビリティ改善

Mike：EKSのコントロールプレーンのスケーラビリティ改善について、我々はあまり大々的に発表していないのですが、非常に重要な進展がありました。実は、6年前のサービス開始時に作成されたEKSクラスターの中には、バージョン1.10から1.30まで継続的にアップグレードされ、現在も稼働しているものがあります。これらのクラスターは、当初とは全く異なる姿に進化しています。

Rama：それは興味深いですね。クラスターの進化について、もう少し具体的に説明していただけますか？

Mike：はい。EKSクラスターを作成すると、専用のインフラストラクチャとしてEC2インスタンス、NATゲートウェイ、NLBなどが構築されます。我々は、より新しいインスタンスタイプ、より高速なボリューム、より優れたネットワーキングなど、継続的なパフォーマンス改善を行っています。特に今年、大きな取り組みとして、etcdの管理方法を大幅に見直しました。

Rama：その改善は、大規模クラスターへの対応が主な目的だったのでしょうか？

Mike：その通りです。一部の顧客から10,000ノード、20,000ノード、さらには50,000ノードのクラスターの要望があり、それに応えるためにはKubernetesのバックエンドデータベースであるetcdの管理方法を根本的に見直す必要がありました。このリファクタリングにより、これまでにない規模のクラスター運用が可能になります。

Cas：Eli Lillyの視点から見ても、この進化は重要ですね。医薬品開発における機械学習ワークロードは年々大規模化しており、コントロールプレーンのスケーラビリティは私たちにとっても重要な課題でした。

Mike：はい、来年にはこの改善についてより詳細な情報を公開する予定です。重要なのは、これらの改善がバックグラウンドで継続的に行われており、顧客は特別な対応をすることなく、その恩恵を受けられるということです。

4.2. EFAサポートの拡張

Mike：低レベルのインフラストラクチャイノベーションの一例として、EFA（Elastic Fabric Adapter）のサポート拡張について説明させていただきます。EFAは、AWSが開発したOSバイパスのハードウェアインターフェースで、高レベルのマルチノード間通信を可能にします。我々は、デバイスプラグインを通じてEFAをEKSとKubernetesで簡単に使用できるようにしています。

Rama：最近の強化点について、もう少し詳しく説明していただけますか？

Mike：はい。まず、EFAが同一AZ内でのクロスサブネット通信をサポートするようになりました。これまでEFAは単一のサブネットに制限されていましたが、この制限が緩和されました。ただし、トレーニングをAZ間で行うのはコストが高くなるため、推奨されません。この機能は主にIPアドレスの枯渇問題への対応を意図しています。

Rama：IPアドレスの管理に関連して、EFAのみのENIサポートも導入されましたよね。

Mike：その通りです。MLトレーニングワークロードの多くは、実際には数学的な計算を行うだけで、インターネットとの通信を必要としません。クラスター内の他のノードとの通信だけが必要です。そのため、EFAデバイスに実際のIPアドレスを追加する必要をなくし、EKSでEFAのみのENIサポートを導入しました。

Cas：Eli Lillyでの大規模なトレーニングジョブの経験から、これらの改善は非常に重要だと感じています。特に、複数のモデルを並行して学習させる際に、ネットワークの最適化は重要な課題でした。

Mike：その通りです。また、これらの機能強化により、特に大規模なトレーニングジョブを実行する際のセットアップと管理が大幅に簡素化されました。EFAデバイスプラグインを通じて、これらの機能をKubernetesのネイティブなインターフェースとして簡単に利用できます。

4.3. GPUモニタリングとヘルスチェック

Mike：GPUインスタンスはCPUインスタンスと比較して故障率が高い傾向にあります。EC2チームはデータセンターレベルでパフォーマンスを向上させるために多大な努力を行っています。例えば、データセンターの湿度を1%変更するだけでGPUインスタンスの寿命が10%向上するといった知見も得られています。しかし、それでも時々故障は発生します。

Rama：そのような状況に対して、どのような対策を講じているのでしょうか？

Mike：はい。今年は特にGPU故障の検出に重点的に取り組みました。先週、EKSオートモード向けにこの機能がリリースされ、今後2週間以内に他のコンピュートオプションにも展開される予定です。具体的には、ノードヘルスモニタリングエージェントを実装し、クラスター内でデーモンセットとして実行されます。

Cas：それは興味深いですね。Eli Lillyでも、GPUインスタンスの管理は重要な課題でした。このエージェントはどのような問題を検出できるのでしょうか？

Mike：我々は6年間にわたってKubernetesクラスターを運用してきた経験から、ノードが故障する可能性のあるあらゆるパターンを把握しています。その知見をこのノードヘルスモニタリング・リペアエージェントに組み込んでいます。特にGPUインスタンスに焦点を当てた機能を実装しています。

Rama：自動修復機能についても説明していただけますか？

Mike：マネージドノードグループでは、自動修復機能をオプトインで利用できるようになります。EKSが問題を検出した際、故障のタイプに応じて、インスタンスの再起動や再作成などの適切な対応を自動的に実行します。これにより、問題のあるインスタンスが無駄にコストを消費し続けるような事態を防ぐことができます。

4.4. Auto Modeの導入

Mike：この数日間の発表でお気づきかもしれませんが、私たちは先日Auto Modeを導入しました。これはEKSにKarpenterを統合し、より使いやすくすることを目的としています。Auto Modeは、Kubernetesデータプレーン、つまりコンピュート、ストレージ、ネットワーキングに関する新しい「簡単ボタン」と考えていただけます。

Rama：このAuto Modeについて、EC2との新しい運用モデルについて説明していただけますか？

Mike：はい。これまでAWSでのコンピュートの実行には2つの方法がありました。1つは完全マネージド型のLambdaやFargateモデルで、コンピュートがAWS所有のアカウントで実行される方式です。もう1つは標準的なEC2で、お客様が所有する方式です。新しいEC2マネージドインスタンスは、この中間に位置づけられます。これは、お客様のアカウント内のEC2インスタンスですが、EKSなどのAWSサービスがそのライフサイクルを所有します。

Cas：そのアプローチは興味深いですね。Eli Lillyでも機械学習ワークロードの管理で苦労していましたが、このような自動化はどの程度まで提供されるのでしょうか？

Mike：例えば、ENIを削除しようとすると、サービスによって使用中というエラーが表示され、EKSを通じて管理する必要があります。特に注目すべきは、機械学習ワークロードをEKSで開始する際の難しい部分、つまり適切なデバイスドライバー、EFAプラグイン、インスタンスストレージの設定などが、EKS Auto Modeで完全に自動化されている点です。例えば、ローカルディスクインスタンスでRAID 0ボリュームをセットアップする複雑なユーザーデータスクリプトが不要になりました。デバイスプラグイン（NVIDIAやNeuronなど）も自動的に設定され、GPUインスタンスを起動すると、それに適合するAMIが自動的に選択されます。

Rama：トレーニングワークロードについては、どのようにお考えですか？

Mike：現時点では、Auto Modeはトレーニングワークロードに完全に適していると言えません。インスタンスの最大寿命が21日に制限されているためです。顧客の中には数ヶ月にわたってトレーニングジョブを実行するケースもありますが、推論ワークロードや本番環境でのモデル実行には、Auto Modeは良い選択肢となるでしょう。

5. 顧客事例：Eli Lilly and Company

5.1. 技術進化の歴史

Cas：Eli Lillyの技術進化について、いくつかの興味深い歴史的な文脈を共有させていただきたいと思います。左側の写真は1987年のもので、典型的な80年代の企業幹部たちが個人用コンピュータの新規導入を喜んでいる様子です。そして右側の写真は、Cray-2スーパーコンピュータです。1989年、Lillyは米国で政府機関以外として初めてこのスーパーコンピュータを購入しました。

Mike：150年の歴史を持つ企業としては、かなり早い段階から技術採用に積極的だったのですね。

Cas：はい。私自身、1年前にLillyに入社した際、この技術革新の歴史を知って驚きました。しかし、残念ながらこの上昇トレンドは2001年に大きな転換点を迎えることになります。我々は社内でこれを「Year X」と呼んでいます。

Rama：その転換点について、もう少し詳しく説明していただけますか？

Cas：2001年に最初のProzacの特許が切れ始めたのです。当時、Prozacは当社の利益の3分の1を占めていました。他の医薬品も特許切れを迎え、売上が劇的に減少する中で、コスト削減の必要に迫られました。ソフトウェア開発などの「非コア」と見なされた技術革新活動は特に大きな打撃を受けました。

Mike：しかし、現在は状況が大きく変わっているように見受けられます。

Cas：その通りです。現在、Lillyは医薬品会社として成功し続けるためには、技術企業になる必要があるという認識を会社全体で共有しています。幸いなことに、最近の医薬品開発の成功と強力なパイプラインにより、ソフトウェアエンジニアリング能力、ロボティクス自動化、データサイエンス、あらゆる種類のAIへの投資を大幅に増やすことができています。これは、今後も継続的に拡大していく予定です。

5.2. CATSプラットフォームの開発

Cas：この技術進化の一環として、数年前に私が所属するソフトウェアプロダクトエンジニアリングチームが設立されました。このチームは元AppleのエンジニアリングリーダーであるGo Cole Rad Krishnanが率いており、高い信頼性と利用率を持つスケーラブルな製品とプラットフォームの構築に焦点を当てています。

Mike：そのようなチームがEKSを選択した理由について、詳しく聞かせていただけますか？

Cas：私たちはCloud Applications and Technology as a Service（CATS）と呼ばれる包括的なクラウドアプリケーション開発・ホスティングソリューションを構築しました。これはAWS上に構築され、オープンソースとAWSマネージドサービスを組み合わせて運用しています。図は簡略化されていますが、Kubernetesの管理にEKS、コンテナ実行にEC2とFargate、そしてS3、RDS、Secrets Managerなど、多数のAWSサービスを統合しています。

Rama：GitOpsとCI/CDの自動化についても触れていましたが、その点についてもう少し詳しく説明していただけますか？

Cas：開発者がコミットを行うと、GitHub Actionsが起動し、DockerイメージがECRにプッシュされ、Argoがそれを検出して適切なKubernetes環境に自動的にデプロイします。これにより、開発者は短時間でコードを本番環境にデプロイできます。また、インフラストラクチャに関する多くの決定を個別に行う必要がなく、標準化された方法で開発を進めることができます。

Mike：セキュリティと可観測性の面ではどのような取り組みをされていますか？

Cas：多くの標準化により、堅牢なセキュリティプラクティスを確保しています。脆弱性スキャンを実装し、またAmazonのサービスとLokiやGrafanaなどのオープンソースツールを組み合わせて、包括的な監視・アラート・レポート・可視化機能を提供しています。これにより、チームは自身のアプリケーションをスケールアップする際に必要な監視機能を容易に利用できます。最も重要な利点は、アプリケーションが一度開発されれば、追加作業なしにLillyの全従業員向けにグローバルにスケールでき、高い信頼性を維持できることです。

5.3. Generative AI実装の成果

Cas：Lillyでは、業界内でGen AIの採用とインパクトにおいてリーダーシップを発揮することを目指しています。私たちの仕事の多くの面で、Gen AIが根本的な変革をもたらすと考えているからです。2023年12月に最初の本番リリースを行い、以来、機能とケーパビリティを継続的に追加しています。

Mike：具体的にどのようなモデルライブラリを構築されたのでしょうか？

Cas：私たちは、開発者がさまざまな最新のLLMから選択できるようにしています。Anthropicのモデルラインを多用していますが、OpenAI、Gemini、Hugging Faceなども利用可能です。法的承認を得られれば、Hugging Faceから実質的にどのモデルでもデプロイできます。これらのモデルは、リテールとして、オープンソースとして、あるいはファインチューニングされたモデルとして、私たちのGPUクラスターでローカルにホストすることができます。

Rama：オーケストレーションツールについてはいかがですか？

Cas：私たちはLangchainをメインのオーケストレーションフレームワークとして使用しています。最初はプロンプトエンジニアリングとモデルチェーニングのための単純なツールから始めましたが、現在では、エージェンティックワークフローやマルチエージェントシステムもサポートできるように、より複雑なオーケストレーションツールを追加しています。

Mike：実際の適用事例について、いくつか共有していただけますか？

Cas：最も印象的な例は、ケミインフォマティクスエージェントです。このエージェントは約20の異なるツールにアクセスでき、その中にはケミインフォマティクスツール、Lilly分子情報の内部データベース、外部データベースが含まれています。LLMがユーザーの質問に応答したり、ワークフローを実行したりする際に、これらのツールを選択して使用します。これにより、初期段階の創薬を支援する強力なワークフローが可能になりました。

また、臨床試験の分野では、世界中の規制当局からの何千もの質問に対する回答を支援するツールを開発しました。製造分野では、SOPや機器センサーデータなどの構造化・非構造化データを活用して、製造ラインの稼働時間を監視・管理するアシスタントを開発しました。特許文書作成ツールも開発し、さらに私たちのプラットフォーム上で最初の患者向けQ&Aツールも開発中です。

5.4. 学びと気づき

Cas：この取り組みを通じて、主に3つの重要な教訓を得ることができました。最も大きな学びは、プラットフォームアプローチの有効性です。EKSのようなスケーラブルなプラットフォームを使用し、Gen AI開発に対してある程度の指針を持ったアプローチを採用することで、開発者の生産性が大きく向上しました。実際に、開発者は数週間でPOCを、数ヶ月でMVPを本番環境にリリースできるようになっています。

Rama：採用パターンについて、興味深い知見があったとおっしゃっていましたが。

Cas：はい。「プラットフォームを構築すれば、みんなが使い始める」というのは誤りでした。Lillyのような環境では、非常に優秀で迅速に動ける開発者チームが最初に採用を始めますが、その後には能力分布に応じた幅広い開発者層が続きます。より広い採用を実現するには、啓発活動、質問への回答、サポートドキュメントの整備、サポートチームの確立など、多くの取り組みが必要でした。

Mike：プロダクトマインドセットについても言及されていましたね。

Cas：その通りです。私たちはこれを純粋な製品として扱い、プロダクトマネージャーやロードマップを設定しました。常に顧客の声を集めることを心がけています。例えば、私たちエンジニアは情報検索パイプラインの最新の改善に夢中になりがちですが、顧客は「QA環境をもう少し安定させてほしい」と考えているかもしれません。技術とエンジニアリングに没頭しすぎず、顧客ニーズに焦点を当て続けることが重要です。

また、期待値は急速に高まっていきます。当初は、開発者から特定のプラットフォームへの誘導に対して懐疑的な反応がありましたが、それはすぐに「これで開発が速くなる」「承認が簡単になる」という認識に変わり、さらに「ドキュメントはどこ？」「正式なSLAは？」といった要求へと発展しました。

最後に、特にLillyのようなサイバーセキュリティや法務、プライバシーの基準が高い企業では、サイバーセキュリティチームとの早期からのパートナーシップが、このプラットフォームの成功に不可欠でした。この経験から、プラットフォーム構築時には、ドキュメント、サポート、SLAの明確な伝達を先回りして準備することをお勧めします。

6. リソースと今後の展開

6.1. Data on EKSプロジェクト

Rama：多くのお客様から、EKSとオープンソースソリューションを統合する際のガイダンスを求める声がありました。「どのように始めればよいか」「ベストプラクティスは何か」「テンプレートはあるか」といった質問です。そこで私たちはData on EKSプロジェクトを立ち上げました。

Mike：その具体的な内容について、もう少し詳しく説明していただけますか？

Rama：このプロジェクトでは、顧客の間で成功を収めているさまざまなGen AIパターンを公開しています。Terraformテンプレートやブループリント、パターンを提供することで、人気のあるオープンソースソリューションとEKSの統合を容易に始められるようにしています。

Mike：特に推論に関するパターンに注力されているとお聞きしましたが。

Rama：はい、昨年から多数のパターンをリリースしていますが、特に推論に特化したパターンの開発に力を入れています。例えば、NVIDIAとVLLMの組み合わせ、RayserとVLLMの統合、EKS上でのNVIDIA NIMsなど、実際の環境で成功を収めているパターンを公開しています。これらのパターンはすべてData on EKSのウェブサイトで確認できます。

Cas：Eli Lillyでも、このようなパターンとテンプレートは非常に有用でした。特に開発者が新しいプロジェクトを始める際の指針として、また既存のプロジェクトのベストプラクティス確認用として活用しています。

Rama：今後も実際の導入事例から得られた知見を元に、新しいパターンを継続的に追加していく予定です。特に推論ワークロードについては、顧客からの需要が高いため、優先的に取り組んでいきます。

6.2. 利用可能なトレーニングリソース

Rama：Amazon EKSの学習を継続するためのリソースについて、いくつかの重要なオプションを用意しています。まず、実践的なワークショップを通じて、実際の環境でEKSを体験することができます。これらのワークショップは、初心者から上級者まで、さまざまなレベルの方々に対応しています。

Mike：また、デジタルバッジ制度も導入していますね。これについて説明していただけますか？

Rama：はい。デジタルバッジは、特定のスキルセットや知識レベルを証明する方法として提供しています。例えば、EKSでのGen AI実装に関する専門知識を獲得し、それを証明したい開発者向けに、専用のバッジを用意しています。

Cas：Eli Lillyでも、これらのトレーニングリソースを活用しています。特にベストプラクティスガイドは、新しいチームメンバーのオンボーディングや、既存のチームのスキルアップに非常に役立っています。

Rama：ベストプラクティスガイドは、実際の顧客事例から得られた知見を集約したものです。特にGen AIワークロードの実装に関しては、セキュリティ、スケーラビリティ、コスト最適化など、さまざまな観点からのベストプラクティスを提供しています。これらのリソースは常に更新されており、最新のトレンドや技術進展を反映しています。