대규모 시스템 설계 리드·아키텍트 CS 기초 면접
새 면접Q. 100GB 메모리를 가진 서버에서 실행 중인 Java 애플리케이션이 32GB Heap을 사용하도록 설정되어 있는데, 시스템 모니터링 결과 실제 RSS 메모리 사용량이 50GB를 초과하고 있습니다. JVM Heap 외에 추가로 소비되는 메모리 영역들을 설명하고, 각 영역의 크기를 추정하고 제어하는 방법을 제시하세요. 또한 메모리 오버커밋 상황에서 OOM Killer가 프로세스를 선택하는 기준은 무엇인가요?
JVM은 Heap 외에도 Native Memory, Thread Stack, Direct Buffer, Metaspace 등 여러 메모리 영역을 사용합니다.
JVM Heap 외 메모리 영역은 다음과 같습니다. (1) Metaspace: 클래스 메타데이터 저장, -XX:MaxMetaspaceSize로 제한 가능, (2) Thread Stack: 스레드당 1MB 기본값, -Xss로 조정, 1000개 스레드면 1GB 소비, (3) Direct Buffer: NIO에서 사용하는 Off-Heap 메모리, -XX:MaxDirectMemorySize로 제한, (4) Code Cache: JIT 컴파일된 네이티브 코드, -XX:ReservedCodeCacheSize로 설정, (5) Native 라이브러리가 할당한 메모리. OOM Killer는 oom_score를 기준으로 프로세스를 선택하며, 메모리 사용량, 실행 시간, nice 값, root 프로세스 여부 등을 고려합니다. oom_score_adj를 설정하여 우선순위를 조정할 수 있으며, 중요한 프로세스는 -1000으로 설정해 보호할 수 있습니다.
- • Metaspace, Thread Stack, Direct Buffer, Code Cache 등 JVM Native Memory 영역 이해
- • 각 메모리 영역별 JVM 파라미터를 통한 크기 제어 방법
- • OOM Killer의 oom_score 계산 메커니즘과 oom_score_adj를 통한 프로세스 보호 전략
대용량 트래픽을 처리하는 서버에서 예상치 못한 메모리 사용량 증가로 인한 OOM 상황을 진단하고 예방할 때 필수적인 지식입니다.
Native Memory Tracking(NMT)을 활성화하여 메모리 누수를 진단하는 방법과, jemalloc 같은 대체 메모리 할당자를 사용했을 때의 장단점은 무엇인가요?
Q. 글로벌 서비스에서 한국-미국 간 RTT가 150ms인 환경에서 대용량 파일 전송 성능이 예상보다 낮게 나옵니다. TCP Window Size가 64KB로 설정되어 있을 때 이론적 최대 처리량을 계산하고, TCP Slow Start, Congestion Avoidance, Fast Retransmit/Recovery 알고리즘이 장거리 네트워크에서 성능에 미치는 영향을 설명하세요. Bandwidth-Delay Product 개념을 활용한 튜닝 방안도 제시해주세요.
처리량은 Window Size를 RTT로 나눈 값으로 근사할 수 있으며, BDP는 대역폭과 지연시간의 곱입니다.
TCP Window Size 64KB, RTT 150ms일 때 이론적 최대 처리량은 64KB / 0.15s = 약 3.4 Mbps입니다. TCP Slow Start는 초기에 cwnd를 지수적으로 증가시켜 대역폭을 빠르게 찾지만, 장거리에서는 ssthresh에 도달하는데 시간이 오래 걸립니다. Congestion Avoidance는 선형 증가로 전환되어 최적 윈도우 크기에 도달하는데 수십 초가 소요될 수 있습니다. Fast Retransmit/Recovery는 3개의 중복 ACK로 패킷 손실을 빠르게 감지하지만, 장거리에서는 타임아웃 기반 재전송이 더 자주 발생합니다. BDP = Bandwidth × RTT로 계산하며, 1Gbps 링크에서 BDP는 1Gbps × 0.15s = 18.75MB이므로 Window Size를 최소 이 값 이상으로 설정해야 합니다. TCP Window Scaling 옵션을 활성화하고, 초기 cwnd를 증가시키며(IW10), BBR 같은 최신 혼잡 제어 알고리즘 도입을 고려해야 합니다.
- • Window Size와 RTT를 기반으로 한 TCP 처리량 계산 공식 이해
- • TCP 혼잡 제어 알고리즘들이 장거리 고대역폭 네트워크에서 성능을 제한하는 메커니즘
- • BDP 개념을 활용한 TCP Window Size 튜닝과 BBR 같은 현대적 혼잡 제어 알고리즘 적용
CDN, 클라우드 스토리지, 글로벌 데이터 복제 시스템에서 장거리 대용량 전송 성능을 최적화할 때 반드시 고려해야 하는 요소입니다.
QUIC 프로토콜이 TCP의 Head-of-Line Blocking 문제를 어떻게 해결하며, 멀티플렉싱 환경에서 혼잡 제어는 어떻게 다르게 동작하나요?
Q. MySQL InnoDB에서 Repeatable Read 격리 수준을 사용하는 환경에서 긴 트랜잭션이 실행될 때 Undo Log가 계속 증가하여 디스크 공간 부족과 성능 저하가 발생하고 있습니다. MVCC의 동작 원리를 설명하고, Read View가 생성되는 시점과 Snapshot Isolation이 Phantom Read를 방지하는 메커니즘을 서술하세요. 또한 트랜잭션 격리 수준별로 발생 가능한 이상 현상(Dirty Read, Non-Repeatable Read, Phantom Read)과 Next-Key Lock의 역할을 설명해주세요.
MVCC는 읽기와 쓰기가 서로 블로킹하지 않도록 데이터의 여러 버전을 유지하며, Read View는 트랜잭션이 볼 수 있는 데이터 버전을 결정합니다.
InnoDB MVCC는 각 행에 트랜잭션 ID(DB_TRX_ID)와 롤백 포인터(DB_ROLL_PTR)를 저장하여 여러 버전을 유지합니다. Read View는 Repeatable Read에서 첫 SELECT 시점에 생성되어 트랜잭션 종료까지 유지되며, 이 시점의 활성 트랜잭션 목록을 기록합니다. Snapshot Isolation은 Read View 생성 시점 이후에 커밋된 변경사항을 보지 못하게 하여 Phantom Read를 방지합니다. Read Uncommitted는 Dirty Read 허용, Read Committed는 커밋된 데이터만 읽지만 Non-Repeatable Read 발생 가능, Repeatable Read는 Snapshot으로 Non-Repeatable Read 방지하지만 표준 SQL에서는 Phantom Read 가능(InnoDB는 Next-Key Lock으로 방지), Serializable은 모든 이상 현상 방지합니다. Next-Key Lock은 Record Lock과 Gap Lock의 조합으로 인덱스 레코드와 그 앞 간격을 함께 잠가 범위 쿼리에서 새로운 행 삽입을 방지합니다. 긴 트랜잭션은 Read View가 오래 유지되어 그 이전 버전의 Undo Log를 퍼지할 수 없게 만들므로, 트랜잭션 시간을 짧게 유지하거나 읽기 전용 작업은 별도 Read Replica를 사용해야 합니다.
- • MVCC의 다중 버전 관리 메커니즘과 Read View 생성 시점에 따른 가시성 결정 원리
- • 트랜잭션 격리 수준별 이상 현상(Dirty Read, Non-Repeatable Read, Phantom Read) 발생 조건
- • Next-Key Lock을 통한 Phantom Read 방지와 긴 트랜잭션이 Undo Log에 미치는 영향 및 해결 방안
대규모 배치 작업이나 복잡한 리포트 생성 중 발생하는 긴 트랜잭션이 운영 DB 성능에 미치는 영향을 분석하고 해결할 때 필수적입니다.
PostgreSQL의 Serializable Snapshot Isolation(SSI)이 InnoDB의 Serializable과 어떻게 다르며, Write Skew 이상 현상을 어떻게 감지하나요?
아직 댓글이 없습니다. 첫 번째 댓글을 남겨보세요!