11장: 스트림 처리

[LOG-INFO]

1) Batch Service vs Stream Service

• Batch: 크던 작던 크기가 정해진 데이터를 일괄 처리
• Stream: 끝이 정해지지 않은 데이터의 흐름을 처리

2) Glossaries

• Producer (=Publisher, Sender): 메시지를 발행하는 주체
• Consumer (= Subscriber, Recipient): 메시지를 받아서 처리하는 주체
• Topic: 관련 메시지들을 묶은 개념

3) 메시징 시스템의 종류

3-1) 생산자에서 소비자로 메시지 직접 전달

• UDP Multicast
• ZeroMQ
• StatsD
• BruBeck
• Service Callback URL

3-2) Message Borker

• JMS(Java Message Service) or AMQP(Advanced Message Queueing Protocol)
  • RabbitMQ
  • ActiveMQ
  • IBM MQ
  • Azure Service Bus
  • Google Cloud Pub/Sub

특징

• 보통은 메시지 발행 후 메시지를 삭제한다

3-3) Log-based Message Broker

• Apache Kafka
• Amazon Kinesis Stream

특징

• 메시지 발행 후에도 메시지를 유지한다
  • 유지를 위해 메시지를 Disk에 저장
• Disk에 저장해서 처리량이 낮아질 수 있지만, Partitioning을 통해 처리량(Throughput) 확보
• Replication을 통해 가용성(Availability) 확보
• 모든 메시지에 Offset 부여
• HOL(Head-of-Line) Blocking이 발생할 수 있다

  • Kafka Parallel Consumer를 통해 어느정도 해결 가능

  • confluentinc/parallel-consumer
  • Kafka에서 파티션 증가 없이 동시 처리량을 늘리는 방법

  • p.445의 밑에 주석에 보면 다른 방법으로는 스레드 풀을 사용해 메시지 처리를 분산할 수 있다. 하지만 이 방법은 소비자 오프셋 관리가 복잡하다라는 문구가 있는데, 이것을 parallel consumer가 대부분 해결해주었다

끄적끄적

• p.447. 오래된 메시지 재생. 메시지를 재처리하기 위해 다른 위치에 출력을 기록할 수 있다

  • Kafka Offset 변경 방법

  • Kafka CLI

  • Java SDK

  • 별도 Admin UI

• CDC(Change Data Capture): DB에서 저수준으로 추출
• Event Sourcing: Application에서 비즈니스 로직 결과 추출

  • *

• CQRS(Command Query Responsibility Segregation)
• p.462. Stream을 정렬하는 방법

  • 우선순위큐를 이용하는 방법으로 가능할 듯

• p.466. 이벤트 시간 대 처리 시간

  • 실제로 이벤트 순서가 중요한 비즈니스에서 이벤트 발생 순서와 컨슘 순서가 다른 경우가 꽤 많음

  • consume 시간을 보지 않고 publish 시간을 봄

• p. 467. 그림 11-7.

  • 처리 시간 기준으로 측정된 요청률 = Consumer Rate

  • 실제 요청률 = Producer Rate

  • 현재시각 - publishedAt dashboard는 Kafka Consumer Group Rebalancing마다 튐. (당연히 배포할 떄마다 튐)

  • 완화하기 위해 Cooperative Rebalancing 도입해볼 예정

• p.475 멱등성(Idempotence)

  • 멱등성 중요. 언제든 재처리 가능.

  • 그런데 Downstream이 있는 경우 나만 멱등하면 안되고, Downstream도 멱등해야 함.

[MinJunKweon]

• 생산자(Producer), 발생자(Publisher), 발송자(Sender)는 이벤트를 만든다.

• 소비자(Consumer), 구독자(Subscriber), 수신자(Recipient)는 이벤트를 처리한다.

• 스트림 시스템에서는 토픽(Topic)이나 스트림(Stream)으로 관련 이벤트를 묶는다.

• 메세지 브로커의 이점

  • 클라이언트의 상태 변경(접속, 접속 해제, 장애)에 쉽게 대처할 수 있다.
  • 브로커가 장애로 중단됐을 때도 메시지를 디스크에 기록하게 되면 유실되지 않는다.
  • 메모리에만 메시지를 보관하는 브로커는 유실될 수 있다.
  • 소비 속도가 느리면 브러커는 큐에 제한 없이 계속 늘어나게 한다.
  • 메시지를 버리거나 배압을 하지 않는다. 다만, 이는 설정으로 변경할 수도 있다.

끄적끄적

• CDC를 위해서 변경 스트림용 API 지원하는지 처음알게됨

[HaeUlNam]

• “스트림”은 시간 흐름에 따라 점진적으로 생산된 데이터
• Polling vs Pushing
  • Polling을 하면 consumer 입장에서 원하는 만큼만 가져올 수 있기에 이를 통해 부하를 조절할 수 있다. Kafka, AWS SQS 등과 같은 distributed queueing system에서 이러한 식으로 컨트롤한다.
  • Pushing을 하면 consumer 입장에서는 이벤트를 바로 알 수 있다. 즉각적인 액션이 취해져야 하는 경우 유용하다. AWS SNS(Simple Notification Service) 등이 이에 포함될 수 있다.
• Consumer read pattern
  • Load balancing: 여러 소비자가 하나의 토픽을 소비하는 작업을 공유
  • Fan out: 각 메세지를 복수 개의 소비자로 전달
  • Kafka에서는 일반적으로 Load balancing과 Fan out을 같이 사용한다고 볼 수 있을 것 같다. 같은 소비자 그룹 내에서는 Load balancing을 하지만, 서로 다른 소비자 그룹에서는 Fan out.
    • 다만, AWS SQS를 사용할 때는 SNS를 같이 사용해야 한다. 기본적으로 SQS가 단일 소비자 모델이기 때문에.
• Log-based message broker: 생산자가 보낸 메시지는 로그 끝에 추가하고 소비자는 로그를 순차적으로 읽어 메시지를 받는다.
  • 각 파티션은 다른 파티션과 독립적으로 읽고 쓰기가 가능한 분리된 로그가 된다.
  • 각각 파티션에서 Offset을 통해 순차적으로 읽음.
  • 로그 기반 접근법은 당연히 팬 아웃 메시징 방식을 제공. 독립적으로 읽을 수 있고, 삭제되지 않음.
  • 만약 장애가 발생한 소비자가 처리했지만, 아직 오프셋을 기록하지 못한 메시지가 있다면 이 메시지는 재시작할 때 두 번 처리된다. 멱등성을 보장한다면 두 번 처리하게 되더라도 문제 없다.
• 여러 시스템 동기화 유지하기: 데이터베이스에 아이템 하나를 갱신하면, 캐시/색인/데이터 웨어하우스도 마찬가지로 갱신해야 하는 경우
  • 일괄처리 방식으로 데이터 웨어하스로 벌크 로드
  • Dual write: 데이터베이스의 아이템을 갱신할 때, 다른 시스템에도 update
    • 문제 1) 경쟁 조건. X=A와 X=B의 요청을 처리하는 도중, 데이터베이스에는 A → B로 적용되었지만, 검색 색인에는 B → A로 적용될 수도 있다.
    • 이런 경우 Lock을 거는 것이 일반적일 것 같음. 버전 벡터와 같은 동시성 감지 매커니즘을 사용할 수도 있을 듯.
    • 문제 2) 한쪽 쓰기가 성공할 때 다른 쪽 쓰기는 실패할 수 있는 점.
    • 원자적 커밋 문제로 동시 성공 또는 동시 실패를 하도록 하면 된다.
• CDC(Change Data Capture): 변경 데이터 캡처
  • 변경 데이터 캡처는 메시지 브로커와 동일하게 비동기 방식으로 동작한다.
  • 복제 지연으로 인한 단점이 존재 - 데이터베이스에서의 불일치 발생 가능. 최종적 일관성은 지킬 수 있음.
  • 최근 변경 사항만으로는 충분하지 않기에 Snapshot 반영이 필요한데, Log compaction을 이용하면 매번 snapshot을 만들 필요가 없다. 주기적으로 같은 키의 로그 레코드를 찾아 중복을 제거하고 각 키에 대해 최신 내용만 유지한다. Compaction과 병합 과정은 백그라운드에서 진행됨.
  • Apache Kafka도 로그 컴팩션 기능을 제공하고, 새 소비자는 컴팩션된 로그 토픽의 오프셋 0부터 시작해서 순차적으로 데이터베이스의 모든 키를 스캔하면 된다.
• Event sourcing: CDC와 같이 저수준에서 상태 변경을 하는 것이 아니라 Application 수준에서 발생한 일을 반영하게끔 설계되었음.
  • 좀 더 비즈니스 로직 관점에서 컨트롤 할 수 있고, 이슈가 발생했었을 때 영향 범위도 직관적이지 않나
  • Event sourcing의 철학은 Event와 Command를 구분하는데 주의한다. 사용자 요청이 처음 도착했을 때는 Command, Validation을 통과한 후에는 Event.
• “로그가 진실이고 데이터베이스는 로그의 부분 집합의 캐시다”
• 불변 이벤트의 장점
  • “실수가 발생해도 회계사는 원장의 잘못된 거래 내역을 지우거나 고치지지 않는다. 대신 실수를 보완하는 거래 내역을 추가한다”
  • “추가만 하는 불변 이벤트 로그를 썼다면 문제 상황의 진단과 복구가 훨씬 쉽다”
• CQRS(Command Query Resposibility Segregation): 읽기 모델과 쓰기 모델을 다르게 가져가는 방식.
  • CQRS 패턴을 사용할 때, NoSQL에는 역정규화된 데이터를 저장하여 읽기 효율성을 높이려고 하는 경우도 있는 것 같음.
  • 이런 경우 읽기 뷰에 반영되지 않을 가능성도 있기에 이를 위해 읽기 뷰를 동기식 업데이트 하는 등으로 해결을 할 수도 있다.
  • https://martinfowler.com/bliki/CQRS.html

Link

• https://www.linkedin.com/posts/jordancutler1_7-technical-whitepapers-recommended-by-an-activity-7190370051269537792-oB-B?utm_source=share&utm_medium=member_ios
• https://notes.stephenholiday.com/Kafka.pdf
• https://www.nasa1515.com/apache-kafka-consumer-poll-method-offset-commit/
• https://stackoverflow.com/questions/13681213/what-is-the-difference-between-amazon-sns-and-amazon-sqs
• https://velog.io/@combi_jihoon/SNS-SQS-Fan-out
• https://bugoverdose.github.io/development/redis-zset-basics/
• https://d2.naver.com/helloworld/7181840