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