Data In Hands

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

Oracle Analytics Server — 로그인·대시보드 지연 진단 주제를 표현한 개념 그림

OCI로 옮긴 뒤 로그인이나 대시보드가 느려졌다면 서버 자원과 함께 이전 환경과 달라진 구성을 확인해야 합니다. 트래픽 경로(LB/WAF/OHS), 인증 경로(AD/LDAP), DB·네트워크 경로를 나눠 보고, 각 구간의 측정값으로 원인 후보를 좁힙니다.


이 글은 마이그레이션 후 지연을 조사할 때 사용할 진단 순서를 정리합니다. 로그인 지연과 대시보드 로딩 지연을 따로 측정하고, 각 단계에서 필요한 로그와 설정 정보를 모읍니다. 백엔드 우회 테스트가 허용되지 않는 환경에서도 확인할 수 있는 항목을 중심으로 설명합니다.


요약 먼저 “언제부터 / 누구에게 / 어디에서”를 분리하면, 불필요한 추측을 줄이고 다음에 확인할 항목을 정할 수 있습니다.
  • 언제부터: 마이그레이션 직후부터인지, 이후 특정 변경(인증/네트워크/패치) 시점 이후인지
  • 누구에게: 전 사용자 / 특정 사용자군(관리자만, 외부 사용자만) / 특정 대시보드 사용자만
  • 어디에서: 로그인 단계 / 대시보드 로딩(쿼리 수행) 단계 / 둘 다

진단 관점“느림”을 두 개의 이슈로 나눠야 하는 이유

로그인 지연과 대시보드 지연은 같은 원인에서 발생할 수도, 서로 다른 원인에서 발생할 수도 있습니다. 우선 두 구간의 소요 시간을 따로 기록하세요. 이렇게 해야 인증 담당자, 네트워크 담당자, DBA에게 어떤 증거를 요청할지 정할 수 있습니다.


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

“로그인이 느리다”는 제보만으로는 조사 범위를 정하기 어렵습니다. 로그 수준을 높이거나 서비스를 재시작하기 전에 발생 시점, 영향을 받는 사용자, 지연 구간을 먼저 확인합니다.

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

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


구분 On-Prem(이전) OCI(이후) 의미(우선순위)
로그인 시간 예: 5~10초 예: 30초~수 분 인증/세션 초기화/Front Door(LB/WAF/OHS) 후보 상승
대시보드 로딩 예: 수 초 예: 수십 초~수 분 DB/쿼리/네트워크/커넥션풀/캐시 후보 추가
영향 범위 — 전 사용자 / 일부 / 특정 대시보드 “공통 구성요소” vs “특정 리소스” 구분
발생 시점 — OCI 이동 직후 마이그레이션 과정에서 달라진 설정(SSL/네트워크/인증)이 핵심 단서

현장 팁시간 측정은 “대충” 하지 말고 최소 2가지로 남깁니다
  • 사용자 체감: 스톱워치로 “로그인 버튼 클릭 ~ 화면 전환 완료” 시간을 3회 측정
  • 서버 관점: 같은 시각대의 서버 로그 타임스탬프/ECID 기반으로 상관 분석 가능하게 남김

숫자(초)가 있어야 “개선 전/후”가 객관화되고, 변경(타임아웃/캐시/Provider 설정)의 효과도 명확해집니다.


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

보안 정책상 허용된 우회 비교 테스트는 경로별 영향을 구분하는 데 도움이 될 수 있습니다. 우회가 허용되지 않으면 기존 경로의 요청 시간과 로그를 대조합니다. 우회 테스트를 할 수 없다는 사실만으로 LB/WAF/OHS가 원인일 가능성이 높아지는 것은 아닙니다.

아래 세 경로에서 같은 요청의 시각과 지연 구간을 비교합니다.

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

OCI traffic flow for Oracle Analytics Server: Internet → OCI LB/WAF → OHS → OAS/WebLogic
OCI 트래픽 경로를 단순화한 예시입니다(Internet → OCI LB/WAF → OHS → OAS/WebLogic). 실제 배포 경로와 대조하면서 어느 구간에서 시간이 걸리는지 확인하세요.

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

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

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


bash OPatch basic 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-*가 기대하는 형태로 전달되는지(환경 정책에 따라 차이가 큼)

설명전 사용자에게 나타나는 지연: 공통 경로를 함께 점검하기

전 사용자에게 같은 증상이 나타나면 공통 트래픽 경로, 인증 서비스, DB·네트워크를 함께 조사합니다. 특정 사용자나 대시보드에만 나타나면 해당 계정과 쿼리도 확인합니다. 점검 순서는 우회 가능 여부가 아니라 측정된 지연과 변경 이력을 기준으로 정합니다.


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

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


확인 순서인증 트랙에서는 아래 순서가 안전합니다
  1. Authentication Provider 체인을 확인하고, 실제 로그인 시 어떤 Provider가 호출되는지 파악
  2. 덤프에 보이는 endpoint가 “의도된 대상”인지 식별(의도치 않은 라우팅/Referral 가능성은 ‘확인 대상’)
  3. Timeout을 Connect뿐 아니라 LDAP search/read(응답) 관점에서도 확인(존재 여부/설정값)
  4. Follow Referrals 사용 여부 점검(필요 시에만), 불필요한 endpoint 확장 여부 확인

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


text Common LDAP socket read wait pattern (example) 
- java.net.SocketInputStream.socketRead0
- java.io.BufferedInputStream.read / fill
- netscape.ldap.ber.stream.BERElement.getElement
- netscape.ldap.LDAPConnThread.run

핵심“LDAP 스레드 존재”가 아니라 “Business thread block”를 연결해야 합니다

같은 시각의 로그인 요청을 처리한 ExecuteThread(또는 요청 스레드) 스택을 함께 확보하세요. LDAP 관련 스레드의 대기 상태와 실제 로그인 요청의 지연이 연결되는지 확인한 뒤, 관련 로그를 네트워크·AD·LDAP 담당자와 공유합니다.


bash Thread dump (repeat 3x with 5–10s interval) 
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 트랙으로 전환하는 기준

로그인은 정상인데 대시보드가 느리다면 Physical SQL의 실행 시간과 DB 대기 이벤트를 먼저 확인합니다. 쿼리에서 지연이 설명되지 않으면 결과 전달, 네트워크, 서버 처리와 화면 렌더링도 조사합니다. 로그인 단계와 같은 원인이라고 미리 단정하지 않습니다.


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

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

주의로그인 지연과 대시보드 지연을 ‘하나의 원인’으로 묶지 마세요

로그인 지연이 해결되어도 대시보드가 느릴 수 있고, 반대로 대시보드 쿼리를 튜닝해도 로그인 지연은 남을 수 있습니다. 그래서 이 글에서도 두 구간을 명확히 분리해 “각각의 증거”로 접근하는 것을 권장합니다.


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

Checklist조사 결과와 함께 남길 체크리스트
  • 기준선: OPatch inventory 확보로 패치/버전 기준선 고정
  • 분리: 로그인 vs 대시보드, 전 사용자 vs 특정 사용자군/대시보드로 범위 확정
  • Front Door: 타임아웃/keep-alive/sticky/헤더 전달 점검
  • 인증: Provider 체인 + endpoint 식별 + (connect/read/search) timeout 존재 여부/값 점검 + referral 동작 확인
  • 쿼리: 대시보드 지연은 Physical SQL + DB 실행계획 기반으로 전환
위로 스크롤