サービスクラスによる属性の管理

サービスクラス (CoS) メカニズムを使用すると、エントリ間で属性を共有できます。ロールメカニズムと同様に、エントリが検出されると、CoS がそのエントリに対して仮想属性を生成します。CoS はメンバーを定義しませんが、一貫性の保持と容量の節約のために、関連するエントリがデータを共有できるようにします。CoS の値は、それらの値が要求されたときに動的に計算されます。CoS 機能や、CoS のさまざまな種類については、『Sun Java System Directory Server Enterprise Edition 6.3 Reference 』で詳細に説明されています。

以降の節では、パフォーマンスの低下を回避しながら、CoS 機能を意図したとおりに使用する方法について詳しく説明します。

• 「多数のエントリが同じ値を共有する場合の CoS の使用」

• 「エントリが自然な関係を持っている場合の CoS の使用」

• 「過剰な CoS 定義の回避」

CoS の生成は、常にパフォーマンスに影響します。実際に必要とするより多くの属性を検索するクライアントアプリケーションによって、この問題がさらに悪化する可能性があります。

クライアントアプリケーションの記述方法を指示できる場合は、実際に必要な属性値のみを検索するようにクライアントアプリケーションを記述することで、パフォーマンスの大幅な向上が期待できることを開発者に伝えてください。

多数のエントリが同じ値を共有する場合の CoS の使用

CoS は、サブツリー内の多数のエントリに同じ属性値を表示する必要がある場合に、比較的低いコストで大きな利点を提供します。

たとえば、ou=People の下のすべてのユーザーエントリに companyName 属性が含まれている、MyCompany, Inc. のディレクトリを考えてみます。請負業者のエントリには companyName 属性に直接値がセットされていますが、すべての正社員の companyName には、CoS で生成された値 MyCompany, Inc. がセットされています。次の図は、この例でポインタ CoS を使用した場合を示しています。CoS によって、すべての正社員の companyName 値が生成されるが、請負業者の従業員用に直接設定されている実際の companyName 値は置き換えられないことに注意してください。会社名は、companyName が許可された属性になっているエントリに対してのみ生成されます。

図 4–3 ポインタ CoS を使用した CompanyName の生成

多数のエントリが同じ値を共有する場合は、ポインタ CoS が特にうまく機能します。正社員に対する companyName の管理が容易になることで、属性値を生成するための追加の処理コストが相殺されます。深いディレクトリ情報ツリー (DIT) は、一般的な特性を共有するエントリをまとめる傾向があります。深い DIT でポインタ CoS を使用すると、ツリー内の適切な分岐に CoS 定義を配置することによって、一般的な属性値を生成できます。

エントリが自然な関係を持っている場合の CoS の使用

CoS はまた、ディレクトリデータが自然な関係を持っている場合も、データ管理の大きな利点を提供します。

すべての従業員にマネージャーがいる企業ディレクトリを考えてみます。すべての従業員がメールストップと Fax 番号を、もっとも近い管理アシスタントと共有しています。図 4–4 は、間接 CoS を使用して、マネージャーのエントリから部門番号を取得する様子を示しています。図 4–5 では、メールストップと Fax 番号が管理アシスタントのエントリから取得されています。

図 4–4 間接 CoS を使用した DepartmentNumber の生成

この実装では、マネージャーのエントリに departmentNumber の実際の値が含まれ、生成されているどの値よりもこの実際の値が優先されます。Directory Server は、CoS で生成された属性値からは属性値を生成しません。そのため、図 4–4 の例では、部門番号の属性値をマネージャーのエントリ上でのみ管理する必要があります。同様に、図 4–5 に示されている例では、メールストップと Fax 番号の属性を管理アシスタントのエントリ上でのみ管理する必要があります。

図 4–5 間接 CoS を使用したメールストップと Fax 番号の生成

単一の CoS 定義エントリを使用して、このような関係をディレクトリ内のさまざまなエントリに利用できます。

別の自然な関係に、サービスレベルがあります。顧客にスタンダード、シルバー、ゴールド、およびプラチナのパッケージを提供しているインターネットサービスプロバイダを考えてみます。顧客のディスク割り当て、メールボックスの数、前払いのサポートレベルに対する権限などは、購入したサービスレベルによって異なります。次の図は、クラシック CoS スキーマによってこの機能が可能になるようすを示しています。

図 4–6 クラシック CoS を使用したサービスレベルデータの生成

1 つの CoS 定義が複数の CoS テンプレートエントリに関連付けられる場合があります。

過剰な CoS 定義の回避

Directory Server は、1 つのクラシック CoS 定義エントリが複数の CoS テンプレートエントリに関連付けられている場合は CoS を最適化します。Directory Server は、多数の CoS 定義が適用される可能性がある場合は CoS を最適化しません。代わりに、Directory Server は各 CoS 定義をチェックして、この定義が適用されるかどうかを判定します。この動作によって、数千の CoS 定義が存在する場合はパフォーマンスの問題が発生します。

この状況は、図 4–6 で示した例に変更がある場合に発生する可能性があります。顧客に、各顧客のサービスレベルの委任管理を提供しているインターネットサービスプロバイダを考えてみます。各顧客から、スタンダード、シルバー、ゴールド、およびプラチナのサービスレベルの定義エントリが提供されます。顧客数が 1000 に増えると、1000 個のクラシック CoS 定義が作成されることになります。どの定義が適用されるを判定するために 1000 個の CoS 定義のリストがチェックされるため、Directory Server のパフォーマンスが影響を受ける可能性があります。この種の状況で CoS を使用する必要がある場合は、間接 CoS を検討してください。間接 CoS では、顧客のエントリによって、その顧客のサービスクラス割り当てを定義するエントリが特定されます。

1 つまたは 2 つのターゲットエントリごとに別の CoS スキーマを選択することの限界に近づき始めたら、実際の値を更新することをお勧めします。CoS で生成されていない実際の値が読み取られるため、より高いパフォーマンスが実現します。