エンジニアではない人のためのサーバー入門：役割と置き場所で全体像をつかむ

1. はじめに

AI を使ってシステムの設計や実装を進める場面が増えていますが、システムの全体像がわからないと、AI の説明を理解できません。たとえば、「APサーバーでエラーが出ています」と言われても、どこの話かがわかりません。システムは、役割の違うサーバーの組み合わせでできています。そこで、この記事では、全体像を知るために最低限必要な知識として、サーバーを説明します。サーバーは、「何をするか（役割）」と「どこで動かすか（置き方）」の2つに分けて考えると理解しやすくなります。

2. サーバーとは：リクエストに応えるコンピュータ

システムの通信には、お願いする側と応える側があります。お願いする側をクライアント、応える側をサーバーと呼びます。クライアントの例は、ブラウザやスマホアプリです。

クライアントがサーバーに送るお願いを、リクエストと呼びます。一方で、サーバーが返す答えを、レスポンスと呼びます。たとえば、ブラウザで Webサイトを開くと、次の流れが起きます。

このとき、サーバーは、いつ届くかわからないリクエストを待ち続けています。ここで大事なのは、サーバーかどうかは、機械の種類ではなく役割で決まることです。リクエストを受け付けるソフトウェアを入れれば、手元のパソコンでもサーバーになります。

また、同じコンピュータが、クライアントにもサーバーにもなります。たとえば、ブラウザからリクエストを受けたサーバーが、データを取りに別のサーバーへリクエストすることがあります。このとき、そのサーバーはクライアントです。つまり、クライアントとサーバーは、リクエストの向きで決まる役割なのです。

3. 役割はミドルウェアで決まる

ここから、サーバーの役割を説明します。2章では、サーバーかどうかは役割で決まると説明しました。では、その役割は何で決まるのでしょうか。サーバーは、次の4つの層を重ねて動いています。

層	説明	例
アプリケーション	業務の処理を書いたプログラム	経費精算システム
ミドルウェア	決まった役割を担うソフトウェア	Nginx、PostgreSQL
OS	機械を動かす基本のソフトウェア	Linux、Windows Server
ハードウェア	機械そのもの	CPU、メモリ、ディスク

この中で、サーバーの役割を決めるのはミドルウェアです。ミドルウェアは、OS とアプリケーションの間で、決まった役割を担うソフトウェアです。たとえば、同じ Linux の機械でも、PostgreSQL を入れれば DBサーバーになります。代表的な役割は、次のとおりです。

役割	何をするか	代表的なミドルウェア
Webサーバー	画面のファイルを返す。リクエストを振り分ける	Nginx、Apache
APサーバー	業務の処理を実行する	Tomcat
DBサーバー	データを保存し、検索する	PostgreSQL、MySQL、Oracle
メールサーバー	メールを送る・受け取る	Postfix

APサーバーは、アプリケーションサーバーの略です。業務の処理を書いたアプリケーションは、この APサーバーの上で動きます。なお、Spring Boot のように、APサーバーの機能をアプリケーションに組み込む作り方もあります。1章の例の「APサーバーでエラーが出ています」は、業務の処理を実行する部分でエラーが起きた、という意味です。

また、1台の機械に複数の役割を入れることも、役割ごとに機械を分けることもできます。実際のシステムでは、役割ごとに分けることが多いです。

4. サーバーの置き方：物理・仮想・コンテナ・クラウド

ここからは、サーバーの置き方を説明します。置き方は、役割とは別に決まります。置き方は、2つの観点で整理できます。1つ目は、1台の機械をどう使うかです。2つ目は、誰の機械を使うかです。

1台の機械をどう使うか：物理・仮想・コンテナ

まずは、1台の機械をどう使うかから解説します。物理サーバーは、機械をそのまま1台のサーバーとして使う方法です。機械を用意するところから始めるため、使えるまでに時間がかかります。高い性能を安定して使い続けたいときや、機械を占有する必要があるときに向いています。

仮想サーバーは、1台の機械の上で、複数の OS を動かす方法です。機械の性能を分け合えるので、必要な数のサーバーをすぐに作れます。既存のシステムを OS ごとそのまま移したいときや、OS の設定を細かく決めたいときに向いています。

コンテナは、アプリケーションを動かすのに必要なものだけをまとめて動かす方法です。代表的な道具に、Docker があります。機能ごとに分けて頻繁にリリースしたいときや、負荷に合わせて数を増減させたいときに向いています。

仮想サーバーとコンテナの違いは、何をまとめて用意するかです。仮想サーバーは、OS を含めて、サーバー1台分をまるごと用意します。一方で、コンテナは、アプリケーションを動かすのに必要なものだけを用意します。OS は、土台にあるものを共有して使います。そのため、コンテナは軽く、すぐに動きます。

誰の機械を使うか：オンプレミス・クラウド

次に、誰の機械を使うかの観点です。オンプレミスは、自社で機械を持ち、自社のサーバールームなどに置く方法です。社外にデータを置けない決まりがあるときや、すでに自社の設備があるときに向いています。一方で、クラウドは、AWS などの事業者の機械を借りる方法です。必要なときに、必要な分だけ使えます。小さく始めて利用者の増加に合わせて広げたいときや、すぐにサーバーを用意したいときに向いています。なお、クラウドの上でも、仮想サーバーやコンテナを使えます。

さらに、クラウドには、マネージドサービスがあります。OS やミドルウェアの管理まで、クラウド事業者に任せる方法です。たとえば、AWS の RDS を使うと、DBサーバーの OS や PostgreSQL の管理を任せられます。その代わり、変えられる設定は限られます。ただし、テーブルの設計やデータの扱いは、自社で考える必要があります。DB のように役割が決まったサーバーを、運用の手間をかけずに使いたいときに向いています。

管理する範囲の違い

3章の4つの層で比べると、どこまでを自社で管理するかの違いがわかります。ここでは、コンテナは AWS の ECS を Fargate という方式で使う場合を想定しています。Fargate では、コンテナを動かす機械の OS まで AWS が管理します。

置き方	ハードウェア	OS	ミドルウェア	アプリケーション
物理サーバー（オンプレミス）	自社で管理	自社で管理	自社で管理	自社で管理
仮想サーバー（クラウド）	事業者が管理	自社で管理	自社で管理	自社で管理
コンテナ（クラウド）	事業者が管理	事業者が管理	自社で管理	自社で管理
マネージドサービス	事業者が管理	事業者が管理	事業者が管理	自社で管理

下に行くほど、自社で管理する範囲が狭くなります。管理する範囲が狭いと、機械の故障への対応や、OS の更新、セキュリティ対策を事業者に任せられます。そのため、少ない人数でもシステムを運用でき、業務のアプリケーションづくりに集中できます。一方で、任せた部分の設定は、自由に変えにくくなります。また、事業者が決めた仕様や料金体系に合わせる必要があります。

5. なぜサーバーが複数あるのか：役割ごと、機能ごとに分ける

実際のシステムでは、サーバーが1台だけということはほとんどありません。サーバーを分ける単位には、役割と機能の2つがあります。

役割ごとに分ける

3章では、1台の機械に複数の役割を入れることも、役割ごとに分けることもできると説明しました。実際には、Webサーバー、APサーバー、DBサーバーを分けることが多いです。理由は、3つあります。1つ目は、負荷を分けるためです。処理が重い役割だけ、性能を上げたり数を増やしたりできます。2つ目は、障害の影響を小さくするためです。1つのサーバーが止まっても、ほかの役割への影響を抑えられます。3つ目は、データを守るためです。DBサーバーを、外から直接つながらない場所に置けます。ただし、分けても DBサーバーが1台なら、DB が止まるとシステム全体が止まります。止まらないようにするには、同じ役割のサーバーを複数用意します。

機能ごとに分ける：モノリスとマイクロサービス

さらに、APサーバーで動くアプリケーションも、機能ごとに分けることがあります。分け方は、大きく2つです。

モノリスは、すべての機能を1つのアプリケーションにまとめる方法です。一方で、マイクロサービスは、機能ごとに別のアプリケーションにして、それぞれ別のコンテナで動かす方法です。4章で説明したとおり、コンテナは軽いので、たくさん動かせます。マイクロサービスでは、サービス同士が API で呼び合います。API は、システム同士が決まった形式でリクエストとレスポンスをやり取りする仕組みです。たとえば、承認サービスは、承認が終わると通知サービスにリクエストします。つまり、2章で説明したとおり、サーバー同士もクライアントとサーバーの関係になります。

機能ごとに分けると、それぞれの機能を別々に変更・リリースできます。また、設計しだいで、障害の影響を1つの機能にとどめやすくなります。一方で、サービス同士の通信が増えます。そのため、全体の動きを追いにくくなります。

6. AWSでの配置：React と Spring Boot をどこに置くか

最後に、ここまでの内容を、実際の構成に当てはめます。前提は、画面を React、業務の処理を Spring Boot で作るシステムです。Spring Boot のアプリケーションは、1つにまとめたモノリスとします。

この構成を説明していきます。まず、置き方はクラウドで自社で機械を持たず、AWS の機械を借りています。そのうえで、Webサーバー、APサーバー、DBサーバーを、役割ごとに分けて置いています。

Webサーバーの役割は、S3 と CloudFront が果たします。React で作った画面は、ビルド（動かせる形に変換すること）すると、HTML や JavaScript のファイルになります。このファイルを、ファイルを置くサービスの S3 に置きます。そして、画面のファイルを配るサービスの CloudFront から、ブラウザに届けます。どちらもマネージドサービスなので、OS やミドルウェアの管理は AWS に任せられます。また、リクエストを振り分けるサービスの ALB が、届いたリクエストを APサーバーに渡します。これも、Webサーバーの役割の1つです。

APサーバーの役割は、ECS で動く Spring Boot のアプリケーションが果たします。ECS は、コンテナを動かすためのサービスです。Spring Boot は、APサーバーの機能を組み込んだアプリケーションです。このアプリケーションをコンテナにして、ECS で動かします。Fargate 方式を使うので、OS の管理も AWS に任せられます。DBサーバーの役割は、RDS が果たします。RDS はマネージドサービスなので、OS や DB のミドルウェアの管理を AWS に任せられます。

このように、役割は変わっていません。同じ役割を、クラウドのコンテナやマネージドサービスで実現しているだけです。

7. まとめ

この記事では、サーバーを「役割」と「置き方」に分けて説明しました。この2つに分けて考えると、システムの構成図や AI の説明を読んだときに、次のことがわかるようになります。

• 「APサーバー」「DBサーバー」と言われたときに、システムのどの役割の話か
• 「ECS」「RDS」と言われたときに、どの役割を、どんな置き方で実現しているか
• システムに、サーバーやコンテナが複数ある理由

知らないサーバーの名前が出てきたら、「これは何の役割で、どこに置かれているか」を考えてみてください。システムの全体像をつかむ手がかりになります。

最後まで読んでいただいた方、ありがとうございました。