昨今のエンジニアのインフラ技術を料理で無理矢理例えてみた。

# はじめに
この記事の想定対象者は

- 自分はエンジニア(開発者)ではありません
- でも、エンジニアと関わります。(企画とかマネジメントとか)
- そのため、最低限エンジニアのインフラ知識ないとエンジニアの皆様に『そんなことも知らねーのかよ勉強して出直せ』と怒られます
- でも、少しググったけど何もわからないんです

という人々です

人類どんな人がいようと食べない人はいないだろうということで、無理矢理料理で例える努力をしてみました。

ので、日頃サーバー触っているエンジニアの方々はあまり対象ではありません
もしかしたらプログラミングはできるけどインフラ周り何もわからないっていう人の助けにはなるかもしれません。
ならないかもしれません。

# 具体的な技術について
- クラウド(いわゆるパブリッククラウド。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**とはなんじゃ...」と思っている節があり、そういう人たちが少しでもイメージしやすくなるといいなと思って書きました


割と勢いで書きました。正直お酒飲んでます
ので、あんまり批判が多かったら冷静になった僕が消すかもしれません

兎にも角にも、ここまで読んでくださりありがとうございました。