test

Sun Java Enterprise System 2005Q4 配備計画ガイド

サービス品質要件

サービス品質 (QoS) 要件は、パフォーマンス、可用性、スケーラビリティーなどについてシステム品質を特定する技術仕様です。QoS 要件は、ビジネス要件で指定されたビジネスニーズによって導き出されます。たとえば、サービスが 24 時間 365 日利用可能であることが必要とされる場合、可用性要件でこのビジネス要件に対応する必要があります。

次の表は、一般的に QoS 要件の基礎となるシステム品質を示しています。

表 3–2 QoS 要件に影響するシステム品質

システム品質 

説明 

パフォーマンス 

ユーザー負荷状況に対応する応答時間とスループット。 

可用性 

エンドユーザーがシステムのリソースとサービスにアクセスできる頻度。 通常は、システムの稼働時間として表されます。

スケーラビリティー 

時間の経過とともに、配備されるシステムに容量 (およびユーザー) を追加する能力。通常、スケーラビリティーにはシステムへのリソースの追加が関連しますが、配備アーキテクチャーの変更は含まれません。 

セキュリティー 

システムとユーザーの整合性を説明する、要因の複雑な組み合わせ。セキュリティーには、ユーザーの認証と承認、データの安全性、配備されたシステムへのセキュリティー保護されたアクセスなどが含まれます。 

潜在処理能力 

例外的なピーク負荷が生じた場合に、追加リソースなしでシステムがそれを処理する能力。潜在処理能力は、可用性、パフォーマンス、およびスケーラビリティーの要因です。 

保守性 

システムの監視、発生した問題の解決、ハードウェアおよびソフトウェアコンポーネントのアップグレードなどを含めた、配備されたシステムの保守の容易さ。 

各システム品質は、密接に関連しています。あるシステム品質の必要性が、その他のシステム品質の必要性と設計に影響することがあります。たとえば、セキュリティーのレベルを高めることは、パフォーマンスに影響し、それが可用性に影響する可能性があります。可用性の問題を解決するためにサーバーを追加導入することは、保守性 (保守コスト) に影響します。

ビジネス要件とビジネス上の制約の両方を適切に満たすシステムを設計する鍵は、システム品質がどのように連携するかを把握し、得失評価が必要であることを理解することにあります。

以降の各節では、配備設計に影響するシステム品質を詳細に説明し、QoS 要件を具体化する上で考慮すべき要因についてガイドラインを示します。サービスレベル要件についての節もあります。 この要件は、サービスレベル契約の基礎となります。

パフォーマンス

通常、ビジネス要件では、技術用語を用いずに応答時間を指定することでパフォーマンスを表します。たとえば、Web ベースのアクセスに関するビジネス要件は、次のように指定されます。

ユーザーは、ログイン時に妥当な応答時間、通常は 4 秒以内を想定している。

このビジネス要件に基づき、すべてのユースケースを調べ、この要件をシステムレベルで表す方法を決定します。場合によっては、使用パターン分析で特定したユーザーの負荷状況を含める必要があります。各ユースケースのパフォーマンス要件は、特定の負荷状況における応答時間、または応答時間とスループットの併記で表します。また、許容可能なエラー数も指定します。

次に、パフォーマンス上のシステム要件を指定する例を 2 つ示します。

パフォーマンス要件は、可用性要件 (フェイルオーバーがパフォーマンスにどの程度影響するか) および潜在処理能力 (例外的なピーク負荷の処理に使用できる能力がどの程度あるか) に密接に関連します。

可用性

可用性は、システムの稼働時間を特定する基準で、通常はユーザーがシステムにアクセス可能な時間の割合で測定されます。システムにアクセスできなくなる時間 (停止時間) は、ハードウェア、ソフトウェア、ネットワークの障害、またはシステムをダウンさせるその他の要因 (停電など) によって生じます。サービスの予定された停止時間 (保守およびアップグレード) は、停止時間とみなしません。稼働時間の割合でシステムの可用性を計算する基本的な方程式は、次のとおりです。

可用性 = 稼働時間 / (稼働時間 + 停止時間) * 100%

一般に、可用性は達成できる「ナイン」の数で表現されます。たとえば、99% の可用性であれば、2 ナインとなります。ナインの追加は、配備設計に大きく影響します。次の表では、24 時間 365 日、つまり合計 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、メモリ、ネットワークデバイスなど) とソフトウェアの両方に冗長性を持たせることで実現されます。

シングルポイント障害は、クリティカルパスの一部でありながら冗長コンポーネントによってバックアップされていないハードウェアまたはソフトウェアコンポーネントです。このコンポーネントで障害が発生した場合、システムはサービスを提供できなくなります。耐障害システムを設計するときは、潜在的なシングルポイント障害を特定し、それを取り除きます。

耐障害システムの実装と維持は、高額になる可能性があります。可用性に関するビジネス要件の本質を理解し、それらの要件に見合った可用性ソリューションの戦略とコストを考慮する必要があります。

サービスの可用性の優先順位付け

ユーザー側から見ると、多くの場合、システム全体の可用性よりも、サービス単位の可用性のほうが重要です。たとえば、インスタントメッセージングサービスが利用できなくなっても、通常、その他のサービスの可用性には影響がまったくないか、あってもごく軽微なものです。しかし、その他のサービスの多くが依存するサービス (Directory Server など) が利用できなくなると、はるかに広範な影響をもたらします。高い可用性の仕様には、可用性の向上を必要とするユースケースと使用パターン分析が明確に参照されている必要があります。

可用性の必要性を優先度の順にリストしておくと便利です。次の表は、各種サービスの可用性の優先順位を示しています。

表 3–4 優先度順のサービスの可用性

優先順位 

サービスの種類 

説明 

1 

ミッションクリティカル 

常時使用可能である必要のあるサービス。たとえば、アプリケーションに対するデータベースサービス (LDAP ディレクトリなど) です。 

2 

使用可能である必要あり 

使用可能である必要はあるが、パフォーマンスが低下しても問題はないサービス。たとえば、ビジネス環境によっては、メッセージングサービスの可用性は重要視されない場合があります。 

3 

延期可能 

特定期間内に使用可能であることが必要となるサービス。たとえば、ビジネス環境によっては、カレンダサービスの可用性は重要視されない場合があります。 

4 

省略可能 

恒久的に延期しても問題のないサービス。たとえば、ビジネス環境によっては、インスタントメッセージングサービスは有用ではあっても必要ではないと考えられる場合があります。 

サービスの損失

可用性設計では、可用性が低下した場合や、コンポーネントが失われた場合の状況も考慮します。これには、接続していたユーザーがセッションを再起動する必要があるかどうか、また 1 つの領域で発生した障害がシステムのほかの領域にどのような影響を与えるかについて考慮することも含まれます。QoS 要件には、これらのシナリオが考慮されていて、配備によるこれらの状況への対処が示されている必要があります。

スケーラビリティー

スケーラビリティーは、既存のユーザーまたは増大したユーザーベースからの追加負荷にシステムが対応できるように、システムに容量を追加する能力です。通常、スケーラビリティーは追加リソースを必要としますが、配備アーキテクチャーの設計変更や、追加リソースの追加に要する時間によるサービスの喪失は考慮の対象となりません。

可用性と同様に、スケーラビリティーはシステム全体よりも、システムが提供する各サービスで重要視されます。ただし、他のサービスが依存する Directory Server のようなサービスのスケーラビリティーは、システム全体に影響する可能性があります。

配備の成長の予定がビジネス要件に明確に示されていない限り、スケーラビリティー要件を QoS 要件として指定する必要は必ずしもありません。ただし、ソリューションライフサイクルの配備設計フェーズでは、システムのスケーラビリティーを確保するために何らかの許容範囲を配備アーキテクチャーに必ず追加する必要があります。 これは、スケーラビリティーについての QoS 要件が指定されていない場合にも当てはまります。

成長予測

スケーラビリティー要件を決定するためのシステムの成長予測には、実行できない可能性のある予測、見積もり、推測なども含まれます。スケーラブルなシステムの要件を決定する際の鍵は、次の 3 つです。

次の表は、スケーラビリティー要件を決定する上で考慮が必要な要因を示しています。

表 3–5 スケーラビリティー要因

項目 

説明 

使用パターンの分析 

既存のデータを分析し、現在の (または予定される) ユーザーベースの使用パターンを把握します。現在のデータを利用できない場合は、業界のデータまたは市場予測を分析します。 

妥当な最大スケールの設計 

既知の需要と潜在的な需要の両方について、必要となる最大スケールの目標を設定します。 

多くの場合、これは既存のユーザー負荷のパフォーマンス予想と、将来の負荷に関する妥当な予想に基づく、24 か月間の見積もりです。見積もりの対象期間は、予想の信頼性によって大きく異なります。 

適切な達成目標の設定 

配備設計を段階的に実装することで、予期せぬ成長に対応するための短期要件を満たすことができます。システムリソースの追加に関する達成目標を設定します。 

例: 

  • 予算獲得 (四半期ベース、年次ベースなど)

  • ハードウェアおよびソフトウェアを購入する際のリードタイム (1 〜 6 週間など)

  • バッファー (成長予測に応じて 10 〜 100%)

新興技術の採用 

より高速なプロセッサや Web サーバーなどの新しい技術について知り、これらの新しい技術が、基本となるアーキテクチャーのパフォーマンスにどの程度影響するかを把握します。 

セキュリティー要件

セキュリティーは、配備されたシステムの全レベルが関わる複雑な事項です。セキュリティー要件の作成は、セキュリティー脅威の特定およびそれらに対抗する戦略の策定を中心に進めます。このセキュリティー分析には、次のステップがあります。

  1. 重大な資産の特定

  2. それらの資産に対する脅威の特定

  3. 組織にリスクをもたらす脅威を顕在化する脆弱性の特定

  4. 組織に対するリスクを低減するセキュリティー計画の作成

セキュリティー要件の分析には、管理職、ビジネスアナリスト、情報技術担当者など、組織の幅広い利害関係者が関与する必要があります。多くの場合、セキュリティー設計者がセキュリティー対策の設計と実装におけるリーダーに指名されます。

次の節では、セキュリティー計画の対象となる領域の一部を説明します。

セキュリティー計画の要素

システムのセキュリティーを計画することは、配備設計の一部で、実装の成功に不可欠な部分です。セキュリティーを計画する際は、次の要素を考慮します。

潜在処理能力

潜在処理能力は、使用状況に例外的なピーク負荷が生じた場合に、追加リソースなしで配備がそれを処理する能力です。通常は、潜在処理能力について QoS 要件を直接指定することはありませんが、このシステム品質は、システムの可用性、パフォーマンス、スケーラビリティーの要因となります。

保守性要件

保守性は、システムの監視、発生した問題の解決、システムに対するユーザーの追加および削除、ハードウェアおよびソフトウェアコンポーネントのアップグレードなどのタスクを含め、配備されたシステムの保守の容易さを意味します。

保守性の要件を計画するときは、次の表に示される事項を考慮します。

表 3–6 保守性要件について考慮すべき事項

項目 

説明 

停止時間の計画 

特定のサービスが利用できなくなる、または部分的に利用できなくなる保守作業を特定します。 

ユーザーに対してシームレスに行われる保守とアップグレードもありますが、サービスの中断を必要とするものもあります。ユーザーが事前に停止時間に備えることができるように、可能であれば、停止時間を必要とする保守作業についてユーザーと共同で予定を立てます。 

使用パターン 

使用パターンを特定して、保守を予定するのに最も適した時間帯を決定します。 

たとえば、通常のピーク利用が一般的な業務時間帯であるシステムの場合、夜または週末に保守を予定します。地理的に分散したシステムの場合、この時間帯の特定はより困難になります。 

可用性 

多くの場合、可用性の設計は保守性に反映されます。保守とアップグレードのための停止時間を最小化する戦略は、可用性戦略を中心に展開されます。高度な可用性を必要とするシステムでは、保守、アップグレード、修復のための機会は限られています。 

可用性要件に対処するための戦略は、保守やアップグレードの処理に影響します。たとえば、地理的に分散したシステムでは、サービスの可用性は、保守期間中のリモートサーバーへの作業負荷のルーティング機能に依存します。 

また、高度な可用性を必要とするシステムは、人的な介入をほとんど必要とせずに、システムを自動的に再起動する、より洗練されたソリューションを必要とします。 

診断と監視 

診断ツールと監視ツールを定期的に実行して問題領域を特定することで、システムの安定性を向上できます。 

定期的なシステムの監視により、発生前に問題を回避したり、可用性戦略に基づく作業負荷のバランスに役立てたりすることができます。 また、保守と停止時間の計画も改善されます。