래빗엠큐 - 메시지 발행에서 성능절충

래빗엠큐는 빠른 성능이나 처리량도 중요하지만, 신뢰할 수 있는 메시지 전달도 중요한 지표중의 하나이다.

이번에는 이 두 지표의 상관관계를 알아보고 절충안을 알아보자.

 

빠름 <----> 느림

배달보장 없음 - 실패 통보 - 발행자 확인 - 대체 익스체인지 - HA 큐 - 트랜잭션 - 트랜잭션 HA 큐 - 메시지 디스크에 저장

 

절충안을 찾기 위해 내 시스템을 구성하는 과정에서 확인해 봐야하는 질문들은 다음과 같다.

1. 발행시에 메시지를 큐에 넣는 것이 얼마나 중요한가?
2. 메시지를 라우팅할 수 없는 경우, 발행자에게 메시지를 보내야 하는가?
3. 메시지를 라우팅할 수 없는 경우, 차후에 조정하는 다른 곳으로 메시지를 보내야하는가?
4. 래빗엠큐 서버에 장애가 발생할 때, 메시지가 손실되도 괜찮은가?
5. 래빗엠큐가 메시지를 처리할 때, 요청한 모든 메시지를 라우팅한 후 디스크에 저장하는 작업이 정상적으로 수행했는지 발행자가 확인해야 하는가?
6. 발행자가 메시지를 한꺼번에 전달하면 래빗엠큐는 메시지를 라우팅하고 디스크에 저장한 후 작업이 정상적으로 실행됐는지를 발행자에게 다시 알려야 하는가?
7. 다수 메시지를 라우팅한 후 디스크에 정상적으로 저장됐는지 확인하는 작업을 일괄 처리하는 경우, 메시지를 저장할 큐에 원자커밋이 필요한가?
8. 발행자가 적절한 성능과 메시지 처리량을 달성하는데, 메시지 배달 보장 기능 간에 절충점이 있는가?
9. 메시지 발행의 다른 측면이 메시지 처리량 및 성능에 영향을 미치는가?

 

절충안 솔루션

1. mandatory 플래그 (mandatory = true)

-  Basic.Publish RPC 명령과 함께 전달되는 인수로서, 메시지를 라우팅 할 수 없으면 Basic.Return RPC 를 통해 래빗엠큐가 메시지를 발행자에게 다시 보내도록 지시한다. 

- 이 플래그는 오류감지 모드를 켜는 것으로 간주할 수 있는데, 메시지 라우팅 실패를 알리는데 사용한다.

- 래빗엠큐 브로커의 익스체인지가 메시지를 라우팅할 수 없으면 래빗엠큐는 Basic.Return을 통해 메시지를 보낸 그대로 전체 메시지와 함께 서버로 되돌려진다. (메시지 브로거가 죽은경우는 무쓸모 겠군?)

- Basic.Return 메시지는 비동기로 전달되며, 이 메시지를 전달받으면 실행할 콜백메소드를 등록해야할 수 있다 ( 언어별 라이브러리에 따라 다름. 확인 필요)

 

2. 트랜잭션보다 가벼운 발행자 확인

- 래빗엠큐의 발행자 확인은 AMQP 스펙의 확장 기능이다.

- 발행자는 메시지를 발행하기 전에 래빗엠큐에 Confirm.Select RPC 요청을 전송하고 메시지가 전달 됐는지 확인하기 위해 Confirm.SelectOK 응답을 기다린다. 이 시점에서 발행자가 래빗엠큐에 보내는 각 메시지에 대해 서버는 수신확인(Basic.Ack) 또는 부정 수신 확인 (Basic.Nack) 으로 응답하며 메시지의 오프셋을 지정하는 정수 값을 포함하거나 확인한다. 확인 번호는 Confirm.Select RPC 요청 다음에 수신된 순서에 따라 메시지를 참조한다. 순서는 다음과 같다.

   1) 발행자가 래빗엠큐에 Confirm.Select RPC 요청을 보냄

   2) 래빗엠큐가 발행자에게 Confirm.SelectOK  로 응답

   3) 발행자가 래빗엠큐에 Basic.Publish 를 사용해 메시지를 발행

   4) 래빗엠큐가 발행자에게  Basic.Ack 또는 Basic.Nack 로 응답 ( 이 응답은 비동기로 처리된다 )

- 주의 : 발행자 확인의 사용여부와 상관없이 존재하지 않는 익스체인지에 메시지를 발행할 경우, 채널은 래빗엠큐에 의해 종료된다. 이 경우 Basic.Nack 응답이 아니라 ChannelException 예외가 발생한다.

- 발행자 확인은 트랜잭션과 함게 사용할 수 없으며, AMQP TX 프로세스의 대안으로 가볍고 성능이 뛰어나다. 

- Basic.Ack 와 같은 응답은 비동기적으로 처리되기 때문에 발행자가  확인을 받는 시점이 언제일지 정확히 알 수 없다. 따라서 발행자 확인을 사용하도록 설정한 애플리케이션은 메시지를 보낸 후 언제든지 확인을 받을 수 있어야 한다.

 

3. 라우팅할 수 없는 메시지를 위한 대체 익스체인지 사용하기

- 대체 익스체인지는 처음 익스체인지를 선언할때 명시된다. 

- mandatory = true 인 메시지가 대체익스체인지가 명시된 큐로 라우팅되고 해당 라우팅이 실패해서 대체 익스체인지로 넘어가게되도 발행자는 Basic.Return 을 받을 수 없다. 대체익스체인지에서도 라우팅이 실패했을때 발행자가 Basic.Return 을 받을 수 있는지 확인필요.

 

4. 트랜잭션으로 배치처리 하기

- 래빗엠큐 확장판이 없었을 때 메시지 전달을 보장하기위하 유일한 방법은 트랜잭션이었다.

- AMQP 트랜잭션 클래스는 메시지를 일괄로 래빗엠큐에 발행한 후 큐에 커밋하거나 롤백할 수 있는 메커니즘을 제공한다.

- 존재하지 않는 익스체인지와 같은 오류로 인해 래빗엠큐가 메시지를 라우팅할 수 없으면 트랜잭션 커밋 응답을 보내기전에 Basic.Return 응답이 반환된다. 

- 트랜잭션은 단일큐에서만 사용할 수 있다. 하나의 트랜잭션이 둘 이상의 큐에 영향을 주는 경우 커밋은 원자적으로 동작하지 않는다. 

- delivery-mode = 2 ( 디스크 저장 모드 ) 설정인 경우 원자 트랜잭션은 발행자의 성능에 문제를 일으킬 수 있다. I/O 부하가 많은 서버에서 디스크저장모드와 트랜잭션이 동시에 적용된 경우는 발행자는 매우 많은 시간을 기다리게 될 수 있다. 

 

5. HA 큐를 사용해 노드 장애 대응하기

- 메시지가 큐에 있는 동안 손실되지 않게 하기위해 사용한다.

- 래빗엠큐 팀이 만든 확장 기능중의 하나로, 큐를 여러 서버에 중복해 복사본을 저장하는 기능을 제공한다.

- HA 큐는 클러스터로 구성된 래빗엠큐 환경이 필요하며 AMQP API 또는 웹기반 관리자 UI 로 설정할 수 있다.

- 메시지가 HA 큐로 설정된 큐에 발행되면 HA 큐를 담당하는 클러스터의 각 서버로 메시지가 전송(동기화)된다. 클러스터의 노드가 메시지를 소비하면 다른 노드의 모든 메시지 복사본이 즉시 제거된다.

- HA 큐에는 단일 기본서버 노드가 저장돼 있는데, 기본노드가 실패하면 보조 노드중 하나가 기본노드의 역할을 대신한다. 

- 다운된 노드가 다시 추가되거나 새 노드가 클러스터에 추가되더라도 기존 노드의 큐에 이미 존재하는 메시지는 추가된 노드에 동기화되지 않는다. 대신 이전에 발행한 모든 메시지가 소비되면 모든 새 메시지가 수신되고 동기화된다.

 

6. HA 큐 트랜잭션

- HA 되있는 큐에 트랜잭션 메시지를 보내면 모든 활성노드에 메시지가 동기화된 후에야 성공응답을 보낸다.

 

7. 디스크 저장

- delivery-mode = 2 로 보내면 메시지는 래빗엠큐 브로커 디스크에 저장된다. 래빗엠큐 서버다운 후에도 메시지를 보존하고 싶으면 큐를 만들때 durable 로 선언해야 한다. 

- I/O 성능이 충분하지 않은 서버의 경우 메시지 저장 때문에 극적인 성능 저하가 발생할 수 있다.

- 래빗엠큐는 메시지를 디스크에 기록하고 더이상 큐에 대기하지 않을때까지 참조로 해당 메시지를 추적한다. 메시지에 대한 모든 참조가 사라지면 래빗엠큐는 디스크에서 메시지를 제거한다. 

 

래빗엠큐 푸시백

- 특정 발행자가 너무 많은 메시지를 너무 빨리 래빗엠큐에 전송하는 경우, 래빗엠큐는 그 단일 발행자에게 압도당하지 않기 위해 래빗엠큐 푸시백을 사용해 자신을 보호한다.

- 래빗엠큐 2.0 버전 이하 : 발행자에게 Channel.Flow 명령을 보내 발행자가 메시지를 더이상 보내지 않도록 지시한다.

- 래빗엠큐 3.2 버전 이하 : TCP 배압(Back-Pressure) 매커니즘으로 단일 발행자의 메시지를 수신 중지한다.

- 래빗엠큐 3.2 버전 이상 : 발행자와 커넥션을 맺을 때 발행자에게 "크레딧"을 발행하고 발행자로부터 RPC 명령을 받으면 크레딧을 감소시키고, 연결에 남은 크레딧이 없으면 크레딧이 생길때까지 발행자를 무시한다. 발행자의 연결이 차단된 경우 해당 사실을 발행자에게 알리는 비동기 메소드 (Connection.Blocked) 를 통해 차단 여부를 확인할 수 있다.