Kubernetesは銀の弾丸ではない––AWSにおけるコンテナオーケストレーションの現在地と可能性

Amazon ECSとKubernetesを比較する

AWSにおけるコンテナオーケストレーション、代表的なものが2つあります。Amazon ECSとKubernetes。まあ、ほかにもいろいろあるんですけどね。今日は2つを機能で比べてみましょう。ECSはこんな機能があります。

最近だいぶ機能が増えました。もともとはコンテナのデプロイだけだったんですが、だいぶ初期にIAMロール対応をして、同じEC2インスタンスに相乗りしているコンテナがそれぞれ違うIAMロールを使えるので、セキュリティが高まります。あとはヘルスチェックですね。EC2インスタンスが落ちたら自動復旧する機能がありますが、コンテナにもそういう機能が付きました。

そして、サービスディスカバリです。EC2インスタンス1個だけ並べてもロードバランスするときにどうやってお客さんから複数台のサーバが透過的に使えるようになるかと言うと、サービスディスカバリとロードバランスなんですが。コンテナを同じようにサービスディスカバリできるようになりました。

なのでRoute 53にDNS名があって、その先に複数コンテナがいますみたいなことをECSがサポートしてくれたんですね。とにかくこんな機能があります。だいぶ便利そうですよね。

Kubernetesの機能って一見すると同じなんですよね。コンテナのデプロイできます。サービスディスカバリもあります。ヘルスチェックもあります。ってなってくると、あと何で比較しよう？　ってなります。

ECSの運用上のメリット

先ほどは機能の話でしたが、運用面どうなんでしょう？　そういう観点でECSのメリットを見てみると、こんなメリットがあります。

ECSだったらAWS公式の専用のAMI、マシンイメージがあります。例えばDockerECSが使うAgentの相性問題は自分でデバックしなくていいんですね。もっとビジネスに集中できますよね。

あとマネージドサービスがあって、これあまり意識することはないかもしれませんが、KubernetesだったらKubernetesのシステム用のサーバが別にあって。それはみなさんのアプリケーションが動くものとは別のサーバが必要で。それを自分たちでメンテしなければいけません。それを仕事にしているわけでもないのに、そんな余分なものメンテしている時間ない。でもECSはそれを見てくれてます。

あとはSegment社という海外の大きな会社さんがあって、そこがECSで大規模なクラスタを運用している事例とか、そのために使っているOSSをすごく積極的に公開してくれています。そういうところに乗っかっていくと我々としても楽ですよね。

あとは日本でも採用事例が多いです。採用事例が多いということは情報が多くて教育もしやすいし、なんかハマってバグったときのトラブルシューティングもしやすいですよね。運用目線だとすごくメリットですよね。

スコープが限られているのもいいです。スコープというのは機能が限られています。だいぶ便利機能が増えてきてKubernetesに近づいてきてしまったんですけれども、それでもさっき挙げた4つで説明できるくらいの機能なのでだいぶ取り回ししやすいです。

機能が増えるとどうしてもアップグレードって大変になりますよね。ECSのバージョンが上がったらちょっとビジネスの開発止めて、ECSのバージョンアップに追従しなきゃいけないってやってられないじゃないですか。そういうことはECSに関してはたぶんありません。

Kubernetesを使ってもサーバー管理からは開放されない

これは残念ながらKubernetesのデメリットになってしまいます。Kubernetesだったら今AWS公式の専用のAMIってないんですよ。

例えばサードパーティのCoreOSって会社が、今Red Hat社になっちゃいましたけど。Contaier LinuxっていうLinuxのディストリを持ってて、これはKubernetesと動くようにテストされているんですね。こういうのを使えばさっき言ってた相性問題とかは回避されます。

けれども結局専用のAMIがないってことに変わりないです。AWSさんのサポートを受けられないんですよ。それは辛い。

マネージドサービスもないんですね。さきほど言いましたが、EtcdというKey-Valueストアが必要なんですよ。あとKubernetesのコントロールプレーンっていうEtcdを使うWebアプリのようなシステム用のサーバーがあって、それも自分でEC2インスタンスになんとかしてデプロイしなきゃいけません。

コンテナをいい感じに管理するシステムがほしかったのに、そのためにコンテナ外でこんなにがんばらなきゃいけないのは一体どういうことだとなっちゃいます（笑）。

あとKubernetes on AWSの事例はまだまだ少なくて、海外ではHotels.comとかAtlassianとかZalandoとか、Monzというイギリスの銀行など、大きなところで採用事例はあるんですけど。日本だとあんまりないんですよね。

日本でもあることはあります。ここのリンク先、あとで資料公開するので見ていただきたいんですけど。日本企業って片手で数えられるぐらいしかまだなくて。やっぱり情報が少ないですね。

さっきお話したことの繰り返しになりますけど、情報が少ないとデバックも大変ですし、人を探すのも大変ですし、社内で導入しようってなったときに自分でKubernetes使える人を何人も育てるのめちゃめちゃ大変じゃないですか。ってなっちゃいます。

あとスコープも広いです。ECSより実は機能が多いんですね。

というわけで、マイナスの話しかしてないですね（笑）。Kubernetesの概要をまとめますと、ECSよりは運用が難しいです。Lambdaほどはうれしくないです。サーバ管理から実は解放されていません。

KubernetesのEKSの使いどころ

それでは、KubernetesのEKSの使いどころの話をしようと思います。使いどころあるんですよ、ちゃんと。

ツールの違いは運用と適応領域の違いです。例えばこういう図を思い浮かべてください。

コンテナだったらECSで管理して、KubernetesアプリをKubernetesで管理して、FunctionだったらSAMとかAWSのほかのマネージのサービスを使って運用します。

そういう使い方を考えたときに、Kubernetesの機能ってけっこういろいろ便利なものが用意されているんですね。さっきお話したのはコンテナデプロイとサービスディスカバリ、ロードバランスあたりについてでした。

ほかに便利なCLIアプリケーションがたくさん用意されていて。kubectlというVMでいうSSHコマンドみたいななんでもできるコマンドがついてます。あとhelmっていうパッケージマネージャがあって、例えばWordPressをコマンド1個でKubernetesクラスタにインストールしたりとかそういうことができますね。

あとは便利なAPIがたくさんあります。KubernetesってよくLinuxに例えられます。API、Linuxでいうsyscall。KubernetesのシステムもKubernetesのAPIを呼ぶGo言語のプログラムとして実装されてます。

その同じAPIを、我々は自分たちの作ったソフトウェアから活用することができます。なのでそのAPIを使ってKubernetesのシステムを再実装することもやろうと思えばできます。まあ意味があるかはともかく。

それをサポートする便利なライブラリもあって、Node.jsやJavaとか、あとGo言語。Go言語が1番有名かな。オフィシャルにそういうたくさんの言語向けのKubernetesのAPIを呼べるクライアントライブラリがあります。

そういったものを使っての分散システムを組むような。例えばリーダーエレクションの機能が付いてるライブラリとかもあったりして。そういうものを活用することはできるんですね。もうコンテナオーケストレーションというか、なんなんでしょうね？　これは。

あとはそれらを活用してKubernetesを拡張することはできます。認証を差し込むこともできるし、新しいバリエーションを追加することもできるし、なんならKubernetesに任意のデータモデルを定義して、任意のデータを詰め込むこともできるんですね。Kubernetesってデータベースだっけ？　みたいな。でも本当にそんな感じです。それをKubernetesのAPIから呼び出せたりもします。

Kubernetes用のツールを他のプラットフォームでも利用可

あとは豊富な周辺ツールですね。KubernetesはAWSだけのものじゃないので、例えばGCPとかAzureの大きなユーザーさんがKubernetes用に作ったツールをAWS上でも活用することができます。これはソフトウェアを作りたくない我々にとってはすごくありがたいことです。

Kubernetesの拡張性を表す例なんですが、こんなものがあります。

例えばmetacontrollerがあって、jsを100行ほど書いたりすると、KubernetesをBlue-Greenデプロイ対応にできたりする。中ではさっき言ったKubernetesのAPIを呼んでいるんですけど。そういうふうにちょっとクスリプト的なものを書くだけでKubernetesを拡張できたりします。

今までであればおそらくSSHコマンドを呼ぶCapistranoを魔改造するとか、そういうことをBashスクリプトでがんばって組むとか、そんな感じでやってたことをもうちょっとKubernetesのフレームワークに乗ってやることができます。

あとはsquashっていうのがあって、これはマイクロサービスのデバッガですね。Microservicesアーキテクチャになってすべてコンテナ化していくと、今度、例えばお客さんが特定の機能を使ったら10個とかコンテナで動いてるプログラムが協調動作してやっと仕事が終わります。

ですが、例えばエラーが起きたときに、どこのコンテナの何でエラーが起きたのかわからなくなるし、それをデバッガをアタッチしてデバックしようとすると困難なんですね。

まずコンテナにトンネルを張って、もしくはVPNでつないでとかになりますけど、そんなことやってられないですよね。そういういったことをKubernetesという共通された基盤の中でsquashというデバックを作ってくれている人がいて、活用することができます。

あとはワークフローエンジンがKubernetes前提で組まれていたりとか。おもしろいのがKubernetesで動いているコンテナとLambda Functionを同じようにリバースプロキシしてロードバランスしてくれるゲートウェイとか。そんなものもあったりします。もうなにを言っているのかわからないすね。でもこれぐらい拡張性があります。

Kubernetesを使うべき場面

ちょっと脱線しちゃいましたが、これを踏まえて、僕がKubernetesの使いどころだと思ってるのはこういう点ですね。コンテナの運用を確実に助けてくれます。Lambda、ECSより汎用的です。なのでコンテナ運用を激しく自動化したいという場合にKubernetesは今でも役立ちます。

Kubernetesを構築する手間を押してでもコンテナの運用自体を自動化したい、そういう場合には役立ちますね。どう助けてくれるかと言うと、Kubernetes自体の機能がECSより大きいというのもありますけど、KubernetesのAPIとSDKの存在が多くて、ほかのクラウドを使っているユーザーが作ってくれたツールをそのまま自社に適応できるケースがあるんですよ。それなりに。

なのでそうしたものをうまく選ぶことができれば、自分たちでシステムを作りこまなくても、ちょっとしたパースみたいなものが作れて、運用がすごくはかどります。

Lambda、ECSより汎用的で、なんと言うかこのコンテナオーケストレーションよりは分散システムのフレームワークのような感じなんですね。実際Kubernetesで動くFaaSみたいなのも存在します。

なので、なんて言うのかな、KubernetesとFaaSのどちらを選ぶかというよりは、FaaSだけで自分たちの仕事が済まないんだったらKubernetesを選んでその上でFaaSを選択するということもありなんですね。そういうレイヤーのものです。どちらか選ぶというものでもありません。

その分汎用的なので激しく学習コストが高いです。まあなんにでも使えるので。例えば僕はこの質問はノーなんですけど、みなさん「Linuxわかります」って言えますか？（笑）。「Linuxがわかる」ってどこまでなんでしょうね。システムコールすべて扱えるとかそういうレベルだとすると僕はぜんぜんできないですね。

でもKubernetesってそういうレベルのものなんです。コンテナをプロセスと見立てると、LinuxはKubernetesで、裏側にEC2インスタンスが何千台あるのかわかりませんが、それを1つのコンピューターと見立てたときのOSがKubernetesなんです。システムコールはAPIです。APIがあればそのコンピューターは自在にプログラムできますというものなので。

なんでもできるが故にめちゃめちゃ学習コストが高いので、そういったことを躊躇する場合は採用はためらった方がいいと思います。

freeeはKubernetesをどう使っているか？

やっとfreeeの話ができるんですが、それでも利用例はこれだけです。新規サービスを徐々にKubernetes化していっています。うちはマイクロサービスが徐々に増えてきたので、やっぱり運用上の課題があります。そのために新規サービスを徐々にKubernetes化しています。

既存サービスはまずDocker化から始めています。必ずしもKubernetes化しなくてもいいかなと思ってるんですね。結局目的は運用の効率化なので、別に既存サービスの運用が高度に自動化されているのであれば無理にコンテナ化、Kubernetes化する必要ないんですよね。

うちの場合、新規サービスでそうした高度な運用の自動化をしている暇がないので、先にKubernetesで基盤を作っちゃって同じ基盤でみんな同じように自動化されるような感じにしたかった。楽をしたいからKubernetesを使ってるだけです。

とは言ってもやっぱり学習コストが高いのでオンボーディング勉強会みたいなことをやっていて、Kubernetesを採用するプロジェクトの開始時には必要に応じて僕が勉強会をやるみたいなことをしてます。

あとはできるだけ作り込まないということを徹底しています。Kubernetesを構築して運用するだけでけっこう工数取られるんですよね。だからKubernetesで自社の超かっこいいPaaSとかを作ろうと思わない方がいいかなと僕は思ってます。

なんですが、例えばCapistranoでデプロイ自動化するということをけっこう各社されてて。Capistranoのレシピをちょっと書き換えて自社のデプロイの要件に合わせるようにカスタマイズするじゃないですか。そのレベルのカスタマイズにとどめて、それでもできることは増えるのがKubernetesです。

また、Kubernetesは買われていますが、Kubernetes上で動くPaaSみたいなものはないので、けっこう自動化の余地はあるんですね。自動化しようと思うとみなさんそういうKubernetesで動くアプリケーションを作ることになるんですけど。

freeeみたいなスタートアップだとそれに割ける人って少ないので、基本的にうちではKubernetesのツールを自社だけで作るということはやっていません。既存のOSSのメンテナになったり、メジャーのOSSをそのまま使うとか、そういったかたちでできるだけOSSコミュニティと一体になって自社で開発を持たないようにして自動化を進めてます。

そうしていずれプライベートPaaSみたいなのを自社内に提供できたらいいかなと思ってます。

待望のマネージドサービス、Amazon EKS

EKSの話をしますね。EKSは待望のKubernetesのマネージドサービスです。まだGAにはなってないのかな。日本にもまだ来る予定はないんですが、待望のサービスでして。

これは何か一言で言うと、Kubernetesのコントロールプレーンをマネージしてくれるというサービスです。コントロールプレーンというのは、さっき言ったEtcdというkey-valueストアとかKubernetesのシステムとか、そういうものをマネージしてくれるってことですね。

逆に言うとみなさんのユーザーのコンテナを動かすEC2インスタンスは自分で持ってきてくださいというモデルなんですよ。まあ良し悪しがあって。例えば競合の話をしてしまうと、GCPとAzureだったらワーカーノードも含めてフルマネージなんですね。楽といえば楽です。

ただしカスタマイズ性がちょっと制限されます。GCPだったらGCPがKubernetesのマネージドサービスで対応しているカスタマイズしかできません。

逆にEKSのいいところは、自分たちでEC2インスタンスをつなげるだけなので、そのつなげるEC2インスタンスはいかようにでもカスタマイズしていいんですね。トレンドマイクロさんのDeep Security入れたりとかでもいいですし。そういうことも自在にできます。

それはおそらくGCPだと難しいかもしれない。すぐ対応してくれるので、すぐいたちごっこになるかもしれません。

あとは肝心なところはけっこうちゃんとサポートしてくれています。例えばAWS IAMの対応やVPCとの統合、Kubernetesって普通Kubernetesの仮想ネットワークを中に作っちゃうんですよ。

仮想ネットワークの中は、例えばVPCの中から直接見えないんですよね。Kubernetesを通さないとアクセスできない。そうすると例えば既存のコンテナ化されてないサービスからKubernetesで動かしているサービスにアクセスするときどうするんだと、ネットワーク分断されてるけど、みたいな。そういう話があるんですね。

でもEKSだったらVPCと統合されているので、一応VPCの中の同じIPレンジ中で普通に通信できるんですね。IPアドレスの裏側がEC2インスタンスかKubernetesで動いているコンテナなのかは、透過的になっているのでわかりません。

それぐらい統合されているので、そういう意味ではフルマネージドなサービスではないものの、すごく適応範囲は広いと思います。それがいいところですね。

今のところ僕の考えでは、EKSはKubernetes on AWSでやるときはすべからく使うべきであると思ってます。たださっきも言ったようにEKSだけで関係しないところ、ノードを持ち寄るところがまあ良し悪しでもありデメリットでもあるので、そこは自分でやることになります。

コンテナのこれから

そろそろ締めに入りたいと思います。だいたい話したいことは話したので、余興ですね。コンテナの未来の話をしようと思います。

おそらく、これからコンテナとKubernetesの規格がもっと定まってくると思います。コンテナもDockerだけだった時代からだいぶ規格が定まってきましたが、Kubernetesもおそらくそういう規格になっていくと思います。

すでにAzureやGCPやAWSさんとか、DigitalOceanもかな。いろいろなクラウドがKubernetesのマネージドサービスを始めてます。KubernetesのAPIを喋れるプログラマだったらどのクラウドでも同じようにコンピュートリソースを扱えるわけですよね。

そうなっていくと、我々がいちいちクラウドベンダーの差異に悩まされなくても、クラウドベンダーを活用してすごくビジネスを成長させることができます。そうなっていくと思いますね。

あとはKubernetesクラスタ自体の運用はもっと簡単になっていくと思います。EKSはまだコントロールプレーンだけが予定されてるみたいですけど、周辺ツールが成長してきたり、EKS自体が成長してきたりすることでもうちょっとKubernetes自体の運用が楽になっていくと思います。

そしてKubernetes上のアプリの運用が簡単になっていくと思います。先ほどお話ししたようにsquashみたいなマイクロサービスデバッガというのも出てきましたし。

結局我々がやりたかったことは、どこのコンテナで何のアプリが動いているかとか、それは別に本題じゃなくて、今ビジネスを動かしているこのサービスでエラーが出たらそれをすぐデバックしたいという、それだけなんですよね。そういうことをサポートしてくれるツールがもっと出てくると思います。

そうしたときKubernetesって何なのかって言うと、おそらくServerlessなんですよ。我々が触れるのは。Serverlessなんですけど、裏側は実はKubernetesだったりするので。

いざというときにKubernetesを利用できると、このServerlessで動かしてるサービスのすごく根本的なところで動きがおかしいんだけどっていうときに自分で解決できるかもしれない。そういう立ち位置のものになっていくと思います。

例えばですけど今「Linuxだからできない」ってことあんまないですよね。それぐらいKubernetesも空気になっていって、当たり前にKubernetesが使えていくようにはなっていくと思います。

Kubernetesは銀の弾丸ではない

あと、これだけは言っておきたかったんですけど、ECSはいらない子なのか？

（会場笑）

断じて否です。いいえ（笑）。今何が起きてるかと言うと、ECSとFargateがServerless Kubernetesのバックエンドになってます。

virtual kubeletというプロジェクトがKubernetes界隈であって。これはKubernetesが「こんなコンテナ作りたいよ」って言ったやつをうまいこと ECSで作ってくれる。ECSでマネージしてくれるというミドルウェアみたいなものです。

なので我々は別に利用者としては普通にKubernetesAPIを叩くコマンドでKubernetesを利用しているんだけども、その裏側が実はFargateだったりすると。そうなってきてます。

長期的に見るとKubernetesとECSの両方わかるほうが安心して運用できると思います。なのでいらない子じゃないです。みなさん両方やってください。あ、でもKubernetesは慎重に。

まとめますと、「Right Abstraction. Right Tool.」。これが今日持ち帰っていただきたいことでした。抽象レベルの違い、意識できるようになりましたか？

VMとコンテナとFunctionの話をしました。今後正しいツールを選べるように。Kubernetesは銀の弾丸ではないことがおわかりいただけたかと思います。

VMはServer Configuration Managementしたりしますよね。コンテナだったらコンテナオーケストレーションです。Kubernetesはその手段の1個です。

Functionだったら運用にいろいろな選択肢があります。どれが来るんでしょう。この運用が定まってきたときにもっとFunctionを使う適用領域って増えると思いますね。でも今なのかという問いかけをしたいです。

将来的にはFaaSの裏側はKubernetesになっていくと思います。なので学習が目的だったら早めにやって損はないかなと思います。でもビジネス利用は計画的にお願いします。というところでこの話を締めさせていただきます。ありがとうございました。

（会場拍手）