stories/kafka-consumer-proxy

[hiddenest]

Lag 없는 실시간 데이터 파이프라인을 위한 아키텍처 개선기

https://engineering.ab180.co/d5395849-04ef-4119-ba9f-27f426c4e2dc

[hiddenest]

유익하고 상세한 글 잘 보았습니다! 그런데 제가 관련 지식에 대한 이해가 많이 부족해서, 확인 차원에서 몇 가지만 질문 드리고 싶습니다:

Q1. 문제상황과 해결책을 "각 Consumer 별로 처리하는 양이 편차가 심해져서, 이러한 처리 로직을 (스케일링이 상대적으로 유연한) 뒷단 Application 쪽으로 뺐다"고 요약해도 괜찮을까요?

Q2. 'Python + gRPC에서 multi core 활용' 부분의 설명은, "envoy에서 grpc 요청을 받아서, multiprocessing을 사용하는 파이썬 앱에 전달했다"고 이해해면 될까요?

This comment was made by Disqus. 2021-11-16 08:13:32 roeniss(roeniss)

[hiddenest]

좋은 글 감사합니다 ㅎㅎ 잘 읽었어요. 컨슈머 스케일 아웃에 대해서 고민하다가 글을 찾았는데요. 아이디어를 얻고갑니다. 글을 읽다가 궁금한 점이 있어서 질문 남겨봐요.
consumer에서 application 서버로 요청을 보낼때 모종의 이유로 컨슈밍된 이벤트 처리에 실패한다면 재시도 로직은 어떻게 설계되어 있는지 궁금합니다~!

This comment was made by Disqus. 2021-11-21 03:53:50 kd4(kd4)

[hiddenest]

A1. 네 맞습니다. 그리고 저희 운영 환경상 scale up에 한계가 있다는 문제도 해결됐습니다.
A2. 비슷합니다. gunicorn과 같은 구조를 생각하시면 이해하시기 편하실 것 같습니다.

This comment was made by Disqus. 2021-11-22 06:22:54 Juhong Jung(Juhong Jung)

[hiddenest]

어플리케이션 서버에서도 Deduplication을 처리하도록 기존에 설계되었기에, Consumer 레이어는 At-least-once Delivery Semantic을 가지도록 구현했습니다.
즉, 서버에서 모종의 이유로 처리에 실패에 오류 코드가 반환되거나, 서버가 죽는 등의 이유로 아예 응답을 받지 못하는 경우에는 기본적으로 요청을 재시도합니다.
또한, 클라이언트는 Kafka에서 받아온 메시지를 전부 다 처리했을 때만 commit합니다. 이를 위해서, 일정 횟수 이상 처리에 실패한 메시지는 이후 다시 처리할 수 있도록 SQS로 저장하도록 구현하였습니다.

This comment was made by Disqus. 2021-11-22 06:48:17 Frank Yang(Frank Yang)

[hiddenest]

좋은 글 감사합니다!! 읽다보니 궁금한 점이 하나 생겨서 질문 남깁니다(제가 잘못 이해한 걸수도 있어서 감안해서 읽어주세요.)

데이터 처리 순서에 문제가 없도록 consumer가 batch window 내에서 순서를 고려하여 application server를 호출한다고 적어주셨는데요, 그렇다면 결국 동시요청은 topic의 파티션 갯수만큼만 가능한건가요?
- 만일 그렇다면 application server scaling을 한다는게 단순히 consumer에서 application server로 보낸 요청을 처리하는데 걸리는 시간을 줄이기 위한 목적인건가요?
- 그렇지 않고 파티션 갯수 이상으로 동시요청이 가능하다면 하나의 파티션 내의 순서를 보장하면서 어떻게 가능한가요?

This comment was made by Disqus. 2021-11-22 08:54:11 jongsu(jongsu)

[hiddenest]

좋은 글 감사합니다. 이해를 못한 부분이 있어서 질문을 남깁니다. "데이터 처리 순서: consumer가 batch window 내에서 순서를 고려하여 application server 호출" 이 부분에서 consumer가 순서를 어떻게 고려하는건가요?

This comment was made by Disqus. 2022-01-05 04:41:00 Joe Cho(Joe Cho)

[hiddenest]

안녕하세요! 이 질문에 답하려면 먼저 에어브릿지 시스템으로 들어오는 이벤트의 종류를 설명드려야 할 것 같습니다. 에어브릿지에 들어오는 이벤트는 크게 Touchpoint (TP), Target Event (CV), Subsequent Event (SE) 이 세 카테고리로 분류됩니다. 어트리뷰션을 위해서는 TP -> CV -> SE의 순서로 이벤트가 처리되어야 해요. 하지만 같은 카테고리에 속하는 이벤트들 사이에서는 이벤트의 처리 순서가 그렇게 중요하지 않습니다.
따라서 현재 구현체에서는 클라이언트가 한 Batch window 내의 메시지를 카테고리별로 분류한 후, 각 카테고리 안의 이벤트들을 일정한 크기로 자른 다음 병렬로 서버에 전송하는 방식으로 구현되어 있습니다.

This comment was made by Disqus. 2022-03-10 02:53:39 Frank Yang(Frank Yang)