サーバ
Server ・ さーば
リクエストを受けて応答を返すコンピュータまたはプログラム。要求を出すクライアントと対をなす。
✦ 30秒で試す — 航海機械は元気なのに「サーバが落ちた」と言われることがあるこの4つの係で、数万の接続を同時に抱えられる？予想してみる概要
サーバとは「頼まれたら応える側」のことです。ブラウザやスマホアプリのように要求を出す側をクライアント、その要求（リクエスト）を受け取って結果（レスポンス）を返す側をサーバと呼びます。この「クライアント・サーバモデル」は、ネットワークを介したシステムの最も基本的な構図で、Webページの表示もメールの送受信もオンラインゲームも、突き詰めればこのやり取りの積み重ねです。
紛らわしいのは、サーバという言葉が指すものが文脈で変わることです。データセンターに並ぶ物理的な機械（ハードウェア）を指すこともあれば、その上で動く OS を含めた環境を指すこともあり、リクエストを待ち受けるプログラムそのもの（nginx や Apache のようなソフトウェア）を指すこともあります。「サーバが落ちた」と言うとき、壊れたのが機械なのか、OS なのか、1つのプログラムなのかは、話の流れで読み分ける必要があります。機械が元気でも、待ち受けているプログラムが止まっていれば、クライアントから見ればサーバは「落ちて」いるのです。
また、何に応えるかによって呼び名が変わります。Webページを返すのが Web サーバ、アプリケーションのデータを API として返すのが API サーバ、データの保存と検索を担うのが DB サーバ（多くは RDBMS）です。1台の機械に複数の役割を同居させることも、役割ごとに何十台も並べることもあります。
なぜ生まれたか
コンピュータが高価だった時代、計算資源は1台の大型機（メインフレーム）に集約され、利用者は画面とキーボードだけの端末からそれを共同利用していました。やがて安価なパーソナルコンピュータが普及すると、今度は逆に「各自の手元のマシンだけでは、共有データや重い処理を扱えない」という問題が生まれます。全員のPCに同じデータを配って回れば、誰かが更新するたびに食い違いが生まれ、どれが正しいのか分からなくなります。
そこで「共有すべき資源や処理は専用の機械に集め、各自のマシンはネットワーク越しにそれへ依頼する」という役割分担が1980年代に定着しました。これがクライアント・サーバモデルです。データを一箇所で管理できるので食い違いが起きず、性能が必要ならサーバ側だけを強化すればよい。画面の表示や操作の受け付けは手元のクライアントが受け持つので、共有の機械は「頼まれた仕事」に専念できます。この分担の明快さが、インターネット時代のほぼすべてのシステムの土台になりました。1990年代に登場した Web も、ブラウザというクライアントと Web サーバという、この構図そのものです。
詳細
1台の機械の中で、プログラムが待ち受ける
サーバの仕事は「待つ」ことから始まります。サーバプログラムは OS に頼んで、特定のポート番号で接続を待ち受けます。ポート番号は、同じ機械の中のどのプログラムに宛てた通信かを区別する番号です。Web なら暗号化しない HTTP は 80 番、TLS で暗号化した HTTPS は 443 番が決まりで、ブラウザは URL にポートが書かれていなければこのどちらかに接続します。1台の機械の中で、Web サーバ、アプリケーション、DB サーバがそれぞれ別のポートで待ち受けている、というのはよくある構成です。
プログラムとしてのサーバは、OS 上のひとつのプロセスとして動きます。接続を待ち受ける手順は、どの言語で書いてもほぼ同じです。まず OS に通信の口（ソケット）を作ってもらい、それを自分の IP アドレスとポート番号に結び付け（bind）、待ち受けを始めます（listen）。クライアントが接続してくると、OS はその1本の接続のための新しいソケットを渡してくれるので（accept）、サーバはそこからリクエストを読み、処理をしてレスポンスを書き、接続を閉じるか次のリクエストを待ちます。
リクエストとレスポンスの往復
クライアントがサーバを見つけるには、相手の機械の住所である IPアドレスが必要です。人間が覚えやすい名前（example.com）から住所を引くのが DNS の役割で、ブラウザはまず DNS に問い合わせてから、その住所の 443 番へ接続します。接続の上では TCP/IP が、データが欠けずに順番どおり届くことを支えています。
ここで DNS サーバもまた「名前を聞かれたら住所を答える」サーバだという点に注目してください。1回のページ表示の裏で、ブラウザは複数のサーバにそれぞれ別の仕事を頼んでいます。サーバとは特別な機械の名前ではなく、やり取りの中での役割の名前なのです。
多層に分かれるサーバの役割
実際のWebシステムでは、サーバは役割ごとに層をなします。入口で静的ファイルの配信や振り分けを担う Web サーバ、業務の処理を実行するアプリケーションサーバ、データを預かる DB サーバという3層構成が典型です。規模が大きくなると、入口にロードバランサを置いて複数のサーバへリクエストを分散したり、リバースプロキシを挟んでキャッシュや TLS の終端を任せたりします。
層に分ける利点は、負荷の高い層だけを増強・増設できることです。アプリケーションサーバが足りなければ台数を増やし（スケーリング）、DB が重ければ DB だけを強い機械にする。そのとき、アプリケーションサーバが利用者ごとの状態をメモリに持たない（ステートレスである）ことが、台数を気軽に増やせる条件になります。
同時にたくさんの相手をする
サーバは一度に一人の相手だけをしていれば済むわけではありません。人気のサービスでは、同時に数千、数万の接続が開いています。そこで、どうやって多数のクライアントを同時にさばくかという並行と並列の設計が、サーバソフトウェアの個性になります。古典的なのは、接続ごとにプロセスやスレッドを割り当てる方式で、書き方は素直ですが、接続が増えるとメモリと切り替えの手間が膨らみます。もう一つは、少数のスレッドが「データが届いた」「書き込めるようになった」という知らせを順に処理していく方式で、nginx や Node.js のイベントループがこれです。待ち時間の長い接続を大量に抱えるのが得意な代わりに、1つの重い計算がループを止めると全員が待たされます。
クラウド時代のサーバ
かつてサーバといえば自社で購入・設置する物理マシンでしたが、仮想マシンの技術により1台の物理機を複数の論理的なサーバに分割できるようになり、さらにクラウドコンピューティングの普及で「分単位で借りて使う」ものになりました。近年はコンテナやサーバレスのように、物理的な機械をほとんど意識しない形も一般化しています。とはいえ、どれだけ層が増えても「クライアントが頼み、サーバがポートで待ち受けて応える」という構図そのものは変わっていません。抽象の層を剥がしていくと必ずこの原型に行き着く、という意味で、サーバはシステム設計の出発点となる語彙です。
試問
ネット通販のサイトは、役割ごとに3種類のサーバを重ねて動いています。入口で受け付ける Web サーバ、業務の処理をするアプリケーションサーバ、データを預かる DB サーバです。1回の買い物の裏で起きる8つの仕事を、どのサーバが受け持つかで分けます。
ネット通販の8つの仕事を、Web サーバ・アプリケーションサーバ・DB サーバのどれが受け持つかで仕分けよ
項目を選んでから、入れる箱を選びます