안녕하세요, 이유 있는 코드를 짜는 개발자 천명현입니다.

유지 보수 비용이 낮은 코드와 장애 내결함성이 있는 백엔드를 구축하는것에 관심이 많습니다.

+회사별 JD에 따라 소개말 추가

• 공군 전체가 사용하는 인트라넷 서비스 신규 개발 및 유지보수 업무 수행

• B2B 프레임워크 어드민 백엔드 개발

• 얼굴 기반 OTP 인증 서버 POC 개발

GPA 4.19

Issue1. 운영 시나리오에서 웹소켓 동시 연결 병목 발견

문제상황

• 10만 MAU 시나리오에서 웹소켓 부하 테스트를 진행 후 ~5000 커넥션에서 Out Of Memory 발생

• Heap 메모리 할당량(3GB)에 비해 과도한 메모리 소모인것으로 판단 후 문제 해결 과정 수행

• Spike 상황에서 Fanout Timing이 비대해지는 현상을 확인함 (p99 > 20sec.)

해결 방법

[Tail Latency 현상 해결]

• K6를 통해 부하 테스트 수행 중 어플리케이션 힙을 덤프하여 메모리 분석 수행

• Virtual Thread Pool을 도입하여 Fanout을 병렬 수행하면서도 Context Switch Price를 최적화.

• 세션별 Inbound Task Queue를 도입하여 세션별 메세지 전송 순서 보장.

[OOM 현상 해결]

• Websocket Listener 서비스를 외부로 분리하여 성능 요구치에 따라 Scale-Out 가능하도록 변경

• Redis Pubsub을 사용하여 API Server와 통신하여 실시간 가격 정보 수신

• Docker Compose의 --scale 옵션을 활용하여 목표치에 맞게 배포 가능하도록 설정

적용 성과

• 동일 시나리오에서 Fanout Timing p55 / p99 모두 1초 이내로 감소

• tail latency 를 최적화 하여 고부하 상황에서 사용자 경험 유지

• 시나리오 목표치였던 2만 커넥션 동시 연결을 성공

Issue2. 유저 PK의 타입이 UUID일 경우의 성능 병목 개선

문제 상황

• K6및 Micrometer를 사용해 API별 성능 프로파일링 결과 유저와 관련된 쿼리에 병목을 확인

• 사용자 PK는 예측 불가성을 위해 UUID로 초기에 고려되었음

• 하지만 랜덤성이 큰 UUID PK가 B+ Tree 구조에서 다음과 같은 문제를 발생시킬 것으로 판단

  • 페이지 locality 저하

  • 인덱스 비대화

  • page split 가능성 증가

해결 방법

• 유저 PK를 명목상 PK(UUID)와 실질적 PK(BIG INT)로 분리

• 내부 Querying 에선 실질 PK를 사용하고, 외부 노출 용으로는 명목상 PK를 사용

• 명목상 PK와 실질적 PK의 매핑은 캐싱을 도입하여 탐색 비용을 최적화

적용 성과

• 동일 시나리오 기준 인덱스 및 테이블 크기 최대 20% 이상 감소

• Insert workload 기준 평균 약 5% 성능 개선

• Clustered Index 기반에서 page 접근 수 약 33% 감소 → range 조회 효율 개선

• 일부 Join 쿼리에서 최대 30% 이상 latency 감소

• 내부 PK(Long) / 외부 노출(UUID) 분리 구조를 통해 보안성 유지 + DB 성능 최적화 동시 달성

AI 컨텐츠 생성 일기장 플랫폼

Issue1. 생성형 모델 서빙 시 대기열 장기화 문제

문제 상황

해결 방법

적용 성과

Issue2.