4장 분산 메시지 큐

[HaeUlNam]

• 메세지 format: Avro, Protobuf, String/JSON등을 자주 쓰는 듯. Avro/Protobuf는 binary format이니깐 성능상에 이점이 확실히 있을 듯. 다만, 조직 내에서 하나의 format으로 정하고 쓰는게 낫지 않나라는 생각..?
• 메세지 전달 방식: At-most-once, at-least-once, exactly-once
  • at-least-once, exactly-once를 선택할 텐데 Idempotent 처리를 신경쓰는 게 중요할 듯
  • Producer에서 enable.idempotent=true를 설정하면 Topic에 메세지가 하나 들어가는 것은 보장할 수 있지만, Consumer 측의 idempotent는 다른 문제. Offset을 commit하는 과정에서 네트워크 이슈등이 있을 수 있음.
  • https://dzone.com/articles/exactly-once-semantics-with-apache-kafka-1
  • https://huisam.tistory.com/entry/kafka-message-semantics
• Q. Producer의 id 기준으로 순차적으로 consumer에서 처리하는 것을 보장하려면 어떻게 할 수 있을까?
  • A. Consumer에서 일단 DB table에 저장하고, 다른 Job을 돌려서 id 순차적으로 처리?
  • Producing하는 기준으로 하면 Key 기반으로 같은 파티션에 두도록 하면 가능. 이 또한 실패해서 재시도 처리할 때 메세지 순서가 뒤바뀔 수 있음 (Transactional outbox pattern 등을 통해 해결 가능 - https://ridicorp.com/story/transactional-outbox-pattern-ridi/)
• WAL(Write-Ahead Log): 새로운 항목이 추가되기만 하는 append-Log 일반 파일. 순차적일 때 디스크는 아주 좋은 성능을 보인다. 하나의 파일이 무한정 커질 수는 없으니 세그먼트 단위로 관리할 수도 있을 듯.
• 일괄처리
  • 여러 메세지를 한번의 네트워크 요청으로 전송할 수 있어서 값비싼 네트워크 비용 제거
  • 한번에 쓰는 것이 더 효율적
• Q. Polling vs Long Polling?
• Consumer rebalancing: 어떤 소비자가 어떤 파티션을 책임지는지 다시 정하는 프로세스
• Zookeeper: Hierarchial key-value store
  • Kraft는 Zookeeper없이 구동하는 것인데, Quorum controller를 이용하는데 meta데이터등을 Broker 각각에 복제한 것 같음? 확실히 중지시간 등 성능이 좋긴 한 것 같음
  • https://developer.confluent.io/learn/kraft/
• 복제: 하드웨어 장애등으로 인한 문제를 해결하기 위해 복제를 하는데, 여러 브로커에 특정 토픽의 파티션을 복제해둔다.
  • ISR(In-Sync Replicas): 리더와 동기화된 사본을 일컫는 용어. 몇가지 기준(replica.lag.time.max.ms, replica.lag.max.messages) 을 충족시키기 못하면 ISR에서 추방당하고 리더 자격도 박탈하게 됨.
  • ACK=all: 모든 ISR이 메세지를 수신한뒤에 Producer에게 ACK 응답
  • ACK=1: 리더가 메세지 저장하면 바로 ACK 응답
  • ACK=0: at-most-once. 지표 수집이나 데이터 로깅 등 처리해야 하는 메세지 양이 많고 데이터 손실이 가끔 있어도 괜찮은 경우에 좋다.
• Tag based message filtering:
  • 주문 시스템은 토픽에 주문과 관련된 모든 활동을 전송할 것이지만, Payment 시스템은 결재나 환불 관련 메세지에만 관심이 있을 것. 이런 요구사항이 등장할 때마다 분리해주는 것은 생산자와 소비자의 결합도를 높일 수 있고, 낭비일 수 있다.
  • 메세지마다 tag를 두고 원하는 tag만 구독하도록 메세지를 필터링

→ 과연 좋은 설계일까? 주문/결제와 같은 Critical path는 오히려 명확하게 분리하는 게 더 나을 수도 있을 것 같다는 생각이..

[minkukjo]

끄적끄적

• 메시지 큐 시스템을 설계해보자

(전통적인 MQ의 형태)

(이벤트 스트리밍 플랫폼의 형태)

• 크게 고려해야할 사항은 두 가지
  • 전통적인 메시지 큐의 형태인가? ( Rabbit MQ )
  • 이벤트 스트리밍 플랫폼인가? ( Kafka )
• 여기서는 Kafka에 가까운 플랫폼을 설계하는 것이 목표
• Rabbit MQ와 같은 플랫폼은 메시지 보관에 대해서 중요하게 생각하지 않는다고 함. ( 일정 시간만 메모리에 저장 )
• 데이터 저장을 위해서는 다음과 같은 것들을 고려해볼 수 있다
  • 데이터베이스
  • WAL(쓰기 우선 로그) : 파일에다 대고 계속해서 쓰는 형태, 메시지 로그를 저장하기에 적합한 형태다.
• 메시지는 일반적으로 생산자든 소비자든 일괄 처리를 하는 편이다. buffer를 두고 여러 명령들을 한꺼번에 보내고 읽는 형태
• 주키퍼..에 대한 내용이 나오는데 최신 카프카에서는 주키퍼를 사용하지 않으므로 그냥 주키퍼의 개념 정도만 알고 넘어가도 충분할 듯.
• 메시지 소비 방식
  • At least once : 같은 메시지가 한 번 이상 전달될 수 있으나 메시지 소실은 발생하지 않음, 중복 처리의 발생 가능성 있음
  • Exactly once : 구현하기 까다로움. 정확히 한번만 전송되는 것을 보장하는 형태
  • At most once : 최대 한 번 메시지를 전달하는 형태. 유실되어도 재발송은 없음
• 전반적으로 이번 챕터는 메시지 큐에 대한 내용이 많았던 것 같음