아파치 카프카란?
Apache Kafka는 전통적인 메시지 시스템으로서 메시징 처리 뿐만 아니라, 사용자의 웹 사이트 활동 추적 파이프라인으로 활용하고 애플리케이션의 통계를 집계해 모니터링 데이터로 사용한다. 예전에는 데이터가 필요하면 데이터를 관장하는 조직(Mysql 등)에 요청하고 기다리는 작업을 수없이 반복함으로써 데이터 분석에 걸리는 시간이 늘고 효율도 떨어졌지만, 카프카를 사용함으로써 이벤트 소싱과 같이 시간순으로 발생하는(시계열 데이터) 이벤트를 카프카라는 데이터 버스에 저장해서, 필요한 조직이나 인력이 이 데이터를 필요한 때에 언제든 즉시 활용할 수 있도록 데이터 분석 환경이 빠르게 바뀌고 있다.
카프카는 이처럼 비동기 통신 방식을 매우 큰 규모로, 아주 빠르게 처리할 수 있게 개발된 애플리케이션이다.
2011년 초에 세상에 공개된 이후, 현재 Netflix, Uber, LinkedIn, AirBnB, Microsoft, Kakao, Line 과 같이 사용자의 데이터를 심층적으로 실시간 분석해서 사용해야 하는 수많은 기업에서 비동기 전용 프레임워크로 도입해 사용하고 있다.
카프카의 탄생 배경
Apache Kafka는 링크드인에서 최초로 도입했으며, 기존의 End-to-end 연결 방식의 아키텍처는 많은 문제점이 있었다.
첫 번째로 실시간 트랜잭션(OLTP) 처리와 비동기 처리가 동시에 이루어지지만 통합된 전송 영역이 없으니 복잡도가 증가할 수 밖에 없었다. 이 때문에 문제를 발견하고 조치를 취하려면 이와 관련된 여러 데이터 시스템을 확인해야 한다. 그리고 장애나 운영체제 업그레이드, 하드웨어 증설과 같은 작업을 위해서도 역시 아주 많은 준비 시간이 필요하다.
두 번째로 데이터 파이프라인 관리의 어려움이다. 실시간 트랜잭션 데이터베이스, 아파치 하둡, 모니터링 시스템, 키-값 저장소 등 많은 데이터 시스템들이 있는데, 이 시스템에 저장된 동일한 데이터를 개발자나 개발 부서는 각기 다른 방법으로 파이프라인을 만들고 유지하게 되었다. 처음에는 각자의 목적에 맞게 만들어서 간편했지만, 시간이 지나면서 이 데이터 파이프라인들은 통합 데이터 분석을 위해 서로 연결되어야 하는 일들이 필연적으로 발생한다. 하지만 각 파이프라인별로 데이터 포맷과 처리하는 방법들이 완전히 달라서 데이터 파이프라인은 확장하기 어려웠고, 이러한 데이터 파이프라인들을 조정하고 운영하는 것은 엄청난 노력이 필요했다. 게다가 복잡성으로 인해 두 시스템 간의 데이터가 서로 달라져 데이터의 신뢰도마저 낮아졌다.
이렇게 복잡도가 늘고 파이프라인이 파편화되면서 개발이 지연되고 데이터를 신뢰할 수 없는 상황에 이르자, 링크드인에서 개발팀을 이끌고 있던 카프카의 창시자 Jay Kreps는 Neha Narkhede, Jun Rao와 함께 새로운 팀을 구성해 모든 시스템으로 데이터를 전송할 수 있고, 실시간 처리도 가능하며, 급속도로 성장하는 서비스를 위해 확장이 용이한 시스템을 직접 만들기로 했다. 이 팀은 4개의 목표를 가지고 있었는데,
첫번째로는 프로듀서와 컨슈머의 분리
두번째로는 메시징 시스템과 같이 영구 메시지 데이터를 여러 컨슈머에게 허용
세번째로는 높은 처리량을 위한 메시지 최적화
네번째로는 데이터가 증가함에 따라 스케일아웃이 가능한 시스템이다.
이러한 모든 목표를 해결 가능한 애플리케이션을 만들게 된 것이다. 이것이 카프카의 탄생 배경이다.
카프카의 동작 방식과 원리
카프카는 기본적으로 메시징 서버로 동작한다. 따라서 카프카의 동작 방식을 설명하기에 앞서 먼저 메시징 시스템에 대해 살펴보면, 메시지라고 불리는 데이터 단위를 보내는 측(퍼블리셔 또는 프로듀서 라고 함) 에서 카프카에 토픽이라는 각각의 메시지 저장소에 데이터를 저장하면, 가져가는 측(서브스크라이버, 컨슈머 라고 함) 이 원하는 토픽에서 데이터를 가져가게 되어있다. 중앙에 메시징 시스템 서버를 두고 이렇게 메시지를 보내고(publish) 받는(subscribe) 형태의 통신을 pub/sub 모델이라고 한다.
pub/sub 은 비동기 메시징 전송 방식으로서, 발신자의 메시지에는 수신자가 정해져 있지 않은 상태로 발행(publish)한다. 구독(subscribe)을 신청한 수신자만이 정해진 메시지를 받을 수 있다. 또한 수신자는 발신자 정보가 없어도 원하는 메시지만을 수신할 수 있다. 이러한 구조 덕분에 다이나믹한 네트워크 토폴로지와 높은 확장성을 확보할 수 있다.
일반적인 통신 방식은 빠른 전송 속도와 전송 결과를 신속하게 알 수 있는 장점이 있는 반면에, 특정 개체에 장애가 발생한 경우 메시지를 보내는 쪽에서 대기 처리 등을 개별적으로 해주지 않으면 장애가 발생할 수 있다. 그리고 일반적 형태의 통신의 경우 통신에 참여하는 개체가 많아질 수록 서로 일일이 다 연결을 하고 데이터를 전송해야 하기 때문에 확장성이 좋지 않다.
이런 형태의 단점을 극복하고자 나온 통신 모델이 바로 pub/sub모델인데, 작동 방식은 프로듀서가 메시지를 컨슈머에게 직접 전달하는 것이 아니라 중간의 메시징 시스템에 전달한다. 이 때, 메시지 데이터와 수신처 ID를 포함시킨ㄴ다. 메시징 시스템의 교환기가 메시지의 수신처 ID값을 확인한 다음 컨슈머들의 큐에 전달한다. 컨슈머는 자신들의 큐를 모니터링하고 있다가, 큐에 메시지가 전달되면 이 값을 가져간다.
이렇게 구성할 경우 장점은 개체가 하나 빠지거나 수신 불능 상태가 되었을 때에도, 메시징 시스템만 살아 있으면 프로듀서에게 전달된 메시지가 유실되지 않는다. 이 메시지는 불능 상태의 개체가 다시 회복되면 언제든지 다시 가져갈 수 있고, 각각의 개체가 다대다 통신을 하는 것이 아니라 메시징 시스템을 중심으로 연결되기 때문에 확장성이 매우 용이하다. 그리고 사용자나 어드민이 연결을 직접 관장하는 것이 아니라, 교환기의 룰에 의해서 데이터가 수신처의 큐에 정확하게 전달되므로 메시지 데이터 유실의 염려가 없다. 다만 pub/sub의 단점은 직접 통신하지 않기 때문에 메시지가 정확하게 전달되었는지 확인하려면 코드가 좀 더 복잡해지고, 중간에 메시징 시스템이 있기 때문에 메시지 전달 속도가 빠르지 않다는 점이다.
그래서 카프카는 메시징 시스템이 지닌 성능의 단점을 극복하기 위해, 메시지 교환 전달의 신뢰성 관리를 프로듀서와 컨슈머 쪽으로 넘기고, 부하가 많이 걸리는 교환기 기능 역시 컨슈머가 만들 수 있게 함으로써 메시징 시스템 내에서의 작업량을 줄이고 이렇게 절약한 작업량을 메시징 전달 성능에 집중시켜서 고성능 메시징 시스템을 만들어 냈다.
카프카 역시 기존 메시징 시스템과 동일한 비동기 시스템이다. 프로듀서는 컨슈머와 관계없이 새로운 메시지를 카프카로 전송하고, 컨슈머 역시 프로듀서와 관계없이 카프카에서 새로운 메시지를 가져온다. 이렇게 프로듀서와 컨슈머는 각자의 역할이 정확하게 구분되어 있다. 카프카에도 수많은 메시지들이 저장되고, 그 메시지들은 토픽이라는 식별자를 이용해 토픽 단위로 저장되고 있다.
이처럼 비동기 기반으로 메시지를 전달하는 대표적인 솔루션이 메시지 큐 솔루션이다.
카프카의 특징
1. 프로듀서와 컨슈머의 분리
웹 서비스를 제공하는 회사에서는 안정적인 서비스를 위해 웹 서버에 모니터링을 적용한다. 웹 서버 뿐만 아니라 앱 서버, 데이터베이스 서버에도 모니터링을 적용한다. 이후에는 로그 분석 등이 필요하게 되어 각 애플리케이션들마다 로그 분석 시스템을 적용한다. 그 외에도 서버의 메트릭을 수집해 활용하기 위해 메트릭 수집 서버도 적용한다.
위처럼 구조를 단순히 할 수 있고, 각각의 서비스 서버(producer)들은 모니터링이나 분석 시스템의 상태 유무와 관계없이 카프카로 메시지를 보내는 역할만 하면 되고, 마찬가지로 모니터링이나 분석 시스템들도 서비스 서버들의 상태 유무와 관계없이 카프카에 저장되어 있는 메시지만 가져오면 된다. 이렇게 각자의 역할이 완벽하게 분리되면서, 어느 한 쪽 시스템에서 문제가 발생하더라도 연쇄작용이 발생할 확률은 매우 낮다. 또한 웹 서버가 추가되더라도(scale-up) 카프카로만 보내면 되기 때문에 서버 추가에 대한 부담도 줄일 수 있는 장점이 있다.
2. 멀티 프로듀서와 멀티 컨슈머
카프카는 하나의 토픽에 여러 프로듀서 또는 컨슈머들이 접근 가능한 구조로 되었다. 하나의 프로듀서가 하나의 토픽에만 메시지를 보내는 것이 아니라 하나 또는 하나 이상의 토픽으로 메시지를 보낼 수 있다. 컨슈머는 역시 하나의 토픽에서만 메시지를 가져오는 것이 아니라, 하나 또는 하나 이상의 토픽으로부터 메시지를 가져올 수 있다. 이러한 멀티 기능은 데이터 분석 및 처리 프로세스에서 하나의 데이터를 다양한 용도로 사용하는 요구가 많아지기 시작했고, 이러한 요구 사항들을 손쉽게 충족할 수 있다.
메시지를 전송하는 프로듀서 A는 토픽 A로 메시지1을 보내고 있다. 멀티 프로듀서가 가능하기 때문에 프로듀서B는 토픽 A와 토픽 B 두 개의 토픽으로 메시지2를 각각 보낼 수 있다. 컨슈머 부분을 보면, 컨슈머 A는 토픽 A에서 메시지1을 가져오고 있지만 토픽B에서도 메시지2를 가져오고 있다. 컨슈머B는 토픽B에서만 메시지2를 가져오고 있다. 이렇게 멀티 프로듀서와 컨슈머를 구성할 수 있기 때문에 카프카는 중앙 집중형 구조로 구성할 수 있게 된다.
3. 디스크에 메시지 저장
카프카가 기존의 메시징 시스템과 다른 특징 중 하나는 바로 디스크에 메시지를 저장하고 유지하는 것이다. 일반적인 메시징 시스템들은 컨슈머가 메시지를 읽어가면 큐에서 바로 메시지를 삭제한다. 하지만 카프카는 컨슈머가 메시지를 읽어가더라도 정해져 있는 보관 주기 동안 디스크에 메시지를 저장해둡니다. 트래픽이 일시적으로 폭주해 컨슈머의 처리가 늦어지더라도 카프카의 디스크에 안전하게 보관되어 있기 때문에 컨슈머는 메시지 손실 없이 메시지를 가져갈 수 있다. 그 밖에도 여러 가지 장점이 있다. 앞서 언급한 멀티 컨슈머에도 카프카에 메시지들이 디스크로 저장되어 있기 때문에 가능한 것이고, 컨슈머에 버그가 있어 오류를 발생했다면, 컨슈머를 잠시 중단하고 버그를 찾아 해결한 수 컨슈머를 다시 실행할 수 있다. 이러한 방법으로 작업하더라도 메시지가 디스크에 저장되어 있기 때문에 메시지 손실 없이 작업이 가능하다.
4. 확장성
카프카는 확장이 매우 용이하도록 설계되어 있다. 하나의 카프카 클러스터는 3대의 브로커로 시작해 수십 대의 브로커로 확장 가능하다. 또한 확장 작업은 카프카 서비스의 중단 없이 온라인 상태에서 작업이 가능하다. 최초 카프카 클러스터 구성 시 적은 수로 시작하더라도 이후 트래픽 및 사용량 증가로 클러스터를 확장하는 작업은 매우 간단할 뿐 아니라, 큰 부담 없이 할 수 있다.
5. 높은 성능
카프카는 매우 높은 성능을 목표로 탄생한 애플리케이션이다. 고성능을 유지하기 위해 카프카는 내부적으로 분산 처리, 배치 처리 등 다양한 기법을 사용하고 있다.
카프카 용어 정리
카프카(Kafka) : 아파치 프로젝트 애플리케이션 이름. 클러스터 구성이 가능하며, 카프카 클러스터라고 부른다.
브로커(Broker) : 카프카 애플리케이션이 설치되어 있는 서버 또는 노드를 말한다.
토픽(Topic) : 프로듀서와 컨슈머들이 카프카로 보낸 자신들의 메시지를 구분하기 위한 네임으로 사용한다. 많은 수의 프로듀서, 컨슈머들이 동일한 카프카를 이용하게 된다면, 메시지들이 서로 뒤섞여 각자 원하는 메시지를 얻기가 어렵게 된다. 그래서 토픽이라는 이름으로 구분하여 사용하게 된다.
파티션(Partition) : 병렬처리가 가능하도록 토픽을 나눌 수 있고, 많은 양의 메시지 처리를 위해 파티션의 수를 늘려줄 수 있다.
프로듀서(Producer) : 메시지를 생산하여 브로커의 토픽 이름으로 보내는 서버 또는 애플리케이션 등을 말한다.
컨슈머(Consumer) : 브로커의 토픽 이름으로 저장된 메시지를 가져가는 서버 또는 애플리케이션 등을 말한다.
공부해야 할 용어 : 데이터 버스, 비동기 처리, 이벤트 소싱, 데이터 파이프라인, 프로듀서, 컨슈머, 데이터 웨어하우스, pub/sub모델
'DEV > MSA' 카테고리의 다른 글
| MSA 개발 가이드(3) - 마이크로 서비스 아키텍처 구현해보기 (0) | 2023.06.16 |
|---|---|
| MSA 개발 가이드(2) - Spring Cloud 기반 마이크로서비스(MSA) (0) | 2023.06.16 |
| MSA 개발 가이드(1) - MSA란 무엇인가 (0) | 2023.06.16 |
| API Gateway의 이해 (0) | 2023.06.13 |
| Kafka 용어 정리 (pub/sub, 토픽, 파티션, 브로커) (1) | 2023.05.12 |
아파치 카프카란?
Apache Kafka는 전통적인 메시지 시스템으로서 메시징 처리 뿐만 아니라, 사용자의 웹 사이트 활동 추적 파이프라인으로 활용하고 애플리케이션의 통계를 집계해 모니터링 데이터로 사용한다. 예전에는 데이터가 필요하면 데이터를 관장하는 조직(Mysql 등)에 요청하고 기다리는 작업을 수없이 반복함으로써 데이터 분석에 걸리는 시간이 늘고 효율도 떨어졌지만, 카프카를 사용함으로써 이벤트 소싱과 같이 시간순으로 발생하는(시계열 데이터) 이벤트를 카프카라는 데이터 버스에 저장해서, 필요한 조직이나 인력이 이 데이터를 필요한 때에 언제든 즉시 활용할 수 있도록 데이터 분석 환경이 빠르게 바뀌고 있다.
카프카는 이처럼 비동기 통신 방식을 매우 큰 규모로, 아주 빠르게 처리할 수 있게 개발된 애플리케이션이다.
2011년 초에 세상에 공개된 이후, 현재 Netflix, Uber, LinkedIn, AirBnB, Microsoft, Kakao, Line 과 같이 사용자의 데이터를 심층적으로 실시간 분석해서 사용해야 하는 수많은 기업에서 비동기 전용 프레임워크로 도입해 사용하고 있다.
카프카의 탄생 배경
Apache Kafka는 링크드인에서 최초로 도입했으며, 기존의 End-to-end 연결 방식의 아키텍처는 많은 문제점이 있었다.
첫 번째로 실시간 트랜잭션(OLTP) 처리와 비동기 처리가 동시에 이루어지지만 통합된 전송 영역이 없으니 복잡도가 증가할 수 밖에 없었다. 이 때문에 문제를 발견하고 조치를 취하려면 이와 관련된 여러 데이터 시스템을 확인해야 한다. 그리고 장애나 운영체제 업그레이드, 하드웨어 증설과 같은 작업을 위해서도 역시 아주 많은 준비 시간이 필요하다.
두 번째로 데이터 파이프라인 관리의 어려움이다. 실시간 트랜잭션 데이터베이스, 아파치 하둡, 모니터링 시스템, 키-값 저장소 등 많은 데이터 시스템들이 있는데, 이 시스템에 저장된 동일한 데이터를 개발자나 개발 부서는 각기 다른 방법으로 파이프라인을 만들고 유지하게 되었다. 처음에는 각자의 목적에 맞게 만들어서 간편했지만, 시간이 지나면서 이 데이터 파이프라인들은 통합 데이터 분석을 위해 서로 연결되어야 하는 일들이 필연적으로 발생한다. 하지만 각 파이프라인별로 데이터 포맷과 처리하는 방법들이 완전히 달라서 데이터 파이프라인은 확장하기 어려웠고, 이러한 데이터 파이프라인들을 조정하고 운영하는 것은 엄청난 노력이 필요했다. 게다가 복잡성으로 인해 두 시스템 간의 데이터가 서로 달라져 데이터의 신뢰도마저 낮아졌다.
이렇게 복잡도가 늘고 파이프라인이 파편화되면서 개발이 지연되고 데이터를 신뢰할 수 없는 상황에 이르자, 링크드인에서 개발팀을 이끌고 있던 카프카의 창시자 Jay Kreps는 Neha Narkhede, Jun Rao와 함께 새로운 팀을 구성해 모든 시스템으로 데이터를 전송할 수 있고, 실시간 처리도 가능하며, 급속도로 성장하는 서비스를 위해 확장이 용이한 시스템을 직접 만들기로 했다. 이 팀은 4개의 목표를 가지고 있었는데,
첫번째로는 프로듀서와 컨슈머의 분리
두번째로는 메시징 시스템과 같이 영구 메시지 데이터를 여러 컨슈머에게 허용
세번째로는 높은 처리량을 위한 메시지 최적화
네번째로는 데이터가 증가함에 따라 스케일아웃이 가능한 시스템이다.
이러한 모든 목표를 해결 가능한 애플리케이션을 만들게 된 것이다. 이것이 카프카의 탄생 배경이다.
카프카의 동작 방식과 원리
카프카는 기본적으로 메시징 서버로 동작한다. 따라서 카프카의 동작 방식을 설명하기에 앞서 먼저 메시징 시스템에 대해 살펴보면, 메시지라고 불리는 데이터 단위를 보내는 측(퍼블리셔 또는 프로듀서 라고 함) 에서 카프카에 토픽이라는 각각의 메시지 저장소에 데이터를 저장하면, 가져가는 측(서브스크라이버, 컨슈머 라고 함) 이 원하는 토픽에서 데이터를 가져가게 되어있다. 중앙에 메시징 시스템 서버를 두고 이렇게 메시지를 보내고(publish) 받는(subscribe) 형태의 통신을 pub/sub 모델이라고 한다.
pub/sub 은 비동기 메시징 전송 방식으로서, 발신자의 메시지에는 수신자가 정해져 있지 않은 상태로 발행(publish)한다. 구독(subscribe)을 신청한 수신자만이 정해진 메시지를 받을 수 있다. 또한 수신자는 발신자 정보가 없어도 원하는 메시지만을 수신할 수 있다. 이러한 구조 덕분에 다이나믹한 네트워크 토폴로지와 높은 확장성을 확보할 수 있다.
일반적인 통신 방식은 빠른 전송 속도와 전송 결과를 신속하게 알 수 있는 장점이 있는 반면에, 특정 개체에 장애가 발생한 경우 메시지를 보내는 쪽에서 대기 처리 등을 개별적으로 해주지 않으면 장애가 발생할 수 있다. 그리고 일반적 형태의 통신의 경우 통신에 참여하는 개체가 많아질 수록 서로 일일이 다 연결을 하고 데이터를 전송해야 하기 때문에 확장성이 좋지 않다.
이런 형태의 단점을 극복하고자 나온 통신 모델이 바로 pub/sub모델인데, 작동 방식은 프로듀서가 메시지를 컨슈머에게 직접 전달하는 것이 아니라 중간의 메시징 시스템에 전달한다. 이 때, 메시지 데이터와 수신처 ID를 포함시킨ㄴ다. 메시징 시스템의 교환기가 메시지의 수신처 ID값을 확인한 다음 컨슈머들의 큐에 전달한다. 컨슈머는 자신들의 큐를 모니터링하고 있다가, 큐에 메시지가 전달되면 이 값을 가져간다.
이렇게 구성할 경우 장점은 개체가 하나 빠지거나 수신 불능 상태가 되었을 때에도, 메시징 시스템만 살아 있으면 프로듀서에게 전달된 메시지가 유실되지 않는다. 이 메시지는 불능 상태의 개체가 다시 회복되면 언제든지 다시 가져갈 수 있고, 각각의 개체가 다대다 통신을 하는 것이 아니라 메시징 시스템을 중심으로 연결되기 때문에 확장성이 매우 용이하다. 그리고 사용자나 어드민이 연결을 직접 관장하는 것이 아니라, 교환기의 룰에 의해서 데이터가 수신처의 큐에 정확하게 전달되므로 메시지 데이터 유실의 염려가 없다. 다만 pub/sub의 단점은 직접 통신하지 않기 때문에 메시지가 정확하게 전달되었는지 확인하려면 코드가 좀 더 복잡해지고, 중간에 메시징 시스템이 있기 때문에 메시지 전달 속도가 빠르지 않다는 점이다.
그래서 카프카는 메시징 시스템이 지닌 성능의 단점을 극복하기 위해, 메시지 교환 전달의 신뢰성 관리를 프로듀서와 컨슈머 쪽으로 넘기고, 부하가 많이 걸리는 교환기 기능 역시 컨슈머가 만들 수 있게 함으로써 메시징 시스템 내에서의 작업량을 줄이고 이렇게 절약한 작업량을 메시징 전달 성능에 집중시켜서 고성능 메시징 시스템을 만들어 냈다.
카프카 역시 기존 메시징 시스템과 동일한 비동기 시스템이다. 프로듀서는 컨슈머와 관계없이 새로운 메시지를 카프카로 전송하고, 컨슈머 역시 프로듀서와 관계없이 카프카에서 새로운 메시지를 가져온다. 이렇게 프로듀서와 컨슈머는 각자의 역할이 정확하게 구분되어 있다. 카프카에도 수많은 메시지들이 저장되고, 그 메시지들은 토픽이라는 식별자를 이용해 토픽 단위로 저장되고 있다.
이처럼 비동기 기반으로 메시지를 전달하는 대표적인 솔루션이 메시지 큐 솔루션이다.
카프카의 특징
1. 프로듀서와 컨슈머의 분리
웹 서비스를 제공하는 회사에서는 안정적인 서비스를 위해 웹 서버에 모니터링을 적용한다. 웹 서버 뿐만 아니라 앱 서버, 데이터베이스 서버에도 모니터링을 적용한다. 이후에는 로그 분석 등이 필요하게 되어 각 애플리케이션들마다 로그 분석 시스템을 적용한다. 그 외에도 서버의 메트릭을 수집해 활용하기 위해 메트릭 수집 서버도 적용한다.
위처럼 구조를 단순히 할 수 있고, 각각의 서비스 서버(producer)들은 모니터링이나 분석 시스템의 상태 유무와 관계없이 카프카로 메시지를 보내는 역할만 하면 되고, 마찬가지로 모니터링이나 분석 시스템들도 서비스 서버들의 상태 유무와 관계없이 카프카에 저장되어 있는 메시지만 가져오면 된다. 이렇게 각자의 역할이 완벽하게 분리되면서, 어느 한 쪽 시스템에서 문제가 발생하더라도 연쇄작용이 발생할 확률은 매우 낮다. 또한 웹 서버가 추가되더라도(scale-up) 카프카로만 보내면 되기 때문에 서버 추가에 대한 부담도 줄일 수 있는 장점이 있다.
2. 멀티 프로듀서와 멀티 컨슈머
카프카는 하나의 토픽에 여러 프로듀서 또는 컨슈머들이 접근 가능한 구조로 되었다. 하나의 프로듀서가 하나의 토픽에만 메시지를 보내는 것이 아니라 하나 또는 하나 이상의 토픽으로 메시지를 보낼 수 있다. 컨슈머는 역시 하나의 토픽에서만 메시지를 가져오는 것이 아니라, 하나 또는 하나 이상의 토픽으로부터 메시지를 가져올 수 있다. 이러한 멀티 기능은 데이터 분석 및 처리 프로세스에서 하나의 데이터를 다양한 용도로 사용하는 요구가 많아지기 시작했고, 이러한 요구 사항들을 손쉽게 충족할 수 있다.
메시지를 전송하는 프로듀서 A는 토픽 A로 메시지1을 보내고 있다. 멀티 프로듀서가 가능하기 때문에 프로듀서B는 토픽 A와 토픽 B 두 개의 토픽으로 메시지2를 각각 보낼 수 있다. 컨슈머 부분을 보면, 컨슈머 A는 토픽 A에서 메시지1을 가져오고 있지만 토픽B에서도 메시지2를 가져오고 있다. 컨슈머B는 토픽B에서만 메시지2를 가져오고 있다. 이렇게 멀티 프로듀서와 컨슈머를 구성할 수 있기 때문에 카프카는 중앙 집중형 구조로 구성할 수 있게 된다.
3. 디스크에 메시지 저장
카프카가 기존의 메시징 시스템과 다른 특징 중 하나는 바로 디스크에 메시지를 저장하고 유지하는 것이다. 일반적인 메시징 시스템들은 컨슈머가 메시지를 읽어가면 큐에서 바로 메시지를 삭제한다. 하지만 카프카는 컨슈머가 메시지를 읽어가더라도 정해져 있는 보관 주기 동안 디스크에 메시지를 저장해둡니다. 트래픽이 일시적으로 폭주해 컨슈머의 처리가 늦어지더라도 카프카의 디스크에 안전하게 보관되어 있기 때문에 컨슈머는 메시지 손실 없이 메시지를 가져갈 수 있다. 그 밖에도 여러 가지 장점이 있다. 앞서 언급한 멀티 컨슈머에도 카프카에 메시지들이 디스크로 저장되어 있기 때문에 가능한 것이고, 컨슈머에 버그가 있어 오류를 발생했다면, 컨슈머를 잠시 중단하고 버그를 찾아 해결한 수 컨슈머를 다시 실행할 수 있다. 이러한 방법으로 작업하더라도 메시지가 디스크에 저장되어 있기 때문에 메시지 손실 없이 작업이 가능하다.
4. 확장성
카프카는 확장이 매우 용이하도록 설계되어 있다. 하나의 카프카 클러스터는 3대의 브로커로 시작해 수십 대의 브로커로 확장 가능하다. 또한 확장 작업은 카프카 서비스의 중단 없이 온라인 상태에서 작업이 가능하다. 최초 카프카 클러스터 구성 시 적은 수로 시작하더라도 이후 트래픽 및 사용량 증가로 클러스터를 확장하는 작업은 매우 간단할 뿐 아니라, 큰 부담 없이 할 수 있다.
5. 높은 성능
카프카는 매우 높은 성능을 목표로 탄생한 애플리케이션이다. 고성능을 유지하기 위해 카프카는 내부적으로 분산 처리, 배치 처리 등 다양한 기법을 사용하고 있다.
카프카 용어 정리
카프카(Kafka) : 아파치 프로젝트 애플리케이션 이름. 클러스터 구성이 가능하며, 카프카 클러스터라고 부른다.
브로커(Broker) : 카프카 애플리케이션이 설치되어 있는 서버 또는 노드를 말한다.
토픽(Topic) : 프로듀서와 컨슈머들이 카프카로 보낸 자신들의 메시지를 구분하기 위한 네임으로 사용한다. 많은 수의 프로듀서, 컨슈머들이 동일한 카프카를 이용하게 된다면, 메시지들이 서로 뒤섞여 각자 원하는 메시지를 얻기가 어렵게 된다. 그래서 토픽이라는 이름으로 구분하여 사용하게 된다.
파티션(Partition) : 병렬처리가 가능하도록 토픽을 나눌 수 있고, 많은 양의 메시지 처리를 위해 파티션의 수를 늘려줄 수 있다.
프로듀서(Producer) : 메시지를 생산하여 브로커의 토픽 이름으로 보내는 서버 또는 애플리케이션 등을 말한다.
컨슈머(Consumer) : 브로커의 토픽 이름으로 저장된 메시지를 가져가는 서버 또는 애플리케이션 등을 말한다.
공부해야 할 용어 : 데이터 버스, 비동기 처리, 이벤트 소싱, 데이터 파이프라인, 프로듀서, 컨슈머, 데이터 웨어하우스, pub/sub모델
'DEV > MSA' 카테고리의 다른 글
| MSA 개발 가이드(3) - 마이크로 서비스 아키텍처 구현해보기 (0) | 2023.06.16 |
|---|---|
| MSA 개발 가이드(2) - Spring Cloud 기반 마이크로서비스(MSA) (0) | 2023.06.16 |
| MSA 개발 가이드(1) - MSA란 무엇인가 (0) | 2023.06.16 |
| API Gateway의 이해 (0) | 2023.06.13 |
| Kafka 용어 정리 (pub/sub, 토픽, 파티션, 브로커) (1) | 2023.05.12 |
