LIT-slapd-overview

요약

slapd(Standalone LDAP Daemon)는 OpenLDAP 프로젝트의 LDAP 디렉토리 서버이다. 프론트엔드(네트워크/프로토콜)와 백엔드(데이터 저장)가 분리된 모듈형 아키텍처를 가지며, Overlay라는 미들웨어 레이어로 기능을 확장한다. 현재 권장 백엔드는 LMDB 기반의 MDB이며, syncrepl 프로토콜로 Provider/Consumer 복제를 지원한다. 2026년 현재 2.6.x 버전이 활발히 유지보수되고 있다.

핵심 포인트

아키텍처: 프론트엔드/백엔드/Overlay 3계층

slapd의 아키텍처는 3가지 레이어로 구성된다:

클라이언트 요청
    ↓
[프론트엔드] ← 네트워크 접근, LDAP 프로토콜 처리
    ↓
[Overlay 스택] ← 요청 가로채기, 변환, 기능 확장 (0~N개 적재)
    ↓
[백엔드] ← 데이터 저장/검색

이 구조의 핵심 장점은 각 레이어를 독립적으로 교체/추가할 수 있다는 것이다. 백엔드를 MDB에서 LDAP 프록시로 바꾸거나, Overlay를 추가하여 비밀번호 정책이나 감사 로깅을 활성화하는 것이 서비스 아키텍처 변경 없이 가능하다.

동시에 임의의 수의 백엔드와 데이터베이스 인스턴스를 운영할 수 있어, 하나의 slapd가 여러 DIT를 서로 다른 백엔드로 서비스할 수도 있다.

cn=config: 동적 설정

전통적인 slapd.conf 파일 대신 LDAP 디렉토리 자체로 설정을 관리한다. cn=config라는 별도의 DIT가 설정을 담고 있으며, ldapmodify 등의 LDAP 명령으로 설정을 변경할 수 있다. 서비스 재시작이 필요 없다.

이것은 매우 독특한 설계이다 — 설정 자체가 LDAP 데이터이므로, 설정에 대한 접근 제어, 복제, 감사 로깅도 일반 LDAP 데이터와 동일한 메커니즘으로 처리된다. [추론]

MDB 백엔드 (LMDB)

현재 권장 기본 백엔드이다. OpenLDAP 자체에서 개발한 LMDB(Lightning Memory-Mapped Database) 를 사용하며, 이전의 Berkeley DB(BDB/HDB)를 대체한다.

핵심 특성:

캐싱 불필요, 튜닝 없이 최대 성능 — BDB와 달리 캐시 크기, 체크포인트 등을 조정할 필요가 없음
메모리 효율: back-hdb 대비 RAM 사용량 37%
단일 파일 저장: 모든 DIT 데이터를 하나의 파일에 저장
Memory-mapped I/O를 사용하여 OS의 페이지 캐시를 그대로 활용

BDB가 다양한 튜닝 파라미터(캐시 크기, 체크포인트 간격, IDL 캐시 등)를 요구하고 그에 따라 성능이 크게 좌우되었던 것과 대조적이다. LMDB의 "제로 튜닝" 설계 철학은 운영 복잡도를 크게 줄인다.

Overlay 시스템

Overlay는 프론트엔드와 백엔드 사이에 삽입되는 미들웨어로, 17종이 기본 제공된다. 주요 Overlay:

Overlay	용도	비고
syncprov	syncrepl 복제의 provider 측 지원	복제의 핵심
ppolicy	비밀번호 정책 (만료, 이력, 잠금, 품질)	보안 필수
memberof	그룹 멤버십 자동 업데이트	그룹 관리 편의
refint	참조 무결성 유지	엔트리 삭제 시 자동 정리
accesslog	접근 로그 기록 (별도 DB)	감사/delta-syncrepl에 필요
unique	속성 값 유일성 강제	이메일 중복 방지 등
pcache	검색 결과 캐싱	프록시 환경에서 유용
translucent	원격 LDAP 엔트리의 로컬 오버라이드	하이브리드 디렉토리

Overlay는 개별 데이터베이스에 적용하거나, 프론트엔드에 적용하여 모든 데이터베이스에 전역으로 적용할 수 있다.

복제: Syncrepl

slapd의 복제는 syncrepl (LDAP Content Synchronization Protocol, RFC 4533)을 사용한다.

핵심 설계 결정 — Consumer-side 엔진: syncrepl 설정은 consumer(소비자) 측에서 정의된다. 이것은 provider 재설정 없이 consumer를 추가할 수 있다는 의미이다. 이전의 slurpd(provider-side 복제)와 근본적으로 다른 접근이다.

동기화 모드:

refreshOnly: consumer가 주기적으로 provider를 폴링 (pull 방식)
refreshAndPersist: 영구 연결을 유지하고 provider가 실시간 푸시 (push 방식)

entryUUID 기반 추적: DN이 아닌 entryUUID로 엔트리를 식별한다. DN은 이름 변경 시 바뀔 수 있지만 entryUUID는 불변이다. 이를 통해 DN 변경에도 복제가 정확히 추적된다.

Delta-Syncrepl: 일반 syncrepl이 변경된 엔트리 전체를 복제하는 반면, delta-syncrepl은 변경된 속성만 복제한다. accesslog overlay가 필요하며, 동기화가 크게 벗어나면 일반 syncrepl로 폴백한다.

멀티 프로바이더 복제

모드	설명	장단점
N-Way Multi-Provider	모든 서버가 쓰기를 수락, 서로 복제	일관성 문제, split-brain 위험, 쓰기 부하 분산 안됨
MirrorMode	2개 provider 양방향 복제 + 외부 프론트엔드가 쓰기를 한 곳에 집중	단일 provider의 일관성 + HA, NTP 동기화 필수

MirrorMode는 사실상 Active-Standby에 가깝다. 외부 로드밸런서가 모든 쓰기를 하나의 provider에 보내고, 장애 시 다른 provider로 전환한다. 진정한 multi-master가 아닌 점에 주의. [추론]

ACL (접근 제어)

to <what> by <who> [<accesslevel>] [<control>] 형식으로 세밀한 접근 제어가 가능하다. 접근 레벨은 none → auth → read → write 순서이다. 프론트엔드 데이터베이스의 ACL은 모든 데이터베이스에 자동 추가된다.

다른 LDAP 서버와의 비교

vs Active Directory: AD는 Windows 생태계에 깊이 통합되어 있고 GUI가 뛰어나지만, 라이선스 비용이 들고 Windows에 종속된다. OpenLDAP은 크로스 플랫폼이고 무료이지만 관리가 CLI 중심이다.
vs 389 Directory Server: 389 DS는 Red Hat이 개발하며, 내장형 멀티마스터 복제(최대 4-way, 자동 충돌 해결)가 OpenLDAP보다 강력하다. SUSE에서도 기본 LDAP 서버로 채택. 단, OpenLDAP에서 389 DS로의 마이그레이션은 단방향이다.

현재 상태 (2026년 기준)

최신 LTS: 2.6.10 (2025-05-22)
최신 기능 릴리스: 2.6.9 (2024-11-26)
활발히 유지보수 중이며, Feature Release와 LTS 두 트랙으로 관리
LMDB는 독립 프로젝트로도 널리 사용됨 (Monero, Caffe 등)

나의 생각

프론트엔드/백엔드/Overlay 3계층 아키텍처는 관심사 분리(Separation of Concerns) 원칙을 잘 따르고 있다. 특히 Overlay가 데코레이터 패턴처럼 동작하여 기능을 조합할 수 있는 점이 유연하다. [추론]
cn=config의 "설정 자체가 LDAP 데이터" 접근은 meta-circular한 설계로, 설정 관리에 별도 메커니즘이 필요 없다는 점에서 우아하다. 단, 학습 곡선이 높아 신규 사용자에게는 진입 장벽이 된다.
MDB(LMDB)의 "제로 튜닝" 철학은 Ceph의 BlueStore가 "로우 디바이스 직접 접근"으로 파일 시스템 레이어를 제거한 것과 유사한 근본적 접근이다. 중간 레이어를 제거하여 복잡도와 성능 문제를 동시에 해결한다. [추론]
syncrepl의 consumer-side 설계는 provider의 설정 변경 없이 consumer를 자유롭게 추가할 수 있어 운영상 큰 장점이다. 그러나 MirrorMode가 사실상 Active-Standby라는 점에서, 진정한 multi-master가 필요하면 389 DS가 더 적합할 수 있다.
Ceph/GlusterFS 같은 분산 스토리지와 달리, slapd는 "디렉토리 서비스"에 특화되어 있다. 읽기가 쓰기보다 압도적으로 많은 워크로드에 최적화되어 있으며, 이것이 LDAP 프로토콜 자체의 설계 의도이기도 하다.

요약