Hacker News 의견

• 동의함. 특정 사용 사례에 대해 헤드 오브 라인 문제를 해결할 가치가 있음

  • 그러나 오늘날 모든 스트리밍 시스템(또는 우회 방법)은 메시지 키별 승인에 대해 O(n^2) 비용을 발생시킴
  • Pulsar와 같은 시스템이 이 기능을 위해 자주 사용됨
  • 이러한 복잡성은 매일 나타나지 않을 수 있지만, 나타날 경우 기다려야 함
  • 동료들과 함께 이 문제를 오랫동안 연구한 결과, 확장 가능한 메시지 키별 승인을 지원하기 위해 근본적인 아키텍처 변경이 필요하다는 결론에 도달함
  • 아키텍처는 정렬된 인덱스를 필요로 하며, 이는 n 메시지를 O(n log n)으로 처리함을 의미함
  • 이 주제에 대해 블로그를 쓰고 싶었지만 시간이 없었음
  • 메시지 키별 승인을 의존하려는 경우, 간헐적인 중단이나 지연을 예상해야 함

• NATS.io는 Kafka보다 사용하기 쉬우며, 파티션 제거, 키 기반 스트림 지원, 유연한 주제 계층 구조와 같은 여러 점을 이미 해결함

• Kafka와의 여정은 대부분 비슷함

  • 처음에는 "오, 확장 가능한 append-only 로그, 훌륭하고 간단함"이라고 생각함
  • 그러나 사용해보면 매우 복잡하다는 것을 깨닫게 됨

• 특정 사용 사례에서는, 생성 요청이 승인될 때 파생 데이터 뷰가 업데이트되었음을 보장할 수 있다면 유용할 것임

  • Kafka를 사용하지 말고, 하위 데이터 저장소에 직접 기록해야 함
  • 그러면 데이터가 커밋되었음을 알고, 쿼리할 수 있는 데이터베이스를 가질 수 있음

• 6년 전 이 질문을 했음

  • Rust로 작성하고 WASM을 활용하면 어떨까
  • 지난 6년 동안 이 작업을 진행해 왔음
  • 지난 2년 동안 Rust와 WASM을 사용하여 Flink를 구축해 왔음

• Kafka의 객체 저장소? 이는 지연 시간과 비용을 10배 증가시킬 것임

  • Kafka는 성공의 희생양임
  • 설계가 간단하고 우아하여, 원래 설계되지 않은 다양한 용도로 사용되고 있음
  • 물론 이러한 사용 사례에 완벽하지 않음

• "파티션 제거"와 "키 수준 스트림"에 대해

  • 스토리지 백엔드를 물리적 파티셔닝에 의존할 때, 이는 단순히 파티션을 키로, 키를 이벤트로 이름을 바꾸는 것과 같음

• Northguard를 주목해야 함

  • 이는 LinkedIn의 Kafka 재작성 이름으로, 약 일주일 전 스트림 처리 모임에서 발표됨

• Apache Kafka의 문제 중 얼마나 많은 것이 Apache Pulsar로 전환함으로써 해결되는지 궁금함

  • Kafka 학습을 건너뛰고 바로 Pulsar를 사용했음
  • 우리 사용 사례에 잘 맞음
  • 불만 없음
  • 그러나 왜 그렇게 적은 사람들이 사용하는지 궁금함

• 유용한 사고 실험임

  • Kafka를 새로운 것으로 대체해야 한다는 결론을 제안하는 답변들이 조용함
  • Kafka의 가장 큰 강점은 그 위에 구축된 넓고 유용한 생태계임
  • 이는 또한 약점임
  • 오늘날 처음부터 시작했다면 하지 않았을 디자인 결정을 일부 유지해야 함
  • 아니면 역호환성을 포기하고, 이미 가지고 있는 생태계를 재구성해야 함