메세지 큐라는 단어는 많이 들어봤고 어떻게 사용해야 하고, 어떻게 사용하는 게 올바른 사용법인지 알아보기 위해 이 주제를 선정했습니다. 멘토님께서 채팅을 사용할 때, 동시성 문제를 해결하기 위해서 Message Queue를 사용할 수 있다고 말씀해주셔서 이에 대해 조사하고 우리 서비스에 적용해볼 수 있다면 적용해보도록 하겠습니다.
그럼 메세지 큐는 언제 쓰는 걸까요?
API는 결국 네트워크로 연결된 컴퓨터들 사이에 통신이 이루어질 때, 모두 한 쪽이 다른 쪽에게 직접, 동기적으로 메세지를 전달한다는 것이었습니다.
동기적이라는 것은 한 쪽이 메세지를 보내면 그 때 다른 쪽에서 수신을 하는 것입니다.
만약 클라이언트가 서버로 데이터를 전달하는 시점에 서버가 꺼져 있거나 과부하 등의 문제가 발생했다면 해당 데이터는 성공적으로 서버에 전달되지 못 하고 데이터가 유실될 가능성이 있습니다.
특히 마이크로 서비스 아키텍처에서는 한 쪽이 여러 대상에게 데이터를 보내야 하는 경우가 많습니다. SNS를 예로 들자면 사용자의 포스트를 담당하는 서비스는 새로운 포스트가 올라오면 Feed 갱신 서비스, 알림 서비스, 통계 담당 서비스, 로그 담당 서비스에 모두 전달해야 합니다.
이들 모두가 송신 및 수신이 가능한 상태에서 모든 전달이 성공적으로 이루어져야 합니다.
받는 쪽마다 필요로 하는 데이터가 다르면 그에 맞춰서 구현을 바꿔야 하고, 받는 쪽에서 작업이 추가되거나 작업이 변경되면 보내는 쪽도 그에 따라 대응을 해야 합니다.
보내는 쪽이 여러개가 되면 더 복잡해지겠죠. 예를 들어 팔로우를 담당하는 서비스, 메시징을 담당하는 서비스, 프로필 수정을 담당하는 서비스 등이 더해지면 아키텍처는 점차 꼬이게 됩니다.
그래서 중간에 Message Queue라는 애를 둬서 보내는 쪽 Producer와 받는 쪽 Consumer라고 불리는 곳으로 각각 보내주게 합니다. Producer는 Consumer에 데이터가 올바르게 도달했는지 신경 쓸 필요가 없어집니다. 그렇기에 자기 일에 집중할 수 있게 됩니다. 데이터를 그냥 Message Queue에 던지는 것이죠.
Consumer는 필요하면 이 Message Queue에서 자기가 필요한 데이터를 찾아서 가져가면 됩니다. Message Queue는 전달 받은 데이터를 지정된 시점까지 보관하는 기능도 있기에 Consumer가 바로 찾아가지 않아도 데이터 유실될 걱정이 없습니다. 모든 전달이 Message Queue를 통해 이루어지기에 설계할 때 수월합니다. 데이터 유실을 막을 수 있고 수평적 확장이 가능한 것이죠.
빠른 응답 보다는 안전한 메세지 전달, 노드 간의 독립성, 확장성을 필요로 하는 서비스 ex) 이메일, 로그 수집, 온라인 결제, 이미지 처리, 마이크로 서비스 등에 유용하게 활용됩니다.
반면 비교적 단순한 시스템 안에서 요청에 대한 즉각적인 응답이 필요한 경우에는 Message Broker는 적합하지 않습니다.