• bootstrap.servers : 브로커 정보.
• fetch.min.bytes : 한 번에 가져올 수 있는 최소 데이터 크기. 지정 크기보다 작을 경우, 누적될 때까지 기다림.
• group.id : 컨슈머 그룹을 식별하는 식별자. 동일한 그룹 내의 컨슈머는 정보를 모두 공유.
• heartbeat.interval.ms : 하트비트가 있다는 것은 컨슈머의 상태가 active인 것. session.timeout.ms와 연관이 있으며, 이 값보다 낮은 값으로 설정한다. 일반적으로 session.timeout.ms의 1/3로 설정한다.
• max.partition.fetch.bytes : 파티션 당 가져올 수 있는 최대 크기.
• session.timeout.ms : 이 시간을 이용해 컨슈머가 종료된 것인지 판단함.
• enable.auto.commit : 백그라운드로 주기적으로 오프셋 커밋할지 여부.
• auto.offset.reset : 초기 오프셋이 없거나 현재 오프셋이 더 이상 존재하지 않을 경우, 해당 옵션에 따라 리셋한다. earliest - 가장 초기 오프셋값으로 리셋. latest - 가장 마지막 오프셋 값으로 리셋. none - 이전 오프셋 값을 찾지 못하면 에러.
• fetch.max.bytes : 한 번의 가져오기 요청으로 가져올 수 있는 최대 크기.
• group.instance.id : 컨슈머의 고유한 식별자. 설정한다면 static 멤버로 간주되어 불필요한 리밸런싱은 하지 않는다.
• isolation.level : 트랜잭션 컨슈머에서 사용되는 옵션. read-committed - 기본값. 모든 메시지를 읽음. read-uncommitted - 트랜잭션이 완료된 메시지만 읽음.
• max.poll.records : 한 번의 poll() 요청으로 가져오는 최대 메세지 수.
• partition.assignment.strategy : 파티션 할당 전략. 기본값은 range.
• fetch.max.wait.ms : fetch.min.bytes에 의해 설정된 데이터보다 적은 경우에 요청 응답을 기다리는 최대 시간.

출처) 실전 카프카 개발부터 운영까지 (고승범 저)

• bootstrap.servers : 클러스터는 마스터 개념이 없으므로, 각가의 호스트와 포트 정보. 모든 브로커의 정보를 적지 않아도 최초로 연결된 브로커로부터 통신을 위한 정보를 가져옴.
• client.dns.lookup : 클라인트가 하나의 IP와 연결하지 못할 경우에 다른 IP로 시도. use_all_dns_ips - 기본값. hostname의 모든 ip에 대해 연결. bootstrap 해당 하는 domain name을 그대로 가져가서 클라이언트 인스턴스 생성. 추후 polling과 같은 동작이 일어날 때 서버와 connection을 맺는 시점에서 domain name을 모두 resolve. resolve_canonical_bootstrap_servers_only - 프로듀서 또는 컨슈머가 최초 인스턴스 생성 시 bootstrap의 모든 ip에 대해 reverse lookup 수행. Kerberos의 SASL 인증을 통한 카프카 연동을 하기 위함. FQDN을 얻기 위해 사용. 최초 인스턴스 생성 시 domain name에 대한 모든 ip를 가져와서 bootstrap에 등록. FQDN - Full Qualified Domain Name. 전체 주소 도메인 네임.
• -> 두 옵션의 가장 큰 차이는 domain에 대한 ip를 lookup하는 시기인 듯
• acks : 프로듀서가 카프카 토픽의 리더 측에 메시지를 전송한 후 요청 완료를 결정하는 옵션. 0 - 요청만 보냄. 빠른 전송이 가능하나 메시지 손실 가능성이 있음. 1 - 리더가 받았는지 확인. 대부분의 경우에 기본값으로 사용된다. all(-1) - 팔로워가 받았는지 모두 확인. 다소 느리지만 하나의 팔로워가 있는 한 메시지 손실은 없다.
• buffer.memory : 프로듀서가 카프카 서버로 데이터를 보내기 위해 대기할 수 있는 전체 메모리 바이트.
• compression.type : 메시지 전송 시 선택할 수 있는 압축 타입. none, gzip, snappy, lz4, zstd
• enable.idempotence : 멱등법칙. true로 하는 경우 중복 없는 전송이 가능함. max.in.flight.requests.per.connection은 5 이하. retries는 0 이상. acks는 all.
• max.in.flight.requests.per.connection : ack 없이 전송할 수 있는 최대 요청 수. 메시지 순서가 중요하다면 1로 설정. 하지만 성능은 다소 떨어질 수 있음.
• retries : 전송에 실패한 데이터를 다시 보내는 횟수. 음수로 하면 0으로 바뀌나
• batch.size : 배치 크기 설정.
• linger.ms : 배치 크기에 도달하지 못해도 해당 시간에 도달하면 메시지 전송.
• transactional.id : 프로듀서 트랜잭션을 구분하기 위한 ID. 중복 방지를 위해 UUID 사용. '정확히 한 번 전송'을 보장함. enable.idempotence 값을 true로 설정하고 사용. UUID - Universally Unique Identifier. 범용 고유 식별자. 소프트웨어 구축에 쓰이는 식별자 표준으로, 개방 소프트웨어 재단(OSF)이 분산 컴퓨팅 환경(DCE)의 일부로 표준화하였다.

출처) 실전 카프카 개발부터 운영까지 (고승덕 저) https://blog.voidmainvoid.net/331

보다 큰 규모의 데이터를 모으고, 처리하고, 저장하고 받아서 전달하는 이벤트 스트리밍 플랫폼. 데이터를 받아서 전달하는 데이터 버스 역할을 한다. 즉, 대량의 데이터를 분산 관리해주는 미들웨어이다.

이벤트 스트리밍 : ??? 데이터 스트리밍 : ???

미들웨어 : 운영 체제에서 제공하지 않는 일반적인 서비스와 기능을 애플리케이션에 제공하는 소프트웨어. 이벤트 : 소프트웨어 또는 응용 프로그램에서 식별하거나 기록 하는 모든 유형의 작업, 사건 또는 변경 사항.

핵심 개념

높은 처리량, 빠른 응답 속도, 안정성

카프카를 사용하는 대표적인 이유는 위의 세 가지를 보장해주기 때문이다. 이를 보장해주는 구체적인 카프카의 핵심 개념은 아래와 같다.

• 분산 시스템 : 네트워크 상에서 연결된 컴퓨터들의 그룹. 높은 성능을 낼 수 있으며 장애 대응과 시스템 확장에 용이함.
• 페이지 캐시 : OS의 페이지 캐시를 활용하여 처리량을 높인다.
• 배치전송처리 : 네트워크 오버헤드를 줄이고 빠르고 효율적인 처리를 가능하게 함.
• 압축 전송 : 배치전송과 같이 하여 효율성을 극대화 시킬 수 있다.
• 고가용성 보장 : 파티션의 복제를 통하여 고가용성을 보장한다. 이를 위한 리플리케이션 기능을 제공함.
• 주키퍼 의존성 : 여러 대의 서버를 앙상블(클러스터)로 구성하고, 살아있는 노드 수가 과반수 이상 유지된다면 지속적인 서비스가 가능하다. 이를 위해 반드시 홀수로 구성되어야 한다. znode를 이용해 카프카 메타 정보가 주키퍼에 기록된다. 브로커 노드, 토픽, 컨트롤러를 관리한다. 메타데이터 저장소라고 보면 된다. 카프카를 어려워 하는 이유 중 하나는 주키퍼 때문일 것인데...v3.0부터는 브로커와 통합된다고 한다. 하지만 아직 운영환경에 사용하기엔 무리가 있는 듯 하다.
• Topic : 이메일에서 주소 정도의 개념.
• Partition : 토픽은 병렬 처리를 위해 파티션으로 나뉜다.
• Offset : 파티션의 메시지가 저장되는 위치이다. 숫차적으로 증가하는 64비트의 고유한 정수. 오프셋을 통해 메시지의 순서를 보장하며, 컨슈머에서는 마지막 읽은 위치를 알 수 있다. 여기서 메시지의 순서를 보장한다라는건 같은 파티션 내에서의 순서를 보장한다는 뜻이다.

특징

Kafka의 핵심 개념과 연관 되며, 이는 곧 기업에서 사용할만한 충분한 이유가 된다.

1. 높은 처리량과 낮은 지연율

2. 높은 확장성

3. 고가용성

4. 내구성

5. 개발 편의성

6. 운영 및 관리 편의성

기본 구조

프로듀서 -> 카프카(Broker) -> 컨슈머 이와 같은 흐름을 가진다. 화살표는 메시지가 흐르는 방향. 주키퍼는 카프카의 정상 동작을 보장하기 위해 메타데이터를 관리하는 코디네이터이다. 클러스터는 브로커로 구성 되며, 브로커 안에는 토픽이 존재한다. 토픽은 파티션으로 구성된다. 파티션은 세그먼트 형태로 파티션에 저장된다. xxx.log와 같은 파일로 hexdump에 저장된다. linux 명령어인 xxd를 이용하여 파일을 볼 수 있다. 저장 경로는 브로커 속성 중 하나인 log.dirs이다.

즉, 프로듀서에 의해 브로커로 전송된 메시지는 토픽의 파티션에 저장되며, 각 메시지들은 세그먼트라는 로그 파일 형태로 브로커의 로컬 디스크에 저장된다.

Apache Kafka vs Conluent Kafka

https://www.knowledgenile.com/blogs/confluent-kafka-vs-apache-kafka/

출처) 실전 카프카 개발부터 운영까지 (고승범 저)