389 Directory ServerとOpenLDAPの違い｜アーキテクチャから移行判断まで

「Linuxでディレクトリサービスを立てるなら、389 Directory ServerとOpenLDAPのどちらを選ぶべきか」。社内認証基盤の刷新や、RHEL系からの移行を検討する場面で、いまだに繰り返される問いです。私は20年以上Linuxサーバーの構築と運用に関わってきましたが、この二択は「どちらが優れているか」ではなく「自分の現場の前提に、どちらの設計思想が噛み合うか」で答えが変わります。

どちらもLDAPプロトコルを話すディレクトリサーバーで、表面的にはユーザーやグループの情報を木構造で持つという点で似ています。しかし中身を開けると、設定をどこに持つか、データベースに何を使うか、レプリケーションをどう設計するかといった根っこの部分がかなり違います。この記事では、389 Directory Server（Red Hat系・dirsrv）とOpenLDAP（slapd）のアーキテクチャ・運用・管理性の違いを公式ドキュメントで裏取りしながら整理し、現役の管理者目線で「どちらを選ぶか」「移行をどう判断するか」を掘り下げます。

まず全体像：389 Directory ServerとOpenLDAPの立ち位置

389 Directory Serverは、Red Hatが商用提供するRed Hat Directory Server（RHDS）のアップストリーム（上流）にあたるオープンソースのLDAPサーバーです。メインプロセスはns-slapdで、Fedora・RHEL系のパッケージとして整備されています。FreeIPA（Red Hatの統合ID管理基盤）のディレクトリ部分も、この389 Directory Serverが担っています。つまり「Red Hatのエコシステムに組み込むこと」を前提に磨かれてきたサーバーです。

一方のOpenLDAPは、特定のディストリビューションに紐づかない、文字どおりの汎用LDAP実装です。デーモンはslapd。Debian系・RHEL系を問わず広く採用され、軽量で素直、必要な部品を自分で組み上げる自由度の高さが持ち味です。長くLDAPの「標準的な選択肢」として使われてきました。

同じLDAPサーバーでありながら、片方は「統合された製品の一部」、もう片方は「組み立て式の汎用部品」という出自の違いがあります。この性格の差が、以降で見ていく設定方式やデータベース、運用ツールの違いに一本の線でつながっていきます。まずはここを押さえておくと、後の比較が腹落ちしやすくなります。

アーキテクチャの違い：バックエンドDBとプラグイン設計

両者の最も技術的な違いは、データを実際に格納するバックエンドデータベースにあります。ここを理解しておくと、性能特性やバックアップ運用の違いまで一気に見通せます。

389 Directory Serverは、伝統的にBerkeleyDB（bdb）をバックエンドに使ってきました。サーバー本体は「インデックス・クエリ最適化・エントリキャッシュ・レコード単位のロック」を担い、その下でBerkeleyDBがB-treeやトランザクションログといった低レイヤーを処理する、という二段構えの設計です。ただしBerkeleyDBはFedora 33以降で非推奨（deprecated）となり、上流ライブラリ自体がサポートされない状態に入りました。そこで389側はLMDB（Lightning Memory-Mapped Database、内部名mdb）への移行を進めています。公式FAQによれば、LMDBとBerkeleyDBの両対応はバージョン2.1.0で導入され、3.0.0からは新規インスタンスが既定でLMDBで作られるようになりました。バックエンドの実装はcn=config配下のnsslapd-backend-implement属性でbdbかmdbかを指定します。

OpenLDAPは、すでにこの移行を済ませています。公式管理者ガイド（2.5系）は、LMDBを使うback-mdbを「通常のslapdデータベースにおける推奨プライマリバックエンド」と明記しており、これが旧来のBerkeleyDB系バックエンドを置き換えた、と説明しています。LMDBの特徴は、インデックスに対応しつつキャッシュを使わず、チューニングなしで最大の検索性能を引き出せること、完全な階層型でサブツリーのリネームを定数時間で行えることです。ひとつ実務上の注意点として、LMDBは最大データベースサイズを手動で設定する必要があります。ここを小さく見積もると、エントリ増加時に書き込みが詰まるので、設計段階で余裕を持たせておくのが鉄則です。

面白いのは、両者が結局はLMDBという同じ土台へ向かって収束している点です。OpenLDAPは早くからLMDBを標準に据え、389 Directory Serverは3.0.0でようやく既定を切り替えた。データベース選定という根っこでは、もはや大きな思想差はなくなりつつあります。逆に言えば、いまから新規に構築するなら「どちらもLMDBで動く」前提で、その上の運用層で比較するのが現実的です。

設定方式の違い：cn=config・dse.ldif・slapd.conf

運用の手触りを最も左右するのが、設定をどこに、どう持つかです。両者はここで歴史的な経緯を引きずっており、混乱しやすいポイントでもあります。

389 Directory Serverは、インスタンスごとに/etc/dirsrv/slapd-INSTANCE/ディレクトリを持ち、その中のdse.ldifにLDIF形式で設定を格納します。設定情報はcn=configサブツリーとして表現され、稼働中の変更はdsconfコマンドで行います。dsconfは内部的にはLDAPクライアントとしてldapmodify相当の操作を投げる仕組みです。インスタンスの作成はdscreate、オフラインのバックアップやエクスポートはdsctl、ID管理はdsidmと、用途別に専用ツールが整っているのが特徴です。systemd統合も明確で、各インスタンスはdirsrv@INSTANCE.serviceとして登録され、全体はdirsrv.targetでまとめて制御できます。「製品として組み上がっている」感覚が、ツール体系に表れています。

OpenLDAPは過渡期の名残が残っています。古くは単一のslapd.confファイルに設定を書く方式が主流でしたが、公式ドキュメントはこのslapd.confを非推奨（deprecated）と明言し、将来のリリースでサポートを打ち切ると予告しています。現行の標準はcn=config動的設定バックエンド（slapd-config）で、これはOpenLDAP 2.3以降に導入されました。設定はslapd.dディレクトリ配下のLDIFファイル群として保存されますが、公式は「これらのLDIFファイルを直接編集してはならない」と強く釘を刺しています。変更はldapadd・ldapmodifyなどのLDAP操作で行い、多くの設定はサーバーを再起動せずに反映できます。

ここで実務上の落とし穴になりやすいのが、ネット上に残る古い記事です。OpenLDAPの解説の多くがいまだにslapd.confを前提に書かれており、その通りに構築すると非推奨の方式に足を踏み入れることになります。新規に組むならcn=configで始めるのが正解で、この一点を押さえているかどうかで、後々の運用のしやすさが大きく変わります。両者を比べると、設定方式は389が一貫して整理されている一方、OpenLDAPは「新旧どちらの作法で書かれた情報か」を見極めるリテラシーが管理者側に求められる、という違いがあります。

レプリケーションと運用管理の違い

冗長化や複数拠点展開を考えるなら、レプリケーションの設計思想は外せません。ここにも両者の性格が色濃く出ます。

389 Directory Serverは、マルチサプライヤ（multi-supplier、かつてはマルチマスターと呼ばれていた方式）レプリケーションを備えます。サプライヤやハブ上では、レプリケーション用プラグインが「他サーバーへ再生すべき変更」を記録するchangelogデータベースを保持します。すべての変更はCSN（Change Sequence Number）でインデックス付けされて記録され、既定では変更が発生し次第すぐにレプリケーションが走ります。設定や運用がツール（dsconf）側に集約されているため、レプリカ構成も「製品のお作法」に沿って組んでいく形になります。

OpenLDAPは、syncrepl、そしてその差分版であるdelta-syncreplをレプリケーションの軸に据えています。マルチマスター（N-Way）構成では各ノードにserverIDという整数を割り当て、それぞれのURIと対応づけます。注意したいのは制限事項で、delta-syncreplとOLC（オンライン設定）を組み合わせたN-Wayマルチマスターは、OpenLDAP 2.4.35の時点でサポート外とされていました。マルチマスターを前提に設計する場合は、自分が使うバージョンでどの組み合わせが正式サポートなのかを、公式ドキュメントで必ず確認しておく必要があります。

運用管理の手触りで言えば、389は「専用ツールとsystemdユニットで囲い込まれた、製品としての運用体験」、OpenLDAPは「LDAP操作という素のインターフェースで、自分で組み上げる運用体験」と整理できます。前者は迷いが少なく定石に乗りやすい代わりに、Red Hatのエコシステムへの依存が前提になります。後者は自由度が高い代わりに、設定の正しさや構成の一貫性を管理者自身が担保しなければなりません。どちらが楽かは、チームの人数とスキル、そして「製品の流儀に乗るか、自分で制御を握るか」という好みに左右されます。

選定と移行の判断軸

では、実際にどちらを選ぶか。私が現場で整理に使う判断軸を、表にまとめておきます。

観点	389 Directory Server（dirsrv / ns-slapd）	OpenLDAP（slapd）
出自・エコシステム	Red Hat系。RHDSの上流、FreeIPAの基盤	ディストリ非依存の汎用実装
バックエンドDB	bdb→mdb（3.0.0で既定がLMDB）	back-mdb（LMDB）が推奨プライマリ
設定方式	dse.ldif / cn=config、dsconfで操作	cn=config（slapd.confは非推奨）
管理ツール	dscreate / dsconf / dsctl / dsidm	ldapadd / ldapmodify など標準LDAP操作
レプリケーション	マルチサプライヤ（CSN付きchangelog）	syncrepl / delta-syncrepl（N-Wayはバージョン制約に注意）

判断のとっかかりはシンプルです。すでにRHEL系で固めていて、将来的にFreeIPAやRed Hatの統合ID管理に寄せていく見込みがあるなら、389 Directory Serverが素直です。エコシステムが一貫し、専用ツールで運用の定石に乗れます。逆に、ディストリビューションを問わず軽量に立てたい、外部依存を減らしたい、あるいは既存のOpenLDAP資産があるなら、OpenLDAPを続けるか選ぶのが合理的です。

移行を考える場合、私が最初に問うのは「移行で何を解決したいのか」です。BerkeleyDB非推奨への対応が目的なら、389のままLMDBへ切り替える（bdbからmdbへの移行）だけで済むことも多く、わざわざ別実装へ乗り換える必要はありません。実装そのものを変えるのは、エコシステム統合やサポート体制といった、データベース以外の理由がある時に限るべきです。LDAPの移行はスキーマ・ACL・レプリケーショントポロジを丸ごと作り直す重い作業になりがちなので、「目的が手段に見合うか」を冷静に見極めることが何より大事です。

Linux管理者・学習者にとっての教訓

この比較から持ち帰ってほしいのは、個別の製品知識そのものよりも、その奥にある共通の原理です。

第一に、「設定をどこに持つか」がそのまま運用のしやすさを決める、という点です。389のdse.ldif、OpenLDAPのcn=config、いずれも設定を構造化データとして扱い、ファイルの直接編集ではなく操作（コマンドやLDAP操作）で変更する方向へ進んでいます。これはサーバー運用全般の流れと同じで、手で設定ファイルを書き換える時代から、宣言的に管理し、操作を通じて変更する時代への移行を映しています。

第二に、ネット上の情報の「鮮度」を疑う癖の重要性です。OpenLDAPのslapd.confが非推奨になっているのに、それを前提にした解説が大量に残っている。これはLDAPに限らず、Linuxの学習で常につきまとう問題です。手を動かす前に、必ず公式ドキュメントの最新版で「いま正しい作法は何か」を確認する。この一手間を惜しまない人だけが、古い罠を踏まずに進めます。

第三に、「移行は目的があってこそ」という当たり前の原則です。技術トレンドや新しい実装に飛びつく前に、いまの構成で何が困っていて、それは本当に乗り換えでしか解決しないのかを問い直す。データベースの非推奨対応のように、同じ製品の中の設定変更で片づく問題を、丸ごとの移行で大事にしてしまう失敗は、現場で何度も見てきました。

389 Directory ServerとOpenLDAPのどちらを選ぶにせよ、土台になるのはLDAPそのものの理解と、Linuxサーバーの基礎体力です。ディレクトリサービスは認証基盤という、止めれば全社が止まる中核を担います。だからこそ、流行りの単語をなぞるのではなく、仕組みから説明できる地力をつけておくことが、結局いちばんの近道になります。

---

• 次のページへ：Intel APX×AMDレジスタ拡張にKVMが対応｜次世代CPU仮想化の実装動向
• 前のページへ：Homebrew 6.0.0公開｜サードパーティtap信頼確認でセキュリティ強化、Linuxユーザーの対応
• この記事の属するカテゴリ：Linux情報・技術・セキュリティへ戻る