連載 アプリケーション・アーキテクチャ・ガイド2.0解説 第2回 アプリケーション概要を定義するには？ 日本ユニシス　猪股 健太郎 2009/06/02
Page1 Page2 Page3

■アプリケーション概要を定義するには

　アプリケーション概要を定義するには、

1. 主要シナリオで想定している利用形態から、アプリケーション種別を決定する
2. アプリケーションを配置する際の要件や制約を洗い出し、それらがアーキテクチャに与える影響を検討する
3. 採用するアーキテクチャ・スタイルを選ぶ
4. 要素技術の候補を洗い出し、アプリケーション種別などから来る制約を考慮して採用する技術を決める

という4つのステップがあると説明したが、これらの内容をそれぞれ説明する。

●1. アプリケーション種別を決定する

　アプリケーション種別とは、第1回で述べたとおり、「アプリケーションを、その物理配置のパターンから分類したもの」である。この時点で決めるべきなのはあくまで概要であるので、次の5種から選べばよい。アプリケーションは種別に応じてメリットとデメリットが存在する。主要なシナリオを実現できるような種別を選ぶこと。

（1）モバイル・アプリケーション：
モバイル端末で実行するので、場所を問わずアプリケーションを利用できる。また、オフラインで実行するアプリケーションにすることもできる。半面、画面が狭く、入力方式に制約がある。

（2）クライアント・アプリケーション：
クライアントPCの資源を活用できる。応答性もよく、見栄えや快適さにこだわることもできる。半面、プラットフォームに依存し、アプリケーションの配布と更新にコストがかかることもある。

（3）Webアプリケーション：
複数プラットフォームをサポートでき、配布と更新が容易である。半面、ネットワークへの常時接続が必要で、UI（ユーザー・インターフェイス）の機能や操作性を豊かにすることが難しい。

（4）RIA（リッチ・インターネット・アプリケーション）：
クライアント・アプリケーションと同程度のUIを提供できるうえ、配布と更新が容易である。半面、クライアント・アプリケーションと比べるとクライアントPCの資源を自由には使えないにもかかわらず、Webアプリケーションと比べると、クライアントPCに高い処理能力が必要である。また、ブラウザ・プラグインを必要とするなど、実行環境に一定の制約がある。

（5）サービス：
クライアントとサーバを疎結合にでき、相互運用性が高い。半面、UIの開発支援はまったくない。また、ネットワークへの常時接続が必要となる。

●2. 配置シナリオを検討する

　アーキテクチャを決定する際、企業のIT運用管理規定やITインフラを考慮しなければならない。セキュリティ・ポリシーや運用要件といった制約や要件は後から覆せるようなものではないので、設計プロセスの早い段階で明確化し、それに沿った配置シナリオを決定しなければならない。

　ここでは、アプリケーションを分散させるかどうか、スケーラビリティを確保する手段、そしてパフォーマンスや信頼性やセキュリティにかかわる分散パターンについて説明する。

　最初に決めるべきなのは、サーバに配置するアプリケーションを物理的に分散させるかどうかだ。次の図は分散させない場合とさせる場合の比較図だ。

アプリケーションを物理的に分散させない場合とさせる場合の比較図

　分散させない：アプリケーションの論理構造は階層化したとしても、物理的なサーバは階層化しない。例えば、Webアプリケーションにおいて、データ・ストレージ以外の機能、つまりプレゼンテーション層、ビジネス層、データ・アクセス層をすべて1つのサーバに配置する場合がこれに当たる。

　この配置はサーバの数が少なくなるため管理しやすく、レスポンス・タイムも良好である。半面、ビジネス・ロジックをほかのアプリケーションと共有させるのが難しかったり、各層の間でサーバ・リソースの競合が起きる恐れがあったりする。

　分散させる：アプリケーションの論理階層を物理的に複数のサーバに配置する。例えば、Webアプリケーションにおいて、プレゼンテーション層をWebサーバに、ビジネス層とデータ・アクセス層をAPサーバ（＝アプリケーション・サーバ）に配置する場合がこれに当たる。WebサーバとAPサーバの間にファイアウォールを設置することができたり、ビジネス層だけをスケールアウトさせることができたりするなど、自由度が高い。半面、アプリケーション内部にネットワーク呼び出しが含まれるため、オーバーヘッドが大きくなる。また、管理コストも大きくなる。

　特別な要件がないのであれば、単純であるという理由だけでも分散させない戦略を取る価値がある。あえて分散させるのであれば、以下の点に注意するとよい。

• パフォーマンスがなるべく悪化しないような通信経路やプロトコルを選ぶ
• OSやミドルウェアの機能を利用して設計を単純にする
• 呼び出し回数が少なくなるような、大きな粒度のインターフェイスにする
• 長い間実行されるビジネス・プロセスを別サーバに分離する
• フェイルオーバー戦略を決定しておく
• 非同期呼び出しやメッセージ・キューなどを検討する
• リソース増強の戦略を決定しておく

　次に、スケーラビリティを確保する手段を検討する。すなわち、スケールアップにするか、スケールアウトにするかを決定するのである。

　スケールアップは、CPUやメモリといったリソースを増強することで1台あたりのサーバの能力を上げる手段のことであり、スケールアウトは、サーバの台数を増やすことでシステム全体の能力を上げる手段のことである。また、スケールアウトはサーバを多重化することにつながるので、システムの可用性を改善できるというメリットもある。

　一般的に、スケールアップの方が容易であり、管理コストも抑えられる。しかし、スケールアップによる性能向上は限度があるので、より大規模なシステムではスケールアウト戦略を取った方がよい場合もある。

　ただし、スケールアウトしやすい設計と、しにくい設計というものがあるので、設計する時点で意識しておく必要がある。スケールアウトしやすい設計とは、

• ステートレス（＝状態を持たない）なコンポーネント
• 読み出し専用のデータ。データベースを複製して分割できる
• 特定のユーザーまたはセッションだけに関係するデータ。パーティショニングにより分割できる

などである。

　最後に、分散配置のパターンのうち代表的なものを紹介する。アプリケーションの品質属性と照らし合わせてパターンを選択するとよい。

○パフォーマンスに関する分散パターン: Webファーム

パフォーマンスに関する分散パターン: Webファーム

　同じアプリケーションが動作するWebサーバを並列に並べるパターンである。Webサーバに対する要求を分配する方法については特に規定しない。

○パフォーマンスに関する分散パターン: 負荷分散クラスタ

パフォーマンスに関する分散パターン: 負荷分散クラスタ

　APサーバに対する要求を1つの機器（負荷分散装置と呼ばれる）が受け取り、各APサーバに分配する。通常は、APサーバの負荷が均等になるように分配される。負荷分散のロジックによっては、APサーバで動作するアプリケーションがすべて同じものとは限らない。

○信頼性に関する分散パターン: フェイルオーバー・クラスタ

信頼性に関する分散パターン: フェイルオーバー・クラスタ

　あるサーバが利用できなくなったとき、自動的に別のサーバが処理を続ける。

○セキュリティに関する分散パターン: 偽装／委任

セキュリティに関する分散パターン: 偽装／委任

　ある処理を実行する際のセキュリティ・アカウントが、その処理で利用するリソースにアクセスするときのセキュリティ・アカウントと一致する。上の例では、Web/APサーバでの認証情報を使って、DBサーバにアクセスしている様子を示している。

○セキュリティに関する分散パターン: 信頼されたサービス

セキュリティに関する分散パターン: 信頼されたサービス

　ある処理を実行する際のロールに応じてサービス・アカウントが割り当てられ、そのアカウントでリソースにアクセスする。上の例では、DBサーバはWeb/APサーバの認証・承認機構を信頼している。

　続いては、アプリケーション概要を定義する3つ目のステップだ。

INDEX
	連載：アプリケーション・アーキテクチャ・ガイド2.0解説
	第2回 アプリケーション概要を定義するには？
	1．アーキテクチャ設計とは
	2．アプリケーション種別を決定する／配置シナリオを検討する
	3．アーキテクチャ・スタイルを選ぶ／採用する技術を決める

「アプリケーション・アーキテクチャ・ガイド2.0解説」

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