1.1 카프카 탄생
링크드인에서 서비스의 성장과 더불어서 내부의 아키텍처가 거대해지고 운영 애플리케이션의 수가 증가하면서 소스 애플리케이션과 타깃 애플리케이션의 개수가 많아지기 시작하였고 데이터를 전송하는 라인이 기하급수적으로 복잡해지기 시작했다. 또한 소스코드 및 버전 관리에서 이슈가 발생하고 타깃 애플리케이션에 장애가 발생하면 소스 애플리케이션으로 장애가 전파되는 문제가 발생하였다.
이러한 문제점을 해결하기 위해서 등장한 것이 kafka
이다.
카프카를 데이터 전송 파이프라인으로 도입하게 되어 복잡한 데이터 의존성 관계를 카프카와 애플리케이션들과의 관계를 단순화되었고 애플리케이션 입장에서 데이터 전송의 타켓이 카프카로 통일되었기 때문에 데이터 전송과 관련된 의존성 설정 문제에서 자유로워질 수 있었다. 아키텍처 역시 단순화된 데이터 전송 라인으로 명확해졌다.
1.2 카프카의 특징
높은 처리량
많은 양의 데이터를 묶음단위
로 처리함으로써 데이터 전송에 필요한 리소스를 줄여 높은 처리량을 가지도록 동작한다.
확장성
처리되는 데이터의 양에 따라 브로커의 개수를 Scale-in/out
함으로써 유동적인 데이터 처리가 가능하다.
영속성
메모리 영역에 데이터를 저장하는 것이 아니라 디스크
영역에 데이터를 저장/전송함으로써 데이터 유실을 방지할 수 있다.
디스크 영역의 데이터 저장시 성능 저하는 운영체제 레벨의 파일 시스템(페이지 캐시 메모리 영역)을 최대한 황용하여 보안하였다.
고가용성
3대 이상의 서버들로 운영되는 카프카 클러스터
를 사용하여 데이터 복제
를 통해서 고가용성을 제공한다.
카프카 클러스터를 2대 이상이 아닌 3대 이상을 운영하는 이유?
2대의 클러스터로 운영시 브로커 간에 데이터가 복제되는 시간 차이로 인해 일부 데이터가 유실될 가능성이 있다.
유실을 막기 위해서 min.insync.replicas 옵션을 2대 이상으로 설정하며 완전한 복제를 보장한다.
하지만 2대 운영시 1대가 장애가 발생한다면 2대 이상의 복제가 없기 때문에 데이터 처리가 불가능하다.
따라서 3대가 운영되어야 1대가 장애가 발생하여도 안정적인 운영이 가능하기 때문에 3대를 권하는 것이다.
REFERENCE
아파치 카프카 애플리케이션 프로그래밍 with 자바
'devops > kafka' 카테고리의 다른 글
3장 카프카 스트림즈 (0) | 2023.10.23 |
---|---|
3장 카프카 컨슈머 (0) | 2023.10.21 |
3장 카프카 기본 개념 설명 - 브로커, 프로듀서 (1) | 2023.10.17 |
2장 카프카 빠르게 시작해보기 (카프카 커맨드 라인 ) (0) | 2023.10.16 |
2장 카프카 빠르게 시작해보기 (실습용 카프카 브로커 설치) (0) | 2023.10.15 |