간단한 메시지 큐는 Rebus로
세줄요약
배보다 배꼽이 큰 일반적인 기술 선택 조언
분산 시스템에서 message queue를 도입하려는 이유는 다양하다. 하지만 스택 오버플로를 비롯한 어디에 물어봐도 사람들이 추천하는 message queue 시스템/라이브러리는 거의 다음 중 하나이다.
- RabbitMQ
- 클라우드 메시지 서비스(Azure Service Bus, Azure Storage Queue 등)
이들의 공통점? 다 분산 시스템에서 별도의 구성요소란 것이다.
굳이 그러는 이유? 확장성(Scalability) 때문에…
한동안 마이크로 서비스 약이 잘 팔려서 웹에서는 확장성이 필수요소인 것처럼 착각하지만 대부분의 경우, 틀린 말이다. 오히려 시스템을 구성하는 부품이 많아지면 라이브 장애가 많아진다. 예를 들면 다음과 같다.
- SLA가 99%인 서비스가 1개면 1년에 다운타임이 53분
- SLA가 99%인 서비스가 2개면 1년에 다운타임이 106분 (2배)
하지만 이보다 더 큰 문제는 개발이 더 어려워진다는 것이다. 원래대로라면 비주얼 스튜디오만 열어서 실행하면 곧바로 개발/디버깅이 가능한 프로젝트였는데 이제는 별도의 메시지 큐를 설정해줘야 한다. 그외 기타 등등…
아, 물론 비용도 더 들어간다. Azure Service Bus의 문서 + 가격표를 보면 메시지 전달이 push 방식인 것처럼 보이지만(따라서 메시지 수가 많지 않으면 비용이 별로 안 들 것처럼 보이지만) 사실 폴링(엄밀히 말하면 30초 단위 long-polling) 방식으로 돈다.
따라서 listener 한 명 당 최소 하루에 ~2,880번씩 연산을 하며 이걸 금액으로 환산하면 basic-tier의 SQL 서버 하나 사용하는 것이 훨씬 싸다!
확장성이 필요없는 경우의 메시지 큐 선택지
그렇다면 당장 확장성이 필요없는 제품을 만든다면? (참고: 이 글을 보는 개발자의 90% 이상이 여기에 포함) 그래도 메시지 큐가 필요할까?
그렇다. 어쩔 수 없이 외부 시스템에 요청을 넣거나 받을 때가 있는데 그럴 땐 내 코드 외의 다른 요인 때문에 제대로 메시지 처리를 못하는 경우가 있다. (예: 메시지 유실, 메시지 처리하다가 서버가 죽음 등) 이럴 때는 메시지를 다시 전달(retry) 해야 하는데…
메시지 큐가 바로 이때 메시지 전달을 보장하는 역할을 한다. 사람들이 자꾸 헷갈리는 거 같은데 메시지 큐의 가장 핵심 기능이다. 확장성이 아니라…
-
race condition을 가장 확실히 잡는 기술인 SQL 서버 위에 제대로 코드만 작성해도 이런 기능은 구현할 수 있다. SQL 서버야 이미 존재하는 기술이고 다들 쓰고 있어서 문제없지만 제대로 된 메시지 큐 로직을 작성하는 일을 피하고 싶다고?
-
그렇다면 오픈소스 메시지 큐 라이브러리인 Rebus를 쓰면 된다. Rebus는 핵심 로직 라이브러리 + 선택 가능한 여러 저장소 라이브러리로 제공된다. 당연히 SQL 저장소 라이브러리도 있다. (확장성이 별로라는 주의도 큼지막하게 박혀있음)
메시지 큐 시스템은 실제 개념이 매우 간단하고, 기능이 정형화되어 있는 설계라 외부 라이브러리의 완성도도 높다. 따라서 개인적으로 2번을 추천한다.
나중에 확장성이 필요해지면?
Rebus 저장소로 Azure Service Bus나 RabbitMQ도 사용할 수 있다. 이럴 경우 그냥 SQL 저장소 라이브러리 대신 다른 저장소 라이브러리를 사용하면 끝이긴 한데…
성능을 고려하면 굳이 Rebus + Azure Service Bus 등을 사용할지는 모르겠다. 확장성이 필요하면 그냥 Azure Service Bus만 사용하지. Rebus를 Azure Service Bus로 변환하는 과정은 그리 어렵지 않다.
TOP 1% 프로그래머 테크트리 | MIT급 컴공인강 | 코딩 독학순서
야근 없이 오직 실력으로 대우받는 프로그래머가 되고 싶다고요? 최저시급도 안 되는 수업료를 내고 최고연봉을 받는 프로그래머가 되세요!