概要

2024/9/26に開催されたAWS Innovateのうち、受講させて頂いた林政利様による「Kubernetesベースの開発プラットフォームの実現 ~理想の開発者体験を提供するための考え方とプラクティス~」を受講したので簡単に内容についてまとめた。

公式サイト(下記リンク)から30分程度の講演視聴が可能。
https://resources.awscloud.com/aws-modern-applications-innovate-jp/2024-aws-innovate-mmb-t5-3-jp

発表内容

ゴール

・Kubenetisを利用したプラットフォーム構築のベストプラクティスを知る
・Kubenetisで開発者体験を改善する手法を学ぶ

目次

1.Kubenetisプラットフォーム構築でよくある課題とその対策
・1-1 よくある課題
・1-2 対策

2.担当領域の明確化とその必要性
・2-1 担当領域の明確化
・2-2 明確化しなかった場合のプラットフォームチームの負担
・2-3 明確化しなかった場合の開発チームの負担

3.プラットフォームの実現方法
・3-1 仕様を明確にする
・3-2 開発とプラットフォーム両方を考慮した仕様を作る
・3-3 リソース管理は任せる

1 : Kubenetisプラットフォーム構築でよくある課題とその対策

1-1 よくある課題

DevOpsとクラウドサービスの台頭によってCI/CDの導入やOSSが発展し、開発におけるアジリティー(構築の俊敏性)は近年で大きく向上した。しかしその反面、開発チームがそのメリットを享受するためには膨大な数のサービスやツールについて習熟しなければならなくなってしまった。

1-2 対策

肥大化した開発チームの負担を減らすためにも、習熟コストを払うことなく利用できるような"隠蔽されたプラットフォーム"が今強く求められている。以降はこの隠蔽されたプラットフォームの実現方法について記述していく。

2 : 担当領域の明確化とその必要性

2-1 担当領域の明確化

隠蔽されたプラットフォームを実現するためにはまず、開発チームとプラットフォームチームの担当領域(責任範囲)を明確に分ける必要がある。

2-2 明確化しなかった場合のプラットフォームチームの負担

AWSにおけるマネージドサービスを活用したアプリケーションの運用環境はそれ自体がプラットフォームであり、統制の管理は基本的にプラットフォームチームが行う。運用環境は近年では複雑化してきており、AWSのようなクラウドサービス以外にもオンプレミス、VMから複数種類を環境の土台とした設計がなされる場合も多く存在する。プラットフォームチームはこのような複雑化した土台の上に複数のコンポーネントを構築していくため、作業には非常に多くの労力と神経を使う。

またコンポーネントの改築の際には作業のタイミングや影響領域といった面で開発チームとの折り合いを付ける必要があり、更に多くの労力を割く必要が生じてしまう。

2-3 明確化しなかった場合の開発チームの負担

Kubenetisを使用することでこの問題は容易に解決することが出来る。しかし今度は開発チームが主体となってコンテナ管理やアラート、スキーマといったような様々なコンポーネントを管理しなければならなくなり、これが前述した開発チームの学習コスト・管理コストの負担増大につながってしまっている。

よくある例としてコンポーネントの管理を進める中で複数チーム間の設計思想が大きく異なり、最終的に出来上がったKubenetisの環境がバラバラになってしまう事例も多く存在する。これはコストの増加のみならず、新規に参加した開発者の学習コスト増大にも繋がってしまう。またプラットフォームチームとの責任範囲が曖昧になってしまい、トラブルが発生した際の解決遅延に繋がる事も少なくない。

3 : プラットフォームの実現方法

3-1 仕様を明確にする

担当領域を明確に分けるにはまずプラットフォームの仕様を明確にする必要がある。仕様を明確にするとは開発チームが"そのプラットフォームで何が出来て何が出来ないのか"を明確にするということである。

　仕様書を作成する際のコツとして開発者が開発に関する事だけ認知すればいいようにすることが大切である。これはOSSツールであるKubelaを利用することで実現可能である。

　またAmazon CodeCatalystやOSSのBackStageを利用することでテンプレートを作成し、開発者のデプロイに関する負担を下げることも効果的である。

3-2 開発とプラットフォーム両方を考慮した仕様を作る

KubenetisはシングルテナントのシステムなのでKubenetisのアップグレードや機能追加の際には設計を考慮していなければすべてのチームに影響が及んでしまう。

ここで言う考慮されていない設計とはプラットフォームとチームが密結合してしまっている状態を指す。密結合はプラットフォームの設計の際に、その仕様を明確することで回避できる。具体的にはメンテナンスやその影響を開発チームとプラットフォームチームが双方に理解しやすい形で明記する必要がある。つまり双方におけるルール作りを進めるという事になる。

プラットフォームの仕様書によってメンテナンス時期や影響を把握することで開発者側はダウンタイムを意識することなく開発を進められる。プラットフォームチームは開発チームが仕様に準拠している前提でメンテナンスを行うことが出来るため、余分なメンテナンスのコストを割く必要がなくなる。
　これらの点から双方にとっても仕様書の作成は大きなメリットを生み出す事が分かる。

3-3 リソース管理は任せる

さらに担当領域の明確化を行うためにはKubenetis上のリソース管理を自動化してしまうのが有効となるKubenetis上ではすべてのワークロードがリソースを共有する。よってどこにどれだけのリソースを割くのかを人力で計算するのはかなりの負担となる。

またノード管理の自動化によってオンデマンドなリソースの起動以外にも、テナント毎のコスト管理を実現することが出来る。チームごとのリソース使用料やコスト把握が可能になるため、このような別の側面からの明確化も行えるようになる。

最後に

講演を受講する事でKubenetisを用いた開発プラットフォームの実現に関するベストプラクティスについて改めて考える事が出来た。デプロイやテストの行いやすさが注目されがちな分野だが、その実現にあたり開発チームのみならずプラットフォームチーム側を含んだ双方にとってメリットのあるような設計を第一優先として行う必要がある点は、見落とされがちな点のように感じた。

今後開発環境の構築を行う機会がある際は改めてこの視点に立ち返ってみたい。