[ILM/MIIS] Delta Import より Full Import のほうが早いときがある

みなさん御機嫌よう。ういこです。
今日 2009/10/08 はリンゴ台風以来の凄い台風が列島縦断しています。子供の学校はサックリ休みになっております。学童クラブからは、朝 8:30 から預かるが、空気を読んで自粛してほしいというメールを頂きましたが、断腸の思いでお弁当を持たせて行かせてしまいました…。(旦那がバイクで連れて行きました。)お弁当作るのって本当に大変です。奥様に作っていただいている世の旦那様、「いつもありがとう」の言葉と、せめて弁当箱くらいは洗ってあげてくださいね。でないと、微妙に不満や怨念が蓄積されていくかもしれませんよ。洗ってくれなくても言葉くらいはマジでほしいです。語らなくても通じるなんてうそです!!絶対に。ちなみに少なくとも私は蓄積されます。

と、まあ微妙に怨念が台風のように渦巻くのはさておき、今日のお題は、最近本業の ILM を忘れたような感じになってるので、ILM のことについて。

【今日のお題】
Active Directory / ADAM の MA を使ってます。Full Import は遅いので、Delta Import にしたいと思ってますがどうでしょう。

【回答】
結論からいうと、必ずしも Full Import より Delta Import のほうが早いとは限りません
場合によってはむしろ Full Import のほうが早い場合があります。

では、それはなぜか。まず、Active Directory / ADAM のマネージメントエージェント (MA) を例にとり、各 Import 処理はどんなことをしているか見てみましょう。

1. Import の処理ってどんなことをしているの?
・Full Import
ADAM および Active Directory の MA の Full Import では、LDAP API を使用し、接続先ディレクトリに存在するすべての対象オブジェクトに対してクエリーを実行します。たとえば、MA の "Select Object Types" プロパティ シートで指定されているオブジェクト クラスすべてを対象としてクエリーを実行する、というようなことが可能です。
Full Import で収集された情報には、特定オブジェクトに格納されているすべての属性値などがあります。
ILM も、最終更新時に関する情報を格納しているため、この情報は Delta Import でも使用することができます。

・Delta Import Delta Import では、[Configure Partitions] ダイアログの [Containers] ボタンおよび [Deleted Objects] コンテナで設定されたコンテナのオブジェクトを対象としてクエリーを実行します。ADAM および Active Directory のマネージメント エージェントの Delta Import では、LDAP API と DirSync LDAP コントロールを併用します。DirSync LDAP コントロールを使用することにより、直近に成功した Full Import 以後、変更のあったディレクトリに対してのみ、クエリーを実行することが可能です。このような処理が可能なのは、Import した全オブジェクトのオブジェクト ステート情報を格納しているためです。

…これを見ていただいても、Delta Import は、クエリーを実行するのが、最後の Import 以後に変更の生じた箇所のみであるため、Full Import と比較し、Delta Import の実行時間がかなり短縮されるという以外に、何があるのだろう?といぶかしまれるかもしれません。

しかしながら、この、「最後の Import 以後に変更の生じた箇所」をチェックする、というところが実は誤解しやすいポイントなのです。ディレクトリのすべてオブジェクトあるいは大半が更新されるなど、大量の更新があった場合は Full Import の方が効率的な場合もあります。
実際、Delta Import でも Full Import の実行時間と変わらない場合や、逆に非常に遅くなることまであるのです。

2. Delta Import のコスト Delta Import についてもう少し詳しく見てみましょう。
Active Directory は、 オブジェクトの属性に Update Sequence Number(USN) を持っています。
Delta Import では、コネクタ スペース (CS) 内のオブジェクトと Import 動作時に AD にアクセスし、USN 値を比較して差分を検出し、差分更新の生じているオブジェクトの Import を実施しています。
データ数が少ない状況ですと、Delta Operation は Full Operation と比較するとこれらの差分確認処理を含めても処理件数、プログラム コードの処理数的にも優位ですが、これが数万件単位になるとこの差分処理がオーバーヘッドとなります。
さらに、アクセスしにいくのは AD だけではありません。CD オブジェクトを参照し、比較する際に SQL Server にクエリを投げるのですが、これも処理コストとしては決して少なくない処理です。結果的に Full Operation よりも処理コストが高い処理になる、というからくりなのです。

まとめますと処理コストとなる要素として大きなものは下記となります。

・AD への USN の参照
・SQL Server に対する CS オブジェクトとの比較クエリ

件数が少ない場合、Delta Import のほうが早いというのは、差分が少なければディレクトリアクセスは抑制され、一連の処理で一番件数が増えて影響を受ける SQL クエリの処理の件数が少ないからです。

こうした事情により、更新オブジェクト数がディレクトリのほぼ全てに及ぶような場合、Delta Operetion の生じない Full Import の方が効率が良いことになります。つまり、若干の更新のみが検出されるような動作や運用初期においては Delta Import を通常操作としつつ、定期的に Full Import を施行する、というのが効率がよい運用ということになります。
なぜならば、定期的に Full Importをかけないと、差分が増加を続けるので、結果的に USN の処理も比例的に増加してしまうためです。

以下が公開されている情報でわりと詳しいものかと思います。

Understanding run profiles in MIIS 2003
https://support.microsoft.com/kb/827118/en-us

※ 補足
・なお、AD 側でデータを直接登録、変更などを行った際は Full Import を定期的に行うほうが Delta Import の効率化を図れますが、たとえば AD 側で直接データ変更などを行わず、別のデータソースからのデータを Export のみで更新していくような運用であれば、定期的な Full Import は必ずしも有効ではありません。

・初回、AD 上の全オブジェクトが Export 操作により生成される前提条件であれば、Import 対象のオブジェクトはこの Export 操作により更新されていると判断されます。よって全オブジェクトが要更新対象(差分)とみなされますので、その後 Delta Import を行っても全てのオブジェクト属性が収集されます。

・Full Sync を以前行った日が半年以上前など、Active Directory における既定の TombStone 期間よりも前である場合、ドメインのオブジェクトの移動や削除に関する正しい情報が、データソースから得られないため、CS オブジェクトが無効となる恐れがあります。この場合、一旦 CS オブジェクトを削除し、Full Import と Delta Sync をやり直すことをお勧めします。

3. Delta Import と Full Import の所要時間逆転の閾値はシステムに依存する
残念ながら Delta Import と Full Import の所要時間が逆転する閾値に相当するかどうかの判断は、お客様の動作環境、ネットワーク構成および実際の動作状況から判断する必要があります。
また、ディレクトリ アクセスと SQL 負荷のどちらが、MIIServer サービスに影響を与えているかは、構成に依存するため、帯域、CPU 負荷、ハードディスクアクセスの状態など複数の要素によって状況が左右されるということがあり、ILM の製品的に一意の閾値は存在しません。
実際の運用の実績ベースの RunHistory からの更新件数、処理時間などから、判断する必要があります。

ではみなさんごきげんよう。

ういこう@うずまきといえば伊藤潤二先生だと思う