본문 바로가기

Develop/[Kafka]

 (27)
[Kafka] 토픽과 파티션 토픽이라는 개념과 파티션이라는 개념이 있다. 토픽은 한개이상의 파티션으로 이루어져있고, 각각의 파티션은 큐 형태로 들어가있다. 위 그림 처럼 프로듀서에서 레코드의 값이 파티션으로 들어가게 되면, 각각의 파티션의 큐에 해당 데이터가 쌓이게 된다. 컨슈머가 데이터를 가져가도, 데이터가 삭제 되지않는다. 토픽 생성시 파티션이 배치되는 방법은 아래와 같다. 브로커 3개에서 토픽이 생성되는 것을 예시로 들어보자 기본 라운드로빈 방식으로, 순차적으로 리더 파티션이 분배된다. 프로듀서가 각각의 리더파티션과 통신을 할때 한개의 브로커에 몰리는것이 아니라, 브로커를 균등하게 나눠서 통신할 수 있는것이 장점이 된다. 데이터가 많아지더라도, 한개의 브로커와 통신하는 것이 아닌 선형 확장되는 것을 알 수 있다. 리더 파티션이..
[Kafka] ISR (In-Sync-Replicas) ISR은 리더 파티션과 팔로워 파티션이 모두 싱크가 된 상태를 뜻한다. 싱크는 : 오프셋의 개수가 같다는 뜻이다. 즉 리더파티션의 데이터가 모두 팔로워 파티션의 데이터에 복제가 되었다는 것을 뜻한다. ISR 장애 상황에서 중요하다. 리더 파티션이 장애가 나고 ISR이 되기 전에 새로운 리더가 선출이 되면 아직 리더 파티션 의 데이터가 복제가 다 되지 않는 상태에서 리더 파티션이 바뀌게 되고 이는 곧 데이터 유실이 된다. 따라서 해당 ISR이후에 리더 선출에 대한 옵션은 중요하다. unclean.leader.election.enable=true -> 유실을 감수함, 복제가 안된 팔로워 파티션을 리더로 승급 unclean.leader.election.enable=false -> 유실을 감수하지 않음 해당 브..
[Kafka] Replica 데이터 복제는 카프카를 장애 허용시스템으로 동작하도록 하는 원동력이다. 복제의 이유는 클러스터로 묶인 브로커 중 일부에 장애가 발생하더라도 데이터를 유실하지 않고 안전하게 사용하기 위함이다. 카프카의 데이터 복제는 파티션 단위로 이루어진다. 브로커에서 장애가 발생하면 데이터 유실이 발생될 것으로 예상되는데 각각의 데이터를 브로커의 파티션 단위로 복제를 하여, 장애가 나더라도, 데이터를 유실하지 않게 된다. 토픽을 생성할때, replication factor도 같이 설정이 되는데, 이를 설정하지 않으면 브로커에서 설정한 기본값으로 따라간다. 최소값은 1 이고 최대값은 브로커의 개수만큼 설정할 수 있다. 2~3으로 대게 설정한다. 3으로 설정하는 경우, 위와 같고, 파티션이 1개가 되고, 2개가 팔로워로 복..
[Kafka] 세그먼트와 삭제 주기 cleanup.policy로 해당 삭제 주기를 정할수 있다. delete를 하게되면, 기본값 7일이 지나면 삭제된다 (액티브 세그먼트 제외) retention.bytes로 하게되면, 해당 세그먼트의 크기에 따라 삭제 여부를 결정한다. 만료된 세그먼트의 크기를 보고 결정한다. 이 삭제에 대한 작업은 브로커가 한다. log.retention.check.interval.ms에 설정한 값에 따라, 세그먼트가 삭제 영역에 들어왔는지 확인 한다. 기본값은 5분이다. 스케줄링이라고 생각하면 된다. retention.ms 는 기간으로 삭제를 체크하기 때문에, 기간 동안 쌓이는 용량에 따라 디스크의 용량의 문제가 발생할 수있다. 따라서, 앵간하면 크기로 판단하는 것이 중요하다. retention.ms 에서 보유할 최대기..
[Kafka] 브로커의 역할 데이터의 저장 카프카를 실행할때 Config/server.properties 의 log.dir 옵션에 정의한 디렉토리에 데이터를 저장한다. 토픽 이름과 파티션 번호의 조합으로 하위 디렉토리를 생성하여 데이터를 저장한다. -hello.kafaka 토픽의 0번 파티션에 존재하는 데이터를 확인 할 수 있다. log에는 메시지와 메타데이터를 저장한다. index는 메시지의 오프셋을 인덱싱한 정보를 담은 파일이다. timeindex파일에는 메시지에 포함된 타임스탬프 값을 기준으로 인덱싱한 정보가 담겨있다. 만약에 3개짜리 파티션을 만들게 되면, 해당 토픽이 3개로 저장된다.(나눠서가 아닌 복제형태로) 프로듀서는 메시지 (레코드)를 보내게 되는데 이 레코드 안에는 타임스탬프,메시지키,메시지 값 들의 정보가 들어가있..
[Kafka] Broker의 역할 1) 컨트롤러 클러스터의 다수 브로커 중 한대가 컨트롤러의 역할을 한다. 컨트롤러는 다른 브로커들의 상태를 체크하고, 브로커가 클러스터에서 빠지는 경우 해당 브로커에 존재하는 리더 파티션을 재분배한다. 카프카는 지속적으로 데이터를 처리해야 하므로, 브로커의상태가 비정상이라면 빠르게 클러스터에서 빼내는 것이 중요하다. 만약 컨트롤러 역할을 하는 브로커에 장애가 생기면 다른 브로커가 컨트롤러 역할을 한다. 2) 데이터 삭제 카프카는 다른 메시징 플랫폼과 다르게 컨슈머가 데이터를 가져가더라도 토픽의 데이터가 삭제되지 않는다. 브로커가 데이터를 삭제하는데, 이 단위를 로그 세그먼트라고 부른다. 이 세그먼트에는 다수의 데이터가 들어가 있기 떄문에 일반적인 데이터베이스 처럼 특정 데이터를 선별해서 삭제할 수 없다...
[Kafka]주키퍼 앙상블 카프카 클러스터에는 브로커를 각기 다르게 설정할수있다. 이런한 클러스터들은 하나의 주키퍼 앙상블로 운영이 될 수가 있는데 아래와 같다. 하나의 주키퍼 앙상블은 여러대의 클러스터들과 매핑이되고 각 클러스터는 각기 다른 브로커수를 가진다. 카프카 클러스터를 운영하려면, 반드시 주키퍼가 필요하다. 3.0부터는 주키퍼가 없어도 클러스터 자체로 사용가능하다. 하지만, 예전 버전에서는 주키퍼가 필수였어서 앙상블이라는 개념이 도입되었다.
[Kafka] 브로커와 클러스터 주키퍼 카프카 브로커는 카프카 클라이언트와 데이터를 주고받기 위해 사용하는 주체이자 데이터를 분산 저장하여, 장애가 발생하더라도 안전하게 사용할 수 있도록 도와주는 애플리케이션이다. 하나의 서버에는 한개의 카프카 브로커 프로세스가 실행된다. 하나의 서버에는 한개의 카프카 브로커 프로세스가 실행된다. 카프카 브로커 서버 1대로도 기본 기능이 실행되지만, 데이터를 안전하게 보관하고 처리하기 위해 3대이상의 브로커서버를 1개의 클러스터로 묶어서 운영한다. 그래서 하나의 클러스터에는 3개의 브로커를 사용하는게 기본이고 해당 클러스터를 늘리거나, 브로커의 수를 늘리는경우가 있다. 브로커는 한개당 프로세스이다. 한개로도 돌아가지만, 안전하게 사용하려면 한개의 브로커가 아니라 최소 3개이상의 브로커로 운영을 하는게 ..

티스토리툴바