윤자이 기술블로그

Stream Processing 스트림 프로세싱이란 데이터들이 지속적으로 유입되고 나가는 과정에서 이 데이터에 대한 분석이나 질의를 수행하는 것을 의미합니다. 즉 스트림 프로세싱은 데이터가 이동 중이거나, 생성되어 수신되는 즉시 처리하기 때문에 실시간 분석이라고 불리기도 합니다. 아래의 이미지와 같이 스트링 프로세싱을 사용하기 전에는 주로 데이터를 Database나 File System과 같은 대용량 저장소에 저장한 후, 필요에 따라 애플리케이션이 쿼리를 수행하거나 분석을 하는 등 배치 처리 형태를 띄고 있었습니다. 하지만 빅데이터 붐이 일어나고 스트림 프로세싱이 등장하고부터 이러한 데이터 처리 패러다임이 많이 바뀌었는데, 기존의 배치 형태를 띠고 있던 데이터 처리 파이프라인이 실시간 적이고 지속적으로 ..

이번 포스팅에서는 kafka consumer(소비)에 대해서 알아보겠습니다. kafka producer가 메시지를 생산하고 토픽으로 전송하는 역할을 한다면 consumer는 메시지를 가져와서 소비하는 역할을 하는 애플리케이션 또는 서버를 지칭합니다. 컨슈머의 주요 기능은 특정 파티션을 관리하고 있는 파티션 리더에게 메시지를 가져오기 요청을 하는 것입니다. 각 요청은 로그의 오프셋을 명시하고 그 위치로부터 로그 메시지를 수신합니다. 때문에 컨슈머는 가져올 메시지의 위치를 조정할 수 있고, 또 이미 가져왔던 메시지를 다시 가져오는 것 역시 가능합니다. Consumer option 카프카 컨슈머에는 Old Consumer와 New Consumer 두 가지가 있습니다. 두 컨슈머의 가장 큰 차이는 주키퍼의 사용..

Producer 카프카에서 메시지를 생산해서 카프카 토픽으로 보내는 역할을 하는 애플리케이션, 서버 등을 모두 Producer라고 부릅니다. 프로듀서의 주요 기능은 각각의 메시지를 토픽 파티션에 매핑하고 파티션의 리더에 요청을 보내는 것입니다. 만약 전송하는 메시지에 키 값을 지정하게 된다면 원하는 파티션으로 전송되게 됩니다. 하지만 키 값을 지정하지 않는다면, 파티션은 Round-Robin 방식으로 각 파티션에 메시지를 균등하게 분배합니다. Kafka / Zookeeper Install 이번 포스팅에서는 특별히 docker-compose를 이용해 간단하게 카프카 브로커를 띄운 다음 프로듀서에서 브로커로 메시지를 전송해보도록 하겠습니다. 꼭 docker를 이용해서 kafka와 zookeeper를 설치할 ..

토픽, 파티션 카프카가 고성능, 고가용성 메시징 애플리케이션으로 발전하는 데에는 토픽과 파티션이라 불리는 카프카 데이터 모델의 역할이 컸습니다. 토픽은 메시지를 받을 수 있는 논리적인 모델로 데이터를 구분하기 위한 단위입니다. 예를 들어 A라는 사람에게서 받은 메일과 B라는 사람에게서 받은 메일을 구분하기 위해서 이메일 주소를 사용하는 것과 비슷한 논리입니다. 파티션은 토픽을 구성하는 데이터 저장소로서 수평 확장이 가능한 단위입니다. 즉 토픽을 분할해서 파티셔닝 한 형태입니다. 이와 같이 토픽을 파티셔닝 하는 이유는 프로듀서로부터 도착한 메시지의 순서가 보장되어야 하면서 동시에 성능을 향상하기 위해서입니다. 예를 들어 4개의 프로듀서에서 전송되는데 1초가 걸리는 메시지를 하나의 파티션에 전송했다고 가정해..

카프카는 중앙 집중형 빅데이터 스트리밍 플랫폼으로 고성능으로 디자인된 플랫폼입니다. 이와 같이 고성능으로 실시간 메시지를 처리하기 위해 카프카는 내부적으로 몇 가지 특징을 가지고 있습니다. 분산 시스템 그 첫번째로 카프카는 분산 시스템을 기반으로 디자인되었습니다. 분산 시스템이란 네트워크로 이루어진 컴퓨터들의 그룹으로서 시스템 전체가 공통의 역할을 하는 서버 컴퓨터의 집합입니다. 분산 시스템의 경우 단일 시스템보다 더 높은 성능으로 작동할 수 있고, 분산 시스템의 일부 노드가 장애가 발생하더라도 다른 노드가 이를 대신하여 처리할 수 있으므로 장애에 대한 내성을 가지고 있습니다. 또한 추가적으로 서버를 추가하는 것과 같이 시스템 확장에 용이합니다. 예를 들어 초당 1000개의 메시지를 처리하게 되면 CPU..

앞선 포스팅에서 살펴봤듯이 카프카는 크게 메시지를 카프카로 전송하는 프로듀서, 메시지를 저장하고 있는 카프카(브로커), 메시지를 가져가는 컨슈머가 있다고 했습니다. 그리고 마지막으로 카프카와 떨어질 수 없는 코디네이션 애플리케이션인 주키퍼zookeeper가 있습니다. 주키퍼는 중앙에서 분산 application을 관리하는 코디네이션 애플리케이션으로 카프카의 상태 관리는 목적으로 합니다. 카프카는 주키퍼와 긴밀하게 통신을 하기 때문에 카프카를 사용하기 위해서는 주키퍼의 사용이 필수적입니다. 원래 주키퍼는 하둡Hadoop의 서브 프로젝트 중 하나였습니다. 대용량 분산 처리 애플리케이션인 하둡에서는 중앙에서 분산 애플리케이션을 관리하는 코디네이션 애플리케이션이 필요하기 시작했고, 서브 프로젝트로 주키퍼 개발을..

Micro Service Architecture로 아키텍처 패턴이 만들어 짐에 따라서, 각각의 서비스들이 통신하게 되는 구조가 이전보다 복잡해지게 되었습니다. 이와 같이 복잡해진 데이터 전송 구조는 베포와 장애의 어려움을 만들어내게 됩니다. 또한 데이터를 전송할 때 프로토콜의 파편화가 심각해지게 되는 문제가 발생하게 됩니다. Apache Kafka는 이러한 문제를 해결하기 위해 Linked In에서 개발한 오픈소스로 Source Application과 Target Application의 커플링을 약하기 위해 개발 된 것으로 애플리케이션들의 중추 신경과 같은 역할을 하게 됩니다. 아래의 이미지는 카프카가 개발되기 전 링크드인의 데이터 처리 시스템을 나타낸 것입니다. 한눈에 보기에도 복장한 아키텍처 흐름도를..