変更追跡手法の概要

変更追跡メカニズムには、次のようないくつかの方法があります。

• 変更を追跡するためのスコープ: アプリケーションは、1 つのオブジェクトの 1 つの属性、do 内のすべてのオブジェクトに対する変更メインなどを追跡できます。 メカニズムがアプリケーションの要件と一致する場合、アプリケーションは最小限の無関係なデータを受け取り、これによりパフォーマンスが向上します。

• タイムライン: アプリケーションは、発生するたびにすべての変更を通知するか、分または時間の間に変更の正味の影響を通知することができます。

  複数の変更が 1 つに折りたたまれる可能性があるため、より短いタイムリーなデータの処理がより効率的になる場合があります。 たとえば、属性が 1 時間間隔内で 3 回変更された場合、1 時間にわたって累積された変更を通知したアプリケーションには、3 つではなく 1 つの属性変更だけが通知されます。

  タイムラインについて考えるときは、レプリケーションの待機時間の影響を考慮してください。 1 つの do メイン コントローラーで発生した更新プログラムは、すぐに別の doメイン コントローラーにレプリケートされません。 変更追跡タイムラインを必要とすると、予想されるレプリケーション待機時間よりもはるかに優れていますが、多くの場合、アプリケーションにとって実際のメリットはありません。

• ポーリングと通知: ポーリングでは、アプリケーションは定期的に doメイン コントローラーに変更追跡データを受信するように要求します。 通知を使用するとメインコントローラーは変更が発生した場合にのみアプリケーションに変更を送信します。

  ポーリングのオーバーヘッドは明らかです。重要なものが何も発生していない場合、アプリケーションは変更追跡データを要求する可能性があります。 通知のオーバーヘッドは、より微妙です。 サーバーはメイン通知要求に関するデータを含める必要があり、通知を送信するかどうかを決定するには、このデータを参照する必要があります。 これにより、通常の更新要求にオーバーヘッドが発生する可能性があります。

• アプリケーションの知識を表現する: 永続的と一時的: すべての変更追跡メカニズムには、"変更" の概念が明確に定義されるように、追跡対象のデータを保持するサーバーがアプリケーションの知識の状態を理解するためのメソッドを含める必要があります。 たとえば、アプリケーションの知識の状態は、"時刻 t より前に DC d で発生したすべての変更で更新されました" と表現される場合があります。アプリケーションの知識の状態を表すこの方法に基づくメカニズムは、指定された時間より後に発生した変更をアプリケーションが取得するための効率的な方法を提供します。

  アプリケーションの知識の式を永続化できる場合、つまり、ファイルやデータベースのように回復可能に格納される場合、アプリケーションの再起動は、リソースを消費できない場合よりも少なくなります。 上の例では、DC d と時刻 t を記録することで、アプリケーションの知識の式を保持できます。 一部の変更通知メカニズムでは、このデータを永続化できません。 サーバーとアプリケーションは、アプリケーションの起動時に他のメカニズムと同期する必要があります。 これは、複数のオブジェクトが関係し、複雑なプログラミングを伴う可能性がある場合に、リソースを集中的に消費します。

Active Directory ドメイン サービスの変更を追跡するには、次の手法を使用します。

• 変更通知コントロールを使用して、指定したフィルターに一致する変更の永続的な非同期検索を開始します。 詳細については、「Active Directory ドメイン サービスの変更通知」を参照してください。
• ディレクトリ同期 (DirSync) 検索を使用して、以前の DirSync 検索以降に発生した変更を取得します。 詳細については、「DirSync コントロールを使用した変更のポーリング」を参照してください。
• 前の検索以降に変更されたオブジェクトを検索するには、USNChanged 属性を使用します。 詳細については、「USNChanged を使用した変更のポーリング」を参照してください。

変更通知制御は、まれな変更の通知を合理的に迅速に行う必要があるアプリケーションまたはサービス向けに設計されています。 たとえば、Active Directory サーバーに構成データを格納し、変更が発生したときにすぐに通知を受け取る必要があるサービスまたはプログラムがあります。 通知コントロールには制限があることに注意してください。

• 通知のプロンプトは、レプリケーションの待機時間と変更が発生した場所によって異なります。 監視しているレプリカに変更がレプリケートされると、すぐに通知を受け取る場合がありますが、変更は他のレプリカでかなり前に発生した可能性があります。
• コントロールは、1 つのオブジェクトまたはコンテナーの直下の子を監視するように制限されます。 複数のコンテナーまたは関連のないオブジェクトを監視する必要があるアプリケーションは、最大 5 つの通知要求を登録できます。
• 頻繁に発生する変更をリッスンしているクライアントが多すぎると、サーバーのパフォーマンスに影響します。 一般に、アプリケーションでは、サーバー上のパフォーマンス上の理由から、このコントロールの使用を制限する必要があります。 変更についてすぐに知る必要がない場合は、変更通知を使用するのではなく、定期的に変更をポーリングすることをお勧めします。

DirSync および USNChanged 検索手法は、Active Directory サーバー上のデータと他のストレージ内の対応するデータとの間の整合性をメインするアプリケーション向けに設計されています。 これらの手法は、定期的に変更をポーリングするアプリケーションで使用されます。 DirSync 手法は、ADSI または LDAP API を介して使用できる LDAP サーバー コントロールに基づいています。 DirSync コントロールの欠点は、doメイン 管理者など、高い特権を持つアカウントでのみ使用できることです。 DirSync コントロールの制限事項の一覧を次に示します。

• DirSync コントロールは、doメイン 管理者などの高い特権を持つアカウントでのみ使用できます。
• DirSync コントロールは、名前付けコンテキスト全体のみを監視できます。 DirSync 検索のスコープを制限して、名前付けコンテキスト内の特定のサブツリー、コンテナー、またはオブジェクトのみを監視することはできません。

USNChanged 手法にはこれらの制限はありませんが、DirSync よりも使用がやや複雑です。