Data In Hands · Real Support Case Notes

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

서버 스펙이 아니라 인증 Provider 체인이 문제였던 케이스입니다. 핵심은 “weblogic 계정이 AD에 없는데도 AD Authenticator가 오래 잡고 있는 상황”을 fail-fast방식으로 처리하도록 적용하는 것입니다.

증상: 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에 없다는 걸 빨리 판단하고 다음 provider로 넘어가야 하는데, 그 과정이 느리면 admin 로그인만 유독 길어집니다.

DefaultAuthenticator Control Flag REQUIRED

왜 “weblogic”만 느려지나

원래 기대하는 흐름

weblogic 입력 → AD Authenticator가 “없음”을 빠르게 판단 → DefaultAuthenticator(embedded LDAP)로 넘어감 → 로그인 완료

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

오해 포인트

“AD에 없으면 바로 넘어갈 것”이라는 가정은, AD 응답이 빠르고 time limit이 정상일 때에만 맞습니다. 타임아웃이 0(무한)으로 되어 있거나 referral이 확장되면, 없는 사용자도 오래 기다릴 수 있습니다.

덤프에서 본 것

로그인 지연 타이밍에 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

왜 효과가 있었나

목표는 단순합니다. weblogic 계정은 AD에 없으니, AD Authenticator가 “없는 사용자”를 빠르게 포기하고 embedded LDAP로 넘어가도록 해야 합니다. 그래서 “시간 상한”과 “불필요한 확장”을 제한 했습니다.

Connect Timeout을 유한 값으로

Connect Timeout=0이면 연결 시도에 상한이 없을 수 있습니다. 문제 재현/개선 단계에서는 10~30초 같은 유한 값이 출발점입니다.

포인트

Connect는 “연결 성립”까지만입니다. 연결이 된 뒤 검색이 느리면 Results Time Limit가 필요합니다.
Results Time Limit(검색/응답)을 유한 값으로

Results Time Limit=0이면 검색이 끝없이 느려질 수 있습니다. 2000~5000ms부터 시작해 환경에 맞게 조정하는 방식이 현실적입니다.
Follow Referrals는 필요할 때만

referral로 인해 예상치 못한 endpoint로 조회가 확장되면 지연이 커지고, 원인 규명이 어려워집니다. 요구사항이 없다면 해제가 안전합니다.
Keep Alive는 보조

연결 재사용에 도움이 될 수 있습니다. 다만 “최악의 대기 시간 상한”을 만드는 건 time limit 쪽이 핵심입니다.
변경 후 재시작

provider 설정 변경은 재시작 후 일관성 있게 동작하는 경우가 많습니다. 운영에서는 반드시 변경 창/롤백 계획과 함께 진행하세요.

결과

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

DefaultAuthenticator REQUIRED를 SUFFICIENT로 바꿔야 하나?

권고

지연 해결만을 이유로 바꾸는 건 권장하지 않습니다.
weblogic 계정이 embedded LDAP에만 있다면, DefaultAuthenticator=REQUIRED는 보통 안전한 기본값입니다.

이 패턴에서 문제는 DefaultAuthenticator가 REQUIRED라서가 아니라, AD Authenticator가 “없음”을 늦게 결정하기 때문인 경우가 대부분입니다. 그래서 fail-fast(Connect/Results time limit + referral 통제)가 먼저입니다.

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

AD가 즉시 “없음”을 응답하면 빨리 넘어갑니다. 하지만 네트워크/검색/리퍼럴로 인해 응답이 지연되면, 설정된 상한(또는 무한)까지 기다릴 수 있습니다. 즉, 결국 체감 시간은 timeout/리퍼럴 설정이 좌우합니다.

검증

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

다음: 대시보드 오픈 지연

대시보드가 모든 사용자에서 계속 느리다면, 인증이 아니라 쿼리/DB 트랙입니다. Physical SQL을 특정하고 실행계획/대기 이벤트로 DBA와 협업하는 것이 가장 빠릅니다.

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

Related Posts