Amazon EKSによるプラットフォーム・エンジニアリング

Pulisher : Strategic Tech Center チャン・セジョン
Description : EKSで内部プラットフォームを構築・拡張する事例紹介

はじめに

普段EKSに関心があり、これまでEKS業務をしてきたので、EKSをプラットフォームとして選定して使用する場合、プラットフォーム構成をどのようにするのかについて知りたく、それと一緒にCI/CDシステムも良いリファレンスがないかと思い、セッションを申し込みました。

セッションの概要紹介

プラットフォームの実装、プラットフォームの実装パターンとベストプラクティス、つまり、EKSで内部プラットフォームを構築して拡張する事例について学ぶセッションです。

会社ごとに各チームがあり、各アプリケーションがあり、そして各インフラ資源があります。これらをどのように分け、どのように管理するかを定義し、構築及び運営するのがPlatform Engineersの役割と言えます。

プラットフォームエンジニアと開発者の間で、エンジニアは安定的で標準化された運用を目指す一方、開発者は運用が自動化されたシステムを望みます。

一方、開発者は運用が自動化されるシステムを望みます。 そのため、どちらかに偏ることなく、両方が適切に包含されるようにするのもプラットフォームエンジニアの仕事です。

今日のプラットフォーム設計は、各サービスごとに分けることを考慮しなければなりません。aws account別、テンプレート別、クラスター別、名前空間別、プラットフォーム別など、サービスごとに分けて独立して動作させることを考慮しなければなりません。

中央管理用アカウントと各テナント別アカウントを分離して、テナントアカウントではアプリケーションPodとそれに関連するALB、S3などのリソースを生成し、中央管理用アカウントではCI/CDやクラスターConfigを管理するようにします。

DevOpsのパターンを見ると、開発アイデアから開発ソースをビルドし、デプロイして、テストやモニタリングを通じた運営をすることになりますが、これが継続的に循環しながらDevOps業務の循環が行われます。

DevOpsの業務循環をWorkFlowで説明した図で、DevOpsの基本的な基盤はObservabilityを通じたモニタリングを基本根幹として、継続的なモニタリングと継続的なデプロイメントによるサービス運営を追求することになります。

構築/運営とそのポリシーガイドから開発者とのコミュニケーション、顧客とのフィードバックなど、単純なインフラ的なことだけでなく、コミュニケーションと協議がより重要な業務領域であることが分かりました。

セッションを終えて

セッションを聞きながら、プラットフォームエンジニアリングはソフトウェアを提供し、ライフサイクルを管理するためにセルフサービス機能を設計・構築する分野であり、内部ユーザーに共有インフラストラクチャープラットフォームを提供することを学び、プラットフォームエンジニアの最も重要な目標は開発者の生産性を向上させることだと感じました。一言で言えば、プラットフォームエンジニアの役割が非常に重要だということでした。