ポッドキャストの紹介とテーマ設定
こんにちは、シニアソフトウェア エンジニアのリドルです。
こんにちは、リドル ソフトウェア エンジニアのひびのです。
このポッドキャストでは、僕たち二人で キャリアや普段の困り事など、
IT業界に関するさざまな話をして、 リアルを届けようという趣旨の番組でございます。
今日のテーマがです、Kubernetesって いつ使うの?ECSでよくない?です。
これ、ちなみに僕の素朴な疑問から 生まれたんですけど、
僕がこれまで関わってきたサービスって EC2インスタンスでアプリケーションが動いているものから、
規模が大きくなっても、ECSだったり あとGoogleクラウドならクラウドランかな?
複数のコンテナを動かせれば、 十分なサービスしか扱ってなかったんですよ。
その目線から、Kubernetes いつ使うのか、僕全く分からなくて、
ちょっとこれぜひKubernetesの専門家、 リドルさんにお聞きしたいなと思います。
リドル クバネティスの専門家です。
クバネティスの資格は持ってないです。 すみません。
KubernetesとECSの基本理解
何も持ってないです。
クバネティスといえば、リドルさんくらいの、 社内でプレゼンスを発揮していたような気はしていたんですが。
そんなことないから、詳しい人いたと思う。
ちなみに、クバネティスって何か知ってますか?
クバネティスは、Googleという会社が作った、 複数のコンテナをオーケストレーションするサービスだと理解しています。
オーケストレーションって何ですか?
オーケストレーションというのは、 これから自信ないんですけど、
複数のコンテナ、多分マイクロサービスみたいなものを、 イメージとしては多分、
無数にあるコンテナをうまく、 一つの指示だけでうまく動かすみたいな感じですかね。
そうですね。管理するやつです。
なるほど。便利なのは分かりますよ。
ちなみに、ECSって何ですか?
ECSっていうのは、これはAWSが提供している、 コンテナベースのアプリケーションをホスピングするサービスで、
それこそ、Dockerファイルを複数書いて、 それをデプロイして、動かして、みたいなことができるやつ。
ただ、多分それこそ、何て言えばいいかな。
無数のコンテナを動かそうとすると、 コンフィグレーションが膨大になって、
ちょっとやりづらいな、みたいなことは何となくありそう。
はい。確かにね。ありがとうございます。
ちょっと知らない人のためにもですね、 ある程度単語を整理しておくんですけども、
クライアントネスは、きっかけ皆さん説明していただいた通り、 Googleが最初作って、
その後、みんなでOSSとして運用している、 コンテナのオーケストレーションツール、管理ツールです。
これをAWSだったり、Googleクラウドとか、 Azureとか、そういう大きなクラウドベンダーが、
それを持ってきて、自社のブランドをつけて、 もうちょっと使いやすくカスタマイズした状態で出しているものがいくつかあって、
AWSだとEKSってやつだったり、 GoogleクラウドだとGKE、AzureだとAKSだったかな。
それぞれ名前をつけて管理しています。
ECSは、それも説明していただいた通りで、 AWSのコンテナマネジドサービスで、
Kubernetesの利点と具体的な使用シチュエーション
名前からしてもエラスティックコンテナサービスなので、 そのままコンテナを管理するサービスなんですけども、
同じ目線で見ると、AWSにおいてはEKSとECSっていうのが、 似たようなことをやるけど、ちょっと違うものとして存在しているみたいな感じなので、
ちょっとタイトルがややこしいんですけど、 EKSとECS、どっち使えばいいの?みたいなのが分かるといいかなと思います。
はい、そうですね。そこの勘どころというか、規模感というか、知りたい、すごく。
OKです。
まず、ひめのさん、あなたはもうEKS使わなくていいです。
EKS使わなくていい?
何を言いたいかというと、
何を言いたいんですか?
EKSを使うときっていうのは、 EKSじゃないと困るときだけなんですよ。
ほう、なるほど。
それ以外のときは、ECS使ったきゃいいんですよ。
ほう、なるほど。
じゃあ、EKSじゃないと困るときって何ですか?
まず、例えばですけど、すごいイレギュラーなケースかもしれないですけど、 複数のKubernetesの環境を作って、それはクラウドまたぎとかオンプレも含みで、
それをうまく統一管理したEKS。
例えば、AWSがダウンすると困るから、 Google Cloudにも同じものを立てておこうっていうケースがあると思うんですけど、
マルチクラウドって構成ですね。
そのときに、なるべく同じアプリを同じ手間でデプロイできたほうが嬉しいですよね。
うん、それはおっしゃるとおり。
で、EKSとGKEだと、同じ感じでデプロイできたり管理できるんですよ。
そうなんですね。
一つのKubernetesのコンフィグレーションファイルで、こいつはGoogle Cloudにアップロードする、こいつはAWSにアップロードするみたいなことがサポートされてるってことですか?
そうですね。すごい厳密に言うと微妙に差があったりするんですけど、
基本的にはどっちもKubernetesのOSSをラッピングしたものなので、KubernetesにおいてPodをとかコンテナをデプロイする方法とか、その他の設定ファイルってもう規格があるんですよ。
それ便利ですね。
便利なんですよ。だから同じファイルを使ってどっちにもデプロイできる。
これが今二つですけど、オンプレ100台もやりたいですとか、AKSもやりたいですとか、他のベンダーのやつもやりたいですってなると、やっぱり同じ設定ファイル、マニフェストって呼んでますけど、それを使って適応できるとめっちゃ便利ですよね。
その規模になったら本当に、こいつされた設定で管理できないとぐちゃぐちゃになってしまいそうですね。
でもこのシチュエーションが起きる現場って、まあないじゃないですか。
ないですね。少なくとも僕はこれまでなかったし、多分社内で今使ってるプロダクトもかなり借りられますよね、Kubernetesは。
これはあくまでめちゃくちゃ極端な事例の一つなので、これ以外にもKubernetesだったりAKSっていったものを使った方がいいシチュエーションっていっぱいあるんですけども、どれも結構少ないというか。
強く世の中のIT現場を見てたときに、その現場の数は結構少ないかなと思います。
なるほど。ちなみに他、例えばこういうシチュエーションで使った方がいいっていう事例はどういうものなんですか?
使った方がいいというか、使わざるを得ないよねっていう話で言うと、さっきの話が出てきましたマイクロサービスみたいな文脈で言うと、マイクロサービスで一つのサービスを運用するために100以上のコンテナが共同して動いています。
ってなったりすると、この100サービスのコンテナを相互に通信させるための通信手段だったり、ここのコンテナはこのコンテナにアクセスしていいけど、このコンテナはこっちのコンテナにアクセスしちゃダメだよねみたいな。
全部うまく管理したり、このコンテナが落ちてる時にこのコンテナからアクセスが来ちゃったら、それで連鎖的に全部障害が起きてサービスがめちゃくちゃなことになっちゃうよみたいなものをうまいこと防ぐみたいなことを考えないといけなかったりですね。
マイクロサービスの複雑度が上がるようなマイクロサービス群みたいなものを運用する際には、もうほとんどKubernetesベースの何かしらで運用することがスタンダードになってる。
なるほど。確かにそこまで考えてDocker Composeを書くのは無理ですね。
無理ですし、Composeの場合って基本的に1ファイルで完結するじゃないですか。
そうですね。
ただ、複数チームの場合ってそのコンポーズファイルを共有してみんなで編集できない。できないでもできるかもしれないですけど、やらないんですよね。
そうですね。
そうなるとお互いにあんまりお互いのことを知らなくても済むような感じで運用ができないといけないっていうところもあって、そういう文脈で使われることもあります。
他にもゲームではよく使われまして。
それはなぜですか。
ゲームの中でもマルチプレイってひめのさんも遊んだことがあると思うんですけども、
特にここではプレイヤーが複数人で遊ぶゲームサーバーみたいなものがインターネット上、我々の運用管理上にあると思ってほしいんですが、
そのゲームサーバーで、例えばルーティングをして4人プレイ対戦を実現しますって言ってもいいんですし、
そこで実際にゲームの物理エンジンみたいなものがあって、
例えばスプラトゥーンかな。スプラトゥーンはどうやってるのかちょっとわかんないですけど、
任天堂側のゲームサーバーがあって、そこに通信してうまいことやりたいと思うんですけど、
Kubernetesとゲームサーバーの関係
あれって多分クバネテスのGKEの基盤があるはずなんですね。
はい。
で、その上にアゴネスっていうミドルウェアがあるんですよ。
アゴネス。
ゲームのサーバーを作るための専用のミドルウェアみたいなやつなんですけど、
これポットの特性、コンテナ特性をちょっと思い出してほしいんですけども、
基本的な思想って、ステートレスなポットやコンテナをいっぱい立てて、
で、上にロードバランサーを置いて、分散してどこにアクセスしてもいいよねっていうのが、
基本的なコンテナの使い方というか、クバネテスの思想なんですね。
なるほど。じゃあ例えばイメージとしては、スプラトゥーンで一つ試合が始まりましたみたいな時に、
その試合専用のインスタンスというか、一つのコンピューターが自動で立ち上がってくれるみたいなことが起こってるみたいな感じですかね。
そうですね。アゴネスを使うとゲームサーバーと呼ばれる種類のリソースが立ち上がりまして、
これはこの試合用のやつ、これはあの試合用のやつみたいな感じで、
ポット一つ一つがちゃんと識別されるんですよ、このゲーム用みたいな。
はいはいはい、なるほど。
で、この4人はここに入れて、この4人はここに入れて、この4人はここに入れてみたいな、
もう元々のクバネテスの思想とはちょっと違うというか、ステートレスじゃない管理方法がゲームだと求められるので、
それをうまいことやるためには、本当は自前で全部そういういい感じのものを作らないといけないんですけど、
せっかくクバネテスっていうコンテナのオーケストレーションツールがあるので、
その中でもうちょっと自分たちが使いやすいようなことができるようにカスタマイズしてあげると、
いい感じにゲームの専用サーバーとして使えるみたいなことがあったりしますね。
EKSとECSの利用シナリオ
なるほどなるほど、そのゲームのオンライン環境すべてをいい感じに管理できる基盤として、すごくクバネテスは有用だったということですね。
そうですね。他にも、例えばK8Sってクバネテスのことを言うことが多いんですけれども、
Kクバネテスっていうスペルを書いたときに、Kで始まって最後Sで終わる間に8文字あるので、
K8Sって呼ぶんですね。I11N、インターナショナリゼーションとか、O11Yでオブザーバビリティみたいな、そういうのもあるんですけども、
K8Sってあるんですけど、K8Sだとちょっと機能が多すぎるから、ちょっと減らしてK3Sみたいなものもあったりするんですよ。
K3S。
K3Sかな。このK3Sとかを戦闘機に乗せて、戦闘機が100であったら、それぞれにK3Sを入れて、それぞれをK3クラスターみたいにして、
それをさらにクラウド上にあるサーバーと通信させて、それぞれの戦闘機をK3Sのクラスターで管理する。
だちの軍電用ですね。
軍電用みたいな。
すごいなんかめちゃめちゃハイテクな話になってて。
すごいっすね。そういうことにも使えるんだ、でも確かに。
そう。なので、K8Sはすごい汎用性が高くてですね、どういうものを作るかっていうのもだいぶカスタマイズが自由に効きますし、
その反面、自分で面倒見ないといけないことも多いんですよね。
はいはいはい。
ログ飛ばすとか、モニタリングしたいとか、あとなんかPodのリスタートするとか、いろいろあるんですけど、
そういうところをいろいろやってくれてるのが、いわゆるECSとかクラウドランみたいなサービスなんですね。
そう考えると、さっき言ったような事例だけじゃもちろんないんですけれども、そういう事例なのかっていうことをそもそも考えると、
そういう事例じゃない会社の方が多いかなと思うので、基本的にはECS使っておけばいいんじゃないって話ですね。
Kubernetesの競合と普及
なるほど、めちゃくちゃ踏み落ちた。それこそ、ECSで手に余る規模にならない限りはECSを使い続けろということですね。
そうです。
ちなみに気になったことが一つあって、僕はこの分野めちゃめちゃ素人なんですけど、
それあれじゃん、学会とかで聞いてくるやつじゃん。
いや、完全にその意図はないです。クバレティスの競合サービスみたいなものは現状ないんですか?
ゲームしてるとあるっていうか、あったというのが正しいのかわからないですけど、
まずですね、2014年ぐらいにDockerっていうのがすごい流行りだったんですよ。
そうですね。
Dockerはそれ流行った後に他の商品出そうって言って、Docker ComposeってやつとDocker Swarm。
Swarm、ありましたね。
Swarmってやつを出してきたんですね。これがまず先にあって、その後にクバレティスが出てきたんですよね、確か自分の記憶だと。
なるほど、それこそDocker Composeで管理しきれない規模のコンテナをオーケストレーションするためにクバレティスが生まれたっていう背景ですね。
そうですね。厳密に言うとGoogleがもともと社内はコンテナ環境で管理していて、Vogueっていうオーケストレーションツールを社内で使ってたんですけど、
それをクバレティスとしてOSSとしてカスタマイズして出したみたいなのが始まりだったみたいですね。
なるほど。そしてそれがいろいろな会社のユースケースに刺さって今があるってことですね。
そうですね。なんか自分もちょうどクバレティスがまだバージョン1になる前に仕事で言えたりしてたんですけど、
いやなんかその時は動かすのがめっちゃ大変だったし、わけわかんないですよね。
クバレティスって難しいんですよ、特に初学者がやろうと思うと。
なんか概念多いし、知らん単語多いし、前提知識多いし。
はいはいはい。
だからめちゃくちゃ大変なんですけど、バージョン1になる前はもっとドキュメントも少なかったんで、わけわからなかったなっていうところと、
あと一つ競合で言うと、レッドハット、今だとIBMなのかな?
はいはいはい。
オープンシフトっていうクバレティスプラスなんかラッパーみたいなもので、オープンシフトっていうものを出したりしてますし、
あとランサーっていう会社かな?ランサーラボかな?ランサーラボって会社がランサーっていう、またこれもクバレティスのラップみたいなものを出したりしてますし、
あとハシコープ社がコンサルな。
コンサル?
コンサルっていうものをコンサル出してて、これはなんか競合だった気がしますし、
なんかどうかの会社でコンサル使ってクバレティスはあえて使わずに自前でコンテナのオーケストレーション環境を作ってます会社もなんかありましたね。
へー、そうなんですね。じゃあ完全にクバレティス一強ってわけでもなく、
いや、一強だと思っていいですよ。
一強、なるほど。一強だけど、まれに他のサービスを使ってオーケストレーションしてる会社もあるくらいですかね。
そうですね。クバレティスの工材があると思っていて、クバレティスの工材というかクバレティスを使う人の工材なんですけど、
この前SMSで履歴職堂開発って言われてバカにされてたんですけど。
履歴職堂開発、ほうほう。
一年ぐらい前にそれこそEKSとかGKEとかが出てきて、使われるようになったよっていうタイミングで、触りたいからという理由でそれらを入れる人たちがいたんですよ。
これは良くないな。しかも個人プロジェクトじゃなくて、それは職場でっていうことですよね。
そう、職場で入れて、自分も最初の転職活動するときに、これなんでEKS入ってるんですか?みたいな。
聞いたら、前任者が入れてて、今ECSに移動してるんですよ、みたいな話を3軒くらい聞いたから。
それこそ、ECSの手に余らない規模のサービスだったってことですね。
そうそうそう。だってECSで戻そうとしてるぐらいだから。
これは良くないな。
良くないのよ。EKSとか入れたら、インフラの人も大変だけど、アプリの人もドッカーファイル以上にマニフェストをずらずらめちゃくちゃ書かないといけないから、訳わかんないと思う。
確かにそうですよね。そして、不必要なマイクロサービスの流動で分けなきゃいけないってことですもんね。
そこはマストじゃないんですけど、例えばアプリ側でAPIキーとか機密鍵とか使いたいとするじゃないですか。
例えばですけど、適当にやるなら、例えばEC2の時代だったらローカルに置いときゃいいじゃないですか。
それでも動くそうですね。
ECSだと、今だとGoogle CloudだとSecret Storeみたいなところとか、Secret Manager入れたり、ECSでもパラメータストアみたいなところに入れるじゃないですか。
そこから勝手に引き出せばいいとかできたはずなんですけど、GKEとかECSの場合だと、そのパラメータストアから持ってきて、
Kubernetesの複雑さ
クバンテス上のシークレットっていうリソースに置き換えてあげるみたいなためだけのミドルウェアをOSSで自分で持ってきて入れないといけなくて。
それ面倒くさいですね。
しかもそれが別に1個じゃないんですよ。4,5種類あって好きなやつ選んでいいんですけど、それは比較とかしないといけないし。
それこそAWSとかGoogle CloudがそこをSecret Managerでサポートしてくれるようになるといいのになって思いますね。
そうですね。何をサポートするか決めてないんでしょうね。
でもなんか初めから入れてくれるやつもあるんですよ。例えばログ伝送だったらフルエントビットを入れてくれたりとか、あと証明書を発行するためのSARTマネージャーみたいなものを入れてくれたり、
監視のためのプロメテウスを入れてくれたりとか、あと名前解決のためのCoreDNSってやつを入れてくれたり、それだと遅いからノードローカルDNSみたいなものを入れたりとか、
いろいろまずデフォで入れたほうがいいものいっぱいあるんですよ。
大変ですね、そこまでいくと。
そこからさらに案件によってはグラファナ入れたりとか、例えばPodからディスクとかを参照したかったらそのためのストレージのドライバー入れたりとか、なんかマジでいろいろあるんですよ。
なるほど。しかもあれですよね、それこそコンテナが無数にある分コンテナの定義を書かなきゃいけないってことですもんね。
そこはですね、マニフェストってやつで管理するんですけど、みんなが入れるようなものに関しては、初めからこういうふうに入れるといいよみたいなものが用意されていて、楽に入れられるんですけど、
ここまためんどくさくて、入れ方がいくつかあって、入れ方というかマニフェストの管理方法がいくつか破末があって、Helmってやつと、Customizeってやつと、Teptoってやつと、Helmファイルってやつと、TueでQってものかな、Qってやつと、Jsonnetってやつと、いっぱいあるんですよ。
そのHelmとHelmファイルは違うんですか?
ヘルムとHelmファイルは違っていて、CustomizeとHelmが二大巨頭なんですけど、個人的にはですよ。ちょっとごめんなさい、いろんな人いるんで何とも言えないんですけど、その二つが多くて、ただその二つを使うのめんどくさいから、その二つをまとめて使えるHelmファイルっていうのが別にあって。
複雑だな。
で、デプロイするときも、例えばGitHub ActionでKubectlっていうコマドラなんですけど、このコマドラでApplyってやって、Applyするかと思いきや、いや、ダメですと。
時代はGitOpsですよと。GitOpsっていうのは、Kubernetes用にArgoCDとかPluxみたいなアプリ入れといて、そいつが常にGitのリポジトリ見てくれていて、そのGitリポジトリがコミットとかが積まれたら、その状態に勝手にKubernetesを更新してくれるみたいな、そういうやつがいるんですよ、何種類か。
はい、Kubernetesのデプロイをマネージしてくれる別サービスがあるってことですね。
そうです。で、今挙げたようないろんなツールがあるんですけど、それらのバージョンアップとかも自分でやらなきゃいけないんですよ。
なんだと。
ECSだとほぼないと思うんですよ。
そうですね。
サイドカーでデプロイしたやつぐらいだと思うんですけど、基本的にはAWSさんがうまくやってくれてるんですけど。
そうです。
さっきのやつは自分たちアップデートしないといけないし、何だったらKubernetesのコントローラーっていう、我々があまり管理しない、KubernetesはKubernetesたるゆえみたいなアプリが勝手に動いてるとかなんですけど、それとかは結構な頻度でバージョンアップするんで、そのバージョンアップするためには、いろいろとマニフェストを追随していかないといけないとか、このAPIも使えないっすねみたいな感じがあったりするんで、まじで重り大変なんですよ、Kubernetesは。
導入時の留意点
なるほど。
使いたいですか?
少なくとも、個人的に導入しなきゃいけなくなるまでは考えたくないですね。
そうですね。
そう、懸命だと思います。
なのでですね、もし皆さんが採用担当とかされる場合にですね、履歴書にKubernetesやってましたっていう職歴を書いてる人で運用あんまりやってなさそうな人がいたら、ちょっとブラックな可能性がある。
なるほど。導入だけ力を入れた方の可能性が高いってことですね。
高い。もちろんね、本当に必要な可能性はあって、たまたま運用前にやめてしまったっていう可能性もあるんで、そこはちょっと皆さんの技術で引き出していただけると思いますが、そういう可能性があるんだよということだけね、覚えていってもらえればと思います。
Kubernetesよもやまばし、面白いですね。でもなんかあれですね、今の話を聞いて確かにエンジニアの面接をして、Kubernetes触ったことない状態だと、本当にKubernetesを使いこなしていったのかとかあんまりわからないけど、今の話を聞いたら何となくどういうことを聞けばいいのかってわかった気がします。
いっすいっすいはなぜダメだったんですかって聞いてみたいと思いますよ。
もうそれにつきますね、本当に。
個人的にはクラウドランでめっちゃ使いやすくて楽で、本当にデプロイも楽なんで、あれいいっすよね。
そうですね。僕も大好きです。
そんな感じで皆さんがどういう環境にいるかはちょっとわかりませんが、Kubernetesをやる際にはぜひですね、いろいろした手段を利用してですね、もうお前しかないんだという状況で初めて手を出すのがいいかなと思います。
はい、このポッドキャストはハッシュタグライキーで皆様からの感想やコメントを募集しております。
またチャンネルの概要欄にGoogleフォームのリンクもありますのでそちら側のご投稿も大歓迎です。
ありがとうございました。
ありがとうございました。
