Spring 리드·아키텍트 CS 기초 면접
새 면접Q. 대규모 Spring 기반 API 서버에서 TCP 연결 고갈 문제가 발생했습니다. TIME_WAIT 상태의 소켓이 수만 개 쌓여 있고, 새로운 클라이언트 연결이 거부되는 상황입니다. TCP 연결의 4-way handshake 과정에서 TIME_WAIT 상태가 왜 필요한지 설명하고, SO_REUSEADDR, SO_LINGER, tcp_tw_reuse, tcp_fin_timeout 같은 커널 파라미터의 동작 원리와 각각의 리스크를 분석해주세요. 또한 Connection Pool 크기, Keep-Alive 설정, 그리고 로드밸런서의 Connection Draining과의 관계를 고려한 종합적인 해결 전략을 제시해주세요.
TIME_WAIT는 지연된 패킷 처리와 연결 종료 확인을 위해 존재하며, 각 커널 파라미터는 서로 다른 트레이드오프를 가집니다.
TIME_WAIT는 TCP 연결 종료 시 마지막 ACK가 손실될 경우 상대방의 FIN 재전송을 처리하고, 네트워크에 남아있는 지연 패킷이 새 연결과 혼동되는 것을 방지하기 위해 2MSL(Maximum Segment Lifetime) 동안 유지됩니다. SO_REUSEADDR은 바인딩 주소 재사용을 허용하지만 서버 측에서만 안전하며, SO_LINGER는 close() 시 남은 데이터 전송 대기 시간을 제어하지만 0으로 설정 시 RST로 강제 종료되어 데이터 손실 위험이 있습니다. tcp_tw_reuse는 타임스탬프 옵션을 활용해 outbound 연결에서 TIME_WAIT 소켓 재사용을 허용하지만 NAT 환경에서는 문제가 발생할 수 있고, tcp_fin_timeout 단축은 비정상 종료 위험을 증가시킵니다. 근본적 해결을 위해서는 Connection Pool의 maxTotal과 maxIdle을 적절히 설정하고, HTTP Keep-Alive로 연결 재사용을 활성화하며, 로드밸런서에서 Connection Draining으로 graceful shutdown을 보장하고, 애플리케이션이 능동적으로 연결을 종료(active close)하지 않도록 설계해 TIME_WAIT가 클라이언트 측에 발생하도록 해야 합니다. 또한 ephemeral port 범위를 확장(net.ipv4.ip_local_port_range)하고, 모니터링을 통해 연결 수명주기를 지속적으로 관찰해야 합니다.
- • TIME_WAIT의 존재 이유: 지연 패킷 처리와 FIN 재전송 대응
- • 커널 파라미터별 동작 원리와 리스크 이해
- • Connection Pool과 Keep-Alive를 통한 연결 재사용
- • Active close를 서버가 아닌 클라이언트에서 수행하도록 설계
- • 로드밸런서 Connection Draining과의 통합 고려
대규모 트래픽을 처리하는 API 게이트웨이나 프록시 서버에서 TIME_WAIT 소켓 고갈로 인한 서비스 장애를 예방하고 해결할 때 필요한 지식입니다.
NAT 환경에서 tcp_tw_reuse를 활성화했을 때 발생할 수 있는 문제와 그 원리를 설명해주세요.
Q. Spring 애플리케이션이 배포된 Linux 서버에서 CPU 사용률은 30%인데 평균 응답 시간이 5초를 넘는 성능 저하가 발생했습니다. top 명령어로 확인했을 때 load average가 50을 넘고 있습니다. CPU 사용률과 load average의 차이를 설명하고, load average가 높은 원인(CPU-bound, I/O-bound, 과도한 컨텍스트 스위칭)을 진단하는 방법을 제시해주세요. 특히 vmstat, iostat, sar 같은 도구를 활용해 디스크 I/O 대기(iowait), 네트워크 I/O, 그리고 메모리 스와핑을 구분하여 분석하는 절차와, 각 원인별로 애플리케이션 레벨과 인프라 레벨에서 취할 수 있는 최적화 방안을 설명해주세요.
load average는 실행 대기 중인 프로세스 수를 포함하므로 CPU 사용률과 다르며, I/O 대기 상태도 포함됩니다.
CPU 사용률은 CPU가 실제로 연산을 수행한 시간의 비율이고, load average는 실행 가능(runnable) 상태와 I/O 대기(uninterruptible sleep) 상태에 있는 프로세스의 평균 개수로, CPU 코어 수 대비 load average가 높으면 대기 중인 작업이 많다는 의미입니다. 먼저 vmstat 1로 r(실행 대기 프로세스)과 b(I/O 대기 프로세스), wa(iowait) 컬럼을 확인하여 CPU-bound인지 I/O-bound인지 판단하고, iostat -x 1로 디스크별 await, util을 확인해 디스크 병목을 식별하며, sar -n DEV 1로 네트워크 인터페이스의 rxkB/s, txkB/s를 확인합니다. iowait가 높다면 디스크 I/O가 병목이므로 애플리케이션에서 불필요한 동기 I/O 제거, 배치 처리, 비동기 I/O 도입을 검토하고, 인프라 레벨에서는 SSD 도입, RAID 구성 변경, 파일시스템 튜닝을 고려합니다. 컨텍스트 스위칭이 과도하면(vmstat의 cs 값) 스레드 수를 줄이고 스레드 풀 크기를 최적화하며, 메모리 스와핑이 발생하면(si/so 값) JVM 힙 크기를 조정하거나 물리 메모리를 증설합니다. Spring 애플리케이션에서는 @Async 남용, 과도한 DB 커넥션 풀, 동기 HTTP 클라이언트 사용 등이 I/O 대기를 유발할 수 있으므로 이를 프로파일링하고 개선해야 합니다.
- • CPU 사용률과 load average의 개념 차이 이해
- • vmstat, iostat, sar를 활용한 체계적인 진단 절차
- • I/O-bound, CPU-bound, 컨텍스트 스위칭 원인 구분
- • 애플리케이션 레벨과 인프라 레벨의 이중 최적화 전략
- • Spring 특화 원인(과도한 스레드, 동기 I/O) 식별
프로덕션 환경에서 성능 저하 발생 시 근본 원인을 신속하게 진단하고 적절한 최적화 방향을 결정할 때 필수적인 지식입니다.
load average의 1분, 5분, 15분 평균값의 패턴을 보고 시스템 부하의 추세를 어떻게 해석하시겠습니까?
Q. Spring 기반 실시간 순위 시스템에서 수백만 사용자의 점수를 관리하고 특정 사용자의 순위를 O(log N) 시간 내에 조회해야 합니다. 이를 위해 어떤 자료구조를 선택하시겠습니까? B-Tree, Red-Black Tree, Skip List, 그리고 Heap의 특성을 비교하고, 각 자료구조에서 삽입, 삭제, 순위 조회, 범위 조회의 시간 복잡도와 메모리 효율성을 분석해주세요. 특히 동점자 처리, 점수 업데이트 빈도가 높은 상황, 그리고 분산 환경에서 Redis Sorted Set 같은 외부 저장소를 활용할 때의 트레이드오프와 일관성 문제를 함께 설명해주세요.
순위 조회는 특정 값보다 작은 원소의 개수를 세는 것과 같으며, 이를 효율적으로 지원하는 자료구조가 필요합니다.
순위 시스템에는 Order Statistic Tree(증강된 Red-Black Tree 또는 AVL Tree)가 적합하며, 각 노드에 서브트리 크기를 저장해 O(log N) 시간에 k번째 원소와 특정 값의 순위를 조회할 수 있습니다. B-Tree는 디스크 기반 저장소에 적합하고 범위 조회에 유리하지만 메모리 내 순위 계산에는 추가 구현이 필요하고, Red-Black Tree는 균형 유지 비용이 낮아 삽입/삭제가 빈번한 상황에 적합하며, Skip List는 구현이 간단하고 lock-free 알고리즘 적용이 용이하지만 메모리 오버헤드가 있고, Heap은 최대/최소값 조회는 O(1)이지만 임의 순위 조회가 O(N)이라 부적합합니다. 동점자 처리는 보조 키(타임스탬프, 사용자 ID)를 복합 키로 사용해 해결하고, 점수 업데이트가 빈번하면 삭제 후 재삽입 비용을 고려해 lazy update나 배치 처리를 검토해야 합니다. 분산 환경에서는 Redis Sorted Set(내부적으로 Skip List와 Hash Table 조합)을 활용할 수 있으며, ZADD로 O(log N) 삽입, ZRANK로 순위 조회가 가능하지만 단일 인스턴스 메모리 제약과 샤딩 시 글로벌 순위 계산의 복잡도가 증가하는 트레이드오프가 있으므로, 주기적으로 스냅샷을 DB에 저장하고 실시간성과 정확성 사이의 균형을 맞춰야 합니다.
- • Order Statistic Tree를 통한 O(log N) 순위 조회 구현
- • 각 자료구조의 시간 복잡도와 적합한 사용 시나리오
- • 동점자 처리를 위한 복합 키 전략
- • Redis Sorted Set의 내부 구조와 분산 환경 제약
- • 실시간성과 정확성, 확장성 간의 트레이드오프 이해
게임 리더보드, 실시간 랭킹, 소셜 미디어 인기 콘텐츠 순위 등 대규모 순위 시스템 설계 시 핵심적인 자료구조 선택 기준이 됩니다.
Redis Sorted Set을 여러 샤드로 분산했을 때 전체 사용자 중 특정 사용자의 정확한 글로벌 순위를 계산하는 방법을 설명해주세요.
아직 댓글이 없습니다. 첫 번째 댓글을 남겨보세요!