Oracle Analytics Server: OCI 마이그레이션 직후 로그인/대시보드가 느려졌을 때 빠른 진단 플로우

시스템 마이그레이션 직후에 “로그인도 느리고 대시보드도 느리다”는 의견이 들어오면, 대부분은 먼저 서버 스펙부터 의심합니다. 물론 리소스 이슈가 원인이 되는 케이스도 있지만, OCI로 옮긴 직후부터 지연 현상을 체감하는 빈도가 급격히 증가하는 유형은 실제로는 트래픽 경로(Load Balancer/WAF/OHS), 인증 경로(AD/LDAP), DB/네트워크 경로에서 생긴 기존 시스템과의 구성 차이가 체감 성능을 크게 좌우하는 경우가 적지 않습니다.

이 글의 목적은 정답을 제시하는 것이 아니라, 현장에서 시간을 가장 많이 잡아먹는 ‘원인 분류/분석 단계’를 좀 더 신속하게 진행하는데 도움을 주기 위해서 입니다. 느린 증상을 로그인 지연과 대시보드 로딩 지연으로 분리하고, 각 트랙에서 “최소한으로 확보해야 하는 증거”와 “우선순위”를 정리해두면, 백엔드 우회 테스트가 불가능한 환경에서도 진단 속도가 확실히 빨라집니다.

1) 증상 패턴 정리: 범위를 좁히는 “3문장”

현장에서는 “로그인이 느려요”, “대시보드가 느려요”와 같은 1줄 짜리 불만사항으로 시작합니다. 이때는 바로 로그 레벨을 올리거나, 서버를 재시작하거나, 인프라를 의심하기 전에 아래 3문장을 먼저 채우는 것이 가장 효율적입니다.

• When: 언제부터 느려졌는가? (OCI 마이그레이션 직후 / 이후 변경 이후)
• Who: 어떤 사용자군이 느린가? (전 사용자 / 특정 사용자군 / 특정 계정만)
• Where: 어디 구간이 느린가? (로그인 / 대시보드 로딩 / 둘 다)

이 3개가 정리되면, 원인 후보는 자연스럽게 확보됩니다. 예를 들어 “전 사용자, 로그인부터 느린” 것이라면 인증/세션 초기화/Front Door 경로가 상위로 올라오고, “로그인은 정상인데 특정 대시보드만 느림”이면 쿼리/DB 트랙으로 들어가야 합니다.

2) “우회 테스트 불가” 환경에서의 진단 전략

가장 깔끔한 진단은 “LB/WAF 우회 후 동일 테스트”입니다. 하지만 보안 정책상 우회가 불가능한 환경도 흔합니다. 이때 중요한 것은, 우회가 안 된다는 사실 자체가 “진단 불가”를 의미하지는 않는다는 점입니다. 우회가 불가하면 오히려 Front Door 구성(LB/WAF/OHS)이 원인 후보에서 더 위로 올라갑니다.

우회가 불가능한 환경에서는 다음 3개의 축으로 변수를 줄이면서 접근하는 것이 안전합니다.

1. Front Door 축: SSL 종료 위치, 타임아웃, Keep-Alive, 헤더 전달, 세션 지속성(Sticky) 등
2. 인증/미들웨어 축: Authentication Provider 체인 동작, LDAP/AD 연결·검색 지연 여부
3. 쿼리/DB 축: 대시보드가 느릴 때 Physical SQL과 DB 실행계획 중심으로 좁히기

A simplified OCI traffic path (e.g., Internet → OCI LB/WAF → OHS → OAS/WebLogic). Keeping this diagram aligned to your real deployment helps focus discussions on where time is being spent.

3) 수집/확인 항목: 최소 단위로 “증거”를 남기기

3-1. 패치 레벨 고정 (필수)

성능 이슈는 “비슷해 보이는 다른 문제”가 섞이기 쉽습니다. 특히 마이그레이션 직후에는 소프트웨어 레벨(패치/번들/PSU)과 구성 레벨(인증/네트워크/프록시)이 동시에 바뀌는 경우가 많습니다. 그래서 제일 먼저 OPatch inventory를 확보해 기준선을 고정해야 합니다.

cd $ORACLE_HOME/OPatch
./opatch version
./opatch lsinventory -detail > /tmp/opatch_lsinventory_detail_$(hostname)_$(date +%F).txt

이 파일은 단순 참고용이 아니라 “이후에 무엇을 바꿨는지”를 추적하는 기준점입니다. 예를 들어 타임아웃/Provider 설정을 바꾼 뒤 성능이 좋아졌다면, 그 변경이 패치 때문인지 설정 때문인지 분리할 수 있어야 합니다.

3-2. Front Door(LB/WAF/OHS)에서 자주 놓치는 포인트

OCI 마이그레이션에서 흔히 바뀌는 것 중 하나가 SSL termination(종료) 위치입니다. SSL이 LB에서 종료되면 백엔드로는 HTTP로 들어갈 수 있고, end-to-end SSL이면 OHS/WLS까지 TLS가 유지됩니다. 어떤 방식이든 정답은 없지만, 방식이 바뀌면 연결 재사용(Keep-Alive), Idle/Backend timeout, 헤더 처리에서 체감 성능 차이가 크게 날 수 있습니다.

• Timeout 체계: Client/Backend/Idle timeout이 서로 어떤 값으로 정렬되어 있는지 확인
• Keep-Alive: 연결이 매 요청마다 새로 만들어지면 로그인/대시보드 모두 체감 지연이 커질 수 있음
• Sticky session: 로그인 후 요청이 다른 노드로 분산되며 재인증/재세션이 반복되는지 확인
• Proxy 헤더: Host/X-Forwarded-*가 기대하는 형태로 전달되는지(환경 정책에 따라 차이가 큼)

3-3. 인증(AD/LDAP) 경로 점검: “단정 금지, 확인 우선”

로그인 시간이 길어졌다면 인증 단계에서 사용자/그룹 조회가 지연되는지 확인해야 합니다. 다만 스레드 덤프에서 LDAP 관련 스레드가 보인다는 사실만으로 “LDAP이 원인”이라고 단정할 수는 없습니다. 실제로는 LDAP 스레드가 정상적으로 대기 중이고, 문제는 다른 곳(Front Door, DB, 내부 캐시)일 수도 있습니다.

특히 LDAP 스레드가 아래 패턴으로 반복적으로 보이면 “응답을 기다리는 상태”일 수 있습니다. 다만 자바 스레드 상태가 RUNNABLE로 보이더라도, 네이티브 소켓 read에서 대기하는 패턴(예: socketRead0)은 실질적으로 응답 대기인 경우가 많습니다. 중요한 것은 “그 대기가 실제로 로그인 처리 스레드를 블록시키는지”를 연결하는 것입니다.

- java.net.SocketInputStream.socketRead0
- java.io.BufferedInputStream.read / fill
- netscape.ldap.ber.stream.BERElement.getElement
- netscape.ldap.LDAPConnThread.run

PID=<bi_server1_pid>
jcmd $PID Thread.print > /tmp/bi_server1_td_1.txt
sleep 10
jcmd $PID Thread.print > /tmp/bi_server1_td_2.txt
sleep 10
jcmd $PID Thread.print > /tmp/bi_server1_td_3.txt

4) 대시보드 로딩 지연: 쿼리/DB 트랙으로 전환하는 기준

로그인 자체는 정상인데 대시보드 로딩이 느리다면, 이제는 “인증”이 아니라 “쿼리/DB” 트랙으로 전환해야 합니다. 이 단계에서 흔히 하는 실수는, 계속 WebLogic/Front Door에서만 원인을 찾는 것입니다. 대시보드 지연은 결국 어떤 Physical SQL이 얼마나 오래 걸리는지로 좁혀져야 합니다.

실무적으로는 다음 3단계를 추천합니다.

1. 문제가 되는 대시보드에서 “느린 구간”을 재현하고, 해당 시점에 어떤 쿼리가 실행되는지 식별
2. 식별된 Physical SQL을 DB에서 직접 확인하고, 실행계획/대기 이벤트/인덱스 사용 여부를 점검
3. On-Prem 대비 OCI에서만 느리면, DB 위치/네트워크 경로/세션 설정(예: NLS, optimizer 환경) 차이도 같이 비교

5) 정리: 다음 단계 체크리스트(최소 단위)