일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
- scala
- enablekafkastreams
- Elasticsearch
- statestore
- avo
- 한빛미디어
- schema registry
- kafkastreams
- spring-kafka
- Elk
- 카프카
- Kafka
- confluent
- spring-cloud-stream
- gradle
- kafkastream
- spring-batch
- springboot
- scala 2.10
- Spring
- kafka streams
- aws
- coursera
- 플레이 프레임워크
- Logstash
- Slick
- RabbitMQ
- reactive
- play framework
- kafka interactive query
- Today
- Total
b
Kafka 기반의 event driven stateful microservices 본문
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를 작성하였지만 같은 문제점을 그대로 노출하고 있다..
- https://github.com/hpgrahsl/kafka-streams-emojitracker
- 사용 : confluent connect, stream, statestore, reactive(boot2.0)
- 특징 : 트랜잭션 사용안함(at_least_once) /
- 데이터 서칭
이 분은 그리고 request/reply 모델이 아니다. 그래서 아래와 같은 부분에 대해서는 구현이 빠져있다.
https://github.com/confluentinc/kafka-streams-examples/blob/4.0.0-post/src/main/java/io/confluent/examples/streams/microservices/OrdersService.java#L232
reply에 대한 고민은
- 채번을 하고, 해당 Order Id의 reply를 consumer로 받을 수 있는 Node으로 요청을 보낸다.
이슈) zuul, client load loadbalancer가 주키퍼를 기반으로 브로커 파티션/파티셔너 정보를 알고 있어야 한다.
- zuul 에서 기존 routing 정책에 의해 요청을 보낸후, 실제 Node에서 '응답을 받을 수 있는' 채번을 한다.
이슈) Range(0,PartionNum).boxed().filter(local-state::matchingkey).findFirst();
그럼 아마 ID가 1,7,11 이런식으로 생기겠지. (중간에 사용못하는 애들 생김)
- 또는... 정말 옛날로 돌아간다. (생각도 안해봤지만, 팀원분께서 차라리 이럴꺼면 2번 호출해라고)
ex) 채번 자체는 Node 에서 하고, 이벤트를 발생한다. 그리고 그 노드가 '응답'을 받는 다는 보장이 없으므로 Mono로 FT로 바로 리턴, FT는 응답을 바로 받고 'OrderId'를 가지고 다시 한번 zuul 영역을 호출한다. -_-;
- 또는 제일 심플하게 각각의 Node를 Consumer Group으로 사용하지 않는다!
이슈) 트래픽이 WAS 만큼 '배수'로 든다. 즉 기존에 WAS 50대로 10MB/SEC 트래픽이었다면 이렇게 하면 500MB/SEC -_-;;;
'Cloud' 카테고리의 다른 글
kafka stream의 fail-over & high-availability (0) | 2018.01.30 |
---|---|
Spring Cloud Stream 의 버전 선택 (0) | 2018.01.28 |
AWS EC2에 tomcat7 & java8 설치 (0) | 2014.07.09 |
google cloud compute engine 시작하기. (0) | 2013.11.22 |
bitnami MEAN stack announce for OSX(mac) (0) | 2013.11.16 |