Oracle Internet Directory(OID)를 확장할 때는 요청량 증가와 각 구성 요소의 처리 용량을 함께 살펴야 합니다. 이 시리즈의 Part 1에서는 확장이 필요한 이유, 검토할 네 가지 핵심 요소, OID 아키텍처를 정리합니다.
Navigation:
- 현재 위치: 파트 1 – 기본 개념 및 핵심 아키텍처
- 다음: 파트 2 – 구현 전략 및 실제 응용
오라클 인터넷 디렉토리 확장이란?
요청이 늘어도 응답이 안정적이라면 추이를 관찰하고, 대기가 반복된다면 그 병목을 기준으로 확장안을 검토하는 편이 좋습니다.
OID 최적화는 기존 자원을 효율적으로 사용하도록 설정을 조정하는 작업입니다. 확장은 늘어나는 요청을 처리할 수 있도록 자원이나 서버 구성을 늘리는 작업입니다. 두 작업은 목적이 다르지만, 실제 운영에서는 병목 분석과 용량 계획을 함께 검토해야 합니다.
예를 들어 사용자가 매주 수백 명씩 늘어나는 조직에서는 인증 요청량도 증가할 수 있습니다. 현재 처리 용량을 확인하지 않고 운영하면 응답 지연이나 장애로 이어질 수 있으므로, 요청량 추이와 확장 시점을 미리 검토해야 합니다.
이 가이드는 이전 포스팅인 [Oracle Internet Directory (OID) 성능 최적화: 성능 문제 해결 및 모범 사례 가이드]에서 다룬 최적화 기법을 바탕으로, 조직의 요청량 증가에 맞춰 OID 환경을 확장할 때 검토할 항목을 정리합니다.
주요 개념
1. 확장(Scaling) vs. 최적화(Optimization)
확장과 최적화는 목적을 구분해 검토합니다.
- 확장: 요청 증가에 맞춰 CPU·메모리 등의 자원이나 서버 구성을 늘립니다.
- 최적화: 기존 자원의 사용 효율을 높이기 위해 캐시, 연결 풀, 검색·인덱스 설정을 점검합니다.
2. 확장의 중요성
확장 여부는 현재 처리 용량과 예상 요청량을 비교해 판단합니다.
- 사용자 수뿐 아니라 LDAP 작업 종류, 요청 빈도와 피크 동시 요청을 확인합니다.
- 병목 원인을 먼저 확인하고 필요한 구성 요소의 증설을 검토합니다.
- 변경 후에도 같은 부하 조건에서 응답 시간과 실패율을 비교합니다.
확장을 위한 전제 조건
작업 전에 설치 버전과 운영 조건을 확인합니다.
- OID·Oracle Database·OS의 정확한 버전과 지원 조합을 확인합니다. “11g 이상”이라는 조건만으로 호환성이나 지원 여부를 판단해서는 안 됩니다.
- LDAP 검색·인증 동작과 클라이언트 연결 방식을 파악합니다.
- 데이터베이스 관리, 백업·복구 절차와 시험 환경을 준비합니다.
서버를 추가해도 검색 조건, 연결 누수나 데이터베이스 대기가 원인이라면 지연이 남을 수 있습니다. 클라이언트·OID·데이터베이스의 지표를 함께 비교해 어느 구간이 요청 처리를 제한하는지 확인합니다.
성공적인 OID 확장의 네 가지 핵심 요소
1. 자원 활용 분석(Resource Utilization Analysis)
CPU·메모리·디스크·네트워크 사용량을 LDAP 요청량과 같은 시간 구간에 기록합니다. OID 프로세스, 클라이언트 애플리케이션과 데이터베이스의 지표를 구분해 병목 후보를 좁힙니다.
- CPU: 높은 사용률이 지속되는 프로세스와 요청량 변화를 확인합니다.
- 메모리: 프로세스 사용량, 가용 메모리와 스왑 입출력 추이를 확인합니다.
- I/O: 디스크·네트워크 처리량과 지연이 요청 지연과 함께 증가하는지 확인합니다.
자원 지표를 같은 시간 구간에서 비교하면 사용량 변화와 병목 징후를 구분하는 데 도움이 됩니다. 증설 판단에는 요청량과 응답 시간도 함께 사용합니다.
2. 성장 패턴 분석 (Growth Pattern Analysis)
사용자 수, LDAP 요청량과 디렉토리 데이터량의 추이를 기록합니다.
- 사용자 증가: 계정 수와 실제 인증·검색 요청량의 관계를 확인합니다.
- 데이터 증가: 엔트리 수, 속성 크기와 검색 조건의 변화를 함께 살펴봅니다.
- 피크 시간: 업무 시작이나 배치 실행 시 동시 요청이 얼마나 증가하는지 측정합니다.
예상 부하와 시험 결과를 바탕으로 증설 시점을 정합니다. 서버·저장 용량·로드 밸런싱 변경은 확인된 제한 요인에 맞춰 선택하고, 적용 전후의 측정 조건을 유지합니다.
3. 성능 지표 프레임워크 구축(Performance Metrics Framework)
성능 판단에 사용할 지표와 측정 구간을 먼저 정합니다.
- 응답 시간: 검색·인증 등 작업 종류별 지연과 오류를 기록합니다.
- 처리량: 요청량 증가에 따라 완료 작업 수가 어떻게 변하는지 확인합니다.
- 자원 사용: OID·클라이언트·데이터베이스의 CPU, 메모리와 I/O를 구분합니다.
- 연결 풀: 사용량, 최대값, 대기 시간과 연결 누수를 확인합니다.
응답 지연이나 처리량 감소만으로 증설을 결정하지 않고, 요청 구성과 병목 원인을 함께 확인합니다.
모니터링 도구는 설치 버전과 구성에 맞춰 선택합니다.
- Oracle Enterprise Manager: 해당 OID 버전과 관리 플러그인이 제공하는 수집 항목을 확인합니다.
- LDAP 서버 로그: 오류와 처리 지연을 요청량 변화와 대조합니다.
- 합성 트랜잭션: 시험 환경에서 대표 검색·인증 요청을 반복해 변화를 비교합니다.
주요 지표를 정기적으로 비교하고 이상 징후의 지속 시간과 영향을 기록합니다. 이 기록을 다음 용량 검토의 기준으로 사용합니다.
4. 인프라 계획(Infrastructure Planning)
확장 방식은 측정된 제한 요인에 맞춰 선택합니다.
- 수직 확장: CPU·메모리·저장 장치의 제약을 확인한 뒤 자원을 늘립니다.
- 수평 확장: 지원되는 OID 구성과 데이터 일관성·장애 조치 조건을 확인한 뒤 서버 추가를 검토합니다.
- 자원 배분: OID 프로세스, 클라이언트 연결 풀과 데이터베이스 연결 풀을 구분해 조정합니다.
- 캐시·검색 최적화: 설치 버전의 문서에 따라 검색 조건과 인덱스·캐시 효과를 시험합니다.
어느 방식도 성능 향상을 보장하지 않습니다. 같은 작업 부하로 변경 전후를 비교합니다.
OID 인프라 계획 시 고려해야 할 주요 사항:
계획에는 운영 검증과 복구 절차를 포함합니다.
- 용량: 피크 요청과 예상 증가량을 반영하고 여유 용량의 근거를 기록합니다.
- 가용성: 지원되는 복제·장애 조치 구성을 확인하고 전환 시험을 계획합니다.
- 알림: 측정값과 운영 기준에 맞춰 경고 조건과 대응 절차를 정합니다.
- 시험: 대표 부하로 응답 시간·처리량·실패율을 비교하고 되돌릴 조건을 정합니다.
OID 아키텍처 Deep Dive
아래에서는 클라이언트, 애플리케이션, OID LDAP 처리와 데이터베이스를 구분해 설명합니다. 이는 점검 대상을 묶은 설명 방식이며, 모든 배포가 동일한 네 계층의 요청 경로를 갖는다는 뜻은 아닙니다.
OID 시스템 핵심 구성 요소
아래 그림은 검토할 구성 요소를 묶어 보여 주는 개념도이며, 실제 LDAP 요청의 필수 경로를 나타내지 않습니다. LDAP 클라이언트는 OID의 LDAP 수신 포트에 연결하고, OID 서버 프로세스가 Oracle Database를 사용합니다.
WebLogic에서 실행되는 애플리케이션은 LDAP 클라이언트가 될 수 있으며, WebLogic 관리 도구를 이용하는 구성도 있습니다.
모든 LDAP 요청이 WebLogic Work Manager를 거친다고 해석하지 마세요. 실제 요청 경로와 관리 경로는 설치 버전 및 구성에 맞춰 따로 확인합니다.
클라이언트 계층: 엔트리 포인트
클라이언트는 LDAP 인증·검색·변경 요청을 OID에 보냅니다. 인증 결과와 접근 허용 여부를 결정하는 서버 측 처리와 구분해야 합니다.
- 클라이언트의 요청량, 재시도, 타임아웃과 연결 풀 사용량을 확인합니다.
- OID가 수행하는 인증·검색·변경 및 접근 제어 처리 시간을 비교합니다.
- 여러 OID 서버에 요청을 분산할 때는 지원 구성, 연결 유지와 장애 조치 동작을 시험합니다.
애플리케이션 계층 (WebLogic)
WebLogic은 OID를 사용하는 애플리케이션이나 관리 도구를 실행할 수 있습니다. 이를 OID 서버의 LDAP 처리 프로세스와 구분해 점검해야 합니다.
- Work Manager와 실행 스레드는 WebLogic 애플리케이션의 작업 처리에 관여합니다. OIDLDAPD의 LDAP 처리 용량을 직접 지정하는 설정은 아닙니다.
- 애플리케이션의 LDAP 연결 풀, 요청량, 대기 시간과 OID 응답 시간을 같은 구간에서 비교합니다.
- WebLogic 클러스터를 증설하더라도 OID 프로세스나 백엔드 데이터베이스의 처리 용량이 자동으로 늘어나는 것은 아닙니다.
애플리케이션 병목인지 OID·데이터베이스 병목인지 먼저 구분하고, 확인된 구성 요소에 맞는 변경을 시험 환경에서 검증합니다.
LDAP 계층 (Core Services)
OID 서버 프로세스는 LDAP 작업을 처리하고 Oracle Database에 접근합니다.
- 서버 프로세스: 검색·추가·변경·삭제 요청의 처리량과 지연을 확인합니다.
- 데이터베이스 연결: OID 측 연결 풀의 한도, 사용량과 대기 시간을 확인합니다.
- 조정: 설치 버전의 권장 절차에 따라 프로세스 수와 연결 설정을 시험합니다.
OID 저장 스키마에 임의의 파티셔닝을 적용하는 것을 일반 확장 방법으로 권장하지 않습니다. 지원 여부와 스키마 변경 제한을 먼저 확인해야 합니다.
데이터베이스 계층 (기반 구조)
Oracle Database가 디렉토리 데이터를 저장하므로 OID 지연을 조사할 때 데이터베이스 상태도 함께 확인합니다.
- 저장 용량: 데이터·인덱스 증가량과 여유 공간을 기록합니다.
- 성능: LDAP 부하와 데이터베이스 대기·I/O를 같은 시간 구간에서 비교합니다.
- 복구: 백업이 있다는 사실뿐 아니라 복원 절차와 시험 결과를 확인합니다.
ASM·RAC·Data Guard를 모든 환경에 적용할 수 있는 성능 해결책으로 취급하지 않습니다. 버전 조합, 지원 구성, 라이선스와 운영 요구에 따라 별도로 검토합니다.
구성 요소 상호 작용 및 성능 영향
클라이언트, OID 프로세스와 데이터베이스의 부하를 함께 비교합니다. 관리 서버나 애플리케이션 서버의 지표는 해당 요청에 실제로 관여하는 경우에 구분해 확인합니다.
애플리케이션의 동시 요청을 늘리면 OID와 데이터베이스의 부하도 증가할 수 있습니다. 클라이언트 대기 시간, OID 처리량과 데이터베이스 지표를 같은 구간에서 비교해 어느 구성 요소가 제한 요인인지 확인합니다.
WebLogic 스레드 수 증가를 OID 자체의 프로세스 증설과 같은 조치로 취급하지 마세요.
구성 요소 하나의 용량을 늘렸다고 전체 응답 시간이 좋아진다고 보장할 수는 없습니다. 변경 전후에 같은 부하로 시험하고, 실패율과 응답 시간도 함께 비교합니다.
성능 지표 프레임워크 (Performance Metrics Framework)
아래 지표는 같은 시간 구간에서 함께 비교합니다.
- 응답 시간과 오류: LDAP 작업 종류별로 기록합니다.
- 처리량과 동시 요청: 부하 증가 시 완료 작업 수와 대기 변화를 확인합니다.
- CPU·메모리·I/O: 지연이 발생한 시점의 각 프로세스와 데이터베이스 상태를 비교합니다.
- 연결 풀: 클라이언트 LDAP 풀과 OID 데이터베이스 풀의 사용량·대기를 구분합니다.
지표 변화가 나타나면 로그와 요청 구성으로 원인을 좁힙니다.
- Oracle Enterprise Manager: 설치 버전에 맞는 관리 기능과 수집 항목을 확인합니다.
- LDAP 로그: 오류·지연 발생 시점을 부하와 대조합니다.
# 연결 모니터링 명령 (orclstatsflag=1 필요)
ldapsearch -h <host> -p <port> -D cn=orcladmin -q \
-b "cn=client connections,cn=monitor" -s base "(objectclass=*)"합성 트랜잭션은 시험 환경에서 대표 검색·인증 요청을 반복하고 결과를 비교하는 데 사용합니다. 실제 사용자 영향을 피할 수 있다고 보장하지 않으며, 부하와 실행 범위를 먼저 정합니다.
주요 성능 지표(Key Performance Indicators)
메모리, CPU와 연결 상태를 요청량·지연 지표와 함께 확인합니다.
1. 메모리 상태 지표
가용 메모리, 프로세스 사용량과 스왑 입출력을 함께 관찰합니다.
- 가용 메모리: 15%는 이 글의 경고 기준 예시입니다. OS의 가용 메모리 정의, 프로세스 사용량과 스왑 입출력 추이를 함께 확인해 기준을 정합니다.
- 스왑: 5% 사용률만으로 장애나 확장 필요성을 판단하지 않습니다. 지속적인 스왑 입출력과 응답 지연이 함께 나타나는지 확인합니다.
- 페이지 폴트: 전체 발생 수만으로 메모리 부족을 확정하지 않습니다. minor/major fault, 디스크 I/O와 메모리 사용량을 함께 확인합니다.
2. CPU 성능 지표
CPU 사용률이 높은 프로세스와 부하의 지속 시간을 먼저 확인합니다.
- CPU 사용률: 70%와 85%는 경고 기준 예시이며 OID 공통 확장 기준이 아닙니다. 지속 시간, 요청량과 응답 시간을 함께 비교합니다.
- 확장 판단: 높은 CPU 사용률의 원인을 확인한 뒤 설정·검색 조건·자원 증설 중 필요한 조치를 시험합니다. 85%를 넘었다는 이유만으로 즉시 증설하지 않습니다.
- 코어별 부하: 0.7을 보편적인 병목 임계값으로 적용하지 않습니다. 지표가 CPU 사용률인지 정규화한 load average인지 구분하고, 실제 처리량과 대기 시간을 함께 확인합니다.
3. 연결(Connection) 상태 지표
클라이언트 LDAP 연결과 OID 데이터베이스 연결의 사용량·대기를 구분합니다.
- 연결 사용률: 75%는 경고 기준 예시입니다. 클라이언트 LDAP 연결 풀과 OID의 데이터베이스 연결 풀을 구분하고, 각각의 최대값·사용량·대기 시간을 확인합니다.
- 대기 시간: 대기가 길어지면 연결 누수, 요청 처리 지연과 풀 제한을 함께 조사합니다. 원인을 확인하지 않은 채 풀 크기만 늘려서는 안 됩니다.
- 타임아웃: 네트워크, 서버 지연, 클라이언트 제한과 설정값을 나누어 확인합니다. 반복적인 타임아웃만으로 용량 부족을 확정하지 않습니다.
경고 값 하나만으로 확장을 결정해서는 안 됩니다. 여러 지표가 같은 시점에 어떻게 변하는지 비교하고, 지연 원인을 확인합니다.
의사 결정 과정 (Decision Making Process)
확장 결정은 관측, 원인 분석, 변경 선택, 검증 순서로 진행합니다.
1. 분석 단계 (Analysis Phase)
현재 부하와 정상 구간의 측정값을 수집합니다.
- CPU·메모리·I/O와 LDAP 요청량·작업 구성을 같은 구간에 기록합니다.
- 정상 구간을 기준으로 응답 시간·처리량·오류를 비교합니다.
- 차이가 발생한 시점과 영향을 기록해 다음 분석 대상으로 정합니다.
2. 진단 단계 (Diagnosis Phase)
수집한 지표로 병목 후보를 좁힙니다.
- 클라이언트 대기, OID 처리와 데이터베이스 대기를 구분합니다.
- 로그·검색 조건·연결 사용량을 지연 시점과 대조합니다.
- 가설을 시험 환경에서 확인하고 아직 확인되지 않은 원인은 따로 남깁니다.
3. 해결책 선택 (Solution Selection)
확인된 제한 요인에 맞춰 변경안을 선택합니다.
- 설정 조정, 검색 최적화와 자원 증설을 각각 비교합니다.
- 비용·구현 시간·장애 위험·지원 여부를 검토합니다.
- 예상 효과의 측정 방법과 되돌릴 조건을 변경 전에 정합니다.
4. 구현 및 검증 (Implementation and Validation)
시험 환경에서 변경 전후를 비교한 뒤 운영 적용 여부를 결정합니다.
- 동일한 작업 구성과 부하로 응답 시간·처리량·오류를 측정합니다.
- 개선된 지표와 악화된 지표를 함께 기록합니다.
- 검증 결과가 기준을 충족하지 않으면 원인을 다시 조사하거나 정해 둔 절차로 되돌립니다.
판단 근거와 변경 결과를 기록하면 다음 용량 검토에서 같은 조건을 비교할 수 있습니다. 확인되지 않은 원인과 지원 조건은 해결된 것으로 처리하지 않습니다.
구현 단계에서는 이 측정 기준을 설치 버전과 운영 구성에 맞춰 구체화합니다.
파트 1 결론
Part 1에서는 자원 사용, 부하 증가, 성능 지표와 인프라 계획의 검토 순서를 정리했습니다. 실제 변경은 병목과 지원 조건을 확인하고 시험 결과를 비교한 뒤 결정합니다. Part 2의 메모리·연결 관리 예제도 같은 기준으로 검토해야 합니다.
Stay tuned for Part 2: Implementation Strategies and Real-world Applications.