Kubernetesをうまく扱うためのエンジニアチーム

すっかり年が明けて2ヶ月ほど経とうとしていて、年始に決意した今年はブログ頑張るぞという気持ちは雲散してしまったような気がするのでブログを書きます。

弊社のエンジニア勉強会で話そうと思ったけど内容がまとまらなかったネタを元にした怪文書になります。 マイクロサービスとk8sについてまとめた内容ですが、オチは特にありません。

k8sをうまく使うにはアプリケーションのコードだけでなく、アプリケーションをコンテナにビルドしクラスターへデプロイしk8sオブジェクトのDepoloymentでPodを管理してエンドポイントをServiceやingressとをうまく連携させて疎通をとって・・・というやたらと複雑な手順を踏まなければなりません。

当たり前の話ではあるのですが、一つのアプリケーションを運用するのに、そのアプリケーションが連携する全てのk8sオブジェクトの状態を把握する必要があります。このような複雑なk8sオブジェクトの連携が「k8sは敷居が高い」と言われる所以です。

ただ、忘れがちなのはk8sはコンテナオーケストレーションツールである以前にマイクロサービスアーキテクチャのためのフレームワークでもあります。一見、複雑なk8sの運用でもマイクロサービス一つに対しての開発でなら、多くの機能を必要とはしませんし、サーバーに一からデプロイするよりは圧倒的に開発も楽です。マイクロサービスを開発するには「大きなシステムを開発する大きな組織」は適していません。

k8sを運用していくには、k8sに適した開発組織になり、牽いてはマイクロサービスを開発するのに適した自律したチームにしていく必要があります。

ある程度大きな会社組織としてはインフラチームとアプリ開発チームが別れているのが一般的です。

• サーバに載せたもののテスト: QAチーム
• サーバに載せるものの開発:　アプリ開発チーム、プロダクトチーム
• サーバに載せるもののデプロイ: インフラチーム
• サーバの運用・監視:　運用チーム

こういった組織構成に問題となるのは、どのチームがどこまでの範囲でプロダクトの面倒を見るのかという境界が不明瞭になることです。いわゆる責任分解点とか呼ばれたりするやつですね。

インフラの管理とサービスのバックエンド開発、または運用との守備範囲が曖昧だと、野球で例えるとポテンヒットのようなお互いの境界が曖昧な場所での不具合が発生する可能性があります。往往にして、このような境界が曖昧で不明瞭なタスクというのは属人化され、積極的にこのような境界を見に行こうとする視座の高いエンジニアの負荷になりがちです。

また気づかない人は気づかないのでチーム内でのタスクの格差も生まれてしまいます。落ちた球を拾える能力というのはとても素晴らしいスキルでもあるのですが、そのような視座の高いエンジニアに全てを任せるのではなく、全員で落ちそうな球を拾いに行けるチームというのが組織として一つの理想であると言えます。

専門ごとのチームが分かれていると技術領域ごとのサイロ化が進み、自分のチーム以外の箇所がブラックボックスし、障害が発生した際の原因究明や対応が遅れたりする恐れがあります。また、インフラチームやサーバサイド部門というのは少人数で回していることも少なくありません。組織のスケールアウト時において、サービス開発における中間部門にタスクが集中しボトルネックとなります。

このような問題点から、近年ではマイクロサービスアーキテクチャが提唱され始め、それをうまく扱うための組織開発というものが必要になってきました。

”you build it, you run it”という言葉があります。

これはアマゾンのCTOの言葉だそうですが、機能ごとにサービスを細かく分割し、チームそのものも小さなサービスを開発からデプロイ、運用までの全てを担当するという思想を表しています。 マイクロサービスとはサービスの大小を表した言葉ではなく、独立したチームが自律して開発を行うということを目指している思想であるといえます。

従来では職能ごとの横割りのチームでしたが、マイクロサービスでは開発、デプロイ、運用までをこなせる縦割りの組織構成が求められます。チームの技術選定は大きな影響を及ぼしません。各チームごとに好きな技術、必要な技術を用いることになります。アプリケーションをデプロイする共通の基盤となるのが、Kubernetesですが、Kubernetesの機能の一つであるNamespaceごとにシステムを設計することができます。

例えば、

• １チームにつき１マイクロサービス
• １マイクロサービスにつき１Namespace
• インフラチームはNamespace: kube-system をみる

というような運用ができます。

今まで「ミドルウェア」や〇〇（何かお好きなサーバーレス、フルマネージドサービス）で区切られていた部分を丸っとKubernetesのnamespaceごとに各チームの守備範囲を分けることができるわけです。

インフラエンジニアとしての仕事のあり方も大きく変わってきます。自律したチームが構成されると、全員がKubernetesを利用する状態となります。Kuberentesだけではなくそのチームの中で開発からデプロイまでの全ての作業が必要となるわけですから、今で開発だけに集中していればよかったエンジニアに他の領域のデプロイ、運用やテストなども任せていかなければなりません。

このような中でのインフラチームとしての責務はインフラ領域についての専門エンジニアという職能以外に、多くのエンジニアがインフラ領域を扱えるようにするということではないかと考えます。社内のKubernetesの相談の窓口となって問題を解決したり（あくまで運用するのはサービスのエンジニア）、デプロイのパイプラインを整備したり、インフラ分野に対して各チームが自律することを促すための機能が求められるようになるのではないでしょうか。

マイクロサービスアーキテクチャのゴールは各チームが自律することなので、最終的にはインフラチームが不要になるという話にもなるわけですが…。

まぁそれはまだ先の将来の話になるでしょうし、やっていくしかありませんね。