仮想とか分散の何がうれしいの？

こんにちは。筆者です。

仮想マシンとか分散コンピューティングとかそういう「とにかく分ける！」みたいな概念って、現代ではかなり当たり前の考え方なんですが、

これから勉強する＝そのために必要な諸々の設定が壁になる人にとっては、めんどくさいわりに何がうれしいのかがパッとわかりにくい所ですよね。

この記事はそこを簡単に説明して、Kubernetesみたいなことを本格的に勉強しようとしている人のモチベーションになればいいなっていう記事です。

まずは普通に処理することを考える

基本的にWebアプリのような、サーバ上で動いていてネット経由で不特定多数がアクセスするようなアプリで有用な技術なので、そういうのを作りたいときに必要だと思ってください。

そういうアプリの最小の構成を考えると、オンラインでアクセスできるようにIPがわかってて、ポートが解放されているサーバPCが1台あって、その上で通信、処理、データベースの3種類の役割を担うプログラムが動いている状態になります。

問題点１　サーバ上の実行環境がごちゃつく

サーバPC上では基本的に複数の実行環境が動き、その上でプログラムが動く感じになります。

例えば処理をするプログラムをJavascriptで書くならNodejsをサーバPC上に入れておく必要があるって話です。

あまり表層化しませんが、通信、データベースでも基本的には同じだと考えて下さい。

この時点で、1つのPCに実行環境が3つ共存していますが、もっと増える構成だって当然ありますし、それだけ1つのPC上に大量の実行環境がごちゃっと入ってきます。

さて、満を持してサーバ機がぶっ壊れた、あるいはPCスペックを上げたりする目的等で、別のPCに乗り換えることを考えます。

実行環境のバージョン覚えてますか？入手先、設定方法、全部完璧に再現できますか？

これが再現できなければ、その上で動くプログラムが意図した通り動かなくても文句は言えないわけですが、漏れるなんてのはあるあるですし、忘れてるし確認もできないような状態になったら正しく詰みです。

問題点２　実行環境が競合する

競合ってのはあんまりあるようでないですが、例えば処理をするプログラムをNodejs上のJavascriptで書いていた例で、あるライブラリはNode16まで、あるライブラリはNode18以上でしか動かないみたいな事が起こったらどうしましょうか。

基本詰みです。何とか回避するすべもありますが、実行環境がさらにごちゃつくこと請け合いです。

問題点３　PCスペックが足りない

あなたがしれっと営業の才能があり、ユーザ数が爆発的に増えたので、処理数に対してPCスペックが足りなくなり、レスポンスが劇的に遅くなりました。

しかし、必要なPCスペックをざっと計算してみたら、企業向けも含めた現行の最強スペックのPCパーツをそろえても、快適な処理スピードを維持するにはスペックが足りません。

要するに、PC1台で捌くには現代の人類が持ち合わせているPCスペックでは不足という事で、1台で捌くのは詰みました。

問題点４　落とせない

お手元のPCを想像するとわかると思いますが、ちょこちょこ再起を迫られませんか？

サーバが再起するってことは、プログラムが止まるってことで、＝サービスが落ちるってことになります。

これは、Webサービスの概念の中では可用性という重要な要素を損なう事態なので、プロダクション環境ではマジで許されない事案です。

Gmailとか、落ちてるの見たことないと思いますが、あれがちょこちょこ止まるとかって話になると途端にごみですよね。って話です。

華麗な解決策「仮想」と「分散」

先ほどの問題点のうち、１と２は仮想化、３と４は分散が解決してくれます。

仮想化による華麗な解決

１，２の問題点は、要するに実行環境を１つのPCにいっぱい入れるのは嫌という話なので、これをPCごと分けちゃおうというのが仮想化です。

こうして分けたPCはイメージという形で1つのファイルにまとまるので、PCを新しくしたらそこの上でイメージを実行するだけ移行終了となり、1の問題が解決します。

当然実行環境ごとにPC分けてるので、１PC1環境になり2の問題も解決します。

仮想化の一番わかりやすい例は、仮想の「マシン」を作って、そこにOSを入れるところから始める形式で、これをVMって言います。

ただ、実行環境ってのはOSの上で動くソフトのようなものなので、OSは別に入れ直さなくていいんだよな～、容量もデカくなるし、重くなるしな～っていう問題もあります。

そこで、OSはPCに入ってる奴そのまま使うけど、実行環境とかそこ以降の部分だけ仮想化するよ！という非常に都合の良い便利な仮想化技術がDockerやKubernetisのようなコンテナをベースにした仮想化技術です。

近現代の仮想化はこのコンテナによる仮想化が主です。

分散による華麗な解決

PCスペックが足りない問題と落とせない問題は、単にPCが1台だからよくないんだ！増やせばいいやん！という安直な発想が解決します。

まず3の問題、PC1台で捌くには現代の人類が持ち合わせているPCスペックでは不足という事案についてですが、

立ち返って、Webアプリでは通信、処理、データベースの3つが必要って話をしましたが、それぞれ実行するPCを分けてみてはどうでしょうか？

個々のPCを見るとおそらく通信とデータベースは軽いので大抵足ります。でも処理が足りない！

なら処理を実行するPCをたくさん作って、各個が快適な速度で帰ってくる程度の処理数になるように適度に振り分けるようにしてみます。これがいわゆる負荷分散（LB）ってやつです。

これと同じ理屈でPC増やしさえすれば、1台では解消できなかった問題が解決します。

こうやってPCを増やしたら、処理するPCのうち1台がぶっ壊れても、他のPCに流せばサービスは止めないで済みそうじゃないですか？

これで全部同時にぶっ壊れない限りはサービス全体が停止する事は避けられます。

Kubernetesはどっちもやる想定の時に便利な子

冒頭にちらっと述べたKubernetes君は、仮想と分散を両方やる前提の時に生じる面倒事を勝手にやってくれる素晴らしい子です。

たとえばPCが10台繋がったクラスタ上で、あるコンテナを5個動かしたい時、

手動だったら、1個落ちたら、どのPCが空いてるか探して、どれにコンテナ立てるか考えて、負荷分散の接続先をいじくって、どのPCで落ちたのか探しに行って、再起動かけてみて、戻ったらまた負荷分散弄ってみたいなクソめんどくさい事を24時間体制で見張ってまでする羽目になります。

しかしながらKubernetesはこの辺を全部、最初に設定した通りにいい感じにやってくれます。

他にも、アップデートを順繰りにいい感じにやってくれたり等々、とにかくクラスタ構成で複数コンテナ動かす場合の面倒事をなにからなにまでいい感じに解決してくれるわけです。

ここまでで何となくわかったと思いますが、ここまでやって出来上がるアプリは、すげー人数でアクセスしても快適で、まじで滅多に落ちないガチガチのプロダクション環境です。

個人開発の利用者数十人ですぐつぶれるようなサービスに必要なものでは断じてないですが、技術的にはクッソ楽しいので、漢の浪漫を求める方はぜひ自宅のPCを寄せ集めてクラスタ組んでみましょう。

では、また。