Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Chapter 12. 엔터프라이즈 카프카 아키텍처 구성 사례 #11

Open
MinJunKweon opened this issue Nov 27, 2022 · 3 comments
Open

Comments

@MinJunKweon
Copy link
Member

No description provided.

@MinJunKweon
Copy link
Member Author

끄적끄적

  • 다중 IDC를 사용하는 경우가 존재함
    • 일대일 미러링 : 업스트림 카프카에서 다운스트림 카프카로 미러링하는 경우
    • 다대일 미러링 : 여러 센터의 카프카를 중앙 센터 카프카로 미러링하는 경우
  • 미러링된 카프카들은 여러가지 애플리케이션과 연동하여 사용함 (HBase, S3, ES, Hadoop 등)
  • 카프카 커넥트(미러 메이커)를 위치시키는 것은 보통 다운스트림 카프카가 있는 곳에 위치시킴
    • 메시지 중복을 허용하여 메시지 손실을 줄이기 위해서
    • 컨슈밍보다 프로듀싱이 네트워크 장애에 민감함
    • 컨슈밍은 오프셋을 장애 전 시점으로 변경하면 중복될 뿐 유실이 되지 않을 것이기 때문

@LOG-INFO
Copy link
Contributor

LOG-INFO commented Dec 4, 2022

끄적끄적

  • 프로듀서는 컨슈머보다 네트워크 장애에 더욱 민감하다
    • 컨슈머는 그냥 오프셋 다시 앞으로 당기면 됨 (어차피 카프카 브로커에 저장되어 있으니까)
  • CMAK(구 Kafka Manager) vs Kafka Manager ?
    • 기능은 같음
    • 이름이 바뀐 이유 - 요약하면 외부 프로그램에 Apache의 프로젝트 이름을 붙이는걸 허용하지 않음

오타 발견

  • p.399. 3문단 - 하지만 업스트림 카프카의 토픽으로 전송하는 동작은 네트워크 전용선 또는 인터넷 구간에서 이뤄지므로~
    • 업스트림 -> 다운스트림

@minkukjo
Copy link

minkukjo commented Dec 4, 2022

끄적끄적

  • 카프카 미러링은 프로듀서 + 컨슈머로 이루어진다.
  • 일반적으로 프로듀서는 컨슈머보다 장애에 민감함. 컨슈머야 오프셋을 앞으로 땡겨서 다시 컨슈밍 하기만 하면 되니까.
  • 우리도 카프카 로그를 ES에 쌓고 있는데, ES가 죽으려고 한다... 워낙 메시지 처리량이 많아서 ES 관리하는 것도 골치거리 -_-..

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants