02 카프카 알아보기

2.1 메시지 생산과 소비

• 레코드라고도 불리는 메시지는 카프카를 통해 흐르는 데이터의 기본 요소다.
• 메시지는 카프카가 데이터를 표현하는 방식이다.
• 개별 메시지는 타임스탬프, 값 그리고 선택적으로 키를 갖고 있다.

2.2 브로커란 무엇인가?

• 브로커는 카프카의 서버 측면으로 생각할 수있다.
• 유의할 점은 카프카는 명령줄을 염두에 두고 개발되었다.
  • 사용할 GUI가 없으므로 운영체제의 명렬줄 인터페이스와 상호 작용할 방법이 필요하다.

토픽 만들기

bin/kafka-topics.sh --create --bootstrap-server localhost:9094 --topic kinaction_helloworld --partitions 3 --replication-factor 3

• --partitions 옵션은 토픽을 얼마나 분할할 것인지 결정한다. 브로커가 3개가 있기 때문에 파티션 3개를 사용하면 브로커당 파티션 1개씩 제공된다.
• --replication-factor는 개별 파티션에 대해 레플리카가 3개가 필요하다는 뜻이다. 이는 신뢰성과 내결함성 향상을 위해 중요한 부분이다.

토픽 확인하기

bin/kafka-topics.sh --list --bootstrap-server localhost:9094 

토픽 세부 정보 조회

bin/kafka-topics.sh --bootstrap-server localhost:9094 --describe --topic kinaction_helloworld

• 위 명령어를 시도하면 토픽이 가진 파티션과 레플리카 전체 개수를 볼 수 있다.
• 첫째줄 다음부터는 개별 파티션에 대한 정보로 레플리카와 ISR 을 표시한다.
• ISR 은 동기화된 레플리카를 표시하는데, 현재 리더보다 뒤처지지 않은 상태의 브로커를 표시한다.
• 파티션 리더를 참조할 때 레플리카 리더를 참조한다.
• 파티션은 1개 이상의 레플리카로 구성될 수 있다.
  • 리더가 아닌 레플리카는 레플리카의 리더로부터만 업데이트를 받는다.

카프카 컨슈머 명령

bin/kafka-console-consumer.sh --bootstrap-server localhost:9094 --topic kinaction_helloworld --from-beginning

• 프로세스를 종료하고 재시작할 때 --from-beginning 옵션을 제거하면 이전에 보냈던 메시지는 볼 수 없고 콘솔이 시작된 이후의 생산된 메시지만 표시된다.

2.3 카프카 투어

2.3.1 프로듀서와 컨슈머

• 프로듀서는 메시지를 카프카 토픽에 보내는 도구이다.
• 카프카 내부에서 자체적으로 메시지를 보낼 경우에도 사용한다.
  • 예를 들어, 특정 토픽에서 데이터를 읽어 다른 토픽으로 전달해야 할 경우에도 프로듀서를 사용한다.
• 컨슈머는 카프카에서 메시지를 검색하는 도구이다.
• 컨슈머 역할을 수행하는 애플리케이션은 관심 있는 토픽을 구독하고 지속적으로 데이터를 폴링한다.

2.3.2 토픽 개요

• 토픽은 대다수 사용자가 어떤 메시지가 어디로 가야하는지에 관한 로직을 생각하기 시작하는 곳이다.
• 토픽은 파티션이라는 단위로 구성된다.
  • 1개 이상의 파티션이 단일 토픽을 구성한다.
  • 단일 파티션의 레플리카는 단 하나의 브로커에서만 존재하며 브로커 간에 분할될 수 없다.
• 파티션은 세그먼트 파일로 세분화되어 디스크 드라이브에 기록되는데, 이는 내부의 세부 구현으로만 간주된다.
• 파티션 복사본 중 하나가 리더가 되는데, 예를 들어 파티션 3개로 된 토픽이 있고 각 파티션은 3개의 복사본을 갖고 있다면, 모든 파티션은 각각 리더 레플리카를 선출했을 것이다.
  • 리더는 파티션 복사본 중 하나가 되며, 다른 두 복사본은 파티션 리더로부터 데이터를 업데이트 받는 팔로워가 될 것이다.
• 프로듀서와 컨슈머는 각 파티션의 리더 레플리카에서만 읽고 쓸 수 있다.

2.3.3 주키퍼의 용도

• 카프카 클러스터는 1개 이상의 브로커를 포함한다.
• 브로커는 브러커 상호간에 통신을 하고 합의에 도달한다.
• 리더 레플리카가 어떤 파티션인지에 동의하는 것은 카프카 생태계 내 주키퍼를 적용한 한 가지 사례이다.

2.3.4 카프카의 고가용성 아키텍처

• 카프카 핵심은 JVM에서 실행되는 스칼라 애플리케이션 프로세스라고 생각할 수 있다.
• 그러나 수백만 개의 메시지를 빠르게 처리 가능하게 하는 핵심 기능 중 하나는 운영체제의 페이지 캐시 사용이다.
• 브로커가 JVM 힙에 캐시되지 않도록 하여 크기가 큰 힙으로 인해 발생하는 문제(장시간 또는 빈번한 가비지 컬렉션으로 인한 일시적인 멈춤과 같은)를 방지한다.
• 데이터 접근 패턴(access pattern)도 중요한 고려사항이다.
  • 새 메시지가 유입될 때, 많은 컨슈머가 가장 최신 메시지와 상호 작용할 가능성이 더 높으며 최신 메시지는 캐시로부터 제공 받을 수 있다.
  • 페이지 캐시에서 제공받는 경우 대부분 디스크보다 더 빠르다.
• 카프카는 자체 프로토콜 AMQP(Advanced Message Queuing Protocol)을 사용한다.

2.3.5 커밋 로그

• 커밋 로그 개념은 로거로부터 출력을 집계하는 로그 사용사례와는 다르다.
• 커밋 로그는 카프카의 중심에 위치하며 사용자들은 오프셋을 사용해 메시지가 그 로그에서 어디에 위치하는지를 알 수 있다.
• 이벤트가 항상 로그 마지막에 추가되는 추가 전용 특성때문에 커밋 로그를 더 특별하게 만든다.
  • 스토리지의 로그 영속성은 카프카를 다른 메시지 브로커와 구별 짓는 주요 부분이다.
  • 카프카 로그 데이터 보존 기간은 시간과 크기로 구성 속성에서 제어가 가능하다

2.4 다양한 소스 코드 패키지와 역할

2.4.1 카프카 스트림즈

• 카프카 코어 그 자체와 비교해서 많은 주목을 받았다.
• 카프카 스트림즈의 가장 좋은 점 중 하나는 독립된 프로세싱 클러스터가 필요하지 않다. 즉 경량 라이브러리이다.
• 이 API는 스트리밍 애플리케이션을 가능한 쉽게 작성하게 해준다.
• 카프카를 사용하면 데이터를 멍잉하는 서비스 없이 모든 애플리케이션에 데이터를 노출할 수 있다.

2.4.2 카프카 커넥트

• 이 프레임워크는 다른 시스템을 쉽게 통합하기 위해 만들어졌다.
• 소스 커넥터는 소스에서 카프카로 데이터를 임포트하기 위해 사용된다.
  • 예를 들어 MySQL 테이블에서 카프카 토픽으로 데이터를 이용하려고 한다면 메시지를 카프카로 생산하기 위해 커넥트 소스를 사용할 것이다.
• 싱크 커넥터는 카프카에서 다른 시스템으로 데이터를 익스포트하기 위해 사용된다.
  • 예를 들어 어떤 토픽에 있는 메시지를 장기간 유지하려면 토픽으로부터 메시지를 소비하여 클라우드 저장소 같은 장소에 두기 위해 싱크 커넥터를 사용할 것이다.

2.4.3 AdminClient 패키지

• 이 API 이전에는 특정 관리 액션을 수행하기 위한 스크립트나 프로그램은 셸 스크립트나 셸 스크립트가 자주 사용하는 내부 클래스를 호출해야 했다.

2.4.4 ksqlDB

• 연속적인 데이터 흐름을 이용하기 쉽게 만들어 준다.
• 익숙한 SQL 과 유사한 문법을 사용하지만, 쿼리가 연속적으로 실행되고 업데이트 된다는 점이 핵심이다.

2.5 컨플루언트 클라이언트

• 모든 클라이언트가 기능 측면에서 동일한 것은 아니기 때문에, 컨플루언트는 프로그래밍 언어에 따라 지원하는 기능 대조표를 사이트에서 제공한다.
• 자바 클라이언트 사용하는 경우
  • 데이터를 카프카로 이동할 때 직렬화하기 위한 클래스를 제공해야 하는데, 키와 값에 같은 직렬 변환기를 지정할 필요는 없다.
  • 프로듀서 클라이언트는 스레드 안전하다.
  • 컨슈머 클라이언트는 스레드 안전하지 않다. 따라서, 단일 컨슈머를 넘어서 확장할 때 스레드 안전 문제를 고려해야 한다. 한 가지 간단한 선택지는 자바 스레드당 하나의 컨슈머만 둔다.

2.6 스트림 처리와 용어

• 프로듀서는 데이터를 카프카로 보내고, 카프카는 로그를 기반으로 한 신뢰성과 확장성 있는 분산 시스템으로 작동한다.
• 카프카 생태계 내부로 데이터가 들어오면, 컨슈머는 다른 애플리케이션과 그들의 사용 사례에서 데이터를 활용 가능하도록 사용자를 도운다.
• 브로커는 클러스터를 구성하고 메타데이터를 유지하기 위해 주키퍼 클러스터로 코데네이트 한다.
• 카프카가 데이터를 디스크에 저장하기 때문에 애플리케이션 실패의 경우 데이터를 리플레이하는 기능은 카프카 기능 세트의 일부기도 하다.

2.6.1 스트림 처리

• 스트리밍 데이터의 핵심 원칙은 데이터가 계속 도착하며 끝나지 않는다는 사실이다.
• 소스 코드는 항상 이 데이터를 처리해야 하며, 실행 요청이나 시간 프레임을 기다리지 않아야 한다.

2.6.2 정확히 한 번의 의미

• 정확히 한 번을 유지하는 가장 쉬운 방법은 카프카의 범위(및 토픽) 내에서 작업하는 것이다.
• 스트림즈 API를 사용하면 트랜잭션으로 처리 가능한 폐쇄된 시스템을 구축하여 정확히 한 번을 유지할 수 있다.
• 카프카 커넥트의 다양한 커넥터도 정확히 한 번을 지원하며, 모든 시나리오에서 카프카가 데이터의 종점은 아니기 때문에 카프카 커넥트도 카프카에서 데이터를 가녀오는 좋은 예이다.