대규모 시스템 성능 최적화 리드/아키텍트 기술면접

먼저 애플리케이션 로그에서 슬로우 쿼리와 긴 트랜잭션을 식별하고, DB 세션 모니터링으로 대기 중인 커넥션 수와 활성 쿼리 수를 확인합니다. P99 지연이 높은 것은 일부 긴 트랜잭션이 커넥션을 오래 점유하여 다른 요청들이 대기하기 때문입니다. 적정 커넥션 풀 크기는 'connections = ((core_count * 2) + effective_spindle_count)' 공식을 기준으로 하되, 실제로는 평균 쿼리 실행시간과 TPS를 고려하여 'pool_size = TPS * average_query_time + buffer'로 계산합니다. 커넥션 타임아웃과 유휴 커넥션 제거 정책을 설정하고, 긴 트랜잭션은 별도 풀로 분리하거나 Read Replica로 라우팅합니다. HikariCP의 경우 leakDetectionThreshold를 설정하여 커넥션 누수를 탐지하고, maxLifetime을 DB의 wait_timeout보다 짧게 설정하여 끊긴 커넥션 사용을 방지합니다.

먼저 Heap Dump를 떠서 MAT나 VisualVM으로 메모리 누수와 큰 객체를 식별하고, GC 로그에서 Allocation Rate와 Promotion Rate를 분석합니다. Promotion Rate가 높다면 Young Generation 크기를 늘려(-XX:NewRatio 조정 또는 -Xmn 설정) 객체가 Young에서 충분히 정리되도록 합니다. G1GC의 경우 -XX:MaxGCPauseMillis를 200ms 정도로 설정하고, -XX:G1HeapRegionSize를 조정하여 큰 객체 처리를 최적화합니다. Old Generation으로 넘어가는 객체가 많다면 애플리케이션에서 불필요한 객체 생성을 줄이고, 특히 대용량 컬렉션이나 캐시를 Off-Heap 메모리로 이동하거나 외부 캐시(Redis)로 분리합니다. ZGC나 Shenandoah GC로 전환을 고려하여 pause time을 10ms 이하로 줄일 수 있으며, 이 경우 Heap을 더 크게 설정할 수 있습니다. 또한 String.intern() 남용, ThreadLocal 미정리, 정적 컬렉션 무한 증가 등 메모리 누수 패턴을 점검합니다.

먼저 애플리케이션 로컬 메모리에 Caffeine 같은 L1 캐시를 두고 Hot Key를 1~5초 정도의 짧은 TTL로 캐싱하여 Redis 요청 자체를 줄입니다. Redis는 L2 캐시로 사용하되, Hot Key는 Redis Cluster의 여러 노드에 복제하거나 Client-side sharding으로 읽기를 분산합니다. Cache Stampede 방지를 위해 Probabilistic Early Expiration 기법을 적용하여 TTL 만료 전에 확률적으로 미리 갱신하거나, 분산 락을 활용한 Single Flight 패턴으로 동일 키에 대한 DB 조회를 한 번만 수행하도록 합니다. 캐시 갱신은 Cache-Aside 패턴 대신 Refresh-Ahead 전략을 사용하여 만료 전에 백그라운드로 미리 갱신하고, Write-Through나 Write-Behind 패턴으로 쓰기 일관성을 보장합니다. Redis의 --hotkeys 옵션이나 CloudWatch 메트릭으로 Hot Key를 실시간 탐지하고, 애플리케이션에서 L1 캐시 히트율과 L2 캐시 히트율을 분리하여 모니터링합니다.