はじめに
この記事の想定対象者は
- 自分はエンジニア(開発者)ではありません
- でも、エンジニアと関わります。(企画とかマネジメントとか)
- そのため、最低限エンジニアのインフラ知識ないとエンジニアの皆様に『そんなことも知らねーのかよ勉強して出直せ』と怒られます
- でも、少しググったけど何もわからないんです
という人々です
人類どんな人がいようと食べない人はいないだろうということで、無理矢理料理で例える努力をしてみました。
ので、日頃サーバー触っているエンジニアの方々はあまり対象ではありません
もしかしたらプログラミングはできるけどインフラ周り何もわからないっていう人の助けにはなるかもしれません。
ならないかもしれません。
具体的な技術について
- クラウド(いわゆるパブリッククラウド。AWS/Azure/GCP...)
- コンテナ(Docker)
- Kubernetes
についてかるーく触れます
雰囲気が伝わることをめざしています。ので超厳密にいうと少し違うかもしれません。
ご了承ください
嘘は書いてないつもりです。ここ違うよ！ってところがあればコメントいただけますと幸いです。
本題
では、本題です。
1. 従来
あなたは料理人です(エンジニア)
料理をします(コーディング/プログラミング)
ただそれだけだとお客様に提供がきません(デプロイできません)
まず、**テーブル(物理サーバ)**を用意して、**お皿(ライブラリ等)を用意して、そこに料理(コード)**を盛り付けて初めて提供できます(デプロイ)
なので、毎回テーブルとお皿を用意しなければいけません.。
特にテーブルを毎回用意するのは面倒です。重いし高いし。
2. クラウド
そこで生まれたのがクラウドです
クラウドとは、テーブル(物理サーバ)を1000台以上並べた上に、でっかい真っ白なテーブルクロスを引いたものです
なので中身はテーブルの集合ですが、上から見たら真っ白な巨大なテーブルでしかありません
その巨大テーブルに仕切りを作って、1つ1つの空間に切り分けます。以後この1つの空間をテーブル(仮)とします。(仮想サーバ/EC2インスタンス)。ちょっとイメージしにくいかもしれませんが、テーブル(仮)は普通のテーブルだと思ってください。
それを料理人に提供します。「いくつテーブル(仮)が必要ですか」「ここはあなたのテーブル(仮)です」「好きに使ってください」「レンタル料は1テーブル(仮)あたり1ヶ月いくらです」って貸し出すのがクラウド事業者(AWS/Azure/GCP…)です
ただ、結局そのテーブル(仮)上にお皿（ライブラリ等)は用意しなければいけません。複数のテーブル(仮)に提供したい場合は、それごとにお皿を買ってきて置いて、その上でそれぞれ料理を並べることになります。綺麗な盛り付けも必要です。面倒です。
3. コンテナ
そこで生まれたのがコンテナです
コンテナとは、出前用の箱だと思ってください。岡持ちです。その箱の中にお皿と料理を詰めます。綺麗な盛り付けもここで終わらせます。
ので、一度岡持ちを作ってしまえば、それをテーブルの上に置くだけで済みます。
(コンテナ自体は物理サーバでも仮想サーバでも動きます。なぜこの順番で説明しているかは一番下の番外編をご覧ください)
そして、ここからが現実と違うところですが、この岡持ちは全く同じものが複製できます。
ここいい例え思いつきませんでした。この岡持ちに入ったら超科学で3dプリンターが使えるとか思ってください。
ので、複数のテーブルに提供したい場合も、その複製した岡持ちごとおけば全て解決します。毎回**お皿（ライブラリ等)**を買って来る必要はありません。
このコンテナという技術のうち一番有名なものがDockerと呼ばれますコンテナです。
しかし、ここでも問題があります。それは、テーブルが壊れれば(割れるとか足が折れるとか)、その上においてある岡持ち(コンテナ)は当然一緒に落ちる、ということです
例えば、そこがバイキング/ビュッフェとかだったら一大事。
常に料理をお客様に提供しなければならないのに、壊れてしまったら、別のテーブルの上にまた岡持ち(コンテナ)を置くまで料理の提供ができなくなります。
(そんな簡単に壊れねーだろと思うかもしれませんが、壊れた時が本当に一大事なので絶対に避けたいのがインフラエンジニアの方々だったりします)
4. Kubernetes
そこで生まれたのがKubernetesです。(略してk8s)
Kubernetesは、なんか、ウエイターです。スーパーウエイターです。
ウエイターは自分の店内にある全てのテーブル(物理/仮想サーバー)を常に見ています。
そして、料理人(エンジニア)はウエイターに置きたい料理が入った岡持ち(コンテナ)を渡します。
例えば「この野菜炒めの岡持ちを置いて欲しい」とかです。
ウエイターは「かしこまりました」と言い、1つのテーブルの上に野菜炒めの岡持ちを置きます。
そこで、そのテーブルが壊れたとしましょう。当然野菜炒めは落ちます。食べられません。
従来なら、料理人が時間差で気づき、慌てて他の空きのあるテーブルの上に新しい「野菜炒めの岡持ち」を置いてお客様に提供するところです。
(この壊れてから新しいテーブルの上に岡持ちを置くまで=お客様に料理を提供できていない時間がダウンタイムです。いわゆるシステム障害と呼ばれWebサービス等に接続できない状態のことを指します。エンジニアからすると恐怖ですね。絶対に嫌です。)
しかしスーパーウエイター(kubernetes)はそんな手を煩わせません。ウエイターが即座に気づき、自動的に空きのあるテーブルを探し、そこに新しい「野菜炒めの岡持ち」を置きます。そのため、そのままお客様に提供し続けることが可能になります。
そうすることで、料理人は料理に集中できるのです。
番外編: オートスケール
ちなみに、たまに聞くかもしれない「オートスケール」とは、2で出てきたテーブル(仮)が,あらかじめ用意していた分では足らなくなった時、勝手に新しいテーブル(仮)を用意してくれる仕組みのことです。
これがクラウドという超巨大テーブルの最大の強みの1つだったりします。
ので、例えば4のウエイター(kubernetes)がとあるテーブル(仮想サーバ)が壊れていることに気づき、「野菜炒めの岡持ち(コンテナ)」を別のテーブルに置きたいけど空きのあるテーブルがない！やばい！どうしよう！ってなった時。
オートスケール機能をつけておけば、なんとびっくり。新しいテーブル(仮)が自動的に使えるようになります。
ので、晴れてウエイターは新しい**テーブル(仮)**に「野菜炒めの岡持ち」を置くことができるのです。
そのため、kubernetesとクラウドを同時に使われることが多い(と勝手に思ってる)のです
終わりに
いかがだったでしょうか。
この記事は、弊社で最近 Kubernetes! Kubernetes! と叫ばれることが多く、開発者ではない大先輩の方々が「Kubernetesとはなんじゃ...」と思っている節があり、そういう人たちが少しでもイメージしやすくなるといいなと思って書きました
割と勢いで書きました。正直お酒飲んでます
ので、あんまり批判が多かったら冷静になった僕が消すかもしれません
兎にも角にも、ここまで読んでくださりありがとうございました。