- 데이터의 모든 부분은 의미가 있으며, 그 다음 처리되어야 하는 작업과 같이 뭔가 중요한 정보를 담고 있다.
- 이것이 무엇인지 알기 위해서는 데이터를 생성된 곳에서 분석할 수 있는 곳으로 옮겨야 한다.
- 데이터를 옮기는 작업을 빠르게 해낼 수록 조직은 더 유연해지고 더 민첩해질 수 있다.
- 우리가 데이터를 이동시키는 작업에 더 적은 노력을 들일수록 핵심 비즈니스에 더욱 집중할 수 있다.
발행/구독 메시지 전달#
- 발행/구독 메시지 전달 패턴의 특징은 전송자가 데이터를 보낼 때 직접 수신자로 보내지 않는다는 것이다.
- 대신, 전송자는 어떤 형태로든 메시지를 분류해서 보내고, 수신자는 이렇게 분류된 메시지를 구독한다.
- 발행/구독 시스템에는 대개 발행된 메시지를 전달받고 중계해주는 중간지점 역할을 하는 브로커가 있다.
초기의 발행/구독 시스템#
- 서비스가 커지면서 서버와 애플리케이션 간에 메트릭 데이터를 전송해야되는 구조가 복잡해지고, 이런 방식에서 발생하는 기술 부채는 명백하기 떄문에 다소 개선의 필요가 있다.
- 모든 애플리케이션으로부터 메트릭 데이터를 받는 하나의 애플리케이션을 만들고, 이 지푯값들을 필요로 하는 어느 시스템이든 지표를 질의할 수 있도록 해주는 서버를 제공하면 된다.
- 이렇게하면 메시지 발행/구독 시스템을 하나 만든 셈이다.
개별 메시지 큐 시스템#
- 위 예시에서 사용자 활동을 추적해서 이 정볼르 기계 학습 개발자에게 제공하거나 관리자용 보고서를 생성하는데 사용해야 할 수도 있다.
- 이러한 경우에도 비슷한 시스템을 구성함으로써 정보의 발행자와 구독자를 분리할 수 있다.
- 포인트 투 포인트 연결을 활용하는 방식보다 이쪽이 더 바람직하지만, 여기에는 중복이 많다.
- 이렇게 되면 버그도 한계도 제각각인 다수의 데이터 큐 시스템을 유지 관리해야 한다.
- 여기에 메시지 교환을 필요로 하는 사례가 추가로 생길 수도 있다.
- 비즈니스가 확장됨에 따라 함께 확장되는, 일반화된 유형의 데이터베이스를 발행하고 구독할 수 있는 중앙 집중화된 시스템이 필요하다.
카프카 입문#
- 아파치 카프카는 위에서 설명한 것과 같은 문제를 해결하기 위해 고안된 메시지 발행/구독 시스템이다.
- ‘분산 커밋 로그’ 혹은 ‘분산 스트리밍 플랫폼’이라고 불리기도 한다.
- 카프카에 저장된 데이터는 순서를 유지한채로 지속성 있게 보관되며 결정적으로 읽을 수 있다.
- 또한, 확장시 성능을 향상시키고 실패가 발생하더라도 데이터 사용에는 문제가 없도록 시스템 안에서 데이터를 분산시켜 저장할 수 있다.
메시지와 배치#
- 메시지: 카프카에서 데이터의 기본 단위
- 메시지는 키라 불리는 메타데이터를 포함할 수도 있다.
- 카프카 입장에서 메시지와 키는 단순히 바이트의 배열일 뿐이기 때문에 여기에 포함된 데이터에는 특정한 형식이나 의미가 없다.
- 키는 저장할 파티션을 결정하기 위해 사용된다.
- 카프카는 효율성을 위해 메시지를 배치 단위로 저장한다.
- 배치: 같은 토픽의 파티션에 쓰여지는 메시지들의 집합
- 배치 크기가 커질수록 시간당 처리되는 메시지의 수는 늘어나지만, 각각의 메시지가 전달되는 데 걸리는 시간은 늘어나는 것이다.
- 배치는 더 효율적인 데이터 전송과 저장을 위해 약간의 처리 능력을 들여서 압축되는 경우가 많다.
스키마#
- 카프카 입장에서 메시지는 단순한 바이트 배열일 뿐이지만, 내용을 이해하기 쉽도록 일정한 구조를 부여하는 것이 권장된다.
- 각 애플리케이션의 필요에 따라 사용 가능한 메시지 스키마는 여러 가지 있는데, 가장 간단한 방법으로는 쓰기 쉽고 사람이 알아볼 수 있는 JSON이나 XML이 있다.
- 하지만 이 방식들은 타입 처리 기능이나 스키마 버전 간 호환성 유지 기능이 떨어진다.
- 많은 아파치 카프카 개발자들은 아파치 에이브로(Avro)를 선호한다.
- 에이브로는 조밀한 직렬화 형식을 제공하는 데다가 메시지 본체와 스키마를 분리하기 때문에 스키마가 변경되더라도 코드를 생성할 필요가 없다.
- 강력한 데이터 타이핑과 스키마 변경에 따른 상위 호환성, 하위 호환성 역시 지원한다.
- 카프카에서는 일관적인 데이터 형식이 중요하다
- 메시지 쓰기와 읽기 작업을 분리할 수 있도록 해주기 때문이다.
토픽과 파티션#
- 카프카에 저장되는 메시지는 토픽 단위로 분류된다.
- 토픽과 가장 비슷한 개념으로는 데이터베이스의 테이블이나 파일시스템의 폴더가 있을 것이다.
- 토픽은 다시 여러 개의 파티션으로 나뉘어진다.
- 파티션에 메시지가 쓰여질 때는 append-only 형태로 쓰여지며, 읽을 때는 맨 앞부터 제일 끝까지 순서로 읽힌다.
- 대개 토픽에 여러 개의 파티션이 있는 만큼 토픽 안의 메시지 전체에 대해 순서는 보장되지 않으며, 단일 파티션 안에서만 순서가 보장될 뿐이다.
- 파티션은 카프카가 데이터 복제와 확장성을 제공하는 방법이기도 하다.
- 하나의 토픽이 여러 개의 서버로 수평적으로 확장되어 하나의 서버의 용량을 넘어가는 성능보여 줄 수 있다.
- 서로 다른 서버들이 동일한 파티션의 복제본을 저장하고 있기 때문에 서버 중 하나에 장애가 발생한다고 해서 읽거나 쓸 수 없는 상황이 벌어지지는 않는다.
- 카프카와 같은 시스템을 이야기할 때문 스트림이라는 용어가 자주 사용된다.
- 스트림: 하나의 토픽에 저장된 데이터로 간주되며, 프로듀서로부터 컨슈머로의 하나의 데이터 흐름을 나타낸다.
프로듀서와 컨슈머#
- 프로듀서: 새로운 메시지를 생성한다.
- 발행자 또는 작성자라고도 부른다.
- 메시지는 특정한 토픽에 쓰여진다.
- 기본적으로 프로듀서는 메시지를 쓸 때 토픽에 속한 파티션들 사이에 고르게 나눠서 쓰도록 되어 있다.
- 하지만 어떠한 경우에는, 프로듀서가 특정한 파티션을 지정해서 메시지를 쓰기도 한다.
- 대개, 메시지 키와 키값의 해시를 특정 파티션으로 대응시켜주는 파티셔너를 사용해서 구현된다. 이렇게 함으로써 동일한 키 값을 가진 모든 메시지는 같은 파티션에 저장된다.
- 프로듀서는 메시지를 파티션으로 대응시켜주는 나름의 규칙을 가진 커스텀 파티셔너를 사용할 수도 있다.
- 컨슈머: 새로운 메시지를 읽는다.
- 구독자 또는 독자라고도 한다.
- 컨슈머는 1개 이상의 토픽을 구독해서 여기에 저장된 메시지들을 각 파티션에 쓰여진 순서대로 읽어온다.
- 컨슈머는 메시지의 오프셋을 기록함으로써 어느 메시지까지 읽었는지를 유지한다.
- 오프셋은 지속적으로 증가하는 정수값으로, 카프카가 메시지를 저장할 때 각각의 메시지에 부여해주는 또 다른 메타데이터이다.
- 주어진 파티션의 각 메시지는 고유한 오프셋을 가지며, 뒤에 오는 메시지가 앞의 메시지보다 더 큰 오프셋을 가진다.
- 파티션 별로 다음 번에 사용가능한 오프셋 값을 저장함(대체로 카프카 자체에 저장됨)으로써 컨슈머는 읽기 작업을 정지했다가 다시 시작하더라도 마지막으로 읽었던 메시지의 바로 다음 메시지부터 읽을 수 있다.
- 컨슈머 그룹
- 컨슈머는 컨슈머 그룹의 일원으로서 작동한다.
- 컨슈머 그룹은 토픽에 저장된 데이터를 읽어오기 위해 협업하는 하나 이상의 컨슈머로 이루어진다.
- 컨슈머 그룹은 각 파티션이 하나의 컨슈머에 의해서만 읽히도록 한다.
- 컨슈머에서 파티션으로 대응 관계는 컨슈머의 파티션의 소유권이라고 부른다.
- 이 방법을 사용함으로써 대량의 메시지를 갖는 토픽들을 읽기 위해 컨슈머들을 수평 확장할 수 있다.
- 또한, 컨슈머 중 하나에 장애가 발생하더라도, 그룹 안에 다른 컨슈머들이 장애가 발생한 컨슈머가 일곡 있던 파티션을 재할당받은 뒤 이어서 데이터를 읽어올 수 있다.
브로커와 클러스터#
- 하나의 카프카 서버를 브로커라고 부른다.
- 브로커는 프로듀서로부터 메시지를 전달받아 오프셋을 할당한 뒤 디스크 저장소에 쓴다.
- 브로커는 컨슈머의 파티션 읽기 요청 역시 처리하고 발행된 메시지를 보내준다.
- 카프카 브로커는 클러스터의 일부로서 작동하도록 설계되었다.
- 하나의 클러스터 안에 여러 개의 브로커가 포함될 수 있으며, 그중 하나의 브로커가 클러스터 컨트롤러의 역할을 하게 된다. (컨트롤러는 클러스터 안의 현재 작동 중인 브로커 중 하나가 자동으로 선정된다)
- 컨트롤러는 파티션을 브로커에 할당해주거나 장애가 발생한 브로커를 모니터링하는 등의 관리 기능을 담당한다.
- 파티션은 클러스터 안의 브로커 중 하나가 담당하며, 그 브로커를 파티션 리더라고 부른다.
- 복제된 파티션이 여러 브로커에 할당될 수도 있는 이것들을 파티션의 팔로워라고 부른다.
- 복제 기능은 파티션의 메시지를 중복 저장함으로써 리더 브로커에 장애가 발생했을 때 팔로워 중 하나가리더 역할을 이어받을 수 있도록 한다.
- 모든 프로듀서는 리더 브로커에 메시지를 발행해야하지만, 컨슈머는 리더나 팔로워 중 하나로부터 데이터를 읽어올 수 있다.
- 아파치 카프카의 핵심 기능 중에 일정 기간 동안 메시지를 지속성 있게 보관하는 보존 기능이 있다.
- 카프카 브로커는 토픽에 대해 기본적인 보존 설정이 되어 있는데, 특정 기간동안 메시지를 보존하거나(예, 7일) 파티션의 크기가 특정 사이즈에 도달할 때까지(예, 1GB) 데이터를 보존한다.
- 이러한 한도값에 도달하면 메시지는 만료되어 삭제된다.
- 각각 토픽에는 메시지가 필요한 정도까지만 저장되도록 보존 설정을 잡아줄 수 있다.
- 토픽에는 로그 압착 기능을 설정할 수도 있는데, 이 경우 같은 키를 갖는 메시지 중 가장 최신의 겂만 보존된다.
- 이 기능은 마지막 변경값만이 중요한 체인지로그 형태의 데이터에 사용하면 좋다.
다중 클러스터#
- 설치된 카프카가 확장 되어감에 따라 다수의 클러스터를 운영하는 것이 더 나은 경우가 있다. 이 방식에는 아래와 같은 장점이 있다.
- 데이터 유형별 분리
- 보안 요구사항을 충족시키기 위한 격리
- 재해 복구(DR)를 대비한 다중 데이터센터
- 카프카가 다수의 데이터센터에서 운용될 때는 데이터센터 간에 메시지를 복제해 줄 필요가 있는 경우가 많다.
- 카프카 클러스터의 복제 메커니즘은 다중 클러스터 사이에서가 아닌 하나의 클러스터 안에서만 작동하도록 작동하도록 설계되었다.
- 카프카 프로젝트는 데이터를 다른 클러스터로 복제하는 데 사용되는 미러메이커(MirrorMaker)라는 툴을 포함한다.
- 근본적으로 미러메이커도 단지 큐로 연결된 카프카 컨슈머와 프로듀서에 불과하다.
- 하나의 카프카 클러스터에서 메시지를 읽어와서 다른 클러스터에 쓴다.
- 아래는 미러메이커를 사용하는 아키텍처의 예제를 보여주는데, 두 개의 로컬 클러스터의 메시지를 하나의 직접 클러스터로 모은 뒤 다른 데이터 센터로 복사하는 모습을 보여준다.
왜 카프카인가?#
다중 프로듀서#
- 카프카는 프로듀서가 여러 토픽을 사용하든 하나의 토픽을 사용하든 상관없이 자연스럽게 여러 프로듀서를 처리할 수 있다.
다중 컨슈머#
- 카프카는 많은 컨슈머와 상호 간섭 없이 어떠한 메시지 스트림도 읽을 수 있도록 설계되었다.
- 이것이 하나의 메시지를 하나의 클라이언트에서만 소비할 수 있도록 되어있는 많은 큐 시스템과의 결정적인 차이점이기도 하다.
- 다수의 카프카 컨슈머는 컨슈머 그룹의 일원으로 작동함으로써 하나의 스트림을 여럿이서 나눠서 읽을 수 있다.
디스크 기반 보존#
- 카프카는 메시지를 지속성 있게 저장할 수도 있다.
- 이는 컨슈머들이 항상 실시간으로 데이터를 읽어올 필요는 없다는 의미이기도 하다.
- 메시지는 디스크에 쓰여진 뒤 설정된 보유 규칙과 함께 저장된다.
- 이 옵션은 토픽별로 설정이 가능하기 때문에 서로 다른 메시지 스트림이 컨슈머의 필요에 따라 서로 다른 기간 동안 보존될 수 있다.
- 따라서 만약 컨슈머가 느린 처리 속도 혹은 트래픽 폭주로 인해 뒤처질 경우에도 데이터 유실의 위험은 없다.
확장성#
- 카프카는 유연한 확장성을 가지고 있기 때문에 어떠한 크기의 데이터도 쉽게 처리할 수 있다.
- 처음에는 실제로 잘 돌아가는지 검증하는 의미에서 하나의 브로커로 시작한 뒤 3개의 브로커를 가진 소규모의 개발용 클러스터, 마지막에는 데이터 증가에 따라 수십 개에서 수백 개의 브로커로 구성된 대규모 클러스터로 이루어진 프로덕션 환경으로 옮겨가면 된다.
- 카프카 클러스터는 작동 중에도 시스템 전체의가용성에 영향을 주지 않으면서 확장이 가능하다.
고성능#
- 아파치 카프카가 고부하 아래에서도 높은 성능을 보여주는 발행/구독 메시지 전달 시스템이 될 수 있었던 것은 지금까지 설명한 모든 특징들 덕분이다.
플랫폼 기능#
- 아파치 카프카의 코어 프로젝트에는 개발자들이 자주 하는 작업을 훨씬 쉽게 수행할 수 있도록해주는 플랫폼 기능이 추가되어 있다.
- YARN처럼 구조화된 런타임 환경을 포함하는 완전한 플랫폼은 아니지만, 이 기능들을 탄탄한 기반과 자유로운 형태로 실행할 수 있는 유연성을 갖춘 API와 라이브러리의 형태로 사용이 가능하다.
- 카프카 커넥트는 소스 데이터 시스템으로부터 카프카로 데이터를 가져오거나 카프카의 데이터를 싱크 시스템으로 내보내는 작업을 도와준다.
- 카프카 스트림즈는 규모 가변성과 내고장성을 갖춘 스트림 처리 애플리케이션을 쉽게 개발할수 있게 해주는 라이브러리다.
데이터 생태계#
이용 사례#
- 활동 추적
- 메시지 교환
- 지표 및 로그 수집
- 커밋 로그
- 스트림 처리
