- 문제 인식
- Airbridge 인증 서버에서 간헐적인 응답 지연 발생.
- API 요청 전 인증/인가를 수행하므로, 인증 서버의 지연은 전체 서비스 안정성에 직접 영향.
- 모니터링 결과, 1초 이상 응답 지연 알림이 점점 잦아짐 → 원인 분석 및 최적화 작업 착수.
- 원인 분석
- (1) 과도한 DB Query: 권한 확인 과정에서 요청마다 DB Query가 과다하게 발생, 이로 인해 DB Connection Pool이 빠르게 소진 → 응답 지연 발생.
- (2) HikariCP Connection Pool 포화: DB Query 과다 실행 시 HikariCP 풀 포화 → 30초 이상 스레드 대기 현상 확인.
- (3) 낮은 캐시 효율성: TTL을 30초로 짧게 설정 + 비효율적 캐싱 로직 → DB Query 재발 가능성 높음.
- 개선 전략
- (1) 권한 확인 및 캐싱 구조 개선
- DB 일괄 조회(findAllBy~) 방식 도입 → DB Query 134회 → 4회(-97%) 감소.
- 애플리케이션 메모리 기반 mutableMap 캐싱 적용.
- 단일 책임 원칙(SRP) 적용 → 메서드 분리 및 하위 로직별 캐싱 전략 설정.
- (2) 2-Layer Cache 구조 도입
- Local Cache(Caffeine, L1) + Remote Cache(Redis, L2) 혼합 구조 적용.
- 캐시 전략을 L1-Only, L2-Only, Hybrid로 세분화하여 운영 효율성 개선.
- 캐시 메모리 사용량 분석 → Redis 키 50만 개 예상, 메모리 요구량 약 190MB, 안전 버퍼 확보.
- (3) Redis Pub/Sub 기반 캐시 무효화
- TTL 의존에서 벗어나 권한 정보 변경 시 실시간 캐시 동기화.
- 한 서버에서 변경 시, Redis 채널을 통해 모든 서버의 Local Cache를 동기 무효화.
- (4) HikariCP 커넥션 풀 튜닝
- maximum-pool-size 10 → 30으로 확장.
- Connection Timeout, Idle Timeout, Max Lifetime 등 세부 옵션 최적화 → DB I/O 경합 완화.
- 성능 테스트 및 결과: 대규모 트래픽에서도 안정적 성능 유지.
- 운영 환경 개선 효과
- 배포 후 응답 지연 알림 사라짐, 전체 응답 시간 안정화.
- 서비스 신뢰성과 운영 안정성 크게 향상.
- 추가 최적화: JVM Warm-Up
- 배포 직후 JIT 컴파일 지연으로 인한 초기 요청 응답 지연 문제 발견.
- Warm-Up Runner 도입:
- 애플리케이션 시작 시 더미 요청을 미리 실행.
- K8s Pod 교체 시 JIT 완료 후 트래픽 처리 → 초기 응답 시간 1.07s → 94ms로 단축.
- 결론 및 효과
- 응답 지연 문제 해결 + 트래픽 급증 대응 구조 확보.
- Airbridge 전반 서비스 안정성 및 신뢰도 향상.
- 인증 서버 활용도를 높여 도메인 서비스 개발 생산성 향상.