サーバ

概要

サーバとは「頼まれたら応える側」のことです。ブラウザやスマホアプリのように要求を出す側をクライアント、その要求（リクエスト）を受け取って結果（レスポンス）を返す側をサーバと呼びます。この「クライアント・サーバモデル」は、ネットワークを介したシステムの最も基本的な構図で、Webページの表示もメールの送受信もオンラインゲームも、突き詰めればこのやり取りの積み重ねです。

紛らわしいのは、サーバという言葉が指すものが文脈で変わることです。データセンターに並ぶ物理的な機械（ハードウェア）を指すこともあれば、その上で動く OS を含めた環境を指すこともあり、リクエストを待ち受けるプログラムそのもの（nginx や Apache のようなソフトウェア）を指すこともあります。「サーバが落ちた」と言うとき、壊れたのが機械なのかプログラムなのかは、話の流れで読み分ける必要があります。

また、何に応えるかによって呼び名が変わります。Webページを返すのが Web サーバ、アプリケーションのデータを返すのが API サーバ、データの保存と検索を担うのが DB サーバです。1台の機械に複数の役割を同居させることも、役割ごとに何十台も並べることもあります。

なぜ生まれたか

コンピュータが高価だった時代、計算資源は1台の大型機（メインフレーム）に集約され、利用者は端末からそれを共同利用していました。やがて安価なパーソナルコンピュータが普及すると、今度は逆に「各自の手元のマシンだけでは共有データや重い処理を扱えない」という問題が生まれます。全員のPCに同じデータを配って回るわけにはいきません。

そこで「共有すべき資源や処理は専用の機械に集め、各自のマシンはネットワーク越しにそれへ依頼する」という役割分担が定着しました。これがクライアント・サーバモデルです。データを一箇所で管理できるので整合性が保て、性能が必要ならサーバ側だけを強化すればよい。この分担の明快さが、インターネット時代のほぼすべてのシステムの土台になりました。

詳細

リクエストとレスポンスの往復

サーバの仕事は「待つ」ことから始まります。サーバプログラムは特定の ポート番号（Web なら 443 番など）で接続を待ち受け、クライアントからの接続を受け付けると、リクエストの内容を解釈し、処理をして、レスポンスを返します。Web の場合、この会話の言葉が HTTP で、その下では TCP/IP が確実なデータ転送を支えています。クライアントがサーバを見つけるには IPアドレス が必要で、人間が覚えやすい名前から住所を引くのが DNS の役割です。

多層に分かれるサーバの役割

実際のWebシステムでは、サーバは役割ごとに層をなします。入口で静的ファイルの配信や振り分けを担う Web サーバ、ビジネスロジックを実行するアプリケーションサーバ、データを預かる DB サーバ（多くは RDBMS）という3層構成が典型です。規模が大きくなると、入口に ロードバランサ を置いて複数のサーバへリクエストを分散したり、リバースプロキシ を挟んで キャッシュ や TLS の終端を任せたりします。

「1台のプログラム」としてのサーバ

プログラムとしてのサーバは、OS 上のひとつの プロセス として動きます。多数のクライアントを同時に相手にするため、接続ごとに スレッド を割り当てる方式や、少数のスレッドでイベント駆動的に捌く方式（nginx や Node.js の方式）など、並行処理の設計がサーバソフトウェアの個性になります。クライアントとの接続そのものは ソケット という抽象で扱われます。

クラウド時代のサーバ

かつてサーバといえば自社で購入・設置する物理マシンでしたが、仮想マシン の技術により1台の物理機を複数の論理サーバに分割できるようになり、さらに クラウドコンピューティング の普及で「分単位で借りて使う」ものになりました。近年は コンテナ や サーバレス のように、物理的な機械をほとんど意識しない抽象も一般化しています。とはいえ、どれだけ層が増えても「クライアントが頼み、サーバが応える」という構図そのものは変わっていません。抽象の層を剥がしていくと必ずこの原型に行き着く、という意味で、サーバはシステム設計の出発点となる語彙です。