2022-08-09-TIL
2022-08-09-TIL
Today I Learned
Git
test1, test2 –> test3 으로 머지하면 어떻게 식별하는가? 베이스 커밋을 변경하게 되므로 충돌이 나지않게 된다.
Git은 두 브랜치를 합칠 때 양쪽 브랜치 끝 커밋과 두 브랜치의 공통 조상(merge base)을 함께 비교하는 3-way merge를 한다. 공통 조상 대비 한쪽만 바꾼 부분은 그쪽 변경을 그대로 가져오고, 양쪽이 같은 부분을 서로 다르게 바꿨을 때만 충돌로 표시한다. git merge-base test3 test2로 어떤 커밋이 기준이 되는지 직접 확인할 수 있다.
test1을 test3에 먼저 머지하면 test3에 머지 커밋이 생기고, 그다음 test2를 머지할 때는 test3과 test2의 공통 조상이 새 기준이 된다. 그래서 test1에서 이미 들어온 변경은 “test3 쪽의 변경”으로 취급된다. 충돌 여부는 결국 test2의 변경이 기준 이후 test3에 들어온 변경(test1의 변경 포함)과 같은 줄을 건드렸는지로 결정되므로, 기준이 바뀐다고 해서 충돌이 항상 사라지는 것은 아니다.
Kafka
Kafka는 메시지를 토픽 단위로 저장하는 분산 이벤트 스트리밍 플랫폼이다. 토픽은 여러 브로커에 흩어진 파티션으로 나뉘고, 새 이벤트는 파티션 중 하나의 끝에 추가(append-only)된다. 같은 키를 가진 이벤트는 같은 파티션에 쓰이고, Kafka는 한 파티션 안에서는 쓴 순서 그대로 읽힌다는 것을 보장한다. 반대로 파티션이 다르면 순서는 보장되지 않는다. 메시지는 소비된 뒤에도 보존 기간 동안 남아 있어서, 여러 컨슈머가 각자 다른 위치에서 읽을 수 있다(Kafka 3.2 Documentation: Introduction).
- https://ggop-n.tistory.com/89
- https://kafka.apache.org/documentation/
- https://medium.com/event-driven-utopia/understanding-kafka-topic-partitions-ae40f80552e8#:~:text=Kafka’s%20topics%20are%20divided%20into,in%20an%20append%2Donly%20fashion.
Kafka Consumer Group
컨슈머 그룹은 같은 group.id를 가진 컨슈머들의 묶음이다. 토픽의 각 파티션은 한 그룹 안에서 정확히 하나의 컨슈머에게만 할당된다. 그래서 컨슈머 상태는 파티션마다 “다음에 읽을 오프셋” 숫자 하나로 충분하고, 메시지마다 확인 응답을 관리하는 큐보다 상태가 훨씬 작다(Kafka Design: Consumer Position).
이 구조에서 두 가지가 따라 나온다. 하나는 그룹의 처리량을 늘리려면 컨슈머를 추가하면 되지만, 파티션 수보다 많은 컨슈머는 할당받을 파티션이 없어 놀게 된다는 것이다. 다른 하나는 서로 다른 그룹은 같은 토픽을 독립적으로 읽는다는 것이다. 같은 이벤트를 정산 서비스와 알림 서비스가 각자 소비하려면 그룹을 나누면 된다.
- https://blog.cloudera.com/scalability-of-kafka-messaging-using-consumer-groups/#:~:text=Consumer%20groups%20give%20Kafka%20the,group%20share%20a%20group%20id.
- https://kafka.apache.org/documentation/#intro_consumers
Kafka Messaging Semantics
| 보장 | 의미 | 컨슈머 쪽 구현 |
|---|---|---|
| at-most-once | 유실될 수 있지만 중복은 없다 | 오프셋을 먼저 저장하고 처리 |
| at-least-once | 유실은 없지만 중복될 수 있다 | 처리 후 오프셋 저장 |
| exactly-once | 한 번만 처리된다 | 트랜잭션으로 처리 결과와 오프셋을 함께 커밋 |
프로듀서 쪽에서는 0.11.0.0부터 멱등 프로듀서가 재전송으로 인한 중복 기록을 막고, 트랜잭션이 여러 파티션 쓰기를 원자적으로 묶는다. Kafka 문서는 exactly-once를 Kafka 토픽에서 읽어 Kafka 토픽으로 쓰는 경우(Kafka Streams 등)에 트랜잭션으로 달성한다고 설명한다. 결과를 외부 DB에 쓰는 경우라면 오프셋을 그 DB에 함께 저장하거나, 처리를 멱등하게 만들어 at-least-once의 중복을 흡수하는 방식이 필요하다(Kafka Design: Message Delivery Semantics).
- https://www.baeldung.com/kafka-exactly-once#:~:text=Initially%2C%20Kafka%20only%20supported%20at,exactly%2Donce%20delivery%20in%20Kafka.
- https://www.confluent.io/blog/exactly-once-semantics-are-possible-heres-how-apache-kafka-does-it/
- https://dhkdn9192.github.io/apache-kafka/kakfa-exactly-once-delivery/
Kafka vs RabbitMQ
둘 다 메시지 브로커로 분류되지만 모델이 다르다.
- RabbitMQ는 AMQP 모델을 따른다. 프로듀서가 exchange에 메시지를 보내면 바인딩 규칙(direct, fanout, topic, headers)에 따라 큐로 라우팅되고, 브로커가 컨슈머에게 메시지를 밀어 준다(push). 컨슈머가 ack를 보내면 메시지는 큐에서 사라진다. 메시지 단위 라우팅과 작업 분배에 강하다(RabbitMQ: AMQP 0-9-1 Model Explained).
- Kafka는 파티션된 로그다. 컨슈머가 오프셋을 기준으로 직접 가져가고(pull), 메시지는 소비 여부와 상관없이 보존 기간 동안 남는다. 높은 처리량, 재처리(오프셋 되감기), 여러 그룹의 독립 소비가 필요한 이벤트 스트림에 강하다.
Upsolver 글의 요약 문장도 Kafka가 훨씬 높은 처리 성능을 내서 빅데이터 용도에 맞다는 쪽이다. 어느 쪽이 맞는지는 처리량보다 라우팅이 복잡한지, 재처리가 필요한지 같은 요구에 먼저 달려 있다.
- https://www.upsolver.com/blog/kafka-versus-rabbitmq-architecture-performance-use-case#:~:text=Kafka%20offers%20much%20higher%20performance,for%20big%20data%20use%20cases.
- https://www.simplilearn.com/kafka-vs-rabbitmq-article
- https://coding-nyan.tistory.com/129
- https://www.instaclustr.com/blog/rabbitmq-vs-kafka/
Books
『Go로 구현하는 클라우드 네이티브 애플리케이션』(미나 안드라오스, 마틴 헬미크 지음, 에이콘출판, 2022년 4월). 클라우드와 MSA 기반 웹 애플리케이션을 Go로 만드는 내용을 다루는 번역서다.
- http://www.kyobobook.co.kr/product/detailViewKor.laf?mallGb=KOR&ejkGb=KOR&barcode=9791161756264
댓글
아직 댓글이 없습니다