110 lines
6.6 KiB
Markdown
110 lines
6.6 KiB
Markdown
### Offset
|
|
- 컨슈머가 poll()을 호출할때마다 읽지 않은 메시지 가져와 처리
|
|
- 컨슈머 그룹이 메시지를 어디까지 읽었는지 저장
|
|
- 파티션별로 독립적인 Offset값을 가지고 있음.
|
|
- 컨슈머 그룹 내부 저장 + 카프카내 토픽에 저장(Commit)
|
|
|
|
### Commit
|
|
- 오프셋 정보를 카프카 내부의 토픽에 저장하는 것을 Commit이라 함.
|
|
- 컨슈머가 내부 정보를 사용할 수 없는경우 리벨런싱 수행함
|
|
- 컨수머 다운
|
|
- 컨슈머 그룹에 새로운 컨슈머 조인할 경우
|
|
- 리벨런스 수행하면 가장 최근에 커밋된 오프셋 값을 가져와 메시지를 다시 읽는 과정을 수행함.
|
|
|
|
##### 자동동 커밋
|
|
- 컨슈머 옵션 중 enable.auto.commit = true 로 설정
|
|
- 커밋을 하기 위한 주기는 기본적으로는 5초마다 커밋
|
|
- auto.commit.interval.ms 값을 조정해 변경이 가능
|
|
- 오프셋 관리를 자동으로 하기 때문에 편리한 장점
|
|
- 리밸런싱으로 인한 문제가 생길 수 있다는 단점
|
|
- 중복으로 메시지를 수신하더라도 결과에 변동이 되지 않도록 어플리케이션의 설계를 잘 해야함.
|
|
|
|
##### 수동 커밋
|
|
- 자동 커밋 방식과 마찬가지로 메시지의 중복이 발생할 수 있다.(오류 부분부터 다시 읽어들여야 하는 경우)
|
|
|
|
---
|
|
|
|
|
|
### Replication
|
|
- Fault Tolerant 를 위해 Replication 을 지원
|
|
- 메시지를 복제해 관리하고 이를 통해 특정 브로커에 장애가 발생해도 다른 브로커가 해당 브로커의 역할을 대신할 수 있도록
|
|
|
|
#### Replication Factor
|
|
- 토픽의 파티션의 복제본을 몇 개를 생성할 지에 대한 설정
|
|
- Replication Factor 를 임의로 지정해 토픽을 생성할 수 있음.
|
|
- Factor 를 2 로 설정하면 복제본을 한 개 생성하고 3 으로 설정하면 두 개의 복제본을 생성한다는 의미
|
|
- replication 이 많아지면 그만큼 데이터의 복제로 인한 성능 하락이 있을 수 있음.
|
|
|
|
#### Leader & Follower
|
|
- Replication 을 표현
|
|
- Topic 으로 통하는 모든 데이터의 Read/Write 는 오직 Leader 를 통해서 이루어진다.
|
|
- 리더와 팔로워는 변경될 수 있다.(ISR)
|
|
- Leader : 팔로워를 감시하고 팔로워들 중 자신보다 일정 기간 뒤쳐진 팔로워가 발생하면 해당 팔로워가 리더가 될 자격이 없다고 판단하고, 뒤쳐진 팔로워를 ISR 에서 제외한다.
|
|
- Follower : 리더와 동일한 내용을 유지하기 위해 일정 주기마다 리더로부터 데이터를 가져온다.
|
|
|
|
|
|
#### ISR (In-Sync Replication)
|
|
- Replication Group
|
|
- 여러개의 토픽의 Replication 들의 Leader & Follower를 하나의 그룹으로 묶은것을 ISR 이라 칭한다
|
|
- ISR 내의 모든 Follower 들은 Leader 가 될 수 있다.
|
|
- 장애시 일시적으로 Read/Write 의 Timeout 이 발생할 수 있지만 Retry가 일어나면 새로운 리더를 통해 Read/Write할 수 있음.
|
|
- ISR 이 존재하는 목적은, Replica 들이 느려지거나 죽은 경우에도 Fault Tolerant 한 시스템을 유지하는 것(Acks참고)
|
|
|
|
|
|
#### All Down Situation
|
|
- 장애 발생하여 모든 브로커가 중단되었고 브로커마다 최종 가지고 있는 메시지가 상이한경우
|
|
- 마지막까지 리더였던 브로커1이 다시 Up 되고 리더가 될 때까지 기다린다. (손실 최소화, 브로커1이 빨리 up되어야 함)
|
|
- 리더 / 팔로워 상관없이 가장 빨리 Up 이 되는 브로커의 파티션이 리더가 된다. (효율적, 일부 메시지 손실 감수)
|
|
-
|
|
|
|
---
|
|
|
|
### Partitions
|
|
- 카프카의 토픽들은 여러 파티션으로 나눌수 있음.
|
|
- 토픽이 카프카에서 일종의 논리적인 개념이라면, 파티션은 토픽에 속한 레코드를 실제 저장소에 저장하는 가장 작은 단위
|
|
- 파티션의 레코드는 각각이 Offset 이라 불리는, 파티션 내에서 고유한 레코드의 순서를 의미하는 식별자 정보를 가진다.
|
|
- 파티션 간에는 순서가 보장되지 않음.
|
|
- 토픽의 파티션들을 여러 브로커에 배포.
|
|
- 파티션을 여러개로 나눠 병렬처리할 수 있음(하나의 파티션에 하나의 컨슈머 그룹이 지정됨)
|
|
|
|
#### Using a Partition Key
|
|
- Producer 는 파티션 키를 사용해서 특정한 파티션에 메시지를 전달할 수 있다.
|
|
- 동일한 키를 갖는 모든 레코드들이 동일한 파티션에 도착하는 것을 보장한다.
|
|
- 키가 제대로 분산되지 않는 경우 특정 브로커만 메시지를 받는 단점도 존재한다.
|
|
|
|
#### Reading records from partitions
|
|
- Consumer 가 카프카의 파티션으로부터 메시지를 읽어 (pull) 가야함.
|
|
- 파티션 내의 메시지는 그룹 내의 Consumer 중 하나에 의해서만 소비되는 것을 보장
|
|
|
|
|
|
Consumer Group : 어떤 토픽을 소비하는 Consumer 들을 그룹으로 묶은 것
|
|
|
|
###### 하나의 파티션에 하나의 그룹이 지정된경우(순서보장, 하나의 컨슈만 가져감, 하나의 컨슈머가 장애시 다른 컨슈머가 처리함)
|
|
###### 하나의 파티션에 여러컨슈머 그룹이 지정된경우
|
|
###### 여러개의 파티션에 여러게의 그룹이 지정됨경우 (순서보장x, 병렬처리)
|
|
|
|
![[Pasted image 20230417164940.png]]
|
|
|
|
파티션의 개수가 병렬성의 정도를 결정함
|
|
|
|
---
|
|
|
|
### ACKS (프로듀서, 데이터 유실 방)
|
|
- Acks 옵션으로 [1, 0, -1(all)] 값으로 설정할 수 있다.
|
|
##### acks = 0
|
|
- 브로커에게 메시지 전달이 정상적으로 되었는 지를 확인하지 않는다
|
|
- 성능 면에서는 세 가지 옵션 중 가장 월등
|
|
- 메시지 전달이 정상적으로 되고 있는 지를 보장하지 않는다.
|
|
##### acks = 1
|
|
- 리더에게 메시지가 제대로 전달되었는 지를 확인
|
|
- 리더는 팔로워들이 메시지를 복제하는 것을 기다리지 않고 잘 전달되었다고 프로듀서에게 알린다.
|
|
- 복제가 되었는 지를 확인하지 않기 때문에 리더가 메시지를 받고 바로 장애가 발생할 경우 메시지가 유실될 수 있다
|
|
##### acks = all (-1)
|
|
- 리더와 ISR 팔로워들이 메시지를 모두 전달받았는 지를 확인
|
|
- 메시지의 전달에 있어 상대적으로 매우 긴 시간이 필요하지만, 다른 옵션들에 비해 월등한 안정성을 제공
|
|
##### 기타
|
|
- min.insync.replicas : 이 옵션값이 2로 설정되면, ISR 내에 하나의 replica 만 존재할 경우 전달받는 메시지를 거절 (replica 가 최소 몇 개 존재해야 하는 지를 의미)
|
|
- ex) 노드가 3개 존재할 때 min.insync.replicas 를 3으로 설정하면, 하나의 노드만 장애가 발생해도 어떤 메시지도 받을 수 없게 된다
|
|
|
|
|
|
https://data-engineer-tech.tistory.com/11 |