컨슈머란, 프로듀서가 메세지를 생산해서 카프카의 토픽으로 보내면 그 토픽의 메세지를 가져와 소비하는 애플리케이션, 서버이다.
주요 기능은, 특정 파티션을 관리하고 있는 파티션 리더에게 메세지를 가져오기 요청을 하는 것이다.

파티션과 메세지 순서

파티션 3 개로 구성한 토픽과 메세지 순서

프로듀서 다음 순서로 보낸다.

1
2
3
4
5

a
b
c
d
e

컨슈머에서 –from-beginning 옵션으로 받는다.
메세지의 순서가 프로듀서가 보낸 순서가 아니다.

1
2
3
4
5

a
d
b
e
c

다음으로, 프로듀서서가 숫자를 보낸다.

1
2
3
4
5

1
2
3
4
5

컨슈머에서 –from-beginning 옵션으로 받는다.

프로듀서란, 메세지를 생산해서 카프카의 토픽으로 보내는 역할을 하는 애플리케이션 or 서버이다.
주요 기능은, 각각의 메세지를 토픽 파티션에 매핑하고 파티션의 리더에 요청을 보내는 것이다.
프로듀서 옵션 중에 acks 옵션 설정에 따라
카프카로 메세지를 전송할 때, 메세지 손실 여부와 메세지 전송 속도 및 처리량이 달라진다.

1. 메세지 보내고 확인하지 않기
   메세지 손실 가능성이 있다.

2. 동기 전송
   카프카의 응답을 기다린다.

3. 비동기 전송
   응답을 기다리지 않기 때문에 빠른 전송이 가능하다.

메세지 손실 가능성 높음 && 빠른 전송 속도

acks = 0
카프카 서버의 응답을 기다리지 않고 메세지 보낼 준비가 되면 즉시 다음 요청을 보낸다.

메세지 손실 가능성 낮음 && 적당한 전송 속도

asks = 1
프로듀서는 메세지를 보내고 Leader 는 잘 받았으면, 바로 ack 를 한다.
팔로워들은 주기적으로 리더를 확인하고 새로운 메세지가 확인되면 팔로워들에도 저장한다.
메세지 손실이 발생하는 경우는 리더에 장애가 발생하는 경우이다.
즉, 프로듀서가 리더에게 메세지를 보내고 리더는 메시지를 저장한 후에 바로 장애가 발생하는 경우이다.

메세지 손실 없음 && 느린 전송 속도

acks = all
메세지를 보내고 잘 받았는지 확인하고 추가적으로 팔로워들까지 메세지를 잘 받았는지 확인한다.
이 때, 프로듀서 설정 뿐만 아니라 브로커 설정도 같이 해줘야한다.

프로듀서 acks = all, 브로커 min.insync.replicas = 1

카프카 디자인의 특징

분산 시스템

분산 시스템이란, 같은 역할을 하는 여러 대의 서버로 이뤄진 서버 그룹이다.
장점은,

1. 단일 시스템 보다 높은 성능
2. 하나의 서버가 장애가 발생해도 다른 서버가 대신 처리
3. 시스템 확장 용이

페이지 캐시

OS 는 물리적 메모리에 애플리케이션이 사용하는 부분을 할당하고, 남은 잔여 메모리 일부를 페이지 케시로 이용한다.
즉, 디스크에 읽고 쓰기를 하지 않고 페이지 케시를 읽고 쓰는 방식으로 처리 속도가 빠르고 전체적인 성능을 향상 시킨다.

배치 전송 처리

서버와 클라이언트 사이, 또는 서버 내부적으로 데이터를 주고 받는 과정에서 I/O 가 발생한다.
작은 I/O 가 빈번하게 발생하는 것을 막기 위해, 작은 I/O 들을 묶어러 처리할 수 있도록 배치 작업으로 처리한다.

카프카 데이터 모델

토픽

코드 재사용 기법으로는,

1. 상속
   부모클래스와 자식클래스를 연결해서, 부모클래스의 코드 재사용

2. 합성
   전체를 표현하는 객체가 부분을 표현하는 객체를 포함해서 객체의 코드 재사용
   내부에 포함되는 객체의 구현이 아니라 퍼블릭 인터페이스에 의존

01 상속을 합성으로 변경하기

상속의 문제는,

1. 불필요한 인터페이스 상속
2. 메서드 오버라이딩 오작용
3. 부모 클래스와 자식 클래스 동시 수정

이 문제들을 합성으로 해결해보자.

불필요한 인터페이스 상속 : java.utils.Properties, java.utils.Stack

1. 불필요한 Hasbtable 의 오퍼레이션들이 Properties 클래스의 퍼블릭 인터페이스를 오염시키지 않는다.

1
2
3
4
5
6
7
8
9
10
11

public class Properties {
    private Hashtable<String, String> properties = new Hashtable<>();

    public String setProperty(String key, String value) {
        return properties.put(key, value);
    }

    public String getProperty(String key) {
        return properties.get(key);
    }
}

2. 불필요한 Vector 의 오퍼레이션들이 Stack 클래스의 퍼블릭 인터페이스를 오염시키지 않는다.

카프카 : 대용량, 대규모 메세지 데이터를 빠르게 처리하도록 개발된 메시징 플랫폼

탄생 배경

end-to-end 아키텍쳐의 문제점은,

1. 통합된 전송 영역이 없어서 복잡도 증가하고
2. 데이터 파이프라인의 관리가 어렵다.

하지만 카프카는 아래 그림 처럼,

1. 모든 시스템으로 데이터 전송이 가능하고
2. 실시간 처리 가능하고
3. 확장이 용이하다.

동작 방식과 원리

메시징 시스템을 먼저 살펴보자.
중앙에 메시징 시스템 서버를 두고 메시지를 Publish 하고 Subscribe 하는 형태의 통신을 Pub/Sub 모델이라고 한다.