K로 시작한다는 점 외에는 공통점이 없는 세 기술.
- Kafka
- Kubernetes
- Kinesis
직접 사용해본 적이 없고, K로 시작하는 이름때문에 자꾸 헷갈려서
각 기술들의 정의, 운영 주체, 등장 배경, 역할, 사용 사례, 유사 경쟁 기술을 정리해보려고 한다.
Apache Kafka
정의
Kafka는 분산 이벤트 스트리밍 플랫폼이다.
대량의 이벤트를 순서대로, 오래, 안전하게 저장하고 전달하는 로그 시스템이다.
Kafka의 핵심 아이디어는 "시스템에서 일어난 모든 일을 로그로 남기자."
이 로그를 여러 소비자가 각자 필요에 맞게 읽는다.
운영 주체
오픈 소스 프로젝트로, Apache Software Foundation이 관리한다.
Confluent 등 다수의 기업이 상용 배포와 운영 지원을 하고 있다.
등장 배경
Kafka는 LinkedIn 내부 문제에서 출발했다.
2010년대 초반, Linked In은 아래와 같은 문제에 직면했다.
- 서비스 곳곳에서 이벤트 로그가 폭발적으로 발생
- 각 팀이 각자 로그 파이프라인을 만들어 관리
- 데이터 유실, 순서 꼬임, 재처리 불가능 문제 반복
이로 인해 모든 "이벤트를 하나의 신뢰 가능한 로그로 모으자"는 니즈가 발생했다.
이에 따라 Kafka는 처음부터
메시지 큐가 아니라, 분산 커밋 로그(distributed commit log)로 설계되었다.
이게 지금 kafka가 "재처리 기능", "순서 보장"에 집착하는 이유다.
역할
Kafka의 역할은
- 이벤트를 append-only 로그로 저장
- 이벤트 순서 보장
- 여러 consumer가 독립적으로 읽을 수 있게 제공
- 장애 발생 시 데이터 유실 없이 복구 가능
Kafka는 처리를 하는 것이 아니라, 기록하고 전달하는 역할이다.
사용 사례
Kafka는 백엔드와 데이터팀의 경계면에 자주 위치된다.
- 클릭, 노출, 결제 포인트 적립 등의 이벤트 로그 수집
- 하나의 이벤트를 아래 서비스들이 각각 다르게 소비해야 할 때
- 정산 시스템
- 어뷰징 방지
- 통계 집계
- 실시간 알림
- 재처리(replay)가 필요한 데이터 파이프라인
유사 경쟁 기술
RabbitMQ
전통적인 메시지 브로커로 작업 큐에 강점이 있다.
Apache Pulsar
Kafka 대체를 목표로 하는 스트리밍 플랫폼이다.
Amazon MSK
Kafka를 AWS가 관리해주는 형태다.
Kafka는 지금도 가장 널리 쓰이는 이벤트 로그 표준에 가깝다.
Kubernetes
정의
kubernetes는 컨테이너 기반 애플리케이션 오케스트레이션 시스템이다.
컨테이너를 대규모로 안정적으로 운영하기 위한 플랫폼이다.
Kubernetes로 관리할 수 있는 것은 "이 애플리케이션을 언제, 어디서, 몇 개로, 어떻게 살려둘 것인가" 이다.
운영 주체
오픈 소스 프로젝트로 처음 만든 회사는 Google이지만, 현재는 CNCF(Cloud Native Computing Foundation)가 공식 관리 주체이다.
CNCF는 리눅스 재단 산하의 중립적인 오픈소스 재단으로, 특정 기업이 마음대로 끌고 갈 수 없게 하는 장치다.
등장 배경
Google 내부에서 10년 이상 검증된 운영 철학의 공개판이라고 할 수 있다.
Google은 오래전부터 Borg, Omega 라는 내부 컨테이너 관리 시스템을 운영하고 있었다.
이 시스템들이 해결한 문제는 수십만 개의 프로세스를 사람이 관리할 수 없다는 것이었다.
Kubernetes는 Borg의 개념을 정리해
- 컨테이너
- 선언형 상태 관리
- 자동 복구
라는 형태로 외부에 공개한 결과물이다.
즉, Kubernetes는 처음부터 개발 도구가 아니라 운영 도구였다.
역할
Kubernetes의 관심사는 운영이다.
- 컨테이너 실행 및 종료
- 장애 발생 시 자동 재기동
- 트래픽 분산
- 오토스케일링
- 무중단 배포
Kubernetes는 애플리케이션 내부 로직을 전혀 모른다.
HTTP 서버든, 배치 작업이든, Kafka Consumer든 그냥 컨테이너로 취급한다.
사용 사례
Kubernetes가 필수인 팀은 아래와 같다.
- 마이크로서비스 구조
- 트래픽 변동이 큰 서비스
- 수십~수백 개의 서버를 사람 손으로 관리하기 어려운 환경
- 배포 안정성이 중요한 서비스
Kubernetes는 개발 속도보다 운영 안정성을 극적으로 높이는 도구다.
유사 경쟁 기술
Docker Swarm
Docker 자체 오케스트레이션이다.
Apache Mesos
범용 클러스터 리소스 관리자다.
Nomad(HashiCorp)
단순한 워크로드 오케스트레이터다.
현재는 사실상 Kubernetes가 표준이 되었다.
Amazon Kinesis
정의
Kinesis는 AWS에서 제공하는 완전관리형 실시간 데이터 스트리밍 서비스다.
Kafka와 같은 문제를 풀지만, 운영을 AWS가 대신한다는 점이 핵심이다.
서버를 띄우지 않고,
클러스터를 관리하지 않아도,
바로 스트림을 쓸 수 있다.
운영 주체
Amazon Web Services에서 운영하는 완전 관리형 서비스(Closed source)다.
등장 배경
AWS의 문제 의식은
- 고객들이 로그를 실시간으로 모으고 싶어한다.
- Kafka의 운영 난이도가 높다.
- AWS 서비스와 자연스럽게 연결되어야 한다.
그래서 아래와 같이 설계되었다.
- 서버 관리 없음
- AWS IAM, S3, Redshift와 즉시 연동
- 운영 세부 사항은 사용자에게 숨김
즉, Kinesis는 스트리밍을 쓰고 싶지만 스트리밍 시스템을 운영하고 싶진 않은 사용자를 위해 탄생했다.
역할
- 대량 이벤트 스트림 수집
- 실시간 처리 또는 저장소로 전달
- AWS 서비스와 즉시 연동
Kinesis는 내부적으로 여러 컴포넌트로 나뉜다.
- Data Streams: 실시간 스트림 처리
- Firehose: S3, Redshift 등으로 자동 적재
사용 사례
- 인프라가 100% AWS인 경우
- 운영 인력이 제한적
- 로그를 바로 S3 혹은 Redshift로 쌓고 싶은 경우
- 빠른 구축이 중요한 프로젝트
Kinesis는 유연성보다 관리 편의성에 최적화된 선택이다.
유사 경쟁 기술
Google Pub/Sub
GCP의 완전관리형 메시징/스트리밍 서비스다.
Azure Event Hubs
Azure의 스트리밍 플랫폼이다.
Apache Kafka
자유도가 높고 책임도 크다.
Kinesis는 AWS 생태계 최적화형 선택지다.