Post

메시지 큐·빅데이터·클라우드: 비동기/배치 사고의 설계 언어

MQ 도입 조건, 전달 보장, 스트리밍·배치 선택을 다루는 비동기 설계 실전 가이드

메시지 큐·빅데이터·클라우드: 비동기/배치 사고의 설계 언어

비동기 설계의 출발점

결론: 메시지 큐는 ‘편의 기능’이 아니라 동기 처리가 깨지는 지점에 대한 구조적 해법이다.

  • 왜(문제): 동기 호출은 피크 트래픽·느린 종속 서비스·부분 실패에서 연쇄 장애를 만든다.
  • 무엇(개념): MQ는 버퍼링·비동기화·결합도 감소로 실패를 흡수한다.
  • 어떻게(설계/선택): 처리 지연 허용 여부와 실패 전파를 기준으로 동기/비동기를 나눈다.
  • 트레이드오프: 지연 증가·중복 처리·운영 복잡성.
  • 인터뷰 문장: “동기 경로의 실패 전파를 끊기 위해 MQ를 둡니다.”

MQ 도입 조건

결론: MQ는 ‘버퍼가 필요한 순간’에만 가치가 있다.

조건설명
버퍼링피크 트래픽 흡수
비동기사용자 응답과 분리
결합도생산자/소비자 독립
재처리실패 복구
  • 함정: 단순 CRUD에 MQ 도입
  • 체크리스트:
    • 즉시 응답이 필요한가?
    • 실패를 나중에 처리해도 되는가?
  • 인터뷰 문장: “응답 경로와 처리 경로를 분리합니다.”

전달 보장(Delivery Semantics)

결론: 전달 보장은 ‘중복·유실·순서’ 중 무엇을 감수하는지의 선택이다.

보장특징대가
At-most-once중복 없음유실 가능
At-least-once유실 없음중복 처리
Exactly-once중복·유실 없음복잡·비용
  • 실무 포인트: Exactly-once는 Idempotency + 트랜잭션의 조합.
  • 인터뷰 문장: “중복은 허용하고 유실은 막습니다.”

중복·유실·순서 문제 대응

결론: 문제를 없애려 하지 말고, 흡수한다.

  • 중복: Idempotency 키
  • 유실: ACK/재시도/DLQ
  • 순서: 파티션 키 기반 보장
  • 트레이드오프: 처리 지연·파티션 편향
  • 문장: “순서는 파티션 단위로만 보장합니다.”

스트리밍 vs 배치

결론: 실시간은 ‘빠름’이 아니라 ‘지연 허용치’의 문제다.

기준스트리밍배치
지연초~분분~시간
복잡도높음낮음
정확성근사정확
비용지속간헐
  • 함정: 모든 집계를 스트리밍으로 처리
  • 인터뷰 문장: “이 집계는 시간 민감도가 낮아 배치가 적합합니다.”

Spark를 쓰는 상황과 설명 방식

결론: Spark는 ‘빠른 코드’가 아니라 ‘분산 집계 모델’이다.

  • 왜: 단일 노드로 감당 불가한 데이터량.
  • 무엇: 메모리 기반 분산 처리(Shuffle 비용 인지).
  • 어떻게: ETL/대규모 집계/오프라인 피처 생성.
  • 트레이드오프: 클러스터 비용·운영 복잡성.
  • 인터뷰 문장: “Shuffle 비용을 줄이는 방향으로 파이프라인을 설계합니다.”

클라우드 리소스 선택: 컴포넌트 매핑

결론: IaaS/PaaS 선택은 기술 선호가 아니라 책임 분담이다.

컴포넌트IaaSPaaS/Managed
MQ직접 운영관리형 큐
Spark클러스터Managed Spark
DBVM 설치Managed DB
  • 트레이드오프: 제어권 vs 운영 부담
  • 문장: “운영 리스크를 줄이기 위해 관리형을 택합니다.”

예시 1: 웹 크롤러 파이프라인(토이)

결론: 단계 분리로 실패를 국소화한다.

  • 수집 → MQ → 파싱 → 저장
  • 보장: At-least-once
  • 버린 것: 즉시 일관성
  • 문장: “중복 크롤링은 허용합니다.”

예시 2: 이벤트 로그 기반 추천/랭킹(실무형)

결론: 온라인과 오프라인을 분리한다.

  • 실시간: 스트리밍 집계
  • 오프라인: Spark 배치
  • 보장: 중복 허용
  • 문장: “랭킹은 근사치를 사용합니다.”

흔한 실수 5개 + 교정

  1. MQ 만능론 → 도입 조건 명시
  2. Exactly-once 집착 → Idempotency 설명
  3. 순서 전역 보장 → 파티션 한정
  4. 모든 집계 실시간 → 배치 병행
  5. 클라우드 나열 → 컴포넌트 매핑

면접에서 바로 쓰는 답변 문장 템플릿 8개

  1. “동기 경로를 끊기 위해 MQ를 둡니다.”
  2. “피크는 버퍼로 흡수합니다.”
  3. “유실보다 중복을 허용합니다.”
  4. “순서는 파티션 단위입니다.”
  5. “배치는 비용 대비 효율적입니다.”
  6. “Spark는 대규모 집계에 사용합니다.”
  7. “운영 부담을 줄이기 위해 관리형을 씁니다.”
  8. “실시간과 오프라인을 분리합니다.”

핵심 체크리스트 12개

  1. 동기/비동기 경계
  2. MQ 도입 이유
  3. 전달 보장 선택
  4. 중복 처리 전략
  5. 유실 대응
  6. 순서 보장 범위
  7. 스트리밍/배치 기준
  8. Spark 사용 이유
  9. Shuffle 비용 인식
  10. 클라우드 책임 분담
  11. 운영 복잡도
  12. 버린 선택 언급

면접관이 집요하게 파는 질문 10개

  1. 중복 처리 어떻게?
  2. DLQ는 언제?
  3. 순서 깨지면?
  4. Exactly-once 가능한가?
  5. 소비자 느리면?
  6. 파티션 키 기준은?
  7. 재처리 전략은?
  8. 배치 지연 허용치는?
  9. Spark 실패 시?
  10. 관리형의 한계는?

30분 복기 플랜(타이머 기준)

  • 0–5분: MQ 도입 조건
  • 5–10분: 전달 보장 3종
  • 10–15분: 중복/유실/순서
  • 15–20분: 스트리밍 vs 배치
  • 20–25분: Spark 사용 시나리오
  • 25–30분: 추천/랭킹 설명

한 줄 요약

비동기 설계는 큐를 쓰는 기술이 아니라, 실패와 지연을 다루는 선택이다.


This post is licensed under CC BY 4.0 by the author.