[대규모트래픽 이론] #2.3 비동기 처리 시스템의 장단점 및 사례

학습목표

1. 비동기 처리시스템의 장단점 및 사례를 살펴본다.

목차

1. 비동기 처리의 장점
2. 비동기 처리의 단점
3. 실제 비동기 처리 시스템의 예시

들어가기 전..

비동기 메시징 시스템 복습하기

[대규모트래픽 이론] #2.2 비동기 메시징 시스템 이해

---

비동기 처리의 주요 장점

1. 높은 확장성 (Scalability)
   • 비동기 처리 시스템은 시스템이 동시에 처리할 수 있는 작업의 수를 크게 늘리는 것이 가능
   • 특히 트래픽이 증가하는 상황에서도 시스템이 효율적으로 확장 가능함
2. 시스템 리소스 최적화 
   • 비동기 시스템은 I/O 대기 시간을 줄여 시스템 리소스를 최적화
   • 동기적 방식에서는 작업 완료를 기다리면서 CPU나 메모리 자원을 낭비할 수 있지만, 비동기 방식에서는 대기 중에서도 다른 작업을 처리
3. 높은 응답성 (Responsiveness)
   • 비동기 시스템은 사용자에게 빠른 응답을 제공할 수 있음
   • 실시간 시스템에서 비동기 처리는 사용자 경험을 크게 향상

---

비동기 처리의 주요 단점

1. 복잡한 오류 처리 및 디버깅
   • 비동기 시스템은 비동기적 흐름에서 발생하는 오류를 처리하고 디버깅하는 것이 복잡 할 수 있음
   • 작업이 병렬로 처리되기 때문에 오류가 발생한 시점과 원인을 정확히 파악하는 것이 어려움
     • 사가 패턴으로 보상 작업을 해도, 그 자체에 문제가 생길 가능성이 있음
     • 해당 컴포넌트, 서비스간 데이터 동기화를 유지하는 것이 주 과제
2. 순서 보장 문제
   • 비동기 처리에서는 메시지 순서 보장이 어려움
   • 여러 작업이 동시에 실행되면서, 처리 순서가 중요한 경우 문제가 될 가능성
     • 메시지 순차 처리가 되지 않아, 데이터 불일치 가능성이 있음, 순서보장을 위해 복잡한 로직이 필요
     • ex. 돈관련 시스템 (입출금 등)
3. 상태 관리의 어려움
   • 비동기 작업이 병렬로 처리됨로, 공유 상태에 대한 접근과 관리가 복잡해 질 수 있음
   • 잘못된 상태 관리로 인해 데이터 일관성이 깨질 가능성이 존재
     • 분산시스템에서 상태관리는 큰 과제중 하나

---

실제 비동기 처리 시스템의  예시

1.  푸시 알림 시스템

• 뉴스 앱에서 새로운 기사가 업데이트 될 때 실시간으로 푸시 알림을 발송하거나, 메시징 앱에서 새로운 메시지가 왔을 때 알림을 제공하는 시스템에서 비동기 처리
• 이벤트 기반 비동기 처리
  • 사용자의 특정 행동(결제완료, 새로운 메시지 수신) 등 외부 이벤트 발생시 비동기 트리거
• 메시지 큐와 푸시 시스템
  • 큐에 저장하고 background에서 반응
• 실시간 알림 처리
  1. 메시지 큐 : 푸시 알림 저장
  2. 알림 서버 : 메시지 소비하여 사용자에게 전달 -> 사용자는 메시지를 실시간으로 받으면서도 서버 부하를 줄일 수 있음
  3. 비동기 i/o를 통해 다수 사용자에게 동시 알림 발송 -> 높은 성능, 빠른 응답성 

2. 쿠폰 발급

• 온라인 쇼핑몰에서 특정 이벤트 기간 동안 수많은 사용자에게 동시에 쿠폰을 발급하는 시스템에서 사용. 타임 세일이나 이벤트 쿠폰 발행 시에 사용자가 빠르게 쿠폰을 받을 수 있도록 비동기 처리를 통해 부하를 분산
• 쿠폰 발급 요청 비동기 처리
  • 동시 데이터 폭증을 효과적으로 처리
• 쿠폰 발급 중복 방지 및 순차 처리
  • 서버 과부하 방지하고 큐기반 메시지 브로커 사용
• 비동기 작업으로 백엔드 처리 최적화
  • I/O 작업 -> DB 대기시간 최소화하여 쿠폰이 발송 될 수 있도록 함

3. 채팅 시스템

• 메신저 어플리케이션에서 사용자의 채팅 메시지를 실시간으로 전달하는 시스템. Slack이나 Whatsapp과 같은 서비스는 비동기 메시징 시스템을 통해 다수의 사용자간의 빠른 메시지 전송을 보장
• 메시지 큐 기반 처리
  • 채팅 메시지는 늘 큐에 넣고 비동기적으로 전달
• 실시간 데이터 전송
• 다중 사용자 동시 처리
  • 메시지 브로커를 통해 다수의 클라이언트에게 메시지를 동시 전달

4. 실시간 주문 처리 시스템

• 배달 앱이나 전자 상거래 시스템에서 수백 개의 주문을 동시에 처리하는 상황에서 사용. 주문 폭주 시에도 서버가 안정적으로 주문을 처리할 수 있도록 비동기 처리 시스템이 적용
• 주문 요청 비동기 처리
  • 주문 처리량 극대화 가능, 주문 요청시 서버 부하를 줄이고 빠른 응답
• 재고 관리 시스템과의 비동기 통신
  • 주문시 재고 상태 업데이트 
  • 메시지 큐를 사용하여 각 주문 순차처리 하고 실시간 응답 보장
• 결제 처리 비동기화
  • 사용자가 대기하지 않고 결제 완료 이후에만 최종 주문완료 메세지 발송

5. 이메일 발송 시스템

• 마케팅 캠페인 이메일이나 주문 확인 이메일을 대량으로 발송하는 시스템에서 비동기 큐를 사용하여 부하를 관리하고, 안정적인 이메일 발송을 보장
• 이메일 발송 큐 관리 
  • 순차처리
• 실시간 이메일 발송과 대기 처리
  • 요청 폭주시 부하를 줄이고, 안정적인 처리
• SMTP 서버와 비동기 통신

 

---

tmi 1

메시지 큐와 메시지 브로커 아키텍쳐간 차이의 이해를 확실히 하고자 질문함. 다른 방식으로 말하자면 소비자와 구독자간의 컨셉차이가 더 궁금했음. 

 

나 :

메시지 큐는 메시지를 큐에 넣고 소비자가 준비될 때 가져가서 처리하고 메시지 브로커는 프로바이더, 섭스크라이버 구조로 해서 프로바이더가 메시지를 큐에 넣으면, 이벤트 브로커가 병렬의 시스템에게 섭스크라이버에게 주는거야?

 

 

챗과장: 캬~ 개념 거의 다 잡으셨어요! 아주 가까이 왔습니다 😎 이제 딱! 10초만에 정리되도록 정확한 차이점을 깔끔하게 짚어드릴게요.

 

✅ 메시지 큐 vs 메시지 브로커 핵심 비교

	메시지 큐 (Message Queue)	메시지 브로커 (Message Broker)
구조	Producer → Queue → Consumer (1:1 구조)	Publisher → Broker → Subscriber (1:N 구조도 가능)
메시지 처리 방식	소비자 준비될 때까지 큐에 쌓임, 소비자가 꺼내감 (Pull 방식)	브로커가 메시지를 받아 적절한 구독자에게 라우팅 (Push or Pub/Sub 방식)
주요 목적	작업 처리의 분산과 병렬화, 백프레셔 조절	다양한 시스템 간 통합과 이벤트 전달
대표 예시	Amazon SQS, RabbitMQ (큐 기반 사용 시)	Apache Kafka, Redis Pub/Sub, RabbitMQ (Pub/Sub 모드), NATS

✅ 정리된 문장으로 한 줄 요약

메시지 큐는 작업 분산과 순차 처리에 강점이 있고,
메시지 브로커는 다양한 구독자에게 동시 전달하는 이벤트 중심의 시스템 통합에 강점을 가집니다.

---

✅ 추가 팁: RabbitMQ는 둘 다 된다!

 

RabbitMQ는 큐 기반의 메시지 큐 역할도 하고,
Pub/Sub 기반의 브로커 역할도 할 수 있어요.
그래서 어떤 구성(Exchange Type)을 하느냐에 따라 Queue로도, Broker로도 쓰일 수 있죠.

---

tmi 2

소비자와 구독자간의 일 진행방식의 주체성을 좀 더 명확히 하고자 하여 질문함. 

나:

오케이 , 내가 궁금했던 걸 너가 구체화 시켜줬어. 그럼 정리해볼게, 메시지 큐의 소비자는 본인이 주체가 되어서 큐에서 땡겨가는거고 메시지 브로커는 브로커가 섭스크라이버에게 메시지를 주는거라고 이해해도될까? 섭스크라이버 자체는 주체성이 없어보이는데

챗과장:

오오오~ 네가 지금 말한 문장, 핵심을 제대로 짚었어요. 이제 거의 마스터 단계입니다!
바로 피드백 + 살짝 더 디테일한 이해 도와드릴게요 

 

 

✅ 당신의 정리: 아주 정확합니다!

"메시지 큐의 소비자는 본인이 주체가 되어서 큐에서 땡겨가는 것이고,
메시지 브로커는 브로커가 섭스크라이버에게 메시지를 주는 것이다."

 

✔️ 이거 정확합니다.

• 메시지 큐 (Queue) → Consumer가 Pull 주체
• 메시지 브로커 (Broker) → Broker가 Push 주체

🎯 그럼 섭스크라이버는 진짜 수동적인가?

 

약간 더 기술적으로 정리해보면, 섭스크라이버가 "완전히 수동적"이라고 보긴 어렵고, 사실 구독(Subscribe) 요청을 먼저 보내놓고 기다리는 구조입니다.

• 구독자(Subscriber): “나는 이 주제(topic)에 관심 있어! 메시지 오면 알려줘” 라고 등록
• 브로커: 메시지가 도착하면, 구독자 리스트를 확인하고 자동으로 메시지를 전달 (Push)

그래서 실제 동작은 이렇습니다:

1	Subscriber가 브로커에 구독 요청 (나는 topic-A 듣고 싶어요)
2	Publisher가 topic-A로 메시지 전송
3	Broker가 그 메시지를 구독 중인 Subscriber에게 Push 전달

📌 즉, 주체적인 동작은 구독 시점에 한 번 있고, 이후는 브로커가 관리합니다.

 

✅ 다시 한 번 핵심 정리!

	메시지 큐	메시지 브로커
메시지 전달 주체	소비자가 메시지를 직접 Pull	브로커가 메시지를 Push
소비자 / 구독자 역할	계속 큐를 확인하거나 Polling	한 번 구독 설정 후 대기만
사용 용도	백엔드 비동기 작업 처리, 작업 분산	이벤트 전파, 시스템 간 연결

---

 

 

후후,,,,,,, ~~~~~!~!~!~! 

대용량으로 가기 위한 비동기 처리 시스템이란~!~!

그래두 곧 새로운거 실습하려니 설렌다 ㅋㅋ크킄

 

 

참고, 강의 및 구글링

1티어 패션 커머스의 세일 도메인 프로젝트로 배우는 대규모 트래픽을 견디는 실전 백엔드의 모