ソリューションライフサイクルの技術要件フェーズでは、使用パターンの分析を行い、ユースケースを特定し、提案する配備ソリューションのサービス品質要件を決定します。
この章で説明する内容は、次のとおりです。
技術要件の分析は、ソリューションライフサイクルのビジネス分析フェーズで作成されたビジネス要件ドキュメントに基づいて行います。ビジネス分析に基づいて、次の手順を実行します。
想定される負荷状況を特定するために、使用パターンを分析します。
システムに対するユーザー操作のモデルとなるユースケースを作成します。
配備されたソリューションに必要とされる、応答時間、可用性、セキュリティーなどの領域におけるパフォーマンスを定義する一連のサービス品質 (QoS) 要件を作成します。
サービス品質要件は、それまでに特定したビジネス要件とビジネス制約を考慮しながら、使用パターン分析およびユースケースから導き出します。
後の論理設計フェーズでは、サービス品質要件を論理アーキテクチャーと対応付けて、配備シナリオを作成します。配備シナリオは、ソリューションライフサイクルの配備設計フェーズへの主要なインプットです。
ビジネス分析の場合と同様に、使用パターン分析、ユースケース、およびシステム要件を導く、技術要件分析のための単純な公式は存在しません。技術要件分析では、ビジネス領域、ビジネス上の目的、基本となるシステム技術の理解が必要となります。
使用パターンの分析では、設計しているソリューションを利用するさまざまなユーザーを特定し、それらのユーザーの使用パターンを特定します。収集した情報は、システムの負荷状況を見積もるための基礎となります。使用パターンの分析結果は、「ユースケース」で説明するユースケースに重みを割り当てる上でも役立ちます。
使用パターンを分析するときは、できるだけ多く機会を設けてユーザーにインタビューし、使用パターンに関する既存のデータを収集する必要があります。また、従来のシステムの構築者や管理者にもインタビューします。次の表は、使用パターンの分析時に考慮すべき要因を示しています。
表 3–1 使用パターンの分析で考慮すべき要因
ユースケースは、設計しているソリューションとユーザーとの一般的なインタラクションをモデル化し、エンドユーザーの観点から完全な操作フローを説明します。すべてのユースケースについて設計の優先順位を付けることで、想定される機能の提供に継続して注力できます。ユースケースは、論理設計への主要なインプットです。
ユースケースには重みを割り当てます。 最も重いユースケースが、ユーザーの最も一般的なタスクを表します。ユースケースに重みを割り当てることで、最も使用されるシステムサービスに集中して設計上の意思決定を行うことができます。
ユースケースは、2 つのレベルで説明されます。
ユースケースレポート: 各ユースケースの説明。 イベントの一次フローと代替フローの説明が含まれます。
ユースケースダイアグラム: 関連要素とユースケースの関係を示す図。 より正式な構造でイベントフローが示されます。ユースケースダイアグラムは、長いユースケースまたは複雑なユースケースをモデル化する上で有用です。通常、ユースケースダイアグラムを作成するには、統一モデル言語 (UML: Unified Modeling Language) を使用します。
サービス品質 (QoS) 要件は、パフォーマンス、可用性、スケーラビリティーなどについてシステム品質を特定する技術仕様です。QoS 要件は、ビジネス要件で指定されたビジネスニーズによって導き出されます。たとえば、サービスが 24 時間 365 日利用可能であることが必要とされる場合、可用性要件でこのビジネス要件に対応する必要があります。
次の表は、一般的に QoS 要件の基礎となるシステム品質を示しています。
表 3–2 QoS 要件に影響するシステム品質
システム品質 |
説明 |
---|---|
パフォーマンス |
ユーザー負荷状況に対応する応答時間とスループット。 |
可用性 |
エンドユーザーがシステムのリソースとサービスにアクセスできる頻度。 通常は、システムの稼働時間として表されます。 |
スケーラビリティー |
時間の経過とともに、配備されるシステムに容量 (およびユーザー) を追加する能力。通常、スケーラビリティーにはシステムへのリソースの追加が関連しますが、配備アーキテクチャーの変更は含まれません。 |
セキュリティー |
システムとユーザーの整合性を説明する、要因の複雑な組み合わせ。セキュリティーには、ユーザーの認証と承認、データの安全性、配備されたシステムへのセキュリティー保護されたアクセスなどが含まれます。 |
潜在処理能力 |
例外的なピーク負荷が生じた場合に、追加リソースなしでシステムがそれを処理する能力。潜在処理能力は、可用性、パフォーマンス、およびスケーラビリティーの要因です。 |
保守性 |
システムの監視、発生した問題の解決、ハードウェアおよびソフトウェアコンポーネントのアップグレードなどを含めた、配備されたシステムの保守の容易さ。 |
各システム品質は、密接に関連しています。あるシステム品質の必要性が、その他のシステム品質の必要性と設計に影響することがあります。たとえば、セキュリティーのレベルを高めることは、パフォーマンスに影響し、それが可用性に影響する可能性があります。可用性の問題を解決するためにサーバーを追加導入することは、保守性 (保守コスト) に影響します。
ビジネス要件とビジネス上の制約の両方を適切に満たすシステムを設計する鍵は、システム品質がどのように連携するかを把握し、得失評価が必要であることを理解することにあります。
以降の各節では、配備設計に影響するシステム品質を詳細に説明し、QoS 要件を具体化する上で考慮すべき要因についてガイドラインを示します。サービスレベル要件についての節もあります。 この要件は、サービスレベル契約の基礎となります。
通常、ビジネス要件では、技術用語を用いずに応答時間を指定することでパフォーマンスを表します。たとえば、Web ベースのアクセスに関するビジネス要件は、次のように指定されます。
ユーザーは、ログイン時に妥当な応答時間、通常は 4 秒以内を想定している。
このビジネス要件に基づき、すべてのユースケースを調べ、この要件をシステムレベルで表す方法を決定します。場合によっては、使用パターン分析で特定したユーザーの負荷状況を含める必要があります。各ユースケースのパフォーマンス要件は、特定の負荷状況における応答時間、または応答時間とスループットの併記で表します。また、許容可能なエラー数も指定します。
次に、パフォーマンス上のシステム要件を指定する例を 2 つ示します。
Web ページ更新に対する応答時間は、終日 4 秒以内である必要がある。 サンプリングは 15 分間隔で実行されるものとし、エラーの数は 100 万トランザクションあたり 3.4 件未満とする。
定義されたピーク時において、システムは 1 秒あたり 25 件のセキュリティー保護されたログインが可能である必要がある。 すべてのユーザーに対する応答時間は 12 秒以内とし、エラーの数は 100 万トランザクションあたり 3.4 件未満とする。
パフォーマンス要件は、可用性要件 (フェイルオーバーがパフォーマンスにどの程度影響するか) および潜在処理能力 (例外的なピーク負荷の処理に使用できる能力がどの程度あるか) に密接に関連します。
可用性は、システムの稼働時間を特定する基準で、通常はユーザーがシステムにアクセス可能な時間の割合で測定されます。システムにアクセスできなくなる時間 (停止時間) は、ハードウェア、ソフトウェア、ネットワークの障害、またはシステムをダウンさせるその他の要因 (停電など) によって生じます。サービスの予定された停止時間 (保守およびアップグレード) は、停止時間とみなしません。稼働時間の割合でシステムの可用性を計算する基本的な方程式は、次のとおりです。
可用性 = 稼働時間 / (稼働時間 + 停止時間) * 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 スケーラビリティー要因
セキュリティーは、配備されたシステムの全レベルが関わる複雑な事項です。セキュリティー要件の作成は、セキュリティー脅威の特定およびそれらに対抗する戦略の策定を中心に進めます。このセキュリティー分析には、次のステップがあります。
重大な資産の特定
それらの資産に対する脅威の特定
組織にリスクをもたらす脅威を顕在化する脆弱性の特定
組織に対するリスクを低減するセキュリティー計画の作成
セキュリティー要件の分析には、管理職、ビジネスアナリスト、情報技術担当者など、組織の幅広い利害関係者が関与する必要があります。多くの場合、セキュリティー設計者がセキュリティー対策の設計と実装におけるリーダーに指名されます。
次の節では、セキュリティー計画の対象となる領域の一部を説明します。
システムのセキュリティーを計画することは、配備設計の一部で、実装の成功に不可欠な部分です。セキュリティーを計画する際は、次の要素を考慮します。
物理的なセキュリティー: 物理的なセキュリティーは、ルーター、サーバー、サーバールーム、データセンター、またはインフラストラクチャーを構成するその他の部分に対する物理的なアクセスに対応します。権限のない人物がサーバールームに入ってルーターのプラグを抜くことができる場合、その他のセキュリティー対策の効力が脅かされます。
ネットワークセキュリティー: ネットワークセキュリティーは、ファイアウォール、セキュアアクセスゾーン、アクセス制御リスト、およびポートアクセスを使用した、ネットワークへのアクセスに対応します。ネットワークセキュリティー対策のために、不正なアクセス、改ざん、およびサービス拒否 (DoS) 攻撃に対する戦略を策定します。
アプリケーションおよびアプリケーションデータセキュリティー: アプリケーションおよびアプリケーションデータセキュリティーは、認証と承認の手順とポリシーを使用した、ユーザーアカウント、企業のデータ、および企業向けアプリケーションへのアクセスに対応しています。この領域には、次のポリシーの定義が含まれます。
パスワードポリシー
管理者アクセスではなく、ユーザーに委任された委任管理などのアクセス権限
アカウントの無効化
アクセス制御
セキュリティー保護されたデータ転送やデータに署名する際の証明書の使用などの暗号化ポリシー
個人のセキュリティー順守: 組織全体のセキュリティーポリシーでは、作業環境と対策が定められます。 これらは、その他のセキュリティー対策が確実に設計どおり実施されるために、すべてのユーザーが順守する必要があります。通常、セキュリティーについてのハンドブックやマニュアルを作成し、ユーザーにセキュリティー順守についてのトレーニングを提供します。セキュリティーポリシー全体が効果的であるためには、適切なセキュリティーの順守を組織文化の一部にする必要があります。
潜在処理能力は、使用状況に例外的なピーク負荷が生じた場合に、追加リソースなしで配備がそれを処理する能力です。通常は、潜在処理能力について QoS 要件を直接指定することはありませんが、このシステム品質は、システムの可用性、パフォーマンス、スケーラビリティーの要因となります。
保守性は、システムの監視、発生した問題の解決、システムに対するユーザーの追加および削除、ハードウェアおよびソフトウェアコンポーネントのアップグレードなどのタスクを含め、配備されたシステムの保守の容易さを意味します。
保守性の要件を計画するときは、次の表に示される事項を考慮します。
表 3–6 保守性要件について考慮すべき事項
項目 |
説明 |
---|---|
停止時間の計画 |
特定のサービスが利用できなくなる、または部分的に利用できなくなる保守作業を特定します。 ユーザーに対してシームレスに行われる保守とアップグレードもありますが、サービスの中断を必要とするものもあります。ユーザーが事前に停止時間に備えることができるように、可能であれば、停止時間を必要とする保守作業についてユーザーと共同で予定を立てます。 |
使用パターン |
使用パターンを特定して、保守を予定するのに最も適した時間帯を決定します。 たとえば、通常のピーク利用が一般的な業務時間帯であるシステムの場合、夜または週末に保守を予定します。地理的に分散したシステムの場合、この時間帯の特定はより困難になります。 |
可用性 |
多くの場合、可用性の設計は保守性に反映されます。保守とアップグレードのための停止時間を最小化する戦略は、可用性戦略を中心に展開されます。高度な可用性を必要とするシステムでは、保守、アップグレード、修復のための機会は限られています。 可用性要件に対処するための戦略は、保守やアップグレードの処理に影響します。たとえば、地理的に分散したシステムでは、サービスの可用性は、保守期間中のリモートサーバーへの作業負荷のルーティング機能に依存します。 また、高度な可用性を必要とするシステムは、人的な介入をほとんど必要とせずに、システムを自動的に再起動する、より洗練されたソリューションを必要とします。 |
診断と監視 |
診断ツールと監視ツールを定期的に実行して問題領域を特定することで、システムの安定性を向上できます。 定期的なシステムの監視により、発生前に問題を回避したり、可用性戦略に基づく作業負荷のバランスに役立てたりすることができます。 また、保守と停止時間の計画も改善されます。 |
サービスレベル契約 (SLA: Service Level Agreement) には、最小パフォーマンス要件と障害時にこれらの要件を満たすために提供する必要のあるカスタマーサポートのレベルと範囲を規定します。サービスレベル要件は、SLA が基づく条件を特定するシステム要件です。
サービスレベル要件は、QoS 要件と同様にビジネス要件に基づいて特定され、配備されたシステムが満たす必要のあるシステム全体の品質についての保証を示します。サービスレベル契約は契約の一環とみなされるので、サービスレベル要件の仕様は明白である必要があります。サービスレベル要件は、どのような条件のもとで要件がテストされるのかを具体的に定義し、何をもって要件の不適合とするかを厳密に定義する必要があります。