AWSでDockerを乗りこなせ〜AWS FargateからKubernetesまで〜
西谷圭介氏（以下、西谷）：みなさま、こんにちは。Amazonの西谷と申します。よろしくお願いします。今日は前半で私からAWSのコンテナサービスをご紹介させていただきます。後半はfreeeの九岡さんからKubernetes等のお話をさせていただきます。
というわけで、さっそく進めていきたいと思います。
改めまして、Amazonの西谷と申します。ふだんはスペシャリストSA（Solutions Architect）という、どちらかと言うとテクノロジーやソリューションにフォーカスしているソリューションアーキテクトをしています。コンテナやサーバー レスなど、デベロッパー的な動きを担当しています。
最初に告知で申し訳ないのですが、いくつか本を書いています。新しいサーバーレスアプリケーション開発の本がちょうど今週末（2018年3月16日）に出ますので、よろしければお手に取っていただけたらなと思います。あとは今月末（2018年3月28日）に予約者・購入者限定のイベントもやります。
もともとAWSのコミュニティに「JAWS」というものがあるんですけれども、少し切り口の違う、デベロッパー向けの新しいコミュニティ「Meguro.dev」というものを始めていまして、今月末の3月30日に第1回が開催予定となっています。「connpass」で「Meguro.dev」と検索してもらえれば出てくると思います。
AWSのコンテナが愛される3つの理由
今日は、AWSのコンテナサービスについてお話しさせていただくのですが、その前にそもそも「なぜ昨今、コンテナがこれほどもてはやされているのか？」というところの理由を少しまとめてみたので、まず最初にその話をしたいと思います。
理由は大きく分けて、パッケージング、配布、イミュータブルインフラストラクチャという3つの部分があると思います。
パッケージの部分に関していうと、アプリケーションをコンポーネントレベルで考えたり、モデル化することが容易になるのかなと思います。その結果、これまた昨今トレンドのマイクロサービスだとか12 factorなアプリケーションが作りやすくなっていくのではないかと思います。
あとは配布です。コンテナ、とくにDockerかなと思うのですが、コンテナイメージというものがアプリケーションに必要な依存関係などもすべて含めて、それが小さく軽量なのでほとんどどのようなマシン上でも動くという、繰り返し実行可能ということが大きな特徴かなと思います。
最後は、イミュータブルインフラストラクチャです。パッケージングと配布の2つによって、必要に応じてスケールさせられるイミュータブルな基盤が簡単に実現できると言えます。
この3つがコンテナが愛される理由かなと思うのですが、そうは言ってもいまいちよくわからないかなというところで、もう少しわかりやすく説明したいと思います。
スタートアップこそコンテナを活用すべき
先ほどコンテナが人気の理由を3つあげましたが、「結局のところコンテナのメリットって何なんだ？」というところを簡単にご紹介したいと思います。
これも大きく分けて3つあると思っています。Portability & Flexibility、Fast & Rapid、Efficientと書いていますが、これだけだとわかりづらいと思うので、1つずつ見ていきます。
Portabilityは言葉どおり、可搬性が高いということだと思います。特定のイメージをいつどこで実行しても、まったく同じ環境が動くということが一番のポイントです。
Flexibilityは、Dockerを触ったことがある方はご存知かと思うのですが、再現可能な環境の策定が柔軟性を持って可能、各イメージ自体のバージョン管理もできるというところがポイントです。
その結果、容易な構成管理と自動化が実現できるということが最初の利点だと思います。これを例えば、chefとかansibleで一生懸命いろいろと書いていたものがDockerfileという、定型ファイルだけで落ち着くということが1つのポイントです。
続いて、Fast & Rapidです。日本語では同じ「速い」という言葉になってしまうのですけれども、1つはそもそも「起動が速い」というのは、Dockerの利点としてよく言われていることかなと思います。先ほどお話したように、アプリとそのアプリに必要な依存関係だけがパッケージングされていることから、コンテナというのは所詮はただのプロセスなので、非常に起動が速いと言えます。
もう1つが「開発-テスト-本番まで一貫したイメージを利用したCI/CDのパイプライン構築が可能」と書いてますが、このようなCI/CDのパイプラインをきちんと整理することで、フィードバックループを速く回すことができるようになると言えます。
その結果この2つは、「繰り返し」に強いということが言えます。「繰り返し」に強いということは、例えば、先行き不透明なスタートアップだからこそ必要なトライ&エラーがやりやすかいのかなと思います。
例えば、そもそもサーバの起動が遅かったり、パイプラインそのものが重厚長大だったりすると、トライ&エラーがそうそうできなくなったりするので、非常に大事なポイントかなと思います。
最後のEfficientは効率性なのですが、2種類の意味があるかなと思います。
そもそも1サーバ上で複数のサービスを動かすことになるので、そのサーバが持っているリソースを余すことなく使うことができる。高集積にすることで、リソース効率が向上するということです。
あとは先ほどの、起動が速いとか、パッケージが小さいという点によって、よりダイナミックなスケーラビリティが実現できるので、バッファとして確保しておく、余らせておくリソースが減らせるというところで無駄を削減できると思います。
結果的にはこの2つによって、コスト効率が非常に高くなるということです。
というわけで、少し整理をします。
少人数で、低コストに、トライ&エラーを繰り返し、速くフィードバックループを回す必要があるスタートアップこそコンテナを活用すべきではないか、ということが私からの1つのメッセージになります。
ここでは、コンテナのユースケースを大きく3つあげています。マイクロサービスアーキテクチャ、非同期ジョブ実行、あとは先ほどお話ししたCI/CDのパイプライン（継続的インテグレーション、継続的デプロイ）です。
このようなユースケースはいろいろとあるのですが、今日の本題として、私からそのようなコンテナを管理運用していくための、AWSのコンテナサービス関連をご紹介したいと思います。
Amazon Container Servicesの全体像
まず、Amazonのコンテナサービス全体像はこのようなかたちになっています。
レジストリとしてAmazon ECR、コントロールプレーンとしてAmazon ECSとAmazon EKSの2つ、データプレーンとしてAWS Fargateが存在しています。それぞれご説明していきます。
まず1つ目は、Amazon ECRです。これはいわゆるフルマネージドな高可用性・スケーラブルなレジストリで、信頼性と性能の高いDockerのイメージレジストリを構築するようなサービスになっています。
当然ながらAWSのサービスなので、IAMによる認証管理機構などもサポートされています。あとは開発者がDockerと同じPush PullのAPIを使ってコンテナイメージが保管できるようになっています。
2つ目は、Amazon ECSです。実はAWSとコンテナという観点でDay1と言えるサービスがこのAmazon ECSになります。
3年くらい前にローンチしたのですが、AWS上へのDockerコンテナのデプロイと管理とスケールが求められていて、それらを実現するようなサービスになっています。
その後、ここ数年でAmazon ECS自体は非常にたくさんの本番利用が進んでいます。2016年比較で、アクティブユーザーがだいたい450パーセントくらい増えていて、毎月数百万くらいのインスタンス上でコンテナが管理されています。
2015年にGAしたのですが、それ以降、お客さまからのフィードバックをもとに50以上の新機能がリリースされています。
このECSなのですが、もともとプロダクションでコンテナをAWSの上で大規模運用するお客さまを支援するために機能を開発してきていて、個々には説明しませんが、このような機能群があります。
いくつかECSの概念的なものがあるので、簡単にご紹介したいと思います。
1つ目は、Taskです。これはコンテナ（群）の実行単位なのですが、Task Definitionというファイルを使って定義することができます。Taskないのコンテナ群はこの情報から実行されるかたちになります。CPUとメモリの上限を指定するものです。
2つ目は、Serviceです。Taskの数を希望数に保ったり、ELBと連携することもできます。
Amazon ECSはAWSのサービスなので、当然ながらIAMとの統合も行われています。
IAM RoleをTaskごとに設定可能になっていたり、AWS SDKを使って自動的に認証情報が得られるようになっています。
AWSのVPCのネットワークモードです。こちらを使うと、TaskごとにENIを割り当てることができます。何ができるかというと、セキュリティグループをTaskごとに設定可能になるというものです。
その他いくつかAmazon ECSの特徴があります。Amazon CloudWatch Logsというログを収集するサービスと簡単に連携できるようになってたり、Amazon CloudWatch Eventsというサービスと連携して各種イベントが流れるようになっています。
顧客はアプリケーション開発に集中したい
3年前にローンチしたということもあって、数多くの事例があります。国内外で企業規模の大小や業種を問わず、いろいろなお客さまに使っていただいています。
先ほども、この3年間でいろんなフィードバックをもとに50以上の機能を開発してリリースしてきたという話をしました。いろいろなフィードバックが寄せられているのですが、その中でもっとも多かったフィードバックというのは、コンテナまたはアプリケーションのことだけを考えたいということです。
Amazon ECSは、コンテナを動かすデータプレーンという部分のEC2の管理が必要になるのですが、そのインスタンスの管理はしたくないというフィードバックが非常に多かったです。
そのような声にお応えするかたちで、新たに提供を開始しているのがAWS Fargateというサービスになります。
これはインスタンスの管理の必要なくコンテナを実行できる新しいテクノロジーになっています。
あとはタスクネイティブAPIによってクラスタそのものの心配が不要になります。利用効率だったりオートスケーリングといったものも考える必要はありません。
あとリソースベースの価格モデルによって、Taskに割り当てられたリソースにだけお金を払えばいいという話なのですが、わかりづらいと思うのでこのあと説明します。
繰り返しになるのですが、コンテナを動かすEC2インスタンスのデータプレーンと呼ばれる部分の中に、ECSのTaskが動いています。
その上で、ECSのコントロールプレーンと呼ばれる各EC2インスタンス、どこのEC2インスタンスにTaskを起動するかというスケジューリングのためのコントロールプレーンが動いていたのですが、AWS Fargateは、ECSの既存のコントロールプレーンをそのまま使える状態でフルマネージドなデータプレーンが使えます。
つまり、EC2のインスタンスの管理をする必要がないので、そのあたりを気にせずに、これまで以上にその上で動かすコンテナにフォーカスできるということが最大のメリットかなと思います。
AWS FargateはAmazon ECSと一緒に使うように設計されているので、他のAWSサービスとの深い連携や強力なスケジューラ、オートスケーリング、ロードバランといったような、過去3年間に開発してきた機能群がすべて利用できるようになっています。
料金に関しては、用意されたCPUとメモリの組み合わせをTask Definitionの中で定義することで、それをもとにした実行時間が秒単位で課金するようなモデルになっています。
CPUとメモリの設定が選択肢として50個くらい用意されているので、その中から好みのものを使うというかたちになるわけです。
これ（スライド右図）はECSのスクリーンショットなのですが、実はECSを使う場合、ECSで使う新しいサービスというよりかは、ECSの1つのモードになっていまして、TaskのローンチタイプとしてAWS Fargateを選択するだけでよかったりします。
ECSクラスタの、今のEC2上でコンテナを実行したい場合は、これまでどおりEC2を選択するとEC2上で動かすこともできます。ECSの概念はそのまま使えます。同じクラスタでEC2と混在することも可能になっています。
あとはその他の特徴として、VPC INTEGRATIONとか、ALB/NLBが使えるようになっているとか、先ほどご紹介したECR、Public Repositoryがサポートされています。
FargateモードとEC2モードの話をしましたが、ここの使い分けは基本的にFargateで大丈夫かなと思いますが、Fargateでは難しいものがいくつかあるのも事実です。例えば、ここに挙げているWindows ContainersなどはEC2モードで動かしてもらうのがいいかなと思います。
Amazon FargateとAWS Lambdaの使い分け
料金モデルのところではCPUとメモリの設定と、Taskが動いている実行時間に対して秒単位で課金するというところで、Lambdaというサービスをご存知の方は、Lambdaとの違いも少し気になるかなと思います。
ここの使い分けはわりとシンプルです。Lambdaはいわゆるイベントドリブンなプラットフォームになっていたり、ランタイム管理も不要になっているので、イベントドリブンなアプリケーションを作りたいという場合はLambdaを使えばいいかなと思います。
逆に言うと、それ以外はFargateを使ってもらうのがいいかなと思います。例えばLambdaの場合、実行時間に制限があるということをご存知の方も多いかなと思うのですが、 Fargateの場合、そのような制限はとくにないので、ロングランニングなローンチなどにも向いているかなと思います。
あとはL3 L7でロードバランシングしたり、ネットワーク関連のオプションをコントロールしたり、そのような柔軟性がより必要になる場合は、Fargateを使ってもらうということで、どちらかを選ぶというか、特性に合わせて使い分けてもらう、組み合わせてもらうのがいいかと思います。
先日、EC2やEBSのSLAがこれまでの稼働実績をもとに99.99パーセントに引き上げられたのですが、同時にこのECSとFargateの中に含まれていたりします。
Kubernetesの特長
最後、コンテナというところで当然Kubernetesに触れないわけにはいかないので、この話を少しして私のパートを終わりたいと思います。
ご存知ない方はあまりいらっしゃらないかなと思うのですが、Kubernetesはオープンソースのコンテナ管理のプラットフォームです。
ここ12ヶ月くらいで非常に人気が出ているかなと思います。もちろんAWSのカスタマーでKubernetesをご利用になっている方も多いです。コンテナの大規模な運用に有用だったり、という部分があります。
CNCF surveyという団体のアンケートによると、実はのKubernetesのユーザーの63パーセントは、今日時点でAWSを利用しています。
そうは言っても、みなさんオープンソースのプラットフォームなので、EC2上で自前で動かしているのですが、それを自前で管理するのは大変だよねという声が大きくて、そこでAmazon EKSというサービスの提供も最近始めています。
というわけで、私のパートは以上になります。KubernetesおよびAmazon EKSの話は九岡さんにお話をしていただこうと思います。
Kubernetes on AWS
九岡佑介氏（以下、九岡）：代わりまして、九岡がKubernetes on AWSの話をいたします。freeeでSREとして働いていまして、副業でChatWorkの技術顧問もやっています。あとはmumoshuという名前でGitHub/Twitterをやっています。よろしくお願いします。
さっそくなのですが、コンテナを取り巻く環境の話をしていきたいと思います。
僕の頭の中で、コンテナを取り巻く環境をいろいろと書いてみようと思って、スライド1枚くらいにまとまればいいなと思ったんですけど……やってみるとこうなっちゃうんですよね。
どこから話していいのかわからないので、今日持ち帰っていただきたいなと思っているのはこれだけです。
Right abstraction, right tool. ということで、抽象レベルの違いをちゃんと意識できるようになってほしいです。何の抽象レベルのことかというと、VMとコンテナとファンクションの話です。
あとは、今後正しいツールを選べるようにということで、最初に言っておきたいのですが、Kubernetesは銀の弾丸「ではない」ので、Kubernetesをどう使いわけていくかという話をしていきます。そのときにまたコンテナとVMとファンクションの話をします。
みなさん覚えてますか？ このイベントのテーマは「実践知」なので、これは今日話さないことにしました。Kubernetesの歴史や特定ツールの使い方など、ググればわかるようなことは話しません。
アジェンダに戻ります。
AWSのことはみなさんよくご存知だと思うので、あまり触れません。そのような文脈でいうと、Kubernetesの概要はよく知られていると思います。
GoogleのBorgというシステムが起源になっていまして、けっこう大昔からありました。コンテナオーケストレーションシステムというもので、ひと言でいうと、Dockerコンテナをいい感じにデプロイしてくれるやつです。
Kubernetes自体は2014年にOSSとして公開されまして、プロジェクト自体は今年で5年目に入りました。その2年後の2016年にバージョン1.0、プロダクションレディになりました。
CNCF（Cloud Native Computing Foundation）というところで管理されていまして、AWSさんも昨年加入されましたね。今年になってCNCFを卒業して、十分にメジャーなプロジェクトということで認定されました。
逆によく知られていないことはこれです。
「なぜKubernetesを使うべきではないのか？」。みなさん10秒くらい考えてみてください。それぞれ答えがあると思うんですけど、僕なりに考えたのは、切っても切れない問いが2つありまして、なぜコンテナを使うのかという話となぜECSを使うのかという話です。
スタートアップの生産性・エンジニア不足の課題
「オーケストレーション以前に、そもそも、なぜコンテナ？」というところから話したいんですけど、スタートアップの課題のトレンドとして、「生産性が上がりません」「エンジニアが足りません」というのはけっこうどこでも言われていることだと思います。
生産性に関することとか、チーム間の調整コストが高くなってきたとか、意思決定に時間がかかるとか。
あとは宗教戦争が起こりがちで、道具にこだわりたい派とアウトプットにこだわりたい派と両立したい派があるんです。ちなみに僕は道具にこだわりたい派なんですけど、だいたい宗教戦争を起こしてます。
あとは「エンジニアが足りません」という話なんですけど、売り手市場で採用したいけど来ないとか、人件費が高沸しているということがあります。
サービス開発のトレンド2つ
そのような文脈で、最近のスタートアップにおけるサービス開発のトレンドをあげると、僕の観測範囲では2つあるなと思っています。
Microservicesアーキテクチャがすごく進んでいるということと、リモートワークが徐々に浸透してきている気がします。
Microservicesアーキテクチャは、チーム間の調整コストをできるだけ下げたいという文脈で採用されていることがすごく多いです。APIで疎結合のサービス間をつなぐようにしていくと、それぞれAPIさえ変えなければ自由に案件を進めていいということになります。
それで齟齬が出るのではないかということで、マイクロサービス化が進められている会社がよく見受けられます。こうすると言語などの宗教戦争が起きづらいんです。自由があるよということで強制しないだけなので、実際には同じ言語で作られることもあると思うんですけど、そのような文脈で使われています。
あとはリモートワークです。分散チームをあまり気にしない人とか、マイクロサービスの文脈で、そもそもこのサービスだけはリモートワークのチームがやっていてもそんなに調整コストがかからないという文脈で使われていたりします。あとは若者のチャット慣れということもありますね。
そのような状態で、「どの抽象レイヤー以降で課題を解決するか？」という話があります。
たぶんスタートアップのみなさんは、達成したい大きなビジョンがあって、そのためにコードを書いていると思います。
コードを書くということは、コンピュータに何か役に立つことをさせようとしていると思うんですけど、そのときにどこでそのコードを動かすかというのはすごく大事な話です。それが物理マシンなのか、仮想マシンなのか、コンテナなのか、Functionなのか、選択肢が4つあります。
違いで比較するといいかなと思って書いてみました。AWSさんのイベントなので、物理マシンはとりあえず置いておきます（笑）。
仮想マシン、コンテナ、関数でいうと、仮想マシンはマシンイメージからつくります。物理マシン上で動かす。あまり物理マシンのことを気にすることはないかもしれないですけど、そのような感じです。
コンテナはコンテナイメージからつくって、それが物理マシンか仮想マシン上で動きます。関数はスクリプトやバイナリから作って、マシンやコンテナ、LambdaのようなFaaS上で動きます。
仮想マシンや物理マシンの「これはどうかな？」と思うところは、複数チームのサービスが1つのVNにうっかり乗っかってしまったりします。なので「この機能だけ切り出したい…」ということがスタートアップで1、2年やっているとよくあります。
コンテナになるとどうなるかというと、コンテナにうっかり複数サービスが乗っかってしまうということがあるので、コンテナで動かしている一部分だけを切り出したいということはまだあります。
関数だったら、「関数のこの機能だけ切り出せない」ということはあまりないです。だいぶ解決されると思います。
FaaSの新しさは何かというと、関数をデプロイの単位としたことです。 FargateとかECSだったらコンテナが単位になっていますし、Lambdaだったら関数をデプロイします。
これまでは違っていて、capistrano deployとかしていたわけです。Javaだったらwarをまいたりしていたわけです。
Dockerでもコンテナイメージをまきますけど、FaaSだったら関数をまくわけですね。なので、「これまで悩んでいたことがけっこう解決するのではないか？」「FaaS最強では？」ということで、実際にそうだと思います。
ただ、ここでよく知られていないことが1つあります。「なぜ今さら、Functionではなくコンテナなのか？」。
それはこの話に戻ってくるんですけど、仮想マシンを管理しなきゃいけないんです。仮想マシンをどうやって管理していたかというと、ChefやPuppet、Ansible、CloudFormationなどで管理していました。
コンテナはどうするかというと、DockerやECS、Kubernetesなどで管理しています。関数はLambdaやOpen FaaS、OpenWhiskなどいろいろあります。
僕はこれがすごくネックになっていて、仮想マシン、コンテナ、関数……全部いいんです。関数が使えれば全部関数にしたいんですけれども、ツールが揃ってないと運用が大変です。
会社によっていろいろ違うんですね。サーバーレスでうまく運用回せるところはたぶんそういう案件規模で収まってるか、ツールがうまいこと自分たちにフィットしなくて自分たちで作らなくて済んでいるかだと思います。
なので「コンテナとか関数のマネジメントってどうしたらいいの？」という問題に即答できない人は、まだコンテナとか関数とかは使えないです。使えるところはいいです。
なぜ今、コンテナなのか
まとめると、なぜ今コンテナなのかというと、比較論でいうと、「ツールが揃ってなくて運用が大変だから」。このひと言に尽きます。
コンテナの話をしているときに、なぜコンテナオーケストレーションが出てくるかというと、けっこうわかりきっている課題があります。コンテナをデプロイするのにsshでは済まないんですね。cap deploy dockerとかしないわけです。
なぜそうしないかというと、コンテナはその性質上、VMより落ちやすいです。不安定という意味じはなくて、そのような運用になりがちということです。なので、コンテナが落ちたときにほかのノードへ自動移行してほしいとか、そのような固有の事情がありますよね。
あとコンテナのロードバランサに自動でつなぎたいよね、EC2インスタンスみたいにとか。サーバの余剰リソースでコンテナを動かしてほしい。コンテナはネームスペースで隔離されていて、そういうことができるはずですよねとか。いろいろあるんですね。
こういうことをやろうとすると途端にsshでは済まなくなります。だからコンテナオーケストレーションが必要です。
なぜKubernetesを使うべきではないのか？
やっとKubernetesに戻ってきた感があるのですが、まだネガティヴな話をします。「なぜKubernetesを使うべきではないのか？」
コンテナオーケストレーションシステム、Amazon ECSとKubernetesの2つを比較します。
ECSはひと言でいうと、コンテナデプロイのサービスだと思っています。
Kubernetesもそういう意味では、コンテナデプロイのシステムでしかないんですね。
そのような状態で、運用者目線でのECSのメリットを見ます。
ECSがすごくいいのは、AWS公式の専用のAMIがあるんです。そのAMIで何が動くかというと、DockerのデーモンとECSのAgentと、まあいろいろ動くんですけれども。
僕たちがスタートアップのビジネス向けのサービスを作っているときに、DockerとOSとECS Agentの相性問題のバグみたいなものを踏みたくないわけです。どこかでマネージしてくれるものを使いたいですよね。
それはAWSさんがマネージしてくれます。ECSのコントロールプレーン、マネージしてくれますよね。そのようなマネージサービスがあるというのは、運用負荷を軽減するにはすごく重要です。
あとECSだとSegment社というところの事例がすごく大きくて、あそこはECSの周辺ツールをすごくOSSで公開していて、なかなかの規模でサービスを運用されています。
こういうものがあると、だいたいのケースで「うちの会社でも、あそこの会社のような規模だったらECSでいけるか」と確信を持って採用できます。それはメリットです。
日本での採用事例も多いですし、あとスコープが限られているということは僕はソフトエンジニアとしてはすごく重要だなと思っています。
あまりにも便利機能を増やしすぎると、ECSだけ覚えればいいということにもなりますけど、そうするとECSの敷居も上がりますし、バージョンアップ辛い問題が発生するんですね。
Railsなんでもできますけど、Railsのアップデートはそこそこ辛い。Rails専用、アプリ専任の人とか欲しくなってしまうくらい辛かったりするので。それがECSみたいなインフラのレベルで起こるとすごく辛いです。
今度は運用者目線でのKubernetesの話をすると、正直に言って、Kubernetesのデメリットにつながってしまいます。
AWS公式の専用のAMI……ないです、そんなもの。マネージドサービス、そんなものは最近までありませんでした。
Kubernetes on AWSといえばこの会社という事例は、少なくとも日本にはないです。海外に行くと、「Hotels.com」とか「Zalando」というヨーロッパのファッションサイトなど、いろいろ大きいところがあります。でもSegment社レベルで、日本でも世界中でも知られているKubernetes on AWSの事例はあまりないんです。これはちょっと心配ですね。
日本での採用事例もまだまだ少ないです。僕の関わっているChatWorkとfreeeと、あとWantedlyさんでプロダクション利用されていますけれども、まだまだ少ないです。あとはスコープが広いんですね。実はコンテナデプロイだけではないんです。
まとめると、ECSより運用が難しいです。Lambdaほどはうれしくないです。FaaSではないから。
KubernetesとEKSの使いどころ
ここでアジェンダに戻ってきました。今、折り返し地点です。これから3番のKubernetesとEKSの使いどころに入っていきます。ちょっと休憩させてください。
ではKubernetesとEKSの使いどころの話をしていきます。何度もこの話をしている気がするんですけど、ツールの違いは運用と適用領域の違いです。
なのでサーバーレスとかFaaSとかに適応しやすい課題と、コンテナとかECSに適応しやすい課題と、Kubernetes用のアプリとKubernetesの組み合わせで解決できる課題は違います。
課題解決にどんな機能を使うかという話がすごく大切ですけど。Kubernetesの機能をよくよく見てみると、コンテナのデプロイだけではないんですね。
サービスディスカバリがあります。クラスタ内のDNSサーバーがいて、サービス名をDNSサーバーにルックアップかけるとIPアドレス返ってきたりしますね。便利ですね。
ロードバランサもあります。クラスタ内のネットワークではELBとかを立てなくてもロードバランスできます。VMの時代だとsshで何か不満を叩けばできないことって基本的にないと思うんですね。それくらいリッチなkubectlというCLIがあります。極論、これを叩いていれば運用はできます。EC2インスタンスをSSHやSCPで手運用しているようなものです。不可能ではない。
あとは便利なAPIがあります。Kubernetesの機能はすべてオープンのAPIで提供されています。それを叩けるライブラリもあります。これ不思議なのは、そのAPIをただ呼ぶだけではなくて、APIを使って便利機能をアプリに組み込む機能も入っているんです。
例えばリーダーエレクションですね。分散システムを組むときにそのような機能が必要になることがあるんですけど、そういうのもライブラリでカバーしています。
そのようなリッチなAPIとリッチなライブラリのおかげで、周辺ツールがすごく豊富です。たとえば、AWSでコンテナを動かすときにGCPとかAzureのユーザーが作ったツールが使えるわけです。これはけっこう便利です。
あとは拡張性です。Kubernetesのバリデーションの仕組みとか、認証の機能とか、データモデルとか、基本的に拡張できます。拡張できると何がうれしいのかという話なんですけど、このような例があります。
metacontrollerというプロジェクトがあって、jsを100行くらい書くとKubernetesをBlue-Greenデプロイ対応にできるんですね。それくらい拡張性があります。
あとはsquashっていうおもしろツールがあります。Kubernetes上でマイクロサービスが何十個も動いたりするじゃないですか。どうやってデバッカーをアタッチするかという問題があって、普通に考えるとデバックできないですよね。なんですけど、squashを使うとKubernetes上で動くマイクロサービスにデバッカーをアタッチできます。
あとはargoというワークフローエンジンがあって、Kubernetes前提なんですね。ワークフローエンジンって、「こういうタスクとこういう依存関係で順番に実行、失敗したら勝手にリトライしてね。データを適切にIN・OUTしてね」みたいな。
こういうのがないと夜間バッチがとても辛いことになったりするんですけど、そういうものがKubernetes前提で組まれたりしています。Kubernetes前提にすることで、実装はとてもシンプルになっています。
あとはglooという、言うなればAWSのLambda Functionとコンテナをまとめて1本APIゲートウェイにぶら下げるみたいなものがあります。だからこのAPIゲートウェイ以降は実装がLambdaかもしれないし、コンテナかもしれないですよみたいな状態が作れます。これは拡張性の証拠だと思います。
さて、ここまで話したことを踏まえて、Kubernetesnの使いどころを考えました。
コンテナの運用を助けてくれるので、どうしてもコンテナの運用を効率的にしたい場合には使えます。
LambdaやECSより汎用的です。コンテナをデプロイするシステムというよりかは、本当に分散システムのフレームワークという感じなんです。FaaSやサーバーレスとかの基盤と考えてもいいと思います。
AWS LambdaみたいなものをKubernetes上で組むことができると思います。実際にそういうことでいくと10個とかあるんですね。Kubernetesは、そういうレイヤーのものです。
汎用的な分だけ学習コストがめちゃくちゃ高いので、学習コストを今払えないと思う段階では絶対採用しないほうがいいと思います。
僕の会社ではどのように使っているかというと、今、このようなことに使っています。
新規サービスをKubernetes化していっています。これは何かというと、インフラエンジニアの採用ってけっこう大変なんですよ。
そのような状態で、でもKubernetesを見れる人をうまく社内に1人2人立てられれば、けっこうインフラエンジニアがこれまでやってきたことをアプリエンジニアにオフロードできます。
それでアプリエンジニアに大きな権限を差し上げて、この手順でやれば、AWSのアカウントをそのまま渡すよりも、みなさん安全にセキュアな本番サービスを公開できますよ、というような手順に落とし込みやすいんです。結果的に、安全に組織をスケールしやすくなります。
うちは既存サービスはDocker化から始めています。新規サービスはKubernetes前提ですけど、既存サービスはいきなりそうはならないので、まずDockerイメージを作って適切なところから徐々にKubernetesに乗せたいね、という進め方をしています。
Kubernetesは学習コストが高いという話をしましたけど、うちはオンボーディング勉強会をやっていて、Kubernetesを初めて採用するチームには僕が勉強会をしています。そういうことをしないとなかなか採用が進まなかったり、明日は我が身なのですが例としてホットなので言及させていただくと、Teslaみたいなことになります。
TeslaがKubernetesの管理コンソールをインターネットに大公開してけっこうやばいことになってますけど、そういうことがないように基本は勉強会で押さえるほうがいいです。
できるだけ自社だけで作り込まないということも徹底しています。すごく学習コストが高いですし、Kubernetesがあまりにも汎用的すぎて、ツールを作れば自動化できるところが無限にあるんですね。
自社だけでやってると絶対に負債になるので、できるだけ必要になってもほかの会社さんとかOSSのプロジェクトとかと連携して、自社だけで1つのツールを抱え込まないようにしたほうがいいと思います。
うちは実際にそうしていて、基本的に仕事で使うツールは全部OSSプロジェクト、既存のプロジェクトがあればメンテナーになってやったりしてます。
例えば、うちのkube-awsというOSSがあるんですけど、KebernetesクラスタをAWSにデプロイするツールですね。それは僕がメンテナーをやっていたりします。
KubernetesにアプリをデプロイするhelmfileとかbrigadeというOSSがあるんですけど、そういうのは他のエンジニアや会社さんが最初に開発したものを、後から僕がメンテナーとして入ってやっています。そういうふうにしていないと、負債が多くなりすぎてやってられないです。
やっとEKSの特徴にたどり着きました。よかったです。時間が間に合いました。
EKSは待望のKubernetesクラスタのマネージドサービスです。良いところが2点あります。Kubernetesのコントロールブレーンだけをマネージしているサービスです。
これはECSと同じ仕組みですね。ECSはFargateを使うのもなければECSのコントロールプレーンをAWSさんがマネージしてくれて、そこにEC2インスタンスをつなぎこむ使い方だと思うんですね。それと一緒です。
これのメリットはノードのカスタマイズがしやすいということです。西谷さんもおっしゃっていましたけど、GPUを使いたいという場合、どうしてもEC2インスタンス側で手を入れる必要がありまして、そういうケースでもEKSで対応できることになります。ただ、そこは自分たちで作り込む必要があります。
あとはAWSのIAMやVPCとの統合です。この2点はAWSさんがやってくれないといかんともし難いんです。IAMユーザーで、このユーザーが何ができるかってAWSのAPIに対しては絞り込んでると思うんですけど、でもKubernetesに入った途端「全エンジニア全部管理権限です」みたいなことは許されないわけです。でも連携してくれれば、そんなに苦労せずにそういう権限管理もできます。自分たちでツールを作らなくても。
VPCとの統合もそうです。Kubernetesはクラスタ内DNSがあるというお話をしたのですが、あれはKubernetesの中に仮想ネットワークがもう1個ある。基本的に、VPCの中にKubernetesの仮想ネットワークを作る前提なんです。
この状態だと二重管理になるんですよね。VPCがあるのにKubernetesのネットワークは自分たちで管理するのかとか。そこはもちろんアウトソースしたいですよね、という第一歩がVPCとの統合なんです。だからこれは、本当にEKSいい仕事をしています。本当にAWSさんに感謝です。
こういう状態なので、EKSの使いどころはこの1点に尽きます。Kubernetes on AWSやるんだったら、すべてEKSを使ってください。大丈夫です。
コンテナとKubernetesの未来
あとはもう消化試合です。コンテナとKubernetesの未来の話をします。「FaaS使えるところはFaaS使っとけ」という話をした口でこんなことを言うのもあれなんですが。
これからコンテナとKubernetesという規格が定まってくると思います。それでどうなるかというと、クラスタ自体の運用がもっと簡単になってくると思います。
ちょうどCNCFでKubernetesがホストされて、AzureとかGCPとかAWSでそういうマネードサービスが出てきたように、もっともっと運用が簡単になってくると思います。FargateのEKS対応も予定されていると聞いてます。なのでもっと簡単になってきます。
次に起きるのはKubernetes上でアプリを運用するとき、まだまだツールが少ないですね。Capistranoみたいな。VM時代、みんなCapistranoを使っていたと思うんです。
そういうレベルのアプリの運用を簡単にしてくれるツールというのは、Kubernetesに完全なのはまだないんですよね。そういうものが出てきて、アプリの運用がもっと簡単になっていくと思います。
それで何が起きるかというと、たぶんスタートアップみたいに開発リソースが限られているうちのような会社であったとしても、どんどんKubernetesを使っています。
そのときにどういう状態になっているかと言うと、たぶんツールが進化しすぎていて、Kubernetesを使っているという感覚はなくて、サーバーレス的なものを使ってるいると。サーバーのことは意識してないからサーバーレスなんですけど、その中で実はKubernetesが基盤になっていて、Kubernetesを必要に応じて触れるという状態になっていくと思います。ずっと先の話ですけどね。
今って「Linexだからできない」とか、「Windowsだからできない」ことってあまりないですよね。Linuxを創業期に採用して、そこからWindowsに移行することはそうそうないと思うんですけど、Kubernetesもそういう状態になっていくと思います。
まとめに入ります。Right abstraction,right tool.という話だったんですけど、最後ちょっとエモい話になってしまいましたが、こういうことを言いました。
抽象レベルの違いを意識できるようになってほしいです。
コンテナとVMとFunctionがありましたね。VMはいいとして、コンテナはVMで動いてECSとかKubernetesとかで運用しますと。ツールはちょっと揃ってきましたよ。まだ完全じゃないです。
Functionはコンテナ以下で動きます。運用ツールの成熟化はこれからだと思っています。でも使えるところにはどんどん使ったほうがいいと思ってます。
今後正しいツールを選べるように、ということなんですけど、説明したとおり、Kubernetesは銀の弾丸ではありませんでした。なのでやっぱり、Kubernetesにもメリットデメリットがあって、運用が大変なんですね。
VMだったらChefとかPupptとかAnsibleとかで運用してました。コンテナの時代になってもまだそこから解放されないです。そういうものの上に、Kubernetesクラスタをどうマネージするかというクラスタマネジメントの問題がプラスされます。すんごく辛いです。なので、それをペイする状態で採用してください。今だったら。
Functionですね。これはサーバーレスとか LambdaとかFaaSとかで動かせる。それで運用が大丈夫と思うところだったらどんどん使いましょう。Kubernetesが進化するとサーバーレスとかFaaSとかもっと身近になってくると思います。
なので、今使えるところはうちみたいにKubernetesを使ってもいいです。将来的にFaaSの裏側はKubernetesになっていくと思うので、学習目的で今から使うのはありだと思います。でもビジネス利用は計画的にお願いします。
以上です。freeeではDockerとKubernetesをやりたい人を募集してます。よろしくお願いします。ありがとうございました。
（会場拍手）