ビシッと決めるチューニング：もう一絞り編：OpenLDAPによるディレクトリサーバ運用（6）（1/3 ページ）

ユーザー情報や組織情報などを一元的に管理するディレクトリサーバは、企業システムの中で重要な役割を果たしています。オープンソースの「OpenLDAP」によるディレクトリサーバの構築方法を解説した前連載に続き、その運用方法を紹介していきます。（編集部）

[菊池研自，伊藤忠テクノソリューションズ株式会社]

　今回も引き続き、OpenLDAPサーバのパフォーマンスチューニングについて説明していきます。

　前回の第5回では、データベースサーバなどにも共通する、より一般的な観点からのパフォーマンスチューニングを説明してきました。今回はOpenLDAPサーバの内部へと踏み込み、OpenLDAPサーバの持つキャッシュ領域、スレッド処理の実装、同時接続数の管理といった、あと一絞りというところのチューニング技術を説明していきます。

OpenLDAPサーバのキャッシュ領域

　第5回では、バックエンドデータベースであるBerkeley DBの持つバッファキャッシュを活用した高速化について説明しました。それは、ディレクトリデータをディスク−メモリ間でやりとりするバックエンドデータベースにおいて、低速なディスクI/Oを避け、より多くのデータを高速なメモリ上に展開させるという方法でした。

　ここで説明するキャッシュ領域は、OpenLDAPサーバがバックエンドデータベースからデータを取得した後に利用するキャッシュ領域です。バックエンドデータベースが利用するバッファキャッシュではありません。2回目以降の同じリクエストに対して、バックエンドデータベースへのアクセスを省略することを目的に、OpenLDAPサーバそのものが、いくつかのキャッシュ領域にデータを保持しておく技術です。

　デフォルトのバックエンドデータベースであるBerkeley DBを利用している場合、OpenLDAPサーバのパフォーマンスチューニングに利用できるキャッシュ領域は、次の3つです。

1. エントリキャッシュ
2. IDリストキャッシュ
3. DNキャッシュ

　それでは、それぞれのキャッシュ領域の概要とチューニング方法に加え、それぞれのキャッシュ領域の利用状況の確認方法までを説明していきましょう。

エントリキャッシュのチューニング

　第5回では、OpenLDAPサーバは、Berkeley DBをKey/Valueタイプのデータベースとして扱うこと、また、「dn2id.dbd」ファイルからIDを、「id2entry.bdb」ファイルからエントリを取得することを説明しました。ここで説明するエントリキャッシュとは、OpenLDAPサーバが「id2entry.bdb」ファイルから取得したエントリを、OpenLDAPサーバ側のメモリにキャッシュする領域のことです。

　例えば、LDAPクライアントがインデックスを利用せずに、OpenLDAPサーバへ問い合わせを行ったとします。OpenLDAPサーバは、検索対象となる範囲のエントリをすべてバックエンドデータベースから取得し、それらのエントリデータのデコードを行い、フィルタ条件があればそれにマッチするデータを選択して、クライアントへ必要なデータのみを送付します。

　このとき、OpenLDAPサーバ側でエントリデータをデコードした状態でキャッシュしておけば、それ以降のクライアントからのリクエストに対して、

• バックエンドデータベースに対して行うアクセス
• 取得したデータを扱えるようデコードする処理

の2つを省略するメリットが生まれます。これを可能にするキャッシュ領域が、エントリキャッシュです。

図1　エントリキャッシュの役割

　このエントリキャッシュの設定は、OpenLDAPサーバ全体で行う設定ではありません。バックエンドデータベースがBerkeley DB（bdb）、またはHierarchical DB（hdb）の場合に、それぞれのバックエンドデータベースに対して個別に行う設定です。実際のエントリキャッシュの設定に用いるディレクティブは、cachesizeです。このcachesizeディレクティブに特に設定を行わなかった場合は、デフォルトの1000がエントリキャッシュの上限として指定されます。

　パフォーマンスチューニングの観点からは、エントリキャッシュの入れ替えが発生しないよう、バックエンドデータベースに格納するエントリと同数をエントリキャッシュへと格納できるようにサイズを確保するとよいでしょう。次の設定例は、あるバックエンドデータベースのエントリキャッシュに、10000エントリまでキャッシュ可能とすることを指定しています。

　また、以下の設定例では、指定したエントリキャッシュの利用状況の確認を行う目的で、monitorバックエンドデータベースの設定を有効にしています。

　それでは、OpenLDAPサーバを再起動させ、エントリキャッシュの設定を反映させてみましょう。

# cd /usr/local/openldap-2.4.23 # kill -INT `cat var/run/slapd.pid` # ./libexec/slapd -u ldap

エントリキャッシュの利用状況

　運用中にエントリキャッシュの利用状況を確認するには、monitorデータベースを利用します。エントリキャッシュにデータが追加されるのは、エントリデータをバックエンドデータベースから取得したタイミングです。ここでは、何らかのエントリを取得した後にmonitorデータベースを検索し、エントリキャッシュの領域にデータが蓄積されたことを確認しています。

# cd /usr/local/openldap-2.4.23 # ./bin/ldapsearch -x -b dc=my-domain,dc=com -s sub …[略]… # numEntries: 10000        ←10000エントリを取得 # ./bin/ldapsearch -x -D cn=Manager,dc=my-domain,dc=com -w secret \ > -b "cn=Database 1,cn=Databases,cn=Monitor" olmBDBEntryCache -LLL dn: cn=Database 1,cn=Databases,cn=Monitor olmBDBEntryCache: 10000    ←エントリキャッシュに、10000エントリが格納されている

第5回へ