지난 글에서는 메시지를 발행하는 과정을 따라가면서 프레임의 단위에 대해 알아 보았다.
이번 글에서는 메시지를 발행할 때 전송하는 프레임 중 콘텐츠 헤더 프레임에는 어떤 속성이 있는지 알아보고 각 속성 별로 사용 방법에 대해 소개하려고 한다.
✅ Header frame 속성, 한 눈에 보기
Header frame 에 포함된 속성은 위 그림처럼 14개의 속성을 포함하고 있다.
지난 글에서 알게된 delivery_mode의 경우, 1로 설정하면 메시지를 디스크에 저장하는 것처럼 AMQP 스펙에서 정의한 의미를 가지는 속성도 있는 한편, 정확한 스펙이 없는 속성도 있다. 그럼 위의 속성 별로 어떤 특징을 가지는지 알아보자.
✔️ content_encoding
- AMQP를 통해 전달하는 메시지는 기본적으로 압축되지 않는다.
- 서버에서 웹 페이지를 압축하는 것처럼 content_encoding 속성을 통해 명시적으로 처리할 수 있다.
- 운영 환경에서는 publisher와 consumer의 메시지 계약(메시지의 포맷과 내용)을 변경하지 않는 것이 바람직하다.
- content_type과 혼동하여 UTF-8로 설정하는 경우가 있는데, AMQP 스펙에 의하면 MIME 콘텐츠 인코딩을 저장하기 위한 것이기 때문에 적절하지 않다.
- consumer에서 클라이언트 라이브러리를 사용하는 경우, 이 속성을 사용해 자동으로 디코딩할 수 있다.
✔️ content_type
- 표준 HTTP 스펙에서 content-type 의 값처럼 메시지 본문 내용의 MIME 유형을 의미한다.
✔️ message_id 와 correlation_id
- AMQP 스펙에서 둘 다 애플리케이션 용도로 지정되어 공식적인 동작은 없다.
- message_id 를 사용해 메시지를 고유하게 식별하고, correlation_id를 사용해 메시지에 대한 응답임을 표현할 수 있다.
- correlation_id의 경우 트랜잭션 ID를 전달하는 데에도 이 속성을 사용할 수 있다.
✔️ timestamp
- timestamp도 애플리케이션 용도로 지정되었다. 이 속성을 메시지 생성 시점으로 기록하면 메시지를 발행할 때 성능 측정이 가능하다.
- unix epoch 와 같은 8바이트 크기의 정수형으로 전송된다.
- 다만 타임존 정보가 없기 때문에 UTC 등의 시간대로 일관되게 사용할 수 있도록 미리 정의할 필요가 있다.
✔️ expiration
- 메시지를 버려야 하는 시점을 관리한다.
- 특이한 점은 구현할 때 사용할 수 있지만 공식적인 동작은 없다는 점이다.
- 또다른 이상한 점으로는 255바이트의 문자열이라는 점이다. 따라서 자동으로 메시지를 만료처리하려면 timestamp와 같은 형식의 unix epoch 값을 사용하되 문자열로 처리해야 한다.
- 이 속성을 사용하는 경우 시간이 만료된 메시지는 큐로 삽입되지 않고 삭제된다.
- 특정 상황에서만 메시지가 만료되는 다른 기능이 있는데, 큐를 선언할 때 x-message-ttl 속성을 인자로 전달해서 만료시킬 수 있다.
✔️ delivery_mode
- 메시지를 디스크에 저장할지 말지를 결정한다.
- 1은 디스크에 저장하지 않고 메모리에서만 관리하고 2는 디스크를 사용하게 된다.
- 메시지의 지속성(persistence) 속성과 큐의 내구성(durable) 속성을 혼동할 수 있으나 둘의 개념이 다르다는 것에 유의해야 한다.
✔️ app_id
- AMQP 스펙에서는 app_id는 255바이트의 문자열로 정의하고 있다.
- 메시지를 처리하기 전 그 출처를 관리하거나, 통계 데이터로 수집하는 등의 활용이 가능하다.
✔️ user_id
- 사용자를 식별하기 위한 용도로 사용하기 좋아보이지만 대부분 권장되지 않는다.
- 연결된 유저와 일치하는 경우에만 발행하게 된다.
✔️ type
- type도 애플리케이션 용도로 지정되어 있다.
- self-describing 메시지를 만들 때, 메시지 본문이 직렬화 되지 않은 경우 유용하게 사용할 수 있다.
✔️ reply_to
- 애플리케이션 용도로 지정되어 있다.
- 이 속성을 사용해 작업 결과에 따라 동적으로 다음으로 실행할 큐나 메시지가 원래 발행된 익스체인지의 응답 키를 전달하는 데에 사용할 수 있다.
✔️ headers
- key-value 구조로 사용할 수 있는 자유로운 테이블이다.
- 이 속성을 통해 원하는 어떤 데이터를 추가하고 전달하고 메시지를 라우팅할 수 있다.
✔️ priority
- RabbitMQ에서는 이 속성을 unsigned byte로 구현해 0~255 사이의 값을 지정할 수는 있지만 AMQP 스펙과의 상호 운용을 위해 0~9 사이의 값을 사용해야 한다.
- 0일수록 우선순위가 높고, 우선순위가 높은 메시지가 먼저 처리된다.
✔️ cluster_id
- AMQP 0-8 스펙에서는 이 속성을 정의했지만 차후에 제거되었으며 RabbitMQ에서는 동작이 구현되지 않았다.
- 가급적 사용하지 않는 게 좋다.
✅ 나가며
이번 글에서는 아래 내용에 대해 알아보았다.
- 메시지를 발행할 때 헤더에 어떤 속성을 정의할 수 있는지
- 속성 별로 어떻게 동작하는지
- 속성 별 사용 사례
다음 글에서는 rabbitMQ에서 메시지를 발행할 때 delivery를 어떻게 보장하는지에 대해서 알아볼 예정이다.
✅ 참고 문서
- 📚 Gavin M. Roy, RabbitMQ In Depth
- RabbitMQ AMQP.BasicProperties
'개발 > Backend' 카테고리의 다른 글
authentication & authorization (0) | 2025.02.16 |
---|---|
[RabbitMQ] AMQP 통신 과정 속 프레임 구조 이해하기 (0) | 2025.02.02 |
[RabbitMQ] RabbitMQ란 (0) | 2025.01.19 |
모르면 손해보는 git rebase (1) (3) | 2024.10.13 |
HTTP/3, HTTP over QUIC (0) | 2022.07.24 |