Data In Hands
OAS 인증 지연 — AD 사용자 · weblogic 비교 주제를 표현한 개념 그림
Data In Hands · Real Support Case Notes

How To: AD 사용자는 빠른데 “weblogic”만 2분 이상 로그인 느릴 때

이 사례에서는 서버 자원보다 인증 Provider 체인의 조회 지연을 조사했습니다. AD에 없는 weblogic 계정을 조회하는 동안 어디에서 시간이 걸리는지 확인하고, 연결·검색 제한과 리퍼럴 동작을 점검했습니다. 다음 Provider의 호출과 최종 로그인 성공 여부는 Provider 순서와 JAAS Control Flag도 함께 봐야 합니다.

증상: weblogic만 느림 구성: AD + Embedded LDAP 해결: 타임아웃 + 리퍼럴 목표: 예측 가능한 로그인 시간
무슨 일이었나 환경/인증 구조 왜 느려지나 덤프에서 본 것 어떻게 바꿨나 DefaultAuthenticator REQUIRED는? 검증 다음(대시보드)
무슨 일이었나

처음엔 전형적인 “성능 이슈”처럼 들렸습니다. OCI로 옮긴 뒤 로그인도 느리고 화면도 느리다는 피드백이었죠. 그런데 로그인에 걸린 시간을 측정해보면, 재미있는 패턴이 바로 나옵니다.

핵심 패턴

AD 사용자는 온프레미스와 비슷하게 빠르게 로그인합니다.
그런데 weblogic(관리자 계정)만 2분 이상 느립니다. 그리고 이건 WebLogic Console / Analytics 로그인 모두 동일합니다.

참고: 대시보드 오픈 지연은 모든 사용자에서 느릴 수 있고(쿼리/DB 트랙), 이 글과는 분리했습니다.

환경/인증 구조
  • 일반 사용자: Microsoft AD에서 관리
  • weblogic: embedded LDAP(DefaultAuthenticator)에만 존재
  • Security Realm: ADAuthenticator + DefaultAuthenticator 구성

weblogic 계정이 AD에 없다는 사실 자체가 장애는 아닙니다. AD 조회가 지연되면 로컬 계정의 로그인도 늦어질 수 있습니다.
다만 DefaultAuthenticator로 이어지는지와 최종 인증 결과는 Provider 순서와 각 JAAS Control Flag에 따라 달라집니다.

Authentication Providers list
Providers → Authentication에 구성된 서비스 목록 (예: ADAuthenticator, DefaultAuthenticator 등).
DefaultAuthenticator Control Flag REQUIRED
DefaultAuthenticator Control Flag가 REQUIRED인 화면 예시. 다른 Provider의 순서·Control Flag와 함께 인증 성공 조건을 확인해야 합니다.
ADAuthenticator before tuning
ADAuthenticator 변경 전 예시(Connect Timeout/Results Time Limit이 0이면 사실상 상한이 없을 수 있음).
ADAuthenticator after tuning
ADAuthenticator 변경 후 예시(Connect Timeout, Results Time Limit, Referrals, Keep Alive 등).
왜 “weblogic”만 느려지나

Provider는 로그인을 확인하는 인증 구성 요소입니다. 이 사례에서는 빠른 계정과 느린 계정이 어떤 Provider를 거치는지 나누어 살펴봐야 합니다.

원래 기대하는 흐름

이 사례에서 확인할 흐름: weblogic 입력 → AD 조회 결과 확인 → Provider 순서와 JAAS Control Flag에 따라 DefaultAuthenticator 인증 진행 → 전체 인증 결과 확인

그런데 AD Authenticator가 (연결/검색/리퍼럴) 단계에서 오래 기다리면, “없음” 판단이 늦어지고 결국 그 지연 시간이 곧 로그인 지연으로 체감됩니다.

오해 포인트

사용자가 AD에 없으면 곧바로 다음 Provider로 넘어간다고 가정하지 마세요. 조회 응답 시간뿐 아니라 Provider 순서와 JAAS Control Flag를 확인해야 합니다. 연결 제한과 검색 결과 제한이 설정돼 있는지, 리퍼럴로 조회 범위가 늘어나는지도 각각 점검합니다.

덤프에서 본 것

로그인 지연 타이밍에 LDAPConnThread가 여러 개 보이고, socketRead0 패턴이 반복되었습니다. 자바 스레드 상태가 RUNNABLE이라도 네이티브 I/O 대기일 수 있습니다.

text LDAP socket read wait pattern 
java.net.SocketInputStream.socketRead0
java.io.BufferedInputStream.read / fill
netscape.ldap.ber.stream.BERElement.getElement
netscape.ldap.LDAPConnThread.run
중요: 여기서 단정하지 않기

LDAP 대기 스레드가 보인다는 것만으로 “LDAP이 원인”이라고 확정하지 않습니다. 핵심은 로그인 요청 스레드(ExecuteThread)가 LDAP 호출 때문에 실제로 막히는지를 연결하는 것입니다.

bash Thread dumps (3x) 
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
왜 효과가 있었나

AD 조회에 걸리는 시간과 필요한 조회 범위를 구분해 확인했습니다. 연결 제한, 검색 결과 제한, 리퍼럴 동작은 서로 다른 항목입니다. 조회 지연을 줄이더라도 Provider의 호출 순서나 인증 성공 조건이 자동으로 바뀌는 것은 아닙니다.

  1. Connect Timeout을 유한 값으로

    Connect Timeout은 LDAP 연결을 맺는 시간의 제한이며 단위는 초입니다. 0은 연결 타임아웃 제한이 없는 설정입니다. 기존 예시의 10~30초는 범용 권장값이 아니므로 정상 연결 시간과 장애 대응 기준을 측정한 뒤 환경에 맞게 정합니다.

    포인트

    Connect는 “연결 성립”까지만입니다. 연결이 된 뒤 검색이 느리면 Results Time Limit가 필요합니다.

  2. Results Time Limit(검색/응답)을 유한 값으로

    Results Time Limit은 LDAP 검색 결과를 기다리는 시간의 제한이며 단위는 밀리초입니다. 기존 예시의 2000~5000ms를 그대로 적용하지 말고 정상 조회 시간, 그룹 규모와 해당 WebLogic 버전의 동작을 확인합니다. 이 설정만으로 전체 로그인 시간이나 모든 소켓 대기의 상한이 보장되지는 않습니다.

  3. Follow Referrals는 필요할 때만

    리퍼럴이 다른 LDAP 서버로 조회를 이어가는지 확인합니다. 다른 도메인이나 디렉토리를 조회해야 하는 인증 구성이라면 필요한 기능일 수 있습니다. 지연을 줄이려는 이유만으로 끄지 말고 조회 대상, 접근 권한과 인증 요구사항을 먼저 확인합니다.

  4. Keep Alive는 보조

    Keep Alive는 연결 재사용과 관련된 항목입니다. 연결 재사용 여부와 연결·검색·소켓 대기 제한은 구분해서 확인하세요. 하나의 설정만으로 최악의 로그인 시간을 보장할 수는 없습니다.

  5. 변경 후 재시작

    변경한 항목이 즉시 반영되는지, 재시작이 필요한지는 해당 WebLogic 버전의 문서와 관리 화면에서 확인합니다. 재시작이 필요하다면 변경 창, 영향 범위와 롤백 절차를 준비하고 적용 전후 로그인 시간을 비교합니다.

결과

weblogic 로그인 시간이 “분 단위”에서 “예측 가능한 짧은 시간(수십 초 수준)”으로 줄었습니다. AD 사용자 로그인 속도는 그대로 유지되었습니다.

DefaultAuthenticator REQUIRED를 SUFFICIENT로 바꿔야 하나?
권고

로그인 지연만을 이유로 REQUIRED를 SUFFICIENT로 바꾸지 마세요. REQUIRED는 해당 Provider의 인증 성공이 필요하다는 뜻입니다. AD 사용자와 로컬 사용자를 함께 인증한다면 Provider 순서와 각 Control Flag의 조합을 기준으로 두 사용자군의 성공·실패 조건을 검토해야 합니다. 로컬 계정이 존재한다는 이유만으로 REQUIRED를 보편적인 안전값으로 볼 수는 없습니다.

조회 지연과 인증 정책은 별도로 확인합니다. AD 조회에 시간이 걸리는지 측정하고, 각 Provider의 성공·실패가 전체 인증 결과에 어떻게 반영되는지 점검합니다. 전체 구성과 증거 없이 특정 Control Flag나 타임아웃을 원인으로 단정하지 않습니다.

“없으면 바로 넘어가나?”

AD가 사용자 없음 결과를 빨리 반환해도 이후 흐름은 Provider 순서와 JAAS Control Flag에 따라 달라집니다. 응답이 늦다면 연결, 검색, 리퍼럴과 소켓 대기를 나눠 확인하세요. 실제 로그인 시간은 이들 단계의 측정값으로 비교합니다.

검증
  • weblogic으로 WebLogic Console 로그인 시간 3회 측정
  • weblogic으로 Analytics sign-in 시간 3회 측정
  • AD 사용자 로그인 속도 회귀 여부 확인
  • 여전히 느리면: 덤프 재수집 후 request thread ↔ LDAP 대기 연결 확인
다음: 대시보드 오픈 지연

로그인이 정상인데 대시보드가 계속 느리다면 별도 구간으로 조사합니다. Physical SQL과 실행계획·DB 대기 이벤트를 DBA와 함께 확인하고, 쿼리 시간으로 지연이 설명되지 않으면 결과 전달·네트워크·서버 처리와 화면 렌더링도 확인합니다.

위로 스크롤