LDAP 동기화 구축 설계
LDAP 디렉터리 서비스의 이해와 구축
#7 Data Design
Maintaining Good Relationships with Other Data Sources
[다른 데이터 저장소와의 동기화 유지]
회사 내에 다른 곳에 위치한 데이터 저장소와 그와 관련된 LDAP 서버의 데이터(attribute, 각 계층의 노드를 칭하는 개체 entries 와 관련된 정보나 데이터로 속성이라고 함.)를 어떻게 보유하는 것에 대해 생각하는 것은 중요하다. 오늘날 많은 기관들은 다중으로 저장되어 있는 데이터 구성요소 내의 데이터 지연(Redundancy) 문제에 대해 고심하고 있다. 또한 알맞게 조정되어있지 않은 데이터베이스와 디렉터리 시스템 내의 데이터 지연 문제도 마찬가지이다. 디렉터리 서비스는 이 문제를 해결하는데 도움이 될 수 있으며, 그 문제가 악화되는 것을 피하기 위해 확실히 노력해야 한다.
그래서 다음 섹션은 같은 데이터 구성요소를 보유하고 있는 다중의 데이터 저장소의 환경 내에서 디렉터리 서비스가 성공적으로 이루어지기 위해 관리자가 할 수 있는 기술을 개관하고자 한다. 23장은 많은 다른 데이터 저장소와 통합하는 것을 더 넓은 범주에서 논의한 것이 포함된 디렉터리 양립(동기화)에 대해서 다루고 있다.
Replication [복제]
만약 같은 밴더사나 복제를 위한 같은 규약(protocol)*을 사용하는 밴더사로부터 들여온 디렉터리 제품을 통해 업무를 본다면, 데이터 구성요소의 일관성(보안에서 무결성)이 깨지지 않고 많은 서버로 넘겨줄 수 있는 복제 기능을 구축하기 위한 기능을 사용할 줄 알아야 한다. 서드 파티 소프트웨어 또한 로그 변경 메커니즘과 같은 공통의 LDAP 확장을 지원하기 위한 LDAP에서 LDAP 간의 서버 복제를 제공한다.
*그 규약이란, 대두된 LDAP 이중화/복제/IETF(Internet Engineering Task Force) 갱신 표준 프로토콜(LDUP IETF)이다.
Synchronization [동기화]
동기화는 하나의 시스템에서 생성된 변화들이 다른 시스템으로 전파되는 식의 과정이다. 프로토콜, 스키마, 그리고 데이터 포맷의 복제는 각각 다르다. 데이터 포맷 같은 경우는 사이트에서 사용하는 디렉터리 서버와 관련된 데이터 저장소들 사이에서 더 다양할지도 모른다. 동기화는 일반적으로 자주(매시간, 매일, 혹은 매주) 이루어진다. 그러나 데이터의 일관성은 복제와 함께 가능한 아주 타이트하지는 않다. 동기화는 하나 혹은 양방향 그리고 두 개 혹은 더 많은 저장소 사이에서 수행할 수 있다.
예를 들면 만약 직원명 변경이 항상 인사과에 의해서만 다루어지지 않으면, 이것의 동기화 수행(일방향 동기화)은 디렉터리 서비스에 이러한 변경사항을 전파하는 것이 적절할지도 모른다. 만약 인사과 데이터베이스와 디렉터리 서비스의 저장소 양쪽 모두 전화번호가 변경되는 것을 원한다면, 당신은 양방향 동기화를 시스템 간에 설정해야 한다. 만약 양방향 동기화가 사용된다면, 서비스 관리자는 산출물이 무엇인지 조심스럽게 고려할 필요가 있다. 그 산출물이란, 두 개의 다른 시스템들 내에서 같은 데이터의 구성요소가 바뀌었을 때 갱신 내용을 가리킨다.
동기화 도구는 다양한 밴더사로부터 이용 가능하다. 또한 그들의 디렉터리 제품 또는 독자적인 툴과 번들화해서도 가능하다. 일례로 마이크로소프트 사는 메타 디렉터리 서비스를 마이크로 액티브 디렉터리와 많은 다른 데이터 저장소(넷스케이프 디렉터리 서버, MS Exchange 서버, 다양한 관계형 데이터베이스, Lotus Note, 그리고 평이한 파일들까지 포함)와 LDAP 서버 사이에서 동기화할 수 있었다.
기본적으로 동기화 도구는 동기화 프로세스로의 접속과 데이터 변경의 결과와 같은 다른 행위의 원인을 허용해준다. 예를 들어 신규 사원의 정보가 인사과 데이터베이스에 추가되면, 하나의 엔트리가 중앙 디렉터리 서비스에 생성된다. 운영체제의 계정 생성 또는 프린터와 파일서버처럼 네트워크와 연결된 장치로의 접근권한을 부여하는 것과 같이 중앙 디렉터리 서비스 외부에서 트리거(trigger*)가 앞의 이벤트와 똑같이 수행될 수 있다.
* trigger: 데이터베이스가 미리 정해 놓은 조건을 만족하거나 어떤 동작이 수행되면 자동적으로 수행되는 동작. 트리거는 데이터베이스에서 데이터에 대한 유효성 조건과 무결성 조건을 기술하는 데 유용하다. (발췌 : 정보통신용어사전)
만약 당신이 데이터 저장소 사이에서 동기화를 설정한다면, 작업 간에 몇 가지 난점을 거쳐야 할 것이다. 종종 많은 튜닝과 자체 개발 소프트웨어는 데이터 저장소들 사이의 차이점을 해소할 필요가 있다. 많은 경우에 소프트웨어(타사에 의한 디렉터리 소프트웨어) 동기화는 다른 밴더사에 의해 행해지고 데이터베이스 소프트웨어는 다른 데이터 저장소(기존의 밴더사)에 의해 사용된다. 보통의 시스템 통합 작업이 이루어지는데 위한 같은 데이터 포맷에 대한 차이점의 쟁점사항을 해소하기 위해 바로 ‘동기화’가 대안이 될 수 있다.
배치 업데이트 [Batch Updates]
배치 업데이트는 일종의 느슨하게 맺어진 동기화의 한 종류이다. 일반적으로 배치 업데이트는 자주는 아니더라도 한 달에 한 번과 같이 행해지고 다른 성격의 저장소로부터 온 데이터의 병합(merging)에 관여하기도 한다. 데이터를 합치는 프로세스는 약간의 예외와 함께 내부적으로 개발해야만 한다. 이것은 실제 데이터가 버그로 작용하게 되어 대응해야 하는 반복적인 작업이 자주 발생하기 때문에 상당한 낭비 요인을 일으킬 수 있다.
이 책의 저자들이 미시간 대학에 있을 때, 복잡한 C 언어 프로그램의 호출을 통한 개발 작업에 의해 데이터가 대폭 변경된 적이 있었다. 인사과 데이터베이스와 학생 데이터베이스 그리고 중앙 디렉터리 서비스의 데이터를 통합(merge) 하기 위한 개발 작업이었다. 실제 변경된 데이터를 합친 이후에도 사용이 가능한 포맷으로 바꾸는 작업(munge)은 월에 한두 번, 약 하루에 걸쳐 발생했다. 그 시간 동안 어떠한 변경 작업이 없을 때는 데이터를 중앙의 디렉터리 서비스에 보유할 수 있게 하였다. 그리고 시스템 관리자는 일반적으로 그 작업이 제대로 이루어지는지 매번 확인해야 했다. 만약 데이터 포맷 변환 간에 어떤 문제가 발생했을 때, 시스템 관리자는 수작업으로 그 데이터 형식을 변환해주거나 전체 변환 프로세스(munge)를 재시작해야만 했다. 이러한 작업은 관리자로 하여금 피곤하게 만들었다.
배치 업데이트를 성공적으로 사용하는 데 핵심은 프로세스를 스트림라인(streamline)으로 보내는 배치 업데이트를 사용하는 것이고 이것은 너무나 단순한 개념이며 또한 자동화시킬 수 있다.
정책 고려 사항 [Political Considerations]
이제 막 구축한 디렉터리 서비스는 아마도 사이트의 관계자들에게 반복 작업이나 어떤 제약으로부터 벗어나게 해 주기보다는 아직까지는 검증되지 않은 애물단지로 비칠지도 모른다. 특히 자원이 제한된 데이터 저장소의 관리자가 속한 큰 기업일 경우 더욱 그렇다. 또한 그들 자체의 문제에만 포커스를 맞추거나 단지 그들의 방식으로 설정된 경우 더욱 그렇다.
이것은 그 기업만의 상황은 아니다. 그러나 이 상황이 본인이 속한 사이트에 해당한다면 최적의 해결책은 당신의 디렉터리 서비스에서 도움을 줄 수 있는 다른 중요한 데이터 저장소의 일관성을 유지하는 방식을 당신의 동료에게 확신시키는 것(양방향 켜뮤니케이션)이다. 이를 테면, 만약 함께 일함으로써 당신은 네다섯 개 되는 주소 변경의 형식을 제거할 수 있고, 전체 컬렉션을 하나의 주소 변경 웹페이지로 대체(통합)할 수 있다. 그렇게 할 수 있는 주인공은 그 사이트에서 능력자로 비칠 것이다.
만약 non-LDAP 디렉터리 또는 데이터베이스를 관리하는 사람들 중 하나라면, 그 사람은 우리에게 환영의 대상이다. 이 책을 보고 있는 독자는 스스로 앞서가는 사람들 중 하나임을 증명했다. 독자가 스스로 그 과제 해결력을 소유할 수 있다는 운을 믿지 않는다면, 부디 LDAP 디렉터리 서비스를 설계, 구축하기 위해 노력하는 사람에게 도움이 될 수 있고 친근해질 수 있도록 노력해라.
데이터 설계 체크리스트
다음은 데이터 설계를 만들기 위해 필요한 절차를 요약한 목록이다.
V 향후 또는 초기에 당신의 디렉터리를 사용할 애플리케이션에 대한 이해를 발전시켜라.
V 데이터 정책 사항을 만들어라.
V 전체 조직에 대한 데이터 저장소 집합을 만들어라.
V 각각의 디렉터리-활성화된 애플리케이션에 의해 필요한 데이터 구성요소의 목록을 만들어라.
V 다음을 따르는 각 데이터 요소를 상세화(Characterize)하라.
- Format (형식)
- Size of each value (각 값의 용량)
- Number of distinct values (NDV: 고윳값의 수)
- Data ownership and restrictions (데이터 소유권과 제한)
- Consumers (데이터 이용자)
- Frequency of changes in values (dynamic versus static: 동태 통계로 동적인 값들의 빈도)
- Range of application (shared versus application-specific: 애플리케이션의 범위로 특정 응용 프로그램과 관련된 데이터의 범위)
- Relationships with other data elements (다른 데이터 요소들과의 관계)
V 데이터 구성요소들 사이에서 서로 겹치는 부분에 위치한 상세목록을 조사하라.
V 데이터 저장소들 사이에 관계를 관리하기 위한 계획을 세워라.
더 읽을거리
Netscape Directory Server Deployment Guide: #2, How to Plan Your Directory Data. Available on the World Wide Web at http://enterprise.netscape.com/docs/directory (Discarded from the site)
마치며
파트 II의 첫 번째 장의 약간은 독자로 하여금 사이트의 디렉터리와 관련된 니즈, 저장시키는 데이터를 둘러싼 쟁점거리를 밝히는데 도움이 될만한 디렉터리 설계 프로세스의 개관을 하였다. 다음 몇 개의 장은 더욱 구체적인 LDAP 디렉터리의 설계에 대한 토픽들을 볼 것이다. 먼저, 8장에서 다루는 내용과 밀접한 디렉터리 스키마 디자인이다.
Reference:
Clines, S., & Loughry, M. (2008). 『Understanding and Deploying LDAP Directory Services 2nd Edition』p255-258, Hoboken, NJ: Wiley Pub.
