Kafka 신뢰성에 관련한 소프트웨어 디자인 질문

Question

안녕하세요.카프카를 서비스에 도입하고 있는데요, 카프카에 신뢰성과 관련하여 소프트웨어 디자인을 어떻게 해야할지 모르겠습니다.먼저 카프카에서 다루는 데이터는 1건이라도 놓치면 안되는 중요한 데이터입니다. 그럼에도 불구하고 빠른 처리 속도를 보장하여야 하기 때문에 Kafka를 사용하는데요.1안.Producer -> Broker -> Consumer - 처리 전에 DB에 로깅 후, 처리 후에 DB에 또 로깅 Acks 및 Offset 등 설정을 잘 했다는 가정 하에 Loss 없이 Consumer에 도달하므로, 별도의 장치 없이 바로 Producer에서 Consumer로 연결됩니다. 데이터를 받은 Consumer는 처리 전에 한번 DB에 로깅, 처리 하고, 처리 후에 DB에 로깅합니다. 2안.Producer -> DB 로깅 및 Broker 전송 -> Consumer - 처리 후에 DB에 로깅2안은, Producer -> Broker가 제대로 가는지 신뢰할 수 없음, Broker -> Consumer도 제대로 가는지 신뢰할 수 없음따라서 처리 전 Producer에서 DB에 로깅하면서 Broker에 병렬적으로 던져주고, Consumer에서 받으면 데이터를 처리하고, 처리 후에 DB에 로깅합니다. 만약 Loss가 발생하더라도 DB에 저장된 데이터를 피칭함으로서 로스를 확인하고 재처리가 가능합니다. 제 주된 생각으로는 설정만 잘 해주면 카프카를 신뢰할 수 있고 1안처럼 가도 된다는 생각이 있어요. 프로덕션에서 사용해보신 경력자분들에게 어떤 방안이 더 좋을지 조언을 구합니다.

냥길동 · Accepted Answer

카프카를 최소 3대 구성해서 처리를 하면 유실이 될 가능성을 걱정할 필요까지는 없다고 생각됩니다. 혹시나 데이터가 너무 많아서 브로커가 연달아 죽는 경우가 생겨서 발생할지도 모르는 데이터의 유실이 걱정된다면..이미 DB에 로그를 남기는 방식은 제가 볼땐 잘못된 방식입니다. 카프카보다 DB가 먼저 문제가 생길것 같습니다.역으로 DB가 감당가능한 수준의 로그라면 카프카쪽은 더 문제가 안된다고 생각해도 될것같구요. 저도 많이 아는건 아니지만 이런상황에서 보통 제가 하는이야기는 네카라쿠배당토급 대용량 서비스 할거아니면....일반적인 상황에선 그렇게까지 고민 할 사항은 안생길것이다 입니다. 제 경우에는 분당 100-120만건급 로그데이터가 들어오면 이것을 분석해서 결과를 얻어내는 것이었는데요.최초기획에선 로그를 모두 디비에 저장하는내용이 있었지만 다 걷어내고 오로지 도출된 결과정보만 저장하는 식으로바꾸었습니다. (카프카 스트림즈로 실시간분석)애초에 디비가 못버티니까요. 단 이번에 다른 고객사와 프로젝트를 진행하면서 해당 로그성 데이터는고객사가 원하는대로 엘라스틱서치쪽으로 집어넣는것으로 진행중입니다. (사후분석용)

집킨 · Answer

카프카를 신뢰할 수 없으면 어떤 방법으로 카프카를 안쓰는게 낫습니다그리고 가용성,안정성과 성능은 트레이드 오프 요소이기 때문에 한쪽을 비약적으로 높이려면 다른 쪽을 조금 낮춰야 합니다정말 한건이라도 손실되면 안되는 경우에 어느정도 성능이 나와야하고 대용량의 데이터가 왔다갔다 할거라면 카프카가 적당한게 맞구요이런 경우에는 카프카 클러스터를 노드 갯수 최소 3개 이상으로 구축해야합니다프로듀서에서 브로커에 데이터를 send할때 노드가 3개라면 2개에서 aks응답이 오도록 하고 5개라면 3개에서 aks응답이 와야 정상적으로 send했다고 판단하도록 설정해놓으면 최소한 프로듀서가 보낸 데이터가 중간에 어떠한 장애로 인해 브로커에 적재되지 않는 케이스는 없을겁니다 (브로커 자체가 모두 죽어 있는게 아니라면요)또 하나의 노드에 적재되는 순간 모든 노드에 복제가 될거라서 노드들을 최소 2개의 데이터센터에 걸쳐서 구축해놓았다면 진짜 천재지변이 아니면 데이터 손실도 없을거구요

Kafka 신뢰성에 관련한 소프트웨어 디자인 질문

2개의 답변

기술 목록