Java 시니어 CS 기초 기술면접
새 면접Q. 대규모 트래픽을 처리하는 서버에서 TCP TIME_WAIT 상태가 대량으로 발생하여 포트 고갈 문제가 발생했습니다. TIME_WAIT의 존재 이유와 발생 조건을 설명하고, 클라이언트와 서버 각각에서 이 문제를 해결하기 위한 방법들(SO_REUSEADDR, SO_LINGER, tcp_tw_reuse 등)의 동작 원리와 주의사항을 설명해주세요.
TIME_WAIT은 TCP 연결 종료 시 능동적으로 close한 쪽에서 발생하는 상태로, 네트워크에 남아있을 수 있는 지연 패킷을 처리하고 정상적인 연결 종료를 보장하기 위해 2MSL(보통 60초) 동안 유지됩니다. 서버에서 먼저 close하면 서버 포트가 TIME_WAIT에 묶이므로, 가능하면 클라이언트가 먼저 close하도록 설계해야 합니다. SO_REUSEADDR은 TIME_WAIT 소켓의 주소를 재사용할 수 있게 하며, tcp_tw_reuse는 커널 레벨에서 outbound 연결에 한해 TIME_WAIT 소켓을 재사용합니다. Connection Pool을 사용하여 연결을 재사용하거나, HTTP Keep-Alive로 연결을 유지하는 것이 근본적인 해결책입니다.
- • TIME_WAIT은 능동적 close 측에서 발생하며 지연 패킷 처리와 정상 종료 보장이 목적
- • 서버가 먼저 close하지 않도록 설계하고 클라이언트 측에서 연결 종료 유도
- • SO_REUSEADDR은 바인딩 시 재사용, tcp_tw_reuse는 outbound 연결 재사용
- • Connection Pool과 Keep-Alive로 연결 재사용이 근본적 해결책
tcp_tw_recycle 옵션이 최신 리눅스 커널에서 제거된 이유는 무엇이며, NAT 환경에서 어떤 문제를 일으켰나요?
Q. Java 애플리케이션에서 메모리 페이지 폴트(Page Fault)가 빈번하게 발생하여 성능 저하가 일어나고 있습니다. Major Page Fault와 Minor Page Fault의 차이점을 설명하고, 각각이 발생하는 원인과 JVM 환경에서 페이지 폴트를 줄이기 위한 방법들을 설명해주세요. 특히 Huge Pages와 Transparent Huge Pages의 차이점과 적용 시 고려사항도 함께 설명해주세요.
Minor Page Fault는 요청한 페이지가 물리 메모리에는 있지만 프로세스의 페이지 테이블에 매핑되지 않은 경우 발생하며, Major Page Fault는 디스크에서 페이지를 읽어와야 하는 경우로 I/O 작업이 필요하여 성능에 큰 영향을 줍니다. JVM에서는 -Xms와 -Xmx를 동일하게 설정하여 초기에 모든 메모리를 할당받고, -XX:+AlwaysPreTouch 옵션으로 시작 시 모든 페이지를 미리 터치하여 런타임 페이지 폴트를 방지할 수 있습니다. Huge Pages는 기본 4KB 대신 2MB 단위로 페이지를 관리하여 TLB 미스를 줄이고, 명시적 설정이 필요하지만 메모리 단편화 위험이 있으며, Transparent Huge Pages는 커널이 자동으로 관리하지만 예측 불가능한 지연이 발생할 수 있어 데이터베이스나 실시간 시스템에서는 비활성화를 권장합니다.
- • Minor는 메모리 내 재매핑, Major는 디스크 I/O 필요로 성능 차이 큼
- • -Xms=-Xmx 설정과 AlwaysPreTouch로 런타임 페이지 폴트 최소화
- • Huge Pages는 TLB 효율 향상하지만 명시적 설정과 메모리 단편화 고려 필요
- • Transparent Huge Pages는 자동 관리이나 예측 불가능한 지연으로 프로덕션에서 주의
컨테이너 환경에서 메모리 limit과 JVM 힙 크기를 설정할 때, 페이지 폴트와 OOM Killer를 고려하여 어떤 비율로 설정하는 것이 적절한가요?
Q. IP 주소 기반 라우팅 테이블을 구현해야 합니다. 수백만 개의 CIDR 블록(예: 192.168.1.0/24)이 저장되어 있고, 특정 IP 주소가 들어왔을 때 가장 긴 프리픽스 매칭(Longest Prefix Match)을 빠르게 찾아야 합니다. Trie 기반 접근법과 Radix Tree(Patricia Trie)의 차이점을 설명하고, 메모리 효율과 검색 성능을 고려한 최적의 자료구조 설계 방안을 제시해주세요.
일반 Trie는 IP 주소의 각 비트마다 노드를 생성하여 IPv4 기준 최대 32단계의 깊이를 가지며 메모리 사용량이 많지만, Radix Tree는 공통 프리픽스를 압축하여 하나의 노드에 여러 비트를 저장함으로써 메모리를 절약하고 탐색 깊이를 줄입니다. IP 라우팅에서는 Radix Tree를 기반으로 각 노드에 프리픽스 길이와 라우팅 정보를 함께 저장하고, 탐색 시 루트부터 리프까지 내려가면서 매칭되는 가장 긴 프리픽스를 갱신하는 방식으로 구현합니다. 추가로 Level Compression과 Path Compression 기법을 적용하여 메모리와 성능을 최적화할 수 있으며, 자주 검색되는 경로는 캐싱하여 성능을 향상시킬 수 있습니다.
- • Trie는 비트별 노드로 깊이가 깊고, Radix Tree는 공통 프리픽스 압축으로 메모리 효율적
- • 각 노드에 프리픽스 길이 저장하고 탐색 중 가장 긴 매칭 갱신
- • Level/Path Compression으로 트리 최적화 및 메모리 절약
- • 자주 검색되는 경로는 LRU 캐시로 성능 향상
IPv6 환경에서 128비트 주소를 처리해야 할 때, Radix Tree의 메모리 오버헤드를 줄이기 위한 Multi-bit Trie 기법에 대해 설명해주세요.
Q. MVCC(Multi-Version Concurrency Control)의 동작 원리를 설명하고, PostgreSQL과 MySQL(InnoDB)의 MVCC 구현 방식 차이점을 비교해주세요. 특히 Undo Log와 Vacuum 처리 방식, 그리고 Long Transaction이 시스템에 미치는 영향과 모니터링 방법을 설명해주세요.
MVCC는 읽기와 쓰기 작업이 서로 블로킹되지 않도록 데이터의 여러 버전을 유지하는 동시성 제어 기법입니다. PostgreSQL은 테이블 내에 모든 버전을 저장하고 각 튜플에 xmin, xmax를 기록하여 가시성을 판단하며, VACUUM 프로세스가 주기적으로 오래된 버전을 정리합니다. MySQL InnoDB는 Undo Log를 별도 테이블스페이스에 저장하고 현재 버전만 테이블에 유지하며, Purge Thread가 비동기로 Undo Log를 정리합니다. Long Transaction은 오래된 버전을 계속 참조하여 VACUUM/Purge가 동작하지 못하게 만들어 디스크 공간 증가와 성능 저하를 유발하므로, pg_stat_activity나 information_schema.innodb_trx를 모니터링하여 장시간 실행 트랜잭션을 감지하고 타임아웃을 설정해야 합니다.
- • MVCC는 데이터 다중 버전 유지로 읽기-쓰기 블로킹 방지
- • PostgreSQL은 테이블 내 버전 저장 후 VACUUM, MySQL은 Undo Log 별도 관리 후 Purge
- • Long Transaction은 오래된 버전 정리 방해로 디스크/성능 문제 유발
- • 트랜잭션 모니터링과 타임아웃 설정으로 Long Transaction 관리 필요
Serializable 격리 수준에서 Snapshot Isolation과 True Serializability의 차이점과, Write Skew 문제를 해결하는 방법에 대해 설명해주세요.
Q. 대규모 로그 데이터에서 특정 시간 범위의 중앙값(Median)을 실시간으로 계산해야 하는 스트리밍 환경을 구현해야 합니다. 데이터가 계속 추가되고 오래된 데이터는 제거되는 슬라이딩 윈도우 상황에서, 두 개의 Heap을 사용한 방법과 Order Statistics Tree를 사용한 방법의 시간복잡도를 비교하고, 각 연산(삽입, 삭제, 중앙값 조회)의 효율성과 구현 복잡도를 분석해주세요.
두 개의 Heap(Max Heap과 Min Heap) 방식은 작은 절반을 Max Heap에, 큰 절반을 Min Heap에 저장하여 중앙값을 O(1)에 조회할 수 있지만, 삽입은 O(log N), 특정 값 삭제는 O(N)이 소요되어 슬라이딩 윈도우에서 비효율적입니다. Order Statistics Tree(Augmented Red-Black Tree)는 각 노드에 서브트리 크기를 저장하여 k번째 원소를 O(log N)에 찾을 수 있으며, 삽입과 삭제도 O(log N)으로 처리되어 슬라이딩 윈도우에 적합합니다. Java에서는 TreeMap을 활용하여 값의 빈도를 관리하고 누적 카운트를 계산하여 중앙값을 찾거나, Apache Commons Math의 RandomDataGenerator를 사용할 수 있으며, 정확도를 약간 희생하면 Count-Min Sketch나 t-Digest 같은 근사 알고리즘으로 메모리를 절약할 수 있습니다.
- • 두 Heap 방식은 중앙값 조회 O(1)이나 삭제 O(N)으로 슬라이딩 윈도우에 부적합
- • Order Statistics Tree는 삽입/삭제/조회 모두 O(log N)으로 효율적
- • Java에서는 TreeMap으로 빈도 관리하며 누적 카운트로 중앙값 계산
- • 근사 알고리즘(t-Digest 등)으로 메모리 절약 가능
분산 환경에서 여러 노드의 데이터를 합쳐 전체 중앙값을 계산해야 한다면, 어떤 알고리즘과 데이터 구조를 사용하시겠습니까?
아직 댓글이 없습니다. 첫 번째 댓글을 남겨보세요!