第 5 章 サービスレベル契約の定義

サービスレベル契約とは、システムが特定の条件下でどのような動作をしなければならないかを決定する技術的仕様のことです。この章では、Directory Server Enterprise Edition に固有のサービス要件について説明します。また、配備がこれらの要件を満たすことを保証するために、計画フェーズの間に確認する必要があるチェックポイントを示します。

この章の内容は次のとおりです。

• 「システム品質の識別」

• 「パフォーマンス要件の定義」

• 「可用性要件の定義」

• 「拡張性要件の定義」

• 「セキュリティー要件の定義」

• 「潜在処理能力要件の定義」

• 「保守容易性要件の定義」

システム品質の識別

システム品質を識別するには、ディレクトリサービスが提供しなければならない最低限の要件を指定します。一般的に、サービス品質要件の基礎を形成するのは次のシステム品質です。

• パフォーマンス: ユーザーの負荷条件に対する、応答時間およびスループットの測定値。

• 可用性: システムのリソースやサービスにエンドユーザーがアクセスできる時間の指標であり、システムの稼働時間と表現されることもよくあります。

• 拡張性: 配備済みのシステムに容量やユーザーをあとから追加できる能力のこと。拡張性は一般的に、配備アーキテクチャーは変更せずに、システムにリソースを追加することを指します。

• セキュリティー: システムとそのユーザーの完全性を担保する各種要因の複合的な組み合わせです。セキュリティーを構成する要素には、ユーザーの認証と承認、データのセキュリティー、配備済みシステムへのセキュリティー保護されたアクセスなどがあります。

• 潜在処理能力: きわめて高いピーク負荷をリソースの追加なしで処理できるシステムの能力。潜在処理能力は可用性、パフォーマンス、および拡張性に関係する要因です。

• 保守容易性: 配備済みシステムを容易に保守できること。ここでいう保守には、システムの監視、発生する問題の修正、ハードウェアおよびソフトウェアコンポーネントのアップグレードなどが含まれます。

パフォーマンス要件の定義

パフォーマンス要件は、ディレクトリ使用状況の一般的なモデルに基づいて定義することをお勧めします。すべてのディレクトリ配備で、Directory Server は 1 つ以上のクライアントアプリケーションをサポートします。これらのアプリケーションの要件を評価する必要があります。ディレクトリに格納される情報の分量とアクセス頻度を見積もるには、これらのアプリケーションを識別し、アプリケーションが Directory Server をどのように利用するかを特定する必要があります。

クライアントアプリケーションの識別

ディレクトリにアクセスするアプリケーションと、データに対するこれらのアプリケーションのニーズは、パフォーマンス要件に大きな影響を及ぼします。クライアントアプリケーションを識別するときは、次のことを考慮します。

• Directory Server にアクセスするクライアントアプリケーションのタイプ

• これらの各アプリケーションにアクセスするユーザー数

• これらのアプリケーションが実行する操作のタイプ

• これらの操作の使用状況パターン

ディレクトリを使用する可能性がある一般的なアプリケーションには、次のものがあります。

• White pages などのブラウザアプリケーション: この種のアプリケーションは一般に、電子メールアドレス、電話番号、従業員名などの情報にアクセスします。

• メッセージングアプリケーション、特に電子メールサーバー: すべての電子メールサーバーは、電子メールアドレス、ユーザー名、およびルーティング情報を必要とします。サーバーの中には、ユーザーのメールボックスが格納されているディスク上の格納場所、休暇通知情報、およびプロトコル情報など、さらに高度な情報を必要とするものもあります。

• ディレクトリ対応の人事管理アプリケーション: これらのアプリケーションは、政府指定の ID 番号、自宅住所、自宅電話番号、給与詳細などのより個人的な情報を必要とします。

• セキュリティー、Web ポータル、個人化用アプリケーション: この種のアプリケーションは、プロファイル情報にアクセスします。

各アプリケーションが使用する情報を特定すると、いくつかのタイプのデータが複数のアプリケーションによって使用されていることが判明する場合があります。計画段階でこのような課題に取り組むことで、ディレクトリ内のデータが重複する問題を避けることができます。

ディレクトリエントリの数とサイズの決定

ディレクトリに格納されるエントリの数とサイズは、第 4 章「データ特性の定義」で説明したようなデータ要件に大きく左右されます。

エントリの数とサイズを計算するときは、次のことを考慮します。

• 配備で一括インポート初期化を繰り返し実行する必要があるか。

• 必要な場合はインポートの実行頻度

• 一度にインポートされるエントリの数

• インポートされるエントリのタイプ

• サーバーが稼働したままの状態で、オンラインで初期化を実行する必要があるか

読み取り数の特定

読み取りトラフィックを見積もるときは、次のことを考慮します。

• 1 秒あたりの検索件数がどれくらいになるか

• どのようなタイプが検索されるか

  例: 一意 ID 検索、ワイルドカード検索、完全一致検索

• ピーク時の検索率はどの程度になるか

• 平均の検索率はどの程度になるか

• インデックスを使用しない検索がどの程度行われるか

  インデックスを使用しない検索とは、インデックスファイルではなくデータベースを直接検索する検索のことです。インデックスを使用しない検索が発生するのは、検索に使用されるインデックスファイルの内部で「すべての ID のしきい値」に達した場合、インデックスファイルが存在しない場合、または検索に必要な形式でインデックスファイルが構成されていない場合です。

  インデックスを使用しない検索は通常、インデックス検索よりも時間がかかります。

• 検索が特定のデータセンターまたは地理的な領域に集中しているか

  あるデータセンターが受信する検索トラフィックがほかのデータセンターに比べて多い場合、サーバーをレプリケートしてこのデータセンターに追加配置し、負荷分散を図ることを検討する余地があります。

• 検索が一日の特定の時間帯に集中しているか

• ファイアウォール内部での検索がどれくらい行われるか

• ファイアウォールの外からの検索がどれくらい行われるか

読み取りパフォーマンスがもっとも重視されるビジネス環境での配備については、第 10 章「拡張配備の設計」を参照してください。ここでは、読み取りトラフィックの増加に対応できる拡張性を確保しながらディレクトリサービスを配備するための提案事項を紹介しています。

書き込み数の特定

書き込みトラフィックを見積もるときは、次のことを考慮します。

• 1 秒あたりの更新件数がどれくらいになるか

• どのようなタイプが更新されるか

• ピーク時の更新率はどの程度になるか

• 平均の更新率はどの程度になるか

• 更新が特定のデータセンターまたは地理的な領域に集中しているか

  あるデータセンターが受信する更新トラフィックがほかのデータセンターと比べて多い場合、書き込み可能なサーバーをこのデータセンターに追加配置し、更新負荷を分散させることを検討する余地があります。

• 更新が一日の特定の時間帯に集中しているか

書き込みパフォーマンスがもっとも重視されるビジネス環境での配備については、第 10 章「拡張配備の設計」を参照してください。ここでは、書き込みトラフィックの増加に対応できる拡張性を確保しながらディレクトリサービスを配備するための提案事項を紹介しています。

許容可能な応答時間の見積もり

それぞれのクライアントアプリケーションについて、許容可能な最大の応答時間を特定します。許容可能な応答時間は、地理的条件や操作の種類によって異なる可能性があります。

許容可能なレプリケーション待ち時間の見積もり

マスターレプリカとコンシューマレプリカの間で必要な同期性のレベルを見積もります。Directory Server のレプリケーションモデルは疎整合です。これは、マスター上で更新が受理される際に、トポロジ内のほかのレプリカとの通信が不要なことを意味します。そのため、各レプリカの内容が一時的に異なっている可能性があります。これらのレプリカは時間の経過とともに収束し、最終的には各レプリカがデータの同じコピーを保持するようになります。パフォーマンス計画の一環として、レプリカが収束しなければならない最長の許容可能時間を決定します。

Directory Server 6.x には、新しい「優先順位付きレプリケーション」機能が含まれています。この機能では、特定の属性の変更をできるだけ早くレプリケートしなければならないことを指定できます。優先順位付きレプリケーションは、許容可能なレプリケーション待ち時間についての決定に影響を及ぼす場合があります。詳細については、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の「Prioritized Replication」を参照してください。

可用性要件の定義

可用性は、ディレクトリサービスに関して合意された最低限の「稼働時間」およびパフォーマンスレベルを指します。ここでは、ディレクトリサービスがこの最小レベルのサービスを提供できなくなるあらゆる要因を障害と定義します。

可用性要件を評価するときは、次のことを考慮します。

• ディレクトリサービスは一日の特定の時間帯にのみアクセスされるか

• 読み取り操作と書き込み操作のそれぞれに対して異なる可用性要件が存在するか

• 地理的に離れた複数のサイトにまたがってサービスが提供されるか。その場合、アクセス時間に関する要件がこれらのサイト間で異なっているか

• システムの保守のためにシャットダウンできるか

  できる場合、許容可能な最長の停止時間はどのくらいか

• 移行中にシステムをシャットダウンできるか

• 停止時間が組織にもたらすコスト (損失) はどの程度か

高可用性ディレクトリサービスの配備に関する提案事項については、第 12 章「高可用性配備の設計」を参照してください。

拡張性要件の定義

ディレクトリが拡大する過程で、サポートしなければならないサービスレベルが変化する可能性があります。システムの配備後にサービスのレベルを引き上げることは難しい場合があります。したがって、初期設計では将来の要件も考慮に入れる必要があります。

拡張性要件を定義するときは、次のことを考慮します。

• エントリ分量の増加が予測されるか

• 今後数年間で新規ユーザーの数はどれくらいになるか

• 今後数年間で、データ、ユーザー、およびクライアントアプリケーションの増加率はどの程度になるか

• 新しいビジネスプロセスの導入予定の有無

あまり早い時期に配備の拡張が必要にならないように、必要な CPU 数については多めに見積もっておきます。拡張の時期として想定しているマイルストーンと、今後の負荷の増加分を比較検討して、マイルストーンに到達するまでは十分な能力を維持できるようにします。

セキュリティー要件の定義

セキュリティー要件については、独立した解説が必要です。第 7 章「セキュリティー要件の特定」で詳しく説明します。

潜在処理能力要件の定義

潜在処理能力要件を定義するときは、ディレクトリサービスのピーク時の負荷条件を見積もります。次の点を考慮してください。

• すべてのクライアントアプリケーションが動作中と仮定した場合に達する可能性がある、Directory Server への最大同時接続数

• 1 台以上のサーバーが停止したと仮定した場合に、配備内の残りのサーバーにかかると予測される負荷

保守容易性要件の定義

保守容易性要件については、第 8 章「管理と監視の要件の特定」で詳しく説明します。