[re:Invent 2023 レポート] Platform engineering with Amazon EKS

Introduction

AWS Re:Invent のセッションの内容をレポート形式で投稿します。

今回は  Platform engineering with Amazon EKS のセッションの内容を咀嚼したものを記し、 Next Action の体験を記載しています。

Description 

A wide range of companies, from the most innovative startups to the world’s leading enterprises, are running their internal platforms on Amazon EKS, helping them to accelerate developer velocity and increase the pace of innovation. In this session, learn about best practices that AWS has developed over years of helping thousands of customers build and scale their internal platforms on Amazon EKS.

最も革新的な新興企業から世界をリードする企業まで、幅広い企業がAmazon EKS上で社内プラットフォームを運用しています、 開発者のベロシティを加速し、イノベーションのペースを高めるのに役立っています。 このセッションでは AWSが、Amazon EKS上で社内プラットフォームを構築し、拡張する何千ものお客様を長年にわたって支援してきたベストプラクティスについて学びます。

Agenda 

アジェンダは以下の流れの通りです。

EKSの視点からプラットフォームエンジニアリングをどのように見ているか？この解釈の定義と、プラットフォームエンジニアリングへの投資を通じて実現できるメリットの話です。

その後、具体的な事例を挙げ、ここからベストプラクティスへと話が移ります。

What is platform engineering ? 

会社や組織にクラウドを導入している場合、アプリケーション毎に開発、保守チームが多く存在し、これらはそれぞれのインフラストラクチャ上に様々なサービス、アプリケーションを展開しているものと思います。ここにおけるインフラストラクチャは AWS でいう、EKSやEC2、データベース、ストレージ、さらにはネットワーク、監視サービスなどが含まれるケースもあります。

クラウド全体の視点から見ると、これらは単一のアプリケーションとしてではなく、全体として費用対効果の高い方法を見つける必要性があります。

複数のアプリケーションを実行する中で、費用がかかるインフラの管理自体は誰が担当するものでしょうか？この問題を解決する選択肢はいくつかあると思います。

まずは、アプリケーションを構築するチームが、アプリケーションに必要なインフラを展開、保守を担当するという考え方です。これは運用におけるトラブルシュートを含めて担当するという意味合いになります。

一方で、インフラストラクチャを一元化する事も出来ます。インフラストラクチャサービスをプラットフォームとして抽象化するチームが中央に存在し、それらをアプリケーションチーム単位に提供する事で、アプリケーションチームがインフラの管理責任を軽減する事が可能というものです。プラットフォームエンジニアリングの概念は、後者に傾向にあります。

ここにおける抽象化は、実際の組織においては要件が異なるため、様々な部分に焦点が当てはまります。例えば、一部のアプリケーションではインフラの制御が必要と考えている、他のアプリケーションでは、コンプライアンス要件がある、などです。

プラットフォームエンジニアリングは、これらの組織の固有の要件を満たすコンピューティングの抽象化を特定、構築し、効率的にコスト効率よく導入を行う実践であると考えます。

プラットフォームの構築は投資であり、時間と共に利益やメリットを得られる事が期待されます。ここでは、EKS を社内プラットフォームとして構築した成功例を元に、ユーザーが得たメリットをについて触れます。

一つ目は 速度 です。

これは独自のプラットフォームを展開する必要がなくなるため、開発者のコードがサービスへ提供されるまでの時間が短縮する事が出来る点です。

二つ目は ガバナンス です。

ここにおけるガバナンスは信頼性やスケーラビリティ、セキュリティなどを包括したものです。

全てのアプリケーションは、自動化された方法により、各懸念事項に対する要件を満たす事が出来るという点です。アプリケーションチームは、プラットフォーム上に組み込まれた標準化された構成を享受する事ができるため、独自に構成を行う必要性がなくなります。

三つ目は 効率 です。このうち、システムのコスト効率と、人的資本の効率の二つの観点があります。

システムのコスト効率という観点では、マルチテナントあるいはコンテナ化された世界において、プラットフォームを構築する事で、別のチームの複数のワークロードを同じ基盤となるホストから実行できるという点です。人的資本の観点では、開発者が個別のインフラストラクチャ―専門の知識を持つ必要性がなくなり、人的コストを節約できるというものです。

Platform Implementation Patterns 

プラットフォームエンジニアや DevOps チームの存在の脈絡の１つには、開発者やデータサイエンティストが何を望んでいるかという点があります。好きなフレームワークを使って、コード開発を行いたい、といった自由を開発者は望んでいると考えます。一方で、プラットフォームを作るチームは、ガバナンスの標準化を行う事を必要とされ、また、先述した開発者へ自由を提供しすぎるが故に、セキュリティやコストの問題に衝突するケースもあるかと思います。

プラットフォームエンジニアは、これらの問題に直面した際の課題解決を、下記のように領域毎に触れています。

まずは、所有権に関してです。これは、プラットフォーム自体を誰が所有しているのかという概念です。これついて、プラットフォームエンジニアは、プラットフォーム自体をプロダクトとして認識し、取り扱う必要があると言います。そして、顧客は、提供する開発者やデータサイエンティストであるという事です。

続いて抽象化のレベルです。ユーザーは、AWS アカウントが欲しいのか、クラスターが欲しいのか、コードを push できるようにしたいのか、要求にはばらつきが存在し、ここに対する境界線がどこにあるのかについて不明瞭です。このばらついた要求には、サービスとして正しい基準があり、プラットフォームは、それらの問題を全て解決できるものであるという事をお伝えできれば良いと考えると言います。

上図の Trobleshooting については、"分離" という考え方に沿う必要があります。これらは、提供されるプラットフォームが AWSアカウント毎であるのか、リージョン毎であるのか、ネットワーク、クラスター、ネームスペース毎など、開発者は一定の分離された環境が必要となり、分離された環境がある事でトラブルシュートを行う事が出来ます。

この分離された環境をデザインするためには、プラットフォームとしてのサービスがどの位置付けにあたるのかを考え、それぞれの選択に対して最適化を行っていく必要があります。これらは、いずれもの選択においても欠点は必ず存在し、これらを考慮した最適化を実施する必要があります。

つまりは、万能なアプローチというものは存在しない。という事になります。

では、これについてどのように考える必要があるかという点について下記が言及されていました。

組織にあるワークロード、データをプラットフォームとしてサポートする必要がある場合、ビジネスドメインを発端として逆算して作業を行う事です。なぜなら、ビジネス機能を果たすアプリケーションを構築していくからです。

再利用可能で双方向の利用が可能なモジュール単位に分類し、開発者にとって必要なパーツを逆算して考慮していく必要があります。ここには多岐にわたる依存関係が発生し、それらを考慮して構築をする必要があります。

しかし、プラットフォームを構築していくプロセスにおいて、EKS は多くのツールと選択肢があります。

下図は Argo CD、OPA、CrossPlane や ACK を使用して、kubernetees 上から RDS、S3、ALB、SQSなどの外部サービスをプロビジョニングして管理している例です。Cross Plane を使用して、クラスター(Data plane)を作成、プロビジョニング、アップグレードする機能も持ちます。また、backstage アドオンを使用し、ソフトウェアのカタログサイトを作成出来ます。

但し、これらのツールを利用にあたっては、先述したサポートする必要のあるモジュール、パーツを逆算して、用意し、検討していくことが重要な点であるという事になります。

Platform best practices / guidance

最後に要約です。

• プラットフォームの構築において、最大な間違いの１つは、スポンサーやワークロードなく何かを構築するという事です。予め、複数のワークロードを持ち、顧客(開発者)、エンジニアと一緒にプラットフォームを作り上げていく事が一番の成功になると考えます。そして、これらのユースケースを活用していくことで、例えば、ステートレス、あるいはステートフルなワークロード、リクエストが多いアプリ―ケション、大規模なアプリケーションなどとパターンを作っていく事です。
• 回避策を用意する事です。１つの選択肢が全てのワークロードに適合するわけではないため、個別の問題点がどこにあるかを捉えて、柔軟に変更が出来る、選択肢を用意する方法を学んでおく事です。例えば、サービスとしてのドキュメントを事前に用意しておいたり、承認方式を設けるなどです。
• ドキュメントと教育は、プラットフォームの取り組みにおいて重要な部分です。プラットフォームを利用するにあたって、ユーザーが何をしたいのかを考えて、教育を行う事が良いでしょう。

Next Action 

本セッションでは、Amazon EKS を体系的に学ぶ AWS skill Builder  Amazon EKS - Knowledge Badge Readiness Path が紹介されました。

最終的な試験を経て Badge が取得出来る本パスは、コンテナ、Kubernetes のイントロダクションから Amazon EKS までを体系的に学ぶことができます。

コードから見るマニュフェストファイルの詳細な定義方式や Helm の解説、セキュリティ、可観測性などレイヤ別のコンテンツがありましたので、側 のみを理解出来るというものではなく非常に分かりやすいコンテンツでした。

なお、具体的な日付までは確認出来ませんでしたが、バッチの公開自体が re:invent の週のようなため、コンテンツの情報自体もかなり最新のもののようです。

最終的な試験は 50問で、正答 80% を超える必要がある非常に難しい試験でしたが、合格するとバッチが取得出来ます。

体系的に学習が出来るため、学習コンテンツとして非常に意味があるものと感じました。また、これを学ぶことで、Kubernetes の奥行きと、本セッションの意義を少し実感する事が出来た気がします。

是非挑戦してみても良いかもしれません。

以上となります。最後まで御覧いただきましてありがとうございました。