ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • 카프카, 데이터 플랫폼의 최강자
    기타/내용 2023. 6. 30. 00:35

     

    변화의 방향은 느슨한 결합

    이벤트를 카프카에 저장해 필요한 조직에게 전달

    전달의 확인이 복잡한 것이 단점

    pub/sub의 교환기의 부하, 정합성관리 등으로 메시징 시스템의 성능이 좋지 못했으나 카프카는 

    책임을 프로듀서와 컨슈머에게 할당함으로써 고성능이 될 수 있었음

    하나의 토픽에 여러 프로듀서 컨슈머, 컨슈머와 프로듀서 역시 여러 토픽에 발행 및 소비가 가능함

    디스크에 메시지를 저장해 안정성을 높일 수 있음

     

    주키퍼는 카프카의 메타정보 및 상태관리, 분산 애플리케이션을 위한 코디네이터

    클라이언트의 정보를 주키퍼는 지노드라는 key value에 저장함. 모두 메모리에 저장하고 스냅샷과 트랜젝션 로그를 남김.

    앙상블은 과반수 방식으로 안정성을 유지함

    분산시스템은 같은 기능의 서버가 여러대있는 것이며 높은 성능, 장애대응, 높은 확장성이 목표임.

    카프카도 분산시스템이며 링크드인의 클러스터는 브로커가 60대인 것도 있음

    토픽은 메시시를 받을 수 있는 논리적 개념. 파티션은 토픽을 분할하는 개념

     

    카프카의 리플리케이션은 파티션을 리플리케이션

    리플리케이션 팩터 : 리더 + 팔로워 수, 클러스터 내 모든 브로커와 동일한 설정을 해야 함

    모든 쓰기와 읽기는 리더에서만.

    중요도에 따라 팩터를 조정한다. ISR에 속해야만 리더가 될 수 있다.

    리플리케이션은 장애대응에 효과적이지만 토픽사이즈 * 리플리케이션 수 의 용량이 필요하다

    팔로워가 복제를 주기적으로 하지 않을 경우 리더가 통신을 통해 확인한 후 ISR에서 추방한다.

    클러스터 내 모든 브로커가 죽으면 프로듀서는 발급을 할 수 없다.

    해결방안으로 마지막 리더의 부활을 기다리거나 가장 먼저 살아나는 브로커가 리더가 된다-> 동기화가 되어 있지 않았다면 new리더로 인해 old리더는 메시지 유실을 하게 된다.

    카프카 클러스터의 브로커가 3개이고 토픽 1을 처리, 파티션이 2개이면 브로커1과 브로커2에 토픽 1의 파티션이 있는 개념이다.

    지노드는 브로커 중 컨트롤러의 역할을 하는 정보와 토픽의 상세정보가 있다.

     

    파티션 1 팩터 3일 때 브로커1~3중에 리더가 있을 것이고 나머지는 팔로워가 있을 것이다.

    설정 중 acks는 프로듀서가 메시지를 발행하고 response를 확인하는 설정이다.

    배치사이즈 설정이 좋을 수도 있고 안 좋을 수도 있는데 환경에 따라 다르다 배치 사이즈가 차기를 기다리다가

    에러가 나면 유실되기 때문. 제한 시간을 짧게 가져갈 수도 있다.

    ack =1도 리더의 장애로 인해 유실이 있을 수 있다. 리더가 ack를 보내고 메시지 복제 전에 장애가 난다면 팔로워들 중 리더가 선출되고 old리더의 메시지는 유실된다.

    ack=all이더라도 relacas=1이면 복제 범위가 자기 자신 하나이기 때문에 유실이 있을 수 있다.

    가장 안전한 설정은 브로커 3개일 때, acks=all, in-sync-replcas=2, 팩터=3이다. 팩터 3으로 묶고 isr 최소 2이기 때문에 팔로워 2개의 복제는 보장된 다음 ack를 보낸다. isr =3이면 팔로워 하나가 다운될 경우 설정 조건이 충족되지 않아서 프로듀서가 카프카에게 메시지 발행을 하지 못한다.  

     

    카프카 컨슈머는 이미 가져갔던 메시지를 다시 가져올 수 있다.

    카프카는 토픽의 파티션이 여러 개인 경우 메시지의 순서를 보장하지 않는다. 여러 파티션에 메시지가 쌓이기 때문이다.

    정확한 보장을 원한다면 파티션의 개수를 1로 하자. 근데 이러면 컨슈머는 하나밖에 존재할 수 없다. 파티션 하나에 컨슈머 하나이다.

    하나의 토픽에 여러 컨슈머 그룹이 붙을 수 있고 각자 오프셋을 관리한다.

    그룹으로 관리되니 컨슈머의 확장이 쉽다.

    그룹에 컨슈머가 추가되면 파티션과 컨슈머가 연결되는 리밸런싱이 이뤄지며 이때는 메시지를 폴링 하지 않는다.

    하트비트를 보내지 않는다면 리밸런싱을 한다.

    가져간 위치를 오프셋이라고 하고 이를 컨슈머 내부에 저장하는 것을 커밋이라고 한다.

    컨슈머는 폴링할 때 커밋을 할 시간인지 체크하고 커밋한다.

    커밋 주기가 오기전에 리밸런싱이 일어나 컨슈머가 오프셋정보를 잃어버린다면 마지막의 오프셋정보를 가져오기 때문에 메시지 중복이 이뤄진다.

    오토커밋이 자주 쓰이지만 수동도 쓰이는데 수동은 메시지를 완전히 처리될때까지 커밋을 하지 않는다

    토픽의 파티션은 증가만 가능. 파티션만큼 컨슈머가 있어야 성능 업.

    lag은 토픽에 저장된 메시지와 컨슈머가 가져간 메시지의 차이

    '기타 > 내용' 카테고리의 다른 글

    SQL 튜닝의 시작  (0) 2023.08.08
    아파치 카프카 애플래케이션 프로그래밍 with 자바  (0) 2023.07.20
    실용주의 프로그래머  (0) 2023.06.20
    적정 소프트웨어 아키텍처  (0) 2023.03.16
    pdf  (0) 2023.01.01

    댓글

Designed by Tistory.