Kubernetesは、流行る前から使っていた
『モンスターストライク』から見るk8sのイケているところ3つ

「Kubernetes」を使いこなせると何がうれしいの？

司会者：それでは本日のゲスト社員を紹介したいと思っています。『モンスターストライク』事業本部の浅野さんです。よろしくお願いいたします。

浅野大我氏（以下、浅野）：よろしくお願いします。

司会者：では簡単に自己紹介をお願いできればと思います。

浅野：よろしくお願いします。私は2020年にミクシィに入社をしました。ミクシィとの関わりとしては、まず2018年に『モンスターストライク』のインターンで初めてGoやKubernetesなどに触れて、そのあと内定をもらってそのまま入社したのですが、それまでに2019年から内定者アルバイトとして、1年弱ぐらい『モンスターストライク』のSREとして開発環境の改善や、あとは『モンスターストライク』で使っているCI基盤のJenkinsなどのKubernetesへの移行を進めました。

そのあと入社するまでには数ヶ月ありましたが、その間は「6gram」、現在の「MIXI M」というところで、サーバーサイドでElixirを書いていたりしていました。そんな経験をした上で、2020年にあらためて新卒で入社をして、それから今はずっと『モンスターストライク』のサーバーサイドのエンジニアとして働いている感じですね。

司会者：では本日さっそくですが、こちらですね。「よく耳にする『Kubernetes』。使いこなせると何がうれしいの？」というところについて、まずは記事の内容をざっくりと振り返ってみようと思っています。

ではさっそくなんですけど、そもそもKubernetesとは何ですか？というところから説明してもらえればと思います。

浅野：詳しめな解説はインターネットで検索すると出てきますが、すごくわかりやすくした答えとして、LinuxというOSがあって、そのLinuxの機能をフル活用した仮想技術のコンテナという技術が最近浸透してきたと思いますが、それを使いこなすためには、コマンドをいっぱい叩いたり、Linuxのカーネルにあるいろいろな機能を使わないといけません。

そういう機能などを使いやすくしたりわかりやすくしたりして、いろいろなものを自動化していきましょうと。なので軽く説明すると、コントローラーをいろいろ作らせていって自由に拡張したりすることです。

（スライドを示して）あとはここにも書いてあるとおり、例えばクラウドに何かものをデプロイする時に、サーバーや、ノードの台数やプロセス、コンテナの数などを自動で増減させたり。あとは、途中で障害が起きたらどうしていけばいいの？　みたいなものもKubernetesだとけっこう簡単に、コントローラーに書いてあればやってくれたりもします。

アプリケーション開発エンジニアが、インフラも自動化していくみたいな。けっこうエンジニアにとってうれしいパッケージ、ソフトウェアなど、そういうプラットフォームのことをKubernetesとか言ったりします。

司会者：最後に「自動化パッケージ」となっていますが、本当にこれを自動化パッケージと呼んでも大丈夫なんですか？

（一同笑）

浅野：ちょっと広い意味なので（笑）。

司会者：なるほど（笑）。

浅野：Kubernetesがあれば完全にすべて自動でやってくれるわけでもなくて、もちろんいろいろ考慮しなきゃいけないこともありますし、Kubernetesでサポートしていないことをやろうとしたら自分で書かないといけないのですが、そこも含めてアプリケーション開発をしているエンジニアが何かを自動化したいとなった時に、Kubernetesの上で何かを作ればそういう自動化を簡単にやってくれる。

今までだったらゼロからやらなきゃいけなかったり、例えばパブリッククラウドの提供しているサービスしか使うしかできなかったり、アプリケーション開発エンジニアがインフラに入っていけるようにしたり、といったことがKubernetesという感じです。

「Kubernetes」は1つだけで動いているわけではない

司会者：あらためての振り返りになりますが、仕組みはどうなっているんですか？　こちらは記事にも書いてありますが、こちらもサマリーでお願いできればと思います。

浅野：Kubernetesというソフトウェアは1つだけで動いているわけではなく、kube-apiserverというAPIサーバーがあって、これはみなさんが作られているようなHTTPでしゃべるようなAPIサーバーと同じですが、それが中枢にいて、そこを経由していろいろな情報、つまりデータストアをKubernetesは持っていて、それとそのAPIサーバーを使っていろいろな機能を拡張することができるんです。

コントローラーと呼ばれるいろいろなコンポーネントがあって、例えばそのPodを動かすためのコンポーネントがいたり、ネットワークを担当するコンポーネントがいたり、そういうのが全部組み合わせて全体のシステムを動かすのが、Kubernetesが動く仕組みですね。

司会者：なるほど。

浅野：ポイントは、Kubernetesのコントローラーを宣言しておくこと。例えばこういう状態でありたいみたいなことを宣言したファイルを書いてデプロイしますが、その状態から何かが変わったとしても、そのコントローラーの中でそれを検知して元通りにするというか理想的な状態に限りなく近づける、自動的に戻すような仕組みを提供してくれているところなんですね。

例えばコントローラーの例で1つ挙げると、複数のコンテナが動いている状態で、それぞれ役割があるコンテナを「このノードでこのコンテナを動かす」ということをファイルに書いておけば、そのコントローラーが自動的に、今このノードが空いているからここにPodを動かしてあげようといったことがコントローラーに標準で装備されている、コントローラーだとそういうことができる感じです。

司会者：その設定自体は、けっこう自由に組み替えられるとか。

浅野：そうですね。Kubernetesが提供している範囲内であればけっこう自由に書くことができて、いわゆるYAMLというファイルがあるんですけど、そのYAMLを書いていったり、あとはそもそもKubernetesを使っている人たちが有志でというか「設定ファイルはこう書けばいいですよ」みたいな、公開しているものもあるので、自分で持ってきて使うということも可能です。

Kubernetesのイケているところ3つ

司会者：ざっくりとですが、ここまでが記事の振り返りでした。ではここからは、延長戦というかたちで、さらに質問したいと思っています。ズバリ「浅野さんが考えるKubernetesのイケているところを3つ教えてください」という質問があったら、どう回答しますか？

浅野：まずコンテナのデプロイにおいて、KubernetesはAPIサーバーが許す限りですが、スケールすることができるというか、今までだとデプロイツールとかそういうのを使ってWebアプリケーションをデプロイしている方も多かったと思いますが、YAMLだけを書いておいて、あとはコントローラーにお任せすることで、デプロイ戦略などを深く考えなくても自動でやってくれるのは、わりとブレイクスルーだったんじゃないかなと思います。

司会者：それは他のケースだとスケールできないケースが多かったんですか？

浅野：そうですね。例えば自分でデプロイ基盤をOSSなどで作ったりすると、例えば使っているフレームワークに依存しちゃったり、この言語で書いたWebアプリケーションをデプロイするならこれとか、あとはこのコンテナを使うソフトウェアだったら、例えばDockerだったらそのDockerにswarmという、Kubernetesのようなクラスタ基盤があったんですが、そういうけっこうベンダー依存になるんですね。

何かに依存しちゃう、ロックインしてしまうことが多かったのが、Kubernetesはわりとベンダーフリーに使えるので、その点において開発速度が向上するんじゃないかというところにけっこう期待ができるのが1つ。

司会者：なるほど。それがいけているところの1つ目？

浅野：1つ目になります。ちょっと長いですけど（笑）。その次は、あらゆるリソースを宣言的に表現できるのがKubernetesがいけているなと思うところで、コンテナのデプロイは普通にYAMLで宣言できるのですが、例えばロードバランサーの設定も、ふだんはパブリッククラウドの設定画面からWeb UIを使って設定していると思いますが。

Kubernetesであれば、標準でserviceというリソースがあるので、そこに設定をしておいて、あとはクラウド側が提供しているロードバランサーのコントローラーであったり、それこそ自分で作ったロードバランサーのコントローラーをデプロイしておけば、そのservice側でリソースを取ってきて自分でセットアップできます。

要はそのコンテナをデプロイするところだけではなく、ネットワークの話であったりストレージやデプロイをどうするであったり、そういうのも全部Kubernetesのリソースとして宣言できるのが、けっこう良い面じゃないかなと。

司会者：それが2つ目ということですね？

浅野：2つ目です。

司会者：リソースを宣言的に表現できる。では3つ目はいかがですか？

浅野：3つ目はreconcileループというのがあって、reconcileは日本語に訳すと修復とかそんな感じなのですが、そういうところで常に正しい状態に・宣言した状態に近付けようとするループをコントローラーで表現していて、それがけっこういけているなと思うところです。

例えばノードが故障してしまい、動いているPodが3から2に減ってしまいました。今までだと、それを復元するのにたぶん人間の手がないと元の状態に戻すことができなかったと思います。障害対応でノードを増やしてもう1回デプロイをし直して、のようなことをやってようやく復活するみたいな。

司会者：一般的な対応というか。

浅野：一般的な対応をしようとしたら、そういう対応をしなくちゃいけないのですが、Kubernetesであれば、Podが欠けたと時に、そのノードに余裕があれば自動的にもう1回Podをスケジュールして起動しようとしてくれる。

司会者：なるほど。

浅野：例えばダメになっちゃった原因が、何か設定ファイルに原因があって起動ができなかったり、データベースにこれ以上つながらなくてPodが起動しない状態になってしまうと、新しいPodは作れません。でもそういうことではなくて、例えばノードに単純な障害が起きてしまった場合、空いているノードがあればそれを自動的に探して新しい、例えば2から3の状態にしようとしてくれるのがけっこうおもしろいところです。

司会者：それによってエンジニアが手を入れなくて済むとまではいかない感じなんですか？

浅野：そうですね。あらゆる状態があるので、できる限り正常な状態に近付けようとはしてくれますが、どうしてもそれでも直らない場合もあるので、今サービスを動かしているもの・デプロイしているものが正常かどうかの確認は、もちろんエンジニア側で監視する必要はあります。

「モンスト」ではKubernetesが流行る前から使っていた

司会者：それでは次に行きましょうか。「Kubernetesの『モンスターストライク』への導入はいつくらいからだったの？」というところをお聞きしたいのですが、これはもしかしたら浅野さんの入社前から？

浅野：入社前から使われていました。Kubernetesという技術自体がわりと有名になったのはここ2、3年ぐらいかなと僕の中で思っていて、ブレイクしてからは2、3年ぐらい経っているかなと思いますが、それよりもっと前から『モンスターストライク』の中では使われていて、2017年ぐらいから使っていたんですよね。

司会者：そうなんですね。

浅野：2017年に『モンスターストライク』で使っているいろいろな細々としたツールがKubernetesに移行されて、そのあと2018年ぐらいからわりと本格的に使われるようになりました。『モンスターストライク』で運用しているPodなどをKubernetesにポンッとデプロイするようにしたり。

そこから徐々にツール関連を先ほど自己紹介で言ったようなCI基盤やJenkinsを移行したりして、ツール関連は今はわりとKubernetesで動いているのが多い状態ですね。

司会者：そうなるとわりと早めというか、けっこう歴史があるんですね。

浅野：そうですね。最初に入れたのは早いかなと思います。

「Kubernetes」がないとどんなことが起きるか

司会者：それでは次に行きましょうか。「もし『Kubernetes』がないとどんなことが起きますか？」ということをお聞きしたいのですが。不便や不具合など、どういうことが予想されるのかを可能な限りでいいのですが、『モンスターストライク』を事例に教えていただければと思いますが、いかがですか？

浅野：『モンスターストライク』で先ほどKubernetesを使っているという話をしましたが、本番環境でKubernetesを利用しているのは一部。リアルタイムのメッセージをやり取りするサーバーがKubernetesで現状動いていますが、それ以外のAPIサーバーやゲーム本体のサーバーは、今はKubernetesを利用してはいないんですね。

司会者：そうなんですか!?

浅野：（本番環境では）Kubernetesは使っていませんが『モンスターストライク』のアプリケーションのデプロイは、オンプレミスやさまざまなクラウドインフラを使っていて、1つのパブリッククラウドだけで完結するわけではないんです。そういうのもあって、今は『モンスターストライク』本体はコンテナを交わしていなくて。通常のWebアプリケーションなので、これまでどおりのWebアプリケーションのデプロイ戦略をしています。

例えばそういう細かいツールはメンテナンスされなくなったり、それこそ自分たちのインフラ戦略に合わせて常に最適化をしていかなきゃいけない、メンテナンスをしていかなきゃいけないのですが、Kubernetesであればそういうメンテナンスはけっこうしやすいのかなと。アップデートとかも頻繁ですし、OSSもあるし、先ほども言いましたが、ベンダー依存があまりないのでそういうのはけっこうしやすいと思います。

例えばあとはKubernetesを使っている、『モンスターストライク』であると周辺のツールも別にデプロイしています。

司会者：周辺というのは？

浅野：例えばQAや企画が使うようなツールにアクセスするためのプロキシとか。今は『モンスターストライク』の業務をしようとすると、Kubernetesのクラスタをみんな絶対1回通るようになっているんですね。

司会者：なるほど。

浅野：そういうツールや、あとはテストのCI基盤をパブリッククラウドのインフラを使うとすると、インスタンスをそれこそ1個用意して、そのロードバランサーを借りてきて構成管理をしないと、次に引き継ぐ人や次にやる人がこの構成がどうなっているのかがイマイチよくわからない状態になってしまう。

そういう、インフラを手作業でメンテナンスをしていくのはけっこうつらい部分が多いので、それであれば新しく作ったものであったり、そういう移行コストが低いものはどんどんKubernetesに載せて、構成管理を1ファイルにまとめておいて、もし何かノードに障害が起きても勝手に元に戻る状態にしてくれるようにして、Kubernetesにどんどん載せていこうという感じにはなっていますね。

司会者：そうなると開発の観点でもかなり利便性が高くなるというか。

浅野：そうですね。利便性と、あとは開発速度が上がるというのはありますね。

GKEとKubernetesの関係

司会者：ではもう1つ。これもよく界隈で聞かれる話としてあったりしますが、「GKEとKubernetesの関係を教えてください」。この関係性みたいなところも、浅野さんにお聞きしたいなと思っています。

浅野：わかりました。『モンスターストライク』でもGKEを使っていて、GKEというのはGoogleが提供しているGoogle Cloudというパブリッククラウドで提供されているマネージドのKubernetesなんです。マネージドというのは何なのかというと、Kubernetesは先ほども言いましたが、1つのアプリケーションではなくていろいろなコンポーネントとかストレージであるとかノードです。

実際にコンテナデプロイされるインフラがあって、そこの管理をやらないといけないのが、Kubernetesのけっこう大変な、面倒くさいところでもあるんですね。

司会者：なるほど。

浅野：そこを一手に引き受けてくれるのがマネージドKubernetesで、そのうちの1つですね。Googleが提供しているものがGoogle Kubernetes Engine、略してGKEです。

他のクラウドベンダーさん、AWSやマイクロソフトなど、いろいろクラウドインフラを提供している会社がありますね。そういうところでもそういうマネージドKubernetesを提供している会社がありますし、今はマネージドKubernetesをオンプレミスで提供しているような会社もあったりします。

「面倒くさい部分」と言いましたが、例えばマネージドKubernetesの面倒くさいところを体感するのに一番良いのは自宅でKubernetesを構築する。Kubernetesのクラスタを構築するのが一番面倒くさいのを実感できるところで、そういうのをやれば自分でもKubernetesのクラスタを運用することが可能です。

司会者：ちなみに浅野さんはそのへんはいかがですか？

浅野：今は自宅にKubernetesのクラスタがあって、最近ちょっと引っ越しをして元の状態に持っていけてはいませんが、RyzenというCPUを積んだ小型のPCが3台と、Raspberry Piという教育用のコンピュータボードがあって、その3台です。

Raspberry Piをマスターノードというコントローラーを動かして、3台で実際にコンテナが動くノードみたいな感じでクラスタを構築しようと思っていて、前は3台のRyzenだけだったのが、最近はRaspberry Piも増やして本格的にマネージドKubernetesの面倒臭さの1つでもあるマスターノードというAPIサーバーを動かしている部分があって、そこを1台にすると、そこが障害になったらKubernetesが動かなくなってしまう。

司会者：そうですよね。

浅野：だけどマネージドKubernetesはそういうのも全部冗長化してくれるので、そこをチャレンジしてみようかなと思って、Raspberry Piを用意してちょっと悪戦苦闘している最中ですね。

司会者：それがうまくいったかいっていないかというのは、いずれ浅野さんのブログなどで。

浅野：そうですね。Twitterのアカウントかブログなどで。最近のツイートにもRaspberry Piを縦に積んでいる画像をアップロードしているので。

（一同笑）

司会者：じゃあそれはぜひみなさんにご覧いただいて。

ECSやOpenShiftとの使い分け

司会者：いろいろ聞かせてもらいまして、ここからはみなさんの質問に答えていこうかなと思っています。

ではさっそく事前質問が来ていたので、そちらの質問にご回答いただければと思っています。「ECSやOpenShiftとの使い分けについて聞きたい」というところですが、いかがでしょうか？

浅野：ECSはAWSが提供されているマネージドKubernetesの1つで、OpenShiftがRed Hatが提供しているKubernetesのプラットフォームみたいなものですね。後者はKubernetesの基盤みたいなところがあって、前者はGKEと同列のマネージドKubernetesがあって、それで説明はOKなのかなとなります。

OpenShiftは弊社は使っていないとは思いますが、Red HatはLinuxの保守などをやってくれる会社です。LinuxはもともとOSSなので、自由に使ってOKだよ、その代わり責任は取らないよと。なのでアップデートなどはやっていかないといけないのですが、そういう保守パッケージみたいなものを提供しているのがRed Hatで、そのRed Hatという会社が提供しているKubernetesのプラットフォームがOpenShiftなんですね。

例えばオンプレミスとかでKubernetes運用したいよという場合に、自分たちでKubernetesのデプロイをしていくのが難しいと。その保守が必要だよという場合にOpenShiftを使っていくケースはあるかなとは思います。

司会者：なるほど。事前の質問は以上ですね。

（後半へつづく）