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

パフォーマンス要件は、ディレクトリ使用状況の一般的なモデルに基づいて定義することをお勧めします。すべてのディレクトリ配備で、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」を参照してください。