아파치 카프카(Apache Kafka) 는 왜 필요할까?

과거 대규모의 데이터가 아닌 적은양의 정형화된 데이터가 주를 이루던 시절

단일 서버로 서비스가 돌아가던 시절에는 end - to - end 방식으로 해도 문제가 없었습니다

서비스의 규모가 크지않다면 각 서버를 직접 연결하여 통신하게 되면, 전송속도도 빠를분더러

수신된 데이터의 결과도 빠르게 파악할수있는 일반적인 메시지 통신 방법을 사용했습니다

좀더 시간이 흘러 고객들은 더많은 서비스를 원하고 기업도 해당 서비스를 제공하려고 합니다

하지만 서버가 한두개 늘어갈수록 여러 문제점과 직면하게 됩니다

첫번째로 서버가 하나씩 늘수록 기존에 사용하던 플랫폼과 연결하는데 많은 시간이 걸린다는것

서버 하나가 증가함에 따라 데이터를 전송하는 라인이 기하급수적으로 복잡해지게 됩니다 (n^2)

또한 각기 다른 연결 파이프라인을 가지고있어 장애발생 가능성이 늘었다는 것입니다

또한 데이터를 수신받는 서버에서 장애발생시 전달하는 서버에도 장애가 전파되어 사이드이펙트가 자주 발생했습니다

여러기업들은 해당문제들을 해결하기위해 자체적인 EventBus를 만들거나 다른 라이브러리들을 사용하였습니다

2011년, 유명 사이트인 링크드인(LinkedIn)에서는 늘어가는 서비스에 따라서 데이터 송수신 및 아키텍처를 운영하는데

위와같은 이유로인해 골머리를 앓고있었습니다

서비스를 확장하고 운영하는데 해당문제는 꼭 해결해야할 문제였으며 그 결과 아파치 카프카(Apache Kafka)가 탄생하게 됩니다

end - to - end로 앱끼리 연결해서 데이터를 처리하는것이 아니라 한곳에 모아 처리할수있도록 프로세스를 만들고

대용량 데이터를 수집하고 처리하기위해 데이터 스트림을한곳에 모아 소비할수있게 만들었습니다

그 결과 서버가 서버끼리 통신하는게 아닌 중간에 카프카를 배치함에 따라 의존도를 최소화 하였습니다

데이터가 생성되어도 어디로 전송할지는 카프카가 해주었기때문에 어디로 보낼것인지 고민하지 않아도 됬습니다

카프카는 프로듀서(Producer)가 큐에 데이터를 보내고 카프카 내부에서는 큐와같은 자료구조처럼 동작하게됩니다

Topic을 하나의 큐로 생각하고 해당 큐에 실시간으로 들어온 데이터가 적재되게 됩니다

여기서 적재된 데이터는 여러개의 파티션(Partition)으로 나뉘어 병렬처리를 수행하게 됩니다

그리고 컨슈머(Consumer)는 카프카를 바라보고있다가 Topic에 데이터가 쌓이게되면 데이터를 가져가 처리하게됩니다

위와같은 구조로인해 높은 처리량을 기대할수 있었는데, 이유는 아래와 같습니다

카프카 높은 처리량 뿐만아니라 안정적으로 화장가능 하도록 설계되었는데

만약 예기치 못한 오류로인해 서버와 연결이 끊어져도 데이터는 사라지지않는 영속성을 가지고있다

또한 하나의 브로커에 장애가 발생해도 다른 브로커에도 복제된 데이터가 있기떄문에 지속적으로 처리가능

만약 사용자에게 서비스를 제공할때 아래와같은 문제가 있다면 카프카를 도입함에 따라 아래와같은 문제를 해소할수 있을것입니다

현재 많은 기업들이 카프카를 도입하여 활용중이며, 데이터 처리 프로세싱에 대부분 쓰인다고 보면 될것같습니다

OpenTelemetry(Otel)을 이용한 로그 수집 Feat. docs (0)	2025.01.18
아파치 카프카(Apache Kafka) 사용하기 (4)	2024.10.31

큐습장