오라클 인터넷 디렉토리(OID) 확장 Part 2: 엔터프라이즈급 구현 전략 완벽 해설
대규모 기업 환경에서 OID를 효율적으로 운영하는 것은 매우 중요합니다. 이번 가이드에서는 실제 현장에서 검증된 확장 전략을 다룰 예정인데요, 크게 세 가지 핵심 영역에 초점을 맞추고 있습니다:
- 메모리 최적화
- 연결 관리
- 단일 서버와 다중 서버 구성의 모범 사례
이러한 검증된 전략들을 통해 시스템 성능을 한 단계 끌어올리고, 비즈니스 요구사항을 충족시킬 수 있습니다.
메모리 최적화: OID 성능의 핵심
메모리를 최적화하는 것은 마치 도시의 교통 시스템을 설계하는 것과 비슷합니다. 체계적인 계획이 없다면 교통 체증이 발생하듯, 메모리 관리가 제대로 되지 않으면 시스템 성능이 크게 저하될 수 있죠. OID 환경에서 메모리는 크게 세 영역에 걸쳐 있습니다:
- 데이터베이스 계층
- OID/LDAP 프로세스
- 애플리케이션 계층(WebLogic JVM)
System Global Area(시스템 글로벌 영역, 이하 SGA) 구성과 튜닝
SGA는 Oracle Database 성능의 핵심입니다. 데이터베이스와 OID가 같은 서버에서 운영되는 경우, 다음과 같이 SGA를 설정할 수 있습니다:
-- 기본 메모리 아키텍처 설정 ALTER SYSTEM SET sga_target = '24G' SCOPE=BOTH; ALTER SYSTEM SET sga_max_size = '24G' SCOPE=BOTH; -- 버퍼 캐시 설정 -- SGA의 약 2/3를 버퍼 캐시에 할당 ALTER SYSTEM SET db_cache_size = '16G' SCOPE=BOTH; -- 공유 풀 설정 -- 초기 설정은 4GB, 실제 사용량에 따라 조정 ALTER SYSTEM SET shared_pool_size = '4G' SCOPE=BOTH;
32GB 메모리를 가진 서버에서 이렇게 24GB를 할당하는 이유를 살펴보겠습니다.
75% 규칙의 의미 Oracle은 전체 서버 메모리의 약 75%만 사용하도록 권장합니다. 이는 마치 고속도로에서 차량이 늘 100% 꽉 차있으면 교통 체증이 발생하듯, 시스템도 약간의 여유 공간이 필요하기 때문입니다. 이 여유 공간은 운영체제와 다른 프로세스들이 원활하게 동작하는데 필수적입니다.
메모리 균형 배분의 원칙:
- 버퍼 캐시에 16GB 할당: 자주 사용하는 데이터를 빠르게 접근할 수 있게 합니다
- 공유 풀에 4GB 할당: SQL 문장, PL/SQL 코드, 메타데이터를 효율적으로 관리합니다
서버 구성에 따른 메모리 관리 전략
대부분의 기업들은 OID를 데이터베이스와 별도 서버에서 운영합니다. 이렇게 분리된 환경에서는 각 서버의 특성에 맞게 메모리를 최적화할 수 있습니다:
데이터베이스 서버:
- OID나 WebLogic과의 메모리 경쟁이 없어 더 많은 메모리를 Oracle Database에 할당할 수 있습니다
- SGA 크기를 보다 여유있게 설정할 수 있어 성능 향상에 유리합니다
OID/LDAP 서버:
- 큰 SGA가 필요하지 않습니다
- 대신 JVM 힙, 운영체제 오버헤드를 위한 충분한 메모리가 필요합니다
금융 서비스 기업의 성능 개선 사례
한 금융 서비스 기업이 시간당 5만 건의 사용자 인증을 처리하는 과정에서 성능 문제를 겪고 있었습니다. 어떻게 문제를 해결했는지 단계별로 살펴보겠습니다.
초기 상황 분석
먼저 시스템의 현재 상태를 정확히 파악하는 것부터 시작했습니다:
-- 현재 메모리 파라미터 설정 확인 SELECT name, value, display_value, description FROM v$parameter WHERE name IN ( 'sga_target', 'db_cache_size', 'shared_pool_size' );
초기 설정은 다음과 같았습니다:
sga_target = 8G db_cache_size = 4G shared_pool_size = 1G
이러한 설정으로 인해 발생한 문제점들:
- 디스크 읽기 작업이 과도하게 발생
- 피크 시간대에 응답 시간이 크게 증가
- 잦은 세션 타임아웃 발생
시스템 개선 과정
문제 해결을 위해 32GB 서버에서 다음과 같이 메모리 설정을 최적화했습니다:
-- 최적화된 메모리 설정 sga_target = 24G db_cache_size = 16G shared_pool_size = 4G
변경 내이 실제로 어떤 효과를 가져오는지 실시간으로 모니터링했습니다:
-- 주요 성능 지표 모니터링 SELECT metric_name, value, metric_unit FROM v$sysmetric_history WHERE group_id = 2 AND metric_name IN ( 'Physical Read Total IO Requests Per Sec', 'Response Time Per Txn', 'Session Count' );
최적화 효과
메모리 최적화 후 시스템은 눈에 띄는 성능 향상을 보였습니다. 특히 개별 서버 환경에서는 OID나 WebLogic과의 자원 경쟁 없이 데이터베이스가 필요한 만큼의 메모리를 사용할 수 있게 되었죠. 마치 교통 체증이 심한 도로에 새로운 차선을 추가한 것처럼, 시스템이 더 원활하게 작동하기 시작했습니다.
연결(Connection) 관리: 안정적인 OID 운영의 핵심
데이터베이스, OID, 그리고 클라이언트 간의 연결 관리는 시스템의 병목 현상을 방지하는 데 매우 중요합니다. 마치 도시의 교통 신호 체계와 같이, 효율적인 연결 관리는 시스템의 모든 부분이 원활하게 작동하도록 돕습니다.
데이터베이스 연결 설정의 이해
먼저 현재 시스템의 연결 상태를 확인하는 방법부터 알아보겠습니다:
-- 현재 연결 및 프로세스 설정 확인 SELECT name, value, display_value, description FROM v$parameter WHERE name IN ( 'processes', 'sessions', 'transactions' );
이후 최적의 성능을 위해 다음과 같이 설정을 조정합니다:
-- 최적화된 연결 파라미터 설정 ALTER SYSTEM SET processes = 500 SCOPE=BOTH; -- 기본 프로세스 제한 ALTER SYSTEM SET sessions = 750 SCOPE=BOTH; -- processes의 1.5배 ALTER SYSTEM SET transactions = 825 SCOPE=BOTH; -- sessions의 1.1배
각 설정값의 의미를 자세히 살펴보겠습니다:
프로세스 제한(processes = 500)
- 일반적으로 300-400개의 동시 사용자 세션을 지원합니다
- 시스템 운영에 필요한 백그라운드 프로세스를 위해 50-100개의 여유를 둡니다
- 이는 마치 건물의 엘리베이터 용량을 설정하는 것과 비슷합니다. 평소 이용자 수와 긴급 상황을 모두 고려해야 하죠
세션 관리(sessions = 750)
- 프로세스 제한의 1.5배로 설정하는 것이 일반적입니다
- 한 사용자가 여러 세션을 사용할 수 있기 때문입니다
- 백그라운드 작업을 위한 여유 공간도 확보할 수 있습니다
중요한 점은 이 설정이 WebLogic의 스레드 설정과 조화를 이뤄야 한다는 것입니다. 예를 들어, WebLogic 스레드가 50개로 제한되어 있는데 데이터베이스에서 750개의 세션을 허용하도록 설정하면 두 가지 문제가 발생할 수 있습니다:
- 데이터베이스 자원 낭비: WebLogic이 최대 50개의 연결만 만들 수 있다면, 나머지 700개의 세션은 사용되지 않은 채 자원만 차지하게 됩니다.
- 스레드 병목 현상: WebLogic의 50개 스레드가 모두 사용 중일 때 추가 요청이 들어오면, 새로운 요청을 처리할 수 없게 되어 시스템이 응답하지 않거나 타임아웃이 발생할 수 있습니다.
LDAP 서버 연결 관리
데이터베이스와 조화롭게 작동하기 위해서는 LDAP 계층도 세심한 연결 설정이 필요합니다. 마치 교통 체계에서 주요 도로와 이면 도로의 신호 체계가 서로 조화를 이뤄야 하는 것과 같은 원리입니다.
LDAP 서버의 연결 설정 예시:
-- 현재 LDAP 연결 설정 확인 dn: cn=oid1,cn=osdldapd,cn=subconfigsubentry changetype: modify replace: orclmaxcc orclmaxcc: 10 - replace: orclserverprocs orclserverprocs: 8 - replace: orclldapconntimeout orclldapconntimeout: 60
이 설정의 각 요소가 어떤 의미를 갖는지 살펴보겠습니다:
최대 동시 연결 수(orclmaxcc = 10) 각 LDAP 서버 프로세스는 최대 10개의 데이터베이스 연결을 동시에 처리할 수 있습니다. 이는 마치 한 계산대에서 동시에 처리할 수 있는 고객 수를 정하는 것과 비슷합니다. 너무 적으면 대기 시간이 길어지고, 너무 많으면 시스템에 부담이 될 수 있죠.
서버 프로세스 수(orclserverprocs = 8) 일반적으로 CPU 코어 수에 맞춰 설정합니다. 8개의 코어가 있다면, 8개의 서버 프로세스를 실행하는 것이 가장 효율적입니다. 마치 은행의 창구 개수를 적절히 조절하는 것과 같습니다.
연결 타임아웃(orclldapconntimeout = 60) 60초 동안 활동이 없는 연결은 자동으로 종료됩니다. 이는 제한된 자원을 효율적으로 사용하기 위한 설정입니다. 마치 카페에서 오랫동안 자리만 차지하고 있는 손님에게 양해를 구하는 것과 비슷한 원리입니다.
실제 연결 상태를 모니터링하기 위해서는 다음과 같은 명령을 사용할 수 있습니다:
연결 사용량 모니터링:
-- 활성 연결과 사용 패턴 모니터링 ldapsearch -h -p -D cn=orcladmin -w -b \ "cn=client connections,cn=monitor" "(objectclass=*)" \ orclmaxconnections orclcurrentconnections
대형 리테일 포털의 연말 쇼핑 시즌 대응 사례
한 대형 온라인 쇼핑몰이 연말 쇼핑 시즌에 심각한 연결 타임아웃 문제를 겪었습니다. 이 사례를 통해 연결 관리가 얼마나 중요한지, 그리고 어떻게 문제를 해결했는지 자세히 알아보겠습니다.
초기 상황 분석
먼저 시스템의 초기 상태를 확인했습니다:
-- 연결 상태 확인 SELECT resource_name, current_utilization, max_utilization, ROUND(current_utilization/max_utilization * 100, 2) as usage_percentage FROM v$resource_limit WHERE resource_name IN ('processes', 'sessions');
초기 설정값:
processes = 200
sessions = 300
orclmaxcc = 5
orclserverprocs = 4
이 설정값으로 인한 문제점 :
- 쇼핑 피크 시간대마다 연결 타임아웃 발생
- 로그인과 결제 과정에서 사용자 대기 시간 증가
- 결과적으로 고객 불만이 급증하고 매출에도 영향을 미침
시스템 최적화 과정
문제 해결을 위해 다음과 같이 설정을 변경했습니다:
-- 데이터베이스 연결 용량 확장 ALTER SYSTEM SET processes = 500 SCOPE=BOTH; ALTER SYSTEM SET sessions = 750 SCOPE=BOTH;
-- LDAP 서버 설정 최적화 dn: cn=oid1,cn=osdldapd,cn=subconfigsubentry changetype: modify replace: orclmaxcc orclmaxcc: 10 - replace: orclserverprocs orclserverprocs: 8
최적화의 결과 다음과 같은 개선 효과가 확인 되었습니다:
- 연결 타임아웃 95% 감소
- 인증 대기 시간이 수 분에서 수 초로 단축
- 평상시 부하의 3배에도 시스템 안정성 유지
특히 주목할 점은 데이터베이스 연결 제한과 LDAP 설정을 함께 조정했다는 것입니다. 마치 고속도로의 진입로와 본선 차로 수를 동시에 늘리는 것처럼, 전체 시스템의 균형을 맞추는 것이 중요했습니다.
핵심 요약: 데이터베이스 연결 제한을 LDAP 설정과 조화롭게 맞추니 피크 시간대의 장애가 해소되었습니다. 다중 서버 구조에서는 네트워크 지연을 주의 깊게 살펴봐야 합니다. OID가 데이터베이스와 다른 호스트에 있을 경우, 네트워크 속도 저하나 포화는 마치 연결 풀이 포화된 것처럼 보일 수 있기 때문입니다.
확장 전략 구현: 체계적인 접근법
시스템을 개선할 때는 마치 오래된 건물을 리모델링하는 것처럼 신중하고 체계적인 접근이 필요합니다. 무작정 변경하기보다는, 현재 상태를 정확히 파악하고 단계적으로 개선해 나가는 것이 중요합니다.
초기 시스템 분석
먼저 현재 시스템의 상태를 정확히 파악하는 것부터 시작합니다. 이는 마치 의사가 정확한 진단을 위해 여러 검사를 하는 것과 비슷합니다.
메모리 사용량 확인
- 단일 서버 환경에서는 DB SGA, WebLogic(JVM), OS가 메모리를 놓고 경쟁하지 않는지 확인합니다. 다중 서버 환경에서는 각 노드(DB 노드와 OID/WebLogic 노드)를 개별적으로 메모리 사용량을 확인합니다.
- Unix나 Linux 환경에서는 다음과 같이 메모리 상태를 확인할 수 있습니다:
$ free -m total used free shared buff/cache available Mem: 32000 24000 1000 1000 6000 7000
이 결과가 보여주는 것처럼 메모리가 부족한 상황입니다. 전체 32GB 중 가용 메모리가 1GB밖에 남지 않았다는 것은 마치 8차선 도로에서 1개 차선만 비어있는 것과 같은 상황입니다.
CPU 부하 분석
$ top %Cpu(s): 85.2 us, 10.3 sy, 0.0 ni, 4.1 id, 0.0 wa, 0.0 hi, 0.4 si
CPU 사용률이 85%를 넘어선 것을 확인할 수 있습니다. 이는 마치 엔진이 계속해서 높은 RPM으로 돌아가는 것과 같은 상황으로, 장기적으로는 시스템 안정성에 영향을 미칠 수 있습니다.
데이터베이스 프로세스 상태 확인
-- 데이터베이스 연결이 제한에 근접 SELECT resource_name, current_utilization, max_utilization FROM v$resource_limit WHERE resource_name = 'processes'; RESOURCE_NAME CURRENT_UTILIZATION MAX_UTILIZATION processes 450 500
이 쿼리 결과가 보여주듯이 프로세스 사용량이 한계에 근접했다면, 이는 곧 병목 현상이 발생할 수 있다는 경고 신호입니다.
단계별 변경 적용: 안전하고 효과적인 시스템 개선
시스템을 개선할 때는 한 번에 많은 것을 바꾸기보다 단계적으로 접근하는 것이 안전합니다. 이는 마치 대형 선박의 방향을 바꿀 때 급격한 회전을 피하고 점진적으로 방향을 전환하는 것과 같은 원리입니다.
1단계: 메모리 최적화
SGA 크기를 단계적으로 늘려가며 시스템의 반응을 관찰합니다:
-- 단계적 SGA 증가 ALTER SYSTEM SET sga_target = '16G' SCOPE=SPFILE; ALTER SYSTEM SET db_cache_size = '10G' SCOPE=SPFILE;
처음부터 32GB나 48GB로 급격히 증가시키지 않는 것이 중요합니다. 단일 서버 환경에서는 특히 운영체제, WebLogic JVM, 기타 서비스를 위한 충분한 여유 공간을 확보해야 하기 때문입니다.
2단계: 연결 풀(Connection Pool) 최적화
데이터베이스 쪽 연결 수를 점진적으로 확장합니다:
-- 연결 용량의 단계적 확장 ALTER SYSTEM SET processes = 750 SCOPE=SPFILE; ALTER SYSTEM SET sessions = 1125 SCOPE=SPFILE;
- DB 측에서 세션 사용률이 높으면
processes,sessions,transactions값을 늘립니다. - 이에 맞춰 LDAP 측의
orclmaxcc,orclserverprocs값도 적절하게 조정합니다. - WebLogic 스레드 풀 크기와 조화를 이루도록 조정합니다 (특정 계층에 과도한 자원이 할당되지 않도록 신경 씁니다).
3단계: 모니터링과 검증
각 변경 단계마다 다음 항목들을 꼼꼼히 확인합니다:
- CPU 사용률의 변화
- 메모리 사용 패턴
- 디스크 입출력 상태
- 전반적인 시스템 응답 시간
특히 분산 환경에서는 네트워크 지연 시간을 주의 깊게 모니터링해야 합니다. 때로는 세션이 제대로 정리되지 않아 문제가 발생할 수 있기 때문입니다.
실제 사례를 통해 배운 교훈들
시스템 성능 개선 작업을 통해 우리는 매우 인상적인 결과를 얻을 수 있었습니다. 메모리 사용량, 연결 제한, OID와 데이터베이스 구성을 체계적으로 조정한 결과를 살펴보겠습니다.
성능 개선의 실제 효과
가장 눈에 띄는 변화는 시스템의 반응 속도였습니다. 로그인 인증이나 검색 작업의 응답 시간이 45% 이상 개선되었는데요, 이는 마치 복잡했던 교차로에 신호등을 새로 설치한 것처럼 트래픽이 훨씬 더 원활하게 흐르게 된 것과 같습니다.
더 놀라운 점은 시스템의 안정성이었습니다. 사용자가 4배 이상 증가하고 동시 접속이 급증하는 상황에서도 시스템이 안정적으로 작동했습니다. 이는 마치 좁은 도로를 넓은 대로로 확장한 후에 교통량이 늘어나도 정체가 발생하지 않는 것과 비슷합니다.
핵심 교훈
- 균형 잡힌 접근의 중요성
- 데이터베이스 파라미터, LDAP 설정, WebLogic 스레드는 서로 긴밀하게 연결되어 있습니다. 한 부분만 개선하면 문제가 다른 곳으로 이동할 뿐입니다. 마치 한쪽 끝만 높이 들어올린 시소처럼, 전체적인 균형이 깨질 수 있기 때문입니다.
- 지속적인 모니터링의 가치
- 매 변경 단계마다 CPU, 메모리, 세션 사용량, 로그를 확인하는 것이 중요합니다. 이는 마치 환자의 상태를 지속적으로 체크하는 의사처럼, 시스템의 건강 상태를 계속해서 확인하는 것입니다.
- 단계적 접근의 필요성
- 여러 가지 변경을 한꺼번에 적용하면 문제가 발생했을 때 원인을 찾기 어렵습니다. 마치 복잡한 퍼즐을 풀 때 한 조각씩 맞춰나가듯, 천천히 단계적으로 접근하는 것이 안전합니다.
OID 서버 분리 구성 고려 사항: 성능과 안정성의 균형
대부분의 기업 환경에서는 Oracle Database와 OID(WebLogic 포함)를 별도의 서버나 클러스터에 배치합니다. 서버 분리 구성이 왜 중요한지, 그리고 어떤 이점이 있는지 자세히 살펴보겠습니다.
OID/LDAP 서버는 다음에 집중할 수 있습니다:
- WebLogic 스레드의 효율적인 관리
- JVM 힙 메모리의 최적 활용
- LDAP 프로세스의 원활한 운영
데이터베이스 서버는 이런 작업에 전념할 수 있습니다:
- SGA의 효율적인 운영
- PGA 메모리의 최적화
- 데이터베이스 백그라운드 프로세스의 안정적 실행
독립적인 확장성 확보
분리된 환경의 가장 큰 장점은 각 서버를 독립적으로 확장할 수 있다는 점입니다. 이는 마치 건물의 각 층을 독립적으로 리모델링할 수 있는 것과 같습니다.
OID/LDAP 서버 측면:
- 필요할 때 CPU나 메모리를 독립적으로 증설할 수 있습니다
- 사용자 인증 요청이 증가하면 서버를 추가할 수 있습니다
데이터베이스 서버 측면:
- 다른 서비스에 영향을 주지 않고 RAM을 증설할 수 있습니다
- 필요한 경우 Oracle RAC를 도입해 확장성을 높일 수 있습니다
네트워크 설계: 안정적인 성능의 기반
서버를 물리적으로 분리하면 네트워크가 시스템 성능의 핵심 요소가 됩니다. 마치 두 도시를 연결하는 고속도로처럼, OID와 데이터베이스 서버 사이의 네트워크 연결은 전체 시스템의 성능을 좌우하게 됩니다.
네트워크 대역폭과 지연 시간
대량의 인증 요청이나 검색 작업이 발생할 때는 OID와 데이터베이스 사이에 안정적이고 빠른 네트워크 연결이 필수적입니다. 실제 운영 환경에서는 다음과 같은 점들을 고려해야 합니다:
지연 시간(Latency) 관리:
- 두 서버 간 네트워크 지연은 1밀리초 이내로 유지하는 것이 이상적입니다
- 가능하다면 두 서버를 같은 데이터센터, 더 나아가 같은 네트워크 세그먼트에 배치하는 것이 좋습니다
- 네트워크 지연이 커지면 데이터베이스 연결이 마치 끊어진 것처럼 보일 수 있습니다
대역폭(Bandwidth) 요구사항:
- 평상시 트래픽의 최소 3배 이상의 여유 대역폭을 확보해야 합니다
- 피크 시간대의 동시 접속자 수를 기준으로 필요한 대역폭을 계산해야 합니다
- 대역폭 부족은 마치 좁은 병목구간처럼 전체 시스템 성능을 저하시킬 수 있습니다
실제 운영 환경에서의 주의사항
- 네트워크 모니터링:
- 정기적으로 네트워크 사용량과 지연 시간을 측정합니다
- 특히 피크 시간대의 네트워크 상태를 면밀히 관찰합니다
- 문제가 발생하기 전에 병목 현상을 미리 파악하고 대응합니다
- 네트워크 이중화:
- 중요한 연결은 항상 백업 경로를 준비해둡니다
- 장애 발생 시 자동으로 전환될 수 있도록 설정합니다
- 정기적으로 페일오버 테스트를 수행합니다
비용과 라이선스: 현실적인 의사결정의 기준
서버를 분리하면 성능은 개선되지만, 그만큼 비용도 증가합니다. 이는 마치 단독 주택과 아파트를 선택할 때처럼, 각각의 장단점을 면밀히 살펴봐야 하는 의사결정입니다.
Oracle 라이선스 고려사항
Oracle Database 라이선스는 CPU 코어 수를 기준으로 책정됩니다. 서버를 분리하면 다음과 같은 상황이 발생할 수 있습니다:
단일 서버 환경의 경우: 한 대의 서버에서 모든 것을 운영하므로 라이선스 비용이 상대적으로 적게 듭니다. 예를 들어, 16코어 서버 한 대면 충분할 수 있습니다. 하지만 이 경우 모든 작업이 하나의 서버에 집중되어 성능 저하가 발생할 수 있습니다.
분리 서버 환경의 경우: 데이터베이스 서버와 OID 서버를 분리하면 각각 8코어씩 필요할 수 있습니다. 결과적으로 전체 코어 수는 같지만, 두 대의 서버를 관리해야 하므로 운영 비용이 증가합니다. 반면 각 서버가 자신의 역할에 집중할 수 있어 성능은 더 좋아집니다.
인프라 비용의 현실적 검토
하드웨어와 운영 비용도 신중히 고려해야 합니다:
초기 구축 비용:
- 서버 하드웨어 추가 구매
- 네트워크 장비 증설
- 전원 및 냉각 시설 보강
지속적인 운영 비용:
- 전력 사용량 증가
- 서버실 공간 추가
- 관리 인력 보강 필요성
이러한 비용 증가가 성능 개선으로 인한 이점과 균형을 이루는지 검토해야 합니다. 예를 들어, 온라인 쇼핑몰의 경우 응답 시간이 1초만 개선되어도 매출이 크게 증가할 수 있습니다. 이런 경우에는 추가 비용을 감수하고서라도 서버를 분리하는 것이 합리적인 선택일 수 있습니다.
Quick Parameter Reference Table
아래는 주요 파라미터와 권장 값을 요약한 것입니다. 실제 구성은 동시성 수준, 가용 하드웨어, 실제 사용 패턴에 따라 달라질 수 있습니다.
| Layer | Key Parameters | Typical Starting Point | Notes |
|---|---|---|---|
| 데이터베이스 | processes, sessions, transactions | processes=500, sessions=750, transactions=825 | 동시성에 따라 조정. sessions는 processes의 1.5배, transactions는 sessions의 1.1배로 설정 |
| sga_target, db_cache_size, shared_pool_size | sga_target=24G, db_cache=16G, shared_pool=4G (on 32GB server) | DB가 별도 서버인 경우 조정. 단일 서버에서는 OS + WebLogic 메모리 사용량 주의 | |
| LDAP (OID) | orclmaxcc, orclserverprocs, orclldapconntimeout | orclmaxcc=10, orclserverprocs=8, conntimeout=60 | orclserverprocs는 CPU 코어 수에 맞추고, DB 동시성(processes/sessions)을 고려 |
| WebLogic | Thread Pool min/max, queue-size | min=50, max=400, queue-size=-1 | 피크 부하를 처리할 수 있는 충분한 스레드 확보; queue-size를 -1로 설정하면 대기열 크기에 제한이 없어져서 갑작스러운 부하 증가도 처리할 수 있으나 무제한 대기열은 시스템 리소스를 과도하게 사용할 수 있어 지속적인 모니터링이 반드시 필요함. |
| Work Manager constraints | e.g., | 중요 작업에 fair-share나 우선순위 클래스 사용 (예: 50) | |
| JVM | -Xms, -Xmx, -XX:+UseG1GC, -XX:MaxGCPauseMillis, etc. | -Xms=4G, -Xmx=8G, Pause=200ms (G1GC) | 힙 사용량과 GC 로그를 기반으로 조정 OID의 경우 Metaspace는 보통 256-512MB |
Tip: 보수적인 값으로 시작하세요. 지표(AWR, OEM, OS 로그)를 수집하면서 점진적으로 확장하는 것이 좋습니다. 실제 부하를 관찰한 후 파라미터를 조정하는 것이 최선의 방법입니다.
구현 전략 요약
지금까지 살펴본 내용을 바탕으로, OID 시스템의 최적화는 단순한 기술적 결정이 아닌 비즈니스적 판단도 필요한 복합적인 과제임을 알 수 있습니다. 성능 향상과 비용 효율성 사이에서 최적의 균형점을 찾는 것이 중요합니다.
메모리 공간의 전략적 계획, 효율적인 연결 구성, 그리고 현실적인 비용 검토를 통해 기업의 상황에 가장 적합한 구성을 선택할 수 있습니다. 중요한 것은 이러한 선택이 기업의 현재 요구사항뿐만 아니라 미래의 성장 가능성도 고려해야 한다는 점입니다.
이어지는 Part 3: WebLogic/JVM 최적화 가이드에서는 이러한 기반 위에서 애플리케이션 서버 계층의 성능을 한 단계 더 끌어올리는 방법을 자세히 살펴보겠습니다.
2 Comments