キャパシティ管理運用ガイド

トピック

 キャパシティ管理の概要
 用語集
 役割と責任
 キャパシティ管理のプロセス
 スケーラビリティを備えた IT ソリューションの設計
 推奨トレーニング コース

キャパシティ管理の概要

キャパシティ管理は、サービス レベル契約 (SLA) として定められている、または IT の運用レベル合意 (OLA) として内部的に定められているパフォーマンス レベルの範囲内において、適正なコストでユーザーの要求を満たせるサービス ソリューションのキャパシティをプランニングし、サイジングと制御を行うプロセスです。

キャパシティ管理は、IT リソースの最適な使用によって、クライアントと合意したパフォーマンス レベルを実現します。"最適" とは、リソースを適切な量だけ、適切な場所で適切なタイミングで、しかも適正な価格で使用している状況を指します。これは、IT サービスが適正で妥当なコストで機能するように、組織が適切なキャパシティ レベルを達成し維持するのを支援するプロセスです。

キャパシティ管理は、主に手順とシステムを管理の対象とし、IT リソースと結果として提供されるサービス パフォーマンスの仕様設定、実装、監視、分析、およびチューニングなどが含まれます。キャパシティの必要条件は、サービス レベル管理プロセスによって設定される質と量の基準に基づき、SLA または OLA の条項に指定されます。

キャパシティ管理には、この文書の基礎となる ITIL (CCTA IT Infrastructure Library) モジュールがあります。キャパシティ管理の最終目的は、ITIL の定義に示すように、コストに見合った IT キャパシティが存在し、そのキャパシティが現在および将来のビジネス ニーズに一致していることです。

キャパシティは、IT サービスにおいて最も重要な定量的側面の 1 つです。ビジネスとエンド ユーザーに重点が置かれているため、このプロセスによって以下のような基本的利益を実現することが重要です。

• IT サービス コストの削減

• 顧客満足度の向上

そのほか、以下のような利益を実現します。

• IT サービスおよびキャパシティの必要条件の基になるビジネス要件と、逆に、統合化されたキャパシティ管理による合意されたサービス レベルのためのビジネスの必要条件を実現する。

• IT のキャパシティおよびパフォーマンスのプランニングと監視にかかるコストを算出し、承認された関連変更要求を介した適切なアップグレードを算定して、コストを調整する。

• 必要なキャパシティ レベルの合意、測定、および監視によって、サービス レベル管理を全面的にサポートする。

• キャパシティおよびパフォーマンスが必要なレベルの規定を満たしていない状態を認識し、適切な対応策を識別して実装する。

• ビジネスおよびエンド ユーザーの観点から IT 可用性を検討し、IT インフラストラクチャの最適利用とパフォーマンスを確保し、最大利益を提供する。

• キャパシティを原因とする IT の不具合の発生頻度と持続時間を、時間経過と共に軽減する。

• IT サポート組織の考え方を、エラーの修正からサービスの向上へと変化させる。

• IT サポート組織をビジネスの「付加価値」と見なす。

• キャパシティ マネージャをキャパシティのプランニングと監視に関する説明責任を負う唯一の担当者として確立する。

ほかのプロセスとの関連

キャパシティ管理は、MOF (Microsoft Operations Framework) を構成するサービス管理機能 (SMF : Service Management Function) の最適化フェーズにあたります。キャパシティ管理は、MOF サービス レベル契約見直しのマイルストーン (主要管理点) に従って行います。このプロセスは、IT によって提供されるソリューションのサービスの品質 (QoS) を確保するための対策を行うレベルです。また、キャパシティの変更プロセスを管理し、MRF (Microsoft Readiness Framework) および MSF (Microsoft Solutions Framework) に必要な設計とプランニングのフィードバックを行います。

キャパシティ管理は、IT サービスの分析、監視、および制御に基づく勧告、管理情報プラン、およびレポートを提出することにより、IT サービスのキャパシティおよびパフォーマンスの継続的改善を開始します。また、サービス レベル契約 (SLA) を基に必要条件の設定と調整を行い、次にこの必要条件から、IT 組織の内部的な運用レベル合意 (OLA) を作成します。キャパシティ管理で中心になるのは、サービス レベル管理との関係です。キャパシティ管理の勧告の多くではコスト管理のデータが活用され、通常の最適化作業は可用性管理と緊密に結びついています。また、緊急事態対策のプランニングに対しては、データを提供します。詳細については、『MOF 運用ガイド』の「サービス レベル管理運用ガイド」、「経費管理運用ガイド」、「可用性管理運用ガイド」、および「サービス継続性管理運用ガイド」を参照してください。

キャパシティ管理プロセスでは、新しいテクノロジ、既存アプリケーション、基本システム ソフトウェアおよびハードウェア、サポート ツール、および関連マニュアルの適切なキャパシティ レベルまたはパフォーマンス レベルに焦点を当てます。キャパシティの不足または低下によって、サービスの可用性に深刻な影響が引き起こされることがあります。キャパシティ管理機能と可用性管理機能は、多くの場合、共通のスタッフと管理情報ツールを共有します。この 2 つのプロセスでは、同じような管理データ ビューとベンダ提供ソフトウェアを使用し、変更による混乱を最小にすることが共通の目標であるため、関連する作業を調整する必要があります。

IT 環境内のキャパシティに対して必要であるとして推奨された変更のプランニング、決定基準、実装の成功は、組織内の多くの関連作業の調整にかかっています。MOF (Microsoft Operations Framework) にはサービス管理機能 (SMF : Service Management Function) があり、IT 業務の調整機能を改善するための方針が提案されています。このセクションでは、キャパシティ管理とほかの MOF SMF プロセス モジュールとの関係の概要を説明します。

経費管理
キャパシティ管理では、予算作成プロセスに含まれるアップグレード計画を作成します。キャパシティのアップグレードに関する予算を正確に算出するためには、正確なコスト情報が欠かせません。キャパシティ管理のプランニングには、新しいハードウェアおよびソフトウェアの計画が必要です。これらのコストは、年間予算に組み入れなければなりません。コストは、意思決定の際に制限要因となることもあり、SLA の交渉に影響を与えます。サービスの可用性とキャパシティの最適化に必要なコストを有効に見積もることにより、リスクとコストを比較して、予算上からも実装が可能であり、緊急事態対策のシナリオにも対応できる対策を決定することができます。ときには、必要な変更を実行した場合の投資利益 (ROI) を実証しなければならない場合もあります。キャパシティ管理によって、対費用効果に優れた方法で必要なリソースが取得され実装されるようにします。詳細については、『MOF 運用ガイド』の「可用性管理運用ガイド」および「サービス継続性管理運用ガイド」を参照してください。

サービスレベル管理 (SLA)
IT サービスのプロバイダ (提供側) と利用者の間で結ばれる契約は、多くの組織に存在していますが、場合によっては契約が非公式であるだけでなく、関係者の一方または双方にとって不明瞭な場合もあります。

SLA の見直しと準備は、サービス レベル管理の基本的作業です。また、キャパシティ管理は、サービス レベルの目標値を基に作成される OLA の定義に役立ちます。IT は、可用性に影響が現れる前にパフォーマンスの低下を防止するためのサービスの警告と対策に優先順位を付けます。キャパシティ管理のスタッフは、サービス レベル管理、可用性管理、サービス継続性管理、および経費管理のスタッフと緊密に協力し合って、サービスの "品質" を向上させるための、コストに見合った予防策を決定します。

可用性管理
可用性管理では、リソース、メソッド、およびテクノロジを正しく使用して、IT サービスが最適な状態で提供されるようにします。キャパシティ管理はこの可用性管理プロセスと密接な関連があります。それは、適正なコストでパフォーマンス レベルを達成するために IT リソースを最適利用することは、サービスの高可用性を実現するという目的とかかわっているからです。共有レポートでは、キャパシティまたはパフォーマンスの問題を示す動向に焦点を当てる必要があります。管理情報ツールは、一般的に、この両方のプロセスに必要な監視情報を提供するために利用されます。

可用性プランは、キャパシティ プランニングのプロセスと調整する必要があります。同じテクノロジ ソリューションで両方のプランのニーズを満たせる場合がよくあります。可用性とキャパシティのプランは、共同作業によって作成しなければなりません。片方のプランだけではコストに見合わないソリューションでも、もう一方のプランと組み合わせれば妥当性が認められることもあります。

サービス継続性管理
サービス継続性管理は、IT サービスを停止できる期間がなく、通常の可用性対策では処理できないような予定外の状況に対して、その対応とサービスの復旧を行います。影響の及ぶ範囲とどのようなサービス停止が容認できないかについては、違いがあります。可用性管理では、より実際的な、日常業務の一環として IT がより効果的に処理できる対象を扱いますが、原則、アプローチ、および考慮事項については、サービス継続性管理とほとんど同じです。どちらのプロセスでも、対応策を実行するときのパフォーマンス レベルを判断するため、キャパシティ管理のデータを必要とします。

記憶域の管理
記憶域の管理には、IT 環境の記憶域を効果的に運用、管理するための日常業務がすべて含まれます。これは、システム全体の管理プロセスの主要な SMF です。データのバックアップ、復元、および復旧操作を扱います。キャパシティまたはパフォーマンス監視の細かいコンポーネントについては、この SMF で説明されています。Windows 2000 の特に記憶域に関するキャパシティおよびパフォーマンスの "ヒント" が提示されています。

ジョブスケジューリング
ジョブ スケジューリングでは、バッチ ジョブ処理に含まれる日常のキャパシティ関連作業を扱います。ジョブ スケジューリング プロセスは、バッチ ジョブの制御、監視、およびチューニングの詳細内容に関与しています。これは、日常業務に適用されるキャパシティ管理対策の一例です。キャパシティ管理は、ジョブ管理、作業負荷、およびパフォーマンスの予測値に対する必要条件を設定します。

ネットワーク管理
この SMF は、ネットワーク使用量、帯域幅、および動向分析を提供し、中央の管理設備からキャパシティ プランニングの予測情報にアクセスさせ、キャパシティ管理データベース (CDB) にデータを格納します。キャパシティ管理では、このデータを入力データとして引き出し、要求管理情報や予防的勧告を提供します。ネットワーク管理の 1 つの機能として、ネットワーク サービスの使用状況を監視するツールを提供するプロセスがあります。このツールは、IT サービスのキャパシティと可用性を定量化するのに役に立ちます。キャパシティ管理の作業として作業負荷と要求を正しく管理できるかどうかは、ネットワーク管理作業が適切に行われているかどうかにかかっています。

システム管理
システム管理では、変更を実装し、IT サービスやコンポーネント システムのキャパシティとパフォーマンス レベルを効果的に運用、維持するための継続的運用作業が業務の対象です。

システム管理者の権限で承認されたキャパシティ変更を行うこともできますが、キャパシティに関する推奨事項は、キャパシティ管理か、またはジョブ スケジューリング スタッフと機能上の必要条件によって指定された代理人が提示する必要があります。

変更管理
キャパシティ管理では、変更による既存キャパシティへの影響を査定し、要求の変化に基づく追加リソースの必要条件を特定します。必要な変更は、一般的には、キャパシティ管理、可用性管理、サービス継続性管理、およびスタッフ管理によって作成されるプランニングと勧告を介して実装されます。近日中に実行される日常業務の変更は、より日常的なキャパシティ変更を調整するジョブ スケジューリングとして実行されることもあります。どの場合も、IT サービス環境の変更はすべて、変更要求として変更管理を通して提出されます。

構成管理
IT リソース (構成項目 (CI : Configuration Item) に加えられた変更、およびこれらのリソースに対するサービス レベル目標を、構成管理データベース (CMDB) に反映する必要があります。CMDB に格納されているサービス レベル契約 (SLA) の可用性およびキャパシティ データを利用して、SLA 準拠に基づくさらに予防的な対策を実行することができます。このデータは、キャパシティ管理の重要な入力データです。関連する要求と作業負荷の必要条件、成果となるパフォーマンス、およびリソースのメトリックがキャパシティ管理データベース (CDB) に記録されます。適切なタイミングで情報を提供し、継続的なキャパシティの勧告とプランニングを行うには、関連する要素をこれらの論理データベース間で効果的に調整し相関させることが必要です。

問題管理
問題管理は、問題の根本的な原因を判定します。問題とは、同様の症状を示す 1 つまたは複数のインシデントとして定義されます。キャパシティ管理では、問題管理と連携して IT サービスのパフォーマンス レベルに影響を与えた既知のエラーを調査します。またキャパシティ管理は、キャパシティまたはパフォーマンス関連の問題を識別し診断する専門家のインフラストラクチャとして役割を果たします。キャパシティ管理は、サービスのパフォーマンスの低下、またはそれから派生した既知のエラーによって引き起こされたインシデントを調査して、継続的フィードバックと変更の勧告を行います。

サービスデスク
サービスのパフォーマンス レベルに関するインシデント発生頻度と統計情報は、問題管理、CMDB の記録、またはキャパシティ管理の専門家がパフォーマンスや記憶域のキャパシティに関する既知のエラーの識別にかかわったデータを通じて報告されます。理想的には、IT リソースのパフォーマンスはサービス デスクが記録して管理し、過去の復旧や分析のデータは構成管理が CMDB に保管します。作業負荷、パフォーマンス、および要求管理の各作業では、インシデントのエスカレーション、キャパシティの問題のフェールオーバーと復旧、その他追跡されたインシデントのレポートと傾向を基に作成された CMDB の記録を参照することができます。

サービスの監視と制御
このプロセスは、サービス パフォーマンス レベルを決定する際の基礎を提供します。サービス パフォーマンスの最適化には、アプリケーションのエンドツーエンドでの応答時間の監視が必要です。適正に運用されている IT サービス提供組織では、パフォーマンス レベルが予測され、監視システムによって設定されたしきい値アラームが、サービスの顧客が問題に気付く前に警告を発生します。監視と制御は、キャパシティ、可用性、および緊急事態またはサービス継続性への対応策が必要かどうかの判断に影響する警告の中枢です。サービス キャパシティの監視と制御の運用レベルの目標には、カスタムまたは選択されたベンダのソフトウェア製品による管理データ ビューが必要です。WMI (Windows Management Instrumentation) や Web ベース エンタープライズ管理 (WBEM : Web-based Enterprise Management) などの標準では、セキュリティ保護された Web ブラウザのユーザー インターフェイスを使用して、堅固なシステム管理情報が提供されます。自動監視機能は、IT サービスのパフォーマンス レベルを追跡します。しきい値のアラームによって、範囲外の状況が発生したときに対応できます。

 ページのトップへ

用語集

可用性

可用性とは、アプリケーションが作業を実行できる時間量であり、動作可能時間のパーセントで示します。

キャパシティ管理
キャパシティ管理の仕事は、IT 処理および記憶域のキャパシティを、対費用効果の大きい方法を使用して適切なタイミングでビジネスの発展要求に対応させることです。

キャパシティ
キャパシティとは、クライアントと合意したパフォーマンスを最適なサービス レベルとコストで提供するために必要なすべてのものと定義することができます。

キャパシティプラン
キャパシティ プランは、キャパシティ管理プロセス内で編集や調整が行われます。キャパシティ プランでは、リソースの使用状況とサービス パフォーマンスの現在のレベルをドキュメント化します。ビジネス要件を考慮したうえで、ビジネスをサポートする IT サービス リソースの将来の必要条件を予測します。キャパシティ プランでは、必要なリソース レベルと、SLA をサポートする運用レベル目標を達成するための変更が勧告されます。その中には、そのコスト、利点、IT SLA への準拠の報告、優先順位、ビジネス全体および IT インフラストラクチャに与える影響が含まれています。

キャパシティ管理データベース (CDB)
キャパシティ管理データベース (CDB : Capasity Management Database) は欠かすことのできないキャパシティ管理ツールであり、構成管理データベース (CMDB : Configuration Mmanagement Database) と混同しないようにしてください。このデータベースは、必要な技術、ビジネス、およびサービス レベル管理の詳細データを格納する論理エンティティでなければなりません。これは、動向分析に必要な現在のリソースとサービス パフォーマンス レベル データを記録するのに用いられますが、予測やプランニング レポートにも使用されます。データの一部がほかのプロセスのリポジトリ、たとえば CMDB などとオーバーラップ、リンク、または同期することがあります。構成管理プロセスは、構成データを最新の状態に維持します。キャパシティ管理スタッフは、CDB のパフォーマンス情報を記録するか、記録を自動化します。組織によっては、これらを 3 つのデータベースに分割し、それぞれをリレーショナルにクエリできるように共通のキー設計を持たせる場合があります。

その他のキャパシティ管理用語および技術用語

要求管理
このサブプロセスでは、IT サービスの将来のビジネス要件が適切なタイミングで考慮され、プランニングされ、実装されるようにします。キャパシティ管理スタッフがこのサブプロセスを達成するには、各種 IT ソリューションの現在のリソース使用状況を分析し、傾向と予測を作成します。将来の必要条件は、現在および将来の顧客ニーズを継続的に調査している会計管理から提供されます。

作業負荷管理
このサブプロセスでは、顧客の要求を IT ソリューションのコンポーネント (実際のソリューションの作成に使用する各種アプリケーション) に対する作業負荷に変換します。この分析を基にして必要なリソースが決定されます。このプロセスでは、現在と将来の両方の要求を作業負荷に変換します。

リソース管理
このサブプロセスでは、主に、IT インフラストラクチャの個々のリソースを管理します。作業負荷を基に、現在および将来に必要なリソースを決定します。また、すべてのリソースが、適切なタイミングで対費用効果の大きい方法で取得され実装されるようにします。

パフォーマンス管理
このサブプロセスでは、主に、顧客が使用する IT ソリューションのパフォーマンス、およびソリューションが依存する基本リソースのパフォーマンスを管理します。業務としては、技術インフラストラクチャの主要 IT レイヤに対して設定されている OLA 目標に従って、すべての IT ソリューションのパフォーマンスを監視します。また、基本リソースのパフォーマンスを確実に監視します。収集されたデータはすべて記録、分析、報告されます。キャパシティ管理スタッフは、必要に応じて、ソリューションのパフォーマンスがビジネス要件に確実に適合するようにします。サービスの監視と制御は、このサブプロセスの主要な SMF です。

スケーラビリティ
スケーラビリティとは、アプリケーションが、容認できるパフォーマンス レベルを維持しながら、作業量の増加に対応できるキャパシティです。たとえば、1 台のシステム/プロセッサが 10 人のユーザーをサポートしている場合、2 台のシステム/プロセッサでは 20 人のユーザーをサポートでき、以下同様に増加します。線形のスケーラビリティでは、傾きが一定の直線を想定します。

縦方向のスケールアップ
縦方向のスケール アップ (垂直スケール) とは、既存サーバーに徐々にデバイスを追加することによって、ソリューションの能力を拡大することです。一般的には、中央処理装置 (CPU)、メモリ、ディスク、ネットワーク インターフェイス カード (NIC) をサーバーに追加します。これは、垂直スケーリングまたは垂直成長とも呼ばれます。

横方向のスケールアップ
横方向のスケール アップ (水平スケール) とは、プロセッサ、記憶域、帯域幅を備えたサーバーを徐々に追加して、これらのサーバーで負荷を共有し、ソリューションの能力を拡大することです。これは、水平スケーリングまたは水平成長とも呼ばれます。

リレーショナルデータベース管理システム (RDBMS : Relational Database Management System)
リレーショナル データベース管理システム (RDBMS) は、IT サービス ソリューションで最も多く利用されているデータベース ソフトウェア コンテンツ データ ストアです。リレーショナル データベース管理システムは、一般に規格品のパッケージ ソフトウェアとして販売されています。その他、アプリケーション開発やコンテンツ開発の IT を支援するソフトウェア ツールセットは、通常、RDBMS ベンダから入手できます。

意思決定支援システム (DSS : Decision Support System)
意思決定支援システム (DSS) は、情報に関する一般的なビジネス要求に対する回答を提供します。個々の RDBMS クエリによって、ビジネス上の意思決定に必要な情報のコンポーネントが提供されます。意思決定支援システム (DSS) ソリューションは、高い柔軟性と "分野を特定した" 情報を提供できることで知られています。

オンライントランザクション処理 (OLTP : On Line Transaction Processing)
オンライン トランザクション処理 (OLTP) アプリケーションは、一般的に、ビジネスの基幹アプリケーションであり、分散型のクライアント/サーバー環境への導入が増えています。トランザクション モニタは OLP と関連付けられ、リレーショナル データベース管理システム (RDBMS) などの企業のデータ リポジトリによるトランザクションの管理と調整が容易に行えます。オンライン トランザクション処理 (OLTP) は、通常、意思決定支援システム (DSS) とは別の種類のソリューションです。どちらの種類のソリューションにも、一般的には、関連する RDBMS があります。

分散トランザクション処理 (DTP : Distributed Transaction Processing)
キャパシティ プランニングでは、分散トランザクション処理 (DTP) モデルに準拠するソフトウェアからのデータを利用することがあります。分散トランザクション処理モデルは広く認められている国際標準で、異機種コンピュータ システム間の相互運用性を促進するため X/Open によって確立されました。分散トランザクション処理 (DTP) ソフトウェアは、分散型クライアント/サーバー環境でオンライン トランザクションを監視し、基幹オンライン トランザクション処理 (OLTP) アプリケーションを管理するために導入されます。トランザクション モニタなどのミドルウェアは、DTP (デスクトップ パブリッシングとの混同に注意）のより一般的な情報カテゴリに分類されます。

WMI (Windows Management Instrumentation)
WMI (Windows Management Instrumentation) は、統一された標準ベースを使用し、拡張可能な単一のオブジェクト指向インターフェイスによって管理情報を提供します。WMI は Microsoft の Web ベース エンタープライズ管理 (WBEM : Web-based Enterprise Management) を実装したもので、エンタープライズ環境における管理情報へアクセスする標準テクノロジを開発するための業界イニシアティブです。このイニシアティブの目的は、システム、アプリケーション、およびデバイスを対象とする強力なエンタープライズ クラス管理を実現することによって、企業の総保有コスト削減を支援するものです。現在、数百の企業が、Microsoft、および Compaq Computer、Intel、Cisco、BMC Software 各社によって開始された当初の WBEM コンソーシアムから生み出されたこの標準をサポートしています。

ノード
ネットワーク上で一意にアドレス指定できる 1 つのコンピュータ システム、またはサーバー プラットフォーム。1 つのノードに複数の CPU が搭載されていることもあります。一般的には独自のブート ドライブ (直接接続された記憶域) を持ちますが、より一般的なデータ記憶域を "共有" し、よりスケーラブルで可用性の高いデータ リソースとコンテンツを実現している場合も多くあります。

メトリック
メトリックは、ノードに関する特定の情報アイテムです。たとえば、過去 5 秒間の平均実行待ち行列長、ディスクとやり取りされたバイト数、またはクライアント ノードに送信された文字数などです。キャパシティまたはパフォーマンスを表すメトリックとして考えられる項目は数百にのぼり、いくつかのカテゴリ (CPU、メモリ、I/O 速度またはディスク速度、ネットワークなど) に分類されています。

しきい値
メトリックに設定できる制限値。この制限値を超えた場合は、前もって指定したアクションが実行されます。たとえば、ディスクの一部または全部にキャパシティ使用量 90% のしきい値と、そのディスクからいくつかのファイルを移動するコマンドを実行するアクションを設定することができます。

クラスタ
単一のサーバー システムと見なされるノードの集まりで、単一システムより高いアプリケーション可用性とスケーラビリティを提供します。

管理ステーション
管理ステーションは、システム内のノードを管理し監視するための運用センターです。このセンターは、データを収集するためのサーバー ノード (データベースを含む場合あり) か、または管理情報のプレゼンテーションが表示されるワークステーションです。より一般的には、WMI と WBEM による柔軟な Web ベース コンソールが可能です。このコンソールは、CIM (Common Information Model) などの確立されたプラットフォーム標準の管理情報ベース (MIB : Management Information Base) の拡張機能によって、要約された総合的詳細情報を提供します。分散コンピューティングの世界では、DMTF (Distributed Management Task Force) が標準に関する作業のほとんどを管理しています。

 ページのトップへ

役割と責任

ここでは、キャパシティ マネージャの役割と責任について説明します。キャパシティ マネージャは、このプロセスの所有者になります。これは役割であり、業務内容の説明ではないことに注意してください。小さな組織で 1 人でいくつかの役割を兼務することもあれば、大きい組織で 1 つの役割をチーム (キャパシティ管理スタッフなど) として担当する場合もあります。たとえば、大きい組織では、専門家のコーディネータと、キャパシティ マネージャから受けた指示を実行する役割を持つ人間をスタッフとして配置する場合もあります。ただし、その場合も、キャパシティ マネージャの役割は 1 人で担当することをお勧めします。

キャパシティ マネージャ

キャパシティ マネージャは、ユーザーに提供するサービスのキャパシティを管理します。キャパシティ マネージャは、システムおよびソリューションのキャパシティ、パフォーマンスの測定、および IT 組織の将来予測に関連するプランニング、監視、作業の報告を行います。この役割は、MOF チーム モデル内のインフラストラクチャ ロール クラスタの一部です。インフラストラクチャ ロールは、サポートおよび運用のロール クラスタと緊密に連携し、効率的なインフラストラクチャの開発と効果的な展開を実現します。

キャパシティ マネージャには多くの関連作業があり、以下のものが含まれています。

• 将来のサービス キャパシティの必要条件を予測する。

• キャパシティの目標値が妥当なコストで達成されるようにする。

• 新しいサービス レベル契約 (SLA) の作成と見直しを支援する。

• CAB (変更諮問委員会) に参加して、提案された変更が既存サービス レベルに与える影響を検討する。

• キャパシティ条項を含む外部契約の見直しと作成に関し、専門知識に基づくアドバイスを行う。

• サービスの日常的なキャパシティ必要条件を管理する。キャパシティ管理に関する日常の運用作業の詳細については、『MOF 運用ガイド』の「ジョブ スケジューリング運用ガイド」を参照してください。

 ページのトップへ

キャパシティ管理のプロセス

キャパシティ管理の目的は、ITIL に定義されているように、IT インフラストラクチャおよびサポート組織の能力を最適化して、ビジネスがビジネス上の目標値を達成できるような、対費用効果の大きい一定レベルの可用性を提供することです。たとえば、顧客の要求を、適切なタイミングで対費用効果の大きい方法で満足させるために、基幹サービスのプロセッサ パフォーマンスまたは記憶域のキャパシティの適切なレベルを慎重に調査する必要があります。キャパシティ管理のプロセスでは、現在および将来の IT リソース要求の最適化を継続して追求します。キャパシティ管理スタッフは、この最適化のプロセスに基づいて変更要求を提出し、それを基に MSF の制御による開発変更や新規インストールが行われる場合もあります。その後、運用に任され、効果的な運用のためのサイクルが引き続き行われます。

このプロセスは重要な定義であり、最適化レベルの IT サービスを適切なリソース消費量で効果的に提供するためのドキュメント化の段階です。

はじめに

このプロセスは、顧客が適切なコストで各自のビジネスをサポートするために必要な IT サービスのキャパシティ必要条件を、組織が容易に達成し維持できるようにします。このプロセスの中心は手順とシステムで、その中には、SLA に定められているサポート キャパシティの必要条件に、可用性に関する契約上の義務を持っている提供業者の特定と監視も含まれています。サービスの可用性に影響するようなキャパシティのサイジングおよび変更も対象となります。このモジュールでは、キャパシティは便宜上使用する用語であり、記憶域の容量、CPU のパフォーマンスまたは負荷分散、あるいは IT サービスのキャパシティ全体を表します。最良の方法を見つけるための多くの原則や提案も提示します。

キャパシティ管理プロセスには、IT リソースの最適利用を目的とする、キャパシティ プランニング、モデリング、パフォーマンス管理、リソース管理、要求管理、作業負荷管理、アプリケーション サイジング、およびキャパシティ プランの作成時に要約される勧告などの業務領域があります。このような作業では、ビジネス要件に適合するよう、リソースおよびサービス パフォーマンス レベルの管理を適切に行います。

キャパシティ管理の重要性
キャパシティ管理は、所定のソリューションの使用状況レベルを適正化し確立するためのガイドラインを提供します。不適切なキャパシティ プランニングは、サービスが停止するもとであり、基幹 IT サービスの場合には深刻な被害を引き起こすことがあります。最適なサービス レベルを提供する顧客中心の有効な IT 部門を運営し維持することが重要です。

またキャパシティ管理によって、IT サービスのプランニング、実装、および稼働に必要な手順で使用するデータが提供されます。サービスのキャパシティ レベルは記録して解釈する必要があり、新しいアプリケーション ソリューションやサービスのプランニングと設計には、キャパシティ データを欠かすことはできません。キャパシティ管理は可用性管理と相互に関連し、新しいサービスやコンポーネントのソリューションの設計、または既存ソリューション コンポーネントの修正やアップグレードにおいて、最適なキャパシティを確立するための鍵となります。また、緊急事態対策の作成時に検討されるサービス継続性シナリオに対して、コスト数値付きの有意義なパフォーマンスおよびキャパシティ プランニングについてのフィードバックを提供します。

キャパシティ管理スタッフは、IT リソースやビジネスにリスクをもたらす状況にはすばやく対応することが必要であり、さらに重要なことは、問題の発生をすべて防止することです。キャパシティ管理は、予防的な IT サービス提供の重要なコンポーネントです。

キャパシティ管理のためのサービス品質のメトリック
キャパシティ管理では、現在のシステム リソースがキャパシティの上限に近づいたら、追加リソースを計画して、ビジネス要件を満たす適切な IT リソースを確保します。適切なシステムおよびアプリケーション管理ツールを使用して既存リソースの使用状況を監視し、しきい値に対して警告を発生させ、IT 組織が、適切なタイミングで対費用効果の大きい方法を用いて将来のアップグレードを準備できるようにします。E コマース環境は急速に変化しています。キャパシティ管理では、適切なツールを配置し、リソースの適切なレベルを見積もる予想モデルを活用し、OLA の必要条件を満たすパフォーマンス レベルを予測することによって、予防のための勧告を提案します。見直しのためのマイルストーンを定義し、コストの数値と、サービス レベル、財務、要員、サービス継続性、可用性、およびキャパシティ管理を効果的に調整して、そのマイルストーンをさらに細かく設定します。これには、広く認められているキャパシティ管理計算の手法、ツール、測定方式、すべての関係者との適切なコミュニケーションが必要になります。

キャパシティ管理の成功は、以下のようないくつかの要素にかかっています。

• 正確で適切なタイミングでのビジネス予測

• 現在および将来のテクノロジに対する理解

• 有効な利点、コスト分析、およびコストの適正性を提示できる能力

• ほかのサービス管理プロセスとのコミュニケーションと相互作用

• ビジネス ニーズに合った適切な IT キャパシティを計画し実装できる能力

キャパシティ管理は、サービスの品質を監視し、可能な場合には改善しなければならないプロセスです。これには、サービスの品質のメトリックが欠かせません。プロセスの成否は、以下のサービス品質を検査することによって測定できます。

• ビジネス予測

  • 適切なタイミングで作業負荷の予測が作成されているか。

  • ビジネス動向が正確に予測されているか。

  • キャパシティ プランにビジネス プランが組み込まれているか。

• テクノロジ

  • すべてのサービスとコンポーネントのパフォーマンスとスループットを監視する能力があるか。

  • ビジネス要件 (時間、コスト、および機能性) に応じた新しいテクノロジが導入されているか。

  • 旧式テクノロジのサポートやパフォーマンスによる問題を原因とする SLA 違反がないか。

• 対費用効果

  • 緊急購入が減少しているか。

  • ビジネス上コストを正当化できないような大量の過剰キャパシティがないか。

  • 計画的な支出は正確に予測されているか。

• ビジネス ニーズに適合する適切な IT キャパシティの計画と実装

  • パフォーマンス不足によるインシデント発生数が減少しているか。

  • 不適切なキャパシティによるビジネス上の損失が減少しているか。

  • サービス レベル目標 (SLO) に適合する新しいサービスが実装されているか。

  • キャパシティ管理によって作成された勧告に対するアクションが実行されているか。

キャパシティ管理は、これらのサービス品質のメトリックについて目標を設定し、その実現を監視します。キャパシティ マネージャは、定められた目標が定められた時間枠内に達成されるように、プロセスを改善し管理しなければなりません。

範囲とトピック

キャパシティ管理のプロセスは、すべての IT パフォーマンスおよびキャパシティに関する問題が集中する場所でなければなりません。ほかにも、MOF の運用フェーズの SMF で解説されている技術領域として、サービスの監視と制御、ネットワーク管理、記憶域の管理、およびジョブ スケジューリングなどがあります。すべてのキャパシティ関連作業に関する全体的責任は、中央のキャパシティ管理プロセスにあります。プロセスは、運用環境と開発環境の両方にわたっています。

• すべてのハードウェア - PC、ファイル サーバーから中型機、メインフレームおよびスーパーコンピュータまで

• すべてのネットワーク設備 - LAN、WAN、ブリッジ、ルータなど

• すべての周辺装置 - 大量記憶装置、プリンタなど

• すべてのソフトウェア - オペレーティング システム、ネットワーク、社内開発および購入パッケージ

• 要員、要員が不足している場合にはエンドツーエンドの応答時間が遅れることがあります (たとえば、夜間のデータ バックアップが、テープを用意するオペレータがいなかったために時間までに完了できなかった場合など)。一般に、人的リソース管理はライン部門を管理する仕事であり、人的リソース管理の IT プロセスの最適化については、ほかの場所で説明します。詳細については、『MOF 運用ガイド』の「スタッフ管理運用ガイド」を参照してください。

IT が計画に従って、または予期できない理由によって使用できない場合でもビジネスの基幹業務は続行しなければなりません。復旧はすばやく実行する必要があり、障害は顧客に対してできるだけ意識させないようにします。IT が世界的な規模で運用されている場合、企業の IT にはそれに対応したビジョンとコストに見合った適切な必要条件がなければなりません。成長を遂げるグローバル経済で競争力を得るには、企業のデータ センター、分散型サーバーおよび PC、そして世界規模のネットワーク リソースを総合的に考慮する必要があります。

キャパシティ管理は、サービス継続性管理にフィードバックを提供し、可用性管理および経費管理プロセスの所有者と協力して、フェールオーバーや復旧の手段が実装される新しいソリューションを適切に "設計" することが重要です。たとえば、CPU の平均使用量は、維持ベースで 75% を超えないようにします。成長予測、リスク、およびコストに基づいて、実装されているキャパシティの 2 倍を予防的キャパシティとするのが最良の方法です。

クラスタ化された 2 台のサーバーを、それぞれ別のアクティブ - アクティブ クラスタ対応アプリケーションで同時に使用する場合があります。片方のシステムで障害が発生し、1 台のサーバーで両方のアプリケーションを処理する場合に容認できるパフォーマンスを予測しておくのが、最良の方法です。このような可用性に関するデータや、緊急事態対策に含まれないデータが、キャパシティ管理プロセスの重要な出力データです。詳細については、『MOF 運用ガイド』の「可用性管理運用ガイド」または「サービス継続性管理運用ガイド」を参照してください。

可用性およびキャパシティ管理に使用できる、対費用効果の大きい有効なアプリケーションの例として、この文書では E コマース Web サイトに最適な設計案とアーキテクチャを提案しています。詳細については、『MOF 運用ガイド』の「サービスの監視と制御運用ガイド」、「記憶域の管理運用ガイド」、「システム管理運用ガイド」、「ネットワーク管理運用ガイド」、および「ジョブ スケジューリング運用ガイド」を参照してください。

IT( 情報技術 ) サービスレイヤ
サービスは、通常の場合、多くの IT 機能によって構成され、これらの機能が一体となって動作し、サービスを提供しています。このような IT 機能には、技術的なものと人的なものがあります。技術面の機能はレイヤとして考えることができます。各レイヤはすぐ上のレイヤにサービスを提供し、すぐ下のレイヤからサービスを受け取ります。IT 部門には、以下のレイヤがあります。

• サービス

• アプリケーション

• ミドルウェア

• オペレーティング システム

• ハードウェア

• ローカル エリア ネットワーク

• 設備

• 外部サービス

オペレーティング システムが動作するには、ハードウェアが必要です。また、オペレーティング システムは、データベースなどのミドルウェア サービスに重要な機能を提供します。情報技術は、下位レイヤがすべて正常に機能しない限り、サービス (最上位レイヤ) を提供することはできません。したがって、サービスの提供には、サービスの作成に必要なサポートを行う IT 機能の提供が大切になります。これらの機能を "主要 IT レイヤ" と呼びます。

サービス
サービスは、IT スタックの最上位レイヤです。MOF (Microsoft Operations Framework) では、IT の役割および成功を定義するうえでのサービス レベル管理の重要性が強調されています。サービスは、下位にあるすべてのテクノロジ レイヤに依存します。

アプリケーション
アプリケーションは、ソリューションまたはサービスで、多くのユーザーから見える部分です。たとえば会計などのサービスを提供するため、ユーザーは SAP Financials のようなアプリケーションを利用します。これは Microsoft Office のアプリケーションである場合もありますが、また、Web ベースのポータル ビューで、内部および外部のデータ ソースから集められた情報を含む多くの複雑な相互依存形式のビューが表示される場合もあります。

ミドルウェア
ミドルウェアは、"ソリューションの、ユーザーが見えない部分" と定義することができます。したがって、ミドルウェアにはデータベース、Web サービス、トランザクション モニタ、および Microsoft .NET を代表とするようなメッセージング システムが含まれます。この広義の定義において、ミドルウェアは何によって構成されるかという質問に対する答えは、ソリューションによって大きく異なることになります。しかし、どんな場合も、ミドルウェアの可用性とキャパシティの目標が正確に作成できるように、ミドルウェアの完全なマップを作成する必要があります。

オペレーティングシステム
オペレーティング システム (OS) は、ハードウェアを制御するプログラムです。オペレーティング システムは、コンピュータ上の中央処理装置 (CPU)、メモリ、記憶装置などへのアクセスを提供します。このような関係から、適切なアプリケーション パフォーマンスを実現するには適切なオペレーティング システムのパフォーマンスが重要になります。ユーザーはオペレーティング システムの存在や役割を意識していないこともありますが、記述に不備のあるデバイス ドライバなど OS 上の問題によって基幹サービスが使用できなくなったときには、その役割を意識することになります。

ハードウェア
ここで使用するハードウェアという用語は、広範囲にわたるコンポーネントの種類を表します。コンピュータ、記憶装置、メモリ、ファン、電源装置など、言及しきれないほど多くのデバイスの種類が含まれています。この文書では、ネットワーク インターフェイス カード (NIC) はネットワークに分類します。

ネットワーク
建物内のネットワークは通信のバックボーンを提供し、コンピュータ システムはこのネットワーク上で通信を行うことができます。場合によっては、ネットワーク ハードウェアや NIC は、ハードウェアと見なされますが、この文書では、ネットワークとして分類します。ネットワークには、ネットワーク配線、壁面取付用ケーブル ジャック、ハブ/スイッチおよびルーター、ネットワーク インターフェイス カード (NIC) などが含まれます。

設備
設備には、データ センターや関連コンポーネントを収容する建物が含まれます。関連コンポーネントには、物理的建造物、暖房装置、換気装置、空調設備 (HVAC)、防火設備などが含まれます。

外部サービス
外部サービスは IT が管理する設備以外のもの、または外部で接続されているものと定義することができます。基本的な外部サービスの設備は、普通、IT 部門の管理外にあり、したがってほかの組織からの提供を受けなければなりません。しかし、その重要性から、基本システムに障害が発生したときを想定して、すべての外部サービスに対する二次的供給源を IT の方で用意しなければならない場合もあります。外部サービスとは一般に、水道、下水道、ガス、電気、インターネット アクセス (公衆用 xSP) および広域エリア ネットワーク (WAN : Wide Area Network) が提供するサービスです。基礎となる契約は、普通、サービスの品質を確保するため、該当する SLA に含まれています。状況によっては、IT もキャパシティ要件の定義や外部サービス プロバイダの見直しにかかわる場合もあります。多くの場合、エンドユーザーは、このレイヤと IT を区別せず、顧客満足度は IT とサービス プロバイダとの協力関係によって決まります。

運用レベル目標の定義
キャパシティ管理は、最適化フェーズの一部です。このフェーズでは、IT を正常に稼働させることは競争の激しい市場でビジネスを成功させるための前提条件であると認識します。最適化フェーズでは、多くの運用要素の中から特に次の 2 つを扱います。

• ビジネス サービスの信頼性

• コスト

MOF の最適化フェーズには、サービス レベル管理を取り巻く重要な基本概念を説明するドキュメントが別に用意されています。このドキュメントは、すべての運用プロセス、特にサービス レベル制御と各プロセスのメンテナンスに関係しています。

サービス レベル管理のプロセスは、サービス レベル契約 (SLA) によって正式なものとなります。サービス レベル契約には、ビジネス要件と IT 能力が直接反映されていなければなりません。したがって、どのサービス レベルなら能力と予算の範囲内で提供に合意できるかを決定するにあたっては、IT 部門は厳格でなければなりません。次に IT 部門では、提供されるサービスを測定するメトリックを作成し管理する必要があります。測定できないサービスはメトリックに適合しないため、SLA に含めないようにします。詳細については、『MOF 運用ガイド』の「サービス レベル管理運用ガイド」を参照してください。

顧客が技術的な能力以上の期待をすることは、よくあることです。したがって、新しいアプリケーションに対する顧客の期待を初期の段階からうまく管理する必要があります。キャパシティ管理では、顧客に対して技術的に実施可能かどうかを理解させ、特に、過剰な要望を実現するための必要条件を満たすには、どれだけのコストがかかるかについて理解を求めます。このような顧客教育の場は、アプリケーション サイジング作業の一部として設定されます。アプリケーション サイジング作業では、要件と要望を検討し、すべての参加者の同意を得ます。この仕事は、キャパシティの必要条件を決定する初期の段階から開始し、SLA に署名する前に、SLA の可用性とパフォーマンス レベルの必要条件を作成する過程で潜在的なリスクについて考慮しておくようにします (SLA 作業を検証するなど)。

つまり、前述の各 IT レイヤに対する OLO を作成してドキュメント化し、SLA 全体が達成されるようにします。レイヤによっては、サービス提供への影響が (あるとしても) ほとんどないものもありますが、その他のレイヤは、IT が SLA を達成するための能力に深刻な影響を与えます。重要なことは、ドキュメントをやみくもに作成せず、各 IT レイヤまたは部門がサービス提供全体に与える影響を慎重に評価することです。多くの場合、キャパシティ管理にとって重要なことは、SLA に署名する前に OLA の必要条件と SLO を評価し、妥当な IT リソース レベルを確認して、SLA が達成可能かどうかを検証することです。主要 IT レイヤ別の分析は、分析的アプローチとして、さらに検討を重ねる材料や OLA 目標値の制御ポイントにもなります。しかし、ほかのサービス コンポーネントの区分方法や、識別されたサブレイヤについて考慮する場合もあります。

IT サービスの SLA には、通常、特に可用性の必要条件に関する記述が含まれています。キャパシティ プランニングが不適切な場合にはサービスの停止を引き起こすおそれがあるため、正しいキャパシティ プロセスの制御、手順、作業、およびタスクを、可用性管理と協力して実行します。多くの場合、同じマネージャやスタッフがかかわることがあります。実際的な観点からいえば、明確な区別を行って、各プロセスの固有のタスクや、明らかにキャパシティ対可用性という視点で捉えるべきタスクを分離すべきです。

すべての関係者が、OLA に含まれる内容と初期目標値に合意する必要があります。組織もサービスの状況も、ひとつとして同じものはありません。内容も、SLA の種類によって変わります。キャパシティ管理は、一般に、マイルストーンの見直し、対象となる範囲とサービスおよびその説明、除外されるサービス、責任、およびサービス プロバイダ条項に関連します。サービス プロバイダ条項は、対応する OLA および各主要 IT レイヤの特定の運用レベル目標 (OLO) の基になります。

サポートするサービス レベル目標と同様、運用レベル目標には対応しなければならない特定のパフォーマンスの対象があります。IT サービス スタックの各レイヤの必要条件と目標値、たとえば可用性、サービス継続性、キャパシティ、セキュリティ、および要員などに対応する必要があります。サービスが使用できなくなる以前にキャパシティの低下や減少が発生することが多いため、SLA の可用性条項にはキャパシティの監視と制御が前提として含まれています。

可用性対策は、一般的には、サービスを提供する IT ソリューションに埋め込まれています。このプロセスでは、"予期された" 状況に対応します。"予期された" という言葉は、発生の確率が高いイベントを指します。つまり "予期された" という中には、通常の操作だけでなく、しばしば発生する障害も含まれています。

サービス継続性管理では、より極端でコストのかかる、または予測不能の可用性リスクを扱います。各主要 IT レイヤまたはソリューションの各コンポーネントについて、そのレイヤの障害に対するサービスの脆弱性によって査定されたリスクがあります。このリスクは、リスクを軽減するためのコストと比較しなければなりません。情報技術 (IT) 管理では、リスクの軽減コストを想定 (緊急事態対策) するか、またはリスクのコストを想定 (可用性) します。通常、可用性の勧告はキャパシティの勧告と関連し、勧告が承認されると、変更管理を介して生産環境に実装されます。

仮定条件
MOF (Microsoft Operations Framework) では、IT プロセスの実行面と維持管理面に焦点が置かれています。しかし、MOF の最適化フェーズの統合プロセスとして、MOF に、より完全で現実的なキャパシティ管理の必要性があることから、サービス管理へのライフサイクル アプローチが行われるようになりました。最適なパフォーマンスおよびキャパシティ レベルは、多くの場合、IT サービスが実装された後に査定されます。一般的に、影響が大きく可視性を備えた IT サービスでは、ビジネス全体の成功にとってはビジネス アプリケーション、ソリューション、またはシステムのライン部門が不可欠です。理想的には、MOF の実装段階で経営陣と IT 管理グループがキャパシティ プランニングの重要性と、運用キャパシティ管理の監視、分析、チューニング、タスクの実装という継続的サイクルを早い段階から開始する構造的アプローチの必要性を、前もって考慮しておきます。ITIL (Information Technology Infrastructure Library) および MOF では、未熟な IT 組織ではキャパシティ管理を急いで実行に移す場合があることを認識していますが、キャパシティ プランニングを取り囲むライフサイクル全体を通しての必要条件をより詳しく検討することが大切です。

マルチレベルの SLA は、大規模なエンタープライズで広く採用されています。マルチレベル SLA は、一般に、ビジネス エンタープライズ内の複数の組織に提供されている複数のサービスを対象とします。マルチレベル SLA は、サービス ベース SLA と顧客ベース SLA の複合形式です。このシナリオでは、一般的な 3 層構造が適用されます。マルチレベル SLA からキャパシティ関連目標を作成するときの原則、および主要 IT レイヤにおけるパフォーマンスとリソースを監視する際のしきい値の実装は、実質的にはシングル レベル SLA の場合と変わりません。詳細については、『MOF 運用ガイド』の「サービス レベル管理運用ガイド」を参照してください。

この文書においては、SLA と OLA、そしてその目標値は同義と見なします。というのは、SLA に準拠するには各 IT レイヤの OLA に準拠している必要があるからです。IT サービスの提供は、キャパシティ上の制約または各レイヤのコンポーネントにおける可用性の最低値に依存します。詳細については、『MOF 運用ガイド』の「可用性管理運用ガイド」を参照してください。

リソースとサービスパフォーマンスの管理
キャパシティ管理では、IT リソースの使用状況を最適化して、クライアントと合意したパフォーマンス レベルを実現します。これらの IT リソースは、すべてのサポート組織から供給され、ビジネス要件の達成を確実にします。キャパシティ管理のプロセスには、事後的なものと予防的なものがあります。監視、分析、チューニング、およびレポート作成など毎日繰り返される作業は、リソースやサービス パフォーマンスの管理プロセスにおいては重要な作業です。管理の対象によってデータの種類も異なります。たとえば、個々のコンポーネントの利用状況レベルは IT リソース管理の対象であり、トランザクション スループットと応答時間は、サービス パフォーマンス管理の対象になります。

ここでは、キャパシティ管理の一般的入力データと出力データ、および全体のプロセスをサポートするサブプロセスを説明します。

図 1: キャパシティ管理の入力データ、出力データ、およびサブプロセス

以下は、キャパシティ管理に関する入力データ、またはデータ供給源の例です。

• 新しいテクノロジおよびサービスの外部提供業者

• ビジネス方針およびそのプランと関連する必要条件および IT サービスへの要求

• キャパシティ管理のライフサイクルによって影響を受ける現在の IT 予算

• テクノロジの動向とそれに関連する IT 組織の技術的戦略と計画

• キャパシティ管理に関連するインシデントや問題へのサービス デスクの対応方針

• キャパシティ管理に関連する FSC (変更計画) と実装作業

• 可用性管理の考慮事項と最新アーキテクチャの共同調査

SLA の内容を引き継ぐサービス レベル管理、リスクとコストの分析によるサービス継続性管理はソリューションのキャパシティとして提示され、パフォーマンス分析と勧告は、上の図にサービス レベル目標値として示されます。次にサービス レベル目標値が、各 IT レイヤの運用レベル目標値に渡されます。サービスの可用性は、キャパシティ管理が正しく実施されていないことによって影響を受けることがあります。このため、可用性とキャパシティ プラン、アーキテクチャ設計、実装、監視と制御は相互に関連しています。共同のプランニングと実装の考慮事項を前もって検討してから実施する必要があります。詳細については、『MOF 運用ガイド』の「可用性管理運用ガイド」を参照してください。

キャパシティ管理プロセスは、サブプロセスという機能プロセスのタスク領域に分割することができます。これらのタスク領域では、現在の状況と将来の状態を中心的に取り扱います。キャパシティ プランニングは、将来に目標を定めています。リソース キャパシティの監視とその使用量の測定は、現在の状況を把握するためのものです。サービス リソースの監視と制御によって得られた情報が、プランニングに活用されます。ビジネス要件、技術情報、および 関連する SLA のしきい値情報は、構成管理データベース (CMDB) から引き出すことができます。ただし、キャパシティとパフォーマンスに関する意思決定に必要な関連詳細情報もキャパシティ管理データベース (CDB) に保管され、クロスリンクされている必要があります。

キャパシティ管理は、以下のようないくつかのサブ プロセスで構成されます。

• 要求管理 このサブ プロセスでは、IT サービスの将来のビジネス要件が適切なタイミングで考慮され、プランニングされ、実装されるようにします。キャパシティ管理スタッフがこのサブ プロセスを達成するには、各種 IT ソリューションの現在のリソース使用状況を分析し、傾向と予測を作成します。将来の必要条件は、現在および将来の顧客ニーズを継続的に調査している会計管理から提供されます。

• 作業負荷管理 このサブ プロセスでは、顧客の要求を IT ソリューションのコンポーネント (実際のソリューションの作成に使用する各種アプリケーション) にかかる作業負荷に変換します。この分析を基にして必要なリソースが決定されます。このプロセスでは、現在と将来の両方の要求を作業負荷に変換します。これによって、計画対象期間のリソース使用量の予測を作成できます。

• リソース管理 このサブ プロセスでは、主に、IT インフラストラクチャの個々のリソースを管理します。作業負荷を基に、現在および将来に必要なリソースを決定します。すべてのリソースが、適切なタイミングで対費用効果の大きい方法で取得され実装されるようにします。

• パフォーマンス管理 このサブ プロセスでは、主に、顧客が使用する IT ソリューションのパフォーマンス、およびソリューションが依存する基本リソースのパフォーマンスを管理します。業務としては、技術インフラストラクチャの主要 IT レイヤに対して設定されている OLA 目標に従って、すべての IT ソリューションのパフォーマンスを監視します。また、基本リソースの使用量を確実に監視します。収集されたデータはすべて記録、分析、レポートされます。キャパシティ管理スタッフは、必要に応じて、ソリューションのパフォーマンスがビジネス要件に適合していることを確認します。サービスの監視と制御の方針が、このサブ プロセスの鍵になります。

• アプリケーションサイジング このサブ プロセスでは、提案されたアプリケーションおよびサービス レベルをサポートするリソースを予測する手法を確立します。対象には、新しいアプリケーションまたは既存アプリケーションや危機管理シナリオの主要な変更によって生じた、主要 IT リソースとコストの必要条件が含まれます。

• モデリング これは、キャパシティ管理の意思決定を可能にし、作業負荷の個々のモデルと作業負荷全体にわたって調整されたベースライン モデルを、キャパシティ管理データベースにデータとして正しく格納するための、データ解釈の重要な手法とメソッドです。傾向分析から見積もりを算出する方法、または、よりコストがかかり精度が高いキューイング、分析またはシミュレーションによるモデリングなど、いくつかのアプローチがあります。

キャパシティ管理の出力データは、ほかのサービス管理プロセスや組織内のほかの部門で、またはプロセス内のほかの部分で、次のように利用されます。

• キャパシティ管理プロセス内 たとえば、パフォーマンス管理の一環として監視されて収集されたデータを、顧客からの要求や将来予測の変化に応じて、どのハードウェアまたはソフトウェアをいつアップグレードするかの判断材料として使用します。

• ほかのサービス管理プロセス たとえば、キャパシティ管理プロセスで新しいサービス レベル目標を検証し、ハードウェアまたはソフトウェアのアップグレードや新しい装置の購入に予算作成が必要な時期を識別して、コスト管理プロセスを支援します。

• IT 部門内のほかのチーム たとえば、キャパシティ管理がサービスの実行時期について勧告した変更を、IT 部門は使用可能なリソースで最も有効で効率的に使用されるよう、その変更を実装する必要があります。

多くの場合、システムは複数の物理階層上で動作し、各階層にはそれぞれのハードウェア、システム ソフトウェア、およびアプリケーション ソフトウェアがあります。人材、プロセス、およびテクノロジが IT サービス組織の世界を構成しています。キャパシティ プランニングに不備があると、予定外のダウンタイムを引き起こし、IT サービスが影響を受けることがあります。

図 2: 予期しないダウンタイムの推定原因 - Gartner、1998

Gartner Group の推定によれば、IT に関して発生する問題のうち、テクノロジを原因とするものはわずか 20% であり、人為的原因およびプロセスの不備によるものが 80% を占めています。新しいシステムを設計し配置するときは、それをサポートする人間に十分な準備ができていることが重要です。IT 部門に顧客との SLA を達成しようとする場合、質の高いサービスを提供するには適切な人材の教育と動機付けが必要です。このことは、予定外のダウンタイムを削減し、品質の高いサービスを提供するには、教育と手順の改善が重要であることを示しています。

効果的なキャパシティ管理は、予想外のリソースの制限によるアプリケーション障害やキャパシティ上の制約による予期できないダウンタイムの削減を追求します。予防的なプランニング、変更と実施手順、適切なドキュメント化、トレーニングなどを組み合わせることによって、オペレータによるエラーの発生を減らすことができます。キャパシティ管理では、ユーザーの現在と将来の両方のキャパシティ要求を確実に満足できるようにします。組織のニーズを満たすことができないシステムは、ほとんど利用されません。

サービスに対する現在および将来のキャパシティ必要条件は、SLA に定められています。これらの必要条件は、技術インフラストラクチャの各主要 IT レイヤの OLA に細分化されます。IT スタックのあるレイヤに障害が発生すると、サービス全体に障害を引き起こすことがあります。情報技術 (IT) サービスの品質は、最も弱いレイヤによって決まります。たとえば、ハードウェアは適切にサイジングされていても、ネットワークがサービス全体のボリュームを処理できない場合があります。情報技術 (IT) では、各レイヤの観点からキャパシティ要件を検討する必要があります。

キャパシティの提供に必要なテクノロジ ソリューションが、可用性の提供に必要なテクノロジ ソリューションと同じになることはよくあることです。たとえば、ソリューションをクラスタ化すれば、多くの場合、両方の機能が提供されます。また、ある実装コストが、可用性ニーズへの対応というだけでは認められない場合があります。しかし、これにキャパシティ ソリューションへのニーズが加われば、両方の要件によって実装コストの妥当性が認められます。したがって、可用性とキャパシティの実装においては、共通のテクノロジ ソリューションで両方のニーズを満たすことができないか、慎重に検討する必要があります。

IT サービスのパフォーマンスを効果的に管理するためには、IT サービスが SLA の目標を満たしているかどうかを確認するため、ピーク時および最小使用量時の IT リソースの使用状況とその機能の使用量を識別し理解する必要があります。目的は、サービスがリソースの使用量レベルによって左右される場所で、サービス パーフォマンス上の問題を予防的に予測することにあります。このような使用状況のパターンには、通常、山と谷があります。このデータの監視を支援するツールもあります。キャパシティ マネージャは、監視に必要なツールのコストを評価して、IT サービスの円滑な運用を実現することが重要です。一般的に、監視の作業は短期的であり、より長期的な動向やレポートはキャパシティ プランとして要約されます。

図 3: リソース管理およびサービスパフォーマンス管理に関する反復作業

これらの作業は繰り返し実行するものであり、パフォーマンス管理やリソース管理のより大きなサブ プロセスに寄与する日常の運用タスクが、これに当たります。

パフォーマンス管理はできるだけ予防的に行って、問題を前もって封じ込める必要があります。サービスのパフォーマンスは、スループット、応答時間、およびコンポーネント リソースから構成される、IT サービスの可用性の組み合わせによってほとんど決定されます。

リソースの利用状況は、多くの場合、パフォーマンスと相関関係にあり、監視、分析、チューニング、および実装などの反復作業と同じサイクルを持っています。リソース管理は、使用量のピークによって決まります。提供されている IT サービスがピーク時の顧客を処理できれば、非ピーク時の顧客は処理できることになります。

収集されたデータが分析され、チューニングの実施やプロファイルの作成に使用されます。このようなプロファイルを基に、しきい値とアラームが識別され設定されます。例外レポートやアラームが発生したときは、それらの問題を分析、報告し、対応策を取る必要があります。理想的には、しきい値およびアラームは OLA の目標値以下に設定します。これによって、OLA の目標値に違反する前にキャパシティ管理によって対応策を取ることができます。

使用レベルとしきい値を監視し、ルールに基づいて自動的にアクションを実行するよう特化されたパッケージ ソフトウェア ソリューションは、さらに総合的に、そしてさらにインテリジェントになりつつあります。基盤となるデータは、サービス全体に寄与する基本コンポーネントごとに、より細かな情報と向上したビューで表示されます。場合によっては状態インジケータとビューが、ビジネス プロセスと直接に関係しています。

リソース要件の決定には、以下の 3 つの要因が大きく影響します。

ユーザー数 アプリケーションまたはサービスが処理するユーザー数が増大すれば、キャパシティも増やす必要があります。キャパシティを増やさなければ、パフォーマンスの低下が発生します。

アプリケーションまたは Web サイトのコンテンツの複雑度 アプリケーションが複雑になるほど、1 ユーザーあたりのサーバーの仕事は増え、サービス パフォーマンス レベルに影響を与えるシステム全体のキャパシティは減少します。逆に言えば、アプリケーションをチューニングしたり修正することによってキャパシティを増大させることもできます。Web サイトの場合には、コンテンツを簡単にしたり、いくつかのデータベース使用や動的コンテンツの使用を止めたり、より簡単な HTML ページを提供したりすることによってキャパシティを減らします。

サーバーのキャパシティとハードウェアおよびソフトウェアの構成 コンピューティング インフラストラクチャをアップグレードすることによって、サービスのキャパシティを増大させ、より多くのユーザーまたはより複雑なソリューション、あるいはこの両方を組み込むことができます。

一般的に、サービスのキャパシティに影響を与えるのは、以下の 4 つのコンポーネントです。

• CPU 処理パワー

• メモリ利用状況

• I/O スループット - ディスクまたはデータ コンテンツのアクセス速度

• ネットワーク利用状況 - ローカル エリア ネットワーク (LAN) およびインターネット

監視
キャパシティ管理は、内部の運用レベル目標 (OLO) および全体的なサービス レベル契約 (SLA) に寄与する各主要 IT レイヤの関連メトリックにかかわっています。各リソースおよびサービスの利用状況を稼働中に監視し、ハードウェアおよびソフトウェアの最適使用を図って、合意されたサービス レベルがすべて達成されるようにすることが重要です。

多くの監視作業は、本質的には短期的であり、運用の原則に従って基本ツールを使用します。収集された情報は一定期間にわたって記録されるかサンプリングされます。サンプリングの量と作業に必要なリソースも調査する必要があります。キャパシティ管理データベース (CDB) には、過去の傾向とパターンを識別するための情報ポイントが含まれていなければなりません。詳細については、『MOF 運用ガイド』の「サービスの監視と制御運用ガイド」を参照してください。

データは、リソースの総利用量レベルだけでなく、各サービスによって特定リソースにかかる作業負荷の詳しいプロファイルも収集する必要があります。これは、インフラストラクチャ全体、ホストまたはサーバー、ネットワーク、ローカル サーバー、アプリケーション、およびクライアント側またはワーステーションについて実施しなければなりません。同様に、可用性やユーザー画面の応答時間など、各サービスのデータも収集する必要があります。

監視作業は、通常の運用レベルのベースラインまたはプロファイルを使用して行います。正常値を超えるしきい値に達した場合、アラームが発生して例外レポートが作成されます。これらのしきい値とベースラインは、これまでに記録されたデータから決定され、以下のような対象に設定できます。

• 個々のコンポーネント、たとえば 1 時間の維持期間内に CPU 使用量が 80% を超えないように監視します。

• 特定のサービス、たとえば、Web ページの表示に要する時間が 3 秒を超えないように、またはトランザクションが 1 分あたり 1000 を超えないように監視します。

また、監視にもシステムのキャパシティは消費され、したがってシステムのパフォーマンスに影響を与えることがあることを忘れないでください。パフォーマンスの測定とモニタでは、クライアントのサービス レベル契約 (SLA) に重点を置きます。運用レベルの必要条件など、監視に必要な要素は、多くの場合、SLA の達成に全面的に寄与するという条件から外れます。OLO を確実にするための連続する制御レベル (たとえば、ネットワーク、OS、ハードウェア、アプリケーションなどの主要 IT レイヤ) のモニタは、条件に適合します。

オペレーティング システム、アプリケーション管理、関連ハードウェア エージェント、およびシステム管理ツールによって、どのモニタが最も容易に使用できるかが指示されます。多くの場合、ビジネス ルールによって、要素データをサービス レベルに相関させることができます。多くのモニタはオペレーティング システムの一部として含まれるか、ハードウェアまたはソフトウェア ベンダ ソリューションの一部として無料で付属していますが、その他、大規模なシステム管理ツール セットの一部として、個別に評価して購入しなければならないものがあります。モニタは、キャパシティ管理プロセスに必要なすべてのデータを、特定のコンポーネントまたはサービスについて収集できることが重要です。

分析
前述のように、主要な IT レイヤは、監視およびチューニングが可能なコンポーネントを区分するための分析でも役に立ちます。

• サービス

• アプリケーション

• ミドルウェア (データベースを含む)

• オペレーティング システム

• ハードウェア

• ネットワーク (ローカル エリア ネットワーク)

• 設備

• 外部サービス (電力、水など、IT の外部から提供されるサービス)

監視され収集されたデータは分析され、チューニングの実行とプロファイルの作成に使用されます。これらのプロファイルは、しきい値とアラームを正しく識別し調整するために重要です。例外レポートまたはアラームが発生したときは、それを分析してレポートを作成し、対策を実行する必要があります。理想的には、すべてのしきい値を、リソースが過剰使用になるレベルより低く、または OLA または階層化された OLO の目標値より低く設定します。これによって、OLA の目標値に違反する前、またはリソースが過剰使用になってパフォーマンスが低下する前に、キャパシティ管理による対応策を実行することができます。

サービス カタログは、サービス キャパシティ ビジネス影響分析 (BIA : Service Capacity Business Impact Analysis)、投資効果 (ROI : Return on Investment) 分析、IT サービス継続性プランニングのキャパシティ条件の観点から見直し、作業負荷関連の問題および要求管理のフィードバックを行うときの当初のベースラインとして利用できます。

監視で収集したデータを分析して傾向を識別し、それを基にサービス レベルの通常の使用状況、つまりベースラインを確立することができます。定期的に監視してこのベースラインと比較することにより、個々のコンポーネントの使用状況の例外条件やサービスのしきい値を定義して、OLA の違反または異常接近を報告することができます。さらに、このデータを使用して、将来のリソース使用量を予測することもできます。

データの分析によって、以下のような問題を識別することができます。

• 競合 (データ、ファイル、メモリ、プロセッサ)

• 使用可能リソース間での不適切な作業負荷の分配

• 不適切なロッキング方針

• 非効率的なアプリケーション設計

• 予期しなかったトランザクション数の増加

• 非効率的なメモリの使用

各リソースの使用状況は、短期、中期、および長期的な視点で検討し、これらの記録期間における使用量の最小値、最大値、平均値を考慮する必要があります。一般に、短期的パターンでは 24 時間の使用状況を対象とし、中期では 1 ～ 4 週間、長期では 1 年間を対象とします。時間をかけるほど、各種 IT サービスによるリソースの使用傾向が顕著にわかります。

ソリューションが適切なレベルで稼働しているかどうかを判断する 1 つの鍵はレイテンシ (待ち時間)、つまり情報に関する 1 つの要求が完了するまでユーザーが待機しなければならない時間の長さです。サーバーの作業負荷が大きい場合、サーバーはすべての要求を処理することはできるにしても待機時間が許容できないほど長くなります。原則として、反復可能で、パフォーマンス レベルへの寄与の割合が大きいコンポーネントを特定し、それにさまざまな負荷をかけて報告します。

短期、中期、長期のそれぞれの使用状況を理解し、どのサービスの使用状況に変化があっても、個々のリソースの使用レベルに対して予測済みの変更に関連付けられるようにすることが重要です。特定の IT サービスが依存するハードウェアまたはソフトウェア リソースを識別するためには、正確で最新の総合的 CMDB が大いに役に立ちます。関連する詳細なパフォーマンス情報は、キャパシティ管理データベース (CDB) に関連付けられているか保存され、そこで管理されています。

特定のリソースの使用量を考慮するときは、使用量の総レベルと、個々のサービスによるリソース使用量の両方を理解することが重要です。

分析およびチューニングの作業には、この文書の「効果的なキャパシティ管理のためのガイドライン」および「スケーラビリティを備えた IT ソリューションの設計」セクションにある一般的な説明とガイドラインが役に立ちます。

チューニング
監視したデータの分析によって、システム リソースの使用状況を改善したり特定サービスのパフォーマンスを向上させたりするには、どの分野をチューニングすればよいかがわかります。

以下のようなチューニング手法が有効です。

• 作業負荷のバランス調整 - トランザクションは、そのトランザクションがどこから開始されたかによって、特定のゲートウェイでホストまたはサーバーに到着することがあります。ゲートウェイへの開始ポイントの比率を調整することによって、チューニングの成果を得ることができます。

• ディスク トラフィックのバランス調整 - データを効率的また効果的にディスクに保存します。たとえばデータを多くのスピンドルにストライピングすることによって、データの競合を軽減できることがあります。

• 受け入れられるロッキング方針の定義 - ロッキングが必要なタイミングと適切なレベルを指定します。たとえば、データベース、ページ、ファイル、レコード、行など。更新が必要になるまでロッキングを遅らせることで改善されることもあります。

• 効率的なメモリ使用 - 状況に応じて、メモリ使用量の増減の監視も含まれる場合があります。1 つのプロセスで、データがメモリに読み込まれてそこで処理される場合、ファイルから連続して読み込まれるよりもリソースを効率的に使用できます。一方、多くのプロセスではメモリ リソースの競合が発生することがあります。要求が多過ぎると CPU 使用量が増大し、ページがメモリにスワップ インおよびスワップ アウトする間の遅延が生じることがあります。

キャパシティの不足は、パフォーマンス上の問題が発生するまでわからないことがあります。ソリューションのキャパシティ傾向分析を活用して成長を予測する有効なチューニング ガイドラインを作成してください。提供業者やベンダが自社のパッケージ、ハードウェア、またはサービスを直接制御する場合は注意が必要です。特に、IT 組織の資格を有するメンバまたはキャパシティ管理スタッフが適宜監督する場合を除き、ベンダによるシステムのチューニングは許可しないようにします。

収集したデータから傾向を分析し、システムのチューニングや修正を行います。現在の正常なパフォーマンス レベルのベースラインが一定期間にわたって作成されます。このような時間経過によるリソース使用量のプロファイルはキャパシティ プランや推奨された変更にとって、貴重な指標であり入力データになります。これらのプロファイルを基に、しきい値およびアラームを識別して設定することができます。例外レポートまたはアラームが発生したときは、それを分析して報告し、対応策を実施する必要があります。理想的には、しきい値およびアラームは OLA の目標値より低く設定しておきます。これによって、OLA の目標値に違反する前に、キャパシティ管理で対策を実行することができます。

パフォーマンスのチューニングとは、システム リソースを最適化して、最大負荷の状態での許容できるトランザクション応答時間を達成することです。監視されたデータの傾向分析でも、成長の傾向が示されることが必要です。システムは、これを念頭において設計し実装しなければなりません。

新しいアプリケーションやシステムを設計または構築する段階でチューニングの勧告が行われ、ときにはアプリケーション サイジング ツールを介して勧告されることもあります。勧告を受けたら、検討する必要があります。柔軟なアーキテクチャが投資として優れている場合が多いのは、柔軟性のあるアーキテクチャは CPU、メモリ、ディスクまたは I/O 速度、またはネットワーク帯域幅などの主要分野を拡張したりチューニングすることができるためです。たとえば、データベース トランザクション ログ ファイルは、多くの場合、データ要素と同時にシーケンシャルに書き込まれます。ログ ファイルを書き込み用に保護され最適化されたディスク (たとえば個別のミラー化ペア) に分離することによって、データベースのパフォーマンスと可用性が強化されます。同様に多くのディスクにストライピングする速度、たとえば RAID (Redundant Arrays of Independent Disk) の各レベルはデータおよびインデックスのパフォーマンスを大幅に向上し、同時にチューニングのオプションを提供します。ハードウェアやソフトウェア プラットフォームに関するホワイト ペーパーやテクニカル ノートで、キャパシティの設計や導入後のソリューション全体のチューニングを向上するための詳しい手法を参照するのが良い方法です。

実装

• この作業の目的は、分析作業およびチューニング作業によって識別された変更を、稼働中のサービスに導入することです。

• この作業では、キャパシティの変更に対する勧告が既に承認されて、実装しようとしているところであると仮定します。サービスの稼働中に実行するよう計画された作業である場合もありますが、事後の対応であったり、サービスの停止を必要とする変更の場合もあります。

• 変更プロセス全体は、着実に制御されたペースで実行することをお勧めします。実装における変数の数を減らせば、プロセスを強化することができます。

  変更の実装は、正式な変更管理プロセスを介して実行してください。システムのチューニングの変更は、顧客の満足度に大きな影響を与えることがあります。このような変更に関連する影響とリスクは、ほかの変更よりも大きい場合があります。厳格な変更管理手順に従ってチューニング勧告を実装することにより、以下の成果を得ることができます。

  • サービスの顧客に対する悪影響の減少

  • 顧客の生産性の向上

  • IT 担当者の生産性の向上

  • やり直しが必要な変更項目数の減少、ただし簡単にやり直しができる能力は向上

  • ビジネスの基幹アプリケーション サービスのより細かな管理と制御

重要なことは、変更による効果を査定できるように、さらに監視を継続して実施することです。最初の変更からさらにいくつか変更を加えたり、元に戻す必要がある場合もあります。

変更中に個々のサーバー (N+1) またはサーバーのセット (N+N) を切り替えてスムーズに移行する、つまり "ローリング アップデート" する方法では、コストとの均衡点を探す必要があります。ただし、ダウンタイムのコストを過小に見積もってはいけません。過小に見積もると、このようなキャパシティ変更の実装アプローチを容認することが多くなります。

結論として、有効なキャパシティ管理の実装には、慎重な分析と、ビジネス業務、そのプロセス、およびキャパシティが使用される原因または使用されない原因をよく理解することが必要です。コストは、キャパシティの原因とコストの種類によってキャパシティのカテゴリに適切に割り当てます。

監視、分析、チューニング、および (変更管理による) 実装という作業は、リソース管理とパフォーマンス管理の両方について繰り返し実行します。詳細については、『MOF 運用ガイド』の「ジョブ スケジューリング運用ガイド」、「記憶域の管理運用ガイド」、「サービスの監視と制御運用ガイド」、および「ネットワーク管理運用ガイド」を参照してください。

要求管理と作業負荷管理
当初のビジネス要件は、顧客またはエンドユーザーから収集します。このビジネス要件によって、IT サービスに対する要求が定義されます。このような、IT からのサービス提供に対する要求とサポートを管理する必要があります。これは、要求管理と呼ばれるキャパシティ管理の主要サブ プロセスです。

キャパシティ管理の中心は、リソース使用状況の識別と定量化です。使用レベルが要求と直接関連しているかどうか。関連していれば、要求を基に使用レベルを予測して、うまくいけば、要求の不足量を予測することができます。優れた設計にとって重要なのは、ピーク時の要求を予測して計画を立てることです。モデリングは、ピーク時負荷分析によって作業負荷リソースの使用量予測の作成を支援します。ベースラインによるモデルと実際のデータを比較することによって、データの減少を知らせ、CDB に保存される貴重な情報を提供し、キャパシティ管理の重要な出力データを生成します。

要求管理の第 1 の目的は、コンピューティング リソースへの要求とリソースの使用状況に影響を及ぼすことです。要求管理は、基本的に大きな影響力を持っています。ときには、IT サービスの料金還付を設定する方法も役に立ちます。この方法では、異なる料金を設定して需要を制御し、リソースをより最適に分配します。

この作業は、現在のキャパシティが業務の実行をサポートするには不十分なときは短期的必要条件として実行し、また時間をかけて実行する IT 管理の方針として、必要なキャパシティを長期間にわたって制限することもできます。

IT インフラストラクチャの基幹リソースの一部に障害が発生したときは、短期的要求管理を実行する場合があります。たとえば、プロセッサのメモリの一部に障害がある場合、サービスをフル稼働で運用することはできませんが、サービスの一部は実行できる場合があります。

キャパシティ管理では、それぞれのサービスのビジネス上の優先順位を認識し、各サービスのリソース必要条件 (上の例では、サービスの運用に必要なメモリ量) を知って、使用可能なメモリの量が限定されている間はどのサービスを稼働できるかを識別できる必要があります。

長期的要求管理が必要になるのは、コストの関係で高価なアップグレードが困難な場合です。たとえば多くのアプリケーションでは、1 日のうち 2、3 時間、普通は午前の中心時間帯と午後の中心時間帯に CPU の使用量が高くなります。この期間は、1、2 時間の間だけプロセッサは過剰負荷になることがあります。通常の営業時間が終われば、同じシステムでも CPU 全体の使用量はかなり低くなり、リソースの使用率は低くなります。アップグレードのコストをかけることが可能であれば、1 日の数時間だけ追加リソースを提供します。場合によっては、IT から要求側に働きかけて、リソースへの要求を 1 日の中でうまく分散し、アップグレードが不要になることもあります。

サービス カタログは、サービス キャパシティのビジネス影響分析 (BIA : Business Impact Analysis)、投資効果 (ROI : Return on Investment) 分析、IT サービス継続性プランニングのキャパシティ条件の観点から見直し、作業負荷関連の問題および要求管理のフィードバックを行うときの当初のベースラインとして利用できます。

要求管理では、どのサービスがどのレベルでリソースを使用しているかを理解し、それらのサービスをいつ実行することが必要か知っていなければなりません。それによって、リソースの使用に影響を与えることが可能かどうか、可能であればどのオプションが適しているかを決定することができます。

稼働中のサービスに影響を与える要因として、次のようなものがあります。

• 物理的制約 たとえば、一定時間だけサービスの一部を運用停止にしたり、同時ユーザーの数を制限したりして、特定のサービスの顧客数を制限する場合もあります。この制約は、ネットワーク ルーターまたはスイッチへの物理接続数を制限するなど、特定のリソースまたはコンポーネント上に実装されます。

• 金銭的制約 IT サービスに対する課金が行われている場合、1 日のうち低額でサービスを運用できる時間を設定することもできます。提供する時間は、現在リソースに対する需要が少ない時間帯にします。

サービスの顧客は要求管理の影響を受けるため、要求管理の実行は慎重に行い、ビジネス顧客や IT 組織の評判を傷つけないようにします。ビジネス要件と IT サービスへの要求をよく理解し、実行されているアクションについて、すべて顧客に情報を提供しておくことが必要です。

作業負荷管理の第 1 の目標は、計画期間中のリソース使用量の見積もりを示す一連の予測を作成することです。傾向の識別には大量の統計情報を必要とします。したがって、かなり長期にわたってデータを収集する必要があります。データの種類は、オンライン、バッチ、およびネットワークで、現在および提案されている顧客の需要を効果的に作業負荷に変換します。作業負荷の分類は、一般に "作業負荷カタログ" と呼ばれます。次のステップでは、各作業負荷の傾向を分析、理解して、ピーク発生時とその原因を特定します。この調査は、短期、中期、および長期の傾向について実施する必要があります。作業負荷カタログ、ピーク時負荷分析、および運用レベルの必要条件は、すべて予測レポートの作成データとして使用されます。

キャパシティ管理データベース (CDB)
CDB の重要性は、このデータベースがキャパシティおよびパフォーマンス関連情報の中心リポジトリであることに示されています。このデータベースには、これまで説明した入力データのほとんどが集められます。ここには、作業負荷や、顧客関係管理データベースが使用されている頻度などのパフォーマンス、記憶域の必要条件の将来成長予測の傾向などが集められます。このデータベースから、レポートの作成、キャパシティ プラン、パフォーマンスの監視、リソースの管理、および要求に関する情報が提供されます。

キャパシティ管理の入力データを紹介するときに、キャパシティ管理の出力データとサブ プロセスも図に示しました。入力データのほとんどに関連する詳細情報があります。必要な出力データを処理して作成するには、この情報をキャパシティ管理データベースで取得する必要があります。

CDB について考慮すべき入力データは、以下のとおりです。

• 財務データ – コスト

• ハードウェア データ

• 開発データ

• サービス データ - 問題/変更

• 危機管理データ - ハードウェアなど

• 技術データ - 可用性データなど

• ビジネス データ - 将来の方向および戦略

その他 CDB に入力できる詳細データは、以下のとおりです。

• キャパシティ プラン - 現在使用中、DTP ソフトウェア

• モデル ジェネレータ - サイジングおよびモデリングのパラメータ

• サイジング ソフトウェアの結果

• モデリング ソフトウェアの結果

• リソース利用状況モニタ - しきい値の例外

• サービス レベル管理 - しきい値の例外

• その他のパフォーマンス/監視 (サーベイランス) ソフトウェア

• 作業負荷パフォーマンス モニタ

  課金ソフトウェア

  • ビジネス予測の詳細

  • コスト プランニング ソフトウェア

CDB 情報によって使用できるデータ出力は、以下のとおりです。

• サービス レベル管理ガイドライン

• レポート - リソース利用状況の例外、SLM 例外など

• 予測

• キャパシティ プラン

• その他変更に関する勧告 - チューニング

ビジネスの基幹機能に予想しなかったダウンタイムが発生した場合、キャパシティ管理の問題がビジネスに大きく影響します。このため、キャパシティおよび可用性管理の考慮事項を合わせて検討し、ソリューションの設計に矛盾がないようにする必要があります。サービス継続性管理は、通常の可用性設計外のシナリオが発生したときのリスクとコストを比較検討します。緊急事態対策のプランニングでは、キャパシティの予測と勧告を利用して、選択した緊急事態対策のドキュメント化を進めます。その後、各プロセスの明確な必要条件を互いに関連させ、キャパシティおよびパフォーマンスのデータを識別して、CDB に正しく記録します。CDB 内のキャパシティに関する詳細データを OLA に関連付け、関連付けられた OLA と SLA の情報を構成管理データベース (CMDB) で追跡することが重要です。可用性管理情報では、パフォーマンスとキャパシティの測定データが正しく統合されていることが前提となっているため、キャパシティ スタッフと可用性スタッフは、多くの場合、共通の監視ツールや管理ソリューションを共用します。

ビジネス要件の管理
キャパシティ管理は、ハードウェア リソースによる最適使用を実現し、合意されたパフォーマンスとスループット レベルを達成し維持するために、既存サービスの監視とチューニングを行います。

"最適" とは、適切な場所、適切なタイミング、適切な量、適正な価格を意味します。パフォーマンスの必要条件は、サービス レベル管理プロセスによって設定された質および量についての標準が基になります。

優れたキャパシティ管理の 1 つの目的は、運用とビジネス要件の間のコミュニケーション ギャップを埋めることです。よく見られる問題は、IT 業務ではコンピュータ パフォーマンスの測定値、記憶域のメガバイト数、その他のキャパシティやスループットを表す式を扱うのに対して、財務やビジネスでは収益、キャッシュ フロー、投資利益などの財務上の表現を使用することです。詳細については、『MOF 運用ガイド』の「経費管理運用ガイド」を参照してください。

サービス レベル管理は、特定のサービスに "ビジネス価値" を付加する手助けをします。次に IT 組織は、そのサービスのニーズを満たすためのプランを立てることができます。そして、各 IT レイヤに対して運用レベル目標 (OLO) を作成します。OLO は複数の IT エンティティ間で合意された測定可能なサービス メトリック "対象" であり、参加したエンティティに提供されるサービスに適用され、OLA に記載されます。

運用レベル合意 (OLA) とは、複数の IT エンティティ間で結ばれる内部契約です。OLA は、IT の全参加者の責任を定義し、参加者に特定のサービスを提供する義務を負わせます。参加者は、提供されるサービスの品質と量の一定のレベルについて合意します。これは SLA によく似ていますが、通常は正式なものではありません。ただし、メトリックは CDB に保管する必要があります。

ビジネス、サービス、およびその必要条件を満たすための継続的な準拠サイクルの概要と例については、「継続的見直しとメンテナンス」のセクションを参照してください。

キャパシティプランの作成
キャパシティ プランには、将来的にどのキャパシティがいくらのコストで必要になるかを示さなければなりません。また、将来のサービス レベル目標を満たすために必要となるハードウェアのアップグレードや追加装置も予測し、提案された新しいシステムのサイジングに関する情報も提示します。コスト上の制約や可用性または信頼性に関する必要条件を反映する必要があります。

キャパシティ プランでは、現在のリソース使用状況およびサービス パフォーマンスのレベルをドキュメント化します。その際には、ビジネス戦略とプランを、提供される IT サービスまたは計画済みの新しいサービスをサポートするリソースの将来必要量予測に取り入れる必要があります。プランで作成される勧告には、必要なリソース、対応する影響、関連コストと利点などを定量化した詳細を記載します。

キャパシティ プランの作成と更新は、あらかじめ指定された間隔で定期的に行う必要があります。理想的には、ビジネス サイクルや予算のサイクルに合わせて、毎年プランを作成します。ビジネス プランの変更を考慮し、正確な予測値に基づいて報告を作成し、勧告を調整するためには、四半期ごとに更新プランの再発行が必要になる場合もあります。

キャパシティ プランは、あらかじめ指定された間隔で更新しなければなりません。最低限、ビジネス サイクルまたは予算サイクルに合わせて、年に 1 回は発行し、四半期ごとに再発行および更新する必要があります。これにはさらに多くの労力が必要ですが、定期的に更新すればキャパシティ プランの精度が高まり、ビジネス プランや要件の変更を反映できることになります。

はじめに

このセクションでは、背景となる情報を紹介します。ここでは、組織の現在のキャパシティ レベル、キャパシティの過不足によって引き起こされているまたは予測される問題、サービス レベルの達成割合、プランの前回更新または前回発行後の変更事項を説明します。

プランの範囲

理想的には、すべての IT サービスおよびリソースをプラン内で説明する必要があります。このセクションでは、プランで取り上げる IT インフラストラクチャ要素の詳細と範囲を説明します。

使用メソッド

キャパシティ プランでは、サブ プロセスによって収集された情報を使用します。したがって、このセクションではこの情報が取得された方法と時期、たとえばビジネス プランから取得したビジネス予測データ、ユーザーから取得した作業負荷予測データ、モデリング ツールを使用して取得したサービス レベル予測などの詳細を説明します。

管理の要約

キャパシティ プランには、プランのすべての読者が関心を持つとは限らない技術的詳細を記載する必要があります。管理の要約では、主な問題、オプション、勧告、およびコストを強調する必要があります。より詳細なプランの各セクションの主要ポイントを要約した、別の上級管理職用サマリを作成すると役に立つ場合があります。

ビジネス シナリオ

プランは、現在および将来のビジネス環境というコンテキストに当てはめる必要があります。たとえば、新しい CRM ソリューションが現在、既存プロセッサとメモリのキャパシティの 60% を、バックエンド データベースに使用している場合があります。キャパシティ管理は現在のシステムの監視を行い、年度内の成長を見込んだ推奨する CPU、メモリ、およびディスク キャパシティの追加量を予測することができます。

既知のビジネス予測をすべて明示的に記載し、読者がプランの範囲内または範囲外に何があるかを判断できるようにすることが重要です。

サービスの要約

提供されているサービスごとに、サービス プロファイルを提供する必要があります。ここでは、所定のトランザクション応答時間またはスループットに対するリソースの使用状況を説明します。たとえば、このセクションに示す短期、中期、および長期傾向によるプロセッサ、メモリ、記憶域、ネットワークの使用レベルなどです。

予測サービス レベル

ビジネル プランによってキャパシティ マネージャは、計画されている新しいサービス、および既存サービスの成長や縮小の詳細情報を取得します。このセクションでは、新しいサービスと、レガシー システムの使用終了について報告する必要があります。

リソースの要約

このセクションでは、サービスによるリソースの使用状況を中心に取り上げます。また、リソース使用状況の短期、中期、および長期の傾向をハードウェア プラットフォーム別に報告します。この情報は、リソースおよびサービス パフォーマンスの管理のサブ プロセスで収集、分析する必要があるため、いつでも使用できるようにしておかなくてはなりません。

リソースの将来予測

このセクションでは、サービスの将来予測から推定されるリソースの使用状況を予測します。ここでは、前に説明した各ビジネス シナリオについて説明する必要があります。たとえば、新しいインターネット店頭取り引きプロジェクト プランでは、安全なデビット取引を行うトランザクション レベルと応答時間の予測において、対応する特定のネットワーク帯域の必要条件を予測することが必要になる場合があります。

サービス改善のためのオプション

前のセクションの結果をふまえて、このセクションでは、サービス提供の有効性と効率性を改善するためのオプションの概要を説明します。この中には、異なるサービスを単一プロセッサに併合するためのオプション、技術の進歩を活用するためにネットワークをアップグレードするためのオプション、リソースまたはサービス パフォーマンスの使用状況をチューニングするためのオプション、レガシー システムをプログラミングし直すためのオプション、新しいハードウェアまたはソフトウェアを購入するためのオプションなどが含まれることがあります。

コスト モデル

このセクションでは、これらのオプションに関連するコストをドキュメント化します。また、IT サービスを提供するための現在および将来のコストも記載する必要があります。実際には、キャパシティ マネージャはこのような情報の多くは経費管理プロセスから入手します。

勧告

プランの最終セクションには、前のプランで作成した勧告の要約とその状態、たとえば却下、計画済み、実装済みなどを記載する必要があります。プランで説明したオプションのどれが望ましいかなど、新しい勧告があればここに記載します。

勧告では、期待されるビジネス上の利点、勧告の実施による潜在的影響、考えられるリスク、必要なリソース、立ち上げ時と継続のためのコストを定量化する必要があります。

一般的なレポートおよびキャパシティ勧告の対象となるのは、以下のような項目です。

• 現在のハードウェアでサポートされているユーザー数

• ユーザー数が増大した場合のスケーラビリティ オプション

• ソリューションの複雑度が増大した場合のスケーラビリティ オプション

• 監視、分析、またはチューニングについて推奨する変更

• 潜在的なボトルネック箇所の識別

• 設計および導入のパフォーマンス ガイドライン

• 将来のサービス パフォーマンスの予測

モデリング
モデリングは、キャパシティ管理プランニング プロセスの中心的な要素です。シミュレーション ソフトウェア技術の進歩と効果的な使用によって、スケーラビリティと高可用性を備え、可用性管理に役立つキャパシティ プランニング シナリオを調査することができます。サービス継続性管理の危機管理シナリオの調査とコスト計算も行えます。

キャパシティ モデルには、生産性、非生産性、およびアイドルというキャパシティ使用に関する 3 つの主要カテゴリがあります。

定格キャパシティ = 生産性キャパシティ + 非生産性キャパシティ + アイドル キャパシティ

定格キャパシティは 100%、つまり年中無休の稼働を表します。特定のリソースを測定している場合は、修理、セットアップ、その他のダウンタイムによる誤差を除く、完全に生産性に寄与するキャパシティを指します。

生産性キャパシティとは、リソースが機能を完全に発揮して IT サービスをサポートしている状態です。

非生産性キャパシティとは、特定のアイドル定義に含まれない時間です。非生産性作業とは、インストール、メンテナンス、待機、その他のサービス休止の状態です。

アイドル キャパシティとは、技術上、契約上、またはビジネス上の理由による未使用、不要、または使用不能な状態です。

モデリングでは、各リソースがソリューション全体のスループットに与える影響の分離を試みます。

モデリングには、ほかのキャパシティ管理アクティビティからのデータ、特に開発中のアプリケーションと関連ハードウェア仕様による作業負荷およびリソース使用量の予測が重要になります。モデリングは、傾向分析によってキャパシティ (最小コスト) の "価値" を決定できなければなりません。モデリングには、過去の数値に基づく学問的推測を可能にするための見積もりを行うこともありますが、キューイング モデル、分析モデリング、または実際のアプリケーションのシミュレーションの決定事項を基にする方が、より正確で優れた方法といえます。

IT サービス データに基づくアルゴリズムを使用した分析モデリングでは、一般的に、予測的および予防的キャパシティ情報を生成する精巧なソフトウェアを使用します。

シミュレーション モデリングは、通常、分析モデリングよりも正確です。これは、シミュレーション モデリングの方がよりアプリケーションの状況に近いためです。このモデリングでは、スクリプトの準備や実際的なトランザクション負荷の生成にかなり多くの時間とコストがかかります。ユーザーの対話をキャプチャしてさまざまなレベルで再生する、特化されたソフトウェアを使用すれば、この種のモデリングの対費用効果を高めることができます。

現在のシステムのパフォーマンス レベルを正確に反映する "ベースライン" モデルの確立が、重要な第一歩です。これによって、さまざまな作業負荷においてハードウェアを計画的に変更する、"状況別予測" シナリオを作成することができます。パフォーマンス レベルの予測が正確に作成できるかどうかは、ベースライン モデルの精度と、そのモデルが予測モデルに必要な変更を組み込んで反映できる能力を備えているかどうかにかかっています。

モデリングには、プロトタイプのベンチマーク作成も含まれることがあります。コンピュータの場合、ベンチマークとはあるコンピュータ システムのパフォーマンスとほかのコンピュータのパフォーマンスとを比較するために設計されたテストまたは一式のテストです。

必ずしも、ベンチマークのデータだけがキャパシティ管理ツールに有効なわけではありません。たとえば、特定の用途に必要なシステムの適正サイズを推定したい場合は、ベンチマークでは役に立たない場合があります。キャパシティ プランニングに有効なツールであるためには、テストを目的の使用状況に合わせて簡単に設定できる必要があります。有効なベンチマークを実現するには、テストを厳密に指定し、テスト対象のすべてのシステムが比較可能な作業を実行するようにしなければなりません。この 2 つの目的は、相反しています。その結果、ベンチマークは通常、システムを互いに比較するのに便利であり、ほかのテストは個々のニーズにどんなシステムが適しているかを知るために使用されます。

最も単純で費用のかからないモデリングでは、経験と現在のリソース使用量に基づいて見積もりが作成されます。日常のちょっとした意思決定には、これが実際的かもしれません。コストや時間をかけることができる大規模プロジェクトでは、パイロット スタディ、プロトタイプ、またはフルスケールのベンチマークの方が適していることが考えられます。ハードウェアおよびソフトウェア導入へのアーキテクチャに基づく方式、たとえば低コストのプールされた冗長記憶域によって、環境に対して重大な変更を行うことなくスケーラビリティを獲得することができる場合があります。有効なパイロット テストでは、制御を合理的に分離できる、できるだけ多くの変数の機能テストを実行する必要があります。これらの変数は、一定時間不変 (一定) でなければなりません。また、"壊れる" ところまで実行可能な場合は、ソリューションに過負荷をかけるストレス テストも実施します。これによって、ソリューション内でネックとなっているリソース コンポーネントがわかります。キャパシティ管理作業の多くはプロジェクトとして実行し、署名権限を持つ IT 運用管理担当重役が設計側とエンドユーザー側間の緊密な調整を行います。

フィージビリティ スタディでは、モデリングおよびコストの情報を利用してさらに改善点を識別し、"可用性の査定" と組み合わせることで、さらに総合的なキャパシティ プランを作成し、現在のハードウェアや関連コンポーネントのアップグレードでは解決できない問題を解決することができます。技術の進歩は多くの分野で進んでおり、これらの分野では以前に存在していたボトルネックがほかの分野にシフトし、その後そのボトルネックも改善されます。進歩は常に進行中であり、キャパシティ管理チームは新しいテクノロジに遅れないように、現在のソリューションの必要性を診断した後でも改善方法をさらに支援し識別できるようにしなければなりません。新しいハードウェア アーキテクチャでは、多くの点でパフォーマンスやスループットが最適化できます。

前に、キャパシティ管理に関するプロセッサ、メモリ、I/O または記憶域、ネットワーク パフォーマンスの重要性を強調しました。CPU は、いくつかの仕事の単位に相当する命令を実行します。CPU には、参照中にデータを格納する高速キャッシュ バッファが 1 つまたは複数備わっています。オペレーティング システムは、CPU をスレッド化またはディスパッチ化して、1 単位の作業を実行できます。CPU はときにはプロセッサとも呼ばれますが、複数の CPU を搭載した複合プロセッサと混同しないでください。

ベンダのハードウェア システム プロセッサ モデルは 1 つまたは複数の CPU の組み合わせであり、中央および拡張記憶域、I/O プロセッサおよびほかのサブシステム支援プロセッサ (これも CPU)、そして各種レベルのキャッシュ バッファ記憶域と共に提供されています。サーバーは、多くの場合、プロセッサ、メモリ、およびネットワーク カードその他周辺機器用スロット、および記憶装置を内部的に拡張したものとして分類されます。

中央処理装置 (CPU) の速度は、1 つの CPU が仕事を処理できる相対能力として定義されています。速度の速い CPU は、同じ CPU 時間内により多くの仕事を処理できます。CPU の速度は、多くの場合、対象となるアプリケーションまたはサービスに関して合意した標準的な測定条件で計測します。この測定条件の単位として、以前は Digital VAX 11-780 に関する規格として、1 秒あたりの命令数 (MIPS) が使用されました。複数 CPU モデルの 1 つの CPU の速度が、比較のベースラインになります。しかし、対費用効果の大きいソリューションを勧告するには、複数の CPU によるアプリケーションのスケーラビリティを考慮することが重要です。

SPECmark スイートは、CPU、オンチップ キャッシュ、浮動小数点処理に関するより意味のある測定方法として作成されました。SPEC (Standard Performance Evaluation Corporation) では、ベースラインとは、特定のベンチマークに合わせてチューニングされたものに比べてより一般的で単純な設定のことを言います。通常は、"ベースライン" の設定は作業負荷が変化しても有効である必要があり、そのため、利用する機能の使いやすさの必要条件など、さらに細かい制限がある場合があります。一般にベースラインは、ピーク時設定と代替可能です。ピーク時構成は、特定の単一作業負荷で最高の結果を獲得するようにチューニングされた構成です。通常、これが達成可能な最高のパフォーマンス レベルを示します。

マルチプロセッシングの場合、OS のスレッド化と関連サービス、またはアプリケーションとそのスケーラビリティが、最適なパフォーマンスの決定には重要です。線形のスケーラビリティが理想であり、その場合は CPU を追加すると、各 CPU ごとに同じ一定のレベルでパフォーマンスが追加されます。

さまざまな作業負荷での速度とキャパシティを示すプロセッサ モデルに、たった 1 つの規格を当てはめるのは現実的ではありません。これは、予測される走行距離に基づいて車を購入するのに似ています。1 リットルで 18 キロ走行できるという規格の車が、その速度のまま実際に走れることはめったにありません。一般的に、車は、テスト ドライバがその規格を記録したときと同じ状態で運転されることはありません。交差点と交差点の間では車のスピードを上げ、必要に応じて何度もブレーキを踏んでいるような状態では、規格どおりの距離を得ることはできません。メーカーが推奨する速度で、同じような交通量で、同じような路面で、同じような積載量で、エアコンをオフにして走れば、算定された距離に近い距離を稼ぐことができるかもしれません。プロセッサ モデルにも同じことが言えます。

TPC (Transaction Processing Council) の一連のベンチマークは、クロスプラットフォーム データベースと制御されたトランザクション レベルの比較を提供するために作成されました。ベンチマークは便利ですが、特定のアプリケーションが対象の場合には、できれば、実際に近い方法でそのアプリケーションそのものをモデリングすることが重要です。ベンダのハードウェア プラットフォーム上でのクロスプラットフォーム バックエンド データベース ソリューションをより客観的に、狭い範囲で比較するには、TPC-C またはそれ以降が有用な場合があります。

ベンチマーク情報はモデリング ツールおよびソフトウェアに関連付けられていることがありますが、モデリングまたはベンチマークの結果はアプリケーション サイジングで使用する情報としても重要です。

アプリケーションサイジング

アプリケーション サイジングの目的は、提案されたアプリケーションおよびサービス レベルをサポートするためのハードウェア リソースの見積もりです。パッケージ化されたアプリケーションには、たいてい、アプリケーションが正しく動作するための最低必要条件に関するベンダ仕様が記載されています。多くのソリューションには複数のハードウェア階層と、テーブルやインデックスのカスタム設計に基づくデータベース ソリューションの規模があるため、アプリケーション サイジングのスタッフは、より効果的なハードウェア必要条件とアーキテクチャ設計を提供できる能力を磨く努力が必要です。また、提供業者が指定した必要条件の正確さもチェックする必要があります。

アプリケーション サイジングはシステム必要条件の見積もりを作成するだけでなく、新しいアプリケーションまたは変更されたアプリケーションに期待されるパフォーマンス、特に現在の作業負荷に関するパフォーマンスの情報を提供しなければなりません。理想的には、アプリケーション サイジングで、開発または立ち上げプロセスの各段階で予測されたサービス レベルのフィードバックを提供します。このようなサポートは、パフォーマンスが現在 SLA に定められているレベルに対応しない場合に、サービス レベルを修正したりシステム必要条件を変更したりする作業に役立ちます。

負荷をシミュレーションしたり、実際のユーザー トランザクションを負荷を一定量ずつ増加させながら生成するツールがあります。これらのツールは、アプリケーション サイジングに大変便利です。よりハイエンドのツールを取得する際には、事前に、評価基準 (できれば ROI を含む) をよく吟味し、客観的に採点しなければなりません。また、モデリングの結果や実際のアプリケーションに近づける、またはアプリケーションを特性付けるベンチマークも、アプリケーション サイジング プロセスの重要な部分です。外部からの情報も、有用性を継続的に見直す必要があります。

設計の段階でも最適化の段階でも、また可用性やスケーラビリティに関しても、多くの考慮条件があります。主要 IT レイヤ (アプリケーション、ミドルウェア (データベースが最重要)、OS、ネットワークなど) をできるだけ考慮に入れる必要があります。多くのベンダから、強力なサポート ツールやナレッジ ベースが提供されています。

社内のカスタム サイジング ツールにかかる時間やメンテナンス コストを調査する前に、プラットフォーム ベンダから提供されているアプリケーション サイジング ツールを慎重に検討する必要があります。また、ベンダのホワイト ペーパーやテクニカル ノートを参照して、システム必要条件、サイジング、およびチューニングの勧告、および実装後の潜在的ソリューション パフォーマンスの改善など、最良の方法を確認します。

効果的なキャパシティ管理のためのガイドライン
一般的に、ビジネス上の視点と技術上の視点があります。たとえば、ガソリンの販売を例として考えてみましょう。ビジネスの観点では、販売されるガソリンの量と 1 リットルあたりの価格が中心になります。技術的な観点では、事前認証されたクレジット カードでトランザクションが開始され、ガソリン ポンプを元の場所に戻すとトランザクションが終了するシステムの、2 相データベース コミットの設計、監視、および制御の方が関心の対象になります。MOF の最適化フェーズのプロセスでは、両方の観点から考慮することが重要ですが、焦点はやはり適切な情報の提供にあります。

キャパシティとパフォーマンスは、同じものではありません。パフォーマンスとは、一般的に、アプリケーションを中心に応答時間とスループットによって測定されるすべてのものを含む用語です。アプリケーションの設計は、使用するリソースのキャパシティだけでなく、パフォーマンスにも影響を与えます。キャパシティは、CPU、メモリ、ディスク サイズや速度、通信帯域幅などのリソースの割り当てを中心とする、パフォーマンスの重要な構成要素です。

予防的キャパシティ管理は、可用性を最適化し、基幹 IT レイヤのダウンタイムを軽減する、IT の手段です。キャパシティ分析にあたっては、IT サービスとソリューションのレイヤをさらに細かく識別することをお勧めします。

ゆっくりと制御されたペースで変更を実行し、導入される変数の数を減少することによって、分析、実装をさらに改善し、また、予定外のダウンタイムを短縮します。

トランザクション コスト分析 (TCA : Transactions Cost Analysis) 手法によって、キャパシティ チューニングの勧告と将来成長に備えた計画的キャパシティ拡張のためのより正確な情報が提供されます。トランザクション コスト分析では、通常、各ユーザーがシステムにかける処理コストを計算することができます。

アプリケーションのパフォーマンスを向上させたい場合は、パフォーマンスの目標値とそのほかの条件がつりあうところを見つける必要があります。このプロセスは、開発スケジュールや優先順位との調整が難しい場合もあります。

キャパシティ モデルには、生産性、非生産性、およびアイドルというキャパシティ使用に関する 3 つの主要カテゴリがあります。定格キャパシティは 100%、つまり年中無休の稼働を表します。特定のリソースを測定している場合は、修理、セットアップ、その他のダウンタイムによる誤差を除く、完全に生産性に寄与するキャパシティを指します。

定格キャパシティ = 生産性キャパシティ + 非生産性キャパシティ + アイドル キャパシティ

生産性キャパシティとは、機能を完全に発揮して IT サービスをサポートしている状態です。

非生産性キャパシティとは、特定のアイドル定義に含まれない時間です。非生産性作業は、インストール、メンテナンス、待機、その他のサービス休止の状態です。

アイドル キャパシティとは、技術上、契約上、またはビジネス上の理由による未使用、不要、または使用不能な状態です。

キャパシティ管理における賢明な方法は、数値は高い方に見積もって、サービスの低下や停止よりは余裕を持ったキャパシティを提供することです。SLA を達成できなかった場合のコストは、予防的プランニングによる余剰キャパシティのコストよりはるかに高くなります。また、稼働停止の公表、さらに不十分なキャパシティについて内部の方針を理解させるコストは、追加キャパシティのために前もって割り当てるコストより多くなることにも留意してください。

運用状態をシステムで監査する場合は、キャパシティの考慮条件を対象に含め定期的に実行することが必要です。

繰り返し使用できる予測可能な結果を入手するには、アプリケーションに対して使用できるリソースをリアルタイムで知っている必要があります。適切な安全策がなければ、サービスの改善に必要な人間の介在を削減するための自動化さえも、記憶域、CPU、およびメモリなどの主要リソースの使用過多をもたらすことがあります。一定のサービス レベルで指定されたユーザー数にサービスを行う組織を維持するには、データ センターにリソースを予測された量だけ用意する必要があります。使用可能なリソース、モデル アプリケーション、および関連サービス レベル目標を監視し、これらのパラメータに基づいて最も効率的なリソース セットを選択するのは、リソース管理の役割です。次に、アプリケーションをツリー構造にモデル化し、ディスクやバックアップ記憶域など簡単に割り当てられるリソースや、プロセッサ タイムなどのより静的なリソースを含む、必要なリソースの相互依存関係を明らかにします。

キャパシティ管理の算出例

キャパシティ管理のガイドラインとしては、次のような単純なルールを使用すると便利です。

サポートするユーザー数 = (ハードウェア キャパシティ)/(ユーザーあたりのハードウェア負荷)

この式で、サポートするユーザー数は同時にアクセスするユーザーであり、ハードウェア キャパシティはサーバーとネットワークの両方のキャパシティを指します。

この式によって、2 つの推論が引き出されます。

• 各ユーザーがハードウェアに与える負荷を減らせば、サポートできるユーザーの数が増大します。ソリューションのチューニングやリソースの使用方法をより効率的に変更することによって、この方法を実行できます。

• 構成を変更してソリューションのハードウェア キャパシティを増やすと、サポートできるユーザーの数は増大します。このようなオプションとしては、ハードウェアの水平スケール (横方向のスケール アップ、サーバーの追加) や垂直スケール (縦方向のスケール アップ、既存サーバーのアップグレード) があります。

場合によっては、単一サーバー上に複数のアプリケーションが常駐している場合があります。このような場合、キャパシティ管理の計算は、3 段階の分析として考えることができます。たとえば、A と B という 2 つのアプリケーションがあるとします。

まず、要求を査定します。次に、作業負荷を計算します。最後に必要なリソースの量を計算します。以下は、この計算を単純化した例です。

1. 要求量の計算

   総要求量 = (同時ユーザー数) x (単一ユーザーあたりの要求量)

2. 作業負荷の計算

   作業負荷 A = (総要求量) x (アプリケーション A の単一要求あたりの作業負荷)

   作業負荷 B = (総要求量) x (アプリケーション B の単一要求あたりの作業負荷)

3. リソースの計算

   必要な記憶域の MB 数 = 作業負荷 A x 作業負荷 A 単位あたりの MB + 作業負荷 B x 作業負荷 B あたりの MB

   CPU 処理パワー = 作業負荷 A x 作業負荷 A 単位あたりの CPU 処理パワー + 作業負荷 B x 作業負荷 B あたりの CPU 処理パワー

必要なネットワーク帯域幅 = ((作業負荷 A) x (作業負荷 A 単位あたりのネットワーク帯域幅)) + ((作業負荷 B) x (作業負荷 B 単位あたりのネットワーク帯域幅))

この計算例では、A B 両方のアプリケーションが同じコンピュータ上にあると仮定しています。逆算すれば、そのアプリケーションがピーク時に処理できるユーザー数を知ることができます。このように、キャパシティ管理では、アプリケーションがサポートできるユーザー数を簡単に割り出すことができます。

この計算式から、以下の 2 つの推論が考えられます。

• 各ユーザーがアプリケーションに与える負荷を減らせば、サポートできるユーザーの数は増大します。これを行うには、アプリケーションのプランニング、プログラミング、および構成によって、リソース使用の効率化を図ります。

• プロセス処理を制限するリソース (メモリ、ネットワーク帯域幅、ライセンス、およびサーバー) を増やせば、サポートできるユーザー数は増大します。

単純な計算式のようですが、個々のユーザーの要求は常に同じ量とは限りません。リソースにかかる負荷は各ユーザーの要求の結果であり、リソースへの要求は時間経過と共に変化します。

下図は、合意されたパフォーマンスをユーザーに提供するために必要な総負荷量の例です。

図 4: 要求とリソースの曲線

サービスのパフォーマンスは、リソースへの要求によって決まります。IT 組織とユーザーの間で、一定のサービスのパフォーマンスが合意されている場合、インフラストラクチャは、ピーク時にこのパフォーマンスを提供できるように設計しなければなりません。

上記のキャパシティのメトリックは単純なものですが、原則は重要です。一般に、キャパシティの要求は、特定のソリューションにアクセスするユーザー数を、そのソリューションの異なるコンポーネントに各ユーザーがかける増分負荷に関連付けることによって識別できます。この基本計算を使用して、現在および将来の使用量レベルをサポートするために必要なキャパシティ制限リソース (CPU、メモリ、I/O またはディスク速度、およびネットワーク帯域幅) の規模を決定することができます。監視、分析、そしてできればモデリングに基づくチューニングは、全体的なキャパシティ管理プロセスの一部であり、多くの場合、変更要求が勧告されることになります。

ピーク時に十分なキャパシティがない場合、最も簡単な解決方法は、ジョブをピーク時以外にスケジュール設定し直すことです。これとは別に、よく行われる解決方法として、ピーク時のいくつかのサービス料金を高額に設定して顧客の行動に影響を与え、ピーク時のそれらのサービスへの要求を減らす方法です。

またリソース管理は、不要または未使用のデータの削除やアーカイブなど、使用可能な容量をできるだけ効率的に使用するためのデータ記憶域容量の管理 (記憶域の管理) にも関連します。定義、キャパシティ管理に関連するプロセス、記憶装置業界の動向の詳細については、『MOF 運用ガイド』の「記憶域の管理運用ガイド」を参照してください。

また、有効なリソース管理を行うには、新しいハードウェア テクノロジと 4 つの主要カテゴリ (CPU、メモリ、I/O パフォーマンスまたはディスク アクセス、およびネットワーク帯域幅) における開発を評価する必要があります。メーカー、ベンダ、およびユーザー グループと継続的にコンタクトをとることにより、最新の情報を確実に入手します。これによって IT インフラストラクチャをより深く理解し、エンタープライズの全体的ソリューション アーキテクチャを基に作成される構成ダイアグラムを改善することができます。また、新しいハードウェアやソフトウェアの購入時期、および必要な投資額を決定する際にも、リソース管理を欠かすことはできません。

パフォーマンス管理は、システムを評価し、そのシステムが必要なパフォーマンス レベルを提供できるかどうかを判断して、次に必要なパフォーマンス レベルを提供できるようにチューニングを行う、連続プロセスです。多くのアプリケーションでは、これは技術インフラストラクチャが、許容できる応答時間で一定の同時ユーザーを確実にサポートできるようにすることを示します。

パフォーマンス管理は、単なる事後の対応ではなく、サイトのアーキテクチャやコードを設計する段階から開始しなければならない継続プロセスであることに注意してください。たとえば、あるコンテンツを SSL (Secure Sockets Layer) を介して提供する Web サイトを設計すると、パフォーマンスおよびパフォーマンス目標値に深刻な影響を与えることがあります。一方、ユーザーのセキュリティ上またはビジネス上の要件によって設計が決まることもあります。たとえば、状況に合わせてデータを処理せずに遅延して処理するなど、サイトのある側面の設計によってパフォーマンスの目標値が変化する場合もあります。

パフォーマンス管理によって、コーディングの方法が決まることもあります。たとえば、パフォーマンスを測定するにはシステムにフックをプログラムするしか方法がない場合、パフォーマンスのメトリックのログを記録したり、ほかのパフォーマンス測定方法を提供します。これによって、システム処理速度が低下することもありますが、システムの特定部分の速度を知ることが重要なのです。

内部のまたはベンダから提供されるシステムおよびアプリケーションの管理ツールは、可用性管理とキャパシティ管理の両方で役立ちます。プラットフォーム管理エージェントは、普通はベンダによって提供される低レベルの情報プロバイダで、パフォーマンスと可用性の詳細情報を提供します。収集されたデータはすべて記録、分析、レポートされます。パフォーマンス管理は、処理のキャパシティと応答時間に関して OLA で合意されたパフォーマンスを追跡し、可用性管理は可用性を測定します。可用性およびキャパシティの管理スタッフは協力して、必要な変更を行うための予防的計画を立てたり、サービスおよびリソースのレベルをより最適化するために必要な対策を実装します。

キャパシティ マネージャは、キャパシティ プランを定期的に更新します。キャパシティ プランの更新は、普通、プロジェクトとして実行します。

管理情報は、必要に応じて、一定の時間間隔で特別レポートとして報告されます。一般に、このような報告は継続的に実行される予防的チューニングの実施に役立ちます。この情報は、しばしばキャパシティ プランに取り込む必要があります。現在のリソースと監視されたキャパシティ レベル、リソースの将来レベルを正しく推測するために必要な測定値の両方が必要です。CDB は、この管理情報を反映し、構成アイテム (CI : Configuration Item) または CMDB で管理されているリソース情報との整合性を維持しながら、集中して管理されていることが重要です。

その他、入力データとなるレポートまたはキャパシティ プランに要約されるレポートは、以下のとおりです。

• 現在の要求量とリソースへの変換方法

• ピーク時要求量

• 将来の要求量、作業負荷、およびリソースの予測

• 将来のパフォーマンス予測

• 現在のリソースでサポートされるユーザー数

• ユーザー数 (負荷) が増大した場合のスケーラビリティ オプション

• アプリケーションの複雑度が増大した場合のスケーラビリティ オプション

• キャパシティ監視の変更

• 潜在的ボトルネック

レポートは、キャパシティに関する意思決定を明確にしてくれるものでなければなりません。以下の例を参照してください。

• 提供するアプリケーションの複雑度を高め、それによって 1 ユーザーあたりのハードウェアに対する負荷を増大し、しかもサポートされるユーザー数を維持するには、ハードウェアのキャパシティを増やす必要があります。これは、縦方向または横方向のスケール アップを決定するための裏付けになります。

• サポートするユーザー数を増大するには、アプリケーションを単純化 (リソース必要量を削減) するか、またはリソースのキャパシティを増やす必要があります。これは、制約のあるリソース (RAM、ネットワーク帯域幅、ディスク容量など) への集中を減らすためのアプリケーションのチューニングの裏付けとなります。

CDB の正しいメンテナンスとレポート作成に必要なデータの範囲を前もって予測し、必要に応じてデータベース構造を対応させる必要があります。SLA に準拠するためのキャパシティ関連の変更と、成長のためのアップグレードは、使用する変数をできるだけ少なくしながら徐々に実装し、問題が発生した場合のトラブルシューティングを容易にしておきます。

たとえば、サーバーのしきい値をディスク容量の 85% と設定した場合、管理者に警告を送信するか、またはしきい値を超えると自動的に対応策を実行するかを指定できます。このような状況の対応策としては、一時ファイルの自動削除や、ネットワーク トラフィックのルート変更があります。予防的なキャパシティ管理ツールを使用すれば、状況をすぐに修正するか問題イベントが発生したことを管理者に通知する、あるいはその両方を実行して、アプリケーションやシステムの可用性に影響を及ぼすような問題になる前に必要なアクションを取ることができます。

分析ツールとレポート作成ツールを使用すれば、キャパシティ マネージャはさらにプリエンプティブなプロセスを開発し、最大限のリソース可用性を確保することができます。IT エンタープライズのイベントから収集した情報を基に、IT スタッフは、複数レベルのデータを分析し、どこに可用性の問題が存在し、将来の問題を防止するにはどのような作業を実行すべきかを決定できます。また、このソフトウェア分析ツールセットは、IT 組織がエンドユーザーに対して提供しているサービスのレベルもレポートすることが必要です。

IT 管理サポート ツール

効果的なキャパシティ管理を行うためには、サービス ソリューションと基盤となるプラットフォームを監視し制御する、高度なソフトウェアが必要です。このようなソフトウェアは、内部で開発するより、ベンダの長年にわたるプラットフォームの監視や制御のための要素を活用したソフトウェア パッケージを利用する方がコスト的に有利です。このようなツールを IT 管理サポート ツールと呼びます。IT 管理サポート ツールは、機能によって次の 3 つのカテゴリにグループ分けできます。

• サービス管理ツール

• アプリケーション管理ツール

• インフラストラクチャ管理ツール

エンタープライズ管理フレームワークでは、一般に、インフラストラクチャの管理に焦点が置かれますが、これらのカテゴリ全体のツールと情報が統合された総合的な製品を使用したり、ほかのベンダ製品と統合したり、アプリケーションおよびサービスの管理を提供する製品に情報を渡して処理させることもよくあります。詳細については、『MOF 運用ガイド』の「サービスの監視と制御運用ガイド」を参照してください。

情報に関するキャパシティ管理の必要条件と可用性管理の必要条件、およびサポート ツールはよく似ています。一般的に、アプリケーション管理ツールはこれらのニーズに直接対処しますが、プロセスにおいては、サービス管理およびインフラストラクチャ管理のサポート ツール カテゴリから提供される情報も活用します。

サービス管理ツール

サービス管理プロセスの主な目的の 1 つは、IT サービスの品質を管理するための情報管理です。この情報は、サービスおよび顧客に関する情報を監視しレポートするのに使用されます。サービス管理プロセスでは、サービスの定義と必要に応じた変更を確実に実行し、サービス利用時のサポートを提供します。これは IT 管理プロセスであり、このプロセスでは IT サービス プロバイダと顧客とのコンタクトが行われます (インシデント管理、変更管理、サービス レベル管理)。またインシデント管理、問題管理、および変更管理も、IT サービス管理部門内のワークフローを定義します。サービス管理ツールの評価は、一般に、インシデント管理、問題管理、変更管理、構成管理、変更管理、ソフトウェア制御、サービス レベル管理、およびコスト管理のプロセス必要条件をサポートする能力によって決まります。

アプリケーション管理ツール

アプリケーション管理では、エンドユーザーの観点から見たアプリケーションが中心になります。アプリケーション管理では、基幹アプリケーションとデータが常に高い可用性で最適に実行されるようにします。エンドユーザーの代表と IT サービス プロバイダは、実現するサービス レベルに合意します。これらのサービス レベルについては、IT サービス プロバイダが監視してレポートします。アプリケーション管理プロセスは、アプリケーションおよびそのアプリケーションが使用するインフラストラクチャ リソースについて、合意された、または実際に運用されているサービスの可用性およびパフォーマンスのエンドツーエンドの情報を提供します。アプリケーション管理ツールの評価は、一般に、可用性管理、キャパシティ管理、およびサービス レベル管理のニーズを満たすことができる能力によって決まります。

インフラストラクチャ管理ツール

インフラストラクチャ管理は、システム、ネットワーク、データベースとデスクトップの管理、およびソフトウェア配布によって構成されます。これは、サーバー、ルーター、ハブ、データベース、PC および端末など、IT インフラストラクチャのコンポーネントまたは要素の管理として定義されます。インフラストラクチャ管理ツールは、一般に、システム管理、ネットワーク管理、デスクトップ管理、ソフトウェア配布、データベース管理というカテゴリに分類されます。

継続的見直しとメンテナンス
この作業の主な目的は、現在のシステムの監視、コンポーネント特性のモデリング、そして最適なサービス キャパシティとパフォーマンスを実現するための将来レベルのリソースの計画に基づいて、必要条件を確保するために行われているキャパシティ管理による変更要求プロセスが有効かどうかを査定することです。この作業には、広く認められたキャパシティ管理モデリングの手法と、ツール、測定方法、そして全関係者への正しいコミュニケーションが必要です。

IT サービスをアウトソーシングする可能性がある場合は、慎重なコスト分析、監視と制御の能力、契約に含まれる条件、サービスの終了と移行が容易かどうかを検討する必要があります。ビジネスの機密データや所有権データを制御したり、このような情報にアクセスすることは、重大な、そして多くの場合予測不可能なリスクを引き起こすことがあります。契約と罰則によるキャパシティの保証を入念に検討することが必要です。

キャパシティ変更プロセスの有効性を査定するには、継続的見直しとメンテナンスが必要です。この作業には、一般に広く認められているキャパシティ管理の計算手法と、ツール、測定方法、そしてすべての関係者への正しいコミュニケーションが必要です。サービス全体のライフサイクルにわたって、キャパシティ OLA の必要条件を予測します。適切なアプリケーション サイジングを行って、サービス導入の準備をします。サービスのライフサイクルが継続している間は、前に説明した適切なキャパシティ管理を実行し、ライフサイクルが終了したら、利用を停止する計画を立てます。

IT 予算にデータを提供し、予算を見直します。キャパシティ プランのコストに関する利点を調査し、プラン更新サイクルの一部として、担当経営幹部への検討材料として提出します。

キャパシティ管理では、以下のバランスを考慮します。

• 供給対需要 - 使用可能なリソース (処理パワーおよび記憶装置) を、IT サービスを現在および将来使用する顧客のリソース要求に確実に対応させます。

• コスト対キャパシティ - 購入する処理キャパシティは、ビジネス ニーズの点で適正なコストであるだけでなく、リソースを最も効率的に利用できるものでなければなりません。

サービス キャパシティの管理では、IT 処理の一環として常に見直しと管理が必要です。これは、IT サービスの将来的ビジネス要件を確実に考慮し理解するためであり、サービスを十分にサポートできるキャパシティを適切な期限で計画し実装するためです。

図 5: キャパシティ管理のサービスレベル – 継続的見直しとメンテナンス

サービス レベルおよび運用レベルの合意を、定期的または必要に応じて実行される SLA 必要条件の準拠評価に基づいて適切に更新するには、サービス レベル管理者との共同作業が不可欠です。

IT 内部の運用レベル合意は SLA を基に作成されるもので、この例では、ユーザーの同意とリリース管理者による署名とを同義と見なします。

キャパシティ管理は、SLA に定められているパフォーマンス レベルの範囲内で、ユーザーの要求を満たすためにサービス ソリューションのキャパシティ プランニング、サイジング、および制御を行うプロセスです。

サービス レベル契約には、通常、パフォーマンスの期待レベルと容認レベルが定められています。サービス レベルの準拠状況を示す履歴レポートを用意し、傾向を分析して作業負荷の予測値を算定します。

キャパシティ管理で何かが発見された場合は、以下のような手順を実行します。

• キャパシティ管理の日常プロセス、またはより正式な定期的キャパシティ レポートやプランの勧告を基に、正式な変更要求を作成する、直接的な行動を起こします。

• サイトのコンテンツ開発者向けに、将来のコンテンツ変更または開発時の参考になるレポートを作成します。

• 必要があれば、アプリケーション ハードウェアをアップグレードするためのプランを正式に作成します。

• 将来成長がキャパシティに与える影響を予測します。

• 将来のアップグレードのための予算を作成します。

その他、キャパシティ管理の継続的プロセスには、次のようなタスクが含まれます。

• リソースおよびシステム パフォーマンスの監視が適切なレベルに設定され、CBD に記録された情報が常に最新の状態で、その情報をキャパシティ管理プロセスにかかわるすべての部門が使用できるようにします。

• サービス レベル目標とコスト上の制約に基づくハードウェアの増減の必要性をドキュメント化します。

• 現在のリソース使用状況、傾向、および予測を含む管理職への報告書を定期的に作成します。

• 提案された新しいシステムについてすべてサイジングを行い、必要なコンピュータおよびネットワーク リソースを決定し、ハードウェアの使用状況、パフォーマンス サービス レベル、およびコスト上の必要条件を判断します。

• パフォーマンスとコストの観点から、新しいテクノロジと、そのテクノロジが組織に適しているかどうかを査定します。

• プロセスの効率化と有効性を高めるため、キャパシティ管理部門で使用する新しいハードウェアとソフトウェアを査定します。

• キャパシティ関連の日常作業のシステム監査を定期的に実施します。

• 新しいシステムのパフォーマンス テストを実施します。

• SLA の目標値に対するパフォーマンスの状況を報告します。

• IT サービスに対する将来の要求に関する知識を維持し、パフォーマンス サービス レベルに対する要求の影響を予測します。

• 維持が可能でコストに見合うパフォーマンス サービス レベルを決定します。

• CAB (変更諮問委員会) に参加し、変更の査定と認可を行います。

• システムのチューニングを推奨し、すべてのハードウェアおよびオペレーティング システム ソフトウェア リソースを最適使用するためのシステムの設計と使用方法を、IT 管理に勧告します。

• パフォーマンス関連のインシデントや問題の解決方法を提案します。

• 要求管理を採用してシステムに対する顧客からの要求を制限するタイミングを、IT 管理に勧告します。

• IT 管理部門の要求に応じて、パフォーマンスおよびキャパシティの特別調査を実行します。

• あらゆるキャパシティ プランニングおよびサイジング作業において、信頼性と可用性の必要条件が考慮されるようにします。

• 組織のビジネス プランニング サイクルに合わせてキャパシティ プランを作成し、調達に必要な準備期間を考慮できる早い段階でキャパシティの必要条件を識別します。

キャパシティ プランと既存 SLA、また対応する提供されサポートされている各 IT サービスの OLS を、定期的に更新、見直し、およびメンテナンスすることがきわめて重要です。

キャパシティ管理は、IT リソースの最適使用によって、ユーザーと合意したパフォーマンスのレベルを達成するプロセスです。IT サービスの提供業者の場合は、SLA の責務を果たす対象は外部にあります。サービス性 (保守容易性) という言葉は、対象が外部にあることが暗黙のうちに含まれており、可用性管理の主要コンポーネントです。キャパシティ管理はこのサービス性に関するタスクを共有しますが、提供業者へのインターフェイスとして可用性管理にこのタスクを委ねることができます。この場合、キャパシティおよびパフォーマンスの関係が、提供されているサービスの SLA 可用性コンポーネントの一部となります。

組織内から提供される内部サービスでの中心は、一般に、保守性と呼ばれます。可用性管理の場合と同様、キャパシティおよびパフォーマンスの対策は、変更要求を内部的に承認することによって実装され、キャパシティ プロセスによって提案された予防策によって、IT サービスの可用性を向上させることができます。このような OLA は、本質的には、内部で監視し制御される SLA と言えます。

キャパシティ マネージャの仕事は、IT サービス レベルのパフォーマンスとビジネス上の両方への影響を検討し評価するための指示を出すことです。財務分析は、この機能には欠かすことができません。また、サービス レベル管理、経費管理、キャパシティ管理、サービスの監視と制御、サービス継続性管理など、キャパシティ管理の結果によって影響を受けたり、キャパシティ管理とデータのやり取りを行うほかの MOF IT プロセスとも重なる部分があります。

これまでに、パフォーマンス管理、リソース管理、作業負荷管理、および要求管理のサブ プロセスと機能上の分類については説明しました。また、これらのサブ プロセスの各タスク領域に関する細かい作業として、監視、分析、チューニング、および変更実装のライフサイクルがどのような役割を果たすかについても説明しました

その他日常的な運用作業については、MOF 運用フェーズ モデルに詳しく説明されています。詳細については、『MOF 運用ガイド』の「ジョブ スケジューリング運用ガイド」、「サービスの監視と制御運用ガイド」、および「記憶域の管理運用ガイド」を参照してください。

サービス継続性管理シナリオに従うプロセスでは、有効な予防的キャパシティ ソリューションの "設計" を決定します。またこのプロセスは、リスク分析によってフェールオーバーと復旧のシナリオを識別するときも、パフォーマンス レベルを調べるため、欠かすことができません。 同様に、継続的な日常のジョブ スケジューリング活動によって、しきい値によって発生した状況に適切に対応するための情報が提供されます。通常稼働日のキャパシティとパフォーマンスによって、手順やドキュメントがさらに改善されることはよくあります。また習得した内容は、サポートを向上させるためのガイドラインとしても使用でき、キャパシテイやパフォーマンスに関する問題を (理想的には発生前に) 自動修正するソフトウェアのパラメータにもなります。

効果的なフィードバック手順を、十分な品質保証 (QA) チェックポイントと共に実装する必要があります。これは、MOF では SLA 見直し用マイルストーンとして提示されています。このマイルストーンは、ブックマークとして、キャパシティおよび関連パフォーマンス データの最適化を実行する前にこの手順を実行することの重要性を示しています。すべてのソフトウェア、ハードウェア、およびエンタープライズ管理情報やレポートは、定期的に見直して評価する必要があります。結果を追跡し、IT サービス顧客満足度調査との統一を図ります。サービス レベルの変化は、後で、そのイベントに関する顧客からのフィードバックと関連付けます。

このプロセスは、社外のソースから提供されるサービスに拡大することができます。当該プロバイダに要求するパフォーマンス レベルをきめ細かく指定する適切な SLA が必要です。

キャパシティの内部監視と制御に適用されるキャパシティの原則は、外部の契約ベンダにも同様に適用できます。このベンダが、同時にアプリケーション サービス プロバイダ (ASP) である場合もあります。この文書の前の部分で、より効果的な IT キャパシティ管理のプロセス、手法、戦略について説明しました。ASP のキャパシティの監視や制御にも同様の原則を適用して、サービスのパフォーマンス レベルを追跡し、条件が達成されていることを確認します。

外部のアウトソーシング サービスが対象の場合は、個別の特定のサービスから受けることを期待するパフォーマンスと可用性について、ベンダから契約上のコミットメントを取ること、またその内容は測定可能であることが重要です。通常の場合、ベンダからパフォーマンス上の保証を取ることは可能です。この保証は、多くの場合、こちらから請求しなければ提供されません。パフォーマンスまたはキャパシティが関連する場合、SLA の条項はベンダの主張に基づいて作成される傾向があります。

日常的に、IT 部門は内部から外部に向かうサービス、または外部から提供されるサービスと、それに対応する SLA の監視、保守、変更の実装を行わなければなりません。詳細については、『MOF 運用ガイド』の「サービスの監視と制御運用ガイド」、「記憶域の管理運用ガイド」、および「ジョブ スケジューリング運用ガイド」を参照してください。

一般にキャパシティ管理は、外部のベンダからサービス改善のために提案された変更の、パフォーマンス部分のサービス レベル管理の交渉に携わります。また、提案された予防的キャパシティ プランニングや外部ソリューション プラットフォームの予防的メンテナンスが、キャパシティにどんな影響を与えるかを調査します。

内部的には、現在のキャパシティ プラン実装が成功しているかどうかを見直す必要があります。これは、継続的な更新、新たなキャパシティの改善、またはキャパシティ関連の必要条件によって導入された新しいソリューションにとって重要です。ビジネスの基幹サービスや、高い障害リスクが予想される場所については、パイロットまたはプロトタイプによるテストが有効な場合があります。十分な見直し、または指定された制御ポイントによるキャパシティ変更手順の展開が必要です。

キャパシティに影響を与えるような、またはパフォーマンスの変更によって影響を受けるような急激なエスカレーション手順は、キャパシティ管理部門の専門知識を持って検討し、管理する必要があります。

内部および外部のシステムのキャパシティ サービス レベルについて、定期的な監視と保守を実施する必要があります。負荷分散の運用タスクの詳細については、『MOF 運用ガイド』の「ジョブ スケジューリング運用ガイド」を参照してください。

サービスをアウトソーシングするかどうかの意思決定は、慎重に検討する必要があります。場合によっては、ベンダやコンサルタントなど外部の専門知識を求めます。この意思決定には、正しい現状認識、クロストレーニングと、コンサルタントの知識を IT スタッフに伝えて先人の知恵を生かすこと、より経験を積んだキャパシティおよびパフォーマンスのスタッフが必要です。

現代の IT エンタープライズは、独自の全体論的な方法でキャパシティ管理にアプローチしなければなりません。

MOF が適切に機能し実装されることによって、変更管理プロセスが監視されている必要があります。たとえば、次の点について検討します。キャパシティおよびパフォーマンスの監視と制御機能によって勧告された変更は、正しく実装されたか? システム管理者はシステム エリア ネットワークの記憶域プールの拡張に必要な新しい技術 (ハードウェアおよびソフトウェア ツール) の適切なトレーニングを受けているか? 共有記憶域の二重冗長性パスは、要求時、正しく動作したか?

理想的には、成長の余地があればシステムは迅速に対応すべきです。負荷がかかるとキャパシティ問題が起きるシステムでも、通常動作で十分な応答性とスループットを示すものがあります。逆に、キャパシティは余裕があるのにアプリケーションの種類や組み合わされた作業負荷が設計上うまく処理できなくて、応答性やスループットが低い場合もあります。システム管理からの警告に、リアルタイムで突然対応するのは非効率的です。計測ツールを使用して、予防的対策やプランニングを行うことが重要です。問題を修正しなければというプレッシャーの中では、適切な意思決定はできません。データを収集し、それに基づいて問題を予測します。

キャパシティ管理の賢明な方法は、数値は高い方に見積もって、サービスの低下や停止よりは余裕を持ったキャパシティを提供することです。SLA を達成できなかった場合のコストは、予防的プランニングによる余剰キャパシティのコストよりはるかに高くなります。また、稼働停止の公表、さらに不十分なキャパシティについて内部の方針を理解させるコストは、追加キャパシティのために前もって割り当てるコストより多くなることにも留意してください。この原則が最も重要なのは、ハードウェア レイヤとネットワーク レイヤです。

コスト、利点、および潜在的問題
リソース コストの決定には、コスト プランニング ソフトウェアや IT 関連の会計手法を活用します。解説したテクニックには、どの業務領域およびサブ プロセスに関連するソフトウェア市場があるかを記載しました。製品を入手できるベンダ ソフトウェアの評価と選択は、早めにとりかかります。詳細については、『MOF 運用ガイド』の「経費管理運用ガイド」を参照してください。

関連コストは以下のとおりです。

• 必要なハードウェア ツールとソフトウェア ツール。アプリケーション ソフトウェア (カスタムまたはパッケージ)、監視 ツールなどのシステム管理ソフトウェア (多くの場合、可用性管理と共用)、モデリング ツール、グラフィック形式およびテキスト形式のレポート作成ツール、リレーショナル データベース管理システム (RDBMS) ソリューションとしての CDB の実装を含む。

• プロジェクト管理 - MOF プロセスの実装はすべて IT プロジェクトと見なされる。

• スタッフ養成コスト - トレーニング、求人、人材保持、コンサルティング、および知識の共有。

• 設備の確保。

利点

• キャパシティ不足によって問題が発生するリスクを軽減する。

• 既存能力を予算内で最大限活用する。

• IT サービスの提供およびサポートの改善によってビジネスの効率性を向上させる。

• キャパシティ コストをきめ細かく管理する。

• 低コストで実行できるパフォーマンス向上の方法を識別する。

• サービス パフォーマンス レベルの仕様を向上させる。

• ハードウェアおよびソフトウェアのアップグレードのタイミングと構築に関する情報を提供する。

• システムのパフォーマンスをより正確に予測する。

• IT リソース (スタッフ関与時間、ハードウェア予算など) を拡張し、より効率的に使用する。

• パフォーマンスおよびキャパシティに関する問題を適切に予測する。

• 追加ハードウェアの取得を周囲に知らせる。

潜在的な問題

• チューニングの成果に対する期待が高すぎる。

• ユーザーの期待が技術上の現実的なレベルを超えている。

• 提供業者のスループットの見積もりが現実的でない。

• 将来の作業負荷に関するユーザーからの情報に信頼性がない。

• パフォーマンスの統計情報が不十分なことが多い。

• プランニング、購入、監視、管理の責任について部門間で意思統一ができない。

• 提案されたキャパシティ管理のタスク領域が実装困難である。

• 十分な時間とコストが必要となるキャパシティ管理に対して抵抗がある。

 ページのトップへ

スケーラビリティを備えた IT ソリューションの設計

一般的な IT サービスのキャパシティ プランニングでは、現在および将来のインストールの必要性を判定し、次に、現在推定されているニーズに適合し、しかも将来の必要性に対応して拡張またはアップグレードできるハードウェアとソフトウェアを選択します。ここで説明するのは、優れたキャパシティ プランニングの実例です。

一般的な IT ソリューションには多くの変数があります。ニーズの変化が急激なため、キャパシティ プランニングは科学というより芸術に近づいています。キャパシティ プランニングは、一般的には反復アプローチを使用します。現在の IT エンタープライズは、新しいテクノロジ動向の重要性と、可用性管理とキャパシティ管理の協力によって作成される必要条件の重要性を認識しなければなりません。

実際的見地から見ると、キャパシティ管理は、ユーザー画面での応答時間をピーク時のシステム全体のスループットを表す手段として、最悪のケースに対応するプロセスです。ユーザー数と各ユーザーがシステムに占める要求量を計測し、現在または将来の使用レベルをサポートするために必要なコンピューティング リソース (プロセッサ、メモリ、ディスク スペース、I/O 速度、ネットワーク帯域幅) を計算することが重要な場合もあります。

市場が共通標準の重要性を認識し、強調することにより、サービス レベル管理は向上します。このような標準は、広く認知され権威のある標準化設定組織によって設定されるか、または市場によって決定された標準として生き残っているものです。IT では、ますます標準化が進む通信方式に基づいて、ベンダ特有のプラットフォーム管理エージェントによって供給されるデータを活用します。強力なソフトウェア ツールが総合的サービス モニタやキャパシティ情報を提供できる能力は、速いペースでさらに高度化しています。このことが、IT 組織がさらに高いレベルの可用性とさらに最適化されたキャパシティを求める傾向を助長しています。運用のための最良の方策となる原則が認識され、導入されたことによって、管理情報ツールの機能も向上しています。

現在のベンダ製品ソリューションは、論理的に CMDB に相当する RDBMS リポジトリを基盤として使用しています。これらのソリューションは、効率的なサービス デスク、キャパシティ管理、および可用性管理のための、より特化された情報を提供することによって機能が向上しています。システム管理ベンダから提供されているこの新世代ツールは、データ収集と、監視された詳細データに基づくサービス レベルの相関機能が改善されています。この情報は、しばしば、可用性およびキャパシティ管理の目標値として使用され、優れた設計のパフォーマンスまたはキャパシティ管理データベース (CDB) 情報システムの普及をもたらしています。

現在のリソース使用状況を最適化し、必要なアップグレードを完了するには、IT ソリューションへの階層別アプローチをお勧めします。MOF (Microsoft Operations Framework) は、人材、プロセス、およびテクノロジの重要性を強調しています。以下では、サービス、アプリケーション、ミドルウェア、オペレーティング システム、ハードウェア、ネットワーク、設備、および外部サービス (インターネット アクセス、電力など、外部から IT に供給されるもの) の主要 IT レイヤについて、IT 上の考慮事項をいくつか説明します。

ソリューションのスケーリングには、以下の 3 つの基本目標があります。

• サーバー 1 台あたりのユーザー数拡大

• ソリューションが同時にサポートできるユーザー総数の拡大

• ソリューションのレイテンシ (待ち時間) 短縮による応答時間の短縮

これらの目標を達成するため、IT では以下の方法を使用します。

• アプリケーションの最適化。コンテンツの再設計または複雑度の軽減。

• 縦方向のスケール アップ (垂直スケール)。既存サーバーに段階的にデバイスを追加することによって、ソリューションの能力を拡大することです。一般的には、中央処理装置 (CPU)、メモリ、ディスク、ネットワーク インターフェイス カード (NIC) をサーバーに追加します。これは、垂直スケーリングまたは垂直成長とも呼ばれます。

• 横方向のスケール アップ (水平スケール)。プロセッサ、記憶域、帯域幅を備えたサーバーを段階的に追加して、これらのサーバーで負荷を共有し、ソリューションの能力を拡大することです。これは、水平スケーリングまたは水平成長とも呼ばれます。

横方向のスケール アップの場合、対象のアプリケーションがこのような分散処理をサポートしていること、可用性の向上が図れること、価格増加とパフォーマンス向上の間でコストの適正化が含まれることが重要です。

Microsoft は、Web ベースのビジネス アプリケーションおよびプラットフォームを構築して展開するための Microsoft Web Solutions Platform (かつての Windows DNA) を開発しました。その中には、効率的でスケーラブルなアプリケーション プラットフォームの開発に欠かすことのできない動的コンテンツが何種類か含まれています。

分散インターネット サーバー アレイ (DISA : Distributed Internet Server Array) などのハードウェア アーキテクチャは、Web サイトの信頼性、可用性、およびサービス性を得るための標準的戦略と考えられています。このアーキテクチャは、ソリューションからコンピュータ リソースを分離し、さらに最適化してスケーラブルなパフォーマンスを提供し、Windows DNA をフロントエンドに置くソフトウェア レイヤにシームレスに融合されます。このような Web ソリューション アーキテクチャでは、高い柔軟性とスケーラビリティの向上を実現できます。

Microsoft Web Solution Platforms では、標準的な Windows ベースのサービスを使用して、ユーザー インターフェイスとナビゲーション、ビジネス ロジック、およびデータ記憶域による多層形式のソリューションの各層を処理します。

また、多層形式の E コマース ソリューションを構築して、より本来の意味での可用性とスケーラビリティを持たせることができます。このような設計によって、IT サービス ソリューションはスケーラブルで高可用性を持つハードウェアおよびソフトウェア アーキテクチャによって最適化され、IT Web サービスの高可用性はさらに強化されました。可用性管理では、このアーキテクチャで高可用性が実現できる理由を解説します。この文書では、本来のパフォーマンスと負荷分散の利点をさらに説明するため、高度なアーキテクチャについて説明します。

IT の主要レイヤは、以下のとおりです。

• サービス - SLA を基に各下位レイヤの OLA を作成する

• アプリケーション - エンド ユーザーに提示される

• ミドルウェア - COM+、データベースなどを含む

• オペレーティング システム

• ハードウェア

• ローカル エリア ネットワーク - LAN、WAN、または IT が管理するネットワーク インフラストラクチャ

• 設備 - 建物、HVAC など、企業によって管理される

• 外部サービス - IT の管理対象外、インターネット、電力、ガス、水など

SLA (外部の場合) または OLA (内部イントラネットの場合) として定義されている顧客要求によって、要求および作業負荷の特性が決定されます。IT サービスのユーザーが要求するのは、一般的に次の 3 項目です。

• 品質 - サービス レベル契約 (SLA) に定められている合意された品質でのサービスの提供。

• 速度 - SLA に定められているソリューションの必要条件を満たすための、適切なタイミングでのリソース管理。(実行時間/実装時間) に反比例。

• 価格 - 低コストで、最適化され予測可能なコスト。

予防的キャパシティ管理は、品質、速度、および価格に対する顧客の期待をうまく均衡させます。覚えておくとよい法則は、IT サービスの顧客は希望に 2 つのメトリックが含まれることはあっても、3 つすべてを含むことはできないということです。たとえば、新しい機能の実装による高速のターンアラウンド タイム (速度) と高品質な製品 (品質) を求めれば、コスト高 (高価格を許容) になります。また、すばやく実行できる (速度) 安価な実装 (価格) を手にすることはできますが、製品の品質はがまんしなければなりません (低品質を許容)。

サービスの考慮条件

IT サービスの提供とサポートは、すべての MOF 方針がかかわる幅広いレイヤです。サービス レベル管理は、サービスの顧客と SLA の交渉を行い、次に各レイヤの OLO を定義します。キャパシティ管理は、最初の SLA におけるキャパシティ必要条件の定義を支援し、継続的見直しとメンテナンスに参加します。キャパシティ管理は、引き続き、所定のレイヤの OLO を達成するための適切なキャパシティを維持するために必要なコストを決定します。各レイヤに、こうして作成された関連 OLA があります。キャパシティ管理は動向を監視して、使用されているキャパシティがしきい値を超えるタイミングを予測します。しきい値を超えると、各レイヤの OLA に違反する可能性があるため、これを防止する予防的変更を行います。

IT ソリューションのキャパシティとパフォーマンスを管理する最良の方法となる多くの例では、顧客主導の SLA の共同作業に基づいた基準が、サービスの明確な測定値として使用されています。この測定値は、パフォーマンスおよびリソース管理の継続的プロセスによって提供され、ソリューションの縮小またはモデリングの入力データを提供し、変更の勧告の基になります。主要 IT レイヤのそれぞれについて、関連する内部 OLO とサービス品質のメトリックが必要です。

提供される各 IT サービスまたはアプリケーションについて、キャパシティ管理はリソースの必要条件を識別し、絶えず変化する環境で一定の品質を提供するアプリケーションを最適な方法で構築し、管理し、サポートします。SLA プロセスへの参加とフィードバックが重要です。対応するパフォーマンス モニタを特定し、しきい値アラームを設定し、主要メトリックをレポートすることによって、IT リソースの最適レベルが達成できます。

サービス レイヤは、下位にあるすべてのコンポーネント レイヤに依存します。サービスより下位のレイヤは、まとめて技術インフラストラクチャと呼ばれることもあります。

アプリケーションの考慮条件
監視するリソース対象、リソース使用状況の監視方法、およびリソース要件の管理方法の決定は、必要なサービスを予防的に管理するキャパシティ管理にとって欠かすことのできない作業です。

アプリケーションの設計によって、基盤となるレイヤでのパフォーマンスの考慮事項が決まり、パフォーマンスが潜在的に分離されることもあります。一般に、クライアント サーバー方式では、パフォーマンスはさらに分離され特性化されますが、PC の出現によって、クライアント サイドに優れた計算能力が提供されるようになりました。

現在の IT 環境でアプリケーション コンテンツを提供するには、以下の 3 つの方式が一般的です。

それぞれの方法には、キャパシティ管理に関して長所と短所があり、以下に説明するように、プラットフォームの配置とサポートに影響します。

クライアント サーバー。この方式では、クライアントとサーバーの両方で実行されるいくつかのアプリケーション機能を組み込みます。この種のアプリケーション分散化の例としては、リモート プロシージャ コール (RPC) によるメッセージ アプリケーション プログラミング インターフェイス (MAPI : Messaging Application Programming Interface) を介して Microsoft Exchange server と接続した Microsoft Outlook があります。

長所 : 処理能力をエンタープライズ内の複数のリソースに分散します。Exchange ベースの顧客にとっては最も高い機能が得られます。

短所 : サーバーおよびすべてのクライアントの両方にアプリケーション構成上の必要条件が存在します。

シン クライアント サーバー。この方式では、アプリケーション リソースの負荷をサーバーに集中化し、さまざまなクライアント アクセスのオプションを提供します。画面の更新のみをクライアントに送信し、クライアントは、マウス/キーボードの入出力 (I/O) をサーバーに送信することによって、ネットワーク帯域幅の要件を最小限に抑えます。この種のアプリケーションの例としては、リモート デスクトップ プロトコル (RDP : Remote Desktop Protocol) クライアントからアクセスするターミナル サービスを介して Microsoft Windows 2000 Server が提供する分散処理を行う Microsoft Office 2000 があります。

長所 : アプリケーションの構成がサーバー上に集中するため、管理のポイントを集約でき、ネットワーク使用の要件を減らし、クライアント構成の要件、およびクライアント リソースの要件を減らします。

短所 : アプリケーションによってはターミナル サービスによるホスティングが適さない場合があり、サーバー構成が複雑で、サーバーのリソース要件が高くなり、スケール アップのオプションが限定されます (横方向のスケール アップはサポート)。

Web ホスティング。この方式では、アプリケーションのリソースロードをサーバー上で中央制御しますが、クライアントのリソースも利用できます。一般的に、クライアントの必要条件は Web ブラウザのみで、アプリケーションを真にクロスプラットフォームで分散することができます。このようなアプリケーション分散の例として、Web ブラウザからハイパー テキスト転送プロトコル (HTTP) を介してアクセスする Microsoft Exchange 2000 があります。これには、HTML (Hyper Text Markup Language)、動的 HTML (DHTML)、および XML (Extensible Markup Language) のコンテンツが含まれます。

長所 : アプリケーションの構成をサーバー上に集中化し、一元管理を実現し、ネットワーク使用の要件を減らし、クライアントの構成要件が最小限で済み、クライアントのリソース要件を減らし、クロス プラットフォームの分散機能を有し、管理が比較的容易で、ソフトウェアのライセンス コストが比較的削減でき、横方向または縦方向のスケール アップが容易です。

短所 : 比較的新しい方式のため、需要に対して供給が少ない特殊な能力が必要となります。

現在、多くのクライアント サーバー アプリケーションが導入されています。ここ数年では、シン クライアント サーバー アプリケーションが普及しています。また管理が簡単で、スケーラビリティがあり、低コストであることから、アプリケーションの Web ホスティングが増加の勢いを見せています。

スループットは一定期間内にアプリケーションが処理できる仕事量 (トランザクション数) であり、多くの場合、1 秒あたりのトランザクション数 (TPS : Transactions Per Second) で計算されます。

スケーラビリティ。スケーラビリティとは、容認できるパフォーマンス レベルを維持しながら、作業量の増加に対応するアプリケーションの能力です。たとえば、1 台のシステム/プロセッサが 10 人のユーザーをサポートしている場合、2 台のシステム/プロセッサでは 20 人のユーザーをサポートでき、以下同様に増加します。線形スケーラビリティでは、傾きが一定の直線を想定します。スケーラビリティは、リソースが増減したときに発生する線形スループットの変化量を示します。スケーラビリティによって、アプリケーションが、必要に応じてリソースを増減してアプリケーションの "スケーリング" を行うと、数人から数千人まで何人でもユーザーをサポートすることが可能になります。

ここで注意すべき点は、スループットが上昇するとスケーラビリティが増加するということです。たとえば、リソースあたりのスループットの増加率が高ければ、スケーラビリティも高くなります。

トランザクション時間とは、必要なリソースを取得するのに必要な時間量に、トランザクションが実際にこれらのリソースを使用する時間量を加えたものです。

これらの定義のコンテキストでは、システムのスケーラビリティの限界を超えると、許容範囲を超えたパフォーマンス低下によってサービスが利用負荷であると考えられるポイントまで、パフォーマンスが低下することがあります。一般にこれは、SLA 手順に準拠していないとして、アラーム状態を発生する条件となります。むしろ、その他多くのキャパシティしきい値警告で、保留になっている障害が予備警告されることが望ましいと言えます。

重点は、ピーク時のキャパシティではなく維持可能なキャパシティに置きます。キャパシティの最大値を第一に考えがちですが、スケーラビリティにとっては、キャパシティの最小値と段階的に増加するキャパシティの追加方法も重要な要素です。

縦方向のスケール アップには、以下のような長所があります。

• 複数の CPU スレッドまたはプロセッサをサポートするアプリケーションの場合は、多数のプロセッサによる対称型マルチプロセッシング (SMP) またはマルチノードの利点を活用できます。

• ソフトウェアのライセンス使用コストを軽減できる場合があります。単一システム イメージでアプリケーションを起動および実行できます。

• 管理とサポートのコストを軽減できます。

• あるアプリケーション インスタンスがかなりのメモリ量を必要とし、サーバーが適切な拡張をサポートしている場合、(データベースなどでは) この方式でより大きな対費用効果を実現できることがあります。

縦方向のスケール アップには、以下のような短所があります。

• 導入時コストの上昇。縦方向のスケール アップは高価な場合があります (段階的に増加するデバイスのアップグレード コスト)。

• 固有の、組み込まれたフォールト トレランスまたは冗長性が必要。一般的には動作可能時間の短縮。

• 単一プラットフォームによる障害のリスク。

固有の信頼性を向上させる可能性があるか調べる必要があります。特に、サービス可用性の監視と制御の方法が、この決定では重要です。この種のアプリケーションの可用性を高めるには、クラスタ化が 1 つのオプションになります。

この方式の最大の欠点は、より少数のサーバー リソースに可用性を依存することになるという点です。ハードウェア固有の冗長性がなければ、ホストしているサービスを失うという大きなリスクがあります。サーバーがダウンしている間、そのサーバーが提供しているサービスはすべて提供できなくなります。同様に、サーバーのキャパシティが最大に達した場合、より高性能なサーバーに交換しない限り、それ以上のサービス キャパシティは提供できません。

アプリケーションがセッション状態管理をサポートできるとき、また負荷分散によってより対費用効果の大きいソリューションが提供されるとき、またインターネット サービスを複数のサーバーに分散できるときには適しています。

横方向のスケール アップには、以下のような長所があります。

• スケーラブルで可用性の高いサービスを展開して、中断なしにキャパシティを向上させることができます。

• 修理または交換のためサーバーを追加または取り外すときにサービスを停止する必要がなく、サーバーの管理とサポートが容易です。

• アプリケーションを複数のサーバーに横方向のスケール アップする場合、線形の予測可能なコストとして見積もることができます。

横方向のスケール アップには、以下のような短所があります。

• アプリケーションによっては、1 台のサーバーに実装するより、サーバーあたりのコストおよびハードウェア負荷分散のコストが高くなることがあります。複数のブートおよび複数のアプリケーション イメージが必要です。

• ライセンスがサーバー単位で販売されている場合は、ソフトウェア ライセンス料が高くなる場合があります。

• 環境に適切な最善の方法を定義しなかった場合、アレイに追加された各サーバーの管理作業が増加する場合があります。

ソリューションを構築する最良の方法は、ユーザーの状態情報を単一のアプリケーション サーバー上で管理しないことです。ユーザーの状態を単一アプリケーション サーバー上で管理するアプリケーションは、負荷分散アルゴリズムによっては機能しない場合があります。このような問題を回避するための負荷分散用製品もいくつかあり、各ユーザー単位で負荷を管理することによって、セッション全体を通してユーザーが同じアプリケーション サーバーで処理されるようにします。次に、サービスは、単一サーバーではなく複数のアプリケーション サーバーを利用することができます。インテリジェントな負荷分散テクノロジを組み合わせると、複数のアプリケーション サーバーの方が、プロセッサとメモリが追加された単一サーバーよりも高いスケーラビリティと可用性を提供します。可用性が重要な意味を持つ場合、一般的な設計では最低 3 台のサーバーを組み合わせ、1 台のサーバーがオフラインでサービスに備え、常時 2 台の冗長性ペアがオンラインを維持します。

アプリケーション サーバーには、アプリケーションの特性に応じて、1 つまたは複数のプロセッサがあります。適切な負荷分散テクノロジを使用することによって、処理能力や I/O 特性が異なる複数のサーバーを単一のアプリケーション サーバー アレイに組み込むことも可能です。組み込みの冗長性や単一点での障害の解消は重要ですが、コストと、アレイ内のほかのサーバーへのフェールオーバーをサポートするコストとを比較する必要があります。このレイヤにユーザー状態情報やデータ コンテンツがない場合は、複数のサーバーによってアプリケーション サーバー レイヤの可用性とスケーラビリティを向上させることができます。

場合によっては、静的コンテンツやアプリケーション コードなどのデータ リソースは、Web およびアプリケーション サーバー レイヤのアプリケーション サーバーに複製するのではなく、余裕を持って構成された可用性の高いデータ リソース レイヤ サーバーで中央管理することができます。また、クラスタなどのフェールオーバーの手法を適用すれば、クラスタ化されたデータ リソース サーバーによって、急激に変化するアプリケーション リソースのタスクを単純化することができます。また、中央制御アプリケーション リソースでは、キャパシティの拡張と障害からの復旧が容易になります。ダウンタイムを最小限に抑えて優れたパフォーマンスを実現するには、データ リソース サーバーは複数のプロセッサ、十分なメモリ、冗長性コンポーネント (NIC、電源、およびファン) を備えた余裕のある構成にする必要があります。クラスタ化のテクノロジは、中央制御リソースの可用性を大幅に向上させます。ビジネス要件とアプリケーションの観点から考えると、中央制御が常に適切とは言えない場合もあります。

アプリケーション サイジングとモデリングによってプロセスを調整し、ソリューションおよびサービスをより円滑に提供しサポートすることができます。

ミドルウェアの考慮事項
一般に、アプリケーション レイヤはユーザーに提示されるものを指し、ミドルウェア レイヤには、アプリケーションをサポートする基盤となるソリューション コンポーネントが含まれます。現在の市場で最良の方法は、データを共有リソースに配置するキャパシティ オン デマンド技術によってスケーラビリティと可用性を最適化する方法です。これには、共有およびプールされた、冗長記憶域の新しいテクノロジ傾向を説明した「ハードウェアの考慮事項」セクションで説明するハードウェア記憶域のシナリオも含まれています。

ミドルウェア レイヤにも、縦方向と横方向のスケール アップに関して、同様の考慮事項があります。全体的なソリューション アーキテクチャに、アプリケーション、ミドルウェア、オペレーティング システム、およびハードウェアの各レイヤにまたがって機能する能力があるかどうかを判断することが必要な場合があります。一般に、競争の激しい市場のダイナミズムによって選択肢が増え、使用可能なオプションによって可用性とパフォーマンスを分離し、向上させることによって、高い柔軟性が実現されています。インターネットおよびイントラネット ソリューションをさらに最適化するソフトウェアおよびハードウェア アーキテクチャも登場しました。

IT 開発、必要スタッフ、およびトレーニングを最小限にとどめることのできる標準パッケージ ソリューションは有利ですが、ビジネス要件に適合するよう選択されたツールには十分な柔軟性が必要です。

一般的に、データ リソース レイヤのデータ コンテンツの必要条件を満たすには RDBMS の使用が最適です。ソリューションのこのレベルには、すべてのトランザクション データが保管されるため、このレベルの保護はきわめて重要です。単一バックエンド サーバーの組み込みの冗長性 (フォールト トレランス) が重要であり、潜在的な単一点での障害の解消、フェールオーバーおよび復旧にかかる時間、およびソリューションをクラスタ化できる能力を、可用性管理とキャパシティ管理の両方から検討する必要があります。キャパシティ管理では、各サーバー単体でのコストとパフォーマンス レベル、およびクラスタ内のサーバーに障害が発生した場合のパフォーマンス リソースの使用量とピーク時要求の必要条件に重点があります。

複数の CPU スレッド、または共存し、対称型マルチプロセッシング (SMP) マシンを最も活用できる複数のプロセスをサポートするアプリケーションでは、縦方向のスケール アップが最も効果的です。RDBMS では多くの場合がこれに当てはまります。このレイヤでは、縦方向のスケール アップがしばしば選択されます。これは、RDBMS では高容量メモリの必要条件と単一システム イメージ、および可用性のためのクラスタ化機能というオプションがあるためです。

ときには、ミドルウェアの階層の例として、データ リソース (データベース) のクラスタによって可用性だけでなくキャパシティに関する利点が実証できることもあります。フェールオーバーによって許容時間内に復旧できるクラスタ対応ソフトウェアでは、複数のサーバー間での分割によって、コンピュータ リソース (CPU、メモリ、ディスク、またはネットワーク) のキャパシティを追加することができる場合があります。これは、アプリケーションが単一システムに分割または分離されるためです。この場合、単一ノードで両方のノードのピーク時の負荷を処理できる能力を考慮する必要があります。障害が発生したシステムが復旧するまで、IT サービスは低下した状態で稼働しています。低下したパフォーマンス レベルは予想が難しいので、設定されたしきい値に違反する場合は、適切な対策または緊急事態対策の使用が必要になる場合があります。一般的に、可用性管理でもキャパシティ管理でも、クラスタ化ソリューションの設計、実装、およびサポートを予測しておかなければなりません。現在では、多くのデータベース ベンダが、クラスタ化、場合によっては障害が発生したノードのサービスへの影響を最小にして復旧を行うトランザクションのロール バックおよびロール フォワードを視野に入れた複数のノードの並行使用もサポートしているため、クラスタ化またはフォールト トレラントなシステムやソリューションの評価および導入への関心が高まっています。

Microsoft Web Solutions Platform および DISA アーキテクチャでは、異機種ハードウェア プラットフォームの混合と、データ リソースまたは RDBMS バックエンド システムまたはクラスタの高度な分離が可能です。

クラスタ化については、以下の考慮事項を検討する必要があります。

• 管理可能性。Gartner によれば、場合によっては管理コストが TCO の 55% を超えることがあります。

• スケーラビリティ。ソリューションが単一サーバーのアーキテクチャまたは階層化されたプラットフォームによって制限されません。

• 投資保護。これは、複数のフットプリントを統合する能力によって示されます。

• 高可用性。ダウンタイムの削減によって、コストを軽減し、可用性と利益性を高めます。

これらの考慮条件は、オペレーティング システム、ハードウェア、ミドルウェア、およびアプリケーション サポートによって異なります。

この文書の定義では、データベースはミドルウェアの一部と見なされます。アーキテクチャの設計については、いくつか重要な考慮事項があります。これらの重要性については、将来の変更や継続的サポートに与える影響を通じて、運用の時点で理解する必要があります。重要なパフォーマンス上の特性や意味があります。

技術コンポーネントの分散度に関するアーキテクチャ デザインでは、早期に決定しておくべき重要事項があります。データベース アーキテクチャとアプリケーション アーキテクチャは、分散およびミドルウェアに関する方針によって大きな影響を受けます。重要なポイントは以下のとおりです。

• ミドルウェアの決定は大幅な取り消しができない場合が多い - 賢明な選択をしなければ、後でそのツケを払うことになります。

• ミドルウェア ソリューションは実装が困難 - 適切なチーム スタッフの配置と設計上の支援が重要です。

• ミドルウェアの選択によって、下位レベルのアーキテクチャが決定される場合がよくあります。

• ミドルウェアは、システム内、またはシステム間で、さまざまな方法による統合を可能にします。

キャパシティ プランニングでは、分散トランザクション処理 (DTP) モデルに準拠するソフトウェアからのデータを利用します。このモデルは、X/Open によって確立された、異機種コンピュータ システム間の相互運用性を促進するための実績のある国際標準です。分散トランザクション処理 (DTP) ソフトウェアは、オンライン トランザクションを監視し、分散型クライアント/サーバー環境でビジネスの基幹オンライン トランザクション処理 (OLTP) アプリケーションを管理するために導入されます。トランザクション モニタなどのミドルウェアは、DTP (デスクトップ パブリッシング との混同に注意) のより一般的な情報カテゴリに分類されます。

ミドルウェア カテゴリとしては、そのほかに、メッセージング、トランザクション モニタ、Object Request Broker、データベース アクセス方式などがあります。仮想プライベート ネットワーク (VPN) や SSL (Secure Socket Layer) などの通信テクノロジも、ミドルウェアの選択と開発に影響する重要な設計要素です。最適化およびパフォーマンス向上、またはこれらのプロトコルのキャッシュ処理に関しては、ハードウェアに大きな進歩があり、幅広く使用されている Web 対応の安全なソリューションの実行可能性が高まったことも大きな影響を与えています。

オペレーティングシステムの考慮事項
ウィルス スキャンやバックアップ用のソフトウェアなど、カーネルに直接アクセスするすべてのコンポーネントがオペレーティング システム コンポーネントです。変更管理の原則に、さらに高い可用性と固有の設計を提供するため、Datacenter 2000 には OS レベルを安定させるためのコンポーネントの証明テストが含まれています。ISV の増大に対応して、同様の信頼性テストや証明機能がミドルウェア レイヤおよびアプリケーション レイヤで採用されつつあります。また、Microsoft.NET および Windows XP プラットフォーム内での階層化されたアプリケーションやミドルウェアの能力を向上させ続けるため、多くの作業が行われています。

アプリケーションのクラスタ対応は、オペレーティング システムに依存します。Microsoft は、NT 4 Enterprise Server でクラスタ サービスをサポートし、Windows 2000 Advanced Server および Datacenter 2000 ではさらに強化された機能を提供しています。クラスタ サポート、単一システム イメージ、エンタープライズ ディレクトリ サービス、その他のオペレーティング システム レイヤにおける要因は、IT またはサービス プロバイダ組織が利用できる選択肢に影響を与えます。

OS レイヤでの、共有記憶域システムの高度なサポートと交換ファブリック サポートによるマルチパス フェールオーバー機能によって、Windows NT ハードウェア ソリューションと設計における可用性とキャパシティを向上させる能力は、大幅に強化されました。

組み込みの OS パフォーマンス モニタについては慎重に検討する必要がありますが、多くの場合、情報に付加価値を付けたり、上位レベルのルールの相関を可能にする追加ツールが、コスト的には妥当な場合があります。

OS での監視と制御のサポートは、ベンダから公開されているデバイスおよびハードウェア抽象化レイヤのサポート方式によって異なります。Microsoft では、Windows 2000 ファミリおよびそれ以降の OS では標準ベースのイニシアティブを全面的に支持しています。このイニシアティブは現在、DMTF (Distributed Management Task Force) によって管理されています。DMTF は、要素およびデバイス監視の相互通信のための標準として、DMI (Desktop Management Interface) と WBEM (Web-based Enterprise Management) を提唱しています。多くの場合、簡易ネットワーク管理プロトコル (SNMP : Simple Network Management Protocol) 用の管理情報ベース (MIB : Management Information Base) テンプレートのように、内容豊富なデータ定義が共有情報モデル (CIM : Common Information Model) として確実な発展を遂げています。この CIM は、当初は Microsoft NT ファミリ用として提案されたものですが、ハードウェアおよびネットワーク デバイスの監視用として急速に支持を得ています。Microsoft が WBEM を基に開発したインプリメンテーションは WMI (Windows Management Interface) と呼ばれ、Microsoft 管理コンソール (MMC) や柔軟な Web ベース ブラウザのポータル ソリューションなど、多くの表示方式と結び付いて、携帯電話やモバイル機器など、さまざまな管理ステーションからの安全な仮想プライベート ネットワーク (VPN) および SSL (Secure Sockets Layer) 認証を可能にしています。

Windows 2000 Datacenter は、新しいレベルのジョブ オブジェクトの制御およびプロセスの制御を提供し、制限または制約を設定することができます。さらに高い可用性とキャパシティを確保するには、新しい動的リソース管理用ツールを理解する必要があります。

主要プロトコルのパフォーマンスを向上させる、多くのソフトウェア製品およびハードウェア機器が登場しています。これによって、XML、VPN、SSL、マルチメディア ストリーミング形式、DES 暗号化などを使用するためのソリューション パフォーマンス メトリックが急速に変化しています。これらの機能は、世界的規模でアクセスされることが多い大規模エンタープライズ展開の Web ソリューションで考慮事項となる項目を制限するために使用されます。このような進歩を遂げる以前は、セキュリティ、管理、およびパフォーマンスの問題が、こうした製品を使用する障害となっていました。

異機種環境の統合にあたっては、サポートするアプリケーション、相互通信のための標準 (ミドルウェア)、コスト、および選択した場合のパフォーマンス予測を慎重に調査する必要があります。可用性とスケーラビリティに関する最善の策を講じるために、IT ドメイン レイヤを考慮に入れ、十分な対費用効果の分析を実施して、柔軟性のある成長可能な設計を行うことが重要になっています。

オペレーティング システムの考慮事項については、MOF の運用フェーズ ドキュメントでさらに詳しく説明されています。詳細については、『MOF 運用ガイド』の「サービスの監視と制御運用ガイド」、「記憶域の管理運用ガイド」、および「ジョブ スケジューリング運用ガイド」を参照してください。

ハードウェアの考慮事項
可用性管理の点では、単一点での障害が発生する可能性のあるポイントに、妥当なコストで設定できる冗長性を使用することが最良の方法です。負荷分散装置、ファイアウォール、およびネットワーク デバイスにフェールオーバーを構成すると有効です。インテリジェントな負荷分散テクノロジは、冗長アプリケーション サーバーにフェールオーバーを提供します。クラスタ化されたデータベースとネットワーク記憶域によって、データ リソースの動作可能時間が確保されます。ベンダの選択および評価の基準となる標準の確立は、トレーニング コストをさらに削減するには重要なポイントであり、信頼できる統一されたパフォーマンス測定とキャパシティ プランニングを提供することができます。

同様に、対費用効果に優れた負荷分散も検討する必要があります。この負荷分散も単一点での障害を軽減します。たとえば、複数のポートを備えた NIC は、ネットワーク トラフィックをポート間で分割する負荷分散によって追加パフォーマンスを提供しながら、対応するポートへのスロットに冗長性を持たせることができます。

組み込まれたフォールト トレランスやシングル サーバーの信頼性向上なども考慮に入れなければなりません。

RAID (Redundant Arrays of Independent Disks)、冗長 NIC、電源、およびファンは、データ リソース サーバーの動作可能時間の改善に有効です。マルチホーミングによる冗長ネットワーク接続および無停電電源 (UPS : Uninterruptible Power Supply) も役に立ちます。どの程度の冗長性が適切かについては、基盤となるビジネス要件と配分できる予算によって異なります。

場合によっては、フォールト トレランスや可用性の改善によって負荷分散機能が向上し、予測成長分のキャパシティも確保できることがあります。

リモート監視ツールは、高性能で、ビジネスの基幹ソリューションを完璧に復旧、監視、および最適化できる能力を備えている必要があります。

管理ネットワークそのものがダウンしているときに障害が発生したノードを修復することは、管理機能上難しい問題です。バンド (帯域) 内の干渉や通常のネットワーク アクセスが不可能なときは、バンド外 (OOB : Out-of-band) 通信による管理または緊急復旧機能が、可用性管理スタッフにとってもキャパシティ管理スタッフにとっても大変重要になります。バンド外通信による管理とは、担当技術者に、代替 TCP/IP、ダイアルアップ電話回線、またはシリアル ケーブルによる管理ノードへのアクセスを提供する手段のことです。

統合形式かカードの追加形式かにかかわらず、バンド外通信技術を提供するサーバー、機器、ネットワーク装置があるかどうかは、サーバー ベンダを選択するときの基準になります。バンド外 (OOB) 通信管理では、オペレーティング システムとサービス制御、障害を発生したサービスまたはノードの再開、障害が発生しているサービスまたはノードへのオフラインでのアクセス、デバイス使用中でのファームウェアの制御とアップグレード、OS とサービスのセットアップ、BIOS およびブート デバイス制御、ハードウェア電源管理、BIOS 設定とハードウェア診断、および管理コンソールのリモート制御などの機能のうち、一部または全部が提供されます。興味深い方法として、OOB サーバー ソリューションによって現在提供されている VPN 経由の柔軟な Web ベース SSL (またはセキュリティで保護された ID) 認証制御では、マウス、キーボード、およびブラウザで制御するフルカラー グラフィック ユーザー インターフェイス サポートを使用して対応する携帯機器から、コンソールを制御することができます。

すべてのサーバー プラットフォームにデータ収集ツールをインストールしてサーバーの活動を継続的に監視し、社内または社外の統合された分析設備に対し、定期的にデータを送信する必要があります。動向に関する情報と分析は、毎月または四半期ごとのシステム可用性レポートを通して提供します。これらのレポートでは、可用性を最適化し、目標のサービス レベルを達成し、システムのセキュリティを確保するための勧告を行います。

上で説明した Web ソリューション アキテクチャ設計は、Microsoft Web Solutions Platform ソフトウェアの原則によって実現され、各階層で柔軟性を備えた異機種のクロスプラットフォーム ハードウェア コンポーネントを使用できます。このようなアーキテクチャは、分散型システム、基幹業務ソリューションのプランニング、および高可用性を備えたスケーラブルな IT サービスの提供に最適です。数日間にわたるリソースの利用動向の分析によって、記憶域またはパフォーマンス キャパシティに関する拡張の必要性が指摘されることもあります。

このアーキテクチャは、Web またはアプリケーション サーバー レイヤの横方向のスケール アップ、データ リソース サーバー レイヤの縦方向のスケール アップ、およびストレージ エリア ネットワーク (SAN : Storage Area Network) やネットワーク接続記憶域 (NAS : Network Attached Storage) 装置によって追加されるプール化された記憶域の割り当てを単純化することにより、柔軟性に優れたキャパシティをオンデマンドで提供します。この設計では、投資保護と最高水準のハードウェアおよびソフトウェア ベンダの選択を可能にすることによって、冗長性と高可用性を容易に確保できます。これは、スケーラビリティと可用性を同時に備えた Web サイトを設計するときの良い例で、スケーラビリティと可用性の両方の必要条件が含まれることから、ROI および TCO 分析によってソリューションのコストの妥当性が認められます。

もともと、SAN はシステム エリア ネットワーク (System Area Network) の頭字語でもありました。しかし最近ではストレージ エリア ネットワーク (Storage Area Network) としての方が一般的になっています。サーバー間での相互プロセス通信を目的とするシステム エリア ネットワークでは、サーバー間に高速のクロスバー交換機または通信バスを必要とします。このような高速、低レイテンシの相互接続製品は、クラスタ化によってさらに高い可用性とスケーラビリティを提供する、低コストの業界標準サーバーを可能にしています。将来的には、相互接続ハードウェアの分野に新しく登場した標準である Infiniband が、高スケーラビリティ ソリューションの新しい設計の道を築こうとしています。

キャパシティ プランニングの最終目的は、指定されたユーザー数を正確な応答時間でサポートできるコンピュータ システム、ネットワーク、およびその他のリソースの種類と構成を判定することです。実際のリソースを使用し妥当な作業時間でこの判定をするには、テスト対象のシステムで多くのユーザーが対話する状態をシミュレートする必要があります。Microsoft には、このシミュレーションを実行するためのツールが数多く用意されています。

キャパシティ プランニングに役立つ最も重要なパフォーマンス測定値は、コンピュータ システムがサポートできる、指定した負荷に対する最大トランザクション速度です。1 つまたは複数の CPU がその時間の 100% で使用されているとき、システムは最大トランザクション速度に達しています。このメトリックはプラットフォーム トランザクション キャパシティと呼ばれ、測定に使用されたトランザクションがどのような操作の組み合わせであったかによって、測定結果は大きく異なります。たとえば、シミュレートされているブラウザに平均 500 バイトのファイルを送信するテストを受けた Web サーバーが、1 秒あたり 2,000 回の操作数というプラットフォーム トランザクション キャパシティを持っているかもしれません。同じコンピュータで、平均 7,800 バイトという実際の Web ページやグラフィックの平均サイズにより近いファイル サイズの転送テストを実施すると、プラットフォーム トランザクション キャパシティは 900 になります。

プラットフォーム トランザクション キャパシティを測定するには、2 つの方法があります。最初の方法は、多数のユーザーが一定のトランザクション シーケンスでシステムを使用する状態を、ユーザーが画面を読む時間やシステムから返された情報について検討する時間を含めてシミュレートする方法です。InetLoad は、この方法をサポートしています。もう 1 つの方法は、トランザクションをランダム シーケンスでできるだけ速く、ただし一定の頻度で生成する方法です。トランザクション コスト分析 (TCA : Transaction Cost Analysis) は、Web サイトのキャパシティ最適化によく使用される手法です。InetLoad や WCAT などの Microsoft シミュレーション ツールは、この方法をサポートしています。

プラットフォーム トランザクション キャパシティを測定するときは、必然的にシステムの CPU が制限因子であり、環境内のほかの部分は対象になりません。したがって、制御され適切に定義された環境が必要になります。その他の制約やボトルネックが、測定されるプラットフォーム トランザクション キャパシティに大きな影響を与える場合があります。Windows NT ファミリ プラットフォーム付属の Microsoft の perfmon パフォーマンス監視ツールを使用すると、ボトルネックの有無とその場所の特定に役立ちます。

一般的な E コマース インターネット ソリューションでは、縦方向のスケール アップと横方向のスケール アップのどちらを選択するかについても検討すべき項目があります。キャパシティ管理の点からは、どちらの方法にも対応できるプラットフォーム設計が最良の方法と言えます。

DISA アーキテクチャでは、インターネット クライアントをサポートするアプリケーション機能を提供するためのコンポーネントを含む、3 つのレイヤが定義されています。

以下で説明する 3 つのレイヤのほかに、セキュリティと管理について、この設計の汎用コンポーネントとして言及しておきます。

セキュリティ

このアーキテクチャでは、顧客のビジネス要件に基づいて、必要なセキュリティ コンポーネントを統合することができます。また、異なるレイヤの間に複数のファイアウォールを目的に応じて配置し、たとえば負荷分散レイヤとアプリケーション サーバー レイヤの間に 1 つ、アプリケーション レイヤとデータ リソース レイヤの間にもう 1 つファイアウォールを配置することができます。

管理

インターネット アプリケーションは、あらゆる一般的な管理フレームワークと統合することができます。アーキテクチャ上のこのような柔軟性によって、多くの異なるサーバーが協調して 1 つの完全なアプリケーションを提供することができます。ピーク時でも全システムがオンラインで稼働するためには、システム管理において確固とした取り組みが必要です。可用性、キャパシティ、およびリソース使用状況について価値のあるデータを提供してくれるインテリジェント エージェントが重要です。ハードウェア ベンダの評価も、この基準に従って行います。バンド外通信用ハードウェアを使用すれば、Web ベースの SSL 認証によるリモート制御が可能になり、リモートのコンソールと情報がオペレーティング システムの影響を受けなくなります。

管理ステーションは、システム内のノードを管理し、監視する運用センターです。このセンターはデータを収集するためのサーバー ノード (データベースを含む場合が多い) か、または管理情報が表示されるワークステーションです。より一般的に使用されているのは、WMI と WBEM による柔軟性を備えた Web ベースのコンソールで、共通情報モデル (CIM : Common Information Model) などの確立されたプラットフォーム標準である管理情報ベース (MIB : Management Information Base) 拡張機能によって要約された、総合的な詳細情報を提供します。分散コンピューティングの世界では、DMTF (Distributed Management Task Force) が標準に関する作業のほとんどを管理しています。多くのエンタープライズ システム管理ソリューションでは、IT サービス コンポーネント情報をより効果的に相関させるための高度なツールセットやパッケージ ソリューションを必要とします。

多層方式の web ソリューションでは、クライアント レイヤでアプリケーション データが提示され、処理されます。市販されている最も一般的なクライアントは、Web ブラウザです。Web ポータル プラットフォームの概念によって、アプリケーションの提示とシステム管理の制御とレポート作成の両方に関するさまざまな情報が、Web ベースの画面を通して選択的に表示されるようになっています。システム管理の情報としては、可用性、キャパシティ、パフォーマンスに関する情報と、ハードウェア、ミドルウェア、アプリケーションなどの IT サービス コンポーネントを区分して分離するための多くのレベルが含まれています。これらの概念は、詳細情報とその情報のアクセス可能性を提供し、キャパシティと可用性をより効果的に管理するための基礎として重要な概念です。WMI、WBEM、およびアプリケーション応答監視 (ARM) の詳細については、『MOF 運用ガイド』の「サービスの監視と制御運用ガイド」を参照してください。

負荷分散レイヤ

このレイヤは、クライアントに対して仮想ホスト名という形で 1 つのシステム イメージを提示し、クライアントの要求を複数のアプリケーション サーバーに分配します。負荷分散技術には、ソフトウェアによるものとハードウェアによるものがあります。ソフトウェアの場合は、通常、汎用サーバー上にインストールされます。例としては、Microsoft Windows 2000 Advanced Server または Datacenter 2000 にインストールされている Microsoft ネットワーク負荷分散 (NLB : Network Load Balancing) 機能や、Windows NT 4.0 Enterprise 版にインストールされている Microsoft Windows 負荷分散サービスがあります。

どの負荷分散技術とベンダを選択するかは、ビジネス要件や対象となるアプリケーションの特性によって決まります。

ハードウェア (ネットワーク機器またはスイッチ方式のデバイスなど) による負荷分散は、特化されていることが多く、パフォーマンスを大きく向上させることができます。

頻繁に要求されるページの静的コンテンツやコンポーネントの Web キャッシュは、パフォーマンスを高めスケーラビリティを提供する重要な設計コンポーネントです。これらのデバイスは、要求されたコンテンンツおよびオブジェクトを Web サーバーから取得して保管し、それを提供するため、Web サーバーの負荷を軽減しながらコンテンツの配布速度を高め、応答時間を短縮させることができます。ソフトウェア専門のベンダがたびたびハードウェア ベンダとパートナーを組んで、このようなソリューションを開発しています。多くのアプリケーションの領域で、このようなキャッシュ デバイスが力を発揮しています。主な利点としては、レイテンシの短縮、帯域幅の使用量の改善 (減少)、それによる全体的通信コストの減少があり、ときには、公共のインターネット経由で来るはずのデータをローカルで提供することによって、パフォーマンスの予測を容易にし、送信コストを軽減します。

図 6: Web エンタープライズソリューションのための多層形式の Microsoft Web Solutions Platform および DISA アーキテクチャの例

Web およびアプリケーション サーバー レイヤ

アプリケーション サーバーは、インターネット アプリケーションの基本的な作業を実行します。このレイヤには、Microsoft インターネット インフォメーション サービス (IIS) のような Web サーバーと、Microsoft Site Server Commerce Edition や Microsoft Commerce Server 2000 などの E コマース システムが含まれます。アプリケーション サーバーは、エンタープライズ リソース プランニング (ERP : Enterprise Resource Planning) システム、カスタマ リレーションシップ マネージメント (CRM : Customer Relationship Management) アプリケーション、または自動販売システムなどほかのデータ リポジトリにリンクする場合があります。

データ リソース レイヤ

データ リソース レイヤは、アプリケーション データを格納、管理、アクセスする場所です。このアーキテクチャでは、アプリケーション サーバーのドライブに複製データを配置する代わりに、高可用性の中央管理によるファイル サーバーを提供して、複製による問題を回避します。このレイヤには、製品カタログ、ユーザー登録情報、出荷情報、およびサイトのアクセス履歴ログなど、E コマース データを格納するデータベースがあります。また、アプリケーション データ リソースまたはレガシー アプリケーションを保有するほかのシステムへの接続を提供することもあります。

優れた多層アプリケーションを作成するには、プランニンングと最終製品の実装の段階でいくつかの判断が必要です。状態やデータは、ミドル層にキャッシュしてはいけません。開発プロセスの設計フェーズでこのようなキャッシュを回避すれば、膨大な時間をかけてコードを追跡したり書き直したりすることが避けられます。理想としては、そのアプリケーションのスケーラブルな実装で容認できるパフォーマンスが提供される均衡点を見つけます。これには、通常、トレードオフが伴います。スケーラビリティは、スループットが上昇するにつれて増大します。

Microsoft Web Solution Platforms アプリケーションのガイドラインでは、リソースの取得時間とリソース使用時間を最小にするよう奨励しています。ユーザーとネットワークの対話がトランザクションの一部になるのを回避するようにします。

スケールアップされたサーバーのクラスタ化は考慮すべき事項であり、一般にデータ リソース レイヤでは奨励されています。

共有記憶域の技術とアプリケーションの対応が向上したことによって、クラスタ化のオプションがさらに実現可能になっています。

キャパシティの改善に必要なテクノロジ ソリューションが高可用性の提供に必要なテクノロジ ソリューションと同じになることは、よくあることです。たとえば、ソリューションをクラスタ化すれば、多くの場合、両方の機能が提供されます。また、ある実装コストが、可用性ニーズへの対応というだけでは認められない場合があります。しかし、これにキャパシティ ソリューションへのニーズが加われば、両方の要件によって実装コストの妥当性が認められます。したがって、可用性とキャパシティの実装においては、共通のテクノロジ ソリューションで両方のニーズを満たすことができないか、慎重に検討する必要があります。

設計の段階でも最適化の段階でも、データベースの可用性とスケーラビリティについては考慮すべき条件が数多く存在します。たとえば、データベース トランザクション ログ ファイルはデータ要素と同時にシーケンシャルに書き込まれるのが普通です。ログ ファイルが書き込み用として保護され、最適化されたディスク (たとえば個別のミラー化ペア) に分離されることによって、データベースのパフォーマンスと可用性が向上します。同様に、RAID (Redundant Arrays of Independent Disk) レベルなど、多くのディスクにストライピングする速度によって、データやインデックスのパフォーマンスを大幅に向上するとともに、チューニングのオプションを提供することもできます。

アプリケーション サイジングによって、新しいアプリケーションまたはシステムの設計および構築に関する勧告が提供されます。多層アーキテクチャは、CPU、メモリ、ディスク、または I/O 処理速度、ネットワーク帯域幅などの主要分野で、拡大と柔軟なチューニングが可能であり、多くの場合、適切な投資と言えます。ハードウェアおよびソフトウェア ベンダのホワイト ペーパーやテクニカル ノートを参照し、当初のアプリケーション サイジングや、将来のソリューション パフォーマンス改善の " 最善の策" を見つけてください。最近の多層 IT ソリューション設計における技術革新は、今日の E コマース市場での対費用効果の大きいコンピュータ リソース使用にとって重要です。

また、記憶域を取り巻く新しい技術を理解することも大切です。記憶域には、従来の直接接続記憶域 (DAS : Direct Attached Storage)、ストレージ エリア ネットワーク (SAN) と呼ばれる冗長性の高い相互接続パスを備えた交換ファブリックによる共有プール、最近増加しているネットワーク接続記憶域 (NAS : Network Attached Storage) という 3 つの基本的な種類があります。それぞれに重要な考慮事項があり、設計時や変更の勧告 (キャパシティ プランなど) で記憶域を決定する際には、考慮事項を十分に理解しておく必要があります。

SAN は、専用の高速ファイバー チャネル ネットワークで相互接続された複数の記憶域で構成されます。ストレージ エリア ネットワークの記憶域プールは、アプリケーション サーバー、ミドルウェア (データベース) サーバーから直接アクセスでき、記憶装置間で通信するための標準プロトコルを使用します。一般にこれらの装置は、高いフォールト トレランスを備えたスケーラビリティが高い記憶装置であり、データベースなど高パフォーマンスでレイテンシが小さいことが必要なアプリケーションに最適です。ストレージ エリア ネットワークは、データの孤島になりがちな直接接続記憶域の短所を克服するために導入された方式です。

DAS モデルでは、内部または外部の記憶域が特定のサーバーに接続され、このようなサーバーがエンタイプライズ全体に散在しています。直接接続記憶域 (DAS) ではサーバー内部に、一般にシステムをブートするために必要なディスク ドライブを搭載し、SCSI で接続された外部記憶域サブシステムが含まれています。直接接続記憶域 (DAS) は導入コストが低いため、共有記憶域などコストのかかる高度な可用性やパフォーマンスを必要としない作業グループや部門環境では、現在でもよく使用されています。

SAN はデータのブロックを扱うネットワークですが、ネットワーク接続記憶域 (NAS : Network Attached Storage) はファイルの提供と保存に対して高度に最適化された、パフォーマンスに特化したサーバーまたは機器を使用します。こうした NAS サーバーの中には、多数のユーザーが同時に同じファイルにアクセスすることができるものがあります。ドットコム、xSP Web サイトの設計にとっては魅力的な方法です。ストレージ エリア ネットワークはエンド ユーザーから見た可用性とパフォーマンスに優れ、一方 NAS はインストールと管理が容易です。SAN はネットワークに直接接続し、ファイバー チャンネル スイッチによる相互接続を必要としません。したがって、記憶域の方式の変更には、可用性とキャパシティの管理に関して重要な設計上の影響を受けることがあります。

ハードウェア サーバーおよび記憶域のベンダは、高度なソフトウェアによって記憶域を仮想化し、オンデマンドによる記憶域またはキャパシティのプールを実現する方向をめざし、通信業者 (ホットプラグ対応ドライブ装備) やデバイス業界は、対費用効果の大きい移行方式と投資保護を促進する方向に進んでいます。一般的には、各サーバーにブート用のミラー化されたディスク ペアを搭載しておいて、共有記憶域については慎重に検討するというのが、将来のキャパシティ必要条件の最適化の設計と運用を考慮する場合においても通常の対応です。

キャパシティ管理で見積もりを作成するうえで賢明な方法は、数値を高めに見積もって、サービスが低下したり停止したりするより余裕を持ったキャパシティを提供することです。SLA を達成できなかった場合のコストは、予防的プランニングによる余剰キャパシティのコストよりはるかに高くなります。また、稼働停止の公表、さらに不十分なキャパシティについて内部の方針を理解させるコストは、追加キャパシティのために前もって割り当てるコストより多くなることにも留意してください。この原則が適用される最も重要なレイヤは、ハードウェア レイヤとネットワーク レイヤです。

可用性対策は、一般的には、サービスを提供する IT ソリューションに埋め込まれています。このプロセスは、"予期された" 状況に対応します。"予期された" というのは、発生の確率が高いイベントであることを示します。つまり "予期された" という中には、通常の処理だけでなく、たびたび発生する障害も含まれています。詳細については、『MOF 運用ガイド』の「記憶域の管理運用ガイド」を参照してください。

サービス継続性管理では、より深刻でコストのかかる予期できない可用性リスクを扱います。しかし、どちらのキャパシティ管理タスクでも、ハードウェア OLA を明確に識別し、ハードウェア コンポーネント リソースの低下を前もって警告するしきい値レベルを設定しなければなりません。これは、可用性と、危機管理またはサービス継続性の両方のプランニング サイクルで実行する必要があります。サービス継続性の手順およびシナリオでは、普通、可用性が失われそうな危険箇所を指摘します。どちらも、アプリケーション サイジングによる推定値とハードウェアに関するモデリング分析のデータを必要とします。一般的には、指定されたユーザー数での全体的なスループットが追求されますが、より高度な危機管理コストを算出するには、使用量のレベルをいろいろ変化させたスケーラビリティの見積もりが有効です。

ネットワークの考慮事項
建物内のネットワークは通信のバックボーンを提供し、コンピュータ システムはこのネットワーク上で通信を行うことができます。場合によっては、ネットワーク ハードウェアや NIC は、ハードウェアと見なされることがありますが、この文書ではネットワークとして分類します。以下の各ネットワーク コンポーネントについて、該当する対象 OLO を考慮する必要があります。

• パッシブ コンポーネント。配線、壁面取付用ケーブル ジャックなどのパッシブ コンポーネントは、どんなネットワークにおいても重要なコンポーネントです。ケーブル ジャックなどの基本コンポーネントが故障した場合、そのジャックに接続されているサーバーに到達できなくなることがあります。したがって、パッシブ コンポーネントの対象 OLO を考慮しなければなりません。

• ハブ、スイッチ、ルーター。ハブ、スイッチ、およびルーターは、あらゆるネットワーク インフラストラクチャの基本コンポーネントです。これらのコンポーネントは、ネットワーク上のデータを制御し、ルート設定します。各コンポーネントは、いつでも使用可能であり、スタックの上位にあるレイヤが必要とするキャパシティを十分に提供できなければなりません。

• ネットワーク インターフェイス カード (NIC)。ネットワーク インターフェイス カードは、コンピュータ システムがネットワーク バックボーンに接続するための手段です。これらのコンポーネントは比較的安価であり、多くの場合、スロットに複数のポートが接続され、1 台のマシンに複数のカードを組み込んで、障害時の冗長性を提供します。一般的には、単一のまたは 1 組の IP アドレスを表す複数のポートやカード間で、同時にスケーラビリティと冗長性を実現する OS や NIC のサポート ソフトウェアがあります。また、外部 Web トラフィックを 1 つのカードに転送し、ほかのカードを "管理ネットワーク" と呼ばれる内部管理データ用として予約することもよく行われています。いずれの場合も、ネットワーク設計の構成に顧客へのサービス要件を考慮に入れる必要があります。

実際のネットワーク使用状況に基づいて、将来のキャパシティ ニーズを予測します。ネットワーク通信業者が、合意したサービス レベルを守っているかどうかを判定します。ネットワークの可用性を低下させるおそれがある単一点での障害を特定します。この継続的監視とコンサルティング サービスによって、意思決定をサポートするデータや、ネットワークを活用するための専門的アドバイスが提供されます。ハードウェアまたはソフトウェアによるネットワーク負荷分散を利用して、さらに高い冗長性、最適化、チューニングを確保するには、ベンダからハブ/スイッチ/ルーターを入手することも必要です。

単一点での障害を減らすこともできる、対費用効果に優れた負荷分散方式を検討する必要があります。たとえば複数のポートを備えた NIC は、ポート間でネットワーク トラフィックを負荷分散することによってパフォーマンスを向上させながら、対応するポートへのスロットに冗長性を提供します。これらのコンポーネントは比較的安価であり、スケーラビリティと可用性の両方を向上させるためのプランとして、また、成長を見込んだ余剰キャパシティを提供する方法としても、良い方法といえます。また、すべての外部 Web トラフィックを 1 つのカードに転送し、もう 1 つのカードを "管理ネットワーク" と呼ばれる内部管理データ用として予約しておく方法も、よく使用される方法です。いずれの場合も、ネットワーク設計の構成には、顧客へのサービス要件を考慮する必要があります。

負荷分散を実装するには、いくつかの方法があります。この文書では、負荷分散の 3 つの重要な方法について説明します。

• ラウンドロビン ドメイン ネーム システム (DNS)

• 負荷分散スイッチ

• Windows 2000 Advanced Server または Datacenter 2000 のネットワーク負荷分散機能

ラウンドロビン DNS では、サイトの DNS サーバーを、要求されるたびに、クラスタ内のサーバーの全 IP アドレスのリスト内の順番を変えて返すように設定します。通常、クライアントは、返された IP アドレス リストの最初の IP アドレスに要求を送信します。そのため、要求はクラスタ内の異なるサーバーに転送され、サーバー間でトラフィックが分散されます。

負荷分散スイッチは、TCP 要求をサーバー ファーム内のサーバーにリダイレクトします。このようなスイッチは、スケーラビリティが高く、相互運用可能な信頼性の高いソリューションを提供します。負荷分散を実装するため、このスイッチは一般に、要求を送信したクライアントに共通の仮想 IP アドレスを提示し、次にその要求を利用可能なサーバーに転送します。ほかのソリューションでは、受信パケットの HTTP ヘッダーに保管されている情報に基づいて、クライアントの要求をクラスタ内のサーバーに転送します。

Windows 2000 Advanced Server ネットワーク負荷分散 (NLB) 機能は、TCP/IP サービスを提供する複数の Web サーバーに IP トラフィックを分散します。ネットワーク負荷分散は、クラスタ全体の共通仮想 IP アドレスを提示し、クライアントの要求をクラスタ内の複数のサーバーに透過的にパーティション化します。ネットワーク負荷分散は、多くのアプリケーションに高い可用性とスケーラビリティの向上をもたらします。

可用性が高くフォールト トレラントなネットワーク ハードウェア プラットフォームが市場に登場しています。また多くのベンダが、IP 負荷分散、静的 Web コンテンツのキャッシュ、および自動リダイレクトおよびネットワーク トラフィックのチャネリングによって、フェールオーバー時および復旧シナリオのパフォーマンスを改善してトラフィックをリダイレクトするパフォーマンス改善方式をサポートしています。ベンダを選択する際は、対費用効果、組み込みの冗長性とフォールト トレランス、TCO (総保有コスト) の観点、定期的に調査される代替ハードウェアおよびソフトウェアによるシステムおよびネットワーク管理システムなどについて検討する必要があります。サービス レベル管理の交渉にあたっては、キャパシティ管理、可用性管理、記憶域管理、およびネットワーク管理の設計およびサポート スタッフの専門知識も取り入れます。セキュリティ関連事項やシステムまたはネットワークの管理情報も、評価のプロセスにおける重要な基準となります。同様に、トレーニング コストやサポート コストも、コスト分析やベンダ選択のプロセスでは、早い段階から検討要因として加えておく必要があります。

エンタープライズ ネットワークの管理システムでは、パフォーマンスを追跡し、ネットワーク全体の使用動向を識別する必要があります。経験豊かなスタッフがこのデータを解釈し、少なくとも四半期に 1 回はネットワーク可用性レポートを発行します。このレポートには、ネットワーク パフォーマンスの改善に関するデータ分析と勧告を盛り込み、潜在的な問題の防止と将来のビジネス ニーズに適合するキャパシティを計画します。

正しく適用すれば、コストの割り当て方針によって、サービスの使用状況を変えることができます。たとえば、IT 部門でネットワーク帯域幅に問題がある場合、ピーク外の時間帯にシステム リソースを使用する顧客に対して有利な価格方針を設定することができます。この方法では、キャパシティに関する問題を軽減できるだけでなく、サービスのエンド ユーザーにコストの節約手段を考慮することを奨励し、さらには、サービスを消費する部門で積極的にコスト削減を追求するという、予防的措置を実現することにもなります。これによって、サービスの顧客と、サービスの供給とサポートを行う IT 組織の両方が利益を受けることができます。

設備の考慮事項
キャパシティ管理部門は、IT サービス ソリューションに含まれるレイヤのキャパシティおよびパフォーマンスの見積もりにデータを提供することによって関与します。これらのサービスおよびリソースには、可用性プラン、サービス継続性管理、または緊急事態対策のための入力データが含まれることがあります。リスクを受け入れるかどうかの決定は、ソリューションのコストによって決まります。

一般的に、設備や、次に説明する外部サービス レベルの障害は、自然によって引き起こされる深刻な災害を原因とします。この場合、復旧された基幹サービスが災害時でもビジネスを維持できるようなキャパシティ レベルおよびパフォーマンス レベルのプランニングが重要であり、サイトのフェールオーバーを実行するための実装とプランニングに必要なコストの数値を含めて考えます。多くの場合、このレベルに関しては、災害復旧を専門とする第三者との契約が存在します。緊急事態対策の立案とテストの段階で、キャパシティとパフォーマンスの管理を慎重に評価して、サービス継続性プロセスの実装が完了し、あらゆる危機に対処できるようにしておきます。一般的に、設備の考慮事項としては、対象となる IT サービスの運用に十分な通信状態、帯域幅、電力、および設置スペースなどがあります。キャパシティとパフォーマンスのサービス レベル目標によって、第三者から提供されるサービスの SLA 定義が決まります。内部 IT スタッフがサイトを運用する場合は、SLA ではなく OLA になります。

外部サービスの考慮事項
外部サービスは 7 つの階層の最後の層に当たり、一般には外部のサービス プロバイダのユーティリティ (提供サービス) で構成されます。電力、ガス、水道、電気通信、インターネット、アプリケーション ソリューション プロバイダ (ASP)、およびユーティリティとしての記憶装置などです。IT サービスの提供が依存する外部プロバイダによるサービスは、このカテゴリに分類されます。基礎となる契約は、通常、サービスの品質を確保するため、該当する SLA に含まれています。状況によっては、IT もキャパシティ要件の定義や外部サービス プロバイダの見直しにかかわる場合もあります。多くの場合、エンドユーザーは、このレイヤと IT を区別せず、顧客満足度は IT とサービス プロバイダとの協力関係によって決まります。

このようなサービスの可用性管理とキャパシティ管理は大切ですが、外部サービスに障害が発生した場合の一般的なシナリオはサービス継続性管理または緊急事態対策のプランニングの業務とされているため、別の観点に重点を置いて対策を行います。サイトを復旧しなければならない場合、または主要サービス プロバイダを変更する場合に、最も重要な基幹 IT サービスを容認できるパフォーマンス レベルで提供し続けるためには、重大なパフォーマンス上の考慮事項があります。キャパシティ管理スタッフは、サービス継続性管理によって提案されるさまざまな緊急事態対策のシナリオに対して、コストおよびキャパシティに関するデータを提供します。この情報は最終的な緊急事態対策のプランニング プロセスで利用され、緊急事態対策の代案と、現在実行されているソリューションのキャパシティ設計または将来の改善計画に影響を与えることがあります。

たとえば、IT 顧客が記憶域のニーズを決定するにあたって、記憶域ユーティリティのベンダからコンサルティング サービスが提供されることがあります。その他のサービスとして、インストール、構成、立ち上げ、キャパシティ使用状況およびキャパシティのレポート作成、および記憶域の管理などがあります。月額の料金で、顧客と共にオンサイトでサービスを行う場合は、プライベート記憶域サービス (Private Storage Utility) と呼ばれますが、帯域幅が広がりコストが低下したことによって、現在は、パブリックなオフサイトからホストされた完全管理の記憶域サービスもあります。公共保管サービス (Public Storage Utility) は、専用通信回線によって提供されるか、または多くの場合、パブリックなインターネット サービス プロバイダやアプリケーション サービス プロバイダ (xSP) によるセキュリティ保護された VPN 接続によって提供されます。この文書で取り上げたキャパシティおよびパフォーマンスの原則は適用可能ですが、より多くのコンポーネントがサービス契約の一部として契約に従って提供される場合があります。アウトソーシングするサービスの効果的な設計、管理、および制御については、可用性、キャパシティ、サービス継続性、およびスタッフの管理がきわめて重要です。また、これらの管理グループは、契約されたサービスの IT サービス品質を示すメトリックの監視を支援する必要があります。

緊急事態対策および手順に関しては、キャパシティについてさらに考慮すべき点があります。キャパシティ管理は、多くの場合、不測事態のサービス継続性シナリオと関連があります。このシナリオでは、IT はリスクを想定して積極的にフェールオーバーと復旧の手順を設計します。このシナリオは、"災害" と呼ばれることもあります。予想される単一点での障害に、自動的にフェールオーバーと復旧を行うための対応策が組み込まれている場合は、高可用性を備えたソリューションと見なされます。いずれの場合も、可用性と危機管理ソリューションのキャパシティをプランニングするのは、多くの場合、キャパシティ管理マネージャとそのスタッフです。詳細については、『MOF 運用ガイド』の「サービス継続性管理運用ガイド」および「可用性管理運用ガイド」を参照してください。

キャパシティ管理の最適化およびスケーラビリティに関する主要 IT レイヤの考慮事項のガイドラインとしては、業務改善のための一般的な規定とキャパシティ管理プロセスの理解が必要です。

 ページのトップへ

推奨トレーニング コース

このガイドで説明したタスクを実行するために最低限必要な予備知識については、以下に示す Windows 2000 用トレーニング リソースを参照してください。これらのコースの詳細情報は、https://www.microsoft.com/learning/default.mspx (英語) および https://www.microsoft.com/japan/learning/training/default.mspx に記載されています。

コース名
1267 : Planning and Implementing Active Directory (英語コース)

1556 : Administering Microsoft Windows 2000 (英語コース)

1557 : Installing and Configuring Microsoft Windows 2000 (英語コース)

1558 : Advanced Administration for Microsoft Windows 2000 (英語コース)

1561 : Microsoft Windows 2000 ディレクトリ サービス

2151 : Windows 2000 ネットワーク エッセンシャル

2152 : Microsoft Windows 2000 インプリメンテーション

2153 : Microsoft Windows2000ネットワークインプリメンテーション

2154 : Microsoft Windows 2000 ディレクトリーサービスインプレメンテーション

謝辞

この文書の内容は、Accenture、Avanade、Microsoft Consulting Services、Hewlett-Packard Company、Lucent Technologies/NetworkCare Professional Services、および Compaq Global Services の IT 分野におけるさまざまな実装の経験に基づいています。

この文書に資料を提供していただいた各団体の寛大な支援に対し、心から感謝いたします。

この文書に記載されている情報は、発行時点で議論されている問題点に関する Microsoft Corporation の最新の見解を示しています。Microsoft は変化する市場状況に対処しなければならないため、本書の内容を Microsoft の確約事項として解釈してはならず、Microsoft は発行日以降に提示された情報の精度についてはいかなるものであれ保証致しません。

この文書は、情報の通知のみを目的としており、Microsoft は本書に記載されている情報について明示的にも暗黙的にも一切の保証を致しません。

適用し得るすべての著作権法を順守する責任はユーザーにあります。本書中のいかなる部分も、Microsoft の書面による許可なしには、いかなる目的のためであれ、いかなる形態、手段 (電子的、機械的、コピー機の使用、記録など) によっても複製、検索システムへの格納、または伝送してはなりません。ただしこれは、著作権法上のお客様の権利を制限するものではありません。

この文書の内容に関する特許、特許出願、商標、著作権、およびその他の知的財産は、Microsoft が所有します。Microsoft との書面によるライセンス契約に明記されていない限り、本書の提供が、以上の特許、商標、著作権、あるいはその他の知的財産権の利用を認めるものではありません。

この文書で例として取り上げた企業、組織、製品、人物、および出来事は、架空のものです。実際の企業、組織、製品、人物、または出来事との関連を意図または暗示するものではありません。

© 2001 Microsoft Corporation. All rights reserved.

Microsoft、BackOffice、MS-DOS、Outlook、PivotTable、PowerPoint、Microsoft Press、Visual Basic、Windows、Windows NT、および Office ロゴは、米国およびその他の国における Microsoft Corporation の登録商標または商標です。

この文書に登場する実在の企業名や製品名は、各所有者の商標である場合があります。

 ページのトップへ