카프카
쓰는 이유
메시지 발행 및 구독 개념
다중 프로듀서. 성능상에서 뛰어나다. 여러 클라이언트가 많은 토픽 혹은 같은 토픽을 사용해도 무리 없는 구조
다중 컨슈머로써도 마찬가지로 구조상 상호 간섭 없이 스트림 상 메시지를 읽을 수 있다.
그 밖에 디스크에 메시지를 보존함으로써 컨슈머가 꼭 실시간으로 처리를 하지 않아도 되고 (예. 접속 폭주)보존 옵션에 따라 다양하게 사용 가능 하며 유지보수에 용이하다.
확장성이 좋다. 여러개의 브로커로 구성된 클러스터 구성 및 온라인 상태일때도 확장이 용이하다.
주요 개념
메시지
기본 단위. 바이트 배열 형식.
메시지 데이터는 토픽으로 분류된 파티션에 수록된다. 일관된 해시 값인 키값에 따라 같은 파티션에 수록
하나의 토픽은 여러개의 파티션으로 구성될 수 있음
여러개의 메시지가 배치 형태로 파티션에 수록됨. 성능을 위한 트레이드오프 관련
스키마
메시지 자체는 단순히 바이트 배열임
이를 애플리케이션의 필요에 따라 json, xml 이나 직렬화 프레임워크 선택
일관된 데이터 형식 중요
토픽, 파티션 처리 순서
맨 앞부터 끝까지 읽힘. 토픽이 아닌 파티션 별로 관리됨
추가되는 메시지는 각 파티션의 끝에 수록
파티션은 서로 다른 분산된 서버에 존재가능. 즉, 하나의 토픽 분산 처리 가능
스트림
프로듀서로 부터 컨슈머로 이동되는 연속적인 데이터
하나의 토픽 데이터로 간주
프로듀서
특정 토픽으로 새로운 메시지를 생성하는 클라이언트.
커스텀 방식으로 특정 파티션 지정 할 수 있다
컨슈머
토픽을 구독하는 클라이언트
오프셋으로 읽는 메시지의 위치를 알 수 있으며 주키퍼가 이를 저장하고 있으므로 중단되더라도 나중에 다시 읽던 위치를 알 수 있다.
하나의 파티션은 하나의 컨슈머로만 소비될 수 있고, 하나의 컨슈머는 여러 파티션을 소유할 수 있다.
소유 변경을 통해 다른 컨슈머가 대신 읽을 수 있다.
브로커
하나의 카프카 서버
프로듀서로부터 메시지를 받고 오프셋 지정하여 디스크에 저장
클러스터
여러 브로커
클러스터에서 각 파티션은 브로커 중 파티션 리더를 지정한다
다중 데이터 센터등 요구사항에 따라 다중 클러스터를 구성할 수 있다. (미러)
실 사용해보면서 개념을 도입해보는 것이 좋을 것 같다.
'IT > Backend , 네트워크' 카테고리의 다른 글
[aws] networking #3 (0) | 2023.04.03 |
---|---|
[aws] networking #2 (0) | 2023.03.31 |
[aws] networking #1 (0) | 2023.03.25 |
[GCP] firewall 설정을 해도 인스턴스에 반영이 되지 않는 경우 (0) | 2021.10.02 |
보안에 대한 생각 (0) | 2021.08.27 |