b

Kafka 기반의 event driven stateful microservices 본문

Cloud

Kafka 기반의 event driven stateful microservices

dev.bistro 2018. 1. 28. 12:58


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 -_-;;;

Comments