はじめに

前提知識レベル
- Webアプリケーションの裏側で何が起こっているのかをなんとなく知っている
当記事読了後の到達レベル
- Web三層構造の構成要素について説明できる
- Web三層構造のメリットを説明できる
- Web三層構造を採用する上で考慮すべき点を説明できる
当記事の大まかな流れ
- Web三層構造について概要を述べたあと、単層構造と比較しながらWeb三層構造のメリットを説明します

※当記事内での単層構造とは、「三層構造の構成要素が1箇所に集中した構造」と定義します。(下図参照)

Web三層構造の概要

構成要素

Web三層構造では、以下3つの層が存在します。(下図参照)

プレゼンテーション層
アプリケーション層
データベース層

プレゼンテーション層

ユーザが唯一直接アクセスできる層
パブリックな領域に配置される
Webサーバが存在する。Webブラウザを含める場合もある
HTML, CSS, JavaScriptなどで記述された、クライアント側での表示に関わるデータを送信する役割を持つ
動的なコンテンツが必要な場合は、アプリケーション層のAPサーバへリクエストする

アプリケーション層

Webアプリケーションの動的な処理が実行される層
プライベートな領域に配置される
AP(アプリケーション)サーバが存在する
Webサーバからのみアクセスが可能
ビジネスロジックに関わる処理が実行される。Java, Pythonといったバックエンド用の言語で実装される
データベースへのアクセスが必要な場合は、データ層のDBサーバへアクセスする

データ層

永続的なデータを管理する層
プライベートな領域に配置される
DB(データベース)サーバが存在する
APサーバからのみアクセスが可能
MySQL, PostgreSQLなどのRDBや、DynamoDBなどのNoSQL DBといったミドルウェアが存在する

メリット

役割ごとに負荷を分散できる
役割ごとにスケーリング可能
開発・運用の負荷軽減
セキュリティの強化

上記メリットについて、単層構造と比較しながら詳細を見ていきましょう。

三層構造のメリット - vs. 単層構造 -

1. 役割ごとに負荷を分散可能

単層の場合、すべての役割が1箇所に集中しています。
そのため、以下ケースのように、どれか1つの役割だけに大きな負荷がかかった場合でも、システム全体の処理が遅くなってしまいます。

静的コンテンツへのリクエストが増える
ビジネスロジックの重い処理を実行する
データベースで多くの読み書きを実行する

三層構造の場合、各層ごとに負荷を分散できます。
例えば、データ層でデータベースの読み書きを実行中であっても、静的コンテンツへのリクエストはプレゼンテーション層が対応してくれます。

2. 役割ごとに独立してスケーリング可能

単層の場合、前述のようなケースがあったとしても、システム全体をスケールしなくてはなりません。
例えば、データベースの読み書きがボトルネックだった場合、システム全体をスケールする必要があり、無駄なリソース増強をする羽目になります。

三層構造の場合、各層ごとにスケーリングするだけで済みます。
例の場合だと、データ層のDBサーバーをスケーリングするだけで済み、現状で問題のないプレゼンテーション層のWebサーバ、アプリケーション層のAPサーバは手を加える必要がありません。

3. 開発・運用の負荷軽減(クラウドでの構築の場合)

単層の場合、1つのサーバーへ各役割ごとにミドルウェアやOSを自分でインストールする必要があり、作業が煩雑になります。
また、それらのアップデートも自分たちで管理する必要があり、運用面でも大変です。

三層構造の場合、各層に相当するクラウドサービスを繋ぎ合わせることで、ミドルウェアやOSのインストール作業なしに迅速な開発が可能になります。
例えばAWSであれば、プレゼンテーション層はCloudFront&S3、アプリケーション層はApp Runner、データ層はAuroraで構築できます。
また、フルマネージドサービスであれば、クラウド事業者側がアップデートを管理してくれるため、運用作業も軽減されます。

4. セキュリティの強化

単層の場合、秘匿性の高いデータベースやアプリのビジネスロジックを同じ場所に格納しています。
Webアプリケーションなのでインターネットに公開する必要がありますが、秘匿性の高い情報までパブリックに公開されてしまいます。
もし悪意のあるユーザに不正アクセスされた場合には、秘匿性の高い情報が流出してしまいます。

三層構造の場合、パブリックに公開されているのはプレゼンテーション層のWebサーバだけです。
仮にWebサーバが不正アクセスされても、すぐにはAPサーバやDBサーバへアクセスすることはできません。
放っておけばいずれAPサーバやDBサーバにも不正アクセスされかねないですが、Webサーバという1クッションを挟んでいるので、少なくとも時間稼ぎはできます。
不正アクセスを検知後すぐにアプリケーションを落としておけば、情報流出という一番避けたい問題だけは回避できます。

Web三層構造を採用する上での注意点

上手く採用すれば前述のメリットがありますが、注意しないと逆効果になることもあり得ます。

パフォーマンスの低下

プレゼンテーション層とアプリケーション層、データベース層のそれぞれの間で、データのやり取りが発生するため、ネットワークの負荷や遅延が増加します。
アプリケーションの要件が厳しい場合は、デメリットになり得るかもしれません。

開発・運用の複雑化

各層ごとに異なる技術やツールを使用する必要があるため、開発やテスト、デバッグなどの工程が複雑になります。
また、ネットワークや通信プロトコルなどの障害も発生しやすくなる可能性があります。

開発チーム間の連携が必要

各層の開発へと役割分担されたチームが存在することになるため、チーム間の連携が必要になる。

セキュリティの弱点

各層でデータを暗号化したり、認証したりする必要があることから、セキュリティの弱点や漏洩のリスクを増加させる可能性があるといわれています。

参考記事・サイト

https://www.softbank.jp/biz/blog/cloud-technology/articles/202206/web-3-tier-architecture/
https://www.tifana.ai/article/webproduction-article-56
https://ja.stackoverflow.com/questions/18417/web%E3%82%B5%E3%83%BC%E3%83%90%E3%83%BC%E3%81%A8ap%E3%82%B5%E3%83%BC%E3%83%90%E3%81%AE%E5%88%86%E9%9B%A2%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6