re:Invent 2024: AWSが語るAmazon EKSの本番環境向け耐障害性アーキテクチャ構築
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Building production-grade resilient architectures with Amazon EKS (KUB404)
この動画では、Amazon EKSを使用した本番環境グレードの耐障害性アーキテクチャの構築について、ContainersのSenior Specialist Solutions ArchitectのCarlos SantanaとPrincipal Specialist Solutions ArchitectのNiallが解説します。2024年7月までにAWSが管理するEKSクラスター数が前年比33%増加する中、マネジメント、オブザーバビリティ、ガバナンスの3つの主要な課題に焦点を当てています。GitOpsを活用したクラスター管理、Argo CDによる自動化、Backstageを用いたDeveloper Portal構築、Policy as Codeによるガバナンス実装など、100以上のEKSクラスターを効率的に運用するための具体的な方法論とベストプラクティスが紹介されています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
Amazon EKSを用いた耐障害性アーキテクチャの構築：概要と課題
このトークは、Amazon EKSを使用した本番環境グレードの耐障害性アーキテクチャの構築、簡単に言えばレジリエンシーを備えたAmazon EKSの構築についてお話しします。私はCarlos Santanaと申します - ギターは弾きませんよ、これは冗談ですが。Las VegasのHouse of Bluesに行けば、Carlos Santanaの音楽を聴くことができます。私はContainersのSenior Specialist Solutions Architectで、ECSとEKSを担当しています。そして、一緒に登壇するNiallは、ContainersのPrincipal Specialist Solutions Architectです。
本日の1時間のセッションのアジェンダとして、EKS上のプラットフォームエンジニアリングに関する話の中から、特定の側面を選んでお話しすることにしました。具体的には、マネジメント、オブザーバビリティ、そしてガバナンスに焦点を当てます。 プラットフォームについて話すとき、誰もがプラットフォームの構築を始めます。そしてビルダー、つまり組織内でクラウドリソースを担当し、プラットフォームを構築する人々は、チームのために構築を行います。彼らはチームごとに組織化され、AWSで実行したいアプリケーションがあり、そしてインフラストラクチャがあります。
本質的には3つの要素に集約されます：チーム、アプリケーション、そしてそれらのアプリケーションをインフラストラクチャのどこかに配置する必要があります。 プラットフォームについて話すとき、プラットフォームエンジニアが抽象化を構築し、これらのアプリケーションをAWS上で構築する方法を加速させ、チームができるだけ簡単にクラウドインフラストラクチャを利用できるように自律性を提供するというのが考え方です。 2024年7月までに、EKSに関してAWSが管理するクラスター数は前年比33%増加しています。設定、デプロイ、管理、アップグレードが必要なクラスターの数は年々増加しています。
今日は、プラットフォームチームが直面する3つの主要な課題について見ていきます。まず、クラスターのデプロイからアップグレードまでのライフサイクルと、一貫したエコシステムプロセスの開発についてです。次に、クラスターとそのアプリケーションを監視することによるベストプラクティスの強制ですが、今日はクラスターとシステム全体のソフトウェアにより焦点を当てます。最後に、これらのクラスターを必要とするチームをサポートし、適切な自律性を提供するためのガードレールの提供です。
GitOpsを活用したEKSクラスター管理の進化
まずは管理面から見ていきましょう。一般的に、お客様はGitリポジトリと、Terraform、CloudFormation - 会場の誰かがCDKについて話していましたね - Pulumiなどのインフラストラクチャ・アズ・コードツールを使用しています。インフラストラクチャ・アズ・コードの状態はS3のようなオブジェクトストアに保存されます。 その後、クラスターをデプロイし、同じインフラストラクチャ・アズ・コードツールを使用してKubernetesリソースをデプロイし、これらのKubernetesリソースの状態を同じ場所に保存します。シンプルなクラスター管理であれば、これは全く問題ありません。
そして、規模が拡大し始めます。Platform Engineerとして、チームから新しいEKSクラスターが必要だという要望を受けるようになります。そこで、パイプラインをコピー＆ペーストして移行し、2つ目のクラスターを作成して新しいパイプラインを構築します。 そして、このような状態になります - 皆さんの組織でこのような状況、つまり多くのパイプラインが多数のEKSクラスターをデプロイしている状況の組織がある方は手を挙げてください。成長は続き、パイプラインをコピー＆ペーストしているため、どのクラスターが最新の状態なのかを追跡するのが困難になり、パイプラインのバージョンが多すぎて管理できなくなります。これは各クラスター内のリソースやアプリケーションについて考える前の話です。組織内で多くのパイプラインを見かけるのは珍しくありません。これらは本質的にスノーフレーク（一つ一つが個別の存在）で、個々にはEKSクラスターと言えますが、よく見ると異なるバージョン、異なるアプリケーションが内部にあり、それぞれが古いバージョンやパイプラインのバリエーションを持っています。
では、複数のクラスターを持つ場合の管理における主要な課題を整理してみましょう。
主な課題には、クラスター群全体での標準の適用があります。クラスター群について話す際、それらのデプロイメントを自動化することは困難です。自動化がある場合、単一の信頼できる情報源をどのように設定するのでしょうか？Add-on管理は、数多くのオープンソースプロジェクトがあるため、制御が難しくなります。クラスターに導入する全てのAdd-onについて専門家になることはできません。そして最後に、ワークロード管理があります - EC2の場合、ワークロードに最適なインスタンスタイプをマッチングさせ、さらにその上でコスト最適化を行う方法を考える必要があります。
これは現場で私たちが目にしていることです。Neilと私は現場でお客様と働いており、おそらく皆さんの中にも私たちと一緒に仕事をしている方がいらっしゃると思いますが、Amazon EKSクラスターの設定とデプロイを試み、組織内のこれらのチームにサービスを提供するためのパターンを構築しているお客様と協力しています。クラスターをプロビジョニングする方法は様々あり、組織のテンプレートをサービスとして提供することがウェブサイトで紹介されています。これは参入障壁が低いため、多くのPlatformチームが最初に使用します。Platformチームがテンプレートを作成してDevチームに提供し、それを使ってクラスターを作成しますが、これは規模が大きくなると管理が難しくなります。開発チームは通常、クラスターのアップグレードを行わない傾向があります。PlatformチームでAmazon EKSクラスターを扱っている方なら、クラスターのアップグレード、パッチ適用、新しいアップデートのリリースが必要なことをご存知でしょう。単にテンプレートを提供するだけでは、彼らは一度実行するだけで、そのクラスターをアップグレードすることは二度とないでしょう。
Platformチームがより多くの責任を持ち、サービスを提供しています。私たちが提案している内容を見てみましょう。1つ目は「Cluster as a Service」で、チームにクラスターを提供しますが、Platformチームがクラスター自体を管理し、クラスターとAdd-onのアップグレードを確実に行います。2つ目は「Namespace as a Service」です。これは、チームが話し合いを持つか、あるいはそのNamespaceで必要なリソース量を尋ねるフォームがあり、Platformチームがリソースクォータを設定し、APIを構成したり、RequestとLimitのデフォルト値や制限を設定したりできるようにするものです。このようにして、Platformチームによって作成されたNamespaceが提供され、チームはその中にデプロイできます。そして最後は、チームがPlatformチームにアプリケーションを提供するだけでよい方法です - リポジトリを提供すれば、アプリケーションがKubernetesで動作していることを知る必要もなく、Gitにアプリケーションを置くだけで、Platformチームがそのアプリケーションを取得し、コンテナをビルドしてデプロイする作業を担当します。
これは皆さんの中には馴染みのあるものかもしれませんが、GitOpsを使用している方はどのくらいいらっしゃいますか？GitOpsを活用することのメリットや、その方法論をどのように管理し、その上でどのように製品を構築できるかについて、皆さんも実感されているのではないでしょうか。 設定を活用することで複雑さが軽減されます。Gitを使用することで、変更を追跡し、可視性を高めることができます。 セキュリティ基準が自動的に適用されることで、セキュリティが向上します。 現場で実際に見てきたことですが、セキュリティチームがGitOpsを使用して、すべてのAmazon EKSクラスターに自動的にソフトウェアやポリシーを設定できることを知ると、GitOpsの学習を始めるようになります。 また、誰かが何かを変更して間違いを起こした場合でも、その変更を自動的に元に戻すことができます。GitOpsでは、常に望ましい状態と現在の状態を調整します。これは自動同期を有効にしている場合の話で、GitOpsの設定方法には手動と自動の両方があります。組織や作業環境に応じて選択することができます。
大規模EKSクラスター運用におけるObservabilityの重要性
GitOpsを使用してAmazon EKSクラスターをデプロイおよびアップグレードする場合、高レベルでの構成要素がどのようなものか見てみましょう。組織のAmazon EKSクラスターを設定する際には、主に3つの重要な領域があります。Amazon EKSを使用している方々はご存知の通り、実際にはもっと多くの要素がありますが、今回はこの3つについて説明します。1つ目はコントロールプレーンで、これはAmazon EKSサービスの設定です。
Amazon EKSサービスの設定は、暗号化設定やクラスターアクセス管理などの機能を含め、APIを通じて管理することができます。これはConfig Mapの使用に代わる、Amazon EKSの最新機能です。同様に、Pod Identityについても、以前はアノテーション付きのサービスアカウントを使用していましたが、現在は新しいアプローチとしてPod Identityを使用することで、Amazon EKS APIを通じてサービスアカウントとIAMロールを関連付けることができます。もう1つの重要な側面は、EKS 1.31から1.30へのアップグレードなど、クラスターのバージョンアップグレードです。これはコントロールプレーンレベルで処理され、慎重な検討が必要です。
ワーカーのデータプレーン（EKSではワーカーノードと呼ばれる）については、コンテナランタイムなどのコンポーネントがあります。Karpenterを使用することで、CAPIを使用してEC2インスタンスの設定をより適切に制御できるようになりました。多くの組織では、すでにKarpenterのHelmチャートを用意しており、これを使用してテーマに基づいてクラスやノードプールを作成することができます。これらのHelmチャートは通常Gitを通じてデプロイされ、より良い管理が可能になり、チームはPodがEC2インスタンスを要求する際のワークロード要件に合わせてノードプールを設定することができます。
最後のコンポーネントはアドオンで、これにはAWSが提供するEKSアドオンや、Kubernetesクラスターにデプロイされるその他のシステム全体のソフトウェアが含まれます。これらは通常Helmチャートとしてパッケージ化され、オープンソースやAWSパートナーから提供されます。 フリート管理にGitOpsを活用する場合、ソースの真実と実際のクラスターの状態を継続的に調整するプロセスを実装することができます。この構成要素は、アプリケーション、インフラストラクチャ、ポリシー、セキュリティなど、さまざまな専門家が依存関係を把握し制御できるよう、YAMLファイルで設定されたGitの設定ファイルとして表現できます。このプレゼンテーションでは、簡単のためにこれをcluster.yamlと呼ぶことにします。
Bill of Materialsの異なる部分（コントロールプレーン、Karpenter、アドオンなど）に関する設定をGitに保存したら、 GitOpsエージェントによる調整が可能になります。ここではCNCFのオープンソースプロジェクトであるArgo CDを使用していますが、多くのお客様が利用しているこのツール以外にも、Kubernetesクラスターのリソースを調整するためのツールは存在します。 このクラスターでは、AWSが完全にサポートするオープンソースのACKなどのKubernetesコントローラーを使用できます。EKSチームがこのオープンソースプロジェクトを提供しているので、問題や機能リクエストがある場合は、リポジトリで報告することができ、チームが対応します。
ACKを導入したら、Amazon EKSクラスターを取得するように設定できます。これは、先ほど説明したコントロールプレーンに関する最初のレイヤーを表しています。 そして、一種のインセプションのように、Kubernetesクラスター内に再びArgo CDをデプロイします。このArgo CDのデプロイメントは分離を提供し、設定を処理するエージェントとして、特定のKubernetesクラスターのみを管理することを保証します。Argo CDはそのEKSクラスターの管理を担当することになります。
例えば、オープンソースのKarpenterがある場合、Argo CDはワークロード用のノードを提供するKarpenterをデプロイします。 ワークロードがS3バケットなどのリソースにアクセスする必要がある場合は、そのクラスター内にACKをインストールして、アプリケーションが必要とするS3バケットをデプロイできます。これは、GitOpsを使用してコントロールプレーン、データプレーン用のKarpenter、そしてアドオンを設定する際によく使用されるアーキテクチャです。このように、すべてをGit内でYAMLファイルの宣言的な設定として定義することができます。
次はレジリエンシーについて話しましょう。 私たちは今、クラスターを構築し、GitOpsを使用し、オープンソースツールを活用し、APIを使用し、ACKのようなオープンソースツールを使用することができます。多くのクラスターがありますが、先ほど聞いたように、多くの組織が様々な理由で複数のクラスターを持っています。それは異なるリージョン、異なるチーム、異なるAWSアカウントのためかもしれません。速度がなければ、彼らは遅れをとり、すべてを真剣にアップグレードすることができません。複数のEKSクラスターにわたってすべてを真剣にアップグレードしようとすると、1つの変更を行うのに永遠にかかってしまいます。
組織がバッチでアップグレードを行う場合、レジリエンシーと可用性を確保するためのセーフガードが必要です。望ましい設定を行えば、世界中のすべてのクラスターが一度に自動的にアップデートされると考えるのは誤解です。それは高いレジリエンシーを提供しないため、ベストプラクティスではありません。コンポーネントとバージョンの一貫性は、スケールする際に役立ちます。 これは、EKSチームが昨年のre:Invent 2023で発表した、大量のEKSクラスターを持つ方法です。先ほど述べたように、私たちが管理するクラスターの数は年々増加しています。
Developer Portalを活用したクラスターインベントリ管理
例えば、kube-apiserver（AWSが管理するコントロールプレーン上で動作するコンポーネント）にパッチがリリースされた場合、世界中のすべてのEKSクラスターに展開する必要がある上流のKubernetesプロジェクトのパッチを適用しなければなりません。これは私たちが非常に重要視していることですが、速度と回復性の両方のバランスを取っています。クラスターをCellにグループ化することで、影響範囲を管理しやすくなります。Wave間にはベイク時間を設けており、このソーク時間はCellの数が増えるにつれて短くなります。各Wave間では、異なるレベルのテストが実施されます。
1つのCellには約12個のクラスターが含まれる可能性があり、このについてはYouTubeで講演を公開しています。この手法を組織内のAWSアカウントにあるEKSクラスターに適用することで、組織全体で回復性の高い方法でアップデートを展開できるフリート管理が可能になります。具体的な実装方法は、もちろん組織によって異なります。この例では、1つのCellが1つの作業単位、つまり1つのクラスターとなります。このコンセプトでは、1つのCellを1つのクラスターとして扱います。1つのWaveで処理できるCell数は重要で、進行に伴って速度と回復性のバランスを管理し、信頼性は徐々に高まっていきます。
例えば、すべてのEKSクラスターで使用されているAdd-onやKarpenterの設定を変更する場合、クラスターのパッチ適用を開始するにつれて信頼性が高まります。その結果、待機時間を短縮し、アップグレードするCellの数を増やすことができます。この例では、プラットフォームチームが変更をテストするために使用するSandboxクラスターからWaveを開始します。プラットフォームエンジニアリングを行う場合、通常これをSandboxと呼び、1つの環境内で複数のWaveを持つことができます。この例では異なる環境を示しており、DevからStagingへと進みます。Stagingではより多くのクラスターを扱います。Productionでは、デプロイメントの範囲を広げるにつれて、クラスター間で異なるアップデート戦略を取ることができます。
この場合、Prod-1とProd-2は、組織に応じてリージョンやAWSアカウント間で分割される可能性があります。基本的な考え方として、Wave内のCell数を動的に増やすことで、デプロイメントの待機時間を短縮できます。
これを実践的な例で見てみましょう。すでに、Bill of Materialsを定義するクラスターについて説明しました。Amazon EKSクラスターのアップグレードなど、何か変更が必要な場合、それをGitにプッシュし、その後ロールアウトを行います。このロールアウトは、カスタムパイプラインとして作成することも、手動で実行するプロセスとして実施することも、または変更管理を追跡するためのチケットシステムを使用してパイプラインと手動プロセスを組み合わせることもできます。GitHubのようなツールを使用する場合、Argo CDを使用してそのロールアウトをオーケストレーションすることができます。
Wave 1では、チェックを実施します。 アップグレードの前に、アップグレードの実現可能性を判断するためのチェックを自動化することができます。チェックにパスしたら、アップデートに進みます。アップデート後は、その変更に特化したテストや、変更の種類に関係なく実施される標準的なテストを行います。変更は、コントロールプレーンレベル、KarpenterのConfigurationの変更などのデータプレーンレベル、あるいはVPC CNIやその他のオープンソースプロジェクトなどのAdd-onに関連する可能性があります。
次に、待機時間（Soak time）があります。この期間中は、次のWaveに進む前にすべてが正常に機能していることを確認するため、システムの健全性を監視します。 次のWaveは何でしょうか？Wave 2です。この場合、クラスタの数をセル数分だけ増やし、同じテストを再度実行します。チェック、テスト、Soakを行いますが、進むにつれて待機時間は短くなっていきます。 このプロセス全体はArgo CDによってオーケストレーションされます。
Argo CDを使用した具体的な例を見てみましょう（もちろん、他のツールを使用することもできます）。Argo CDには、特定のアノテーションを持つKubernetesリソースであるPre-sync hookを設定できるシステムがあります。Amazon IAM upgrade insights APIを使用してアップグレードの準備状況を確認するためのゲートを実装できます。また、Pre-sync hookは、データベースの移行、Secretの設定、アップグレードを進める前のAdd-onの健全性確認など、セットアップ要件も処理できます。前提条件には、インストールが必要なCRDなどが含まれ、これらのHookはアップグレードでもデプロイメントでも一貫しています。
Hookの後、先ほど説明したテストを実行します。Argo CDにはPost-sync hookがあり、Add-onの健全性、ECSの設定、Upgrade insightsとの統合を確認するための機能テストなど、環境の検証が可能です。また、JenkinsやArgo Workflow（Kubernetes内で実行されるCI/CDパイプラインオーケストレーター）でパイプラインタスクを起動したり、単に完了通知を送信したりすることもできます。ここで、ObserveとGovernについて話すために、Neilにバトンを渡したいと思います。おはようございます。ありがとう、Carlos。彼は今朝の最初のセクションでCNCFビンゴカードを達成しましたね。
Policy as Codeによるガバナンスの実現と課題
それでは、Observabilityから始めましょう。 Dr. Werner Vogelsのこの印象的な引用を含まないAWSのプレゼンテーションは存在しないと思いますが、結局のところ、1つのクラスタであれ100のクラスタであれ、物事は壊れるものです。私たちには問題を見つけ、検出し、修復を支援する戦略が必要です。プラットフォームチームとしてこれができなければ、開発者が信頼できるサービスを運用することはできません。
このセクションでは、Observabilityの基礎については触れません。代わりに、大規模なクラスターを運用する際に、お客様が繰り返し直面する特定の課題に焦点を当てていきます。これらの問題は、10個程度のクラスターを運用し始めた時点で顕在化し始めることがあります。それでは、一つずつ見ていきましょう。
最初のポイントは、役割と責任についてです。Carlosが発表の冒頭で述べたように、多数のAmazon EKSクラスターを管理しているお客様の多くは、PlatformチームとApplicationチームという組織構造を採用しています。これは必須というわけではありませんが、多数のAmazon EKSクラスターの利用を効果的にスケールさせる方法として、現場で多く見られるアプローチです。Platformチームは単なるクラスター製造工場ではありません。その名前が示すように、開発チームが依存する共有機能をより多く提供します。Observabilityの領域では、Observabilityインフラストラクチャ自体の管理が含まれますし、場合によっては、アプリケーションチームのオンボーディング時にダッシュボードやアラートを提供して、より迅速な立ち上げを支援することもあります。
結局のところ、Platformチームはそれらのクラスターの稼働を維持する責任があります。クラスターを構築して投げ渡すだけというのは、私たちが目指すものとは正反対です。私たちが望むのは、開発者をお客様として捉え、開発チームにサービスを提供することです。これが私たちの考え方です。これがPlatform as a Productの考え方であり、それを反映したObservability戦略が必要です。アプリケーションチームがサービスを信頼するためには - ここで信頼が重要なポイントとなりますが - Platformチームは、アプリケーションチームが自身のワークロードシグナルをモニタリングしているのと同様に、クラスターからのシグナルを常時モニタリングする必要があります。
多くの方々がすでにこの道を歩んでいることでしょう。お客様がまず最初にダッシュボードに多大な投資をするのは珍しくありません。ダッシュボードは簡単で見栄えが良く、テレメトリーをシステムに取り込んでダッシュボードに表示すれば、Observabilityができていると考えがちです。しかし、これが効果的にスケールしないのは明らかです。数個のクラスターのモニタリングを始めた時点で、問題が発生するのを待ってダッシュボードを見つめているわけにはいきません。それよりも効果的にスケールする何かが必要です。
そのため、多くの場合、かなり早い段階でプロアクティブなアラートにより重点を置く方向に移行します。Platformチームとして、信頼という観点から、私たちはお客様に問題を気付かせたくありません。クラスターで何か問題が発生した場合、お客様が気付く前に検知して修正できることが理想です。お客様から問題を報告されるのを待つのは絶対に避けたいところです。なぜなら、それはPlatformチームへの信頼が崩れ始める根本的な原因となるからです。これはプラットフォームの採用にも直結します。Platformチームとアプリケーションチームの間の信頼が崩れると、彼らはあなたのプラットフォームを使いたがらなくなります。プロアクティブなアラートを設定し、クラスターの稼働を維持するためのプロアクティブなアプローチを取ることで、その信頼を維持する必要があります。
アラート単体では、いくつかの異なる問題につながる可能性があります。Alert fatigueは今では古い用語となっていますが、誰もが知っています。適切なアラートを設定することはもちろん重要ですが、アラートだけでは問題の解決方法がわかりません。サポート組織を拡大するためには、アラートに効果的にRunbookを紐付けておく必要があります。そうすることで、深夜2時にアラートを受けた担当者がドキュメントを必死に探さなくても問題を解決できます。また、自動修復が次第にパターンとして定着してきているのを目にすることが増えています。
この傾向は、数週間前に私が参加した会議でも明らかでした。ベンダーフロアでは運用の自動修復が目立っていました。Runbookが定義されていなければ、最終的にこれらのプロセスを自動化することはできません。多くの人々が長年これを実践してきましたが、この自動化の傾向が高まるにつれて、Runbookを取り込んで自動的に適用できるツールが登場してきています。これにより、事前にRunbookを定義しておく新たな動機が生まれています。
ここまでの話は、必ずしもクラスターの管理に直接関係するものではありませんでした。しかし、先ほどCarlosが説明したContinuous Deliveryのフローは、このフィードバックループをプロセスに組み込むための前提条件となります。Carlosが説明したように、EKSサービスチームはCellsとWavesを通じてロールアウトを行っています。プロアクティブなアラートは、ダッシュボードを監視し続けるのではなく、プロセスを継続すべきかどうかを判断する指標となります。
Carlosはテストについて話しましたが、Sandboxクラスターでアップグレードをテストする方法を構築したPlatformチームと話をすることは珍しくありません。機能テスト用の小規模なクラスターを使用して、多くの問題を発見することができます。しかし、WavesがStagingやDeploymentに進むにつれて、開発環境では見つけられない問題が出てきます。テストを繰り返して問題を早期に発見することはできますが、何かをモニタリングしてアラートを設定しない限り、理想的には自動化された方法でプロセスのCircuit Breakerとして機能する、Soak期間は意味がありません。この堅牢なアラートセットは、問題が発生し始めた場合にロールアウトをキャンセルするメカニズムとして使用できます。
これはおそらく私がよく受ける質問ですが、もっと良い回答ができればと思います。モニタリングすべき項目とアラートのしきい値について、確定的なリストがあればいいのですが。多くの方々はすでにKubernetesを運用しており、クラスターにインストールできるコンポーネントの数や、実行できる様々なワークロードの数をご存知でしょう。ベンチマークとして使用できる優れた情報がオンラインにはたくさんありますが、具体的なリストを提供するのではなく、このプロセスを効果的に実行し、信頼を得るために必要なモニタリングの範囲の広さを強調したいと思います。
これには、アップグレード後にコントロールプレーンのレートが増加したかどうか、ノードが正常に起動しているか、CoreDNSのレイテンシーが増加したかどうかなどの監視が含まれます - CoreDNSは2024年でもまだ重要な考慮事項です。また、アップグレード中にお客様のワークロードが劣化していないか、アプリケーションチームが高いレイテンシーやエラーレートを経験していないかを理解する必要があります。これにより、提供しているクラスターの健全性だけでなく、開発者に提供している体験の質も理解することができます。最近、EKSクラスターのコントロールプレーン監視機能が改善され、コントロールプレーンから追加のメトリクスを取得できるようになりました。セッションの最後の関連リソースでリンクを提供します。これにより、以前にはなかった一連のメトリクスが提供され、監査ログの確認や問題の特定のためのコンソールに組み込まれた追加のメカニズムも利用できます。
ポリシー管理の実践：一貫性と例外への対応
ここで話題を少し変えて、厳密には可観測性ではありませんが、この範囲に含まれるクラスターインベントリについて説明します。これは問題の発見やトラブルシューティングというよりも、組織内のすべてのクラスターの全体像を把握することに関するものです。特に、リージョン、アカウント、そしてAWS組織全体にわたってスケールする場合に重要です。すべてのコンソール画面を行き来し、集約されたビューで何が起きているかを把握するのは難しい課題となります。これを解決する方法は多くあります - ベンダーツールを使用したり、GrafanaやObservabilityツールを使用したりする例を見かけます。また、特にAWSネイティブなお客様が、BackstageのようなDeveloper Portalを使用してクラスターに関する情報を取り込み始めているのも注目されます。これは、オープンソースのBackstageや、同等の機能を提供するベンダー製品のいずれかを使用する形で行われています。
そこでは、アカウントやリージョンを横断するすべてのクラスターのビューを得ることができます。これは、多くの人々がBackstage以前にDeveloper Portalとしてカスタムウェブアプリを一から構築していた他のアプローチよりも、おそらく良い選択肢だと思います。 これは、より高度なユーザーの間でも活用され始めており、すべてのクラスターの集約リストとしても機能しています。
Backstageのような非常に柔軟なツールを使用することで、Amazon EKSだけでなく、関連システムからの情報も集約してカスタマイズする機会が得られます。アカウントID、AWSリージョン、EKSバージョン、アドオンのバージョンなどの基本的な情報（APIから取得可能な情報）から始めて、AWS Cost ExplorerやOpenCostから情報を取得するコストタブなどの追加情報を加えることができます。Backstageで直接ポリシー違反や調査結果のフィードバックを提供したり、開発チームがクラスターの過去の可用性を確認できるようにSLAを表示したりすることができます。これは監視ツールではありませんが、クラスターのパフォーマンスに関する簡単な概要表示として、ユーザーやマネージャーが確認できます。
BackstageのようなDeveloper Portalで再構築したくない情報がある場合は、必要なすべての場所へのリンクを提供することができます。特に100個のクラスターがある場合、Chromeでブックマークフォルダを管理するのは大変です。そこで、特定のクラスターに関連するすべての場所へのディープリンクを提供し、単なる単一の画面としてだけでなく、クラスターの運用に必要な他のシステムへの起点としても機能させ、フリート全体をナビゲートするための基盤を提供します。
最後に私たちが有用だと考えているのは、関係性です。開発者ポータルでは、カタログ内のアイテム間の関係性を表現できるようにすることが一般的です。Backstageの場合、これはエンティティ間の関係性となります。特定のクラスターにどのワークロードが依存しているかといったモデル化を始めることができます。この時点でBackstageには通常チームの所有権モデルが既に存在するため、ワークロード間の依存関係を理解することで、クラスター間の依存関係もモデル化し始めることができます。このように、Podやデploymentではなく、組織的な観点から、クラスター、ワークロード、組織がどのように関連しているかというメタデータのグラフを構築できます。
何かを把握する必要がある場合や、クラスターがダウンした場合の影響範囲を理解することができます。これは、ワークロードやチームだけでなく、ワークロードが相互にリンクしている下流のクラスターについても同様です。これらはすべて自動的に行うことができ、手動で行う必要はありません。先週、私たちはBackstage向けの新しいプラグインをオープンソース化しました。これにより、AWS Configを通じてAWSインフラを直接Backstageカタログに取り込むことができるようになりました。以前にも同様の機能を持つプラグインは存在していましたが、特定のサービスに限定されていました。現在では、AWS Configに存在するものであれば何でも、EKSクラスターを含めてBackstageに直接取り込むことができ、タグを使用して依存関係を完全に自動的にマッピングすることができます。
Carlosのガードレールに関する講演と同様に、ガバナンスについて話す際、先ほど議論されたテーマの1つが一貫性でした。100個のEKSクラスターを持つお客様と話をする際、一貫性なしではそれらを管理することが難しくなります。Carlosが先ほど話したことで、EKSクラスターレイヤーでの一貫性が得られます - クラスターを立ち上げ、ノードを起動し、Add-onをインストールします。しかし、開発者が実際にクラスターにものを配置しており、組織によっては、クラスターの提供から完全なプラットフォーム抽象化までのスペクトラムのどこに位置するかによって、その様子をコントロールできる場合とできない場合があります。そのため、いずれの場合でも、特により自律的な開発チームと、開発者がクラスターに何を配置すべきかを支援するよりガードレールされたアプローチとのバランスを取ろうとする際には、スケールする上で一貫性を達成するためにガバナンスが重要になります。ただし、これはPolicy as Codeのセッションではありません。
代わりに、スケールでの問題に特化して、人々がこれをどのように適用しているかについてより詳しく話したいと思います。簡単な説明として、OPA GatekeeperやKyvernoのようなPolicy as Codeエンジンは、オープンソースの世界で非常に人気のあるツールで、ポリシーをコードとして表現することができます。例えば、Kyvernoは通常YAMLファイルを使用し、さまざまな方法で強制することができます。一般的なアプローチは、クラスター内でポリシーを適用し、一連のコントローラーが変更に対して調整を行い、対処が必要なポリシー違反をすべてポリシーレポートとしてフラグを立てます。
より厳格なアプローチは、ポリシーに正しく準拠していないクラスターへの変更をブロックするアドミッションコントロールを使用することです。一部の組織はこれを適用することを望みますが、そうでない組織もあります。自律性のスケールでは、望ましくないものを完全に停止する良い方法を提供しますが、チームからは作業が遅くなると言われることが多く、実際にその通りの場合も多いです。組織に効果的に適用するアプローチと、プラットフォームの構築方法のバランスを取る必要があります。
具体的に、Observabilityと同様のフリクションポイントとして、ポリシーが関係してくる場面をどのように捉えているのでしょうか？ どのようなポリシーを作成すべきかという問題は、組織によってポリシーが異なるため、さらに不明確かもしれません。セキュリティに関連するポリシーなど、基本的なベースラインと考えられる種類のポリシーがいくつかあります。これには、Podでの読み取り専用ファイルシステムの実行、追加機能の制限、rootユーザーとしての実行の防止など、実装すべき基本的なポリシーが含まれます。また、スケールアップ時のコスト管理のため、コストの精算に向けてすべてのPodに適切なタグやラベルを付けるといった基本的な要件もあるでしょう。
大規模なクラスターフリートで特に問題となるのは、ロールアウトを正常に保つことです。多くのお客様から伺った話では、開発者がデプロイしたものが原因で、KubernetesチームやPlatformチームがクラスターをアップグレードできない状況に陥っているとのことです。Carlosが言及したように、Infrastructure as Codeのテンプレートを提供してもクラスターをアップグレードしない状況や、非推奨APIや非推奨CRD、Pod Disruption Budgetによってロールアウトが停滞する可能性があります。ここで Policy as Codeが重要になってきます。クラスターのロールアウトを正常に保つために、ガードレールを提供する必要があるのです。
100から200のクラスターを運用している場合、すべての開発者チームのCRDの運用について個別に対応することは不可能です - そのような対応に時間を費やしすぎてしまいます。このプロセスを左にシフトし、レールの上に留めておく必要があります。同様の立場にある方、またはそうなる可能性がある方は、これが多くのお客様が直面している一般的な問題であり、解決にはポリシーの実装が必要だということを知っておいてください。魔法のような技術的解決策はありません。多くは組織的な問題です。解決方法について人々の賛同を得るのに苦労している場合、これが私たちが実際に目にしている状況です。
可用性も重要な側面です。開発クラスターでアプリケーションチームがレプリカを1つしかデプロイしていないため、クラスターをアップグレードできないお客様もいます。クラスターをアップグレードすると、チームはプラットフォームの不安定性を訴えます。Pod Disruption Budgetを使用していない場合、この問題はステージングや本番環境にも及ぶ可能性があります。これはアップグレードだけでなく、他のクラスターの問題でも同様に発生します。定期的なアップグレードや継続的な変更がある中で、これらの対策が講じられていない場合、プラットフォームへの信頼 - たとえそれが信頼の認識だけであっても - が損なわれ、採用に関する問題やチームからの苦情につながります。ポリシーの使用は、アプリケーションの回復力だけでなく、プラットフォームに対するネガティブなフィードバックなしで定期的なアップグレードを確実に行うため、そしてCarlosが先ほど説明したプロセスのために活用すべきツールの1つでなければなりません。
EKSクラスター管理の総括：GitOps、Observability、ガバナンスの統合
ポリシーの管理に関しては、Carlosが既に困難な作業をすべて行ってくれています。私たちは既に、必要なアーティファクトを展開できる駆動プロセスを持っています。スケールアップする際に本当に重要なのは、クラスター全体での一貫性を管理することです。
私たちが本当に目指しているのは、クラスター間での一貫性の管理です。バリエーションや例外にも対応できなければなりません。この一貫性を実現するために、よく見られるパターンの1つは、ベースラインとしてすべてのポリシーを含む単一のHelm Chartをすべての場所に展開することです。初期段階では、1つのクラスターに1つのポリシー、別のクラスターに別のポリシーというパッチワーク的な展開でも機能するでしょう。しかし、規模が大きくなってくると、すべてのポリシーをすべての場所に展開し、Helm Chart内でオプションを適用できるようにする必要が出てきます。Values filesを使用することで、特定のポリシーの有効・無効を切り替えることができます - たとえば、Webサービスクラスターとデータクラスターで異なるポリシーを持つことができます。
例外に関して言えば、Kyvernoのようなツールでは例外がファーストクラスのプロセスとして扱われており、これに対応できる必要があります。たとえば、rootユーザーとして実行しないと動作しないサードパーティソフトウェアがある場合などが考えられます。例外への対応は最終的には必要になりますが、私たちは単一のアーティファクトを展開し続けられる方法で対応したいと考えています。そのため、使用するツールに応じて、例外への対応を計画することが重要です。
先ほど、Policies as Codeフレームワークを実行するさまざまな方法について話しましたが、最も単純な方法は、クラスター内のリソースを評価してレポートを作成することです。例えば、Kyvernoはこの評価を行う際に、Cluster Policy Reportのようなものをクラスターに作成します。最初のうちは、クラスターを直接確認して何が実行されていないかを確認できるでしょう。しかし、フリートの規模が本当に大きくなってくると、ポリシー違反を効果的に監視するためには、より集約的な何かが必要になります。Kyvernoには関連プロジェクトとしてPolicy Reporterがあり、これをクラスターにインストールすることで、すべての検出結果をS3やElasticsearch、AWS Security Hubなどのシステムに集約することができます。
このスクリーンショットの元となった、OPA GatekeeperとKyvernoの両方についてのブログ記事例があります。ここではKyvernoのすべての検出結果をAWS Security Hubに直接送信しています。これにより、アカウント、リージョン、クラスター、そしてデータが存在する場合はワークロードごとに検索することができ、さらにSecurity Hubの修復ワークフローなどの他の機能も活用できます。これらは、違反を検出するだけでなく、修復のためのシステムを構築するための基盤となります。
これは、Carlosが冒頭で話した3つのテーマを反映しています。GitOpsの効果的な適用は、より大規模なAmazon EKSクラスターのフリートを構築しているお客様から見られるトレンドとなっています。GitOpsは、必須条件かどうかは別として、Argo CDやFluxなどのテクノロジー、そしてCIドリブンのインフラストラクチャプロビジョニングと組み合わせたトレンドとして見られています。プロアクティブなモニタリングへの投資は、問題を検出するだけでなく、それをGitOpsプロセスにフィードバックして、手作業をほとんど必要としないシステムを確信を持って構築できるようにするために重要です。最後に、ガバナンスをスケーリングの鍵として活用したいと考えています。
Carlos は今週2回、明日と水曜日にワークショップを開催する予定です。これは GitHub でも公開される予定で、そのリンクは後ほどのスライドで紹介されます。このワークショップでは、本日お話しした Argo CD を使用した GitOps によるマルチクラスター管理の3つの分野について、実践的な経験を積むことができます。ワークショップでは Terraform を使用する例も用意されています。多くの方が Terraform を使用していますので、このパターンでは Amazon EKS API 用の Terraform の管理方法と、GitOps のための Argo CD の使用方法をご紹介します。この2つのツールを組み合わせることに苦労している方も多いので、その例を用意しました。AWS Security Hub の例では実践的な経験を積むことができますので、できるだけ早めにご参加ください。すでに利用可能となっています。
Amazon EKS関連リソースとワークショップの紹介
Observability の管理に関して、多くのプラットフォームチームはアプリケーションの Observability を気にかけていますが、これは良いことですが、Add-on の安定性のモニタリングを忘れがちです。これには、オープンソースの Karpenter のパフォーマンス、CoreDNS の動作状況、VPC CNI サブネットなど、プラットフォームチームが所有する Observability が含まれます。チームはこれらを認識しておく必要があり、最後にポリシー管理に関する学びで締めくくられます。設定には Kyverno と Policy Reporter を使用しています。すべてが GitHub 上でオープンソースとして公開されているので、確認して、自分の組織に適用できる部分を取り入れることができます。
次に、KUB301 があります。これは Adobe と AWS による、Amazon EKS を使用してスケーラブルなプラットフォームを構築した方法についての講演です。彼らは以前、KubeCon や他の CNCF のトークでこの方法について講演しており、Carlos が話したプリフライトチェックとポストフライトチェックの原則を適用しています。プラットフォーム構築に関するテーマだけでなく、Adobe がそれを実践している様子を見ることができるので、必見の講演です。また、Infrastructure as Code、GitOps CI/CD など、さまざまなオプションとそのメリット・デメリット、組織として考慮すべき点について、今週何度か講演が行われる予定で、これらも素晴らしいセッションとなるでしょう。
追加リソースとして、まだ体験されていない方のために、Amazon EKS ワークショップとハンズオンラボがあります。新機能がリリースされるたびに、それらを反映して進化させています。今週も何度か実施しますが、追加セッションには含めていません。自分で実施したい場合は、セルフサービスで実施することも、イマージョンデイと呼ばれるものを実施することもできます。アカウントチームにご相談いただければ、スペシャリストがチームに来て、ハンズオンで学習のサポートをさせていただきます。非常にモジュール化されており、学びたい内容に応じて組織に合わせてカスタマイズすることができます。
多くの方がすでにベストプラクティスガイドをご存知かと思います。しばらく前からありましたが、最近、このデータオペレーションに関する素晴らしい知識セットを Amazon EKS のドキュメントの一部として正式に組み込みました。同じ素晴らしい知識を、ドキュメントに合わせて一箇所にまとめたことで、より見つけやすくなりました。最後に、バッジが欲しくない人はいませんよね？バッジを取得して LinkedIn に掲載しましょう。私はまだ持っていません。皆さんは Amazon EKS バッジを持っていますか？はい？私も追いつかないといけませんね。これは GitHub のページへのリンクです。このリポジトリには、すべての re:Invent セッションが含まれています。各セッションごとにディレクトリがあります。コードは掲載していませんが、各セッションに関連する参考資料へのリンクが多数用意されています。
そのリンクから私たちのフォルダにアクセスできますが、そのリポジトリ内は非常に簡単に見て回ることができます。これまでのセッションで話題に上がった内容へのリンクもいくつか追加してあります。メインリポジトリには、私たちが所属するAIグループトラックなど、すべてのトラックが含まれています。Neilが言及したBackstageのように、他のワークショップもあり、Backstageを実際に体験できるハンズオンワークショップもあります。今日のKUB308では、IaCとBackstageのハンズオン体験ができますし、JFROGやBackstageに関する他のワークショップもあります。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion