|
| |
| Sun Java System Calendar Server 6 2004Q2 配備計画ガイド | |
第 2 章
要件の分析Calendar Server 配備を計画するには、最初に組織のビジネス要件と技術要件を分析する必要があります。この章では、Calendar Server アーキテクチャを決定するための、要件の収集および評価について説明します。
この章で説明する内容は次のとおりです。
配備目標の特定Calendar Server ソフトウェアまたはハードウェアを購入または配備する前に、配備目標を特定しておく必要があります。配備要件は組織内のさまざまな部門から出される場合があります。要件は漠然とした言葉で表現されることが多いため、特定の目標を決定するために、明確なものにする必要があります。
要件分析の結果は、配備の成功を判断できるような、明快かつ簡潔で、計測可能な目標にならなければなりません。プロジェクトのすべての利害関係者が了承する明確な目標を設定しないでプロジェクトを進めることは、避けるべきです。
要件の中には、次のように配備を計画する前に調査が必要なものもあります。
ビジネス要件
ビジネスの目標は配備の各決定に影響します。具体的には、ユーザーの使用パターン、サイトの分散、および場合によっては配備に影響する、起こりうる政策上の問題を理解する必要があります。このようなビジネス要件を理解していない場合、容易に誤った前提に陥る可能性があり、それは配備設計の正確さに影響します。
運用要件
運用要件を単純明快な目標のある一連の機能要件として表現してください。通常、次についての非公式な仕様を目にすることがあります。
たとえば、「適切なエンドユーザーの応答時間」の要件を、すべての利害関係者が、何が「適切」で、どのように応答時間が計測されるかを理解できるような計測可能な用語に変換します。
企業文化と社内力学
配備には企業文化と社内力学を考慮に入れる必要があります。ある領域から要求が出され、結果的にビジネス要件になる場合があります。たとえば、次のようなものがあります。
技術要件
技術要件 (機能要件) は組織のシステムニーズの詳細です。
既存の使用パターンのサポート
既存の使用パターンを、配備を実現させるための明確で計測可能な目標で表現してください。次の質問はそのような目標を決定するのに役立ちます。
サービスにアクセスするユーザーを調査してください。ユーザーが既存のサービスをいつ使用するかなどの要因が配備要件、つまり目標を特定するための鍵です。自分の組織の経験からはこのようなパターンを見出すことができない場合、他の組織の経験を調査し、自分の組織について見積もってみてください。
組織の使用率が非常に高い地域では専用のサーバーが必要な場合もあります。一般的に、ユーザーが実際のサーバーから離れている場合、応答時間が遅くなります。応答時間が許容可能かどうかを考慮してください。
サイトの分散
次の質問を使用し、サイトの分散がどのように配備目標に影響するかを認識してください。
ネットワーク
次の質問はネットワーク要件を理解するのに役立ちます。
既存のインフラストラクチャ
より信頼できる、高帯域幅を持つ場合、サーバーの集中化が可能なことがあります。
従業員のサポート
24 時間、1 週間毎日 (24 × 7) のサポートが利用可能なのは特定のサイトだけに限られる場合があります。少数のサーバーを使った簡単なアーキテクチャの場合、サポートも容易になります。
財務要件
財務上の制約は配備を構築する方法に影響します。財務要件は、配備の制約または目標が定められる全体的な考え方で明確に定義される傾向にあります。
ハードウェア、ソフトウェア、保守などの明確なコスト以外に、次のような他のいくつかのコストがプロジェクト全体のコストに影響する可能性があります。
プロジェクト要件に関連付けられた多くの要因に対して、慎重に、十分な分析を行うことによって、そのプロジェクトに関連付けられた財務上の問題を回避できます。
サービスレベル契約 (SLA)
稼働時間、応答時間、メッセージ配信時間、および障害回復に関する配備について SLA を作成する必要があります。SLA 自体は、システムの概要、サポート組織の役割と責任、応答時間、サービスレベルの計測方法、変更要求などの項目を詳細に記述したものである必要があります。
システムの可用性に対する組織の期待を特定することが、SLA の範囲を決定する鍵です。システムの可用性は、通常、システム稼動時間のパーセントで表現されます。システムの可用性を算定する基本的な計算式は次のとおりです。
可用性 = 稼働時間 / (稼働時間 + 停止時間) * 100
たとえば、サービスレベル契約で、9999 (99.99パーセント) の稼働時間ということは、1 か月のうちにシステムの使用不可能が許容されるのが 4 分程度であることを意味しています。
さらに、システムの停止時間とはシステムが使用不可能な合計時間です。この合計には、ハードウェアの故障やネットワークの障害などの突発的な停止時間だけではなく、予防保守、ソフトウェアのアップグレード、パッチなどの計画的な停止時間も含まれます。システムを 7x24 (1 週間毎日、1 日 24 時間) 使用可能なものとする場合、計画的および突発的な停止時間を回避し、高可用性を確保するために、アーキテクチャに冗長性を含める必要があります。
プロジェクト目標の決定調査と分析を行ってプロジェクト要件を明らかにする必要があります。次に、明確な一連の目標を決定できる必要があります。目標およびその目標に照らしたプロジェクトの評価方法を、プロジェクトに直接関与しない従業員が理解できるような形で、これらの目標を指定してください。
プロジェクト目標は、すべての利害関係者によって承認される必要があります。プロジェクト目標は、プロジェクトの成功を見きわめるために、実装後の検査で計測される必要があります。
拡張計画現在必要な容量を決定することに加えて、将来、計画可能な期間内にどの程度の容量が必要かを査定してください。通常、拡張のスケジュールは 6 か月から 12 か月の範囲のものです。拡張の見込みと使用特性の変更は、拡張に対応するため考慮に入れる必要があります。
ユーザーとメッセージの数が増大するにつれ、容量計画の正しいガイドラインの概要をまとめる必要があります。さまざまなサーバーのメッセージトラフィックの増大、ユーザー数の増大、メールボックスサイズの拡張などについて計画する必要があります。ユーザー数の増大とともに、使用特性は変わります。配備目標 (配備設計) は、将来の発展性に対応している必要があります。
理想的には、将来の拡張に容易に対応するアーキテクチャを設計する必要があります。本稼動フェーズでは、配備の拡張がいつどの程度必要になるかを理解するために、配備の監視も重要になります。
総所有コストの理解
容量計画に影響するもう 1 つの要因としては、総所有コスト (TCO) が挙げられます。これには Calendar Server を配備するハードウェアの選択が含まれます。表 2-1 では、小規模のハードウェアシステムを配備するか、または少数の規模の大きいハードウェアシステムを配備するかのいずれかについて考慮すべきいくつかの要因を示しています。