Webシステムってどうやってできてるの？ Web三層アーキテクチャとボトルネックについて理解しよう。

どうも、ITコンサルタントのShoheiです。 

今日はWebを構成するアーキテクチャの基礎について説明していきます。

以前までの記事との関連性について

過去記事で、Webサーバに関する超入門記事やhttpに関する説明記事を説明しました。

また今までいくつか、データベースに関する記事なども記載してきました。

ただし、WebシステムはWebサーバやデータベースサーバがあれば構築できるかと言われるとNoで、色々なサーバがそれぞれ機能を発揮し合うことで、一つのシステムを構成します。

今回は、その基本となるWeb三層アーキテクチャ(Web三層モデル・Web三層構造)について説明したいと思います。

Web三層アーキテクチャの概要

Web三層アーキテクチャという言葉を聞いたことがありますか？

WebサイトやWebアプリケーションを作る時、以下のような3つの役割を持つサーバによりシステムを構成させるモデルのことを指します。

超基本的なWebサイトは、この3つのサーバさえあればある程度の機能は提供できます。

一つずつ役割を見てみましょう。

Webサーバ

レストランでイメージしてみましょう。あなたがメニューを見て特定の料理を得たい、と思った時、まず誰に何をしますか？　そう、ウェイターさんに注文をしますよね。そして裏で作られた料理を運んできてくれるのもウェイターさんです。

Webサーバはまさにそのウェイターの役割をするためのサーバです。

Webサーバは、HTTPリクエストを受け付けます。あなたが「このブログを見たい」と思ったら、HTTPという形式で、このサーバに対して注文を出すことになります。そしてWebサイトのコンテンツ(主にhtmlファイル)を返してくれるのも、このサーバです。

もっと身近な言葉でいうと、Webサーバとは、ユーザがChromeにURLを入力してエンターを押した時、そのリクエストが到着する場所であり、最終的なコンテンツ(例えばこのブログ)を返答する役割を持つ場所です。

Appサーバ

さて、ウェイターさんが注文を受け付けました。その後、レストランだと何が起こりますか？　きっと裏で控えているコックさんに注文内容を伝えて、料理を作りますよね。

Appサーバはコックさん的な存在です。Appサーバの中にはRuby, Java, PHPなど、コンテンツを動的に生成するプログラムが入っています。プログラムに条件を与えると、それを元にコンテンツを生成します。

コンテンツを生成するってなんやねん、という方、少しイメージを沸かせてみましょう。

(1) いつ誰がアクセスしても全く同じサイトの場合

いつ行っても全く同じWebサイトが表示されるパターン。わかんないですけど古ーい役所のサイトとかですかね。

こういうサイト、もうあまり見なくなりましたが、この場合はあまり生成するというイメージとは合わないかもしれません。確かにこの場合は、おそらくサーバ側には静的なhtmlファイルが格納されていてそれを返すだけになるので、PHPなどの動的にコンテンツを生成するプログラムは不要となるかもしれません。

(2) 時間によって異なるコンテンツを返すサイトの場合

例えば、(1)のサイトに変化をつけるために、サイトのトップに時間や時期によって「おはようございます」「こんにちは」「こんばんは」「メリクリ」「あけおめ」などの挨拶をつける場合、このサイトは動的と言えます。

その場合例えばですが、

1. Webサーバでhttpリクエストを受け付け、Appサーバに処理を依頼
2. Appサーバでphpプログラムを起動し
3. 時間と時期を判定してメッセージを作り
4. そのメッセージをあらかじめ用意しておいた静的なhtmlファイルに追記して(phpが行う)
5. 生成したhtmlファイルをWebサーバ渡す

といった流れで、挨拶文を生成します。

お、なんとなく動的なプログラムが必要そう、って理解できましたか？

イメージ図とともにいくつか例を2つ記載しておきましょう。

(3) システムに保存しているデータを元にコンテンツを生成するサイトの場合

ECサイトをイメージしてください。アクセスすると、商品名や値段、在庫状況などの情報が表示されるかと思います。この情報は、日により、また時には秒単位で変化するものであり、またビジネスの観点でも非常に重要なデータとなります。

またユーザーの検索や絞り込みに合わせて表示するコンテンツも変わりますし、ログインユーザーに合わせて表示内容も変える仕様かもしれません。 これらは言うまでもなく動的にコンテンツを生成する必要がありますね。

細かくは後ほど触れますが、これらの情報はDBサーバに保存されることが大半です。

この際のコンテンツ生成の流れをAppサーバ目線で説明します、

コンテンツを生成する際、AppサーバからDBサーバに対してアクセスし(SQLクエリを発行し)、まず情報を得ます。そしてその情報を元にコンテンツを生成し、クライアントへの送信します。

またデータの参照だけでなく更新も行われます。商品の購入があった際に在庫を減らす、など、DBの値を更新する必要が出た際は、Appサーバ経由でDBサーバにアクセスし、情報の更新を行なった上で、「購入が成功しました、発送日は明日です」などのコンテンツ生成することとなります。

DBサーバ

データベースサーバについては、こちらの記事ですでに紹介されているので、利用のメリット等についてはここでは触れません。

一つ、もう少し細かく中身を分解するのであれば、以下のように構成されています。

上の図のように、データは、データの保護に強かったり、大容量保存が可能な外付けのStorageに保存していることが多くあります。

これだけ見ると大した話ではないのですが、今回は折角Web三層アーキテクチャの話で、個々のサーバの連携の流れについて説明をしているので、Appサーバ・DBサーバ・そしてそのStorageの間での処理の流れについても記載してみましょう。

ハードパース・ソフトパースなどの用語の解説はここではしませんが、ざっくりした処理の流れについては理解できるかと思います。

実はこの処理の流れが意外と重要です。例えば、このシステムの管理者が「Webが遅いんだけど」というクレームを受けた時、DBサーバ側の処理でどこを疑うべきか(ボトルネック)特定したり、対処の計画を立てるときに、ここの理解が重要になります。

それぞれの作業で、どこに負荷が発生しているかは以下の通りです。

前回記事で若干触れた通りですが、CPU/Memory/Diskの中で最も負荷の原因になりやすいのは、DiskへのIO(読み書き)です。

CPU演算 : Memoryへの読み書き : Diskへの読み書きの速さ=ナノ秒 : マイクロ秒 : ミリ秒 というオーダーと言われており、それぞれ1000倍ずつ違ってきます。

とはいえ、DiskIOが必ずしもボトルネックというわけではなく、ケースバイケースなので、それぞれについて細かく分析をし、ボトルネックを特定していく必要があります。

DB周りの性能改善について学ぶには、以下が非常に良本です。本当に勉強になります。興味がある方は是非読んでみてください。

データベースの限界性能を引き出す技術 ~NoSQLに飛びつく前に知っておきたい原理と最新テクニック

まとめ

Web三層アーキテクチャと、Databaseサーバの中身の構造について少しだけ触れました。

なお、Web三層アーキテクチャについては、途中でWebサーバ/Appサーバだけの構成を紹介した通り、必ずしも全て必要とは限りません。また、物理的に環境を分ける必要も必ずしもなく、一つのVM上に全機能を実装するというようなやり方行われることは理解しておきましょう。