3年くらい前にローンチしたのですが、AWS上へのDockerコンテナのデプロイと管理とスケールが求められていて、それらを実現するようなサービスになっています。ECS自体は非常にたくさんの本番利用が進んでいます。2016年比較で、アクティブユーザーがだいたい450パーセントくらい増えていて、毎月数百万くらいのインスタンス上でコンテナが管理されています。2015年にGAしたのですが、それ以降、お客さまからのフィードバックをもとに50以上の新機能がリリースされています。このECSなのですが、もともとプロダクションでコンテナをAWSの上で大規模運用するお客さまを支援するために機能を開発してきていて、個々には説明しませんが、このような機能群があります。いくつかECSの概念的なものがあるので、簡単にご紹介したいと思います。1つ目は、Taskです。Definitionというファイルを使って定義することができます。Taskないのコンテナ群はこの情報から実行されるかたちになります。CPUとメモリの上限を指定するものです。2つ目は、Serviceです。Taskの数を希望数に保ったり、ELBと連携することもできます。ECSはAWSのサービスなので、当然ながらIAMとの統合も行われています。SDKを使って自動的に認証情報が得られるようになっています。AWSのVPCのネットワークモードです。こちらを使うと、TaskごとにENIを割り当てることができます。何ができるかというと、セキュリティグループをTaskごとに設定可能になるというものです。ECSの特徴があります。Eventsというサービスと連携して各種イベントが流れるようになっています。顧客はアプリケーション開発に集中したい3年前にローンチしたということもあって、数多くの事例があります。国内外で企業規模の大小や業種を問わず、いろいろなお客さまに使っていただいています。先ほども、この3年間でいろんなフィードバックをもとに50以上の機能を開発してリリースしてきたという話をしました。いろいろなフィードバックが寄せられているのですが、その中でもっとも多かったフィードバックというのは、コンテナまたはアプリケーションのことだけを考えたいということです。ECSは、コンテナを動かすデータプレーンという部分のEC2の管理が必要になるのですが、そのインスタンスの管理はしたくないというフィードバックが非常に多かったです。Fargateというサービスになります。これはインスタンスの管理の必要なくコンテナを実行できる新しいテクノロジーになっています。あとはタスクネイティブAPIによってクラスタそのものの心配が不要になります。利用効率だったりオートスケーリングといったものも考える必要はありません。あとリソースベースの価格モデルによって、Taskに割り当てられたリソースにだけお金を払えばいいという話なのですが、わかりづらいと思うのでこのあと説明します。繰り返しになるのですが、コンテナを動かすEC2インスタンスのデータプレーンと呼ばれる部分の中に、ECSのTaskが動いています。Fargateは、ECSの既存のコントロールプレーンをそのまま使える状態でフルマネージドなデータプレーンが使えます。EC2のインスタンスの管理をする必要がないので、そのあたりを気にせずに、これまで以上にその上で動かすコンテナにフォーカスできるということが最大のメリットかなと思います。ECSと一緒に使うように設計されているので、他のAWSサービスとの深い連携や強力なスケジューラ、オートスケーリング、ロードバランといったような、過去3年間に開発してきた機能群がすべて利用できるようになっています。Definitionの中で定義することで、それをもとにした実行時間が秒単位で課金するようなモデルになっています。CPUとメモリの設定が選択肢として50個くらい用意されているので、その中から好みのものを使うというかたちになるわけです。Fargateを選択するだけでよかったりします。ECSクラスタの、今のEC2上でコンテナを実行したい場合は、これまでどおりEC2を選択するとEC2上で動かすこともできます。ECSの概念はそのまま使えます。同じクラスタでEC2と混在することも可能になっています。Repositoryがサポートされています。FargateモードとEC2モードの話をしましたが、ここの使い分けは基本的にFargateで大丈夫かなと思いますが、Fargateでは難しいものがいくつかあるのも事実です。ContainersなどはEC2モードで動かしてもらうのがいいかなと思います。Lambdaの使い分け料金モデルのところではCPUとメモリの設定と、Taskが動いている実行時間に対して秒単位で課金するというところで、Lambdaというサービスをご存知の方は、Lambdaとの違いも少し気になるかなと思います。ここの使い分けはわりとシンプルです。Lambdaはいわゆるイベントドリブンなプラットフォームになっていたり、ランタイム管理も不要になっているので、イベントドリブンなアプリケーションを作りたいという場合はLambdaを使えばいいかなと思います。逆に言うと、それ以外はFargateを使ってもらうのがいいかなと思います。Fargateの場合、そのような制限はとくにないので、ロングランニングなローンチなどにも向いているかなと思います。L7でロードバランシングしたり、ネットワーク関連のオプションをコントロールしたり、そのような柔軟性がより必要になる場合は、Fargateを使ってもらうということで、どちらかを選ぶというか、特性に合わせて使い分けてもらう、組み合わせてもらうのがいいかと思います。先日、EC2やEBSのSLAがこれまでの稼働実績をもとに99.99パーセントに引き上げられたのですが、同時にこのECSとFargateの中に含まれていたりします。最後、コンテナというところで当然Kubernetesに触れないわけにはいかないので、この話を少しして私のパートを終わりたいと思います。ご存知ない方はあまりいらっしゃらないかなと思うのですが、Kubernetesはオープンソースのコンテナ管理のプラットフォームです。ここ12ヶ月くらいで非常に人気が出ているかなと思います。AWSのカスタマーでKubernetesをご利用になっている方も多いです。コンテナの大規模な運用に有用だったり、という部分があります。surveyという団体のアンケートによると、実はのKubernetesのユーザーの63パーセントは、今日時点でAWSを利用しています。EKSというサービスの提供も最近始めています。いうわけで、私のパートは以上になります。EKSの話は九岡さんにお話をしていただこうと思います。AWSの話をいたします。freeeでSREとして働いていまして、副業でChatWorkの技術顧問もやっています。あとはmumoshuという名前でGitHub/Twitterをやっています。コンテナを取り巻く環境の話をしていきたいと思います。僕の頭の中で、コンテナを取り巻く環境をいろいろと書いてみようと思って、スライド1枚くらいにまとまればいいなと思ったんですけど......やってみるとこうなっちゃうんですよね。どこから話していいのかわからないので、今日持ち帰っていただきたいなと思っているのはこれだけです。いうことで、抽象レベルの違いをちゃんと意識できるようになってほしいです。何の抽象レベルのことかというと、VMとコンテナとファンクションの話です。あとは、今後正しいツールを選べるようにということで、最初に言っておきたいのですが、Kubernetesは銀の弾丸「ではない」ので、Kubernetesをどう使いわけていくかという話をしていきます。そのときにまたコンテナとVMとファンクションの話をします。このイベントのテーマは「実践知」なので、これは今日話さないことにしました。Kubernetesの歴史や特定ツールの使い方など、ググればわかるようなことは話しません。アジェンダに戻ります。AWSのことはみなさんよくご存知だと思うので、あまり触れません。そのような文脈でいうと、Kubernetesの概要はよく知られていると思います。GoogleのBorgというシステムが起源になっていまして、けっこう大昔からありました。コンテナオーケストレーションシステムというもので、ひと言でいうと、Dockerコンテナをいい感じにデプロイしてくれるやつです。Kubernetes自体は2014年にOSSとして公開されまして、プロジェクト自体は今年で5年目に入りました。その2年後の2016年にバージョン1.0、プロダクションレディになりました。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だったら関数をデプロイします。deployとかしていたわけです。Javaだったらwarをまいたりしていたわけです。Dockerでもコンテナイメージをまきますけど、FaaSだったら関数をまくわけですね。「これまで悩んでいたことがけっこう解決するのではないか?」「FaaS最強では?」ということで、実際にそうだと思います。ここでよく知られていないことが1つあります。「なぜ今さら、Functionではなくコンテナなのか?」。それはこの話に戻ってくるんですけど、仮想マシンを管理しなきゃいけないんです。仮想マシンをどうやって管理していたかというと、ChefやPuppet、Ansible、CloudFormationなどで管理していました。コンテナはどうするかというと、DockerやECS、Kubernetesなどで管理しています。FaaS、OpenWhiskなどいろいろあります。僕はこれがすごくネックになっていて、仮想マシン、コンテナ、関数......全部いいんです。関数が使えれば全部関数にしたいんですけれども、ツールが揃ってないと運用が大変です。会社によっていろいろ違うんですね。サーバーレスでうまく運用回せるところはたぶんそういう案件規模で収まってるか、ツールがうまいこと自分たちにフィットしなくて自分たちで作らなくて済んでいるかだと思います。「コンテナとか関数のマネジメントってどうしたらいいの?」という問題に即答できない人は、まだコンテナとか関数とかは使えないです。使えるところはいいです。今、コンテナなのかまとめると、なぜ今コンテナなのかというと、比較論でいうと、「ツールが揃ってなくて運用が大変だから」。このひと言に尽きます。コンテナの話をしているときに、なぜコンテナオーケストレーションが出てくるかというと、けっこうわかりきっている課題があります。コンテナをデプロイするのにsshでは済まないんですね。dockerとかしないわけです。しないかというと、コンテナはその性質上、VMより落ちやすいです。不安定という意味じはなくて、そのような運用になりがちということです。コンテナが落ちたときにほかのノードへ自動移行してほしいとか、そのような固有の事情がありますよね。あとコンテナのロードバランサに自動でつなぎたいよね、EC2インスタンスみたいにとか。サーバの余剰リソースでコンテナを動かしてほしい。コンテナはネームスペースで隔離されていて、そういうことができるはずですよねとか。いうことをやろうとすると途端にsshでは済まなくなります。コンテナオーケストレーションが必要です。Kubernetesを使うべきではないのか?やっとKubernetesに戻ってきた感があるのですが、まだネガティヴな話をします。ECSとKubernetesの2つを比較します。ECSはひと言でいうと、コンテナデプロイのサービスだと思っています。Kubernetesもそういう意味では、コンテナデプロイのシステムでしかないんですね。そのような状態で、運用者目線でのECSのメリットを見ます。ECSがすごくいいのは、AWS公式の専用のAMIがあるんです。そのAMIで何が動くかというと、DockerのデーモンとECSのAgentと、まあいろいろ動くんですけれども。Agentの相性問題のバグみたいなものを踏みたくないわけです。どこかでマネージしてくれるものを使いたいですよね。それはAWSさんがマネージしてくれます。ECSのコントロールプレーン、マネージしてくれますよね。そのようなマネージサービスがあるというのは、運用負荷を軽減するにはすごく重要です。あとECSだとSegment社というところの事例がすごく大きくて、あそこはECSの周辺ツールをすごくOSSで公開していて、なかなかの規模でサービスを運用されています。いうものがあると、だいたいのケースで「うちの会社でも、あそこの会社のような規模だったらECSでいけるか」と確信を持って採用できます。日本での採用事例も多いですし、あとスコープが限られているということは僕はソフトエンジニアとしてはすごく重要だなと思っています。あまりにも便利機能を増やしすぎると、ECSだけ覚えればいいということにもなりますけど、そうするとECSの敷居も上がりますし、バージョンアップ辛い問題が発生するんですね。Railsなんでもできますけど、Railsのアップデートはそこそこ辛い。Rails専用、アプリ専任の人とか欲しくなってしまうくらい辛かったりするので。それがECSみたいなインフラのレベルで起こるとすごく辛いです。今度は運用者目線でのKubernetesの話をすると、正直に言って、Kubernetesのデメリットにつながってしまいます。AWS公式の専用のAMI......ないです、そんなもの。マネージドサービス、そんなものは最近までありませんでした。AWSといえばこの会社という事例は、少なくとも日本にはないです。海外に行くと、「Hotels.com」とか「Zalando」というヨーロッパのファッションサイトなど、いろいろ大きいところがあります。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前提にすることで、実装はとてもシンプルになっています。Functionとコンテナをまとめて1本APIゲートウェイにぶら下げるみたいなものがあります。このAPIゲートウェイ以降は実装がLambdaかもしれないし、コンテナかもしれないですよみたいな状態が作れます。これは拡張性の証拠だと思います。ここまで話したことを踏まえて、Kubernetesnの使いどころを考えました。コンテナの運用を助けてくれるので、どうしてもコンテナの運用を効率的にしたい場合には使えます。LambdaやECSより汎用的です。コンテナをデプロイするシステムというよりかは、本当に分散システムのフレームワークという感じなんです。FaaSやサーバーレスとかの基盤と考えてもいいと思います。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点に尽きます。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もそういう状態になっていくと思います。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をやりたい人を募集してます。ありがとうございました。Tokyoに関する記事をまとめています。Tokyoに関する新着記事が公開された際に、通知を受け取ることができます。