2024.10.01
自社の社内情報を未来の“ゴミ”にしないための備え 「情報量が多すぎる」時代がもたらす課題とは?
リンクをコピー
記事をブックマーク
AWSにおけるコンテナオーケストレーション、代表的なものが2つあります。Amazon ECSとKubernetes。まあ、ほかにもいろいろあるんですけどね。今日は2つを機能で比べてみましょう。ECSはこんな機能があります。
最近だいぶ機能が増えました。もともとはコンテナのデプロイだけだったんですが、だいぶ初期にIAMロール対応をして、同じEC2インスタンスに相乗りしているコンテナがそれぞれ違うIAMロールを使えるので、セキュリティが高まります。あとはヘルスチェックですね。EC2インスタンスが落ちたら自動復旧する機能がありますが、コンテナにもそういう機能が付きました。
そして、サービスディスカバリです。EC2インスタンス1個だけ並べてもロードバランスするときにどうやってお客さんから複数台のサーバが透過的に使えるようになるかと言うと、サービスディスカバリとロードバランスなんですが。コンテナを同じようにサービスディスカバリできるようになりました。
なのでRoute 53にDNS名があって、その先に複数コンテナがいますみたいなことをECSがサポートしてくれたんですね。とにかくこんな機能があります。だいぶ便利そうですよね。
Kubernetesの機能って一見すると同じなんですよね。コンテナのデプロイできます。サービスディスカバリもあります。ヘルスチェックもあります。ってなってくると、あと何で比較しよう? ってなります。
先ほどは機能の話でしたが、運用面どうなんでしょう? そういう観点でECSのメリットを見てみると、こんなメリットがあります。
ECSだったらAWS公式の専用のAMI、マシンイメージがあります。例えばDockerECSが使うAgentの相性問題は自分でデバックしなくていいんですね。もっとビジネスに集中できますよね。
あとマネージドサービスがあって、これあまり意識することはないかもしれませんが、KubernetesだったらKubernetesのシステム用のサーバが別にあって。それはみなさんのアプリケーションが動くものとは別のサーバが必要で。それを自分たちでメンテしなければいけません。それを仕事にしているわけでもないのに、そんな余分なものメンテしている時間ない。でもECSはそれを見てくれてます。
あとはSegment社という海外の大きな会社さんがあって、そこがECSで大規模なクラスタを運用している事例とか、そのために使っているOSSをすごく積極的に公開してくれています。そういうところに乗っかっていくと我々としても楽ですよね。
あとは日本でも採用事例が多いです。採用事例が多いということは情報が多くて教育もしやすいし、なんかハマってバグったときのトラブルシューティングもしやすいですよね。運用目線だとすごくメリットですよね。
スコープが限られているのもいいです。スコープというのは機能が限られています。だいぶ便利機能が増えてきてKubernetesに近づいてきてしまったんですけれども、それでもさっき挙げた4つで説明できるくらいの機能なのでだいぶ取り回ししやすいです。
機能が増えるとどうしてもアップグレードって大変になりますよね。ECSのバージョンが上がったらちょっとビジネスの開発止めて、ECSのバージョンアップに追従しなきゃいけないってやってられないじゃないですか。そういうことはECSに関してはたぶんありません。
これは残念ながら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の使いどころの話をしようと思います。使いどころあるんですよ、ちゃんと。
ツールの違いは運用と適応領域の違いです。例えばこういう図を思い浮かべてください。
コンテナだったら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は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の使いどころだと思ってるのはこういう点ですね。コンテナの運用を確実に助けてくれます。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化していっています。うちはマイクロサービスが徐々に増えてきたので、やっぱり運用上の課題があります。そのために新規サービスを徐々にKubernetes化しています。
既存サービスはまずDocker化から始めています。必ずしもKubernetes化しなくてもいいかなと思ってるんですね。結局目的は運用の効率化なので、別に既存サービスの運用が高度に自動化されているのであれば無理にコンテナ化、Kubernetes化する必要ないんですよね。
うちの場合、新規サービスでそうした高度な運用の自動化をしている暇がないので、先にKubernetesで基盤を作っちゃって同じ基盤でみんな同じように自動化されるような感じにしたかった。楽をしたいからKubernetesを使ってるだけです。
とは言ってもやっぱり学習コストが高いのでオンボーディング勉強会みたいなことをやっていて、Kubernetesを採用するプロジェクトの開始時には必要に応じて僕が勉強会をやるみたいなことをしてます。
あとはできるだけ作り込まないということを徹底しています。Kubernetesを構築して運用するだけでけっこう工数取られるんですよね。だからKubernetesで自社の超かっこいいPaaSとかを作ろうと思わない方がいいかなと僕は思ってます。
なんですが、例えばCapistranoでデプロイ自動化するということをけっこう各社されてて。Capistranoのレシピをちょっと書き換えて自社のデプロイの要件に合わせるようにカスタマイズするじゃないですか。そのレベルのカスタマイズにとどめて、それでもできることは増えるのがKubernetesです。
また、Kubernetesは買われていますが、Kubernetes上で動くPaaSみたいなものはないので、けっこう自動化の余地はあるんですね。自動化しようと思うとみなさんそういうKubernetesで動くアプリケーションを作ることになるんですけど。
freeeみたいなスタートアップだとそれに割ける人って少ないので、基本的にうちではKubernetesのツールを自社だけで作るということはやっていません。既存のOSSのメンテナになったり、メジャーのOSSをそのまま使うとか、そういったかたちでできるだけOSSコミュニティと一体になって自社で開発を持たないようにして自動化を進めてます。
そうしていずれプライベートPaaSみたいなのを自社内に提供できたらいいかなと思ってます。
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が使えていくようにはなっていくと思います。
あと、これだけは言っておきたかったんですけど、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になっていくと思います。なので学習が目的だったら早めにやって損はないかなと思います。でもビジネス利用は計画的にお願いします。というところでこの話を締めさせていただきます。ありがとうございました。
(会場拍手)
2024.10.29
5〜10万円の低単価案件の受注をやめたら労働生産性が劇的に向上 相見積もり案件には提案書を出さないことで見えた“意外な効果”
2024.10.24
パワポ資料の「手戻り」が多すぎる問題の解消法 資料作成のプロが語る、修正の無限ループから抜け出す4つのコツ
2024.10.28
スキル重視の採用を続けた結果、早期離職が増え社員が1人に… 下半期の退職者ゼロを達成した「関係の質」向上の取り組み
2024.10.22
気づかぬうちに評価を下げる「ダメな口癖」3選 デキる人はやっている、上司の指摘に対する上手な返し方
2024.10.24
リスクを取らない人が多い日本は、むしろ稼ぐチャンス? 日本のGDP4位転落の今、個人に必要なマインドとは
2024.10.23
「初任給40万円時代」が、比較的早いうちにやってくる? これから淘汰される会社・生き残る会社の分かれ目
2024.10.23
「どうしてもあなたから買いたい」と言われる営業になるには 『無敗営業』著者が教える、納得感を高める商談の進め方
2024.10.28
“力を抜くこと”がリーダーにとって重要な理由 「人間の達人」タモリさんから学んだ自然体の大切さ
2024.10.29
「テスラの何がすごいのか」がわからない学生たち 起業率2年連続日本一の大学で「Appleのフレームワーク」を教えるわけ
2024.10.30
職場にいる「困った部下」への対処法 上司・部下間で生まれる“常識のズレ”を解消するには