비동기 처리 시스템의 이해

비동기 처리 아키텍처

단일 프로세스에서 비동기 처리

• 작은 시스템에서는 자원의 효율적 사용이 중요함
• I/O 작업 (파일 읽기, 네트워크 요청 등)은 처리 시간이 길어질 수 있음
• 비동기 처리를 통해 그 대기 시간을 활용하여 다른 작업을 진행함으로써 전체 성능을 향상시킬 수 있음
• CPU 자원이 놀지 않고 계속 작업을 처리하도록 돕는 것이 비동기 처리의 핵심 장점

 

자바에서 비동기 처리의 기본 구성

• 스레드 풀
• 이벤트 루프를 활용한 비동기 처리

 

대규모 시스템에서의 비동기 처리

• 대규모 시스템에서는 많은 요청이 동시에 들어오고, 이러한 요청을 효율적으로 처리하기 위해서는 비동기 처리가 필수적
• 트래픽이 많은 환경에서 비동기 처리를 통해 시스템의 확장성과 안정성을 보장할 수 있음
• 이때 비동기 메시징 시스템 사용하여 아키텍처를 확장

비동기 메시징 시스템 이해

• 비동기 메시징 시스템은 시스템 간 또는 애플리케이션 내부의 여러 구성 요소 간 통신을 비동기적으로 처리하는 방식
• 작업이 비동기적으로 처리되기 때문에 각 구성 요소가 독립적으로 작업을 수행할 수 있어, 시스템의 확장성과 서능을 크게 향상시킬 수 있음 (독립성, 확장성, 성능햣아)
• 메시지 큐와 메시지 브로커가 이러한 비동기 메시징 시스템의 핵심 요소
  • 메시지 큐 : 메시지를 큐에 저장해 두고, 소비자가 준비되면 메시지를 비동기적으로 처리하는 역할
  • 메시지 브로커 : 이벤트 브로커는 발행-구독 패턴을 기반으로 여러 서비스가 이벤트를 구독하고, 특정 이벤트가 발생할 때 이 이벤트를 비동적으로 구독자에게 전달

메시징 시스템을 통한 비동기 처리

• 한 서비스가 작업을 완료하기 전에 메시지를 큐에 넣고, 다른 서비스가 비동기적으로 이를 처리함으로써 시스템의 부하를 줄일 수 있음

Message Queue

• 비동기 처리에서 자주 사용되는 작업 큐는 요청을 처리하기 위해 순차적으로 저장된 작업을 관리
• Producer가 메시지를 큐에 넣고, Consumers는 큐에서 메시지를 꺼내 비동기적으로 처리
• 큐는 작업을 병렬로 분산 처리하는데 중요한 역할
• 서비스 간 느슨한 결합을 가능하게 하고, 확장성을 높이는데 유용함
  • 동작 원리
    • 프로듀서 : 메시지를 생성하여 큐에 넣는 주체
    • 큐 : 메시지가 일시적으로 저장되는 공간
    • 컨슈머 : 큐에서 메시지를 가져가 처리하는 주체

Event-Driven Architecture

• 서비스 간 느슨한 결합과 실시간 반응성을 제공하는 또 다른 비동기 메시징 시스템
• 이벤트 기반 아키텍처는 시스템 내에서 발생하는 상태 변화를 이벤트로 처리하고, 각 서비스는 이 이벤트에 비동기적으로 반응하는 구조

• 이벤트 기반 아키텍쳐는 시스템의 각 구성요소들이 특정 이벤트에 반응하여 작업을 처리하는 방식
• 이벤트가 발생하면 이를 다른 서비스나 모듈이 구독하고, 이벤트가 도착하면 해당 작업을 비동기적으로 처리하는 구조
  • 구성 요소
    • 프로듀서 : 발생
    • 컨슈머 : 구독, 처리
    • 브로커 : 전달

비동기 메시징 시스템의 확장성과 안정성 보장

• 확장성 : 메시지 큐나 이벤트 버스는 필요에 따라 소비자 또는 서비스 인스턴스를 동적으로 추가할 수 있어, 대규모 트래픽을 처리하기 위한 확장성을 보장
• 안정성 : 각 서비스가 독립적으로 동작할 수 있어 시스템의 한 부분에 문제가 생기더라도 전체 시스템이 중단되지 않고 작동

--> 즉 비동기 메시징 시스템은 프로듀서와 컨슈머가 독립적으로 동작하며, 서로 직접적으로 데이터를 주고받지않고 메시지 큐나 이벤트 버스와 같은 중간 매체를 통해 통신

 

이벤트 버스

• 이벤트 버스는 시스템 내에서 발생하는 이벤트를 전달하는 비동기 메시징 시스템
• 이벤트는 시스템 내의 상태 변화나 사용자 액션에 의해 발생하며, 이를 처리하기 위해 비동기적으로 여러 서비스 간에 전달
  • 동작 원리
    • 이벤트 프로듀서 : 이벤트를 발생시키는 주체
    • 이벤트 버스 : 이벤트를 구독하고 있는 여러 서비스로 전달하는 역할
    • 이벤트 컨슈머 : 이벤트를 구독하고 있는 서비스

메시지 브로커

• 메시지 브로커는 메시지 큐나 이벤트 버스와 비슷한 개념이지만, 더 큰 범위에서 시스템 간 통신을 중개하는 역할
• 메시지 브로커는 서로 다른 애플리케이션이나 시스템 간에 비동기 메시지를 전달
• 레빗mq, kafka와 같은 도구
  • 주요 역할
    • 메시지 저장 : 메시지를 큐에 저장하여, 시스템이 메시지를 손실하지 않고 안정적으로 전달
    • 트래픽 분산 : 브로커는 트래픽을 효율적으로 분산시켜 시스템에 과부하가 발생하지 않도록 도와줌
    • 서비스 간 중재 : 서로 다른 시스템 간의 메시지를 중대하여, 각 시스템이 독립적으로 동작할 수 있도록 함
     

 

Apache Kafka

• 분산 처리 : Kafka는 클러스터로 구성되어 대규모 데이터를 분산 처리하며, 수평적으로 확장 가능
• 높은 처리량과 지연 시간 최소화 : Kafka는 고속의 데이터 처리량을 제공하며, 실시간 데이터 스트리밍 처리에서 매우 적합
• 토픽 기반 구조 : Kafka는 데이터를 토픽으로 관리, 프로듀서가 메시지를 특정 토픽에 게시하면, 이를 구독한 여러 소비자가 동시에 데이터를 처리할 수 있음
• 순서 보장 : Kafka는 각 파티션 내에서 메시지의 순서를 보장하며, 메시지의 손실없이 내구성을 보장하는 로그 저장 방식을 채택
• 내구성 보장 : 카프카는 데이터를 디스크에 저아하며 메시지의 손실을 방지하기 위해 복제 지원
•  

RabbitMQ

• 큐 기반 구조 : 프로듀서가 메시지를 큐에 넣고, 컨슈머가 그 큐에서 메시지를 가져가 처리하는 방식. 이는 메시지를 비동기적으로 처리하는데 적합
• 메시지 라우팅 : RabbitMQ는 메시지 라우팅 옵션을 제공하여, Direct Exchange, Fanout Exchange, Topic Exchange 등을 통해 특정 조건에 맞는 메시지를 큐로 전달
• 스케줄링 및 우선 순위 메시징 : 메시지에 우선순위를 설정할 수 있으며, 메시지의 스케줄링도 지원
• 내구성 있는 메시지 저장 : 메시지를 디스크에 저장하여 시스템 장애 발생 시에도 메시지 손실 방지
• 확장성 : 클러스터링을 통해 확장할 수 있으며, 분산처리 환경에서도 높은 가용성 제공

 

Amazon SQS (Simple Queue Serive)

• 완전 관리형 서비스 : AWS가 시스템을 관리, 사용자는 인프라를 신경쓰지 않고 서비스 구축
• 자동 확장 : 트래픽 변화에 따라 자동으로 확장. 대규모 메시지 트래픽을 처리할때 추가적인 설정 없이 시스템이 자동으로 대응
• 메시지 전달 보장 : 최소 한번 메시지를 전달하는 At leas once 방식이 기본으로 제공, FIFO선택하면 순서를 보장
• 지연 큐 : 메시지를 일정시간동안 대기시킨 후 처리할 수 있는 지연 큐 기능을 제공. 특정 조건에서 메시지를 지연 처리해야 할 때유용
• 비용 효율성 : 클라우드 기반 서비스로. 사용한 만큼만 지불

 

메시징 시스템 선택시 고려사항

• 처리속도
  • 메시징 시스템의 처리 속도는 시스템의성능을 결정짓는 중요한 요소
  • 높은 처리량을 필요로 하는 시스템에는 Kafka가 적합 (로그 기반의 메시징 처리에 최적화)
  • 높은 신뢰성과 정밀한 메시지 전달이 중요하다면 RabbitMQ가 유리 (메시지 라우팅에 유리)
• 메시지 전달 보장
  
  • 메시지가 반드시 한번 정달되는지 (Exactly Once)
  • 최소 한번 전달되는지 (At least once)
  • 적어도 한 번 이상 전달될 수 있는지 (At most once)
• 확장성
  • 시스템이 부하가 늘어났을때 대응할 수 있는 능력

 

CQRS (Command Query Responsibility Segregation)

 

• 명령(Command)과 조회(Query)를 분리하여 각각 독립저긍로 처리하는 아키텍쳐
• 명력은 데이터를 변경하는 작업, 조회는 데이터를 읽는 작업
  • 구성요소
    • Command Handler : 데이터를 변경하는 작업을 처리, 이때 메시지 큐를 사용해 명령이 큐에 저장되고, 비동기적으로 처리
    • Query Handler : 데이터를 조회하는 작업을 처리. 데이터 조회는 즉각적으로 처리될 수 있지만, 명령은 비동기적으로 처리되어 데이터 일관성을 유지
    • Event Soucing : 모든 상태 변경을 이벤트로 기록하고, 이벤트를 통해 시스템의 상태를 재구성하는 방식

사가 패턴

• 분산 트랜잭션을 처리할 때 사용되는 아키텍쳐 패턴, 각 서비스가 독립적으로 트랜잭션을 처리하지만, 전체 프로세스는 논리적으로 하나의 트랜잭션처럼 보이게 함
• 사가 패턴은 각 서비스에서 처리된 결과를 비동기적으로 전달받아 트랜잭션을 완성하거나 실패했을 경우 보상 작업을 수행
  • 구성 요소
    • Saga Coordinator : 트랜잭션의 시작과 종료를 관리하며, 중간에 트랜잭션이 실패할 경우 보상 작업을 실행
    • Local Transactions : 각 서비스에서 실행되는 독립적인 트랜잭션으로 각 서비스는 메시지 큐를 통해 비동기적으로 트랜잭셔 결과를 전달

백프레셔 패턴

• 시스템이 과부하 상태일때 요청을 거부하거나 처리 속도를 늦추는 방식으로 트래픽을 조절하는 아키텍쳐 패턴
• 비동기 메시징 시스템과 함께 사용되며, 대규모 트래픽 상황에서 시스템의 안정성을 보장하는데 도움
  • 구성 요소
    • 프로큐 셔 : ㅋ큐가 가득차면 백프레셔를 통해 메시지 생산을 중단하거나 늦춤
    • 컨슈머 : 큐에서 처리할 수 있는 메시지ㅡ이 양을 제어, 과부하 방지

Durable Message Pattern

• 메시지를 손실없이 처리할 수 있도록 보장하는 패턴
• 메시지가 중간에 손실되거나 누락되지 않도록 메시지를 저정하고, 시스템 장애 시에도 복구가 가능한 상태로 유지
  • 구성 요소
  • Persistent Queue :메시지가 시스템에 도착하면 큐에 영구적으로 저장, 메시지는 실패 시 재시도 될 수 있으며, 시스템이 복구된 후에도 메시지가 손실도지ㅣ 않음
  • Retry Mechanism : 실패한 메시지를 재처리, 메시지가 손실않도록 보장 

 

 

예시

푸시 알림 시스템에서의 비동기 처리

이벤트 기반 비동기 처리, 메시지 큐와 푸시 시스템, 실시간 알림 처리

쿠폰 발급 시스템에서의 비동기 처리

쿠폰 발급 요청 비동기 처리, 쿠폰 발급 중복 방지 및 순차 처리, 비동기 작업으로 백엔드 처리 최적화

채팅 시스템에서의 비동기 처리

메시지 큐 기반 처리, 실시간 데이터 전송, 다중 사용자 동시 처리

실시간 주문 처리 시스템에서의 비동기 처리

주문 요청 비동기 처리, 재고 관리 시스템과의 비동기 통신, 결제 처리 비동기화

이메일 발송 시스템에서의 비동기 처리

이메일 발송 큐 관리, 실시간 이메일 발송과 대기 처리, SMTP 서버와 비동기 통신