시스템 설계 질문 답변 2: 캐시, 큐, MSA 전환, DB 마이그레이션

시스템 설계 Q&A 2는 과부하 처리, Redis 캐시 전략, 비동기 큐, RDB에서 NoSQL 전환, Monolithic에서 MSA 전환을 한 번에 훑는 메모입니다.

답변을 잘하려면 기술명을 나열하기보다, 어떤 병목을 줄이려는지와 데이터 정합성, 장애 복구, 사용자 경험의 trade-off를 함께 말해야 합니다.

 

핵심 정리

이 글은 시스템 설계에서 자주 이어지는 두 번째 질문들을 모은 메모입니다. 과부하 처리에서는 CDN, 로드밸런싱, autoscaling, DB 쿼리 최적화, 캐시, queue, rate limit, circuit breaker를 상황별로 꺼낼 수 있어야 합니다. RDB에서 NoSQL로 옮길 때는 기존 데이터 ETL, dual writing, 읽기 전환, feature flag, 롤백 계획이 필요합니다. Monolithic에서 MSA로 나눌 때는 기술 경계보다 비즈니스 도메인과 bounded context를 먼저 봐야 합니다.

• Cache aside는 캐시에 없을 때 DB를 읽고 캐시를 채우는 방식입니다.
• Write through와 write back은 쓰기 시점의 정합성과 성능 trade-off가 다릅니다.
• Queue는 피크 트래픽을 완충하고 비동기 처리로 사용자 대기 시간을 줄이는 데 쓰입니다.
• Dead Letter Queue는 처리 실패 메시지를 따로 모아 재처리와 모니터링을 가능하게 합니다.
• RDB에서 NoSQL로 옮길 때는 데이터 복사, dual writing, 읽기 전환, 검증, 롤백을 단계화해야 합니다.
• MSA 전환은 DB부터 자르는 것이 아니라 도메인 경계, API 계약, 이벤트 흐름, 운영 복잡도를 함께 봐야 합니다.

원문은 시스템 설계 Q&A 1편보다 더 구체적인 캐시 전략, 장애 격리, 마이그레이션, MSA, DDD, NoSQL과 스트리밍 도구 비교를 담고 있었습니다. 보강 블록은 면접 답변에서 빠지기 쉬운 trade-off와 전환 순서를 앞에 배치했습니다.

이어서 볼 글

• 시스템 설계 질문 답변: 요구사항, 트래픽, 캐시, failover - 앞선 시스템 설계 질문 답변으로 요구사항과 트래픽 산정을 먼저 잡는다.
• Redis 기본 개념: 캐시, 자료구조, Cache-Aside 패턴 - 캐시 파트를 Redis와 Cache-Aside 관점에서 보충한다.
• Application 뜻과 MSA 차이: 응용 프로그램과 마이크로서비스 - MSA 전환 판단에 필요한 기본 개념을 정리한다.
• Outbox 패턴: DB 트랜잭션과 Kafka 이벤트 발행 일관성 - 큐와 이벤트 발행 일관성을 설계할 때 이어지는 패턴이다.

 

Q. 설계 디자인 문제의 경우 초기에 질문할 것들은?

• 기능적 요구사항
• 비기능적 요구사항
  • 성능, 확장성, 안정성, 보안
  • 비용최적화
  • 트래픽패턴
• 제약사항
  • 벤드위스, 시스템사양, 외부시스템 디펜던시
• 프로세스
  • 스케일아웃등 의사결정시 데이터 포인트 필요(응답시간, 에러율, CPU/메모리/IO사용율, 대기중인요청, 스레드개수등)
  • 메트릭측정
  • 필드테스트전 로드테스트(환경구축 필요)

Q. 과부하처리

• 웹서버/WAS
  • 정적컨텐츠면 CDN(Content Delivery Network) 고려
  • 커넥션풀
  • 로드밸런싱(리버스 프록시)
  • Scale up, Scale out
  • Auto Scaling
• DB
  • 쿼리최적화/인덱싱
  • 머터리얼뷰(정규화 수준 낮추기)
  • Master/Slave분리
  • 샤딩, 분산트렌젝션(2단계 커밋)
  • NoSQL도입(쓰기작업이 많거나, 주문서등 비정형 데이터 저장)
  • 이벤트소싱(CQRS)
•  캐시적용(Redis등)
  • 읽는경우: Look aside. Cache에 있으면 Cache에서 가져오고 없으면 DB에서 읽고 Cache에 업데이트
  • 쓰는경우:
    • Write Through. 항상 cache에 저장하고 DB에도 저장
    • Write Back. Cache에 저장하고 주기적으로 모아서 DB에 배치 업데이트
  • 일관성보완: 캐시만료timeout, 쓰기시 캐시무효화
  • 가용성보완: 캐시복제

•  
  • Redis의 한계: 싱글스레드. 
    • keys대신 scan사용
• 비동기 처리
  • 대기열 시스템을 통한 고객 경험 개선
•  코드최적화
  • 지연로딩(이미지등), 디바운싱(마지막 요청만 처리)
• 전송방식 변경
  • gRPC
• 외부 디펜던시가 있다면
  • 스로틀링(rate limit포함, 요청수 제한), 서킷브레이크(close, open, half-open)
    • 푸시/풀(전자는 리소스헤비)
      • 풀은 api호출등
      • 푸시는 외부에서 push로 넣어주는것(그래서 부하조심)
      • kafka는 push라기보다 폴링방식임에 주의
    • failover=fallback(다른 결제 시스템)
  • 분리된 Queue에 요청을 저장하고, 백그라운드로 처리. 시스템 복구시 순차적 처리
  • 회로차단기로 막혔을때의 요청을 DLQ(Dead Letter Queue)에 넣고 모니터링 후 원래큐로 돌리거나 후처리.
    • 실시간 처리 시스템에서는 잘 안쓰고 대규모 비동기처리 하는 경우 자주 쓴다고 함

Q. 장애대응

• 네트워크 실패 문제
  • 다중 AZ, 서킷브레이크(외부 서비스면)
• 단일 실패지점
  • 데이터 복제, 로드밸런싱, 자동장애복구(클라우드), 장애격리(MSA)
  • 다중 AZ

Q. 무중단 DB마이그레이션(RDB > NoSQL기준)

• 데이터 동기화
  • 이미 존재하는 RDB데이터를 NoSQL로 복사(배치, ETL)
• 더블 Writing (RDB, NoSQL)
• 읽기연산을 NoSQL로 전환
• 쓰기연산 전환, RDB중단(feature flag사용)
• 경우에 따라 일부 사용자 또는 서비스만 전환(카나리테스트)
• 중간중간에 일관성확인/모니터링/롤백계획도 수립하면서 해야함
• RDB NoSQL
  쓰읽
  쓰읽  쓰
  쓰     쓰읽
          쓰읽

Q. Monolithic에서 MSA로 전환

• 도메인 분석을 통해 몇개 서비스로 나눌지 결정
• 비즈니스영향력이 작고 기술적으로 단순한 도메인 부터 이전
• DB분리 > 서비스간 API설계 > 통계는 별도 ETL구축
• 단점: API는 DB Join보다 비싸고 느림. 대안: 모듈식(펑션콜/공유메모리/로컬큐)

Q. 도메인주도설계(DDD)

• DB스키마 부터 설계하고 CRUD > 비즈니스로직 구현 순서가 아님
• 비즈니스부터 고민. 바운디드 컨텍스트(용어 정의)
• 애그리게이트(대출계좌, 대출자, 대출상품을 묶어 대출로 애그리게이트)
• 이벤트(대출신청, 승인, 상환)
• 서비스(복잡한 비즈니스로직 예를들어 대출 신용평가)

Q. NoSQL vs 스팍/하둡 vs Kafka

• NoSQL: 실시간성
• 스팍/하둡: 배치(하둡은 디스크액세스때문에 느리고, 스팍은 실시간성이 있으나 데이터 저장/관리 기능없음)
• Kafka: 배치보다는 실시간성에 강점. 하지만 메시지가 저장되므로 배치에도 사용가능.