Celery & RabbitMQ 너 뭐 돼?

방학 때 진행한 프로젝트에서 Celery와 RabbitMQ를 적용하게 되었다.

우리 프로젝트를 간단하게 설명하자면 ChatGPT를 활용해서 실시간 음성채팅하는 서비스이다. 장고를 사용해서 AI와 같은 무거운 작업을 실행해야 했다. 이런 무거운 작업들을 Celery Task로 정의해서 Broker(RabbitMQ)와 Consumer(Celery Worker)를 이용해 비동기적으로 처리하여 사용자에게 빠른 응답을 제공해줬다.

그렇다면 Celery와 RabbitMQ를 왜 적용했는지, 이것들이 무엇인지에 대해 설명하려고 한다.

---

Celery에 대해 자세히 알아보기 전에 동기와 비동기에 대해 먼저 짚고 넘어가자

동기

• 첫 번째 손님이 아메리카노를 시켰다.
• 두번째 손님은 첫 번째 손님의 커피가 나올 때까지 기다려야 한다
• 즉 앞의 손님의 주문이 완료될 때까지 뒤의 손님은 계속 기다려야 한다.

비동기

• 카운터에서 첫번째 손님의 커피주문을 받고 손님은 진동벨을 받은 뒤 커피를 기다린다.
• 첫 번째 손님의 커피는 나오지 않았지만 카운터에서 두 번째 손님의 주문을 받는다.
• 진동벨이 울리면, 첫번째 손님이 카운터로 와 커피를 받아간다.
• 즉 손님들의 요청을 계속 받으면서 요청한 결과를 처리한다.

동기(synchronous)란?

• 요청을 보낸 후 응답을 받아야지만 다음 동작이 이루어지는 방식을 말한다
• 모든일은 순차적으로 실행되며 어떤 작업이 수행중이라면 다음 작업은 대기하게 된다
  • 설계가 간단하고 직관적인 반면, 결과를 볼 때까지 아무것도 못하고 대기해야 한다

비동기(Asynchronous)란?

• 동시에 일어나지 않는다. 즉, 요청과 결과가 동시에 일어나지 않는 거라는 약속을 말하고 요청한 그 자리에서 결과가 주어지지 않는다.

• 노드 사이의 작업 처리 단위를 동시에 맞추지 않아도 된다.

  • 결과가 주어지는 데 시간이 걸리더라도 그동안 다른 작업이 가능해 자원의 효율적인 사용이 가능한 반면, 설계가 동기보다 복잡하다

  예를들어

  • 파일을 읽거나 쓰기처럼 오래걸리는 작업
  • ajax 통신작업
  • Dom의 이벤트 처리 작업
  • 일정 시간 뒤에 동작을 해야 하는 작업

그렇다면 비동기는 왜 필요할까? 🤔

온라인 쇼핑 사이트가 있다고 가정해보자. 사용자가 주문을 완료했을 때, 여러 작업이 동시에 발생 할 수 있다.

사용자의 결제 정보를 검증하고 결제를 완료한다 → 사용자에게 주문 확인 이메일을 보낸다 → 구매된 상품의 재고를 업데이트한다

• 만약 동기적으로 처리된다면?
  • 서버는 사용자가 모든 작업이 완료될 때까지 기다려야한다. 즉 결제 검증이나 이메일 발송에 문제가 발생하면 전체 주문 프로세스가 지연되거나 중단된다.
• 비동기로 처리한다면?
  • 주문 처리와 같은 메인 작업이 바로 완료되고 이메일 발송이나 결제 처리와 같은 비동기 작업은 백그라운드에서 독립적으로 실행되며 다른 작업들 또한 계속 처리할 수 있다.

비동기 처리를 하면 사용자는 시스템이 빠르게 반응하는 것을 경험할 수 있고 서버는 다양한 작업을 동시에 처리할 수 있다. 그렇게 되면 사용자 수가 증가해도 성능이 유지된다.

Task Queue

• 스레드 또는 머신에 작업을 분산시키기 위한 메커니즘이다. 테스크라는 하나의 작업 단위를 입력으로 받고 전담 워커 프로세스를 새로운 작업을 수행하기 위해 테스크 큐를 지속적으로 모니터링한다.
  • 일을 처리하기 힘든 대용량의 데이터를 큐라는 작업 공간에 임시로 보내어 대용량의 작업을 나누어 순차적으로 처리하게 됨
• 테스크 큐를 도입하면 구조가 복잡해지기는 하지만 사용자 경험 측면에서 봤을 때 매우 큰 도움이 된다. 특별한 코드에서 병목 현상이 나타날 경우 더 많은 CPU가 가능할 때 까지 해당 코드 실행을 잠시 미뤄 둘 수 있다.
• Celery는 보통 클라이언트와 워커 사이를 중재하는 브로커를 사용하여 메시지를 통해 통신한다. 테스크를 시작하기 위해 클라이언트는 큐에 메시지를 추가하고 브로커는 워커에게 메시지를 전달한다.

어떨 때 필요한건가?

• 어떤 작업을 처리하는데 시간이 걸린다 → Task Queue 이용
  • 단체 이메일 보내기
  • 파일 수정 작업(이미지 포함)
  • 3rd party로 부터 다량의 데이터 가져오기
  • 테이블에 많은 양의 레코드를 추가하거나 업데이트 하기
  • 긴 시간을 요구하는 연산
  • 웹훅(webhook)을 보내거나 받기
    => 트래픽이 많은 사이트의 경우 모든 작업 내용에 대해 태스크 큐가 필요함
    
    
• 사용자에게 결과를 바로 제공 해야 한다 → Task Queue 이용 x
  • 사용자 프로필 업데이트
  • 블로그나 CMS 엔트리 추가
    => 트래픽이 작거나 중간 정도인 사이트의 경우 이러한 여러 작업 내용에 상관 없이 태스크 큐를 이용할 필요가 없음

Celery란?

• 분산 메시지 전달을 기반으로 동작하는 비동기 작업 큐이다.
• 웹 서비스를 하면 응답을 받기 오래 걸리는 작업이 종종 있다. 이 때 사용자는 응답을 받기 위해 오랜 시간을 기다려야 한다. 보통 웹 서비스에서 응답 시간은 서비스의 생명과 직결되므로 비동기로 작업을 처리하게 넘기고 바로 응답하는 경우가 많다. Celery는 그 작업을 할 수 있도록 도와주는 파이썬 프레임워크이다. 보통 worker라고 부른다.
• Worker는 웹 서비스에서 백단의 작업을 처리하는 별도의 프레임이며 사용자에게 즉각적인 반응을 보여줄 필요가 없는 작업들로 인해 사용자가 느끼는 Delay를 최소화하기 위해 사용된다.

그럼 비동기 작업과 분산 메시지 전달은 어떤 관계가 있을까?

즉각적인 응답을 제공하기 어려운 작업을 수행할 때 활용할 수 있다. 예를 들어 대용량 작업을 동시에 처리하거나 사용자 요청(HTTP)에 무거운 연산이 포함되는 경우를 들 수 있다
보통 비동기 작업을 요청하고 나면 즉시 응답을 받지 않아도 계속 다른 일을 수행할 수 있기 때문에 동시 작업이 가능하다.
하지만 작업마다 소요되는 시간도 다르고, 실행 환경도 달라 중복 작업이 발생하지 않아야 하며 작업이 누락되지 않도록 하는 것도 매우 중요하다

왜 Celery 인가?

• Django로 API 서버를 개발하고 운영하면서 사용자 요청에 포함될 필요가 없는 불필요한 과정이나 매우 무거운 쿼리 실행을 포함하는 경우가 있다.
  • 회원 가입 축하 이메일 발송, 주문 내역 엑셀 다운로드 등
• 이런 API에 포함된 외부 연동이나 무거운 작업들은 Celery Task로 정의해서 Broker(RabbitMQ)와 Consumer(Celery Worker)를 이용해 Async하게 처리하여 사용자에게 가능한 빠른 응답 결과를 제공할 수 있다.

Celery 동작 구조

• 웹 서비스(Django)에서 발생한 요청(Task)를 Message Broker에서 받아 Celery를 이용하여 분산 처리를 진행한다. Celery에서는 작업이 완료되는 특정 이벤트에 DB Task를 수행한다.
  • Django에 등록한 task를 Message Broker로 보낸다 → task를 celery에서 비동기 처리한다
• 즉 Celery를 사용하기 위해서는 Message Broker가 필요한데 대표적으로 Redis와 RabbitMQ가 있다.

Message Broker?

• 태스크들이 보관되어 있는 장소
• 송신자의 이전 메시지 프로토콜로부터 메시지를 수신자의 이전 메시지 프로토콜로 변환하는 중간 모듈이다.
• Kafka, ActiveMQ, OpenMessage Queue, RabbitMQ, Redis 등
• 데이터를 지속적으로 보관할 수 있는 도구라면 무엇이든지 이용할 수 있으나 장고에서는 RabbitMQ와 Redis가 가장 일반적으로 쓰임

RabbitMQ

• 메시지 브로커로 큐에 메시지를 저장하고 있어서 메시지가 생성된 후 워커 또는 소비자가 준비가 되었을 때 메시지를 전달할 수 있다.
• 응용프로그램에게 메시지를 주고 받을 수 있으며, 메시지가 수신될 때까지 안전하게 있을 수 있도록 공용 플랫폼을 제공한다.
  • 메시지를 다른 대기열로 보낼 수 있는 라우팅 시스템을 갖추고 있음
  • 우선 순위가 높은 메시지를 먼저 사용하기 위해 작업자가 사용할 수 있는 메시지의 우선 순위를 지원함
  • 메시지 브로커로서 Redis와 비교할 때 훨씬 더 다양한 기능을제공함
  • 크고 복잡한 메시지에 적합

⇒ 복잡한 라우팅을 유연하게 처리해야하고, 정확한 요청-응답이 필요한 Application을 쓸 때 또는 트래픽은 작지만 장시간 실행되고 안정적인 백그라운드 작업이 필요한 경우이기에 RabbitMQ를 쓰게 되었다.

왜 Celery & RabbitMQ인지?

Redis도 빠른 성능을 제공하지만 왜 RabbitMQ를 사용했는지 알아보자.

1. RabbitMQ의 지속성, 고급 기능 및 확장성은 실시간 대규모 통신이 필요한 음성 채팅 애플리케이션에 더 유리할 수 있다.
2. 비동기 처리
   • 우리의 서비스에서 실시간으로 사용자의 요청에 대응해야했다. Celery를 이용하면 장고 서버가 직접 처리하기 어려운 AI 작업을 비동기적으로 처리하여 서버의 부하를 줄이고 사용자 경혐을 향상시킬 수 있다
3. 분산 시스템 및 확장성
   • RabbitMQ를 통해 여러 Celery 워커가 작업을 수행할 수 있도록 메시지를 안정적으로 분배한다. 이는 작업 처리량을 늘리고, 시스템의 고장에 대한 내성을 높인다.
   • 트래픽이 증가하면 RabbitMQ와 Celery 시스템을 확장하여 더 많은 작업을 처리할 수 있다.
4. 실시간 음성 채팅 서비스라는 특성상 메시지의 신뢰성과 내구성이 중요한데 분산 시스템 환경에서의 확장성과 유연성이 요구된다.
   1. 음성 채팅 데이터와 같은 중요 정보를 처리할 때 RabbitMQ의 메시지 지속성 기능은 데이터의 안전을 보장하고 시스템 장애 시에도 유실을 방지한다
   2. 복잡한 라우팅이나 다중 구독자 환경에서도 유연하게 관리할 수 있다. 특히 실시간으로 다수 사용자 간에 통신이 이루어지면 매우 중요하다