人はなぜk8sを始め、そしてやめるのか
Mediumをみていたら、Kubernetes(以下、k8s)をやめたらDevOpsチームが幸せになった、という記事をみつけました。
有料記事なので詳細には触れませんが、記事を読む限りはk8sというインフラがチームに合っていなかったことは明らかだと思いました。
一般的にK8sは開発者の視点ではオーバースペックに感じることが多いと思います。
もし開発者自身に決定権があれば、CI/CDを考慮しても、本番サービスはECSやApp Runnerなどで提供した方が楽になるでしょう。
しかしK8sを喜んで利用する人達はそういう次元では考えていないと思います。
K8sの利点
K8sはフルスタック・インフラエンジニアにとっては魅力的で実際に便利なツールですが、その観点では次のような特徴が魅力的に映ると思います。
- 物理サーバーの統合
- アプケーションの集約
- ネットワークの統合
物理サーバーにはOSの管理コストやストレージ装置を含みます。
アプリケーションの集約には、複数のアプリケーションの共通部分をマイクロサービスのような形で実装・利用するといった変更を含みます。
最後のネットワークの統合というのはL2やL3レベルの機器統合だけではなく、ロードバランサーやL7レベルのFirewall/WAFやnamespaceによる通信の制御といった点を含みます。
ロールベースの権限管理によって1つのクラスターに複数のアプリケーションを混在させても、プロセスやネットワークなどの資源を安全に隔離できることが大きな利点だと思います。
この記事のきっかけになったMediumの記事では、K8sクラスターを1つの仮想マシンのようにアプリケーション毎に1クラスターといった運用を行っていた形跡があって、K8sの利点を生かせていないと思いました。
このような運用であればコンテナツール(docker/podman)の延長線上にあるECSのようなサービスが最適になるでしょう。
あるいはオンプレミスk8sクラスターをまったく持たずにEKSやGKSといったクラウドのK8sクラスターを利用するのであれば、ECSのようなコンテナサービスでほとんどのニーズは満たせるように思えます。
K8sが向かない用途
SIerがプロジェクト毎にk8sクラスターを構築するような使い方は、リソースの集約という利点が十分に活かせないため不適切な利用になる可能性が高いといえます。
SIer以外では、具体的に次のような利用方法が問題になるでしょう。
- アプリケーション単体を動かすプラットフォームとしてk8sを利用する
- 部署やチーム毎にK8sクラスターが存在する
- スケールアウトしないからベアメタルサーバーを使うべきなのに、k8sに全てを集約してしまう
- ミッション・クリティカルな業務アプリケーションの稼動にk8sを利用する
また、私はDevOpsという言葉は開発チームを主体に捉えているイメージを与えかねないので好きではありません。
そしてこの種の問題はそんな開発チームの存在感が大きいか、デリバリー・チームに発言力がないことに起因すると思っています。
セキュリティの観点からドメインを分離したい気持ちは理解できますが、顧客やアプリを別々のクラスターに分散させてしまったことで、統合・集約というk8sのメリットを十分に引き出せなかったのではないでしょうか。
またミッション・クリティカルな業務向けのアプリケーションであれば、不確定要素を削除することも大切で、抽象度の高いインフラの選択にはリスクを詳細に分析することが必要になります。この観点ではECSなども同様に不適かもしれません。
しかしHigh-Availability(HA)構成で十分な用途、おそらくほとんどのWebアプリケーションが該当すると思います、であればk8sは最適なインフラになるでしょう。
k8sをやめてしまう理由
始める理由はそれほど深刻ではないのだと思います。流行っているということもあるでしょうし、GoogleのBorgが元になっていることなど、k8sへの関心が高いことは間違いありません。
コンテナ・オーケストレーションという概念が、DevOps開発において重要であるかのように喧伝されていることも大いに影響していると思います。
関心の高さや、CI/CDとの関連からk8sに手を出してしまうのだと思いますが、やめてしまう背景には開発チームがk8sの運用面に手を出してしまうこともあると思います。
Mediumの記事を書いたチームが幸せになった理由には、k8sをやめた事ではなく、本番環境のインフラを1つに統一した事が本当の理由ではないでしょうか。
本来は規模の大きなk8sクラスターの中に、自分たちが強みを持っているビジネスロジックを共通コンポーネントとしてデプロイし、それらを利用する個別アプリケーションを別々のnamespaceにデプロイするべきだったのだろうと思います。
共通部分のほとんどないアプリケーションを分散したk8sクラスターにデプロイしたとしても、管理コストが増えて幸せにはならないだろうなと記事を読みながら感じたところです。
開発チームが主体となってK8sクラスターを管理することは問題か？
一般的にK8sは複雑なシステムだといわれています。そう感じる理由には開発者が「アプリケーションを安定稼動させる」目的からは過剰に思えるような選択肢が用意されていることがあると思います。
K8sを導入して幸せになる組織
まず組織のインフラ基盤として自社のためにk8sクラスターを整備することには多くのメリットがあります。
デリバリー・チームがk8s環境を整備し、利用できるMiddlewareやストレージ基盤、他のサービスを整理して開発チームに提供することで管理コストを下げることが可能になります。
開発チームが使いたいミドルウェアを全て提供するようなことをするべきではありません。
従業員の認証基盤をk8sのサービスとして共通利用するといった統合化はセキュリティ上だけでなく、全体最適を促すため経営的な観点でも理想的といえます。他のサービスについても同様にデリバリー・チームが中心となって提供するべきです。
開発チームはミドルウェアレイヤー以下について自由な選択肢を失いますが、本来あるべき姿とはそういうものです。
K8sを導入しても幸せを感じられない組織
反対に必要に応じてアプリケーション・サービスを様々な会社から購入するような組織であれば、k8sを整備しても購入先の選択肢が狭まってしまいメリットがないでしょう。
SIerのような受託開発を行うチームや組織がK8sを利用することにも、CI/CDの恩恵はあると思いますが、コンテナ化には意味があっても、本番環境をk8sにするまでのメリットはあまりないと思います。
いずれも完全仮想化の方が幅広いニーズに素早く答えられるはずです。
K8sをやめたくなる組織はDevOps, CI/CDを実践しているといっても、実際には受託開発をメインとするような業態ではなかったのかなと思われます。
認証基盤やストレージ装置の統合といったニーズがなく、もしセキュリティ上の理由で環境を分割するように求められるのであれば、サーバーの統合といった本来のメリットはそのままデメリットになってしまいます。
さいごに
コンテナを利用することで全てのチームメンバーに大きな恩恵があることは間違いないでしょう。
K8sはとても便利なインフラ環境ですが、そのコンテナ・オーケストレーションという機能は必ずしも全てのメンバーに恩恵があるとは限りません。
開発チームがシステム構成について決定権を持っているようであれば、その組織にはK8sは適応しない可能性があります。
例えばLAMP環境での動作を前提としているような既存のWebアプリケーション・フレームワークはスタンドアロン型での動作に最適化されていて、マルチテナント型システムでの動作に対応しない場合があります。
ホスト名やURLパス(context-root)の専有を必要とするWebアプリケーションは有名、無名を問わず多く存在します。
いずれにしても開発チームが作りやすいシステムと、組織のトータルコストを低減するためのシステム・アーキテクチャの間にはトレードオフが存在します。
K8sは必ずしも全ての組織に恩恵を与えるシステムではありません。
またDevOpsという言葉があまり好きではない理由は、Dev"→"Ops というフローを感じるからです。
オペレーションの最適化のために運用チームが力を発揮するべきだと思うのですが、開発チームが工程の上流側にあることで運用チームには決定権のない場合がまだ多いのではないでしょうか。
O'Reillyから出版されている「SREの探求 (Seeking SRE)」ではSREチームへの権限の委譲、運用メンバーのエンジニアリングチームへの参画など、運用重視による全体の見直しがキーであることは繰り返し述べられています。
運用チームを下流工程の仕事だと位置付けている間は、SREやDevOpsの理念を実現することは難しいでしょう。
開発者のk8sに対するネガティブな反応は、本能的に自分達の活動に制約が導入されることに気がついているからかもしれません。
いっそk8sの運用に最適化した形で組織体制を刷新できれば良いのですが、それは革命であって感情面も含めてチームがバラバラになってしまいます。
メンバーの協力を得て穏かな体制の転換を徐々に図るようなk8sの導入や全体最適を図ったアーキテクチャの浸透を模索していき、開発者が喜んでk8sベースの環境を受け入れる道を模索していくことが肝要でしょう。
TODO: Qiitaに投稿するならコードをきちんと含めること。