Web 3 層モデル — Web・アプリケーション・データベースの分担

この記事は、Web 3 層モデルを扱います。

Web アプリを Web・アプリケーション・データベースの 3 つの役割に分けて見る考え方です。

入門書のフロントエンドとバックエンドは、この 3 つのどれかを別の言い方で呼んだものです。

本文では正式な呼び名、図では場所が狭いので Web 層・AP 層・DB 層と略します。

3 層モデルは、1 つのアプリを Web・アプリケーション・データベースの役割で分ける

3 層モデル（three-tier architecture。 Web・アプリケーション・データベースの 3 つの役割に分けて作る構成）が Web アプリの基本形で、分けた 1 つ 1 つを層（tier）と呼びます。

Web サーバー層が返したファイルは、利用者のブラウザが実行して画面を描きます。

アプリをどの部分に分け、どうつなぐかという構成そのものがアーキテクチャ（architecture）で、入門書の「3 層アーキテクチャ」はこの記事の 3 層モデルと同じものです。

3 つの層は、上から下へ利用者に近い順に並びます。

利用者が直接操作するのは Web サーバー層が返した画面だけで、残る 2 つは見えません。

Web サーバー層が返した画面は、利用者 1 人につき 1 つずつブラウザの中で動きます。

利用者が 3 人なら画面は 3 つで、残る 2 つの層は 3 人で 1 つを使います。

左の 3 つの画面は、それぞれ別のパソコンやスマホで動いています。

同じ時間を選んだ A と B のうち、あとから処理されたほうが断られるのは、記録が 1 つのデータベース層にまとまっているからです。

画面がいくつになっても、届く先と記録は 1 つずつです。

3 層モデルは 1 つのアプリの中の分担

3 層モデルとは、1 つのアプリを Web・アプリケーション・データベースの 3 つの担当に分ける決め方です。

入門書のフロントエンドが Web サーバー層、バックエンドがアプリケーションサーバー層で、 Web サーバー層が返した画面は利用者ごとに 1 つずつあり、アプリケーションサーバー層とデータベース層は全員で 1 つを使います。

なぜ層に分けるのか — 直す場所が 1 つで済み、全員分を 1 か所で決められる

分ける理由は 2 つあります。

1 つ目は、変えたいことがあるとき、直す場所が 1 つの層に収まることです。

分けてあれば、触るのは Web サーバー層のファイルだけです。

1 つにまとまっていると、色を決めている場所を探したうえで、関係のない処理まで動くかどうかを確かめ直します。

2 つ目は、全員分をまとめて判断し、保存する場所が要ることです。

Web サーバー層が返した画面は利用者 1 人のブラウザで動き、他の人の入力を知りません。

そのアプリ固有の判断の決まりがビジネスロジック（business logic）で、アプリケーションサーバー層に置きます。

Web サーバー層が返した画面でも、日付の欄が空でないかなどは確かめます。

ただし、その確認をしているのは利用者のブラウザに届いたファイルなので、利用者の側で書き換えたり飛ばしたりできます。

だから同じことを、アプリケーションサーバー層でもう一度確かめます。

2 人が同じ 12/24 18:00 を同時に送った場面で、この判断をどこに置くかによって結果がどう変わるのかを比べます。

違いは、判断するときに何を見ているかです。

画面の側は自分のブラウザの一覧だけを見ていて、アプリケーションサーバー層は全員分の記録を読んでから決めます。

画面の側に置くと、利用者 A と B はどちらも自分の一覧しか見ていないので、両方が「空いている」と判断します。

アプリケーションサーバー層に置けば、全員分のリクエストが 1 か所に届き、記録を読んでから順に確かめられます。

分けるのは、直す場所と決める場所のため

層に分けておくと、直したいときに触る場所が 1 つで済みます。

もう 1 つの理由は全員分を 1 か所で見て決める必要があることで、利用者ごとに分かれている画面では、ほかの人が何を送ったかが分かりません。

予約が 1 件入るまでに、データは層をどうまたぐか

Web サーバー層とアプリケーションサーバー層はリクエストとレスポンスで、アプリケーションサーバー層とデータベース層は読み書きの指示でつながっています。

どの層も、自分の担当だけをして次へ渡します。

Web サーバー層はデータベース層に直接つながらず、間には必ずアプリケーションサーバー層が入ります。

データベース層から記録が返ったあとは、アプリケーションサーバー層が結果を決めます。

どちらに分かれても、 Web サーバー層に戻るのは 1 つのレスポンスです。

3 層はこの記事の基本形で、実際のアプリには例外もあります。

アプリケーションサーバー層を自分で作らず外部サービスへ直接つなぐ構成や、アプリケーションサーバー層が複数に分かれた構成もあります。

それでもWeb・アプリケーション・データベースのどれを担当しているかで見れば読めます。

下りて戻る道は 1 本

利用者の入力は、 Web サーバー層からアプリケーションサーバー層、データベース層へと下りて、同じ道を戻ります。

Web サーバー層はデータベース層に直接つながらず、アプリケーションサーバー層が記録を読んでから結果を決めて、戻すのは 1 つの返事だけです。

自分のアプリではどれがどの層か — 3 層は 3 台とは限らない

入門書に出てくるファイルやフレームワークが、どの層のものかを先に決めると、手順の意味が読めます。

Web サーバー層は、どちらの場合も同じファイルです。

ブラウザが直接読めるのは HTML・CSS・JavaScript なので、言語を選べるのはアプリケーションサーバー層から先です。

層は役割の分け方であって、コンピュータの台数ではありません。

手元で http://localhost:3000 を開いているとき、3 つの層は全部このパソコンの中にあります。

公開すると層ごとに別のサーバーに置かれることが多く、その作業は「デプロイと環境変数 — 手元で動いたものを公開するまで」の記事で扱います。

Web サーバー層が返した画面だけが利用者の端末で動き、アプリケーションサーバー層とデータベース層は公開サーバー側にあります。

データベース層を別の機械に移しても、アプリケーションサーバー層から読み書きの指示を送るという関係は変わりません。

層の数と、コンピュータの台数は別

3 つの層に分かれていても、動くコンピュータが 3 台とは限りません。

手元では 3 つとも自分のパソコンの中にあり、公開したあとは層ごとに別のサーバーに置かれることが多くなります。