메시지 큐란?

먼저 큐에 대한 설명을 해야 할 것 같다.

큐(Queue)란?

자료구조의 한 유형인 큐는 데이터가 삽입되고 삭제되는 순서가 먼저 들어온 순으로 부터 나중에 들어온 순서대로 삭제가 된다. 그림으로 보면 아마 이해가 쉬울 것이다.

Queue의 구조

삽입된 순서 대로 1, 2, 3 번호를 가진다고 했을 때 저런 원통형 구조로 1번이 먼저 삭제 2번이 그 후 3번이 마지막으로 삭제가 된다.

데이터가 삽입된 순서대로 삭제되는 선입선출(FIFO, First In First Out) 구조이다.

큐는 원통 양쪽이 뚫려있는 구조라고 생각하면 되며, 한쪽에서는 데이터의 삽입만 이루어지고, 한쪽에서는 데이터 삭제만 이루어진다.

데이터가 삽입되는 동작을 enQueue, 또한 데이터가 삭제되는 동작을 deQueue라고 한다.

데이터가 가장 처음 들어온 위치를 front, 데이터가 가장 마지막에 들어온 위치를 rear라고 한다.
그림으로 설명하자면 front가 1 rear가 3이 될것이다.

그렇다면 메시지 큐란 무엇인가?

메시지 큐란?

메시지 큐의 정의를 찾아보면

메시지 대기열은 서버리스 및 마이크로 서비스 아키텍처에 사용되는 비동기식 서비스 대 서비스 통신 형태입니다. 메시지는 처리되고 삭제되기 전까지 대기열에 저장됩니다. 각 메시지는 하나의 소비자가 한 번만 처리합니다. 메시지 대기열은 규모가 큰 처리 작업을 결합 해제하고, 버퍼링 또는 배치 작업을 수행하고, 급변하는 워크로드를 원활하게 지원하는 데 사용될 수 있습니다.

정의를 확인해보면 대용량 배치작업이나 채팅 서비스와 같이 비동기적이고 많은 데이터를 처리하는 데 쓰임을 알 수 있다.

메시지가 처리되고 삭제되기 전까지 대기열에 저장되기 때문에 프로세스나 연결이 중단 되더라도 시스템이 계속 작동할 수 있게 한다. (비동기식 메시징을 이용)

개발자는 프로세스와 애플리케이션을 분리하여 통신을 자체 포함하고 이벤트 기반으로 유지해 아키텍처의 안정성을 강화할 수 있다.

당장 실행해서 값을 얻어야하는 서비스보다 나중에 값을 얻으며 다른 동작을 행해도 문제가 없는 서비스에 쓰인다.

메시지라함은 요청, 응답, 오류 메시지 또는 단순 정보 등의 작은 데이터도 될 수 있다.

 그렇다면 메시지 큐를 어느 서비스에서 이용할까?

• 이메일 전송
• 블로그 포스팅
• 메신저

메시지 큐의 장단점

장점

• 비동기 통신 : 생산된 메시지의 저장, 전송에 대해 동기화 처리를 진행하지 않고, 큐에 넣어 두기 때문에 나중에 처리 가능하다.
• 낮은 결합도 : 메시지 생산자와 소비자는 서로 분리 돼 전체 시스템에 영향을 줄 상황이 없다. 그래서 구성 요소를 쉽게 수정하거나 교체 가능하며 유연성과 유지 관리가 용이해진다.
• 로드 밸런싱 : 메시지 큐는 여러 소비자에게 워크로드를 분산시킬 수 있다. 여러 소비자가 대기열에 연결된 경우 메시지는 서로 다른 소비자가 동시에 처리할 수 있어 시스템 성능을 향상할 수 있다.
• 내결함성 : 메시지 대기열은 메시지 내구성을 보장하여 내결함성을 제공한다. 메시지는 일반적으로 사용되기 전에 내구성 있는 저장소에 보관 되므로 장애 발생 시 메시지가 손실되지 않도록 보호된다.
• 확장성 : 수평적 확장성을 용이하게 한다. 더 많은 소비자를 추가하면 시스템의 처리 용량을 늘릴 수 있다. 또한 메시지 대기열은 종종 메시지 분할 또는 샤딩을 지원하여 메시지를 여러 대기열 또는 브로커에 분산시켜 확장성을 더욱 향상시킴.

단점

• 복잡성 증가 : 메시지 직렬화, 라우팅 및 메시지 오류 처리가 필요하므로 시스템에 추가 복잡성이 생긴다. 이런 복잡성으로 인해 개발 및 디버깅이 어려워질 수 있다.
• 잠재적인 메시지 주문 이슈 : 비동기식 메시징은 주문 문제를 일으킬 수 있다. 여러 소비자가 동시에 메시지를 처리하는 경우 메시지가 순서 없이 소비될 수 있다.
• 메시지 중복 : 때때로 메시지가 중복 될 수 있다. 넽워크 또는 시스템 오류로 인해 메시지가 두 번 이상 전달될 수 있다. 소비자는 데이터 무결성을 보장하기 위해 중복 메시지를 처리하도록 설계되어야 한다.
• 대기시간 증가 : 메시지 큐를 사용하면 동기식 통신해 비해 대기 시간이 추가된다. 메시지를 게시, 저장 및 소비해야 하므로 처리 시간이 추가될 수 있다. 일반적으로 대기 시간이 짧지만 실시간 또는 실시간에 가까운 통신이 필요한 애플리케이션에 영향을 미칠 수 있다.
• 운영 오버헤드 : 메시지 대기열을 관리하고 운영하려면 추가 인프라와 리소스가 필요하다. 대기열 시스템을 설정 및 유지 관리하고, 상태를 모니터링하고, 확장성 문제를 처리하고 효율적인 리소스 활용을 보장해야 한다. 

 

[참조] : 

https://leejinseop.tistory.com/36

https://velog.io/@cha-suyeon/%EC%9E%90%EB%A3%8C%EA%B5%AC%EC%A1%B0-%ED%81%90Queue%EC%9D%98-%EA%B8%B0%EB%B3%B8-%EA%B0%9C%EB%85%90-%EA%B5%AC%EC%A1%B0-%EA%B0%84%EB%8B%A8-%EA%B5%AC%ED%98%84Python#1-%EC%83%9D%ED%99%9C-%EC%86%8D-%ED%81%90

https://www.ibm.com/kr-ko/topics/message-queues

https://tecoble.techcourse.co.kr/post/2021-09-19-message-queue/