|
| |
| Sun Java System Messaging Server 6 2004Q2 配備計画ガイド | |
第 2 章
要件の分析Messaging Server の配備を計画する場合は、最初に組織の業務および技術の要件を分析する必要があります。この章では、要件を収集し評価する方法と、それに基づいて構築する Messaging Server アーキテクチャーを決定する方法を説明します。
この章には、以下の節があります。
配備目標の確認Messaging Server ソフトウェアまたはハードウェアを購入したり配備したりする前に、配備の目標を確認しておく必要があります。組織内のさまざまなソースから、配備の要件があがってきます。多くの場合、要件はあいまいな言葉で表現されますが、それを特定の目標に向けた明確な定義に変える必要があります。
配備を計画する前に検討の必要がある要件には、以下のものがあります。
要件分析の結果は、明確で簡潔な言葉で定義し、配備による成果を評価できる目標としてまとめる必要があります。プロジェクト関係者からの同意を得た明確な目標がなければ、先に進んでも成功するのは困難です。
業務の要件
ビジネスの目標は、配備の決定に大きく影響します。具体的には、ユーザーの行動、サイトの配布、配備に影響を与える潜在的な政治的要因について理解しておく必要があります。これらのビジネス要件を理解していない場合は、誤った前提に基づいて的確な配備計画に悪影響をおよぼす結果を招きかねません。
運用の要件
直接的な目標を持った一連の機能上の要件として、運用要件を明確にします。通常、以下の項目が該当します。
たとえば、「適切なエンドユーザー応答時間」という表現を評価可能な用語に変換して、関係者全員が何が「適切」で応答時間がどのように評価されるかを理解できるようにします。
カルチャーとポリティクス
配備を考える場合、企業のカルチャーとポリティクスを考慮する必要があります。需要というものは、結局はビジネス要件そのものから生み出されてくるものです。
例:技術の要件
技術の要件 (または機能の要件) は、組織のシステムニーズの詳細です。
既存の利用率パターンのサポート
既存の利用率パターンを、配備実現のための明確で評価可能な目標として定義します。以下の質問が、目標を定義する際に参考となります。
サービスにアクセスするユーザーについて調査します。ユーザーはいつ既存のサービスを使うのかといった要素が、配備の要件、ひいては配備の目標を定める重要なポイントとなります。組織の今までの事例からこれらのパターンを得ることができない場合は、他の組織の事例を研究し、推測します。
利用率のきわめて高い部署では、専用のサーバーが必要になる場合もあります。一般に、ユーザーが実際のサーバーから遠く離れている場合、応答時間が長くなります。応答時間が適切であるかどうかを検討する必要があります。
サイトの分散
以下の質問を検討して、サイトの分散が配備目標に与える影響を理解します。
ネットワーク
以下の質問を検討することで、ネットワークの要件を理解します。
- 内部ネットワーク情報をわかりにくくしたいと考えるか。
- ネットワークサービスに冗長性を持たせたいと考えているか。
- レイヤーホストにアクセスする場合に、利用可能なデータを制限したいと考えているか。
- エンドユーザー設定を簡略化したいと考えていますか。たとえば、変更が不要なシングルメールホストにエンドユーザーを加入させるなどの方法があります。
- ネットワークの HTTP トラフィックを削減したいと考えていますか。
注
これらの質問にはいと答えた場合は、2 階層アーキテクチャを採用することが考えられます。詳細は、第 3 章「メッセージングアーキテクチャの開発」を参照してください。
既存のインフラストラクチャ
より信頼性の高い高可用性帯域幅が利用できる場合は、集中化サーバーを採用できます。
サポート要員
24時間、週に 7 日 (24 x 7) 体制のサポートは、特定のサイトでのみ提供されます。少数のサーバーによる簡単なアーキテクチャの場合は、サポートが容易です。
財務の要件
財務上の制約により、配備の構築がどの程度影響を受けますか。財務上の要件は全体的な視点から明確に定義される場合が多く、配備の限界や目標が明確になります。
ハードウェア、ソフトウェア、および保守のための明確なコスト以外に、次のような他のコストがプロジェクト全体に影響を与えます。
プロジェクトの要件に関連する数多くの要素を注意深く分析することで、プロジェクトに関連する財務上の問題を回避することができます。
サービスレベル契約 (SLA)
サービスレベル契約には、稼働時間、応答時間、メッセージ配信時間、および障害回復のような領域に関連する配備を盛り込む必要があります。サービスレベル契約自体には、システムの概要、サポート組織の役割と責任、応答時間、サービスレベルの評価方法、要求の変更などの項目が網羅されています。
サービスレベル契約の範囲を決定する際には、システムの可用性に対する組織の予測が重要なポイントとなります。システムの可用性は、システム稼働時間に対するパーセンテージで表されます。システムの可用性を表す公式は次のとおりです。
可用性 = 稼働時間 / (稼働時間 + 停止時間) * 100
たとえば、サービスレベル契約で稼働時間が 99.99 パーセントと規定されている場合、1 か月に許されるシステムが使用できない時間は、約 4 分間となります。
さらに、システムの停止時間とは、システムが使用できない時間の合計を意味します。この合計には、システム障害やネットワークの停止などの予期しない停止時間だけでなく、計画された停止時間、予防的保守、ソフトウェアのアップグレードやパッチを当てる時間なども含まれます。システムが 7x24 (週 7 日、24 時間) 稼働を前提としている場合、アーキテクチャに冗長性を持たせて計画された停止や予期しない停止に備え、高可用性を確保する必要があります。
プロジェクト目標の決定まず、調査と分析を行って、プロジェクトの必要要件を明確にする必要があります。次に、明確で評価可能な目標を決定します。プロジェクトに直接関与しない人員でも理解可能な形で目標を設定し、プロジェクトの評価方法も明確にしておきます。
関係者による目標の容認導入後の検証によりプロジェクトを評価し、その成果を決定する必要があります。
拡張に向けた計画現在要求されている許容量を決定するだけでなく、計画できる時間枠内で将来必要とされる能力も算出しておく必要があります。拡張のスケジュールは、通常 6 か月から 12 か月です。拡張の例外と利用率特性の変化を考慮して、拡張を検討する必要があります。
ユーザー数とメッセージの数の増加に対応して、容量計画のガイドラインを策定する必要があります。さまざまなサーバーのメッセージトラフィックの増大、ユーザー数の増加、メールボックスサイズの増大なども想定して計画を立てる必要があります。収容ユーザー数の増加に伴い、その間の利用率特性も変化します。配備目標 (そして配備設計) は、将来に向けても実現可能なように、状況に応じて対応できるものでなければなりません。
アーキテクチャが将来の拡張を容易に吸収できるよう設計しておくのが理想的です。稼働段階に入ったら、配備状態を監視して、配備ニーズがいつどのように増加しているかを認識することも重要です。
総所有コスト (TCO) の理解
総所有コスト (TCO) もまた、許容量の計画に影響を与える要素です。これには、Messaging Server の配備で選択するハードウェアが含まれます。以下の表で、数を多くした小規模なハードウェアシステム、または少数の大規模ハードウェアシステムのどちらを配備するかに関しての検討項目をまとめています。