最近 Kubernetes 全然触ってねーなって思ってたところに、『6年ぶりぐらいにクラウド使った結果、Kubernetes以外のマネージドサービスとか基本要らなくない？となった話 – データエンジニアの酩酊日記』を見つけて、自分と異なる立場によるコンテナシステムへの感想を興味深く読ませていただきました。
Kubernetes を推す人がいる一方で、ここには昨夏『Kubernetes、はじめました』と言っておきながら今年に入って全然触らず、ECSを使ったシステムばっか手掛け、Kubernetes いらなくね？って思う人もいるわけで。これはいったいどういうことでしょう、と雑感タイムです。
どうしてコンテナシステムで迷うのか
最初に断っておきたいのは、以下 Kubernetes を否定したり腐すような意図は全くなく、なんでやろ？って自身に問いかけた私見です。やめました、と言ってもウチで今も使ってるサービスもありますし、研究開発としてはいったんやめました、また採用を視野に入れる可能性はあります。というのが正しい表現になります。私が触れたK8sシステムとしては、
- AWS EKS
- Fargate for EKS
- GCP GKE
- Cloud Run for Anthos
- Cloud Run (full managed)
があり、クラウドかつマネージドであることを前提として選択しています。始めた時期的に Kubernetes をイチから構築することはそもそも除外しており、ヌルいユーザーの部類に入るでしょうが、インフラの選定ポリシーとしてこの２点を重要視していることに起因します。
- 耐久力がある（安全・安定・拡張性）
- 運用しやすい（シンプル・複製・人材・費用・長年継続）
私のところの場合、複数のWEBサービスを提供することが主な目的になりますので、１サービス１アカウント（GCPの場合１プロジェクト）で、WEB・DB・KVSを基本として、必要ならクラウド特有のサービスも利用する、という感じでベースとなるインフラを用意・提供するわけです。
そういう条件下において、(1)従来のインスタンス構成 (2)ECSなど独自コンテナ (3)マネージドKubernetes でやってみた時にどうなるか、というと……新しいシステムほど怪しい部分はあるものの、どれも概ね要件を満たして構築はできるのです。
インスタンスからコンテナに基盤を変更して、開発効率など改善していくことは確定事項として、ではどれも要件を満たせることがわかった上でどれにしようか、となった時に絶妙に微妙な選択分岐点が迫ってくるわけです。
どれでも十分な機能と品質なら！
最もワードパワーが強そうな Kubernetes にすればいいじゃない？
外部へのアピールや、エンジニアのモチベーションにもなるでしょ？
と、なぜ安易にならないのか。
わりと安定して運用された実績があるっぽいよECS！
魔法の言葉・ベンダーロックイン！
なんで最先端で標準ぽい Kubernetes にしないの？
と、なぜ選択肢に割り込んでくるのか。
おそらくそれは Kubernetes が、時代とエンジニアに依存する割合が大きいがために、選ぶも地獄、選ばぬも煉獄という立ち位置で前衛に陣取ってるからじゃないかな～と感じています。
Kubernetes はどうだった？
Kubernetes の良いところというか最大の特徴は抽象化にあると思っていて、どの環境でもリソース種別ごとの扱い方は等しいし、クラスタ配下の扱いはその世界に閉じている。それによって、オンプレミス⇔クラウド や クラウドA⇔クラウドB そしてマルチクラウドまで視野に入れた動向があり、外殻的にも内部的にも流動性が高い（トーシローなので、だいたい合ってることにしてちょ）。実際に調べたり動かしたりして、なるほどと納得する仕組みや、良い挙動だと思う部分、など多く感じる一方で、わりと高い目線で開発されているであろう Kubernetes のうち、実現している内容は既存システムのリプレースに過ぎないのでは、という状況に気づきます。
それ Kubernetes である必要がある？
WEBサービスという用途に限っていえば、極端に言うと、負荷の増減に対して安全・安定にサービスが提供されれば目的が達成されるわけです。リソース量が不足せず、リソースダウンをカバーする仕組みがあれば、あとは確保したリソース量に対して、どれだけ良いコストパフォーマンスでリクエストを捌けるかという話になるわけで、コンテナシステム自体はそれに大きく影響できるわけではありません。もちろん、特定のコンテナシステムの理解を深めて工夫することで改善の余地はありますが、一定以上のリソース効率を確保するならば、その差よりも、圧倒的にアプリケーション自体の品質による影響のほうが大きいでしょう。
もし得られる結果がただのリプレースに等しいのであれば、より簡素な仕組みのシステムを選ぶことにメリットを見いだせますし、もし Kubernetes を選ぶのであれば、その学習コストに見合った相応の理由・打算なくしては、エンジニアのエゴと捉えられても仕方ないところかと思います。
Kubernetes は学習コストが高い？
何と比較するわけではないのですが、色んなインフラシステムを構築した経験からすると、Kubernetes 自体はしっかり理解するならば、かなり学習コストが高い部類になると思います。クラウドのマネージドになると、Kubernetes 自体の学習量はコントロールプレーンの分が減少するものの、抽象化して扱われる各クラウドリソースについて学習しなくてよいかというと、そんなわけもなく、特徴や関連性について学習することになるため、はいポチりましたで終わるものではありません。
仮にEKSをマスターしたからといって、GKEもすぐ動かせられるかというとそんなことはなく、周辺リソースとKubernetesクラスタの差分について学習する必要があります。Docker や Kubernetesリソース を扱った経験はある程度持ち越せますが、Kubernetesクラスタも、クラウド間で同じかといえばそうでもなく、イケそうに見えて細かいところで勝手が全然違うぞって感覚になると思います。
ECSならばAWSに慣れていれば、DockerをAWSで動かす、という感覚になりますが、マネージドKubernetesだと、Dockerをクラウドという箱の中にあるKubernetes世界で動かす、という２重構造になります。学習総量が近しいとするならば、当然２重の方がツラぽよなのは想像に難くないでしょう。
抽象化って必要ある？
私もエンジニアの端くれなので、マルチクラウドの話など興味はあるわけです。では、仮にクラウド間の互換が強固になったり、複数クラウドで並列稼働ができるとしたらどうか、と問われるならば、別にそれほど必要ない。という答えになるでしょう。一般的なサービスにとって、別リージョン・別クラウドの話が出るとしても、せいぜい最悪を想定したバックアップ置き場だったり、別クラウドにしかない特有のシステムをどうしても使いたい、程度であって、頻繁な移動を前提とすることはないし、巨大なプラットフォームを扱うということもない。
となれば多くの場合、１つのクラウドの理解を深め、使いこなすほうが圧倒的に速いし効率が良くなるでしょう。１箇所でやりくりする前提ならば、抽象化レイヤーの必要性は相当薄まるわけです。ベンダーロックインを唱えられても、どのクラウドでどのマネージドサービスを選んだとしても、必ず一定以上のロックがされることになるわけで。
Kubernetes 側から見れば、抽象化によってその世界に閉じようとすることを正とするかもしれませんが、クラウド側から見ると、それは必ずしも正ではない、ような関係性にみえます。
インフラ環境は、３～５年スパンでみれば移動イベントが発生する可能性がそれなりにありますが、１～２年程度だとインフラの心配よりもまずサービス継続の方が大事になるので、サービスが生きるか死ぬかという時期に、人的リソースを割いてまで抽象化を重要視するわけがないのです。
じゃあなんでこんなに世間は Kubernetes 色が強くなってんのか？っていうと、ぶっちゃけ私には理解できません。１つの大きなサービスに長く注力するならともかく、複数の小～中規模のサービスに適用していき、それぞれの部署で汎用的に運用できるようにしていく── そんなイメージは、触り始めた最初から最後まで持てませんでした。
Kubernetes に対する姿勢の違い？
Kubernetes 目線？
Kubernetes 経験者による、システムの良さを見ていると、それはそれで納得のいくものも多くあるのですが、それ以上に失敗談や反省談の方が説得力があるのが現実な気がしています。それでももし、Kubernetes でほとんどの仕組みを表現できることがわかっていて、Kubernetes で導入してくれって言われたら、Kubernetes を最も扱いやすいクラウドを選定するし、可能な限り Kubernetes にリソースを寄せるでしょう。
それが十分なスピードで、十分な品質で、中長期的に運用できるものであれば、抽象化の特徴も相まって、より成功と言えるシステムになる可能性は高いです。
ただしその成功をもってしても、変化速度と難易度による、時代とエンジニアに依存する特性を打ち消せるわけではありません。大半のエンジニアに理解がある環境ならば問題ないですが、一部の物好きによる成果物の場合、変化に追随するリソースを確保できるのか、退職時に技術的負債とならずに引き継ぎができるのか、というリスク・不安は残るでしょう。
クラウド目線？
うってかわって私のようなオンプレ・クラウドへと地道にインフラに関与してきてエンジニアが、Kubernetes を動かすぞとなると、どうなるか。どうしても、それまで構築してきた仕組みや知見を土台にし、そこに Kubernetes を載せようという考えになります。私の場合、AWSのリソース構成、Terraform による構築、監視などの補助システム、などが強みです。複数サービスの面倒を見ることが前提になると、これらを崩すことは既存サービスとの大きな差分が発生し、運用コストが増加することは目に見えているので、できるだけクラウドの構成を保ちつつ Kubernetes を稼働させようとするのは当然です。
もし、Kubernetes の良さが、Kubernetes に寄せることによって発揮される性質であるならば、Kubernetes を推してくる意見と噛み合うわけがないんですね。寄せる気が限りなく薄いのですから。
インフラの運用において、例えば経営陣あたりから、インフラ費用が半分になる契約をするから、クラウドの引っ越しをしてくれ。と言われたら、はい、面倒ですけどそれはやるべきですね頑張ります（はい！任せてください！）となります。しかし、この先の新規サービスは全て Kubernetes に寄せて作っていこう、その効果は計り知れないはずだ！では、YES Sir！といえるわけがないんです。既存サービスを抱える組織として、効果が不確かで予測しづらいシステムに舵を切ることは、よほどの事態になります。
新興企業として、１つのサービスを盛り上げていくぞ！基盤は Kubernetes だ！ なら、文化醸成と育成がうまくいけば、その先に組織が大きくなって、複数サービスになっても上手に運営できるかもしれません。し、そもそも未熟な組織と認識しているなら Kubernetes を外してくるかもしれないし、未熟ゆえに勢いで選択してなんとかやりくりしていくかもしれない。まぁこの辺を想像してもしょうがないのですが。
インフラ品質（性能・費用）としての向上を高い確度で見込める場合は、案外すんなり新しい選択肢へ舵を切ったりするのですが、Kubernetes はインフラ品質という観点ではそれほど確度が高くない。少なくとも、組織としてのベースシステムとして複製を重ねていくほどのモノはなく、強い意志で採用を望む部署があれば、できる限りの援助はするけど、運用の大半はそちらでお願いしますね、くらいの立ち位置になるのではないかと思います。
好きこそ物の上手なれ！
インフラシステムにおいて重要なのは、構築と運用という２つのフェーズにおいて、いかに早い・安い・安定した構築ができ、
いかに簡潔で手間の少ない運用にできるか、
です。
どちらも重要ですが、特に重要なのはより時間が長くなる運用なので、
どれだけスパッと構築しても、運用コストが重ければクソシステムですし、
研究から構築へ多くの時間をかけても、運用コストが低ければシステムとしては上々だと思っています。
なので、Kubernetes の学習コストが重くても、環境が導入を許容し、運用が軽いのであればそれは少なくとも短期的には成功である、ということになります。中長期的には、責任なり文化なりで踏ん張る部分もあるでしょうが、それは大なり小なりどのシステムでも同じでしょう。
同じものを ECS で実現するならば、より学習コストが低く、理解を得られやすく、成果を想像しやすい中で進捗できる反面、まだ見ぬ Kubernetes でしか得られない利便性、そして失われるナニカが何なのか知らずに終わってしまいます。が、それは先人の知見を読むことで知った気になって、私は安定の Terraform + ECS を選ぶ、ただそれだけのこと・・・
何を選ぶにしても、
時間・予算・人的リソースが許容範囲であることが前提であり、
選択の余地としては担当者の練度により、構築と運用の質がどうなるかってとこですが、
この練度ってヤツがなかなか表立って言えない曲者で、ようは担当者が選ぶシステムが、得意なのか好きなのか、ってのが結局の所デカいんですよ。「使ってみたいんだよね」って理由は確実によろしくないんですけど、「使ってみたい」パワーは成果に繋がりやすいので、Kubernetes ほど知名度と情報があるシステムなら、担当者が使いたいって言ったら、それで行けばいいかって時も絶対あるんですよ。
AWSは複雑だし、Terraformは不満だし、いっちょ Kubernetes でガツンとキメてやるぜ！ってのも成果が伴えばそれもよしですし、
私のように、AWSの理解の仕方と扱い方は心得てるし、Terraformも不満ないように仕上げたし、ECSでもモダンに仕上げてやんぜ！ってのもまたベターに正解。
既存システムに不満を抱いて Kubernetes に解を見出そうとしているのに、違うシステムを採用してしまうとモチベがミジンコになってしまうので、それよりはリスクを承知で Kubernetes に進んだほうが良い成果になりそうですし、
Terraform + ECS で高品質に仕上げられるのがわかってるのに、不安要素の多い Kubernetes に向かうのもまた、モチベダウンになって、イマイチな進捗になってしまいそうです。
エンジニアは結構、面倒くさい感じにモチベと成果が結びつきやすい人種なので、組織の規模が小さめのうちは、好き嫌いでの判断って結構しっくりきたりするんですよね。私はチョット、歳のせいかもしれないですが、胆力を絞り出してまで選択するメリットが見いだせなかったので、平々凡々堅実で高品質なコンテナシステムを目指して磨き上げたいと存じます:-)
