ディレクトリサービス - OpenLDAP

あるひとつのキーを使用してそれに関連した情報を調べられるサービスを指し、データの読み込み・閲覧・検索に特化した仕組みを提供します。代表的な例をあげるとDNS（DomainNameService）、NIS（NetworkInformationService）もこの種のサービスに含まれます。
DNSではIPアドレスをひとつのキーにしてホスト名などを検索でき、 NISの場合はユーザIDをキーにしてパスワードや使用シェルの情報などを検索することができます。
ここ数年、このようなディレクトリサービスを汎用的に利用できる仕組みとしてLDAP（Lightweight Directory Access Protcol）が注目されてきました。
DNSやNISなどのように限られた情報だけを提供するだけではなく、様々なシステムに必要な情報を提供することが可能な仕組みです。

ディレクトリサービスに関しては、以前から「X.500」の国際基準化されたプロトコルが存在しましたが、多機能さと構造の複雑さからインターネット環境での利用が難しいとされていました。LDAPはこのような点を比較的シンプルな構造でTCP/IP上で簡単に動作するように設計したもので、Lightweight（軽い）というネーミングになっています。

LDAPは、標準化されたプロトコルなのでアーキテクチャやオペレーティングシステムに依存することなくディレクトリサービスの機能を利用することができます。
利用する例として多くあげられるのはユーザ情報の管理でしょう。複数台のサーバや複数のオペレーティングシステムが混在する環境では、ユーザの管理をどうするかが必ず検討課題になります。ユーザの情報がサーバごとに分散して管理されていると、ユーザ名やパスワードをサーバごとに使い分けするなど非常に面倒です。従来UNIXの環境では、このような事態を回避するために、NISなどが用いられてきましたが、セキュリティの面で問題があったり、拡張性や性能などに問題があり大規模なシステムで導入できないなどの理由から使用が見送られることが多くなりました。

このような場合に対して、LDAPを利用するとユーザの一元管理を始めとするシステムの拡張性・可用性面など次のような利点があります。

• 数千～数万のデータエントリが可能
• ユーザごとにアクセス制御情報を設定可能、SSLの暗号化にも対応
• レプリケーション（複製）機能を活用することで耐障害にも対応可能
• レファラル（紹介）機能を用いることで、データ管理を分散化可能（遠隔地などに）

LDAPは様々な情報を格納し読み出すことが可能なため、リレーショナルデータベースシステムと混同されがちです。しかし、実際のリレーショナルデータベースシステムとは以下の表に示す通り、機能が格段に異なるため、LDAPをリレーショナルデータベースの代わりに利用することはできません。
LDAPとリレーショナルデータベースの違いについて簡単にあげておきます。

オープンソース・ソフトウェアで、LDAPを実現するには「OpenLDAP」を利用するのが一般的です。「OpenLDAP」は RFC2251 に基づき、開発されているスタンダードなディレクトリサービスです。OpenLDAPには、LDAPサーバslapd、slurpd、 LDAPプロトコルのライブラリ群、LDAPのクライアントユーティリティなどが含まれています。これらの提供されているツールを利用することにより、ディレクトリサーバが構築できます。

メールシステムのユーザ管理にLDAPを使用した場合を想定し、次のような測定環境を用いてOpenLDAPの性能を測定しました。

上記のような環境で、表内の条件の元にユーザの検索処理を行いました。

前回の測定では、140req/sまでの測定を行いましたが、今回はその約3倍近い要求数を処理させる検証を行いました。前回の想定通り、高い負荷をかけた場合でもスループットの低下はみられませんでした。また平均処理時間もメールシステムでの利用を想定した場合でのユーザ検索には十分実用的な結果が得られました。

ここでは、ユーザの検索を中心に性能測定について取り上げましたが、実際のメールシステムで実行される処理を想定し、ユーザ追加・ユーザ削除が同時に処理が行われた場合の性能測定を行っています。検索140req/sを行っているときに、更新系の処理である、パスワードの変更・ユーザ追加・ユーザ削除処理を実行すると更新処理はトータルで、30万エントリ時 15.3ops/s、100万エントリ時 12.8ops/sのスループットが得られています。また検索にかかる平均処理時間が130ms弱となったものの、メールシステムの利用では実用的な範囲内であると考えられ、性能的にOpenLDAPでの大規模なシステム構築は問題ないと考察できます。

LDAPを利用した環境では、クライアント-サーバ間をLDAPのプロトコルで相互通信を行いサーバ側にあるディレクトリ情報をクライアントから操作(検索、追加、削除、変更)します。サーバ上のディレクトリ情報は、オブジェクトクラス（※1）によって分類されており、これをエントリと呼んでいます。いわばエントリは、国、組織、部署、名前、ユーザIDといったような属性（属性型）と実際の属性値を持った情報の集まりで、階層構造的に格納されています。この情報の格納先をDIT（Directory Information Tree）といいます。

※1：例えば国というオブジェクトの中には国名という属性が存在するように、個々の情報(属性)を似たような性質を持つものに分類し整理したものを指します。

LDAPでは、これらの情報を一意に識別するためにDN（Distinguish Name）を使います。

LDAPサーバを1台で運用すると、ネットワークの規模によってはサーバへの負荷がかかりすぎてパフォーマンスが低下したり、トラブルが発生しサービスが停止した場合には、クライアントから情報を利用出来ない事態が起ります。OpenLDAPでは、このような事態への対策としてサーバの複製（replica）を準備しておく事が可能となっています。この機能をレプリケーションといいます。
レプリケーションでは、データの更新を受けたサーバが、その他のサーバに対して更新されたデータの同期をとります。

サーバへと複製する際に、複製を許可するサーバの設定を行います。
設定には次の二つの方法があります。

• 特定の1台のみがデータの更新を受け付け、その他のサーバに対して複製を行う
• 全てのサーバがデータの更新を受け付け可能であり、相互に複製を行う

前者をシングルマスターレプリケーションといい、後者をマルチマスターレプリケーションといいます。（但し後者をサポートしていないDirectory Serverもあるので注意）

マルチマスターレプリケーションの方が、データ更新に関してのシステム上の信頼性は向上しますが、システム構成が複雑化しデータ管理が困難になります。

北海道支社やまたはその他の支社から、遠隔地で管理するLDAPサーバへアクセスをした場合のように、インターネットを経由して多数の検索が集中すると処理効率が劣化します。

このような場合は、北海道支社やその他の支社にもLDAPサーバを置くことにより解決できます。北海道支社を例にすると、データアクセスのほとんどが自支社に関するものの場合、北海道支社のLDAPサーバでは北海道支社に関するデータのみを管理し、その他のデータは東京支社のLDAPサーバに問い合わせる事が可能です。その際に利用するのが紹介（referral）という機能です。
東京本社のLDAPサーバは、北海道支社の管理するDITのサブツリー（図参照）を管理する情報を持ちます。また北海道支社にも支社のDITサブツリーを管理するLDAPサーバを設定し、本社のサーバからの委譲を受けられるようにします。