re:Invent 2023: Amazon EKSの内部構造 - 高可用性と大規模運用の秘訣
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2023 - Inner workings of Amazon EKS (CON327)
この動画では、Amazon EKSの舞台裏を詳しく解説します。Kubernetesクラスターの高可用性、スケーラビリティ、セキュリティをどのように実現しているのか、その秘密に迫ります。ETCDの管理やplatform versionのリリース戦略など、大規模な運用ならではの課題と解決策を紹介。さらに、APIサーバーの監視やAPI Priority and Fairnessの活用など、実践的なベストプラクティスも学べます。Kubernetesの運用に携わるエンジニアにとって、貴重な知見が満載のセッションです。 ※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
本編
Amazon EKSの概要とKubernetesの課題
皆さん、おはようございます。私たちが舞台に上がるキューは音楽がフェードアウトすることだったのですが、舞台に上がったら次の曲が始まってしまいました。少し早かったようですが、おはようございます。皆さんにお越しいただき、うれしく思います。re:Inventを楽しんでいただき、多くの有益な学びを得られていることを願っています。本日は「Inner Workings of Amazon EKS」のセッションにご参加いただき、ありがとうございます。私はVipin Mohanと申します。Amazon EKSチームのprincipal product managerを務めています。同僚のVipul Sabhayaも一緒です。彼はAmazon EKSのsenior software development managerです。私たちは密接に協力して仕事をしています。
Kubernetesはコンテナを大規模に実行するための素晴らしい方法です。Kubernetesの仕組みは驚くべきものですが、Kubernetesの管理には多くの労力が必要です。Kubernetesの管理に費やす時間とエネルギーは、価値を提供し、エンドカスタマーを喜ばせることから奪われる時間です。このセッションでは、Amazon EKSでマネージドサービスとしてKubernetesを運用する方法について、舞台裏をお見せします。高可用性と信頼性を提供し、ビジネスクリティカルなアプリケーションを実行するための安全な環境を提供し、差別化されない重労働を私たちに任せながら、ビジネスアプリケーションを実行する自信と回復力を提供する方法の概要をお話しします。
本日のアジェンダについてですが、まずAmazon EKSとは何かについて簡単に紹介し、Kubernetesアプリケーションにおいてなぜ Amazon EKSを使用すべきかについてお話しします。また、お客様からお聞きしたEKSの使用事例についてもお話ししたいと思います。次に、Kubernetesのバージョンとアップグレードについて時間を割きます。うなずいている方が見えますね。Kubernetesのアップグレードは複雑なので、EKSがどのようにアップグレードを支援するかについてお話しします。そして、EKSのアーキテクチャについて深く掘り下げていきます。その後、Vipulに引き継ぎ、EKSがビジネスアプリケーションのニーズに応じてスケールアップ、スケールダウンする方法や、回復力を提供し、データセンターのインシデントにどのように対応するかについて説明します。最後に、ベストプラクティスと今後のフォローアップのポイントをお伝えし、まとめと総括で締めくくります。
簡単なアンケートをとりましょう。同時中継の部屋もあると思いますが、この部屋では挙手で確認し、感覚をつかみたいと思います。皆さんのKubernetesの導入段階について知りたいと思います。3つの選択肢があります。一つずつ確認していきますので、挙手をお願いします。まず、Kubernetesを始めたばかり、あるいは組織がKubernetesに興味を持ち、評価中という方は挙手をお願いします。部屋の約20%くらいですね。次に、Kubernetesにどっぷりつかり始めている方、テスト用のワークロードを実行し始めている、あるいは少数の本番ワークロードがある方は挙手をお願いします。はい、少し多いですね。30〜40%くらいでしょうか。最後に、EKS上で複数の本番ワークロードを実行しており、Kubernetesのエキスパートという方は挙手をお願いします。おお、これが多数派ですね。部屋の50%くらいです。素晴らしい。今日のセッションから皆さんが何か持ち帰るものがあることを願っています。
Amazon EKSの特徴とKubernetesの管理における課題
では、Amazon EKSについて簡単に紹介します。EKSとは何でしょうか？まず、Kubernetesの概要から始めましょう。Kubernetesはコンテナオーケストレーションソフトウェアです。オープンソースで、コンテナ化されたアプリケーションをデプロイし、任意のスケールでワークロードを実行することができます。EKSは内部で純粋なKubernetesを実行しています。つまり、アップストリームのコードベースをフォークしていません。EKSはアップストリーム準拠の認証を受けており、すべてのアップストリーム準拠テストに合格しています。また、セキュリティ修正をすべて適用およびバックポートしているので、EKSで安全なKubernetes環境を実行する安心感が得られます。EKSは常に最大6つのKubernetesバージョンをサポートしています。実は、ここ数ヶ月でこの数を増やしました。以前は4バージョンでしたが、現在は最大6バージョンをサポートしています。では、Kubernetes環境の管理においてAmazon EKSがなぜ有益なのか、詳しく見ていきましょう。
Amazon EKS は、高性能で信頼性が高く、安全な Kubernetes 環境を管理された形で提供します。EKS の目標と使命は、Kubernetes の運用と管理をシンプルで退屈なものにし、お客様がエンドユーザーに価値を提供することに集中できるようにすることです。では、なぜ Amazon EKS なのでしょうか？Kubernetes はコンテナ化されたアプリケーションのデプロイと管理を簡素化しますが、大規模な Kubernetes の管理は困難です。専門知識が必要で、Kubernetes のアーキテクチャ全体を理解し、環境で Kubernetes を使用する方法、そしてニーズに合わせた規模で Kubernetes アプリケーションをデプロイし管理する方法を実際に理解するためのチームを配置する必要があります。これらすべては、エンドユーザーに価値を提供することから離れて費やす時間です。
では、大規模な Kubernetes の運用における課題には何があるでしょうか？まず、スケーラビリティの側面があります。高可用性とパフォーマンスを維持しながら Kubernetes クラスターを効率的にスケーリングすることは、簡単な作業ではありません。クラスターがビジネスクリティカルなアプリケーションの変化するニーズに応じてシームレスにスケールできることを確認する必要があります。次に、セキュリティリスクの側面があります。Kubernetes はオープンソースソフトウェアであり、Kubernetes にセキュリティの脆弱性が存在する可能性があります。私たちが関与している Kubernetes コミュニティは、これらのセキュリティ問題や脆弱性の修正に取り組んでいます。しかし、これらの修正を取り込み、Kubernetes コンポーネントに適用する必要があります。
Kubernetes クラスターを自己管理している場合、複雑さと学習曲線の側面もあります。独自の Kubernetes コントロールプレーンを管理したい場合、Kubernetes の専門知識を持つチームを設置して、コントロールプレーンの管理だけでなく、運用も処理する必要があります。モニタリングやアラートを設定し、スケーリングイベントにどう対応するかを決定する必要があります。これらすべてには急な学習曲線が必要で、ビジネスにとって時間がかかる可能性があります。Kubernetes を自己管理する運用上のオーバーヘッドは、チームにとって大きな課題となる可能性があり、継続的な運用と管理のためにリソースと時間を割く必要があります。
Amazon EKSのアーキテクチャと高可用性の実現
Kubernetes クラスターを管理する際には、高可用性をどのように提供し、災害復旧システムをどのように整備するかも考慮する必要があります。災害復旧計画を確実に立て、環境で高可用性をどのように実現するかを考えることは、かなり複雑な作業であり、再びビジネスクリティカルなアプリケーションから時間を奪うことになります。私たちの核となる原則は、前のスライドで話したいくつかのトピックと結びついています。セキュリティは AWS の最優先事項であり、それは EKS にも当てはまります。私たちの主な目標は、お客様が安全な環境でアプリケーションを実行できるようにすることです。
EKS は本番環境向けに構築されています。私たちは、本番環境やミッションクリティカルなワークロードを実行するために使用できるマネージドサービスを提供しています。ヘルスケア、製造業、金融サービスなど、さまざまな分野のお客様が EKS 上でミッションクリティカルなワークロードを実行しています。スピード、スケール、信頼性が重要な側面です。これについては、いくつかの観点から考えることができます。一つは、EKS インフラストラクチャ自体がお客様のニーズにどのように対応するかです。アプリケーションの需要が突然急増した場合、コントロールプレーンはそのニーズにどのように対応してスケールするでしょうか？エンドユーザーに対して、可能な限り最小のレイテンシでどのようにエクスペリエンスを提供するでしょうか？
私たちはコミュニティにどれだけ迅速に対応しているかということも示しています。私たちはアップストリームコミュニティと密接に関わっています。例えば、セキュリティ委員会のメンバーであり、さまざまなワーキンググループでリーダーシップを発揮しています。セキュリティの脆弱性が発見されるたびに、私たちは即座に対応し、多くの場合、一般に公開される前に修正を行っています。EKSはアップストリームに準拠しており、最新バージョンのKubernetesをEKSで提供することにコミットしています。また、EKSとKubernetesを使用してソフトウェアのコンピューティングを最適化するお手伝いもしたいと考えています。
結局のところ、アプリケーションはコンピューティングインスタンス上で動作しますが、アプリケーションを実行するために必要なCPUやメモリなど、コンピューティングインスタンスの適切なリソースを見極める必要があります。過剰にプロビジョニングすることもできますが、それは特定のインスタンスのリソースを十分に活用せずに、より多くの費用を支払うことになります。そこで、コンピューティングを最適化する方法を開発しています。
Amazon EKSの利用事例と適用分野
では、お客様はEKS上で何を構築しているのでしょうか？製造業、ヘルスケア、金融サービスなど、さまざまな業界や分野のお客様がEKSを利用しています。政府機関もEKSをさまざまなユースケースで使用しています。その中には、レガシーアプリケーションのモダナイゼーションもあります。これは、オンプレミスからクラウドへアプリケーションを移行するお客様のことです。モノリシックなアプリケーションをモダナイズし、マイクロサービスに分解する過程で、コンテナ化されたワークロードの実行にEKSを選択しています。
AI/MLは、過去12〜15ヶ月間、EKSとお客様にとって主要な焦点となっています。自動運転車などのユースケースでは、お客様がEKSを使用してオブジェクトトラッキングやロボティクスにおけるコンピュータビジョンを実行しています。AI/MLのユースケースを考えると、モデリング、トレーニング、推論という側面があります。まずモデルを構築し、そのモデルをデータでトレーニングし、そしてそのモデルから推論を導き出します。私たちには、これらすべてのアプリケーションやユースケースでEKSを使用しているお客様がいます。
データ処理は、お客様がEKSをよく利用されるもう一つの一般的なユースケースです。ストリーミングのユースケースや、大規模な分析のユースケースを考えてみてください。金融サービスや医療など、大量のデータを処理する必要がある分野が該当します。また、バックエンドシステムにもよく使われます。皆さんの多くはスマートフォンをお持ちだと思いますが、スマートフォンで動作しているアプリケーションの少なくとも1つ以上が、バックエンドにEKSを使用している可能性が高いですね。さらに、IoT（Internet of Things）のユースケースにも適用されます。そして、Webアプリケーションは、EKSの登場当初から非常に一般的なユースケースとなっています。シンプルな静的Webサイトから複雑な動的Webサイトまで、幅広く利用されています。
Amazon EKSの展開範囲とバージョン管理
5年ちょっと前にEKSを立ち上げた当時、EKSはクラウドにおけるマネージドサービスでした。それは今でも変わりませんが、多くのお客様から、クラウドでアプリケーションを実行できないユースケースがあると聞かされました。一部のお客様は、地理的な制約など、ワークロードを実行できる場所を規定する政府の規制があると教えてくれました。また、データ主権のニーズから、自分たちの地理的位置により近い場所でEKSを実行したいというお客様もいました。
そこで数年前、Local ZonesでのEKSの提供を発表しました。Local Zonesは基本的に、お客様の地理的位置により近い場所で利用可能なAWSのインフラストラクチャです。AWS Wavelengthも同様のユースケースですが、こちらは5GとTelcoのユースケースにより焦点を当てています。これらは、アプリケーション全体が通信サービスプロバイダーのネットワークから出ることのないユースケースです。AWS Outpostsは、ご存じない方のために説明すると、AWSが管理するハードウェアです。オフィスやデータセンターにサーバーラックのセットを設置でき、これらは計算用のラックです。このOutpostsのインスタンス上でEKSを実行できます。ハードウェアはAWSが管理し、お客様はそのOutpostsインスタンス上でEKSを実行できるのです。
最後に、近い将来に期限切れとならない長期のデータセンターリースを抱えているものの、現在の環境でアプリケーションをモダナイズしたいというお客様もいました。そこで、EKS AnywhereというオンプレミスでのKubernetes実行のためのオープンソースソリューションを提供しています。ここでの共通のテーマは一貫性です。EKSをどこで実行していても、同じKubernetesのコンポーネントと、Kubernetesクラスターを実行するための同じツールセットが得られます。そして、準備ができたら、いつでも自由に異なる環境間を移動できるのです。
Amazon EKSのコントロールプレーンとデータプレーン
AWSは世界中の様々な地域にグローバルな展開をしており、EKSは30の商用リージョンで利用可能です。今年は、チューリッヒ、ハイデラバード、メルボルン、テルアビブ、そしてスペインの5つの商用リージョンをサポートに追加しました。
さらに多くのリージョンが追加される予定です。私たちは常に新しいリージョンを構築しており、それらすべてのリージョンでEKSを利用可能にしたいと考えています。それに加えて、リストを見ていただくとわかるように、EKSは南北アメリカ、ヨーロッパ、中東、アジア太平洋、アフリカ、そして中国にわたる地域で利用可能です。多くのお客様、特に政府機関は、GovCloudリージョンでEKSを運用しています。
ETCDの重要性とAmazon EKSでの管理
皆さんの中で、一般的にKubernetesのアップグレードで問題を経験した方はどれくらいいらっしゃいますか？これは、多くのお客様から頻繁に聞かれるトピックです。よく耳にする共通のテーマとして、EKSがサポートするバージョンの一貫性を求める声がありました。今年、私たちはそれを実現しました。非常に嬉しいことに、現在、私たちは上流のKubernetesバージョン1.28まですべてのバージョンに追いついています。Kubernetes 1.28はすでにEKSで利用可能であり、1.29は来週、たしか12月5日にコミュニティによってリリースされる予定です。私たちは数週間、場合によっては数ヶ月前から1.29の取り組みに関わってきました。
アップグレードに関して、皆さんからKubernetesクラスターのアップグレードには多くの複雑さがあると聞いています。継続的にアップグレードのためのリソースを確保する必要があり、常に優先順位の競合があります。アップグレードとビジネスの優先事項の間で選択しなければなりません。私たちは、これは明白な選択であるべきだと考えています。ビジネスの優先事項が常に皆さんにとって勝るべきです。アップストリームのコミュニティは4ヶ月ごとに新バージョンをリリースしており、これはかなり速いペースです。
私たちが皆さんに応えてきた方法、特に今年発表したいくつかの事柄については、バージョンのローンチに一貫性を持たせてきました。今年はEKSで多くのバージョンをローンチし、1.28が最新です。また、Extended Supportと呼ばれるものを発表しました。これについては後ほど詳しくお話しします。さらに、プレフライトチェックという機能をまもなく発表する予定です。これにより、アップグレードボタンをクリックする前に、将来のKubernetesバージョンでどのAPIが非推奨になるかを把握できます。アイデアとしては、実際にプロセス全体を経て何かが壊れることを発見する前に、アップグレードを実行する自信を得られるということです。ロードマップにはさらに多くのものがあり、後ほど説明します。
アップストリームのローンチに関しては、長期サポート（LTS）についての議論がありました。私たちはそれらのワーキンググループに参加しています。そのワーキンググループには製品とエンジニアリングの両方の代表者がおり、共同議長を務めています。簡単にまとめると、EKSは現在1.23から1.28までのバージョンをサポートしています。 1.24から1.28のバージョンは標準サポートです。Extended Supportは新しく発表したもので、1.23は現在Extended Supportの対象です。今後、すべてのバージョンがExtended Supportを受けることになります。1.22までのKubernetesバージョンについてExtended Supportを提供しています。
今年10月に発表したAmazon EKSの延長サポートについてお話しします。上流のコミュニティでは、Kubernetesのバージョンを12〜14ヶ月間サポートしています。12ヶ月のフルサポートと2ヶ月のパッチサポートです。私たちはこれをEKSのすべてのお客様向けに26ヶ月に延長しました。標準サポート14ヶ月に加え、コントロールプレーンコンポーネント、デフォルトのアドオン、そしてすべてのAMIに対して12ヶ月のセキュリティパッチを提供します。現在、バージョン1.23に対して無料のプレビューが利用可能で、今後のKubernetesの全バージョンで利用できるようになります。この機能の正式リリースは2024年初頭を予定しています。延長サポートには料金が発生しますが、詳細は正式リリース時に公開されます。
Amazon EKSのリリース戦略と大規模運用
EKSアーキテクチャの概要を説明します。EKSはリージョナルサービスです。Kubernetesクラスターにアクセスするためのリージョナルエンドポイントがあります。図のオレンジ色のボックスがEKSインターフェース、つまりEKS APIです。このEKS APIを通じてアクセスし、内部ではVanilla Kubernetesを実行しています。クラスターが稼働すると、すべてのkubectlコマンドが使用可能になります。クラスター内でKubernetes APIを使用できます。上流と同じAPI Server、kube-controller-manager、kube-schedulerを実行しています。Kubernetesクラスターが稼働すると、多数のAWSサービスと統合できます。DynamoDB、EMR、IAMなどがあり、オープンソースソフトウェアも利用できます。
PrometheusとGrafanaは、よく使用されるオープンソースソフトウェアの例です。Kubernetesと互換性のあるオープンソースソフトウェアは、EKSでシームレスに動作します。なぜなら、EKSは内部でVanilla Kubernetesを使用しているからです。それでは、EKSアーキテクチャの詳細についてVipulに説明を譲ります。
ありがとう、Vipin。ここからは、EKSの動作、Kubernetesの運用方法、そしてサービスの様々な側面について、より深く掘り下げていきます。まずはControl Planeアーキテクチャから始めましょう。 Kubernetes Control PlaneはAWSによって完全に管理されています。ゾーン冗長性があり、最低2つのゾーンにAPI serverがあり、3つのゾーンにetcdがあります。これらのインスタンスはそれぞれプライベートVPCにあるため、VPCレベルの分離が実現されています。クラスターへのパブリックエンドポイントにはNetwork Load Balancerを使用し、NLB内のトラフィックはゾーンに分離されています。そのため、トラフィックがゾーンに入る際にクロスゾーンの影響はありません。
さらに、99.95%のSLAと24時間365日のサポートを提供しています。最も重要なのは、EKSがetcdを管理してくれることです。自分で運用する場合、これが最も複雑な部分になるでしょう。 データプレーンはアプリケーションが実行される場所で、お客様のアカウントとVPC内に存在します。当初は自己管理ノードから始まりました。これは、ワーカーノードをスピンアップし、そのノードがクラスターに参加し、Kubernetesがそのノードにアプリケーションをスケジュールするというものです。EKS最適化AMIを提供しており、このAMIでインスタンスをスピンアップすると、そのインスタンスがクラスターに参加します。これは現在もサポートされていますが、アップグレードの実行、ノードの調整とドレイン、ポッドの退避などの複雑さを管理する必要があります。
その後、EKS Managed Node Groupsをリリースしました。 これは依然として、お客様のアカウントやVPC内にキャパシティが存在する形態です。Auto Scaling グループに属していますが、EKSがアップグレードや、ノード上のポッドの優雅な終了、そして別のノードへの移動といった面倒な作業の一部を担当します。また、Fargateによるサーバーレスオプションも追加しました。 FargateはAWSが管理するコンピューティングで、完全に私たちが管理します。お客様がすべきことは、ポッドにアノテーションを付けて、このポッドをFargateで実行したいと指定するだけです。現在のFargateモデルでは、1ノードに1ポッドが配置されます。つまり、Fargateにポッドをスケジュールすると、裏側でノードを起動し、そのノード上にポッドをスケジュールします。
最後に、Karpenterを構築しました。これは次世代のAutoscalerの私たちのバージョンです。 Karpenterはオープンソースで、最近CNCFに寄贈しました。これにより、オンデマンドインスタンス、スポットインスタンス、その他のインスタンスタイプなど、ワークロードに適したインスタンスタイプを柔軟に選択できます。また、コスト削減にも役立ちます。実際に行っているのは、コンテナの再配置です。ワーカーノードに空きがある場合、できるだけ詰め込もうとし、それらのノードを削除する機能を提供します。これにより、過剰なプロビジョニングに対して支払う必要がなくなります。
Kubernetesクラスター管理のベストプラクティス
Karpenterは、ノードを自動的に置き換えるオプションも提供します。Control Planeやワーカーノードのパッチ適用が必要な場合、Karpenterが自動的にこれらをリサイクルするので、OSのパッチ適用が自動的に行われます。では、このアーキテクチャがどのように私たちにとってより良いレジリエンシーをもたらしたかについて話しましょう。 複数のAvailability Zone（AZ）にまたがってAPIサーバーとetcdを配置するゾーン冗長性について話しました。 AZがダウンすることは周知の事実であり、私たちの目標はそのような事象の影響を最小限に抑えることです。
私たちの目標は、1つのゾーンがダウンしてもクラスターに全く影響を与えないことです。 では、これについて私たちは何をしているのでしょうか？どのようにしてそれを達成するのでしょうか？少し詳しく説明したいと思います。Amazon EKSを長年運用してきた結果、 ゾーン障害は複雑だという結論に達しました。実際には、リージョン内のキャパシティにどのような影響を与えるかによって様々です。Availability Zone（AZ）が完全にダウンする場合もあれば、部分的にダウンする場合もあります。AZ内の一部のラック間でネットワーク障害が発生した場合、これはレイテンシーの増加やスループットの低下として現れる可能性があります。これらは必ずしも完全な障害を意味するわけではありません。クラスターに影響を与える可能性のある障害モードは多岐にわたるため、私たちはこれについて慎重に検討する必要があります。
過去10年間で膨大な経験を積んできました。障害が発生するたびに、深く掘り下げ、何が起こったのか、そして障害を最小限に抑えるために何ができるかを分析します。これらの学びを活用して、より信頼性の高いKubernetesエクスペリエンスを効果的に提供し始めています。私たちが実装したのは、決定論的レジリエンシーです。これは何を意味するのでしょうか？AZにどのような種類の障害モードがあっても、 決定論的な結果を提供したいと考えています。つまり、シームレスなAPIエクスペリエンスを提供し、単なる稼働時間だけでなく、レイテンシーなどのパフォーマンス面でも、障害がない場合と同じように動作し続けることを意味します。また、Kubernetesのコントローラーワークフローに対して、中断や遅延が発生しないようにしたいと考えています。
では、実際にどのように対処するのでしょうか？まず、すべての更新を一時停止します。既存のキャパシティを維持することが目的です。不健全なAZから健全なAZへ、API serverへのすべてのトラフィックを移動させます。 これは外部からのクライアントトラフィックだけでなく、長時間実行される接続、watches、exec proxy、そしてKubernetes APIがサポートするすべてのものを含みます。これらはもはや不健全なAZには向かいません。また、すべてのバックエンドコントローラーのリーダーを健全なAZに移動します。不健全なAZにあるリーダーが必要な操作を実行できるかどうかわからないからです。etcdのリーダーも不健全なAZから健全なAZに移動させます。不健全なAZにリーダーがいた場合に、すべての書き込みが影響を受けないようにするためです。
これらの機能の一部をお客様のアプリケーションにも提供できるよう取り組んでいます。ワーカーノードで実行されているものについては、「アプリケーションをあるゾーンから退避させたい」と指定できるAPIを導入する予定です。これは来年中に利用可能になる予定です。 ここで、私たちが実装したいくつかのことと、それらが正しく機能していることをどのように示しているかをデモンストレーションしたいと思います。障害時の最優先事項は、私たちが「静的安定性」と呼んでいるものです。障害が発生した場合、既存のクラスターが影響を受けないようにすることが目標です。これには、ほぼすべての依存関係を検討し、それらの障害モードに対応するアーキテクチャを設計する必要があります。
Amazon EKSの障害対応と信頼性向上の取り組み
私たちは障害が発生するのを待つのではなく、本番環境でシミュレーションを行います。ネットワーク障害やdependency servicesへの呼び出しの阻止など、さまざまな種類の障害モードを注入します。 また、ヘルスチェックの失敗やパケットドロップ、さまざまな障害モードをシミュレートして、実際に冗長性があり、あるゾーンから離れて障害に対応できることを確認します。最近では、おそらく皆さんもご存知だと思いますが、9月28日にUS-EAST-1で障害が発生しました。これはゾーン単位の障害でした。ゾーン全体が影響を受けたわけではなく、ゾーン内の一部のラックのみが影響を受けた典型的なグレー障害でした。さらに言えば、そのゾーン内の一部のラックの部分的な障害でした。
この障害の際、私たちは根本原因分析を行いました。その障害における私たちのパフォーマンスを詳細に分析し、最大規模のリージョンでの影響を軽減しました。お客様は影響を受けませんでした。これは、最大規模のリージョンにある何十万ものクラスターに対してのことです。
Amazon EKSのスケーラビリティとパフォーマンス
では、コントロールプレーンのスケーラビリティについて見ていきましょう。Amazon EKSは、適切なサイズのコントロールプレーンを提供するために、クラスターを自動的にスケールします。私たちは常にメモリ、CPU、ノード数、ETCDのシグナルなどを監視しています。これらすべての総合的な評価に基づいて、最大値を決定し、クラスターをその最大値までスケールします。クラスターのスケーリングには約10分かかりますが、具体的にどのような操作が行われるかによって異なります。ETCDをスケールする必要があるか、単にAPIサーバーをスケールするだけでよいかによって、個別に対応します。
私たちは垂直スケーリングを行っており、水平スケーリングのサポートも追加しています。スケーリング操作の一環として、コントロールプレーンの様々なパラメータも調整します。例えば、max requests in flightを調整して、クラスターのスケールに応じてより多くのスループットを得られるようにします。また、スケジューラーやController ManagerなどのコンポーネントのQPSも調整し、クラスターがスケールアップした際により多くの作業を処理できるようにします。
Kubernetesの長期的な接続の性質上、私たちは「Go Away Chance」と呼ばれるものを実装しています。これはKubernetesの一部です。実際には、時間の経過とともにこれらの長期的な接続がインスタンス間のトラフィックの不均衡を引き起こします。そこで、私たちはこれらの接続をランダムに切断し、クライアントが再接続を試みると、おそらく別のAPIサーバーに接続されることになります。
EKSは、常にスケールテストを行い、お客様の要求を満たすか、それ以上のパフォーマンスを発揮できるようにしています。私たちは、アップストリームのClusterLoader2フレームワークを活用してスケールテストを実行しています。また、お客様から学んだことに基づいて、これらのClusterLoader2テストを改善しています。例えば、最近CRDのサポートを追加しました。なぜなら、ポッドなどをリストアップするよりも、CRDをリストアップする方がはるかに大きなペナルティがあるからです。
また、AWSで上流の5Kノードテストを実行しており、これらは現在リリースに影響を与えています。これらのテストは、上流のリリースチームにパフォーマンスの低下があるかどうかを示します。私たちは、単に合成テストに頼るのではなく、実際のEC2インスタンスや実際の顧客ワークロードを使用して、本物のノードでテストを行っています。合成テストだけでは、一部の問題が隠れてしまう可能性があるからです。最後に、SIG Scalabilityの一員として、上流が定義した多くのSLOの改善に取り組んでいます。これには、ポッドの起動レイテンシーやネットワーク接続レイテンシーなど、皆さんが気にする項目が含まれています。
Amazon EKSの今後の展望とコミュニティへの貢献
次に、ETCDに移りましょう。Kubernetesクラスターでは、ETCDはクラスターのすべての設定データを保存するために使用されます。これには、ポッド、ネームスペース、およびクラスター内で作成するその他のリソースなど、すべてのオブジェクトが含まれます。ETCDは分散キーバリューストアです。バージョンベースのシステムなので、単にAPIオブジェクトを保存するだけでなく、そのオブジェクトへのすべての更新をETCDクラスター内のリビジョンとして保存します。
ETCDはコンセンサスのためにRAFTを使用しており、クラスターを形成するには3つのノードが必要で、クォーラムを維持するには最低2つのノードが必要です。RAFTは、ETCDが障害耐性と強力な一貫性を提供する秘訣です。RAFTは、リーダーを選出し、すべての書き込みがリーダーに行くようにし、フォロワーが書き込みを行えないようにすることで機能します。高可用性を念頭に設計されており、他のデータベースのように大きく成長できるものとは対照的に、小規模なデータセット向けに推奨されています。なぜETCDがKubernetesにとって重要なのでしょうか？
ETCDはKubernetesの重要なコンポーネントで、クラスターの高可用性と一貫性を確保するために不可欠です。望ましい状態を維持し、変更やイベントを監視するのに重要な役割を果たします。ETCDは障害からの復旧にも役立ちます。Kubernetesの中で最も重要で複雑な部分と言えるでしょう。
Amazon EKSでは、ETCDを3ノードクラスターとして運用しています。EKSはネットワーキングに静的IPを、データストレージに静的ボリュームを使用します。つまり、インスタンスに障害が発生しても同じIPとボリュームが使用されるため、耐久性と災害復旧のシナリオに有利です。EKSではETCDが完全に管理されており、可用性の側面だけでなく、メンテナンスタスクもカバーしています。これには、クラスターのコンパクション（圧縮）とデフラグメンテーション（断片化解消）が含まれ、これらは裏で実行されます。
また、先ほど他のコンポーネントについて説明したのと同じスケーリングロジックをETCDにも適用しています。さらに、定期的にバックアップを取得し、暗号化してS3に保存しています。これらのバックアップは、深刻な問題が発生した場合の復元に使用できます。
2023年、私たちはETCDを静的ボリュームに移行しました。現在は、クラスターごとにAvailability Zone（AZ）ごとに1つのボリュームがあり、ボリュームの寿命はクラスターの寿命と一致します。例えば、AZ1のインスタンスに障害が発生して交換された場合、ボリュームは新しいインスタンスに移動され、そのインスタンスがクラスターにフォロワーとして参加します。この設計により、クォーラムを失った場合でもバックアップから復元する必要がないため、復旧時間が改善されます。ノードがクラスターに参加する際、最初からキャッチアップする必要がないため、障害発生時の復旧がはるかに速くなります。
ETCDは小規模なデータセット、通常10〜12ギガバイト程度を想定して設計されています。このため、ETCDにはデータベースサイズの制限が実装されています。ステータスフィールドの変更などのオブジェクトの更新は、オブジェクト全体のコピーを作成し、データベースに保存します。これには、新しいpodの作成のような新規オブジェクトだけでなく、進行中のすべての変更が含まれます。例えば、1時間続くクラッシュループは、そのオブジェクトの複数のリビジョンを生成し、データベースサイズに影響を与えます。
サイズ制限に達すると、ETCDは「スペースなし」アラームを発し、読み取り専用になります。この時点で、オブジェクトを変更するすべてのリクエストが拒否されます。唯一の対処法は、コンパクション（圧縮）とデフラグ（最適化）ですが、これはリビジョン数がディスク容量の増加を引き起こしている場合にのみ効果があります。実際のオブジェクトが問題の原因である場合、デフラグメンテーションやコンパクションは役に立ちません。今年、私たちは自動回復機能を追加しました。データベースの最大サイズに近づくにつれて、コンパクションとデフラグメンテーションのプロセスを加速する新しいフローを構築しました。
クラスターを自動的に回復できる場合、このプロセスで問題を解決できます。クラスターにスペースなしアラームがある場合、最大15分かかる可能性がありますが、回復ワークフローで解決できれば、15分以内にアラームが解除されます。解決できない場合は、おそらくスペースを解放するためにオブジェクトを削除する必要があります。
さて、ここからはソフトウェアのリリース方法の裏側について少しお話ししたいと思います。 例えば、基盤となるplatform versionの変更などについてです。まず、リリースの影響を最小限に抑える方法から始めましょう。私たちは現在、すべてのAWS Regionで展開しています。 そして各リージョンはセルに分割されています。これらのセルは単なるAWSアカウントであり、クラスターはこれらのセル全体に分散されています。これは決して斬新なアイデアではありません。大規模なサービスであれば、おそらく同様のパターンを採用しているでしょう。重要なのは、セル内のクラスター数を制限することで、影響範囲を効果的に抑えていることです。つまり、セルに何か問題が発生しても、そのセル内のクラスターにのみ影響が及ぶことがわかっています。私たちはセルあたり1,000クラスターの制限を設けており、後ほど説明する段階的なデプロイメントを行って、すべてを安全に実施しています。
platform versionのリリース方法は、 当然ながらパイプラインワークフローのようになっています。アプリケーションの様々なレイヤーでテストを行います。個々のコンポーネントがテストされ、それらがすべてパッケージ化された後に統合テストを行い、最後にエンドツーエンドのクラスターテストを実施します。また、幅広いスペクトルのテストを実行しています：コンフォーマンス、バージョンアップデート、platform versionアップデート、スケーラビリティとパフォーマンステストなどです。テストはパイプラインの各段階で行われます。BetaとGammaの段階では、すべてのリージョンでテストが行われ、次の段階に進む前に実施されます。
私たちのフリートの規模はかなり大規模です。数十万のクラスターについて話しています。これらのクラスターを実行しているインスタンスには、OSのパッチ適用や新しいバージョンのコンテナ、Kubernetesの新しいパッチリリースなどのソフトウェアが必要です。したがって、私たちの課題は、運用しているリージョンとセルの数を考慮しつつ、安全性と速度のバランスを取ることです。適切なバランスを実現するために、AWSが長年かけて進化させてきたデプロイメント戦略を使用しています。これらの各ウェーブにはベイク時間を設けています。この時間はデプロイメントが進むにつれて徐々に短くなります。また、ウェーブの数を指数関数的に増やし、いつでもロールバックできるようにしています。これが、お客様のワークロードに影響を与えることなく、クラスターが新しいplatform versionを受け取る様子を視覚的に表現したものです。
Amazon EKSを5年間運用してきた私たちは、良いこと、悪いこと、ありとあらゆる経験をしてきました。そして、その多くをベストプラクティスに変換してきました。これからそのいくつかについてお話しします。まず、どのように物事が間違った方向に進む可能性があるかについて説明します。 Kubernetesを使用する際には、特定のことを正しく行う共同責任があります。クラスターの設定を間違えるのは非常に簡単で、時にはインストールできるソフトウェアの広大なエコシステムが原因であったり、ベストプラクティスを知らないことが原因であったりします。
私たちは、API Priority and Fairnessによって重要なワークロードが通過せず、本番環境に影響を与えるという問題を目にしてきました。もう一つの典型的な問題は、すべてのリクエストのクリティカルパスにあるwebhooksです。webhooksを適切に設定していないお客様を見かけます。失敗時に閉じる設定になっていなかったり、レプリカが十分でなかったり、ゾーン冗長性がなかったりします。次のスライドでいくつかのヒントをお伝えします。また、クラスター自体に影響を与える不適切なクライアントも見てきました。Kubernetes APIには、キャッシュを活用し、負荷を引き起こさないような適切なクライアントを設計するための様々な方法があります。そこで、これまで議論してきたことを考え、解決するのに役立つベストプラクティスガイドを作成しました。
現在、Prometheusを使用してAPI serverを監視することができますが、これだけでは十分ではありません。実際には監査ログを確認する必要があります。これが私たちのデバッグ方法です。監査ログから始めて、最もコストのかかる呼び出しを教えてくれるクエリを使用します。多数の呼び出しを行っているuser agentやクライアントを特定することで、トップトーカーを把握します。これにより問題を絞り込むことができ、ロギングを有効にしていれば、皆さんも同じことができます。
Kubernetes 1.25以降、API Priority and Fairnessの動作の多くが変更されました。呼び出しパターンを把握し、アプリケーションに適したflow schemaを修正することをお勧めします。適切に動作するクライアントを構築することが重要です。watch、ページネーションされたリクエスト、クラスター全体のリスト呼び出しの排除などの機能を使用してAPI使用を最適化します。namespaceでクエリを行い、field selectorを使用してクラスターの負荷を軽減します。
制限を理解することは重要です。KubernetesとAWSには、正当な理由で至る所に制限があります。これらの制限を尊重するようにアプリケーションをチャート化することをお勧めします。例えば、単一のnamespace内のオブジェクト数や、単一のクラスター内のロードバランサーの数を制限するなどです。最終的には、何らかの制限に達し、影響を受けることになります。 最後に、ガベージコレクションの実装をお勧めします。完了したジョブのクリーンアップにTTLを使用したり、Custom Resource Definitions (CRDs)を削除したりするような簡単なことでも効果的です。CRDを使用してイベント履歴を保持するアプリケーションを見かけましたが、これは良い方法ではありません。これをクリーンアップしてパフォーマンスを向上させてください。
ここで、コミュニティの側面についてお話ししたいと思います。Amazon EKSで行うすべての作業は、コミュニティとのパートナーシップによるものです。今年、私たちはupstreamのレジストリをregistry.k8s.ioに移行しました。これはAWS上のAmazon Elastic Container Registry (ECR)で動作しています。また、私たちはLong Term Support (LTS)ワーキンググループの一員として、extended supportの定義に取り組んでいます。 セキュリティ委員会にも複数のメンバーを送り込んでいます。さらに、リリースやテストインフラのジョブの多くをAWSに移行しました。これは、AWSクレジットを通じてコミュニティをサポートするという私たちのコミットメントに沿ったものです。
私たちはこれ以外にも、Kubernetes Enhancement Proposals (KEPs)やバグ修正への貢献など、多くの活動を行っています。私たちの目標は、これらのクラスターを管理することで得た運用経験を活かし、upstreamプロジェクトに影響を与えることです。では、Vipinに戻します。
まとめとして、私たちが取り組んでいることをいくつか紹介したいと思います。私たちは、お客様の運用上の課題を解決することに投資しています。Amazon EKSによって、私たちがどれだけの差別化されていない重労働を取り除いているかをご理解いただけたと思います。私たちは、より多くのアドオン運用ソフトウェアを管理することで、その取り組みを続けています。また、クラスターのテレメトリーと可観測性についてより良い可視性が欲しいという声も聞いており、これにはコントロールプレーンのメトリクスとログへのより良いアクセスも含まれます。
私たちのお客様は、Kubernetesの導入において様々な段階にあります。設定を細かく調整する柔軟性を好む方もいれば、クラスターを立ち上げるための意見を取り入れたテンプレートを求める方もいます。私たちは、これらのオプションをお客様に最適な形で提供する方法を模索しています。また、クラスターの効率性とフリートレベルの運用作業を常に改善し、お客様に素晴らしい体験を提供することで、お客様が最終的にエンドユーザーに素晴らしい体験を提供できるよう努めています。
GitHubに公開ロードマップを掲載しています。AWSで行うすべてのこと、そしてAmazon EKSチームの活動は、お客様からのフィードバックに基づいています。私たちは、お客様の声から逆算して作業を進めています。ですので、GitHubのロードマップを通じて、Amazon EKSに何を期待しているか、そしてその将来をどのように形作りたいかをぜひお聞かせください。改めて感謝申し上げます。Amazon EKSの舞台裏の仕組みと、Kubernetesクラスターを自己管理した場合に負担することになる運用オーバーヘッドについて、ご理解いただけたことを願っています。
私とVipulのLinkedInプロフィールをご覧いただけます。LinkedInで気軽にご連絡ください。また、このセッションについてのフィードバックをお願いいたします。ご参加いただき、重ねて御礼申し上げます。カンファレンスの残りの時間もお楽しみください。
※ こちらの記事は Amazon Bedrock を様々なタスクで利用することで全て自動で作成しています。
※ どこかの機会で記事作成の試行錯誤についても記事化する予定ですが、直近技術的な部分でご興味がある場合はTwitterの方にDMください。
Discussion