b

Should You Put Several Event Types in the Same Kafka Topic?링크 : https://www.confluent.io/blog/put-several-event-types-kafka-topic/ 에서 필요한 부분만 정리카프카를 쓸 때 가장 중요한 것 중 하나는 토픽을 어떻게 쓸 것인가이다. 만약 여러 이벤트 묶음이 있다면 한 토픽에 넣을 것인가, 여러 토픽에 넣을 것인가? 극단적으로 하나의 토픽에 넣는것은 좋은 생각이 아니다. 컨슈머가 관심있는 이벤트를 선택해서 소비할 수 있는 방법이 없기 때문이다. 반대로 너무 많은 것도 좋은 건 아니다.사실 성능관점에서 중요한것은 파티션의 갯수이다. 경험에 비추어 보면 레이턴시가 중요하다면 브로커 노드당 수백의 토픽-파티션을 가..

https://www.confluent.io/blog/event-sourcing-using-apache-kafka/ 를 읽고 대충 필요한 것만 적음.추가적으로 알게된 내용보다는 다시 한번 지식을 되새겨볼 수 있던 기회. Storing events in Kafka 첫 번째 문제는 이벤트를 어떻게 저장하는가이다. 3개의 방법으로 얘기할 수 있다.1. 모든 타입의 모든 이벤트를 하나의 토픽에 저장하는 방법 (물론 멀티 파티션)2. Topic-per-entity-type : entity별로 관련된 이벤트들을 분리된 토픽에 저장하는 방법 (예를 들어 user관련 토픽, product관련 토픽)3. topic-per-entity : 각각의 user, product 처럼 각 entity별로 별도의 토픽을 할당해서 저..

카프카의 Header 지원- 0.11 버전이후 user(custom) header를 지원하기 시작하였고 아래 위키와 이슈를 참고- https://cwiki.apache.org/confluence/display/KAFKA/KIP-82+-+Add+Record+Headers- https://issues.apache.org/jira/browse/KAFKA-4208 실제로 저장되는 형식과 구현체는 아래를 참고- https://kafka.apache.org/documentation/#record- https://github.com/apache/kafka/blob/trunk/clients/src/main/java/org/apache/kafka/common/record/DefaultRecord.java#L175 Pro..

몇개의 파티션으로 구성할 것인가에 대한 도움 글https://www.confluent.io/blog/how-to-choose-the-number-of-topicspartitions-in-a-kafka-cluster/ 읽고 나서 내 맘대로 정리한 내용- '파티션 갯수가 변경이 된다면, 제대로 메시지가 전달 안될 수 있다. 그래서 현재 필요보다 파티션 수를 많이 구성하라. 파티션 갯수를 변경할 필요가 없도록 해라. (향후 1-2년치 트래픽도 고민해서 충분한 파티션 수를 고민할것)- 그때 문제점은 OS의 open file handle이 커지게 된다. (모든 세그먼트 * 2)- 리더 선출은 주키퍼와 관련된 작업이 포함되고 이것은 선행적이다. 그래서 한 브로커에 파티션 리더가 많다면 선행적으로 파티션 리더를 변경..

현재 팀은 SpringBoot application 을 좀 더 운영하기 쉽도록 하기 위해서 starter를 하나 생성해서 사용하고 있다.cloud-netflix 셋팅과, 그 많고 많은 zuul, eureka 버그 픽스를 위한 몇몇 코드, 그리고 config server를 기반으로 한 다양한 설정들을 공통화 하기 위한 목적이다. 현재 진행 하는 프로젝트는 이 starter 를 쓰지 않고 순수하게 spring/kafka 만을 사용 하고 있다.이 프로젝트를 위해 별도의 metrics 시스템을 구축하기 보다는 기존의 sleuth-zipkin 인프라를 활용하기 위해서 spring-cloud-sleuth-stream을 사용하려 한다. 1. gradle 설정 추가['stream-kafka'].collect { com..

18/01/30 idea 카프카 자체의 data recovery는 훌륭하다. 당연한게 파일로 저장하고 심지어 여러 셋트로 저장한다. 유실되는 경우는 저장 기간을 넘기거나, 1개의 IDC에만 설치한 후 IDC가 물에 잠기는 방법 뿐이다. 이건 다 아는 얘기고, 문제는 이 kafka 를 기반으로 한 streams 를 서비스 할 때이다. 1. Kafka는 기본적으로 1 개의 TopicPartion 에서 1 개의 Consumer Group의 노드가 접속 한다.2. Kafka Topic은 KStream/KTsble/StateStore 등을 통해서 각각의 topic-partition을 local DB에 싱크를 맞춘후 materilized 한다 (비동기/latency 존재) 우선 1번의 문제부터....1. 해당 To..

18/01/26 idea 구현해야 할 도메인은 https://www.confluent.io/blog/building-a-microservices-ecosystem-with-kafka-streams-and-ksql/필요한 내용은- 정확한 request/ responses - scale out - high availability - ktable & state-store를 기반으로 한 local - storage의 사용블로그 글과 예제에 대해서는 100퍼센트 공감이 되지만, 몇몇 부분에서는 '구현' 자체가 고민스러움. 나 뿐 아니라 다른 이의 구현을 살펴보아도 동일하다. 아래의 github 개발자도 위의 블로깅 내용을 보고 example project를 작성하였지만 같은 문제점을 그대로 노출하고 있다.. - ..