re:Invent 2024: AWSがKubernetes APIでクラウドインフラを管理するACKを解説
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Managing infrastructure via APIs with AWS Controllers for Kubernetes (OPN202)
この動画では、AWS Controllers for Kubernetes（ACK）を使用してKubernetes APIでAWSクラウドインフラを管理する方法について解説しています。現在50のACKコントローラーが一般提供されており、宣言的モデル、継続的な調整、拡張性という3つの主要な特徴を持ちます。従来の断片化されたワークフローと比べ、ACKを活用することでアプリケーションリソースとクラウドリソースの両方を単一のKubernetesベースのワークフローで管理できます。また、Argo CDなどのGitOpsツールと組み合わせることで、アプリケーションとインフラストラクチャの両方に対して自己修復メカニズムを実現し、既存のAWSリソースの取り込みも可能です。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
AWS Controllers for Kubernetes (ACK)の概要と利点
みなさん、こんにちは。この最後のセッションにお越しいただき、ありがとうございます。最後まで参加していただき、感謝申し上げます。私はAmazon EKSチームのSenior Product ManagerのLukonde Mwilaと申します。Lukeとお呼びいただいても結構です。本日は、Kubernetes APIを使用してAWSクラウドインフラを管理する方法、具体的にはAWS Controllers for Kubernetes（通称ACK）についてお話しさせていただきます。まず、手を挙げていただきたいのですが、ACKをご存知の方、あるいはすでにアプリケーション環境で使用されている方はいらっしゃいますか？はい、お一人いらっしゃいますね。実験段階でも本番環境でも構いませんが、他にいらっしゃいますか？はい、ありがとうございます。
では、ACKを全く知らない方のために説明させていただきます。ACKは、Kubernetes APIを使用してAWSクラウドリソースのライフサイクル全体を管理できるオープンソースプロジェクトです。特にKubernetesのコントローラーパターンに基づいています。Kubernetesのコントローラーは、Kubernetesリソースやインフラストラクチャの実際の状態と望ましい状態の両方を継続的に監視する役割を担っています。これら2つの状態に違いが生じた場合、コントローラーの役割は、実際の状態が常に望ましい状態と一致するように調整することです。このモデルを、AWSクラウドインフラの管理にも拡張できるようになりました。AWS APIは命令的ですが、このKubernetesベースのアプローチやモデルを使用することで、セルフヒーリングのメカニズムを実現しています。
現在、50のACKコントローラーが一般提供されています。ACKの仕組みとしては、ACKでサポートされている各AWS管理サービスに専用のコントローラーが用意されています。また、プレビュー段階にあるコントローラーもいくつかあります。 ACKへの関心、採用、実験的な利用が増えていることを大変嬉しく思っています。これは、このプロジェクトの目的が支持されていることを示しているからです。ただし、すでに他のツールや手段が存在する中で、なぜクラウドリソースを管理するための新しいツールや手段が必要なのかという質問がよく出ます。これは重要な質問であり、答える必要があります。私たちは、お客様が本質的に何を達成しようとしているのか、またどのように達成しようとしているのかについて、その利用パターンを継続的に観察しています。
これら2つの質問について簡単に考えてみましょう：お客様は何をしようとしているのか、そしてどのように実現しようとしているのか。1つ目の質問については、お客様は本質的にビジネス価値を生み出すために、より安定したソフトウェアをより速く提供しようとしています。2つ目の質問については、この主要な目的をサポートする生産性の高いワークフローを作ることで実現しようとしています。 ACKは、その「どのように」という部分を支援するソリューションです。これは表面的な答えに聞こえるかもしれません。生産性の高いワークフローを作るとは具体的にどういうことなのか、ソフトウェア開発ライフサイクルにおいてそれはどのように見えるのでしょうか。
実際のところ、多くの場合、チームが試みているのは内部プラットフォームを作ることです。このプラットフォームは、アプリケーション開発者が日々のワークフローの中で、必要なリソースの依存関係を含めて、ソフトウェアを開発し実行環境にデプロイできるように設計された環境です。ここでクラウドリソースが関係してきますが、Kubernetesはこの中でどのような役割を果たすのかという疑問が生じます。私たちが観察している利用パターンの傾向として、チームがKubernetesをベースにプラットフォームを構築し、Kubernetesワークフローを標準化したいと考えているということがあります。主な推進要因は次の3つです：宣言的モデル、継続的な調整、そして拡張性です。
チームは今、アプリケーション環境やスタック全体について、アプリケーションリソースの定義とインフラストラクチャの依存関係を含めて、望ましい結果を記述できるようになりました。これは、設定ミスが発生しやすい手続き型やImperativeなアプローチとは異なります。環境のあるべき姿を正確に定義する設定ファイルを用意することができます。2番目の推進要因は、先ほど説明したController patternによって実現される継続的な調整（Continuous reconciliation）です。Continuous reconciliationにより、アプリケーションリソースとインフラストラクチャの両方について、環境全体の自己修復メカニズムが実現します。3番目の推進要因は拡張性です。Kubernetesはネイティブなリソースとデータ型を標準で提供していますが、カスタム要件やユースケース固有の要件が必要なシナリオもあり、Custom Resource Definitionsを使用してKubernetes APIをネイティブデータ型以外にも拡張できます。これらの3つが、チームがプラットフォームの基盤やワークフローとしてKubernetesを採用する主な理由となっています。
プラットフォーム構築におけるACKの役割と統合アプローチの重要性
アプリケーションの観点から見ると、通常、アプリケーションを正常に機能させるために様々なリソースを使用します。デプロイされると、Deployment、Ingress、Service、Service Account、Config Map、Secretなどのリソースが使用されます。これは完全なリストではなく一例ですが、アプリケーションが期待通りに機能するために、それぞれの目的や役割に応じて必要となります。
プラットフォームを構築するチームと、そのプラットフォームを利用する開発チームのコンテキストでは、通常、プラットフォームチームは先ほど説明したKubernetesリソースタイプ（Deployment、Secret、Config Mapなど）をプリミティブまたは低レベルの構成要素として設計します。プラットフォームを使用する開発者の生活を楽にするという目的のため、プラットフォームチームはこれらの低レベルのプリミティブを抽象化します。これにより、アプリケーション開発者はKubernetesの詳細な仕組みを理解するという認知的負荷を必ずしも負う必要がなくなります。
多くの場合、図に示されているように、低レベルでそれらのプリミティブを見つけることができます。その上位には、Custom Resource Definitionsに基づくカスタムリソースがあり、これらの低レベルのプリミティブをグループ化または構成して、チームがアプリケーション環境をインスタンス化または作成できるようにします。チームが利用できるのはその抽象化されたものであり、環境を作成するために必要な変数や値を持つインターフェースとのみやり取りすることで、より簡単に目的の環境を作成できます。
先ほど、Kubernetesアプリケーションに通常必要なさまざまなアプリケーションリソースを示す図を紹介しましたが、それは全体像の一部に過ぎません。チームはアプリケーションが依存するインフラストラクチャリソースも必要とします。例えば、DynamoDBデータベース、RDSデータベース、S3バケット、IAMリソースなどです。チームが直面する一般的な課題の1つは、アプリケーション環境を作成するためのワークフローが断片化していることです。つまり、アプリケーションリソースを作成するための特定のワークフローと、クラウドリソースを作成するための全く別のワークフローが存在するということです。
これにより、プラットフォームの利用者であるアプリケーション開発者にとって、アプリケーション環境を構築する際に2つの異なるワークフローを扱わなければならず、開発速度の低下を招いています。また、開発者が異なる標準やツール、言語を使い分けなければならないシナリオが発生し、認知的な負担も大きくなります。これは、アプリケーション開発者がランタイム環境にアプリケーションを設計・デプロイしやすくするというプラットフォームの目的に反することになります。
ここで重要になってくるのが、アプリケーションリソースとクラウドリソースの両方のプロセスを統合する方法です。これこそがACKの役割です。クラウドリソースを作成するために別のワークフローやアプローチを使用する必要がなくなり、代わりにアプリケーションとインフラストラクチャの両方のリソースを定義するために、同じKubernetesベースのアプローチやKubernetesリソースモデルを使用できます。スタック全体が単一のワークフローを使用することで、プロセスが統合され、プラットフォームの利用者と作成者・管理者の両方にとって作業が容易になります。
この図は、そのプロセスと全体像を示しています。上部の濃い青色のブロックは、Platform TeamとDevelopment Teamの両方が対話するインターフェースを表しています。Platform Teamはシステムの作成者であり、Development Teamはそのシステムの利用者であることを覚えておいてください。私たちが目指す目標である、アプリケーション環境やスタック全体に対する単一のKubernetesベースのワークフローが実現されています。ただし、アプリケーション層とインフラストラクチャ層という2つのセグメントは依然として分かれていることを示す境界線が引かれています。
Kubernetesリソースにおいて、Deploymentリソースは通常、環境で実行されるべきアプリケーションを定義するために使用されます。これに加えて、現在ではBucketカスタムリソース、RDSデータベースカスタムリソース、IAMカスタムリソースも利用できます。これらはそれぞれ、Kubernetes環境内の異なるコントローラーによって監視されています。DeploymentコントローラーはKubernetesクラスターにネイティブで組み込まれており、コントロールプレーンの一部として提供されますが、AWS Controllers for Kubernetesはインストールする必要があります。この例では、S3、RDS、IAMという異なるサービスに対応する3つのACKコントローラーがあり、各コントローラーがカスタムリソースを監視し、リソースが作成されるとAWS環境での作成を担当します。
ここでの重要なポイントは、ワークフローとプロセス全体を統合することのメリットと、断片化された項目を抱える場合の課題です。断片化は開発者のインフラストラクチャプロビジョニングを遅らせます。このような統合システムがない場合、アプリケーション開発者は多くの場合、必要なインフラストラクチャを記述したチケットを作成するなど、異なるモデルに従う必要があります。これにより、アプリケーションをデプロイする前に、必要な形でインフラストラクチャが作成されるのを待たなければならず、時間がかかってしまいます。また、インフラストラクチャの作成に異なるアプローチを使用することになるため、インフラストラクチャの監査も難しくなり、冗長なインフラストラクチャが存在しないことを確認するための統合や監視が困難になります。
統一されたアプローチを使用することで、ベストプラクティスの標準化がより容易になります。アプローチが断片化していると、アプリケーションとインフラストラクチャの提供における全体的な体験が一貫性を欠くことになります。また、複数のテクノロジーや標準が混在するシステムでは、プラットフォームの保守と利用がより複雑になってしまいます。
GitOpsとACKを組み合わせたアプリケーション環境の管理とデモンストレーション
ここで、お客様が AWS Controllers for Kubernetes を環境で使用している一般的なアプローチについてお話ししたいと思います。その重要な側面の一つが GitOps です。挙手していただきたいのですが、GitOps をご存知の方はどのくらいいらっしゃいますか？素晴らしい、何人かの方がいらっしゃいますね。GitOps は本質的に、インフラストラクチャの継続的デリバリーと変更管理プロセスを自動化するモデルで、Git をソース・オブ・トゥルースとして使用します。多くの場合、チームは Argo CD を使用しています。これが唯一の選択肢というわけではなく、Flux CD という選択肢もあります。
これは、チームがアプリケーションとインフラストラクチャの両方を提供するために使用しているアプローチやフローの例です。このアプローチにより、プラットフォームの主要な目的の一つであるセルフサービスモデルが実現できます。アプリケーション開発者は通常、アプリケーションとインフラストラクチャ層の両方について、望む結果を記述した設定ファイルを持っています。それをプラットフォームチームがレビューし、そのプロセスを経て問題がなければ、特定のブランチにコミットまたはマージされます。Argo CD のような GitOps ソリューションは、そのブランチをソース・オブ・トゥルースとして継続的に監視しています。
GitOps ソリューションは、デプロイ先の環境に対するインテントベースの設定のソース・オブ・トゥルースとして、その Git リポジトリと特定のブランチを継続的に監視しています。Argo CD は、マージされたばかりの変更を検出し、実際のインフラストラクチャと比較します。同じコントローラーパターンに従って、現在の状態と望ましい状態を確認します。違いを検出すると、それを調整し、設定に基づいてアプリケーション層とインフラストラクチャ層の両方がクラスター環境にデプロイされるようにします。
これがどのように見えるかをデモでお見せする前に、ACK で GitOps を使用することのメリットをいくつか強調しておきたいと思います。先ほど申し上げたように、アプリケーションとクラウドリソースの管理ワークフローが統一されます。すでに多くのチームやお客様が、特にアプリケーション層で GitOps のメリットを享受していることを私は認識しています。このアプローチが分断されていると、インフラストラクチャ層に対して全く異なるパイプラインを持つことになり、このシステム全体のコンシューマーであるアプリケーション開発者の体験全体に影響を与えてしまいます。彼らにもセルフサービスのアプローチを提供したいものです。
このセルフサービスアプローチは、アプリケーションに必要なインフラストラクチャの構築にも適用されます。また、先ほどControllerパターンで説明したように、全般的な自動化とオーケストレーションもより効果的に実現できます。Argo CDはOperatorですが、本質的にはカスタムControllerです。そのため、アプリケーションスタック全体に対して、宣言的で自己修復可能なモデルを実現できます。例えば、何らかの理由でAmazon DocumentDBデータベースに変更が加えられた場合、Argo CDは継続的にGitリポジトリを監視し、デプロイされた内容やインフラストラクチャの実際の状態を確認します。デプロイされたクラウドリソースと、それを作成する責任を持つカスタムリソースの間にコミュニケーションがあるため、差異が生じた場合、Controllerを通じて自己修復メカニズムが機能します。最後に、アプリケーションスタック全体の統合された可観測性についてですが、特にArgo CDのようなユーザーインターフェースを備えたソリューションでは、アプリケーションだけでなくインフラストラクチャの健全性も含めて、スタック全体を可視化できます。
残り時間が少なくなってきましたので、簡単にデモをお見せしたいと思います。これはordersというサンプルアプリケーションで、ここにはKubernetesベースのリソースのマップ全体が表示されています。ここにServiceがあり、Service Accountがあり、Deploymentがあります。さらに、このマイクロサービスの開発・運用を担当するチームが特定の要件やニーズを持っている場合を想定して、DocumentDBデータベースもあります。こちらにDBクラスターがあり、そのクラスター用のインスタンスがここにあります。少し下にスクロールすると、AWS Secrets Managerから関連する認証情報を取得するためにExternal Secrets Operatorも使用しています。このように、アプリケーションとインフラストラクチャの両方のレイヤーで、プロセス全体がGitOpsを通じて自動化・管理されています。
こちらに移動して、少し拡大表示してご覧いただきます。ここにdelta-ecommerce-dbがありますが、Argo CDに戻って確認していただけるように、これがここにあるデータベースと同じ名前です。これをクリックすると、Argo CDで望ましい状態を確認することができます。このマニフェストをご覧ください - このクラスター内の特定のインスタンスdelta-ecommerce-db-instance-oneがecommerceネームスペースにあることがわかります。これが私が設定した、つまり宣言した内容で、これが実際のマニフェストです。ここにdelta-ecommerce-dbクラスターがあり、これらが特定のインスタンスで、これらはすべてAWS Controllers for Kubernetes (ACK)によって作成され、完全に管理されています。ここでタグを見ると、このリソースがACKによって管理されていることを示すタグが自動的に作成されていることがわかります。また、ACKを使用して、Kubernetesベースのワークフロー以外で作成された、すでにデプロイされている、あるいは実行中のインフラストラクチャを取り込むこともできます。既存のリソースも取り込むことができ、環境でACKを段階的に活用し、Kubernetesベースのワークフローに徐々に移行したい場合に非常に効果的です。
最後に、これが実際に動作していることを示すために、これはDocumentDBからデータを取得しているアプリケーションです。下の時計を見ると残り45秒しかありませんが、もう少しこちらにいますので、ご質問がある方はお気軽にどうぞ。AWS Controllers for Kubernetesに興味をお持ちの方は、オープンソースプロジェクトですので、Googleで検索していただければそのページにたどり着けると思います。先ほど申し上げたように、私はこの後も数分間こちらにいますので、ご質問があればお答えさせていただきます。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion