Blog
스터디
CS Study with SON
21주차
아파치 카프카

출처 - https://github.com/jmxx219/CS-Study (opens in a new tab)

Apache Kafka


탄생 배경

카프카는 비즈니스 소셜 네트워크 서비스인 링크드인(linked-in)에서 처음 개발한 기술로, 링크드인 사이트가 급속도로 성장하면서 발생한 내부 여러 이슈들을 해결하기 위해 탄생하였음


카프카 개발 전, 과거 링크드인의 기존 데이터 처리 시스템



각 애플리케이션과 DB가 end-to-end로 연결되어 있고, 요구사항이 늘어남에 따라 데이터 시스템 복잡도가 높아지면서 여러 문제가 발생하게 됨

기존 데이터 시스템의 문제점

  1. 시스템 복잡도 증가
  • 실시간 트랜잭션 처리와 비동기 처리가 동시에 이뤄지지만, 통합된 전송 영역이 없으니 데이터 흐름을 파악하기 어렵고 시스템 관리가 어려움
  • 특정 부분에서 장애 발생 시, 조치를 취하려면 연결되어 있는 애플리케이션을 모두 확인하며 이 때문에 조치를 취하기까지 시간이 걸림
  1. 데이터 파이프라인 관리의 어려움
  • 각 애플리케이션과 데이터 시스템 간의 별도의 파이프라인이 존재하고, 파이프라인마다 데이터 포맷과 처리 방식이 다름
  • 새로운 파이프라인 확장이 어려워져 확장성과 유연성이 떨어짐
  • 시스템 간 데이터 불일치 가능성으로 신뢰도가 낮아짐

카프카를 이용한 링크드인의 데이터 처리 시스템



링크드인 개발자들이 4가지의 목표를 가지고 새로운 시스템(카프카)을 개발함

  • 프로듀서와 컨슈머의 분리(송신자와 수신자의 분리)
  • 메시징 시스템과 같이 영구 메시지 데이터를 여러 컨슈머에게 허용
  • 높은 처리량을 위한 메시지 최적화
  • 데이터가 증가함에 따라 스케일 아웃이 가능한 시스템

카프카로 인해 얻은 결과

  • 모든 이벤트/데이터 흐름을 중앙에서 관리
  • 새로운 서비스 추가 시 표준 포맷으로 연결 가능하여 확장성과 신뢰성 증가
  • 개발자는 카프카에 데이터만 전달하면 되어 각 서비스 간 연결이 아닌 비즈니스 로직에 집중 가능

카프카란?

메시지 브로커 참고 (opens in a new tab)

  • 오픈 소스 분산 이벤트 스트리밍 플랫폼 으로써 데이터를 생성하는 애플리케이션과 데이터를 소비하는 애플리케이션 간의 중재자 역할을 함으로써 데이터의 전송 제어 및 처리와 관리 역할을 함
  • 여러 노드와 함께 구성될 수 있어 카프카 클러스터라고도 함
  • 서버 간의 비동기 데이터 교환을 용이하게 하고, 하루에 많은 양의 이벤트 처리가 가능하도록 함

이벤트 스트리밍 플랫폼 (opens in a new tab)

  • 이벤트 스트리밍
    • 데이터베이스, 센서, 모바일 장치, 클라우드 서비스, 소프트웨어 어플리케이션과 같은 이벤트 소스에서 실시간 데이터를 이벤트 스트림의 형태로 처리하거나 분석하는 것
    • 이벤트 스트림: 시간별로 정렬된 일련의 비즈니스 이벤트(연속적인 많은 이벤트들의 흐름)
  • 카프카는 이벤트 스트리밍으로써 중요한 세 가지 기능을 가지고 있음
    • 이벤트 스트리밍을 지속적으로 발행(publish-write)하고 구독(subscribe-read) 함
    • 이벤트 스트리밍을 원하는 만큼 내구성 있고 안정적으로 저장(store)함 ➜ KafkaCluster(broker)
    • 이벤트 스트림이 발생하거나 소급되었을 때 지속적으로 처리(process)함

메시지 큐(Message Queue, MQ)


카프카의 기본 구성요소



  • Kafka Cluster : 카프카의 브로커들의 모임으로, 카프카는 확정성과 고가용성을 위하여 브로커들이 클러스터로 구성됨
    • Cluster: 여러 대의 컴퓨터들이 연결되어 하나의 시스템처럼 동작하는 컴퓨터들의 집합
  • Zookeeper: 분산 애플리케이션 관리를 위한 코디네이션 시스템
    • 분산 메시지 큐의 정보를 중앙에서 관리해주는 역할
  • Producer: 데이터를 생성하고 Kafka Cluster로 전달하는 주체
    • 데이터를 Topic에 발행하여 Broker에 전송함
  • Consumer: Kafka Cluster에서 데이터를 소비하는 주체
    • Producer에서 전달한 데이터를 Broker에 요청하여 메시지(데이터)를 소비하는 역할
    • Consumer Group: 목적에 따라 모인 다수의 Consumer들의 그룹
  • Broker: 카프카 클러스터를 구성하는 서버 노드(카프카 서버)
    • 데이터를 Producer로 부터 받아 Topic에 저장하고, Consumer에게 필요한 데이터를 전달하는 중재자(Broker) 역할
  • Topic: 보내는 메시지를 구분하기 위해 카테고리화된 주제
    • Producer가 메시지를 발행하는 곳이며, Consumer는 특정 Topic에서 메시지를 소비함
    • Topic은 1개 이상의 Partition으로 분할됨
  • Partition: 병렬 처리 및 고성능을 위해 Topic을 Storage에 물리적으로 나누어 데이터를 저장하는 단위
    • 특정 Topic의 데이터를 여러 Partition에 분산해서 저장하여 Scale-out이 가능함
    • 각 Partition은 별도의 브로커에 저장될 수 있음
    • 데이터를 효율적으로 분산하고 병렬 처리할 수 있도록 함

카프카 특징(장점)

카프카는 이벤트 스트리밍 플랫폼으로서 여러가지 역할을 할 수 있고, MQ처럼 메시지 브로커 역할을 할 수 있음

  • Event-Oriented
    • 이벤트 중심의 시스템 구성
  • 고성능
    • 대용량 실시간 로그 처리에 특화됨
  • 고가용성
    • 다수의 브로커로 구성되어 장애 발생 시에도 시스템을 유지할 수 있음
  • 확장성(Scale-out)
    • 카프카 클러스터는 여러 대의 서버로 확장 가능하며, 수천 대의 브로커와 수십만개의 Partition으로 이루어진 대규모 클러스터를 구성할 수 있음
  • 분산 아키텍처
    • 컨슈머가 토픽을 구독하여 메시지를 읽는 구조
  • Publish-Subscribe 모델
    • 메시지를 받기 원하는 컨슈머가 해당 토픽(topic)을 구독함으로써 메시지를 읽어 오는 구조
    • 기존 메시징 시스템은 브로커가 컨슈머에게 메시지를 push 해주는 방식인데, 카프카는 컨슈머가 브로커로부터 메시지를 직접 가져가는 pull 방식으로 동작함
      • 컨슈머 중심으로, 컨슈머가 자신의 처리 능력만큼의 메시지만 가져와서 최적의 성능을 낼 수 있음
      • 브로커 중심적인 브로커 메시지와 달리 브로커의 역할이 비교적 단순해짐
  • 메시지를 파일 시스템에 저장하여 데이터 유실을 방지
    • 메시지를 메모리에 저장하는 기존 시스템과 달리 파일에 저장함
    • 장애 시, 데이터 유실 복구가 가능함
    • 메시지가 많이 쌓여도 성능이 크게 저하되지 않음
    • 대규모 처리를 위한 batch 작업에 용이함

카프카의 단점

  • 구성 복잡도
    • 초기 구성이 복잡하고 기술적 이해가 필요
  • 설정 오류의 위험성
    • 다양한 설정 옵션으로 인해 잘못된 설정 시 오류가 발생할 수 있음
  • 아파치 카프카는 서버의 수와 스토리지의 용량에 따라 비용이 증가할 수 있음
    • 기본 브로커가 3개 이상 필요하기 때문에 서버 비용이 듦


XSS와 CSRFJDBC