連載 アプリケーション・アーキテクチャ設計入門 第5回（最終回）　物理配置および運用上の要求 日本ユニシス　猪股 健太郎 2004/02/14
Page1 Page2 Page3 Page4

運用上の要求

　ここでは、運用にかかわる非機能的な要求をアプリケーションに反映させるための設計方針をまとめる。これらはアプリケーションのポリシーにも影響するが、アプリケーション・ロジックの設計にも影響を及ぼす。

■スケーラビリティ

　アプリケーションのスケーラビリティは、負荷が増大したときでもパフォーマンスを一定レベルに維持する能力である。ユーザー数やデータ量、トランザクション数などが指標になる。

• 非同期な業務を利用する。非同期にすることでシステムの制御がユーザーに速やかに渡る。eコマース・サイトを例にすると、同期的な業務処理の場合は、ユーザーは注文処理を実行してから結果が出るまで待ち続けなければならない。業務処理を非同期にすれば、ユーザーは後から確認または失敗の通知をメールで受け取ることが可能になる。

• データは必要とされる場所でキャッシュする。それによってリモートのデータ通信を減らすことができる。

• 不必要な状態を維持しない。業務処理の状態をなくすことで、データの一貫性を保ち、複数サーバで負荷分散することが可能になる。

• リソースが競合しないようにする。排他的なリソースを使う際は可能な限り短い時間で済ませ、長い時間ロックが発生しないようにする。

• データやリソースや業務処理を分割する。例えば、データベースをパーティションに分割することで、データベース・サーバのスケーラビリティを高くすることができる。

■可用性

　可用性は、アプリケーションが要求にこたえることができる時間の割合で表される。どんなに頑強なアプリケーションでもときどき停止することはやむを得ないとされているが、予期しないシステム停止は可能な限り防止しなければならない。

• 単一障害点をなくす。1つのコンポーネントによってアプリケーション全体が利用不可能になるような設計は避ける。負荷分散やクラスタリングによりアプリケーションをハードウェア的にもソフトウェア的にも冗長化する。

• 「同時に起こる要求」を回避するために、キャッシュやキューを活用する。データベースが利用不可能になってもキャッシュが利用できればデータの参照は可能である。また、データソースやサービスが一時的に利用不可能になっても、要求をキューに入れておけば、すぐにクライアントに応答を返すことができる。

• 効果的なバックアップ計画を立てる。致命的な障害が発生してもシステムを速やかに復旧できるように、適切なタイミングでバックアップを取る。

• 厳密なテストとデバッグ。高い信頼性を実現するには、無限ループやメモリリークといったアプリケーションの停止につながりかねないバグを徹底して取り除く必要がある。

■保守性

　アプリケーションは、追跡しやすく、改修しやすいように設計されていなければならない。

• コードを統一的に構造化する。名前空間名や変数名、クラス名、定数の付け方、コメントの記述方法などのコーディング規約を定め、確実に従う。

• 頻繁に変更されるデータや振る舞いは局所化する。ロジックの変更をカプセル化し、変更がほかに影響を及ぼさないようにする。

• アプリケーション設定情報やプログラムのパラメータにメタデータを使う。データベース接続文字列のような設定情報はXML構成ファイルなどに保存し、動的な変更を容易にする。

• 拡張可能な型を使う。インターフェイスを定義して、「プラグイン」を追加できるような設計にする。

• インターフェイスの設計。メソッドやパラメータが共通の型に属するようにインターフェイスを設計し、コンポーネント間の依存関係を減らす。

■セキュリティ

　セキュリティに関する決定はセキュリティ・ポリシーに従う必要があるが、以下の事柄には常に従うべきである。

• リスクを見積もる。セキュリティ的に最もリスクが高いポイントを洗い出して効果的な対策をとる。例えば、クレジットカード番号をHTTPS通信により暗号化して受け渡ししていても、データベースに元の番号をそのまま保存している場合、悪意を持った従業員がカード番号を盗み出すことができてしまう。

• 最小特権の原則に従う。一般的に、処理を遂行するために必要となる権限は必要最小限にする。データを参照するだけのプログラムを管理者権限で動作させることは危険である。

• セキュリティ境界では常に認証する。すべての入り口で認証を行い、適切なアイデンティティを持たない場合は処理を実行しない。

• 非同期業務ではユーザー・コンテキストの位置付けに気を付ける。非同期な処理はユーザーの権限で実行されるとは限らない。

■運用性

　組織的な運用管理ポリシーがアプリケーションの運用を決定する。アプリケーションの状態をモニタする仕組みや、サービス・レベルが契約範囲内であることを確認する仕組みなどを設計しておく必要があるだろう。

■パフォーマンス

　パフォーマンスは、アプリケーションの構築後にチューニングを施すことで改善可能ではあるが、アーキテクチャを設計する段階でもパフォーマンスについては考慮しておくべきだ。アプリケーション開発のさまざまな局面で、以下のプロセスが役に立つだろう。

1. パフォーマンス要求の基準を定める。例えば、スループット、レスポンス・タイム、CPU使用率などである。

2. 負荷テストを実施し、パフォーマンスの正しい情報を得る。

3. テスト結果を分析する。

4. もしパフォーマンスが目標に満たなかったら、ボトルネックとなっている部分を特定し、改善する。

5. パフォーマンスが目標に達するまで、上記2.〜4.を繰り返す。

最後に

　5回に渡って「Application Architecture for .NET」の内容を解説してきた。連載第1回目で書いたように、このAAfNは設計における問題を広くカバーしている。この連載を読み、アプリケーション・アーキテクチャを多面的に定義していくことが重要であること、しかしそのためには要素技術に対する広い知識が必要となること、アプリケーション・アーキテクチャを定めるための簡単なチャートのようなものは存在しないことがお分かりいただけたのではないだろうか。

　またAAfNは、マイクロソフトが提供しているさまざまな要素技術をいかにして組み合わせるかに主眼が置かれていた。そして特に、マイクロソフトの製品が多く登場した。とはいえAAfNでの考え方は、インフラがマイクロソフト製品でなくとも参考にできる部分は多いはずである。

　連載第1回目でも紹介したが、ここでもう一度、関連するリンクを示しておく。「パターンとプラクティス（patterns and practices）」で公開されているガイドの一覧が、読者層に応じて分類されている。これらは、AAfNで取り上げた話題についてさらに詳細に論じたものである。どのようなドキュメントが公開されているか、そのタイトルだけでも一度ご覧いただきたい。それから、.NET Architecture Center（英語）で公開されている情報の一部は日本語に翻訳されているので、日本語で読みたい方はこちらも利用されるとよいだろう。

　なお、本連載では、要素技術については簡単な解説でとどめている。本文中で出てくる要素技術についてより詳しく知りたい方は、まずMSDNの技術情報を見ていただきたい。マイクロソフトはたくさんの詳細なドキュメントを日々公開しているので、きっと目的にかなう技術情報が見つかることと思う。

追加情報 （2004/02/13）

暫定版ながら「Application Architecture for .NET」の日本語訳が「.NETのアプリケーション アーキテクチャ : アプリケーションとサービスの設計」で公開されています。 （編集部）

　

INDEX
	[連載] アプリケーション・アーキテクチャ設計入門
	第5回（最終回）　物理配置および運用上の要求
	1．物理階層（ティア）の構成要素
	2．コンポーネントの物理配置計画とコンポーネント分散境界
	3．コンポーネントの配置パターン
	4．運用上の要求に対する設計方針

「アプリケーション・アーキテクチャ設計入門」

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