Webアプリ構築で、まず考えるべきアーキテクチャの検討ポイント（基礎編）：徹底解説！ ITアーキテクトとは何か？（2）（1/4 ページ）

ITアーキテクトの役割を、具体的かつ分かりやすくふ分けして解説する本連載。今回はアプリケーションアーキテクチャ設計の勘所を紹介する。

» 2014年05月12日 20時00分公開

[熊谷宏樹，TIS株式会社]

ユーザーの要求をアーキテクチャに落とし込む方法とは？

　前回は、アーキテクトの役割とタスクについて解説しました。今回からは、アーキテクチャ設計の話に入っていきたいと思います。アーキテクチャ設計の最初の段階で重要なのは、エンドユーザー／ユーザー企業の要求を見極めて、それをアーキテクチャに落とし込むことです。システムを設計する上で、ベストオブブリードでシステムを構成できる現在のようなオープンな環境の中では、さまざまな選択肢が存在します。その選択肢から選ぶ際に優先されるのは、「ユーザー要求」だということです。

　例えば、顧客が「リアルタイムな情報反映と、その活用」を望んでいるにもかかわらず、バッチ処理中心型のシステムを設計・構築することは、エンドユーザー／ユーザー企業の要望を無視したものであると言わざるを得ません。顧客の要求を第一とし、選択したアーキテクチャにおいて、調整および確認すべき事項について、提案型でエンドユーザー／ユーザー企業に確認を取っていくことが重要です。要件を実装するためのコンポーネントを選択したとしても、それで全てが決まるわけではなく、“検討・設計すべき余地”というものが存在しているからです。

　そして検討・設計の際には、選択肢ごとのメリット・デメリットをエンドユーザー／ユーザー企業に伝えることが重要であり、システム開発に関わった利用者に「アーキテクチャの決定に参加をした」という意識を持ってもらう必要があります。

　ただし、今回はアーキテクチャ設計の第1回目ということもあり、まずは、Webアプリケーションの設計における基本的な事項を中心に話を進めたいと思います。

アーキテクチャ設計時の検討ポイント

　アプリケーションのアーキテクチャはさまざまですが、アーキテクチャ設計においては、「検討すべきポイント」があります。優秀なアーキテクトは、まさにこのような「ポイント」を押さえることができるため、システム開発を成功に導けるのだと思います。ということで、今回は「Webアプリケーション」を題材にして、アーキテクチャの検討ポイントを紹介していきます。

　Webアプリケーションを最も単純化して考えると、以下のようなボックスに収まります。要は、単純なHTTPのイン・アウトのシステムです。

図1　今回、題材とする「Webアプリケーションのアーキテクチャ」

　このボックスの中を、Java EEでのmulti-tierアーキテクチャで分割し、各層での検討ポイントを順に解説していきます。

ポイント1：コンポーネント間のメッセージ受け渡し方式

　まずは、このボックスの中を詳細化していきます。このボックスの中には、通常Webアプリケーションサーバーとデータベースサーバーが含まれます（今回は、問題を単純化するために、ファイアウォールやロードバランサーは省略しています）。この例のように2つのコンポーネントを、1つのボックスに入れた場合、アーキテクチャ設計上の関心事項（考慮点）が生じます。それは「二者の間において、どのようにメッセージのやりとりをするか？」です。

　同一メモリ空間内であれば、単なるメソッド（関数）呼び出しとなりますが、メモリ空間が異なれば、そういうわけにもいきません。検討すべきは、このメッセージのやりとりに関わる以下の4つです。

同期型で行われるのか？／非同期型で行われるのか？
コネクションの確立は事前に確立されているのか？／メッセージ受信時に新たに確立されるのか？
プロトコルは何か？
タイムアウトの設定は？

　「データベースとのやりとりなんて同期に決まっているじゃないか!?」と思われる読者もいらっしゃるかもしれませんが、最近では非同期型のものも存在しています。

図2　二者の間において、どのようにメッセージのやりとりをするか？

　では次に、この新たに登場したデータベース層に関連したアーキテクチャの検討ポイントについて、前述のメッセージのやりとりを考慮して考えた結果、以下のように判断としたとします。

同期型で行われるのか？／非同期型で行われるのか？→同期型
コネクションの確立は事前に張られているのか？／メッセージ受信時に新たに確立されるのか？→サーバー起動時に確立しプーリングする
プロトコルは何か？→JDBC
タイムアウトの設定は？→トランザクションの負荷量から設定する

　これに基づいて、2番目から解説していきます。

ポイント2：コネクションプーリング

　通常、データベースとのコネクションは、アプリケーションサーバーなどが提供している「コネクションプーリング」機能を使用するのがセオリーです。これは「レスポンス」を向上させるための工夫です。最初のコネクションの確立には、データベースサーバー側のリソース確保などの処理を伴うため、コストが掛かります。

　このようなコネクションプーリングの設定においては、さまざまなパラメーターが存在しています。これらについても、「ユーザー要求」を加味する必要があります。例えば、MAXプール数、MINプール数の設定は、ピーク性の高いシステムの場合、MAXプール数を大きく設定しておかないと、ピーク時の大量のリクエストを処理する際に、コネクションの空き待ちが発生してしまいます。加えて、MINプール数も、少な過ぎると足りないコネクションを確立する上で負荷が発生してしまいます。

　また、前述のタイムアウト値を設定する際には、必ず守るべきセオリーがあります。それは、システムの入り口からシステム内部に処理が移管されることに従って、タイムアウト値は小さくなるように設定しなければならないということです。これが守られないと、データベース側で一生懸命処理しても、既にタイムアウトしてしまって、結果を返す場所がないという事態が発生してしまいます。

　次に検討すべきは、データベースを使用する上でのアーキテクチャ設計上の考慮点です。キーワードとして「トランザクション」「排他制御」といった項目が挙げられます。

ポイント3：トランザクション

　Webアプリケーションは、ユーザーからのリクエストに従って、当該の機能を実行します。実行する機能において、複数のテーブルにアクセスすることはよくあります。このようなデータベースアクセスのアーキテクチャを考える上で、無視できない概念に、ACIDがあります。

参考リンク：【DB概論】DBMSに求められるもの（1）排他制御とACID属性（＠IT）

　ACIDとは、「トランザクション処理の信頼性を保証する上で、トランザクション処理に求められる特性」のことです（アーキテクチャを設計する者としては、ACIDの意味くらいはしっかりと理解しておきたいものです）。トランザクションとは、「複数のテーブルへのレコードの挿入や更新を、一つのまとまりのある単位にして取り扱う」というビジネス要求に答えるものとなります。

　ここで考えるべきは、この「トランザクションを実現するための方法を決める」ことです。ここにおいてもアーキテクチャの決定は以下の手順を踏むことになります。