本連載ではこれまで,Webシステムにとって重要な「可用性」と「パフォーマンス」について説明してきた。今回と次回ではその集大成として,次の要件におけるWebアーキテクチャを読者とともに考えたい。

~要件~

社内向けの業務用Webシステム。ほとんどは参照系の機能で,更新系の機能は一部のみ。ピーク時の同時利用者数は100人程度で,ページ遷移時間(思考時間や入力時間を含む)は平均5秒程度である。システムの構築コストを抑えたいので,既存の古いPCサーバーを流用したい。障害が発生した場合,サービス停止時間は1時間以内とするが,数件程度のデータの欠落は許される(後で確認して再入力できれば十分である)。

Webシステムの基本構成

 Webシステムは,Webブラウザとサーバー群で構成する一種のクライアント/サーバー(C/S)型システムである(図1)。ただし,一般的なC/S型システムと異なり,クライアントに当たるWebブラウザではごく簡単な処理しか実行しない。処理もデータもサーバー側に集中している。

図1●Webシステムの構造
図1●Webシステムの構造
一種のクライアント/サーバー型システムであるが,クライアントに当たるWebブラウザではごく簡単な処理しか実行しない
[画像のクリックで拡大表示]

サーバーは3層で成り立つ

 Webシステムのサーバー群は,役割から3層――(1)Webブラウザからのリクエストを受け付けてレスポンスを返す「Webサーバー」,(2)業務ロジックなど処理を実行する「アプリケーション(AP)サーバー」,(3)データを参照したり更新したりする「データベース(DB)サーバー」――に大別できる。

 (1)Webサーバーには,Webブラウザとの通信機能を持つ常駐サービス「HTTPD(HTTPデーモン)」を配置する。HTTPDの代表例は,オープンソース・ソフトの「Apache HTTP Server」や,「IIS(Internet Information Services)」(米Microsoft)である。

 (2)APサーバーには,任意の処理を実行するプログラムの稼働環境となるミドルウエア「APコンテナ」を配置する。具体例として,例えば「JBoss Application Server」(米Red Hat)やオープンソースの「Apache Tomcat」などがある。APコンテナとHTTPDは別のサーバー機に配置することもできるが,1台のサーバー機に共存させることもできる。実際,簡易なスクリプト言語(PerlやPHPなど)用のAPコンテナ(「mod_perl」や「mod_php」)は,Apache HTTP Serverに組み込んで使う仕組みになっている。

 (3)DBサーバーとは,データの管理機構を備えたミドルウエアである「DBMS(Database Management System)」を配置したサーバーだ。具体例として,例えば「Oracle Database」(米Oracle)やオープンソースの「PostgreSQL」などがある。Webシステムの利用者が入力したデータや,アプリケーションで参照するデータを永続的に保管したい場合に,このサーバーを利用する。

 Webシステムの基本はこの3層だが,必ず3層が必要とは限らない。内容が逐次的に変わらない単純なHTMLファイルや画像ファイルを扱うだけであれば,(1)のWebサーバーだけで事足りる。逆に,どんな複雑な要件のWebシステムであっても,基本となる3層構造の応用として構成される。

 今回の要件では「業務アプリケーション」を例とする(業務ロジックや永続的なデータがある)ので,Web,AP,DBの3層すべてを使用する。また,「コストを抑えたい」という要件から,HTTPDには「Apache HTTP Server」,APコンテナには「Apache Tomcat」,DBMSには「PostgreSQL」という無償のオープンソース・ソフトを採用する。

Webシステムで起きやすい二つの問題

 Webシステムでは二つの問題が発生しやすい(図2左)。第一に,利用者が増えた場合に「パフォーマンスの劣化」が起こりやすい。第二に,障害時にサービスが停止する「可用性の不足」に陥りやすい。その理由は,WebブラウザとWebサーバー間のやり取りに使われる「HTTP(HyperText Transfer Protocol)」と呼ぶルール(=プロトコル)の特性にある。

図2●発生しやすい問題と解決策
図2●発生しやすい問題と解決策
Webシステムでは特性上,「パフォーマンスの劣化」と「可用性の不足」という問題が発生しやすい。解決策は,複数台のサーバー機を設置して整合性をとることだ
[画像のクリックで拡大表示]

 HTTPは,テキスト形式のメッセージを送受信するというごくシンプルなプロトコルだ。具体的には,WebブラウザからWebサーバーに対してメッセージを送信(=リクエスト)し,その結果となるメッセージをWebサーバーからWebブラウザに返信(=レスポンス)するという流れになる。ところが,このシンプルさがあだとなり,前述したような問題が起きることがある。

 パフォーマンスの問題が起きやすいのは,(メッセージの)テキストを解析しなければならないからだ。テキスト通信はバイナリ通信に比べて処理が遅いので,利用者が増えた場合には影響が顕著に表れる。

 次に,可用性の問題が起きやすいのは,HTTPには特定のWebブラウザから送られてくる一連のリクエストを識別し,状態管理するといった仕組みがないことに関係する(この特徴を「ステートレス」と呼ぶ)。Webサーバーは,Webブラウザにレスポンスを返すと,「そのWebブラウザの利用者は誰だったか」「どんな処理をしていたか」などの情報をサーバー側には残さない。内容が逐次的に変わらないHTMLファイルなどを提供するだけであればそれでもかまわないが,ユーザー認証やページ遷移などを伴う複雑な業務アプリケーションを実装するには,それでは困る。

 そこでWebシステムでは,HTTPのリクエストに「セッションID」と呼ばれる識別子を付加し,以前にリクエストを送信したWebブラウザであることをサーバー側のアプリケーションで見分け,さらに保持していたユーザー情報や以前の処理内容など(=セッション情報)とひも付けるという仕組みを実装しなければならない。

 この仕組みが「セッション管理」であり,Webシステムでは設計上の重要な検討ポイントとなる。もし,セッション管理の設計に不備があると,Webシステムのサービスが停止してしまったり,ほかの利用者の情報を取り違えて情報漏洩を招いたりするなどのトラブルが発生する。一般にセッション管理にはAPコンテナの機能を用いる。セッション情報の格納方法(APサーバーのメモリー上かDBサーバーのディスク上かなど)は設計者が選定しなければならない。

 パフォーマンスと可用性の問題を引き起こさないように,Webシステムのアーキテクチャを考える必要がある。基本は,同じ機能を提供する複数のサーバー機を配置し,それぞれの間で整合性を取ることだ(図2中央~右)。ここで言う「整合性」とは,各サーバー機で保持するデータと,サーバー機に対する処理の振り分け方(負荷分散の方法)を,論理的に一貫させることを意味する。これに成功すれば,すべてのサーバー機が同時に障害を起こさない限りサービス停止は防げるし,システムの処理量(キャパシティ)が増える分だけパフォーマンスも向上する。

高安 厚思(たかやす あつし) オープンストリーム テクニカルコンピテンシーユニット 主管システムズアーキテクト
銀行系シンクタンクでオブジェクト指向技術の研究に携わった後,大手SI業者でアーキテクチャ構築やプロセス研究を担当。現職ではSOA(Service Oriented Architecture)を中心とする研究開発とアーキテクチャ構築に従事している