サーバー・サーバーレス・コンテナの違い — アプリケーションサーバー層

この記事は、アプリケーションサーバー層を動かす 3 つの形を扱います。

1 台のサーバーを起動したままにする常時稼働、要求が届いたときだけ動かすサーバーレス、そしてコンテナです。

違いは、処理のプログラムが動いている時間です。

動いている時間が違うので、要求が増えたときの増やし方も、自分で用意するものも変わります。

常時稼働のサーバーは、起動したまま要求を待ち続ける

リクエストはいつ届くか分からないので、server.js を先に動かし、プロセス（process。起動して動いている状態のプログラム 1 つ分）として待たせておきます。

このプロセスを終了させずに置いておく形が常時稼働（always-on。プログラムを起動したままにして、要求をいつでも受け付けられる状態を保つこと）です。

Server listening on port 3000
Press Ctrl+C to stop

1 行目は、決めたポート番号で要求を待ち受けている状態を示します。

2 行目のとおり、止める操作をするまでプロセスは終わりません。

自分で用意するのは、いちばん内側の server.js だけではありません。

動かし続けるコンピュータも、その上の OS も node も自分で用意します。

ここが、次に見るサーバーレスとの大きな違いです。

囲みの中が、自分で用意して動かし続ける 1 台です。

プロセスは要求が来ていない時間も終了せず、ポートを開けたまま待っています。

常時稼働は、止めるまで動いたまま

常時稼働のサーバーとは、先に動かしておいて、要求が来るのをずっと待たせておく形です。

動かし始めるのが node server.js で、止める操作をするまでプロセスは終わらず、動かし続けるコンピュータも OS も node も自分で用意します。

サーバーレスは、要求が届いたときだけ処理を動かす

サーバーレス（serverless。要求が届いたときだけ処理のプログラムが動き、処理が終わると止まる形）では、待ち受けるプロセスを自分では動かしません。

登録するのは handler.js のような 1 つのファイルで、登録の単位を「関数」と呼びます。

自分が触るのは、いちばん内側の handler.js だけです。

その外側の枠は事業者が用意し、OS や node の更新も事業者が行います。

誰がどこまで用意するかは「オンプレ・レンタルサーバー・クラウド」の記事で扱います。

要求が届いていない間、handler.js は動いていません。

実行環境は要求のたびに用意され、返し終わると止まります。

ここが、止めるまで動いたままの常時稼働との違いです。

サーバーレスは、呼ばれたときだけ動く

サーバーレスとは、要求が届いてから処理を動かし、返し終わったら止める形です。

自分が置くのは handler.js だけで、それを動かす実行環境は要求のたびに事業者が用意します。

同時の要求が増えたときの、増やし方が違う

同時に届くリクエストの数は、時間帯によって変わります。

これに合わせて行うのがスケーリング（scaling。要求の量に合わせて、処理する側の数を増やしたり減らしたりすること）です。

サーバーレスに 3 件が同時に届いた形から見ます。

事業者が決めた同時に動かせる数までは、待たされる要求はありません。

増やす操作も自分ではしません。

常時稼働のサーバーでも同じ役割は要りますが、行う相手が変わります。

変わるのは、増やす判断を自分でするか、事業者の仕組みに任せるかです。

増えたあとは同じ人の要求が毎回同じ相手に届くとは限らないので、ステートレス（stateless。1 回の処理が、前の処理で覚えた値を持たないこと）が求められます。

1 回目で覚えた値を 2 回目で読めるかは、その値をどこに置いたかで変わります。

次の要求でも使う値は、データベース層に保存して読み出します。

常時稼働のサーバーでも同じで、プロセスを増やすと別のプロセスには残りません。

増やし方と、値の置き場所

同時の要求が増えたとき、常時稼働では自分で数を増やし、サーバーレスでは事業者の仕組みが増やします。

増えたあとは同じ人の 2 回の要求に同じ相手が答えるとは限らないので、次も使いたい値はその場のメモリではなく、データベース層に保存します。

コンテナは 1 つの OS の上で動き、常時稼働が要るかで 3 つから選ぶ

3 つ目のコンテナ（container。アプリと実行環境と必要なファイルを 1 つにまとめ、同じ構成のまま別のコンピュータで動かす形式）は、動いている時間は常時稼働のサーバーと同じです。

違うのは、実行環境をコンピュータに入れるのではなく、アプリと一緒に包んでしまうところです。

OS は 1 つで、コンテナはその上でそれぞれ 1 つのプロセスとして動きます。

実行環境はコンテナの中に別々に入っているので、隣が何を使っていても影響を受けません。

CPU やメモリのような、動かすために使う機器の分がリソース（resource）です。

上は OS を 3 つ動かしますが、下は 1 つの OS を分け合うので、同じ機器により多くのアプリを載せられます。

同じ台数でより多く動かせて、動かし続ける費用も少なく済みます。

OS を新しく起動しないので、動かし始めるまでの時間も短くなります。

1 台の OS に入れられる node は 1 つですが、コンテナなら別々の node を持ったまま並べられます。

アプリごとに実行環境が分かれているので、片方のバージョンを上げても、もう片方は動いたままです。

まとめたファイル一式がコンテナイメージ（container image。アプリ・実行環境・必要なファイルを 1 つにまとめたもの）で、それを作って動かす代表的なソフトウェアが Docker です。

動かす側は、このイメージを受け取って起動するだけです。

動かす場所が変わっても、起動するのは同じ 1 つのイメージです。

公開サーバーで実行環境を入れ直す作業がいらないので、手元で動いた構成のまま公開できます。

選ぶときの分かれ目は、要求がない時間にも動いている必要があるかどうかです。

もう 1 つの分かれ目が、1 台の機器にどれだけ載せられるかです。

上の 2 本は、要求がない時間もプロセスが動いたままです。

その 2 本は、実行環境をコンピュータに入れるか、実行環境ごと 1 つにまとめるかで分かれます。

起動したまま動かす 2 つは、要求がない時間の分も動かし続けることになります。

サーバーレスで数えられるのは、動いた時間と呼ばれた回数だけです。

要求がまばらなうちは、この違いがそのまま差になります。

動いている時間で選ぶ

要求がない時間にも動いている必要があるかどうかで、まず 2 つに分かれます。

必要がないならサーバーレス、必要があるなら常時稼働のサーバーかコンテナです。

コンテナは 1 つの OS をアプリどうしで分け合うので、同じ機器に何本も載せられ、動かし続ける費用を抑えられます。

手元と公開先で構成をそろえたいときも、コンテナを選びます。