|
| |
| Sun Java Enterprise System 配備計画に関する白書 | |
第 3 章
技術要件この章では、技術要件の分析時に行われるプロセスと手順について、その一部を説明します。
技術要件の分析は、ビジネス分析フェーズで作成されたビジネス要件ドキュメントから開始されます。ビジネス要件に基づいて、次の手順を実行します。
使用のモデルケースは、設計フェーズでの論理アーキテクチャの設計の基本となります。論理アーキテクチャとシステム要件から、配備シナリオが形成されます。これは後に、配備設計フェーズの入力情報となります。
次の図は、技術要件フェーズと、ビジネス分析、論理設計、配備設計の各フェーズの関係を示しています。
図 3-1 技術要件フェーズと配備計画のその他のフェーズ
ビジネス分析と同様に、使用パターン分析、使用のモデルケース、システム要件を導く、技術要件分析のための公式は存在しません。技術要件分析では、ビジネス領域、ビジネス上の目的、基本となるシステム技術の理解が必要となります。
この章で説明する内容は、次のとおりです。
使用パターンの分析使用パターンの分析では、設計している配備を利用するさまざまなユーザーを識別し、それらのユーザーの使用パターンを特定します。収集した情報により、想定される負荷の状況が導かれ、後にパフォーマンス要件やその他のシステム要件の特定に使用されます。使用パターンの分析結果は、「使用のモデルケース」で説明する使用のモデルケースに重みを割り当てる上でも役立ちます。
使用パターンを分析するときは、できるだけ多く機会を設けてユーザーにインタビューし、使用パターンに関する既存のデータを収集する必要があります。また、従来のシステムの制作者や管理者にもインタビューします。次の表は、使用パターンの分析時に考慮すべき事項を示しています。
使用のモデルケース使用のモデルケースは、設計している配備とユーザーとの一般的な対話をモデル化し、エンドユーザーの観点から完全な操作フローを説明します。使用のすべてのモデルケースについて設計の優先順位を付けることで、想定される機能の提供に継続して注力できます。
使用の各モデルケースには、ユーザーの行動に関する量的な予想も含まれます。これは、後にパフォーマンス、可用性、その他のサービス品質を得るためのシステム要件の決定に利用されます。また、第 4 章「論理アーキテクチャの設計」で説明するように、モデルケースは論理アーキテクチャの設計の開始点となります。
多くの場合、使用のモデルケースには重みを割り当てます。最も重いモデルケースが、最も一般的なユーザータスクを表します。使用のモデルケースに重みをつけることは、システム要件の決定に役立ちます。
使用のモデルケースは、2 つのレベルで説明されます。
システム要件システム要件は、ビジネス分析によって明確化されたビジネス要件を満たすために、配備されるシステムが提供する必要のあるサービスの品質を説明します。システム要件は、通常は、使用パターンの分析と使用のモデルケースをビジネス要件に照らし合わせた上で特定されます。
次の表は、システム要件を決定する上でよく利用されるシステム品質を示しています。
配備設計に影響するシステム品質は、相互に連携しています。あるシステム品質の必要性が、その他のシステム品質の必要性と設計に影響することがあります。たとえば、セキュリティのレベルを高めることは、パフォーマンスに影響し、それが可用性に影響する可能性があります。可用性の問題を解決するためにサーバーを追加導入することは、メンテナンスコスト (利便性) に影響しかねません。
ビジネス要件とビジネス上の制約の両方を適切に満たすシステムを設計する鍵は、システム品質がどのように連携するかを把握し、得失評価が必要であることを理解することにあります。
次の各節では、配備設計に影響するシステム品質をさらに詳細に説明し、システム要件を具体化する上で考慮すべき事項のガイドラインを示します。また、サービスレベルアグリーメントの作成に使用されるシステム要件の特別セットである、サービスレベル要件についても説明します。
可用性
可用性は、配備されるシステムのアップ時間を指定する方法です。一般には、ユーザーがシステムにアクセスできる時間の割合で表されます。システムにアクセスできなくなる時間 (ダウン時間) は、ハードウェア、ソフトウェア、ネットワークの障害、またはシステムをダウンさせるその他の要因 (停電など) によって生じます。ほとんどの場合、サービス (メンテナンスやアップグレードなど) のために事前に予定される時間は、ダウン時間と見なされません。
一般に、可用性は達成できる「ナイン」の数で表現されます。たとえば、99% の可用性であれば、2 ナインとなります。ナインの追加は、配備の可用性の設計に大きく影響します。次の表は、1 年間無休で、つまり合計 8,760 時間稼動するシステムに、可用性のナインを追加した場合のダウン時間を示しています。
表 3-3 1 年間 (8,760 時間) 稼動するシステムのダウン時間
ナインの数
使用可能割合
ダウン時間
2
99%
88 時間
3
99.9%
9 時間
4
99.99%
45 分
5
99.999%
5 分
フォルトトレラントシステム
4 つまたは 5 つのナインが要求される可用性を実現するには、通常はフォルトトレラントなシステムが必要となります。フォルトトレラントシステムは、ハードウェアまたはソフトウェアに障害が発生した場合にも、継続してサービスを提供できる必要があります。一般に、耐障害性は、主要サービスを提供するハードウェア (CPU、メモリ、ネットワークデバイスなど) とソフトウェアの両方に冗長性を持たせることで実現されます。
障害シングルポイントは、冗長コンポーネントによってバックアップされていないハードウェアまたはソフトウェアコンポーネントです。このコンポーネントで障害が発生した場合、システムはサービスを提供できなくなります。フォルトトレラントシステムを設計するときは、潜在的な障害シングルポイントを特定し、それを取り除きます。
フォルトトレラントシステムの実装と維持は、高額になる可能性があります。可用性に関するビジネス要件の本質を理解し、それらの要件に見合った可用性ソリューションの戦略とコストを考慮する必要があります。
Sun Cluster 3.1 4/04
Sun Cluster 3.1 4/04 ソフトウェアは、高い可用性を必要とするフォルトトレラントシステムの配備に高可用性ソリューションを提供します。Sun Cluster 3.1 4/04 は、サーバー、ストレージ、その他のネットワークリソースを結合することで、迅速に実行され、システムのユーザーにサービスの中断をほとんど感じさせないフェイルオーバープロセスを提供します。
サービスの可用性の優先順位
ユーザー側から見ると、多くの場合、システム全体の可用性よりも、配備されるシステムが提供する各サービスの可用性のほうが重要です。たとえば、通常はインスタントメッセージングサービスが利用できなくなっても、その他のサービスの可用性に与える影響はほとんど、またはまったくありません。しかし、その他のサービスの多くが依存するサービス (Directory Server など) の可用性は、システムに広範な影響をもたらします。
可用性の必要性を優先度の順にリストしておくと便利です。次の表は、各種サービスの可用性の優先順位を示しています。
可用性要件を実装する各種設計戦略については、「可用性のためのサイズ設定」を参照してください。
潜在処理能力
潜在能力は、使用状況に例外的なピーク負荷が生じた場合に、追加リソースなしで配備がそれを処理する能力です。通常は、潜在能力についてシステム要件を直接指定することはありませんが、このシステム品質は、可用性、パフォーマンス、スケーラビリティの要件を決定する要因となります。
パフォーマンス
パフォーマンス要件を特定するプロセスは、ビジネス要件が必要とするパフォーマンスをシステム要件に置き換えるプロセスです。多くの場合、ビジネス要件は技術用語を使用せずに応答時間を表現することで、パフォーマンスを指定します。たとえば、Web ベースのアクセスに関するビジネス要件は、次のように指定されます。
このビジネス要件に基づき、使用のすべてのモデルケースを調べ、この要件をシステムレベルで表現する方法を決定します。使用パターンの分析で特定される、ユーザーの負荷状況も考慮する必要があります。各モデルケースのパフォーマンス要件は、特定の負荷状況における応答時間、または応答時間とスループットの併記で表します。また、許容可能なエラー数も指定します。
次に、パフォーマンス上のシステム要件を指定する例を示します。
パフォーマンス要件は、可用性要件 (フェイルオーバーがパフォーマンスにどの程度影響するか) および潜在能力 (例外的なピーク負荷をどの程度処理できる能力があるか) に密接に関連します。
スケーラビリティ
スケーラビリティは、時間の経過とともに、システムに容量 (およびユーザー) を追加する能力を説明します。通常、スケーラビリティは追加リソースを必要としますが、配備アーキテクチャの設計変更や、追加リソースの追加に要する時間によるサービスの喪失は考慮の対象となりません。
可用性と同様に、スケーラビリティはシステム全体よりも、システムが提供する各サービスで重要視されます。ただし、他のサービスが依存する Directory Server のようなサービスのスケーラビリティは、システム全体に影響する可能性があります。
配備の成長の予定がビジネス要件に明確に示されていない限り、スケーラビリティ要件をシステム要件として指定する必要はありません。配備設計フェーズでは、スケーラビリティ要件を指定しない場合でも、システムの規模拡大を考慮して配備のアーキテクチャを決定する必要があります。
スケーラビリティ要件の決定に適用できる公式はありません。システムの成長予測には、予測し切れない要素も関連します。次に、スケーラブルなシステムを構築する上で重要となる 3 つの鍵を示します。
次の表は、スケーラビリティについて考慮が必要な事項を示しています。
セキュリティ要件
セキュリティは、ユーザーのトランザクションと関連データの整合性を含め、システムとユーザーの整合性に影響するシステム品質です。セキュリティ要件は、その他のシステム要件と同様に、ビジネス要件、使用パターンの分析、使用のモデルケースに基づいて分析されます。
セキュリティ要件の分析は、次の 4 つのカテゴリに分類されます。
認証、承認、アイデンティティ管理と、健全なセキュリティ対策の適用を強制する組織全体のポリシーが組み合わさることで、トランザクションと、サイトに格納されているデータの安全性を確保することができます。
注
通常、インフラストラクチャの完全性に影響するセキュリティ要件 (ファイアウォールソフトウェアやネットワーク設計など) は、システム要件の分析対象には含まれません。セキュリティ上のこれらの問題は、配備の設計時に取り上げられます。
認証
認証は、システムに対してユーザーがユーザー自身を識別する方法、およびユーザーに対してシステムがシステム自体を識別する方法です。認証は、不正なアクセスからシステムを保護するシステム完全性を実現するための重要な要素です。
配備に最適な認証方法を選択するには、ユーザー要件を理解する必要があります。たとえば、B to C (企業から顧客へ) の配備では、多くの場合、ユーザーがユーザー名とパスワードの組み合わせを使用して登録を行えます。これらのユーザーは、セキュリティ保護されたデータ転送を通じた販売システムの認証に、VeriSign などの信頼される認証局が発行するサーバー証明書を使用します。
B to E (企業から従業員へ) の配備では、代わりに従業員が既存のユーザーベースからプロビジョニングされます。企業のファイアウォール内からは、安全であることが確認されている場所へのアクセスが許可されます。ファイアウォールの外から安全な場所へのアクセスは、認証と企業ファイアウォール内へのリダイレクトを行うプロキシを経由します。
承認
承認は、認証されたユーザーに与えられる特定の権限を認識することです。たとえば、管理者として承認されたユーザーは、配備されたシステム上の、一般ユーザーがアクセスできない部分にもアクセスすることができます。
また、承認はシングルサインオン (SSO) を実装する配備で重要な役割を果たします。配備に対して認証されたユーザーは、何度もサインオンせずに複数のサービスにアクセスできます。
アイデンティティ管理
配備されるシステムには、システムサーバーにアクセスするユーザーを追加、修正、または削除する方法が必要です。必要に応じて、承認された管理者、または委任管理インタフェースを通じてユーザー自身がアイデンティティ管理を行えます。中規模または大規模な企業の配備では、委任管理の設計を考慮に入れる必要があります。委任管理により、顧客満足度を向上し、システム管理コストを削減できます。
利便性要件
利便性は、システムの監視、発生した問題の解決、ハードウェアおよびソフトウェアコンポーネントのアップグレードなどを含め、配備されたシステムの管理の容易さを意味します。
利便性の要件を計画するときは、次の表に示される事項を考慮します。
サービスレベル要件サービスレベル要件は、カスタマーサポートの提供が必要となる状況を指定する、システム要件のセットです。サービスレベル要件は、一般にプロジェクト承認時に署名される、サービスレベルアグリーメントの基本となります。
サービスレベル要件は、システム要件と同様にビジネス要件に基づいて特定され、配備が満たす必要のあるシステム全体の品質について顧客に何らかの保証を示します。サービスレベルアグリーメントは、担当者と顧客との間で交わされる契約であるため、サービスレベル要件の仕様に曖昧さは許されません。サービスレベル要件は、どのような条件のもとで要件がテストされるのかを具体的に定義し、何をもって要件の不適合とするかを厳密に定義する必要があります。
