re:Invent 2024: KubernetesとServerlessの統合 - ACKとKroによるEDAデプロイ
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Kubernetes meets Serverless: Deploy EDAs with Kubernetes APIs (API308)
この動画では、KubernetesとServerlessを組み合わせたモダンアプリケーション構築について解説しています。多くの組織で、KubernetesベースのプラットフォームとServerlessアーキテクチャが混在している現状を踏まえ、AWS Controllers for Kubernetes (ACK)とKroという2つのオープンソースツールを活用した統合アプローチを提案しています。具体的な実装例として、Amazon EMR on EKSでApache Sparkを実行し、AWS Step Functionsでワークフローをオーケストレーションするデータ処理パイプラインのデモを行っています。従来のチケットベースの開発者体験の課題を克服し、APIを通じた自己完結的なデプロイメントを実現する方法を、実践的な知見とともに紹介しています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
モダンアプリケーション構築の課題と目標
皆様、ようこそお越しくださいました。re:inventの1日目が素晴らしいものとなっていることを願っています。本日は「KubernetesとServerlessの出会い」というセッションにご参加いただき、KubernetesのAPIを通じてEvent-Driven Architectureをどのようにデプロイするかについてお話しさせていただきます。私はEmily Sheaで、ServerlessのGo-to-Marketチームを率いています。この後すぐに、AWSのSenior Specialist Solutions ArchitectであるChristina AndonovとGiedrius Praspaliauskas が加わる予定です。私たち全員の仕事の中で共通しているのは、様々な業界や地域の、小規模から大規模まで多くのお客様とお会いしているということです。そして、 その大多数に共通して言えることは、皆さんがモダンアプリケーションの構築を目指しているということです。新規に構築するアプリケーションをモダナイズし、エンドユーザーにより多くの価値を提供できるよう、イノベーションを実現する方法を探しているのです。
これらのモダンアプリケーションの主要な特徴を見てみましょう。アーキテクチャパターンについて考えると、時間とともに進化できるよう、モジュール化された方法で構築しようとしています。運用モデルについては、運用作業をAWSやプラットフォームチームに委託するなど、 差別化につながらない運用の負担を軽減する方法を探しています。 ソフトウェアデリバリーの面では、デプロイメントをできる限り自動化し、標準化することを目指しています。 また、管理とガバナンスについては、それを全員の責任とし、会社内で共有の責任として管理とガバナンスの要件を確実に満たすようにしています。
データ管理の面では、アプリケーション全体を通じて目的に特化した分離されたデータベースを使用することを目指しています。これらすべてにより、技術面では、何百万人ものユーザーにスケールでき、グローバルに利用可能なアプリケーションを構築し、ユーザーリクエストにミリ秒単位で応答し、ペタバイト規模のデータを処理できるようになります。 これらすべてが、Total Cost of Ownershipの削減、エンドユーザー体験の向上、そして最終的には市場投入までの時間を短縮し、より良い競争力を持ち、エンドプロダクトにより大きな価値を生み出すという、ビジネス成果につながっています。
プラットフォーム開発の経験と教訓
ソフトウェア開発やテクノロジーのすべてにおいて言えることですが、特定の答えや製品を作り上げるための方法は一つではありません。私たちが協力しているお客様は、モダンアプリケーションを構築するために、大きく分けて2つの異なる運用モデルと2つの異なるパスを選択しています。一部のお客様は、モダンアプリケーションの構築にServerlessやAWSネイティブのアプローチを取っています。その中で、より明確な方向性を持つAWS APIを活用し、それらを通じて自動化を行おうとしています。 自律的な開発チームにより重点を置き、開発チームに必要な選択をする権限を与え、独立して構築できるようにしています。 また、可能な限り多くのインフラストラクチャ管理をAWSに委託し、管理の負担を極めて低く抑えようとしています。 そして最後に、運用やインフラストラクチャの維持に関わるすべての作業を含む、新しいアプリケーションのTotal Cost of Ownershipを本当に削減しようとしています。
このような運用モデルを選択する方々が好んで使用するサービスには、Amazon ECSやAWS Fargate、ServerlessファンクションのためのAWS Lambda、AWS App Runner、そしてAmazon EventBridgeやAWS Step Functionsなどのアプリケーション統合サービス、そしてAWSネイティブサービスのエコシステム全体が含まれます。一方で、KubernetesとKubernetesエコシステムに焦点を当てて、モダンアプリケーションの構築に成功しているお客様も見受けられます。 この運用モデルとパスを選択するお客様は、主にKubernetes APIとKubernetesツールを使用して自動化を構築することに注力しています。 中央のプラットフォームチームを持ち、中央プラットフォームチームによって構築された標準的な実践方法を組織全体で重視する傾向が強くあります。アプリケーション開発者がセルフサービスで利用できる社内開発者プラットフォームを持っている可能性が高いでしょう。 また、Kubernetesを中心に構築されているコミュニティやオープンソースのツールエコシステムを活用することにも重点を置いています。
これらの人々がよく利用するAWSサービスは、もちろんAmazon EKSや、EC2上でKubernetesを実行する方法、そしてコンテナを実行するためのRed Hat OpenShift Service on AWS (ROSA)です。これらはどちらも完全に有効なモデルであり、多くのお客様がこの2つを使用して成功を収めているのを目にします。大規模な組織内でこれらの選択がどのように行われるのか、その意思決定プロセスについて少し考えてみるのは興味深いことです。状況を整理するために、私たちは2つのグループについて考えています。まず最初の観察点として、大規模な組織であれば、中央のプラットフォームチームやクラウドセンター・オブ・エクセレンスのような形で、クラウドに関する重要な決定を下し、ベストプラクティスを実装する中央チームが存在し、アプリケーションや新機能を開発するチームと並行して活動しているということです。
中央プラットフォームチームの役割は通常、パターン作り、ツーリング、セキュリティとコンプライアンス、そしてベストプラクティスの作成を含み、それらを展開して開発チームをサポートすることです。
大規模な組織では、高度な標準化が行われていると思われるかもしれません。例えば、中央プラットフォームチームが、全員がKubernetesを標準として採用し、AWSのコンピューティングサービスとしてAmazon EKSを使用することを宣言し、開発チームがそれに従って開発を始めるというような形です。しかし、多くの（というよりもほとんどの）お客様で私たちが発見しているのは、実際の環境はより異種混合的で、これらの大規模組織内ではコンピューティングの選択においてより多様性があるということです。
この多様性には複数の理由があります。重要な要因の1つは企業買収です。例えば、主にAmazon ECSを使用しているお客様が、Kubernetesをベースにしている企業を買収するというケースです。この場合、全体像を考慮する必要が出てきます。また、技術的な好みという要因もあります。特定の方法での開発に慣れているチームがあり、彼らが構築しているものが最新で上手く機能している場合、完全にスキルを再習得させる必要性はないかもしれません。
最後の考慮点として、特にAWS Lambdaのカスタム関数に関しては、特定のユースケースやワークロードに最適化されたコンピューティングを選択するということがあります。例えば、大量のイベント通知を送信するような、非常に急速なスケールアップが必要なワークロードがある場合、より一貫した負荷パターンを持つ他のユースケースでコンテナが使用されていても、Lambdaが理想的な選択となる可能性があります。これが、私たちが協力している大規模組織のほとんどが直面している現実であり、これらの異種技術の選択が存在することで興味深い課題が生まれています。
KubernetesとServerlessの統合への挑戦
これは問題なのでしょうか？ これは過度な複雑さを生み出しているのでしょうか？そして、もっと標準化を目指すべきなのでしょうか？ 私たちが発見したのは、必ずしもそうではないということです。多くのお客様が、自分たちのユースケースに最も適した技術を選択することで大きな成功を収めています。結局のところ、チームに権限を与え、適切な仕事に適切なツールを提供することが重要なのです。 この好例となるのが、UK Driver and Vehicle Licensing Agency（DVLA）です。DVLAは英国政府の一部で、運転免許証と車両の全国登録を管理し、年間約60億ポンドの収入を集めています。彼らは最近、運転免許サービスアプリケーションの大規模な近代化プロジェクトに着手しました。
これは単なるプレゼンテーション層の更新やフロントエンドの修正だけではなく、クラウド利用のためのアプリケーションを最適化し、長期的な成功を確実にするための、バックエンドの大幅なリファクタリングと近代化も含まれていました。 彼らのシンプル化されたアーキテクチャを見ると、コンテナプラットフォームにAmazon EKSを使用し、UIにはRuby on Railsを、開発者向けには標準的なコンポーネントを採用しています。また、100人以上の開発者がセルフサービスでこのプラットフォームを使用できる、何百ものJavaコンポーネントとライブラリを組み込んだ、堅牢で安定したJavaテックスタックも備えています。
アプリケーション処理のバックエンドに取り組む際、非同期プロセスを持っていたため、ServerlessとEvent-Driven Architectureに適していることがわかりました。新しい運転免許証申請の処理ワークフローには、アップロードされた写真の処理や、プロセスへの人による承認の組み込みなどのステップがありました。これらの要件はすべてServerlessとEvent-Drivenアプリケーションに適していたため、コンテナとServerlessのアプローチを組み合わせることを決定し、そのアプリケーションで大きな成功を収めています。
私たちが関わっているペルソナとその関心事について考えることは有益だと思います。最初のグループはプラットフォームユーザーです。プラットフォームユーザーとは、アプリケーションを構築する人々、例えばML EngineerやData Engineer であり、彼らは自分の好みの技術を使用することに関心があります。つまり、彼らが使い慣れていて、構築しようとしているものに最適だと考えるものを使いたいのです。彼らは単に素早く構築してアプリケーションをデプロイしたいと考えており、パイプラインのトラブルシューティングや、素早い構築と前進の妨げとなるようなことに時間を取られたくないのです。
一方で、プラットフォームビルダーがいます。これらは、ビジネスアプリケーションプラットフォームやデータエンジニアリングプラットフォームを構築するプラットフォームチーム、あるいはそれらのプラットフォームのセキュリティとコンプライアンスに取り組む人々です。これらの人々は、開発者をサポートし、アプリケーションのデプロイを可能にすること、そして開発者がセキュリティやコンプライアンス およびガバナンス要件を満たしやすくすることに関心があります。
DVLAのようなお客様の例を見ると、コンテナのプラットフォームやサービス開発のワークフローなど、別々のシステムがうまく機能しているケースがあります。このプロセスは彼らにとってはうまくいっていますが、同じモデルを採用しようとして課題に直面しているお客様も見受けられます。例えば、アプリケーションの定義とデプロイに異なるInfrastructure as Codeフレームワークを使用するなど、ツールセットが分断されているケースがあります。これは、プラットフォームチームがInfrastructure as Codeフレームワークで提供するブループリントやテンプレートのライブラリが重複する原因にもなります。また、異なるテクノロジータイプを組み合わせる際の適切な権限の有効化とスコープ設定も課題となります。そして最後に、開発者が新しいアプリケーションをデプロイしたい場合、必要なインフラを入手するために長期化したチケット処理プロセスに直面することがあります。これらはすべて、イノベーションを妨げ、作業を遅らせる要因となっており、私たちが解決したい課題です。
全体として、モダンアプリケーションに関して、お客様が採用している2つの運用モデルが見られます。本日、私たちが掘り下げてお話ししたいのは、これら2つを統合し、コンテナとServerless、そしてAWSネイティブの両方の利点を最大限に活用する機会についてです。それでは、Christinaに交代したいと思います。
データプラットフォームのユースケース設計
ありがとうございます、Emily。皆さん、こんにちは。私はChristina Andonovです。AWSのSolutions Architectとして、主にコンテナ上でプラットフォームを構築するお客様のサポートをしています。AWS入社前は、私自身がプラットフォームエンジニアでした。AWSのお客様の一社で働いており、私たちはTerraformを使用する組織で、チームではTerraformを使用してKubernetesクラスターのフリートを作成・管理していました。また、開発者がそれらのKubernetesクラスターにアプリケーションをデプロイするためのツールも提供していました。それらのアプリケーションがAWSの依存関係を必要とする場合、私たちには決まったプロセスがありました。そのプロセスは以下の通りです：開発者がチケットを作成し、私のチームの誰かがそのチケットを受け取り、Terraformのコードをコピー＆ペーストしてAmazon S3バケットを作成し、開発者にバケットの場所を返すというものでした。
毎週かなりの数のチケットが来ていたため、ローテーションを組んで対応していました。私たちはそれを「ヒーローローテーション」と呼んでいました。ただし、私がそのローテーションを担当していた時は、まったくヒーローには感じませんでした。実際、それは私の仕事の中で最も好きではない週でした。時々、「Lambdaが必要です」というチケットを受け取ることがありました。開発者たちはもちろん、AWS Lambdaが素晴らしいので使いたがっていました。様々な理由で、そのチケットは多くのやり取りが必要になるため、1週間以上かかることが分かっていました。Lambdaをどのようにトリガーするのか？結果をどこに保存するのか？彼らが何を作って欲しいのかを理解するまでに、私の楽しい週は終わってしまいました。
そこで私には2つの選択肢がありました。ただ座って不平を言い続けるか、それとも何か行動を起こすかです。もちろん、私は後者を選び、同じ考えを持つ仲間たちと集まりました。私たちは組織全体のために、コンテナの依存関係だけでなく、Serverlessアーキテクチャだけでもなく、この問題を解決することを決めました。データプラットフォームチームが何をしているのか見に行きました。彼らは独自のやり方をしていたので、それを理解する必要がありました。そして、データベースチームやセキュリティチームとも話をしました。
これらのチームのほとんどがすでにTerraformを使用していたため、私たちは本格的なTerraformプラットフォームを構築することにしました。実際に構築を行い、ユーザーのオンボーディングを開始しました。まずは上級ユーザー、つまりデータプラットフォームチーム、データベースチーム、セキュリティとコンプライアンスチームなどから始めました。
そして開発者たちをオンボードする時期が来て、この新しいプラットフォームを彼らに開放しました。その時まで、私はTerraformのパイプラインがこんなにも頻繁に、しかも明確な理由もなく失敗するとは思っていませんでした。今笑っている方々は、きっとTerraformを使っているのでしょうね。Terraform applyの失敗は、私の部屋の隅にある散らかった椅子のようなものでした。長年かけて、私の脳はそれを無視するようになっていたんです。最初に採用した他のチームも同じでした。データプラットフォームチーム、データベースチームなど、これらのチームには共通点がありました。私たち全員が何年もTerraformを使ってきたのです。Terraformのパイプラインがどれほど頻繁に失敗していたのか、気づいていませんでした。
開発者がTerraformで躓いた時、「すみません、ちょっとTerraformの経験を数年積んでから、バケットの作成を終わらせに戻ってきます」とは言わないでしょう。代わりに、チケットシステムに戻って「ねぇヒーロー、私のパイプラインを直してくれない？」と言うはずです。要するに、私たちはこのプラットフォームを作り、組織にとって多くの良いことを実現しました。より広範なプラットフォームチームと効果的に協力し、セキュリティとコンプライアンスの態勢を改善し、その他様々な利点を達成しました。しかし、目標リストを見直すと、プラットフォームチームを方程式から除外できるほどの開発者の生産性向上という目標には、あまり到達できていませんでした。冗談めかして言えば、私たちが構築したのは次世代のテクニカルデットだったのかもしれません。
その時点で、私は次の論理的なステップとして、AWSに移り、残りのチームに何をすべきか考えてもらうことにしました。そしてAWSに移って、皆さん、つまり私たちの顧客と話を始めました。知らなかったのですが、誰もが少しずつ異なるものの似たような状況にあり、私はこの問題に取り組むだけでなく、それをスケールで行うことになったのです。私は質問を始め、その一つが「なぜこんなにも多くのプラットフォームがあるのか」でした。非常に一般的な答えは、開発者に自律性を与えたいということでした。
その答えには一つのトレンドがあることに気づきました。スタートアップの場合、通常は開発者に多くの自律性を与え、時にはAWSアカウントの管理者キーさえも与えます。そして組織が成熟するにつれて、標準とツールを整備し始めます。ある時点で、組織によっては1つのランタイムだけを標準化してサポートすることを決めます。一部の組織は1つのプラットフォームへの移行に成功します。しかし、その次に組織で起こることは成長であり、成長に伴って企業を買収します。そしてその買収企業は常に、あなたが標準化したものとちょうど正反対のランタイムを持ってくる傾向があります。つまり、1つのプラットフォームに標準化することは、本当の答えではないのです。
私たちの顧客からもう一つの回答として得たのは、ワークロードのプロファイルに基づいてコンピュートの選択を行っているということです。あるワークロードはAWS Lambdaで実行し、別のワークロードはコンテナで実行するといった具合です。これは正しいアプローチだと思います。では、私たちが構築したシステムに話を戻して、開発者の生産性を向上させ、Platformチームを介在させないための次の論理的なステップを考えてみましょう。実は、Christinaがヒーローチケットシステムを好まなかった以外にも、多くの教訓を得ることができました。チケットシステムでは、それがボトルネックとなるため、Platformチームを排除することができないということがわかりました。
そのヒーローチケットシステムを振り返ってみると、本格的なTerraformプラットフォームは組織にとって多くの利点をもたらしますが、この特定の問題に対する解決策ではないことがわかりました。先ほど触れた通り、上部には私のチームが開発者にKubernetesへのデプロイツールを提供するというプロセスがありました。ただし、言及しなかったのは、開発者が新しいアプリケーションを自立的に作成し、1日に何度でもコードをデプロイでき、さらには私の助けを借りることなくそれらのアプリケーションを廃止することもできたということです。チケットは一切必要なく、彼らはそのプロセスに満足していました。
では、なぜそれを活用し、発展させてAWSリソースの依存関係やServerlessアーキテクチャを作成できるようにしないのでしょうか？最初に言及しなかったもう一つのことは、私と志を同じくする仲間たちが集まった時、実はこのオプションを評価していたということです。当時、開発者にAPIをインターフェースとして提供すれば、彼らはそれを採用し、気に入ってくれるだろうということはわかっていました。その時にこのアプローチを選択しなかった理由は、より大きなPlatform組織の存在でした。これらのAPIを構築し、Kubernetesのコントローラーをゼロから構築することを検討していましたが、大規模なPlatformチームを見渡すと、これらのコントローラーを構築できるメンバーは数人しかいませんでした。効果的なコラボレーションができないと考えたのです。
また、3人で構築したシステムを他のメンバーがサポートできない場合、Day 2オペレーションや誰がシステムをサポートするのかということも懸念されました。当時、AWS Controllers for Kubernetes（ACK）というオープンソースプロジェクトも検討しました。これはAWSが私たちのためにコントローラーを構築し、クラスターにインストールするだけで良いというものでした。当時、このプロジェクトはオープンソースで、約13のコントローラーがありました。オープンソースだったため、GitHubでの活動を確認できましたが、あまり活発な活動が見られなかったため、AWSがこれをどの方向に進めているのか確信が持てませんでした。
現在AWSで働いている私から、過去に何が起こっていたのか、そして現在の舞台裏で何が起こっているのかをお話しできます。ACKを作成した当初、いくつかの決定を下しました。その一つは、サービスごとに1つのコントローラーを作成するということでした。つまり、Amazon S3サービスにはS3コントローラー、Amazon RDSサービスにはRDSコントローラーというように作成していきました。もう一つの決定は、各サービスチームが自分たちのコントローラーの面倒を見るというものでした。このモデルは、各チームには独自の優先事項があり、また離職もあったため、私たちが考えていたほどうまくいきませんでした。今年の初め、これを認識したAmazon EKSサービスチームは、すべてのACKコントローラーの所有権を引き受けることを決定しました。今日の時点で、GAステータスのコントローラーは50個まで増えており、GAとはこれらのコントローラーがエンタープライズサポートの対象となることを意味します。
ACKを使ってサービスアーキテクチャをデプロイする場合、次のような流れになります：まず、4つのコントローラー（Amazon S3、Amazon SQS、AWS Lambda、そしてIAMコントローラー）をインストールします。これにより、Kubernetesクラスターにロールとこれら4つのコンポーネントを作成するためのAPIが提供されます。その後、開発者は自分たちが使い慣れたツールを使ってリソースを作成できるようになります。2日目に私たちは、これだけではまだ不十分だということに気づきました。なぜなら、サーバーレスアーキテクチャを実現するためには、開発者向けの適切なインターフェースが必要だからです。つまり、これらのリソースを論理的にグループ化し、そのグループを開発者に公開できる必要があります。
また、最小権限の原則に基づいたポリシーにAmazon S3バケットを提供するなど、あるリソースから別のリソースへ値を受け渡す必要があります。これを認識し、私たちは約2週間前に新しいオープンソースプロジェクトを公開しました。それは、Kubernetes Resource Orchestratorの略である「kro」と呼ばれるもので、Kubernetes内でリソースをグループ化し、複雑さを抽象化し、値を受け渡して論理的な操作を実行するための手段として設計されています。kroはオンプレミスであれローカルクラスターであれ、すべてのKubernetesクラスター上で動作します。これはKubernetsネイティブであり、サーバーレスアーキテクチャを含むAWSリソースをデプロイするためのKubernetesリソースモデルを採用する上で、最後のピースになると私たちは考えています。
では、具体的にどのような形になるのでしょうか？先ほどの図に戻りますが、まずクラスターにkroをインストールします。kroをインストールすると、Resource Groupと呼ばれる1つのCRDがクラスターにインストールされます。このResource Groupを使用して、これらのリソースをグループ化できます。この例では、私は任意にServerlessAppという名前を付けましたが、文字列を渡して論理演算を行うことができ、開発者はServerlessAppの種類のResource Groupインスタンスを作成できます。
Kubernetesを通じたデータ処理パイプラインのデモンストレーション
昨年のちょうどこの頃、このプロジェクトに取り組んでいる時に、私は初めてGiedriusとオンラインで会いました。私はKubernetesの世界の出身で、Giedriusはサーバーレスの世界の出身です。会話を始めて10分後、私が「Giedrius、見てください。これらすべてをKubernetesで実現できるんです。すごいと思いませんか？」と言うと、Giedriusはため息をつき、私が子供を叱る時のような口調で話し始めました。「Christina、これはおもちゃのサーバーレスアーキテクチャです。これは典型的なサーバーレスアーキテクチャとは違います」と。私が「では、Giedrius、典型的なサーバーレスアーキテクチャとはどのようなものですか？」と尋ねると、彼はこの図を見せて、「これが典型的なサーバーレスアーキテクチャです。これをKubernetesでどうやって実現するか見せてください」と言いました。
カンファレンスシーズンで忙しい時期だったので、通話を終えた後、私は「また30分を無駄にしてしまった」と思いました。ところが2週間後、彼から電話がかかってきて「Christina、動かすことができました」と言うのです。私は、それが動いたことと、2週間前にはKubernetesについてほとんど知識がなかった彼に感心しました。2週間でどうやってKubernetesを学んだのか尋ねると、彼の答えは「壁に開いた穴を修理するために業者を呼ばなければならなかった」というものでした。
このトークを計画していた時、私はGiedriusに何をデモするか電話で尋ねました。おもちゃのようなServerlessアーキテクチャをデモするわけにはいきませんし、典型的なServerlessアーキテクチャをデモするのでしょうか？その全体のアーキテクチャを Kubernetesを通じてデプロイすることはできますが、それはKubernetesを通じてServerlessをデプロイすることになります。私たちのトークのタイトルは「Kubernetesが Serverlessと出会う」なので、計算処理の一部がKubernetesで実行され、一部が AWS Lambdaで実行されるようなものをデモすべきだと考えました。そしてそれをKubernetesを通じてデプロイします。そこで私たちは一から考え直し、どのようなユースケースが良いか検討しました。そして、analyticsジョブのためのデータプラットフォームというユースケースを思いつきました。このデータプラットフォームのanalyticsジョブには、多くの企業がデモ目的で使用している有名なNew York Taxiデータセットを使用することにしました。
私たちはKubernetes上でanalyticsを実行するオープンソースソフトウェアであるApache Sparkを使用します。また、Kubernetes上でも実行できる最適化されたSparkバージョンであるAmazon EMRも使用します。これが処理の中心部分となり、analyticsジョブには通常何らかのワークフローが必要なので、AWS Step FunctionsをAWS Lambda上で実行することにしました。私たちのトークのサブタイトルがKubernetes APIを使用したイベント駆動アーキテクチャのデプロイメントについてなので、Amazon S3 バケットを使用して、New York Taxiデータセットの新しい月のデータをアップロードすると、それがイベントを発生させ、ワークフロー全体がトリガーされるようにしました。
これがChristinaが言及したデモワークロードです。これは、データが入力され、何かが開始され、データが処理され、どこかに保存されるという最初のアーキテクチャに似たデータ処理の例です。この場合、Amazon EKS上のAmazon EMRとAWS Step Functionsを使用してプロセス全体をオーケストレーションします。このプロセスを順を追って説明し、その後、すべてKubernetesを通じてデプロイされるコードを見ていきましょう。
このデータ処理の例を開発する際、いくつかの要件を考慮しました。まず、すべてのワークロードを分離するためにワークロードごとのNamespaceが必要で、スタック全体の各ジョブが同じNamespaceで実行されるようにする必要がありました。また、ワークフローを作成するデータエンジニアが、許可されていないS3バケットにアクセスしたり、自分に属さないスクリプトを使用して処理を開始したりできないよう、Amazon S3での最小権限アクセスを実装する必要がありました。さらに、スタック全体はプラットフォームエンジニアが管理しますが、データエンジニアは追加の権限や管理者アクセスを必要とせずにデプロイできる必要がありました。
プロセスの流れは次の通りです：まず、データオブジェクトがS3バケットに到着すると、Amazon S3がAmazon EventBridgeにイベントを送信します。次に、EventBridgeがルールに基づいてAWS Step Functionsのワークフロー実行を開始し、どのようなデータが入力されたかという情報、つまりS3バケットに到着したオブジェクトに関する情報を渡します。ワークフローは仮想のAmazon EMRクラスター上でApache Sparkジョブを開始し、そのEMRクラスターは指定されたNamespaceを使用してデプロイされ、すべてを同じ単一のNamespace内に保持し、スタック全体の設定で指定されたスクリプトを使用してデータを処理します。
Spark jobはAmazon S3からデータを取得し、データに対する全ての処理と分析を実行し、出力データをS3バケットに保存します。データ処理と並行して（これはデータセットのサイズと利用可能なSparkリソースに応じて3分から5分、7分、10分程度かかる可能性があります）、EMR on EKSは同じクラスター内で実行されるため、処理能力は利用可能なコンピュートリソースに依存します。Step Functionsワークフローは、入力データをデータレイクにコピーします。このデモでは、単に別のS3バケットを使用していますが、アーカイブ目的や他の処理要件、データ保持ルールのために、どのようなデータレイク実装でも構いません。Sparkがデータ処理を完了すると、ワークフローは次のステップに進みます。
このワークフローは、JSON形式のデータが格納された出力プレフィックスを持つS3バケットから結果を読み取り、Amazon DynamoDBデータベースに保存します。これはS3で直接実装され、Lambdaコードや追加のコードを書く必要はなく、S3の変換機能だけで実現できます。このDynamoDBデータベースは、データにアクセスする必要のあるAPIやワークロードで使用されます。DynamoDBでもRDBMSでも、実装方法は顧客次第です。
最後に、完了したワークフローはEventBridge Custom Busに送信され、そのデータセットの処理が完了し、利用可能になったことを購読者に通知します。処理の概要はDynamoDBに書き込まれて使用可能になります。このデモでは、そのカスタムイベントバスのターゲットはSimple Notification Service（SNS）です。SNSはイベントバスからイベントを受け取り、そのイベントに含まれるすべてのデータを、デモワークロードの設定で指定された受信者のメールアドレスに送信します。
これがStep Functionsワークフロー自体の様子です。コードを見せて、どのように動作するか説明しましょう。注意点として、これから説明するコード全体は、皆さんが入手できるレポートに含まれており、最後にQRコードが表示されます。ですので、これから見ていく興味深いコードの部分をメモしようとする必要はありません。
では、コードについて説明しましょう。データエンジニアの視点からは、このように見えます。ご覧の通り、約20行のYAMLで、データが入ってくる入力バケット、使用するSparkスクリプトの名前、メッセージを送信するメールアドレス、そして一般的な設定のためのデフォルト値をいくつか指定しています。これがプラットフォームエンジニアから見た様子です。指定された全てのリソースを含むリソースグループ全体が見えます。まず、そのスタック全体用に作成されたNamespaceから始まります。これがリソースの1つで、その後に入力バケットがそのNamespace内に配置されます。互いに参照し合い、テンプレートの一部として提供された入力バケット名を使用します。同様に、DynamoDBテーブルについても、スキーマを直接コードで指定します。
Step Functionsのワークフローとその定義は、約170行のJSONとYAMLで構成されるAmazon States Languageで定義します。 Crossplaneは現在も開発中ですが、いずれ外部リソースを参照できるようになることを期待しています。同様に、Virtual Cluster、SNS Topic、そしてインスタンス定義で提供されたメールアドレスを使用したSNS Topicのサブスクリプションなど、他のリソースも定義します。 先ほど最小権限の要件について話しましたが、ここでポリシーに具体的に示されています。特定のバケット、入力用の特定のプレフィックス、一時的な処理出力、さらには処理に使用するスクリプトまでも指定します。特定のスクリプト名に制限を設けることができ、スクリプトライブラリのバケットを指定して使用する特定のスクリプトを指定したり、データエンジニアが使用できるスクリプトを特定のものに制限したりすることができます。
ArgoCDを使用してデプロイすると、このように表示されます。 すべてのリソースが1か所にまとめられ、すぐに使用できる状態でリソースグループ全体がデプロイされます。これは私のデモ環境で、 デモアカウントでの様子です。まず、すべてのタブを確認して、初期状態を確認していきましょう。空のバケットと、空もしくは一部のデータが入ったDynamoDBテーブルがあります。 これは最近の実行リストです。過去に実行され、完了した実行が数件表示されています。同様に、処理開始時のDynamoDBテーブルには、1月と2月のデータのサマリーという2つのレコードがあります。そして、 QuickSightダッシュボードには、すでにいくつかのデータが読み込まれています。
右側に2か月分のデータが表示されており、ベンダー別の平均運賃を見ることができます。あるベンダーは430万件、別のベンダーは130万件のレコードがあります。別のタブに移動して支払い方法の分布や最も高額な乗車を確認すると、 一部の乗車料金がかなり高額であることが興味深いですね。また、メールボックスには通知が1件も届いていません。
次のステップとして、サンプルデータバケットからいくつかのデータファイルをアップロードします。CloudShellセッションを開始して、 3月のデータセット、4月のデータセット、そして5月のデータセット、計3つの追加データファイルをコピーします。これらをS3にロードして、到着を確認しましょう。入力バケットの入力プレフィックスに3つの追加ファイルがロードされたことが確認できます。Step Functionsの実行リストを更新すると、 突然、ワークフローの3つの追加実行が並列で動作していることがわかります。これら3つのファイルは、1つのEMR on EKS Virtual Cluster内で並列処理されています。
数分後、c5.7xlargeで約3〜5分かかりますが、データを更新すると、S3バケット内にそれらのファイルがなくなっていることがわかります。データレイクにコピーが作成された後、処理後のファイルは削除されました。入力バケットに元のデータを残しておく必要はありません。この時点で実行も完了しており、約3分かかりました。DynamoDBテーブルには現在、 Step Functionsワークフローによって書き込まれたJSONサマリーデータを含む3つの追加サマリーレコードがあります。
さて、QuickSightのダッシュボードでデータを更新すると、2ヶ月分のデータが5ヶ月分に増えています。430万トリップと130万トリップだったものが、今では1,150万トリップと370万トリップになっています。ベンダー別の平均運賃のチャートと、支払いタイプ別の支払い分布にも5ヶ月分のデータが表示されています。最も高額な乗車については、より多くのドットが表示され、データが増えていることがわかります。すべての処理が完了し、メールの受信トレイには3つの通知メッセージが届きました。この特定の処理が完了したことを知らせるもので、そのデータを利用するか、EventBridgeを使用して次のサブスクライバーにメッセージを渡すことができます。
Christinaが説明したマイクロサービスの例と、このデータ処理の例の両方がKroリポジトリで公開されています。examplesセクションに行くと、microservicesとdata processorという2つの例があり、そのリンクにアクセスできるQRコードも用意されています。Emily、お願いします。ありがとう、Giedrius。素晴らしいですね。デモと、これまでの少し苦労の多かった経験についてお話ししましたが、開発者にとってより統合された体験を提供し、利用可能な様々なコンピューティングテクノロジーの世界の最高のものを提供することができるようになりました。
セッションのまとめと今後の展望
セッションから学んでいただきたいポイントを簡単にまとめて締めくくりたいと思います。まず、モダンアプリケーションを構築する際に、組織内で異なるテクノロジーを使用しているお客様が多くいらっしゃいます。モダンアプリケーションを構築する際のテクノロジースタックには、ContainerやServerlessの活用場所が確実にあり、また異なるワークロードを検討する際にはLambdaやServerlessの活用機会があります。以前は、チケット処理やTerraformパイプラインなど、開発者にとってデバッグが困難な経験でしたが、現在では使用できる新しいツールが登場しています。
私たちが話してきたAWS Controllers for Kubernetes（ACK）のようなオープンソースプロジェクトや、最新のKroなどがあります。これらを使用することで、全体像をまとめ、Kubernetesを通じてServiceリソースを完全にデプロイでき、組織内での開発を促進し、開発者にとって使いやすい環境を実現できます。最後に、Christinaが説明したように、開発者が自身でビルドできるようにすることが非常に重要です。そのための最良の方法は、APIを提供し、開発者が実際に触れて構築を始められるものを提供することで、現在のプラットフォームチームの負担やオーバーヘッドを最小限に抑えることです。
これらは、様々なコンピューティングの選択肢でモダンアプリケーションを構築しようとしているお客様にとって、うまく機能している方法の一部です。ここでQRコードを表示します。私たちが話した2つのツール、ACKとKroのコードです。Kroのexamplesをチェックすると、Giedriusが説明したすべてのものを見つけることができます。これらのコードサンプルは、すべてこのリポジトリに含まれています。セッションのフィードバックをぜひお寄せください。皆様のご意見や関心事をお聞かせいただければ幸いです。セッション後も質問にお答えできるよう、私たちはここに残っています。ご清聴ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion