Case Studies (실무)
회사 업무에서 해결한 케이스 스터디입니다.
실무 맥락의 문제-해결-결과를 케이스별로 빠르게 확인할 수 있습니다.
Case
정산 시즌 조회 p99 20s → 500ms (실행계획 + LATERAL JOIN)
- • 정산 시즌 조회 성능 병목을 MySQL 실행계획으로 규명
- • subquery join 병목 제거, LATERAL JOIN 중심으로 쿼리 개선
- • Datadog으로 p99 500ms까지 안정화 확인
Context: 정산 시즌 조회 API가 p99 20초까지 증가하며 업무 지연 발생
Approach: 실행계획 분석 → 병목 구간 격리 → LATERAL JOIN/쿼리 개선
Case
워크스페이스 문서 조회 22s → 300ms
- • 문서 조회가 22초까지 지연되는 병목 발생
- • 인덱스/쿼리 최적화로 응답 300ms 달성
- • heavy hitter 구조 한계를 진단하고 개선 방향 제안
Context: 워크스페이스 문서 조회가 장시간 지연되어 업무 흐름에 영향
Approach: 인덱스 재구성 + 쿼리 최적화, heavy hitter 구조 진단
Case
고QPS 조회 API Redis 캐시 도입기
- • 고QPS 조회 API에 Redis Cache-aside를 도입해 DB 부하를 완화 시도
- • PK 리스트 캐시 + Outbox/SQS invalidation 자동화를 적용
- • DB CPU 상승으로 무효화 자동화를 축소하고 TTL 15분 + Jitter로 전환
Context: 1시간 약 4,000회 호출되는 조회 API에서 heavy query로 DB CPU 압박이 지속
Approach: PK 캐싱 + Outbox/SQS 무효화 자동화 적용 후 운영 지표 기반으로 단계적 축소
Case
DFS 조직도 전수 탐색 2GB OOM → 방문 체크 + 요구 범위 축소로 60MB
- • 자산 목록 조회 중 JVM OutOfMemoryError가 간헐적으로 발생
- • 전수 조직도 탐색/적재 구조를 방문 체크 + 필요 범위 탐색으로 재설계
- • 메서드 1회 메모리 사용량을 2GB에서 60MB로 축소
Context: 자산 조회 권한 계산을 위해 하위 조직/직원 탐색 시 메모리 폭증으로 장애 발생
Approach: DFS 탐색에 visited 체크 추가 + 전체 조직도 구성 제거(요구 범위만 탐색)
Case
Kubernetes MSA에서 @Scheduled 배치 3중 실행 사고와 재발 방지
- • 일반 서비스에서 @Scheduled 배치를 운영해 인스턴스 수만큼 중복 실행 위험 발생
- • 3개 Pod 환경에서 동일 배치가 실제 3회 실행된 사실 확인
- • 배치를 전용 배치 서버로 이관하고 재발 방지 원칙(락·멱등성·관측성) 정리
Context: Kubernetes MSA 환경에서 @Scheduled 배치가 인스턴스 단위로 실행되어 중복 실행 사고 발생
Approach: 실행 로그 기반 영향 확인 및 사후조치 후 배치 워크로드 분리/이관
Case
로컬 테스트 자동화 + JaCoCo 도입으로 커버리지 30%대 → 70%대 개선
- • 로컬 테스트 실행 경로를 단일 스크립트로 표준화
- • JaCoCo로 커버리지를 수치화/시각화해 개선 루프를 정착
- • Service 레이어 테스트 커버리지를 30%대에서 70%대로 끌어올림
Context: 배포 시점 중심 테스트 문화로 인해 회귀 대응과 커버리지 관리가 어려운 상태
Approach: 로컬 자동화 엔트리포인트 구축 + JaCoCo 리포트 기반 우선순위 테스트 보강
Case
운영 장애 처리: 진상규명보다 복구 우선 원칙
- • 장애 시 1차 목표를 원인 규명이 아닌 서비스 복구/안정화로 명확화
- • Stabilize → Restore → Learn의 3단계 대응 흐름으로 정리
- • 포스트모템을 통해 근본 원인 분석과 재발 방지 액션까지 연결
Context: 운영 장애에서 진상규명에 매몰되면 복구가 지연되어 고객 영향이 누적되는 문제
Approach: 복구 가능한 단서 중심 가설-검증 루프와 단계별 대응/사후 학습 체계화
Case
변경 회차 기반 이력 모델링: from/to 구간으로 Point-in-Time 조회 최적화
- • from/to(유효 구간) 기반으로 point-in-time 조회 조건을 단순화
- • point >= valid_from AND point < valid_to 패턴으로 조회 경로 명확화
- • PoC로 실행계획과 조회 패턴 단순화 효과를 검증
Context: 특정 변경 회차와 특정 시점 기준 상태를 반복 조회해야 하는 이력성 도메인
Approach: valid_from/valid_to 구간 모델링 + 회차/엔티티 중심 인덱스 설계로 조회 최적화