第8回　規模や信頼性で決めるWebサイトの構成

樫山友一
2002/8/27

---

　 今回は、Webサイトの規模と信頼性による構成を解説します。第2回「Webサイト設計時の考慮点を知ろう」で、簡単に解説したものの詳細版です。Webサイトの性質によってどの部分を強化するべきか、あるいはどの部分の信頼性を上げるかなどでサイト全体の構成が決まってきます。

　Webサイトにおいて、信頼性とパフォーマンスは密接な関係にあります。特にクラスタは、パフォーマンスの向上に利用可能ですが、信頼性の向上にも利用することができます。そのため設計前に、Webサイトのパフォーマンスを強化すべきか、あるいは信頼性を高めるべきか、をあらかじめ明確にしておく必要があります。同時にWebサイトの性質も把握しておく必要があります。

　以下、Webサイトの設計において、事前に明らかにしておくべきことを列挙します。

• （静止画像など）静的コンテンツが多い
  
• （JSPやサーブレットで生成するHTMLなど）動的コンテンツが多い
  
• データベースへのアクセスが多い
  
• ダウンロードが多い
  

　上記の性質によって、Webサイト内のサーバの配置を検討します。では、Webサイトの性質がサイト全体の構成にどのような影響を与えるかを順次解説していきましょう。

小規模なWebサイト

　小規模なWebサイトでは、基本的に図1のような構成をとります。

図1 小規模なWebサイトの基本最小構成

　図1に示す構成では、理解しやすいように2つのファイアウォールを用いていますが、実際には図2のように、DMZ（DeMilitarized Zone）を構成して1つのファイアウォールで実現します。

図2 実際にはDMZを構成して1つのファイアウォールで実現する

　ただし、このような構成では、アプリケーションサーバやデータベースサーバの障害だけでサービスが停止してしまいます。また、この構成のままでパフォーマンスを上げようとすると、アプリケーションサーバとデータベースサーバのハードウェアの仕様をハイレベルなものにするしかありません。具体的には、CPUの数やメモリを増強するといったことです。つまり、このような構成は24時間連続稼働を強いられるサービスでは利用できないことになります。逆に、サービス停止がビジネスに大きなインパクトを与えることがない場合などにはこのような構成を利用してもいいでしょう。

静的なコンテンツが多いWebサイト

　J2EEのアプリケーションサーバは、HTTPサーバの機能を持っているものがほとんどなので、HTMLや画像をWebブラウザに送ることが可能です。しかし、アプリケーションサーバの本来の仕事は、データベースへアクセスをして、WebブラウザのリクエストごとにHTMLを生成することです。そのためには、アプリケーションサーバが動作するハードウェアのリソースを使うことが理想です。Webブラウザへの画像の送信は、ハードウェアのリソースを多く必要とするため、図3のように、静的なHTMLや画像をアプリケーションサーバの前段でWebブラウザに送り返す構成をとると、アプリケーションサーバが動作するハードウェアを理想的に利用することができるのです。

図3 静的なコンテンツが多いWebサイトの基本構成

　図3の構成にDMZを適用すると、図4のようになります。DMZにはHTTPサーバのみが配置されます。HTTPサーバは、Webブラウザからの処理をアプリケーションサーバに中継します。その結果、WebブラウザはHTTPサーバと通信を行うだけになります。DMZからは直接データベースにアクセスすることがなくなるため、図2の構成と比較して強固なセキュリティを築くことができます。

図4 静的なコンテンツが多いWebサイトの基本構成にDMZを適用

動的なコンテンツが多いWebサイト

　動的なコンテンツが多いということは、アプリケーションサーバの仕事量が多いということです。アプリケーションサーバのCPU数やメモリを増強しても対応ができない場合は、アプリケーションサーバをクラスタ化して対応します。アプリケーションサーバのクラスタ方式は基本的に図5のような構成をとります。

図5 アプリケーションサーバの基本的なクラスタ構成

　Webブラウザからの要求はHTTPサーバが受け、設定されているアルゴリズムにのっとってJ2EEアプリケーションサーバにフォワードされます。2つのアプリケーションサーバはすべての要求を均等に処理します。単純に考えると処理能力は2倍になりますが、リクエストごとに同じデータを参照・更新するケースが多い場合は、データベース側で排他制御がかかり、思ったよりも処理能力が上がらない可能性があります。これを回避するには、複数のアプリケーションサーバでデータベースを共有しても、処理が遅延しないように設計する必要があります。

データベースへのアクセスが多いWebサイト

　データベースへのアクセスが多い場合は、アプリケーションサーバでデータをキャッシュする構成をお勧めします（図6）。そのためには、設計時にどの技術を利用してキャッシュをするか決めなければなりません。J2EEでは、データベースへのアクセスは、EJBを用いて行うとトランザクションの制御が簡単に行えます。EJBを用いてキャッシュを行えれば、プログラムの作成はシンプルになります。

図6 データベースへのアクセスが多いWebサイトの基本構成

　最も効率的にデータをキャッシュするには、データベースとアプリケーションサーバを1対1で配置する構成にします。ただし、図5のようにクラスタ構成を採用すると、データが更新されたことをほかのアプリケーションサーバに通知する必要が出てきてしまい、その結果、このような通信が頻繁に発生すると処理能力を落とすことになってしまいます。クラスタ構成にするとデータをキャッシュすることが難しくなってしまうのです。このような場合は、設計時に参照が多いデータと更新が多いデータを明確に区分けしておきます。そして、参照が多いデータはキャッシュするように設計します。この際、更新が多いデータとうまく分離してデータベースへのアクセスを少なくする必要があります。

図7 キャッシュを効率的に利用したクラスタ構成

　基本的には図7のような構成です。効率的にキャッシュを利用するためにはアプリケーションサーバ独自の機能を利用することができます。いくつかのアプリケーションサーバは、クラスタで共有してキャッシュしているデータを、書き込みのタイミングでフラッシュ（キャッシュを廃棄する）する機能を持っています。

信頼性を重視するWebサイト

　24時間サービスを続けなければならないWebサイトは数多くあります。この場合、HTTPサーバ、アプリケーションサーバ、データベース、ネットワークのすべてを二重化して、どこかで障害が起きても動作し続けるような構成をとることが必要です。また、このようなサイトは、アクセス量も多いので処理能力も確保しなければいけません。

図8 すべてを二重化したシステム

　図8を例に考えてみましょう。

　Webブラウザからのアクセスは、まずロードバランサに渡されます。ロードバランサとは、受け付けたアクセスをHTTPサーバに振り分けるもので、ハードウェアとして提供されています。ロードバランサについても、障害発生後に動作を続けるよう構成しなければなりません。ロードバランサへの処理の振り分けはDNSラウンドロビンで行います。DNSラウンドロビンとは、1つのDNS名に複数のIPアドレスを割り当てる機能です。Webブラウザでは、あるURLをDNSから引こうとすると、複数のIPアドレスが順番に返ってきます。つまり、1つのロードバランサが障害で動作しない場合でも、もう1度アクセスを試みれば、動作している側のロードバランサに接続できるのです。

　次にHTTPサーバの障害を考えます。ロードバランサは一定周期でHTTPサーバの動作を監視する機能を持っていますが、もし、HTTPサーバが動作しない場合、ロードバランサは動作している方のHTTPサーバにのみ処理をフォワードします。

　アプリケーションサーバの障害は、前述のとおり、障害時にHTTPサーバが処理をアプリケーションサーバにフォワードしないようにすることで対応します。

　データベースについては、ベンダや製品により二重化の方法が異なります。単純にレプリケーションを取っておくものから、コールドスタンバイ、ホットスタンバイなどの構成を選択することもできます。

コールドスタンバイ	稼働しているコンピュータの障害を検知しながら、障害発生時はそのコンピュータの代替機として動作を開始するシステム
ホットスタンバイ	2つのデータベースが同時に動作し、常にデータの同期を取りながら稼働するシステム

◆

　規模やセキュリティ、処理能力などによってサーバの構成を決めることは、簡単なことではありません。実際には、経験豊かなエンジニアや企業から情報を得て、構成を決めることをお勧めします。ハードウェアの納入には時間がかかり、1度決めてしまった構成を変更することはなかなかできませんから。

■参考文献
「わかりやすいUML入門」オーム社
「Webサイトのわかる本」オーム社

プロフィール

樫山友一（かしやま ゆういち） 大手電機メーカー研究所でオブジェクト指向によるシステム開発に従事する。1996年よりJavaへの取り組みをはじめ、J2EEアプリケーションサーバを活用したWebシステム構築のコンサルタントとして多数のプロジェクトを手掛ける。 2001年3月にイーズ・コミュニケーションズ株式会社の設立に参加し、最高技術責任者に就任。 著書に「わかりやすいUML入門」、「Webサイトがわかる本」（いずれもオーム社）がある。

Java Solution全記事一覧

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）