AWS 리드/아키텍트 CS 기초 면접
새 면접Q. AWS의 여러 리전에 걸쳐 분산된 데이터베이스 시스템을 설계할 때 CAP 정리(CAP Theorem)를 고려해야 합니다. Consistency, Availability, Partition Tolerance 중 두 가지를 선택해야 하는 상황에서, 금융 거래 시스템과 소셜 미디어 피드 시스템은 각각 어떤 조합을 선택해야 하며, 그 이유는 무엇입니까? 또한 선택하지 못한 속성을 보완하기 위해 어떤 아키텍처 패턴을 적용할 수 있는지 설명해주세요.
각 시스템의 비즈니스 요구사항에서 절대 타협할 수 없는 속성이 무엇인지부터 생각해보세요.
금융 거래 시스템은 CP(Consistency + Partition Tolerance)를 선택해야 합니다. 이중 지불 방지와 정확한 잔액 관리를 위해 강한 일관성이 필수적이며, 일시적 서비스 불가(가용성 저하)를 감수하더라도 데이터 정합성을 보장해야 합니다. 반면 소셜 미디어 피드는 AP(Availability + Partition Tolerance)를 선택하여 eventual consistency를 허용하면서 항상 서비스 가능한 상태를 유지하는 것이 중요합니다. CP 시스템에서는 Read Replica와 Circuit Breaker 패턴으로 읽기 가용성을 높이고, AP 시스템에서는 CRDT(Conflict-free Replicated Data Types)나 Vector Clock을 활용한 충돌 해결 메커니즘으로 최종 일관성을 보장할 수 있습니다. AWS 환경에서는 금융 시스템에 Aurora Global Database의 동기식 복제를, 소셜 미디어에는 DynamoDB Global Tables의 비동기식 멀티마스터 복제를 활용할 수 있습니다.
- • 금융 시스템은 CP 선택으로 강한 일관성 보장
- • 소셜 미디어는 AP 선택으로 가용성 우선
- • 보완 패턴: Circuit Breaker, CRDT, Vector Clock 등 적용
- • AWS 서비스별 CAP 특성 이해
멀티 리전 서비스 설계 시 비즈니스 요구사항에 따라 데이터 일관성과 가용성의 트레이드오프를 결정하는 핵심 기준이 됩니다.
DynamoDB Global Tables가 AP 시스템인데, 만약 두 리전에서 동시에 같은 아이템을 수정하면 충돌을 어떻게 해결합니까?
Q. EC2 인스턴스에서 Java 기반 마이크로서비스가 실행 중인데, 메모리 사용량이 지속적으로 증가하다가 OOM Killer에 의해 프로세스가 종료되는 현상이 반복됩니다. 운영체제의 가상 메모리 관리 관점에서 이 문제의 원인을 진단하는 접근 방법과, JVM Heap, Native Memory, Page Cache, Swap의 관계를 고려한 근본 해결 방안을 설명해주세요. 특히 컨테이너 환경(ECS/EKS)에서 메모리 제한이 있을 때의 차이점도 포함해주세요.
JVM이 사용하는 메모리는 Heap만이 아니며, OS 레벨에서 프로세스가 실제 점유하는 메모리 영역들을 구분해서 살펴봐야 합니다.
먼저 RSS(Resident Set Size)와 VSZ(Virtual Memory Size)를 모니터링하여 실제 물리 메모리 사용량을 확인하고, JVM의 -Xmx 설정만으로는 Native Memory(Direct Buffer, Thread Stack, Metaspace, GC 오버헤드) 사용량을 제어할 수 없음을 이해해야 합니다. OS는 프로세스의 총 메모리 사용량이 한계에 도달하면 OOM Killer를 실행하며, 이는 JVM의 OutOfMemoryError와는 별개입니다. 해결을 위해서는 JVM Native Memory Tracking을 활성화하여 메모리 누수 지점을 식별하고, -XX:MaxDirectMemorySize로 Direct Buffer를 제한하며, -Xss로 Thread Stack 크기를 조정해야 합니다. 컨테이너 환경에서는 메모리 limit이 cgroup으로 강제되므로, JVM Heap + Native Memory + OS 오버헤드를 고려해 limit의 70-80%만 JVM Heap에 할당하고, -XX:+UseContainerSupport 옵션으로 컨테이너 인식을 활성화해야 합니다. 또한 Page Cache를 위한 여유 메모리를 확보하고, Swap은 컨테이너 환경에서 비활성화하는 것이 일반적입니다.
- • JVM Heap 외 Native Memory 영역 모니터링 필요
- • OS의 OOM Killer와 JVM OOM 구분
- • 컨테이너 메모리 limit 내에서 JVM, Native, OS 오버헤드 분배
- • Native Memory Tracking과 cgroup 설정 활용
컨테이너 기반 마이크로서비스에서 메모리 부족으로 인한 Pod 재시작을 방지하고 안정적인 서비스를 운영하는 데 필수적입니다.
JVM의 G1GC와 ZGC 중 어느 것이 컨테이너 환경에서 메모리 효율성이 더 좋으며, 그 이유는 무엇입니까?
Q. Aurora PostgreSQL을 사용하는 전자상거래 시스템에서 재고 관리 로직을 구현할 때, Read Committed, Repeatable Read, Serializable 격리 수준 중 어떤 것을 선택해야 하는지 판단해야 합니다. 각 격리 수준에서 발생할 수 있는 Dirty Read, Non-Repeatable Read, Phantom Read 문제와 성능 트레이드오프를 설명하고, 동시에 100명이 마지막 1개 재고에 대해 주문을 시도할 때 어떤 격리 수준과 락 전략(Pessimistic Lock, Optimistic Lock)을 조합해야 하는지 제시해주세요.
재고 차감은 정확성이 생명이지만, 격리 수준을 높일수록 동시성이 떨어져 처리량이 감소하는 트레이드오프가 있습니다.
Read Committed는 커밋된 데이터만 읽지만 같은 트랜잭션 내에서 재조회 시 다른 값을 읽을 수 있어(Non-Repeatable Read) 재고 확인 후 차감 사이에 다른 트랜잭션이 개입할 수 있습니다. Repeatable Read는 트랜잭션 시작 시점의 스냅샷을 보장하지만 Phantom Read가 발생할 수 있으며, PostgreSQL의 MVCC 구현상 Lost Update 문제가 발생할 수 있습니다. Serializable은 완전한 격리를 보장하지만 직렬화 충돌로 인한 재시도가 빈번하여 처리량이 크게 감소합니다. 재고 관리에는 Read Committed + SELECT FOR UPDATE(Pessimistic Lock)를 사용하여 재고 조회 시점에 행 락을 획득하고, 타임아웃을 짧게 설정하여 대기 시간을 제한하는 것이 실용적입니다. 대안으로 Optimistic Lock(version 컬럼)을 사용하면 락 대기가 없지만 충돌 시 재시도 로직이 필요하며, 재고 소진 임박 시점에는 충돌률이 높아 Pessimistic Lock이 더 효율적입니다. Aurora의 경우 Writer 인스턴스에서만 쓰기가 가능하므로 재고 차감은 반드시 Writer 엔드포인트로 라우팅해야 합니다.
- • 격리 수준별 발생 가능한 이상 현상 이해
- • 재고 관리는 Read Committed + SELECT FOR UPDATE 권장
- • Pessimistic Lock과 Optimistic Lock의 적용 시나리오 구분
- • Aurora Writer/Reader 엔드포인트 특성 고려
동시성이 높은 커머스 시스템에서 재고 정확성을 보장하면서도 처리량을 최대화하는 핵심 설계 결정입니다.
만약 재고를 Redis에 캐싱하여 성능을 개선하려 한다면, 데이터베이스와 Redis 간 일관성을 어떻게 보장하시겠습니까?
아직 댓글이 없습니다. 첫 번째 댓글을 남겨보세요!