re:Invent 2024: AWSが語るKubernetesの未来とEKSの新機能
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - The future of Kubernetes on AWS (KUB201)
この動画では、AWSにおけるKubernetesの未来について、Amazon EKSのプロダクト部門を統括するNathan Taberが解説しています。Amazon EKSの最新機能として、Control Planeの更新時間短縮やExtended Version Support、Upgrade Insights、Enhanced Control Plane Observabilityなどが紹介されています。また、SnowflakeのプリンシパルソフトウェアエンジニアHyungtae Kimが登壇し、Amazon EKSを活用した大規模AI基盤Cortex AIの運用事例を共有しています。さらに、新機能のEKS Auto ModeやEKS Hybrid Nodesの発表、そしてAmazon EKSの今後の展望として、マルチクラスター環境での統合管理や開発者エクスペリエンスの向上に注力していく方針が示されています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
AWSにおけるKubernetesの進化と重要性
おはようございます。皆様、Cube 201「AWSにおけるKubernetesの未来」へようこそ。私はNathan Taberです。本日は大変嬉しく思います。後ほど、特別ゲストスピーカーのHyungtae Kimさんにもご登壇いただきます。私はAWSでKubernetesとレジストリのプロダクト部門を統括しています。それでは、早速始めていきましょう。
私たちがここに集まっているのは、コンピューターの使い方に根本的な変化が起きているからです。メインフレームや統合マイクロコンピューターの時代から、エンタープライズコンピューティングには、ハードウェアやデータセンタースペースへの多大な投資が必要でした。 2006年、AmazonはAmazon S3とAmazon EC2を発表しました。これらが最初のAmazon Web Servicesとなりました。 これらは私たちが今日ここにいる理由の一つであり、当時も、そして今日でも世界最大級のトラフィックを誇るウェブサイトの一つであるamazon.comを運営するために使用されているストレージとコンピュートの基本機能を、標準的な形で一般に提供したものでした。
これがクラウドです。ウェブサイトからデータ処理、機械学習モデルまで、あらゆるアプリケーションを実行できるコンピューティング基盤のセットです。 この約20年間で、AWSは220以上のサービスに成長し、アプリケーションやインフラを管理するための複雑なツールを含む、他の多くのクラウドサービスを生み出してきました。クラウドは、私たちのコンピューティングモデル、情報の保存、処理、取得方法を根本的に変えました。今では世界中にアプリケーションを数分で書いてデプロイできます。ほんの数年前なら数十億ドル規模のスーパーコンピューターへの投資が必要だったような複雑なAIモデルのトレーニングのために、データセンター全体を瞬時に立ち上げることができます。
Kubernetesの特徴と課題
つい最近まで何年もの計画と投資、構築が必要だったことが、今ではAWSコンソールで数回クリックするだけで実現できます。クラウドは、アプリケーション構築に対する私たちの考え方を根本的に変えました。しかし、多くの異なるアプリケーションが多くの異なる場所で実行される中で、クラウドの内外で一貫した運用モデルを確立することに苦心してきました。これは新しい問題ではありません - 長年にわたって多くのソリューションが開発され、試されてきました。しかし今日、主要なクラウドオペレーティングシステムとなっているのがKubernetesです。
Kubernetesは非常に人気が高く、現在、大多数の企業が本番環境でKubernetesを使用しているか、パイロット導入を行っています。 これは主に、Kubernetesが実際に役立つものだからです。大規模なサーバーグループを管理し、それらのサーバー全体でアプリケーションの実行を調整するためのシンプルなAPIセットを提供します。シンプルと言うのは、AWS Python SDKの10,000以上のAPI関数と比べて、Kubernetesは約55のコアリソースにわたって約1,500のAPIメソッドまたは関数しかないからです。
Andy Jassyは次のように述べています。「開発者がWeb Servicesを基本的な構成要素として一からアプリケーションを構築すると考えるなら、インターネットがオペレーティングシステムになる」と。インターネットには複数のドメインが存在し、インターネットの外側にも世界が広がっています。ここでKubernetesが真価を発揮します。データセンターからAWS、そしてF-16戦闘機に至るまで、どこでも使える基本的な構成要素を提供してくれるのです。そう、本当にF-16戦闘機での実績があるんです。Google検索すれば確認できますよ。F-16戦闘機上でKubernetesを実行したのです。
そして、Kubernetesには拡張性があります。なぜなら、1,500の機能があっても、クラウドを動かすには十分ではないからです。 この拡張性こそが、顧客が様々な場面でKubernetesを活用できる理由なのです。現在、Cloud Native Computing Foundationの管理下には195のオープンソースプロジェクトがあり、さらにKubernetes上で動作し、統合され、機能を拡張する何百ものランドスケープ・プロジェクトが存在します。独自のプロジェクトを作ることもできますし、ここにいる多くの方々が、そういったプロジェクトを見たり、実際に手がけたりした経験があるのではないでしょうか。
Amazon EKSの進化と最新機能
Kubernetesは素晴らしく、Kubernetesを使うことは素晴らしい体験です。Kubernetesは開発者にとって素晴らしい体験を提供します。 しかし、Kubernetesの運用は困難です。kubectl applyと何百行ものYAML、プラグイン、ネットワーク設定、クラスターのアップグレードなど。Kubernetesは一般的に運用が難しいシステムです。特に大規模な環境や複数の場所での運用となるとなおさらです。 AWSでは、マネージドKubernetesの提供から7年が経ちました。2017年のre:Inventで Amazon EKSを発表して以来、おそらく世界最大規模でのKubernetes運用のあらゆる側面に深く取り組んできました。基本的なマネージドコントロールプレーンから始まり、コンピュート管理、補助ソフトウェア、セキュリティ、スケーラビリティ、ネットワーキング、可観測性とトラブルシューティングの機能を着実に追加してきました。
数十の新しいオープンソースプロジェクトを作成し、その一部をCloud Native Computing Foundationに寄贈しました。Kubernetesの動作方法に根本的な変更を加え、AWSとKubernetesを結びつけるパブリックおよび内部統合の完全なスイートを構築しました。Kubernetes上に構築された最大規模で最も洗練されたアプリケーションや機械学習モデルの多くを支えており、 年間で数千万のクラスターを顧客向けに運用しています。そしてこの数は急速に増加しています。エッジケースがあれば、私たちのチームは必ず遭遇しています。AWSでよく言うように、「経験値には近道がない」のです。
これから45分間、AWSがKubernetesのビジョンを実現するためにどのようなイノベーションを行っているかについてお話ししたいと思います。 本日は、SnowflakeのプリンシパルソフトウェアエンジニアであるHyungtae Kimをお迎えできることを嬉しく思います。SnowflakeはAWS上に構築されたエクサバイトスケールのデータプラットフォームです。後ほど、SnowflakeがどのようにAmazon EKSを活用して顧客向けの機械学習をスケールしているのか、Hyungtaeからお話を伺えることを楽しみにしています。
ビジネス価値を提供することが目標であり、インフラストラクチャシステムを運用することが目標ではありません。私たちのお客様は、必要なときに必要なものだけに触れたいと考えています。私たちの目標は、システム運用における差別化されていない重労働を取り除き、本番環境で使用できるKubernetes環境を構築するために必要な基本的なコンポーネントを提供することです。では、それはどういう意味でしょうか？現在のKubernetes環境はどのようなものでしょうか？私たちはこのように考えています。
Kubernetesを本番環境に導入する際のスタックには、いくつかの層があります。最下層には、AWSがお客様向けに大規模に構築・運用しているコンピューティング、ネットワーキング、ストレージ、その他の基本的なコンポーネントといったインフラストラクチャがあります。その上の層には、Kubernetesのコントロールプレーンがあり、KubernetesのAPIサーバーCDやその他のコントロールプレーンコンポーネントに関するスケール、可用性、統合、拡張を担当しています。その上には、デプロイメント、可観測性、ガバナンス、トラフィック、セキュリティのための管理ツールが必要です。さらにその上には、社内開発者プラットフォーム、ジョブ管理、MLワークフロー管理、分析プラットフォーム、最近ではMLOpsと呼ばれるような開発者ツールがあります。
アプリケーション、コード、データはすべてコンテナ化され、このスタックの下で実行されます。横には、Container Registryがあります。これらすべてがコンテナとしてパッケージ化され、このインフラストラクチャ上で実行されるからです。Kubernetesに関する私たちの目標は、アプリケーションとデータから完全なスタックのKubernetes環境への移行を、お客様にとって本当に簡単にすることです。まずはRegistryから始めましょう。
Amazon ECRの強化とKubernetesのバージョン管理
すべてはContainer Registryから始まります。これは、コードとデータが最初に配置される場所です。データはRDSやS3のような場所に配置される一方で、アプリケーションコードはFinchやDockerなどのクライアントでパッケージ化されビルドされています。AWSのマネージドOCIコンテナレジストリであるAmazon ECRがあります。これは、Amazon EKSよりも長く運用している素晴らしいレジストリ製品です。任意のクライアントでビルドし、そのイメージをAmazon ECRに配置して、AWS cloud上のAmazon EKS、ECS、Lambda、その他好きな場所にデプロイできます。
この数年間、私たちはAmazon ECRを強化してきており、私たちにとって非常に活発な投資分野となっています。この1年間で、Amazon ECRのイメージスキャニングをアップグレードしました。これらのイメージが安全であることは、お客様にとって非常に重要だからです。本番環境では、スキャンされ署名された、信頼できるコードを実行したいと考えています。以前は、Clairというイメージスキャニングライブラリを使用していました。これは素晴らしいものでしたが、お客様が求めるすべてのライブラリと脆弱性データベースを備えていませんでした。そこで2024年には、Amazon Inspectorと統合し、ECRのベーシックおよび拡張イメージスキャニングを導入しました。拡張スキャニングでは、50以上の脆弱性データベースと12以上のオペレーティングシステムに対応しています。これはすべてのECRレジストリ内で有効化でき、プッシュ時や任意のスケジュールで自動的にイメージをスキャンできます。
また、お客様がAmazon ECRで画像の状態を一元管理しやすくなるよう改善を行い、クラスターにプルする前にコンテナイメージのデリバリーパイプラインを確立できるようになりました。その一つの方法が、ECR Pull Through Cache（PTC）です。Authenticated Pull Through Cacheを使用すると、Docker Hub、GitHub Container Registry、その他のパブリックレジストリソースからアップストリームレジストリを同期し、そのイメージをAmazon ECRにダウンロードすることができます。この同期を設定すると、ECRに自動的にプライベートリポジトリが作成され、そのイメージとそのさまざまなバリアントが保存されます。
定期的に同期プロセスを実行して、更新されたイメージをECRにダウンロードし、そこでスキャンを行い、プルに必要なインフラストラクチャと共に保管することができます。これによりセキュリティとイメージのプル時間が改善され、アプリケーションの起動が速くなります。この機能は現在すぐにご利用いただけます。ECRとそのフットプリントに関する取り組みの結果、Amazon ECRは現在、毎日20億回以上のイメージプルを処理しています。
これは、お客様がKubernetesを含むあらゆる方法でコンテナを実行する際に、Amazon ECRを使用しているためです。ここで、Kubernetes Control Planeについてお話ししましょう。Kubernetesにおいてお客様が直面している最大の課題の一つは、Control Planeを最新の状態に保つことです。Amazon EKSでは、以前はControl Planeの更新に関するパフォーマンスが、正直なところ少し芳しくありませんでした。アップストリームに対して最大243日の遅れがありました。この2年間、私たちは自動化に多大な投資を行い、新しいKubernetesバージョンの認定に要する時間を数週間から数日に短縮することができました。
2023年には、この自動化を実践し、Amazon EKSの4つのバージョンをリリースして最新の状態を維持しました。現在は、Kubernetesのアップストリームリリースサイクルに合わせて、年間3バージョンのリリースペースに落ち着いています。アップストリームに対して35〜40日の遅れを一貫して維持しています。これ以上速くすることは考えていません。そういう時期が来るかもしれませんが、通常は新しいKubernetesのマイナーバージョンが安定するのを待ち、1リリース後にAmazon EKSに取り込むようにしています。正直なところ、来年はこのグラフを見せないかもしれません。とても退屈になってきているからです。そして、それこそが私たちの望むところなのです。
Amazon EKSでイメージとバージョンの取り込みを加速させてきましたが、お客様は別の問題に直面しています。それは、最新バージョンへの移行です。Kubernetesのアップグレードは本当に大変な作業になり得ます。昨年、お客様から、通常のバージョンリリースプロセスである14ヶ月以上かかって、新しいバージョンのKubernetesに移行しているという声を聞きました。このお客様からのフィードバックに耳を傾け、Extended Version Supportを導入しました。Amazon EKSのExtended Version Supportは、KubernetesのマイナーバージョンについてAWSから12ヶ月の追加フルサポートを提供します。
コミュニティのリリースサイクルでは、14ヶ月経過後にそのバージョンのサポートが完全に終了します。ドキュメントはウェブサイトから削除され、ダウンロード可能なバイナリも削除され、バグの対応も行われなくなります。実質的に、そのバージョンは存在しなくなるわけです。しかし、Amazon EKSでは、さらに12ヶ月間そのバージョンを維持できるよう投資を行っています。私たちのチームは、新しいKubernetesのバージョンや新たなCVEを確認し、適切なパッチを選んで、古いバージョンのKubernetesを実行しているすべてのシステムにパッチを適用することで、お客様が次のバージョンへの移行を計画している間もセキュリティを確保し続けます。
Extended Version Supportの素晴らしい点は、いつ、どの程度利用するかをお客様自身が選択できることです。どのマイナーバージョンでもExtended Version Supportに移行でき、いつでも標準サポートに戻すことができます。特別なバージョンのKubernetesを選んだり、戦略を立てたりする必要はなく、ビジネスの優先順位に応じてアップグレードのタイミングを調整できます。 また、Extended Version Supportを利用している多くのお客様から「これは開発用クラスターなので、自動的にアップグレードされても構いません。常に標準サポートを維持できるようにしてもらえませんか？」という声がありました。
数ヶ月前、標準バージョンでControl Planeを自動的にアップグレードし続けるアップグレードポリシーを発表しました。どのEKSクラスターにもアップグレードポリシーを設定でき、そのポリシーを設定すると、常にControl PlaneをKubernetesの最新の標準バージョンに保ちます。これは開発環境やテスト環境、あるいはアップグレードの影響を確認したいカナリアステージング環境で、Extended Supportモードに入ることを心配せずに済む優れたソリューションです。この機能は現在ご利用いただけます。
Kubernetesの可観測性とコスト管理の改善
アップグレードまでの時間的余裕を確保することは重要ですが、アップグレード時の確実性を高めることも、Kubernetesバージョンに関する重要な要素です。お客様は、バージョンアップグレード時に何が起こるのかを事前に確認したいと望んでいました。そこで昨年、Upgrade Insightsを導入しました。Upgrade Insightsは、クラスターのレポートカードのような機能です。これは継続的に実行され、30日分のデータを提供します。API Serverに入ってくるAPIコールを監視し、将来のKubernetesバージョンすべてについてチェックを行います。
この例では、バージョン1.25のクラスターを実行しており、Upgrade Insightsはバージョン1.32まで、API Serverとそれに対するコールをテストしています。複数のバージョンをスキップしたい場合、1.26や1.27に移行したいと指定すれば、それらのバージョンに対するレポートカードをチェックして、合格か不合格かを確認することができます。
詳細ビューを見ると、このControl Planeにアップグレードした場合に、どこでエラーが発生し、何が失敗するのかを正確に確認できます。この例では、V1 beta oneのPod Disruption Budgetを使用していますが、1.25ではV1 Pod Disruption Budgetに置き換えられています。もし今このクラスターを1.24から1.25にアップグレードすると、kube-state-metricsと私のアプリケーション（単に"app"と名付けました。あまり創造的ではありませんが）、この2つがそのAPIコールを行っているため、これらを修正する必要があります。Upgrade Insightsの優れている点は、クラスターの詳細な状態を把握でき、アップグレード前にチームが正確に何が起きているのかを理解できることです。これにより、より自信を持ってアップグレードを実施でき、アップグレード中の失敗を防ぐことができます。この機能は現在、すべてのAmazon EKSコンソールで利用可能です。コンソールを開くと、Observableダッシュボードにこの機能があり、すべてのクラスターでデフォルトで無料で実行されています。
Observabilityはアップグレード時に非常に有用ですが、Kubernetesのようなシステムを日々運用する上でも重要な要素です。お客様が常に行う必要があるのは、クラスターのObservabilityの設定です。今年、私たちはこれをより簡単にするために、Enhanced Control Plane Observabilityを導入しました。これは数ヶ月前にリリースされ、2つの主要な機能を追加しました。まず、クラスター、kube-controller-manager、kube-schedulerの追加メトリクスを導入し、新しいPrometheusエンドポイントで収集して、任意のObservabilityシステムにエクスポートできるようになりました。また、EKSコンソールに新しい事前設定済みのダッシュボードを追加し、これらの重要なメトリクスを視覚的に表示することで、Control Planeが健全で期待通りに動作しているかを迅速に評価できるようになりました。
これらのダッシュボードはCloudWatchに事前構築されており、どれでも詳細に調査できます。この一環として、Amazon EKS内に全く新しいObservabilityスイートを構築しました。メトリクスも備えていますが、私が特に気に入っているのは、CloudWatch Log Insightsとの深い統合です。CloudWatch Log InsightsはかなりPの前からあり、EKSからCloudWatchログをエクスポートすることも可能でしたが、これまでは自分で設定して実行する必要がありました。現在は、EKSダッシュボードに事前設定されたログクエリがあり、ボタンを押すだけでクエリを実行できます。私のお気に入りの一つは「Top Talkers」で、クラスター内のどのサービスがAPIサーバーと最も頻繁に通信しているかを示します。これは、APIサーバーで異常な動作が見られたり、期待通りのパフォーマンスが出ていない場合に特に役立ちます。Top Talkersクエリを実行すると、例えばV1 Beta oneのIngressesが過去30分間でAPIサーバーに1700回のコールを行ったことなどが分かります。これらのダッシュボードは、より高度なObservabilityツールに取って代わるものではありませんが、Observabilityの出発点として、またクラスター管理時の迅速なトラブルシューティングのために設計されています。
さらに深く掘り下げると、CloudWatchは昨年、コンテナユーザーにとってより使いやすくするために大幅な改善を行いました。現在、Amazon EKS向けの拡張されたObservabilityを備えたContainer Insightsを提供しています。この機能の一部をEKSコンソールにすぐに使える形で組み込み、CloudWatchをクリックすると、1つまたは複数のクラスターを横断的に見られる、より詳細なパフォーマンス概要が表示されます。ARMの使用状況、クラスターとアプリケーションのパフォーマンスに対してより積極的なアクションを取るためのデータ、そしてクラスターの健全性に関するメトリクスと可視性を提供します。最近、これらのContainer InsightsにGPU、Neuron、Windowsのサポートを追加しました。これは本当に印象的な機能です。
今週のre:Inventで、CloudWatchでネットワークトラフィックに関する非常に興味深い機能を発表しました。 CloudWatchではVPC Flow Logsを長年提供してきましたが、VPCとCloudWatchは数日前にNetwork Flow Monitorを発表しました。これは非常に優れた新機能で、AWSデータセンター内のマシン間のネットワークトラフィックのパフォーマンスを可視化できます。特に大規模な環境では、ネットワークの性能低下を経験したり、ネットワークの問題のトラブルシューティングを行う必要がある場合が多々あります。CloudWatch Network Flow Monitorを使用すると、パフォーマンスの低下が見られるネットワークパス上の正確なデータと場所を確認できます。
Amazon EKSはNetwork Flow Monitorと標準で連携しています。クラスター内のEC2インスタンス間を行き来するメタデータを自動的にアノテーションします。CloudWatch Network Flow Monitorにアクセスすると、クラスターノード間の通信やクラスターの内外の通信など、クラスターに関連するネットワークトラフィックの状態を把握できます。また、ネットワーク層でのパフォーマンス低下のトラブルシューティングも容易になります。これはre:Inventで発表された新機能で、私たちもとても期待しています。
Amazon EKSのセキュリティとネットワーキングの強化
また、お客様との協力のもと、可観測性のために開発したもう一つの機能がSplit Cost Allocation Dataです。VMの世界からKubernetesに移行する際、以前は1つのVMに1つのアプリケーションという形でモノリシックなアプリケーションを実行していた場合、タグ付けが適切に行われ、コストと使用状況のダッシュボードも分かりやすく表示されていました。FinOps管理者は素晴らしいレポートを得ることができましたが、チームがKubernetesに移行すると、共有クラスターやマルチテナントのマイクロサービスになるため、財務面ではすべてがブラックボックス化してしまいます。これまでもKubecostなどのツールをAmazon EKSで実行することをサポートしてきましたが、お客様からはAmazon EKSにネイティブで機能を組み込んでほしいという要望がありました。
そこで、AWS Cost and Usageチームと協力してSplit Cost Allocation Dataを導入しました。クラスター上のPod使用率データを自動的に収集し、バックエンドでのEC2の実際の運用コストと組み合わせる管理された方法を提供しています。Pod、Deployment、Job、Namespace、クラスターレベルで詳細な分析が可能な新しいコストと使用状況レポートを開発中です。EC2の実際のコストを自動的に取り込み、アプリケーションの実コストを理解するためのネイティブなレポートを提供します。
クラスターを運用する際、コントロールプレーンを実行するだけでは十分ではありません。多くの場合、Amazon EKSに様々な運用ツールを導入する必要があります。数年前、私たちは必要な機能が最初から組み込まれたクラスターを作成できるAdd-onsを発表しました。 この1年でAdd-onsのカタログを拡充し、CloudWatch Container Insights、CSI Snapshot Controller、Pod Identity Agent、Node Monitoring Agentという4つの新しいファーストパーティAdd-onsを追加しました。また、コアネットワーキングAdd-onsなしでクラスターを起動することも可能になりました。一部のお客様からVPC CNIなしでクラスターを起動したいという要望があり、現在ではAdd-ons APIでクラスター起動時に設定できるようになっています。
また、これまでに40以上のマーケットプレースAdd-onsをリリースしています。AWSからのファーストパーティAdd-onsに加えて、マーケットプレース連携を追加し、40以上のマーケットプレースAdd-onsから必要なものを選んでクラスターで実行できるようになりました。ワンクリックでDatadog、Kubecost、New Relic、Splunkなどのツールを購読し、Amazon EKSクラスターに導入できるため、非常に簡単に利用を開始できます。
クラスターにそれらのAdd-onをインストールする際、お客様からセキュリティの強化と、クラスター全般のセキュリティ態勢の改善を求められました。昨年のre:Inventでは、特定のPodにIAMロールを割り当てることができるPod Identityについてお話ししました。今年は、このIdentityをEKS Add-onと統合しました。今では、Add-onをセットアップする際にワンクリックで、特定のIAMロールを作成してAdd-onに関連付けることができます。これにより、クラスター上のすべてのコンポーネントのセキュリティスコープが縮小され、セキュリティの影響範囲が改善されました。この機能は現在ご利用いただけます。
セキュリティの面では、私たちはEKSのセキュリティに継続的に投資を行ってきました。
Add-onにPod Identityを導入し、クラスターレベルでのシークレットの暗号化も実現してきました。数年前から、Amazon EKSにKMSキーを持ち込んでシークレットを暗号化することが可能でした。これは良い機能でしたが、まだ十分ではありませんでした。今年から、デフォルトで提供するKMS v2キーを使用してクラスター上のすべてを暗号化するようになりました。シークレットだけでなく、すべてのオブジェクトを暗号化します。もちろん、私たちのKMS v2に加えて、独自のCMKを持ち込んで暗号化することも可能ですが、デフォルトでAmazon EKSクラスターのすべてが完全に暗号化されるようになりました。
暗号化とセキュリティコントロールに加えて、Kubernetesのアクセスコントロールも改善しました。CedarはAWSが開発した新しいオープンソースの言語です。これは、アクセスコントロールのためのより明示的で表現力豊かなポリシーを記述できる言語です。最近のKubeConで、CedarをAmazon EKSとKubernetesに拡張することを発表しました。Cedarを使用することで、拒否、条件付き、属性やラベルベースのアクセスコントロールなど、Kubernetes RBACでは利用できない機能を使用できるようになります。CedarとEKSを統合する新しいオープンソースプロジェクトとしてのCedarに、私たちは非常に期待しています。これにより、クラスター内外のアクセスコントロールが大幅に向上すると考えています。
ネットワーキングの面では、AWSの最も大きな取り組みの1つがIPv6です。IPv6に関する話題をよく耳にすると思います - 少なくともここ20年はIPv6について話し続けてきたと思います。Amazon EKSが今年行ったことの1つは、IPv6に関連するすべての機能を実装したことです。以前からシングルスタックのPodとIPv6クラスター、IPv6管理APIを提供していましたが、数ヶ月前からIPv6クラスターエンドポイントもサポートするようになりました。IPv6戦略を持ち、IPv6への移行を進めている場合、Amazon EKSを採用することで、クラスターのあらゆる部分で完全なIPv6サポートを利用できることを確信していただけます。
さらに、私たちはAmazon Application Recovery Controllerとの統合も実現しました。Route 53は昨年Application Recovery Controllerをローンチしましたが、これによってAZの部分的または完全な障害が発生した際に、自動的にトラフィックを別のAvailability Zoneにシフトできる高可用性のセットアップが可能になりました。これらの障害は自動的に検知してトラフィックをシフトすることもできますし、いつでも緊急停止ボタンを押してトラフィックを切り替えることもできます。ARCはRoute 53によって一元管理されており、他の多くのAWSサービスもARCと統合されています。
AZで部分的な障害が発生した場合、1つのコンポーネントが故障してパフォーマンスが低下することがあります。多くのトラフィックがAZから退避することになりますが、それ自体は問題ありません。担当者が呼び出され、対応が始まり、問題の修正に取り掛かります。しかし、AZが回復し始めると、私たちが「なだれ現象」と呼ぶものが発生することがよくあります。つまり、AZが回復していると判断した全員が一斉にトラフィックを戻そうとするのです。この回復フェーズでは状況がまだ不安定なため、一度にトラフィックが殺到すると、さらなる性能低下や障害が発生する可能性があります。そのため、小さな問題が大きな問題に発展し、短時間の停止が長期化することがあるのです。
Amazon Application Recovery Controllerは、AZの障害時にトラフィックを退避させ、アプリケーションの実行を維持するだけでなく、AZが再び障害を起こすことなく、インシデントからより迅速に回復できるよう、トラフィックを段階的にAZに戻す支援も行います。AWSとの統合の一環として、私たちはお客様にクラウドへの完全なアクセスを提供しています。AWS Controllers for Kubernetesは、ここ数年間開発してきたプロジェクトで、KubernetesのAPIから直接AWSリソースをクラウドネイティブに制御・定義することを可能にします。この1年間で、20の新しいサービスをGAでローンチし、Amazon SDKからサービスを迅速に構築するためのパイプラインを再構築しました。現在では、より多くのお客様がKubernetesリソースと並行してAWSリソースを管理するためにこれを使用しています。
Amazon EKS Hybrid NodesとAuto Modeの導入
ACKの人気が高まり、サービスカバレッジが拡大するにつれて、お客様から、これらすべてを連携させるのが非常に難しいというフィードバックをいただきました。例えば、単一のS3バケットだけでなく、様々な機能のスイートが必要な場合があるためです。そこで最近、Kube Resource Orchestrator（KRO）を導入しました。KROを使用すると、複数のKubernetesリソースを抽象化し、Common Expression Language（CEL）を使用して抽象化を作成し、クラスターに公開することができます。
これは、AWSとKubernetesのリソースを組み合わせて設定し、その抽象化をクラスターにコントローラーとして公開し、ACKを使用してその抽象化をプログラミングできるシンプルなYAMLベースの言語です。例えば、自社でのKubernetes Deploymentやウェブサービスの定義を作成し、それをKROを使用してクラスターのコントローラーとして配置し、開発チームがそれに対してプログラミングできるようにすることができます。これは現在GitHubでアルファ版として利用可能な非常にエキサイティングなプロジェクトで、来年にかけてさらに開発を進めていく予定です。
AWSの特徴の1つは、グローバルな展開を行っているということです。Amazon EKSに関する大きな発表として、現在すべてのグローバルリージョンをカバーしているということがあります。すべての地理的リージョン、Availability Zone、Local Zoneに展開しています。私たちのお客様は、リージョンのAmazon EKSからLocal Zone、Outpost、そしてEKS Anywhereまで、さまざまな形態で運用を行っています。今週のre:Inventで、Amazon EKS Hybrid Nodesの発表ができることを大変嬉しく思います。お客様がデータセンターでAmazon EKS Anywhereを運用している中で、より管理しやすいソリューションを求める声がありました。Amazon EKS Hybrid Nodesを使用することで、既存のオンプレミスやエッジコンピューティングをリージョンで稼働しているAmazon EKSコントロールプレーンに接続し、すべてを一貫した方法で管理できるようになりました。
コントロールプレーンをデータセンターやエッジコンピューティングまで拡張し、一貫した環境で管理できます。また、観測性やアドオンなど、AWSの上位レベルの統合機能がHybrid Nodesとシームレスに連携します。アーキテクチャはこのようになっています：手動またはスクリプトでオンプレミスのノードすべてにインストールできるCLIツールがあります。このCLIがインストールされると、小さなエージェントが実行され、CLIやその他のコンポーネントをブートストラップし、Amazon EKSクラスターに接続します。クラウド上では、そのノードがコンソールやAPIサーバーに、他のインスタンスと同様に表示され、その属性を確認してワークロードのスケジューリングを開始できます。
Hybrid Nodesは、エンタープライズモダナイゼーション、機械学習、金融サービス、メディアストリーミング、製造業のITアプリケーションなど、さまざまな分野で広く採用されると考えています。Hybrid Nodesの活用方法について非常に期待しており、この1週間、お客様とHybrid Nodesの導入計画について話し合ってきました。もちろん、クラウドも重要で、AWSの強みの1つは、幅広い計算オプションを提供していることです。私たちがお客様のために実現したかったことの1つは、クラスターの作成からアプリケーションの実行までをより簡単にすることでした。
今週、EKS Auto Modeの提供開始を発表できることを嬉しく思います。Auto Modeは、クラウドで本番環境対応のKubernetesを実行する方法における大きな進化であり、クラウドでのKubernetesの運用に関する私たちのビジョンの実現でもあります。Auto Modeを使用すると、必要なすべての機能があらかじめ設定された、アプリケーション対応のクラスターをプロビジョニングできます。Auto Modeにより、新しいワークロードの立ち上げにかかる時間が短縮され、新製品の投入やアプリケーションのモダナイゼーションをより迅速に本番環境へ展開できます。
Auto Mode以前のKubernetesでは、お客様は通常、Infrastructure as Codeなどを使用してクラスターの作成方法を選択し、次にアプリケーションの実行に必要な計算リソースの種類を検討し、EC2とFargateのどちらを使用するか、どのインスタンスタイプを使用するかを決定し、さらにクラスターの機能とプラグインについて考える必要がありました。これらすべてをプロビジョニングして連携させる必要がありました。Auto Modeでは、これらすべてが自動で管理されます。クラスターをAuto Modeに設定すると、計算、ネットワーク、ストレージに関するクラスター内の機能が自動的にプロビジョニングされ管理されます。
私たちは、アカウント内で実行される安全で自動管理されたインスタンスであるEC2マネージドインスタンスを提供しています。クラスターの実行に必要なすべてのものを自動的にプロビジョニングし、インスタンスを最適化し、すべてを最新かつ健全な状態に保ちます。Auto Modeでは、Amazon EKSコンソールとCLIでワンクリックでクラスターを作成できるようになりました。コンソールで簡単にワンクリックで始められ、他の機能と同様に、これは本日からご利用いただけます。Auto Modeの一部として立ち上げられた素晴らしい機能の一つが、EKS Node Health and Auto-Repairです。これにより、特にGPUインスタンスのノードの健全性を自動的に監視し、修復・改善を行います。この機能は現在Auto Modeで利用可能で、今後は他の機能にも健全性チェックと自動修復を拡張していく予定です。Auto Modeは現在一般提供されており、ぜひお試しいただければと思います。
Amazon EKSが大規模に採用されている分野の一つが機械学習です。大規模言語基盤モデルのトレーニングからロボティクス開発、AIの推論のスケーリングまで幅広く活用されています。多くのお客様がAmazon EKSを使用しており、私たちはEKSでの機械学習を簡素化し加速させるインフラ機能への投資を続けています。
ノードの健全性チェックと自動修復から、最近発表されたEC2 UltraServersの一部である高速化されたAMIのセットまで提供しています。EC2 UltraServersはAmazon EKSとネイティブに連携し、計算能力のためのキャパシティブロック予約とも深く統合されています。S3 Mountpoint CSIドライバーやGPUインスタンス用のElastic Fabric Adapterネットワーキングを使用するためのEFA Kubernetesデバイスプラグインなど、データ管理のための統合にも投資を続けています。また、RayのようなネイティブOSSフレームワークへの投資や、Container Insightsへの高速インスタンスサポートの追加により、Kubernetesでの機械学習の効率化も進めています。
SnowflakeのAIプラットフォームにおけるAmazon EKSの活用
EKSでの機械学習についてさらにお話しできることを嬉しく思います。この分野は大きく成長していますが、機械学習の活用についてより深く理解するために、Snowflakeのプリンシパルソフトウェアエンジニアであるヒョンテ・キム氏をステージにお迎えしたいと思います。皆さん、こんにちは。私はSnowflakeのAIプラットフォームとインフラストラクチャのエンジニアリングリーダーの一人、ヒョンテ・キムです。本日は、私たちがどのようにしてAIイノベーションを大規模に実現しているかについてお話しできることを嬉しく思います。皆さんはCortex AIのような、お客様に生成AIの機能を提供する私たちのプロダクトをご存知かもしれません。しかし、その裏にあるインフラストラクチャの話、特にこれらのAIサービスの堅牢な基盤を構築するためにEKS上でKubernetesをどのように活用しているかについては、あまりご存じないかもしれません。
Snowflakeの包括的な生成AIプラットフォームであるCortex AIをご紹介させていただきます。Cortexの特徴は、KubernetesとAWS上のEKSを活用して、AIワークロードの全範囲を処理できる能力です。推論の面では、ゼロから数千の同時リクエストまでスケールできるシステムを構築しました。使い慣れたSQLインターフェースを通じて大規模なバッチ処理を実行する場合でも、サブセカンドのレイテンシー要件を持つリアルタイムチャットアプリケーションを実行する場合でも、私たちのインフラストラクチャはシームレスに適応します。トレーニングインフラストラクチャに関しては、単にモデルを実行するだけでなく、モデルを構築しています。私たちのArcticファミリーの基盤モデルは、AI機能への重要な投資を表しており、検索からドキュメント理解まで、企業のユースケースに対応するモデルが必要で、これらすべてにEKSが効率的に管理する集中的な計算リソースが必要とされています。
基盤モデルに加えて、高度なファインチューニングフレームワークもサポートしています。完全なパラメータのファインチューニングから、LoRAのような効率的なアプローチまで、あらゆる手法をサポートしており、お客様は性能と信頼性を維持しながら、特定のニーズに合わせてモデルをカスタマイズすることができます。 ここで、Cortexの構築で直面した実際の課題についてお話ししたいと思います。多くの方々も共感していただけるのではないでしょうか。私たちは従来のインフラストラクチャアプローチの見直しを迫られた2つの大きなテーマに遭遇しました：キャパシティ管理とシステムの脆弱性です。
キャパシティに関して、GPUが希少で高価であることは周知の事実です。特にNVIDIA H100のような高性能なトレーニング用ハードウェアはなおさらです。驚くべきことに、この希少性は私たちの運用方法を根本的に変えることになりました。例えば、クラスターのアップグレードを考えてみましょう。従来のブルーグリーンデプロイメントアプローチでは、一時的にGPUキャパシティを2倍にする必要があります。アップグレードのためだけに何百台ものP5を用意することを想像してみてください。これはコストの面で禁止的であるだけでなく、供給制約のために実現不可能なことも多いのです。このことから、CPUリソースでうまく機能する「とにかくスケールする」という考え方から脱却し、新しいキャパシティ管理パターンを開発することを余儀なくされました。
より興味深い課題は脆弱性です。AI workload、特に分散トレーニングには、独特の「オール・オア・ナッシング」という特性があります。数千個のGPUにまたがる分散トレーニングジョブを調整することを想像してみてください - たった1つのGPUが故障しただけでも、ジョブ全体が危険にさらされてしまいます。さらに、GPUとその専用ネットワークインフラは、従来のハードウェアよりも故障率が高いのです。 これがCortexを支えるアーキテクチャです。私たちはこれをAIクラスターと呼んでいますが、これは先ほど説明した課題を解決するために設計されています。基本的な考え方はシンプルです：1つのクラスター、1つのリージョン、すべてのAI workloadです。これが強力なのは、リアルタイムの推論から大規模なトレーニングジョブまで、異なるワークロードタイプ間でリソースをインテリジェントに管理する方法にあります。これを可能にする主要なコンポーネントについて説明させていただきます。私たちはこれらをキャパシティ管理とレジリエンスという2つの主要カテゴリーに分類しています。キャパシティ管理については、リソース割り当ての頭脳として機能するカスタムCapacity Controllerを構築しました。
これは、どのリソースを優先するかを判断するインテリジェントなトラフィックコントローラーのようなものです。例えば、リアルタイムの推論サービスがより多くのリソースを必要とする場合、優先度の低いトレーニングジョブをインテリジェントにプリエンプトすることができます。これをVolcano Schedulerと組み合わせました。これは分散トレーニングジョブの調整に不可欠なギャングスケジューリングを処理するオープンソースのスケジューラーです。
レジリエンスの面では、3つの重要なコンポーネントを開発しました。1つ目は、Node Health Serviceです。これは、すべてのノードが健全であることを確認するために、集中的な負荷検証を実行する予防的な診断システムとして機能します。2つ目は、Pod Janitorです。これは単純に聞こえるかもしれませんが、ノード上のワークロードを頻繁に終了させるとKubernetesは不安定になる可能性があり、これがPodのクリーンな終了とインテリジェントな再送信を確実にします。最後に、Invariant Enforcerがあります。これは、ネットワーク検出や分散トレーニング機能など、クラスターの多くのプロパティを強制的に適用します。
最も重要なコンポーネントの1つである、Capacity Controllerについて詳しくご説明させていただきます。これは、異なるワークロードタイプ間でGPUリソースを制御する頭脳のような存在です。画面に表示されているのは、Cortex推論ワークロード用の実際のキャパシティバケット定義です。ご覧のように、これは高優先度としてマークされています。つまり、これらの推論サービスがリソースを必要とする場合、最優先で割り当てられるということです。このシステムの真価は、キャパシティバケットの構造にあります。リアルタイム推論、バッチ処理、モデルトレーニングなど、各ワークロードタイプには、明確な境界を持つ独自のバケットが割り当てられます。この例では、サービスの安定性を確保するために最小3ノードを指定し、必要に応じて200ノードまでスケールアップできるよう、P5とP4インスタンスタイプを指定しているのがわかります。
このシステムの強みは、バケット間でノードをインテリジェントに移動できる能力にあります。需要に応じて動的にリソースプールを調整できるようなイメージです。ただし、数百のGPUを使用する分散トレーニングジョブを扱う場合、ランダムにノードを取得するわけにはいきません。どのノードを使用するかについて、慎重に選択する必要があるのです。
AIインフラストラクチャにおける最も厄介な課題の1つ、ハードウェアの信頼性について説明しましょう。GPUは非常に強力ですが、時間とともに問題が発生する可能性がある繊細なハードウェアです。Node Health Serviceは、フリート内の全GPUが最適に動作することを保証する自動化されたガーディアンです。図を見ていただくと、システム内でのノードのライフサイクルがわかります。新しいノードがクラスターに参加すると、まず試用期間（Probation Period）に入ります。この段階ではまだワークロードの実行は許可されません。試用期間中のノードセットは、GPU、ネットワーキング、ストレージ、パフォーマンスという4つの重要な領域を含む包括的なヘルスチェックを受けます。このシステムの特に優れている点は、マルチノードシナリオの処理方法です。分散ワークで問題が発生した場合、問題のあるノードを特定するのは非常に困難で、体系的なアプローチが必要です。私たちは並列テストを使用して問題のあるノードを特定し、テストに失敗したノードはAWS APIを使用して自動的に終了されます。テストに合格したノードは、検証後にアクティブフリートに参加します。その後のワークロードで潜在的な障害が報告された場合は、再度検証に戻されます。
Amazon EKSが私たちのAIインフラストラクチャをどのように加速させたかをお話しさせていただきます。低レベルの複雑な問題に悩まされることなく、本当に重要なこと、つまり革新的なAIソリューションの構築に集中できるようになりました。まず第一にパフォーマンスです。AWSとの緊密な連携により、分散トレーニングに不可欠なElastic Fabric Adapterネットワーキングのパフォーマンスを最適化することができました。システムの互換性も非常に価値があります。Accelerated AMIには、GPUとネットワーキングの両方に対応したドライバーが搭載されています。また、Accelerated AMIは最新のNVIDIA PyTorch Imageとも互換性があります。ストレージも、EKSが運用を簡素化した分野の1つです。私たちは階層型アプローチを実装しました。モデルチェックポイントとトレーニングデータ用の高性能分散ストレージとしてFSx for Lustreを使用し、その他の永続的なストレージニーズにはEBSとEFSを使用し、データとモデルの信頼性の高いアーカイブとしてS3を使用しています。この柔軟性により、各ユースケースに応じてパフォーマンスとコストを最適化できます。
スケーラビリティと運用に関して、先ほど言及したGPUキャパシティの課題を覚えていますか？AWSでは、ノードの修復を自動的に処理してくれるため、パフォーマンスバッファーを自分たちで維持する必要がありません。また、ATOのような下位層のハードウェアについては、EKSの自動スケーリング機能を活用してそれらのワークロードを管理できます。 Snowflake AIクラスターは、これらの課題を強みへと変えてきました。
冒頭で触れた2つの重要な課題 - キャパシティ管理とシステムの脆弱性 - に話を戻しましょう。AIワークロードは従来のKubernetesパターンとは相性が良くないと申し上げましたが、私たちのオンラインInferenceサービスではその状況を一変させ、他のKubernetesワークロードと同様に需要に応じて動的にスケールできるようになりました。これは、Capacity Controllerが必要に応じて優先度の低いワークロードからリソースを賢く借用できるようになったからです。また、クラスターのアップグレードという厄介な問題も解決しました。Blue-Greenデプロイメントのために高価なGPUキャパシティを2倍にする必要がなくなり、代わりに優先度に基づいてアップグレードを調整できるようになりました。まずTrainingワークロードから始めて、レイテンシーに敏感なInferenceサービスへとスムーズに移行することで、アップタイムを最大化しながらリソース要件を最小限に抑えることができます。
脆弱性の課題については、新しいHealth Serviceによってハードウェア障害の影響を大幅に軽減することができました。高性能ハードウェアに問題が発生した場合、自動的に検出され、バックグラウンドで移行が行われます。 このインフラストラクチャを構築する過程で得たAIの旅での教訓をご紹介させていただきます。これは私が開始時に誰かに教えてもらいたかったことです。まず、ワークロードの設計において、一時性を受け入れることです。中断を不具合ではなく機能として扱うことで、よりレジリエントなシステムが実現できることを学びました。Kubernetesでのステート管理を最小限に抑え、HashiCorp VaultやS3などの他の機能にオフロードすることで、ノードの障害やキャパシティの問題に適切に対応できます。つまり、障害の防止ではなく、復旧の最適化が重要なのです。
次に、ハードウェア管理について戦略的に考えることです。GPUは高価なので、良いものを見つけたら、特にReservationを使用している場合は大切に保持する必要があります。ノードの取得時に厳密なバリデーションを実装することで、無数のデバッグ時間を節約できました。これはインフラストラクチャの品質管理のようなものです。第三に、自動化はオプションではなく、必須です。アクティブなワークロードを持つインスタンスを頻繁に終了させると、Kubernetesは興味深い状態になることがあります。私たちは、スタックしたPodからキャッシュ同期の問題まで、これらの問題を監視して修正する自動化システムを構築しました。
最後に、少なくとも1回のクラスター再構築を防いでくれた実用的なヒントをお伝えします。H100ノードは多くのIPを消費するため、ネットワークインフラストラクチャは余裕を持って計画してください。私たちはわずか18ヶ月で8回目のAIクラスターの反復を行っており、反復するたびにスケールについて新しい発見があります。ここでの重要な教訓は、インフラストラクチャを生きて呼吸する生命体のように扱い、潜在的な問題を常に監視し、その都度修正していく必要があるということです。
Amazon EKSの未来像と課題
SnowflakeのHyungtaeとチームがAmazon EKSを使って成し遂げたことは本当に印象的です。彼らはSnowflakeの進歩を加速させ、コアシステムを世界最高クラスのAI TrainingとInferenceシステムの1つへと進化させ、顧客がデータをより効果的にスケールで管理できるよう支援しています。ここからは、Amazon EKSの将来について数分お話ししたいと思います。これは、分散システムや機械学習における最も困難な問題を解決することに専念するエンジニアリングチームを持つ、洗練された顧客の間でAWS全体で見られる傾向です。これらのテクノロジー企業には、これらの困難な問題を解決するというミッションがあります。
また、同様の課題を抱えながらも全く異なる焦点を持つお客様もいます。そういったお客様は、コアビジネスのためにKubernetesを活用してイノベーションを起こそうとしています。これは、あらゆる企業がテクノロジー企業になりつつある副産物とも言えます。AWSやKubernetesのような高度なシステムは、組織全体の成功を後押しする原動力となり得ますが、もしあなたの使命がこれらのシステムを構築することではなく、テクノロジー以外の課題を解決することにある場合、これらのシステムの活用は非常に困難になる可能性があります。テクノロジー企業ではない企業に優秀な人材がいないわけではありません - 単に、彼らの注力点が異なるのです。
re:Inventのようなテクノロジーカンファレンスでは、参加者全員がテクノロジー企業で、私たちはそういった企業のために開発しているように見えるかもしれません。しかし実際には、世界のほとんどの企業はソフトウェアテクノロジー企業ではなく、多くの人々はこのソフトウェアテクノロジーを活用したいと考えながら、別の難しい課題に取り組んでいるのです。これは私たちに一つの課題を投げかけます。なぜなら、すべての企業が先進技術を活用して自社のミッションを推進し、コストを削減し、イノベーションを加速させるべきだと考える一方で、ほとんどの企業はテクノロジー企業になる必要はないはずだからです。
むしろ、専門のテクノロジー企業やソフトウェアコミュニティが構築したツールを活用することで、イノベーションを加速させ、コストを削減し、社会に提供する商品やサービスの品質を向上させることができるはずです。私たちがre:Inventのようなカンファレンスを愛する理由は、未来への展望を示してくれるからです。今まさにここにある素晴らしい新しいものを手に入れられるという希望を与えてくれるのです。
これが私たちの直面する2つ目の課題です - Kubernetesのようなシステムは、私たちには未来として映りますが、使いこなすのが難しい場合があります。インストールや運用には、専門的な努力と知識が必要です。クラウド上でこれらのシステムを運用するには、多くの時間と専門知識が必要となります。オープンソーステクノロジーを使用する場合は、さらにその傾向が強まることもあります。OSSを適切に構築し活用するには、そのOSSの構築方法や活用方法を理解している人材が必要になることがあります。会社で導入する素晴らしいツールを見つけたと思ったら、すぐにそのツールのメンテナーになり、さらにはプライマリメンテナーになってしまう - ビジネスの焦点がそこになかったにもかかわらず、そのツールの所有者になってしまうのです。
オープンソーステクノロジーの使用を discourage したいわけではありません。実際、オープンソーステクノロジーは素晴らしいイノベーションだと考えており、AWSのような企業もお客様もOSSに貢献すべきだと考えています。しかし、規模が大きくなるとOSSのコストが高くなる可能性があるという問題があります。これは私たちがお客様のサポートを通じて改善したい点であり、より簡単にしたいと考えている部分です。これはバランスの問題です - スタートからスケールまで、どのようにコントールと柔軟性を保つのか？スケールとコントロールを維持しながら、変更のスピードとスケールのバランスをどう取るのか？このシステムのトリレンマについて、私たちは多くの場合、これら3つの要素のうち2つしか選べないと考えています。
私たちは、これらすべてのレベルでお客様のために最適化を図りたいと考えています。Amazon EKSのミッションは、このトライアングルをもう少し大きくすることです - トレードオフや選択は依然として必要ですが、より最適化され、それらのトレードオフをより苦痛の少ないものにしたいと考えています。これが私たちの目標です：お客様とともにより速く、より遠くへ進むことです。AWSの強みは、安全で、レジリエントで、スケーラブルな運用にあります。ソフトウェアテクノロジー企業であっても、非常に重要な事業を行う大多数の企業であっても、私たちのミッションは、専門家になる必要のない複雑なツールによって価値実現までの時間を短縮し、AWS、パートナー、コミュニティからのイノベーションを民主化し、スタックのあらゆる側面でCAPEXをOPEXに転換することで参入コストを下げることです。
数年前、私はこれに似たスライドを見せました - これがAmazon EKSの journey（道のり）です。私たちはホステッド型のControl Planeから始まり、その後マネージド型のData Planeを導入し、Auto Modeでさらにマネージド化を進め、マネージド運用ツールも提供しています。そのミッションは変わっておらず、EKSの全体的な戦略も変わっていませんが、お客様のニーズは進化していることがわかりました。皆様は常により良いものを求めています。
少し視野を広げてみましょう。ここにはもっと多くのことが関係しています - 最初に示したように、Kubernetesはクラスターだけではありません。もはや単一のクラスターだけを運用している人はほとんどいません。多くのクラスターを運用しています - 私が話す人々は少なくとも5つ、おそらく10個、時には何百ものアカウントにまたがって何千ものクラスターを運用しています。彼らは、それらのクラスターを、集中管理、可観測性、ガバナンス、アクセス制御、構成管理、デプロイメントを備えたプラットフォームとして統合したいと考えています。そして、テンプレート、コード化されたベストプラクティス、ドキュメント、運用手順書など、開発者やデータサイエンティストがアプリケーションを最適な場所にデプロイするために必要なすべてを、美しいパッケージにまとめたいと考えています。それがクラウド上の高性能なTRN2やNVIDIA GPUインスタンスの群れであれ、数千のエッジロケーションであれ、すべてをAWSの支援を受けてシームレスに管理したいと考えています。
これは私たちの考えている方向性の予告です - 今年、私たちはハイブリッドを統合しました。どのようにしてプラットフォームコンポーネントをさらに取り入れていくか？どのように統合された開発エクスペリエンスを提供するか？これらは今後数年間の投資の優先事項であり、まさにこれを実行していきます。あらゆる規模で重要なワークロードパターンに最適化されたエクスペリエンスを提供します。管理と効率性のためのAWS統合とツールをさらに深化させます。これを行う際の目標は、クラウド上の複数のリージョン、Local Zones、オンプレミスのデータセンター、あるいはエッジのいずれであっても、お客様のワークロードがある場所で対応することです。プラットフォームの構築を簡素化し、AWS上で本番環境グレードのKubernetesベースのプラットフォームを容易に構築できるようにし、最後にコミュニティでのイノベーションのフライホイールを加速させます。
オープンソースは、私たちの活動の多くを支える原動力です。私たちは、そのイノベーションを推進し、新しいイノベーションを開発し、その一部となり、さらにそれをお客様が使用したい各コンポーネントの深い専門家になる必要なく簡単に利用できるようにしたいと考えています。
お客様のために、クラスター内外でより多くの処理をネイティブに自動化し、Kubernetesを通じて最新の AWSイノベーションをお届けし、Kubernetesを革新的かつパワフルにするコミュニティプロジェクトとの互換性とサポートを確保したいと考えています。そして、本日ご来場またはご視聴いただいている多くのパートナーの皆様に向けては、Amazon EKSを基盤とした製品やサービスの開発をより容易にしたいと考えています。EKSのお客様へのサービス提供を可能にし、AWSと共同でお客様への販売を行い、製品改善とパートナーシップ向上のための継続的なガイダンス、サポート、アイデアを提供する、シンプルな道筋をご用意したいと思います。
Amazon EKSの開発方針とリソース
この講演は未来についてのものなので、難しいものとなっています。私たちが取り組んでいることについて詳しく説明するのは難しいのですが、常に次に何をすべきかを深く考えていることはご理解ください。どこまで共有し、どこまで控えめにするかのバランスが重要で、それは変更の可能性があることを知っているからです。なぜ変更されるのでしょうか？それは、私たちのロードマップと計画が完全にお客様からのフィードバックに基づいているからです。すべてはお客様のフィードバックに基づいて構築されています。お客様が本当に求めているものであり、価値があるという良いデータがなければ、私たちは単にそれを構築しません。
開発を始める際、お客様とコミュニケーションを取り、実験を行います。もしお客様が価値を見出せない場合は、変更するか中止して、お客様が求めているものを構築します。このプレゼンテーションの前半では、新しい機能について多く説明しましたが、それらの一つ一つがお客様からの要望によって実現したものです。そして、私が示した各スライドに対して、検討はしたものの、お客様との対話の中で有用性が低いと判断して実現に至らなかったプロジェクトが5つほどあります。
つまり、Amazon EKSの未来を理解するためには、皆様が私たちと同じくらい重要な存在であることを知っていただく必要があります。そして、Kubernetesをスタックの標準的な部分として扱いやすくするための取り組みを続けていきます。Kubernetesは今年で10周年を迎えましたが、10年後の私たちのミッションは、Kubernetesを意識させないようにすることです。これを裏付けるものとして、コンテナのパブリックロードマップがあります。ここでは、私たちが検討中または作業中の項目を公開しており、皆様がアイデアを提案してチームと直接対話することができます。この素晴らしい取り組みについて話すだけでなく、実際の利用状況を確認したかったので集計してみました。2018年の開始以来、ロードマップ上で400以上のEKS関連項目を実装し、すべてのコンテナサービスを合わせると850以上の項目が実現されています。
このロードマップを定期的にご確認いただくことをお勧めします。他の方々の意見を確認したり、実装してほしい機能に投票やコメントをしたり、より良いアイデアがあれば提案したりすることができます。EKSの課題にはEKSタグが付けられていますが、他のコンテナサービスの課題も確認でき、そちらについてもアイデアの提案や議論への参加を歓迎しています。Amazon EKSについてさらに学びたい方のために、チームが素晴らしいリソースを用意しています。最近、機械学習のベストプラクティスが追加されたEKS Best Practices Guideがあります。また、EKS Workshopもあります。re:Inventでは、EKS Workshopに参加された方もいらっしゃるかもしれません。EKS Workshopは、これらすべてのワークショップやイベントのメインサイトとなっています。re:Inventでワークショップに参加できなかった方は、ぜひチームの皆様とともにこちらをご確認ください。さらに、EKS Blueprintsでは、Amazon EKSを使用して完全なクラスターや、最近ではプラットフォームまでもデプロイする方法のベストプラクティスを、TerraformとAWS CDKの両方でコード化した例を提供しています。本日は皆様にお時間をいただき、私とHyeからEKSの取り組みについてご説明させていただき、ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion