맨위로가기 타임라인 바로가기

아파치 카프카

"오늘의AI위키"는 AI 기술로 일관성 있고 체계적인 최신 지식을 제공하는 혁신 플랫폼입니다.
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.
타임라인 바로가기
목차

1. 개요

아파치 카프카는 2011년 링크드인에서 오픈 소스로 개발된 분산 스트리밍 플랫폼이다. 제이 크렙스, 네하 나르케데, 준 라오가 공동 개발했으며, 작가 프란츠 카프카의 이름을 따서 명명되었다. 카프카는 프로듀서가 생성한 키-값 메시지를 토픽 내 파티션에 저장하고, 컨슈머가 이를 읽어 처리하는 구조를 갖는다. 분산 아키텍처, 고성능, 확장성, 내결함성을 특징으로 하며, Streams API, Connect API, Admin API 등 다양한 API를 제공한다. 애플, 넷플릭스, 우버 등 다양한 기업에서 활용되며, 커밋 로그를 기반으로 실시간 데이터 처리에 사용된다.

더 읽어볼만한 페이지

  • 스칼라로 작성된 자유 소프트웨어 - 스칼라 (프로그래밍 언어)
    스칼라는 마틴 오더스키가 설계한 객체 지향 및 함수형 프로그래밍 언어이며, 자바 플랫폼에서 실행되고 자바 코드와 상호 운용이 가능하며, 아파치 스파크 등 다양한 곳에서 활용된다.
  • 스칼라로 작성된 자유 소프트웨어 - 아파치 스파크
    아파치 스파크는 대규모 데이터 처리를 위한 오픈 소스 분산 처리 시스템으로, 빠른 속도와 다양한 API 지원을 통해 빅데이터 분석, 머신 러닝, 스트리밍 처리 등 여러 분야에서 활용되며 아파치 소프트웨어 재단의 핵심 프로젝트 중 하나이다.
  • 메시지 지향 미들웨어 - 마이크로소프트 비즈토크 서버
    마이크로소프트 비즈토크 서버는 다양한 시스템 통합 및 비즈니스 프로세스 자동화를 지원하는 서버 소프트웨어로, 여러 버전이 출시되었으며 어댑터, 가속기 등의 기능을 제공하고 대한민국 여러 산업 분야에서 활용되었으나 클라우드 기반 솔루션의 등장으로 입지가 변화하고 있다.
  • 메시지 지향 미들웨어 - ZeroMQ
    ZeroMQ는 다양한 메시징 패턴을 지원하고 높은 성능을 제공하는 메시지 라이브러리이다.
  • 2011년 소프트웨어 - 아이클라우드
    아이클라우드는 애플의 클라우드 컴퓨팅 서비스로, 다양한 데이터를 저장 및 동기화하며 여러 기기에서 접근 가능하고, 추가 기능과 저장 공간 확장을 제공하지만 보안 및 개인 정보 보호에 대한 논란도 있다.
  • 2011년 소프트웨어 - HHVM
    HHVM은 페이스북에서 개발한 PHP 및 Hack 언어 실행 엔진으로, JIT 컴파일을 통해 높은 성능을 제공하며 웹 개발 분야에 새로운 가능성을 제시했다.
아파치 카프카 - [IT 관련 정보]에 관한 문서
기본 정보
이름아파치 카프카
로고
개발자LinkedIn
개발자아파치 소프트웨어 재단
최초 공개2011년 1월
프로그래밍 언어스칼라
Java
운영체제크로스 플랫폼
장르스트림 프로세싱
메시지 브로커
라이선스아파치 라이선스 2.0
웹사이트아파치 카프카 공식 웹사이트

2. 역사

아파치 카프카는 링크드인에서 개발되어 2011년에 오픈 소스화되었다. 2012년 10월 23일 아파치 인큐베이터를 졸업하였고,[5][17] 2014년 11월에는 링크드인에서 카프카 개발에 참여했던 일부 엔지니어들이 Confluent라는 회사를 설립하였다.[27]

2. 1. 개발 배경

아파치 카프카는 원래 링크드인에서 개발되었으며, 2011년 초에 오픈 소스로 공개되었다.[4][16] 제이 크렙스, 네하 나르케데, 준 라오가 공동으로 개발하였다.[4] 2012년 10월 23일 아파치 인큐베이터를 졸업했다.[5][17] 2014년 11월 링크드인에서 카프카를 만들던 일부 엔지니어들이 카프카에 집중하기 위해 Confluent라는 새로운 회사를 창립하였다.[27] 제이 크렙스는 프란츠 카프카의 작품을 좋아했기 때문에 그의 이름을 따서 "글쓰기에 최적화된 시스템"인 카프카라고 명명했다.[6][18]

2. 2. 오픈 소스화 및 발전

아파치 카프카는 원래 링크드인에서 개발되었으며, 2011년 초에 오픈 소스로 공개되었다. 제이 크렙스, 네하 나르케데|Neha Narkhede영어, 준 라오가 공동으로 개발했다.[4] 2012년 10월 23일 아파치 인큐베이터를 졸업했다.[5][17] 제이 크렙스는 프란츠 카프카의 작품을 좋아했기 때문에 이 소프트웨어의 이름을 작가 프란츠 카프카의 이름을 따서 지었는데, 그 이유는 "글쓰기에 최적화된 시스템"이기 때문이다.[6] 2014년 11월 링크드인에서 카프카를 만들던 일부 엔지니어들이 카프카에 집중하기 위해 Confluent라는 새로운 회사를 창립하였다.[27]

2. 3. 명칭의 유래

카프카는 원래 링크드인(LinkedIn)에서 개발되었으며, 2011년 초에 오픈 소스로 공개되었다. 제이 크렙스(Jay Kreps), 네하 나르케데(Neha Narkhede), 준 라오(Jun Rao)가 공동으로 개발하였다.[4] 제이 크렙스는 프란츠 카프카의 작품을 좋아했으며, 카프카가 "글쓰기에 최적화된 시스템"이라는 이유로 이 소프트웨어의 이름을 프란츠 카프카의 이름을 따서 지었다.[6]

3. 특징

아파치 카프카는 커밋 로그를 기반으로 하며, 사용자는 이를 통해 다양한 시스템이나 실시간 애플리케이션에 데이터를 게시할 수 있다. 예를 들어 우버는 승객과 운전자를 매칭하고, 브리티시 가스는 스마트 홈에 대한 실시간 분석 및 예측 유지 보수를 제공하며, 링크드인은 수많은 실시간 서비스를 수행하는 데 카프카를 활용한다.[7]

3. 1. 분산 아키텍처

카프카는 프로듀서라고 불리는 임의의 수많은 프로세스에서 오는 키-값 메시지를 저장한다. 데이터는 서로 다른 "토픽" 내에서 서로 다른 "파티션"으로 분할될 수 있다. 파티션 내에서 메시지는 오프셋(파티션 내 메시지의 위치)에 따라 엄격하게 정렬되며, 타임스탬프와 함께 인덱싱되어 저장된다. 컨슈머라고 불리는 다른 프로세스는 파티션에서 메시지를 읽을 수 있다. 스트림 처리를 위해 카프카는 카프카에서 데이터를 소비하고 결과를 카프카로 다시 쓰는 자바 애플리케이션을 작성할 수 있게 해주는 Streams API를 제공한다. 아파치 카프카는 또한 아파치 Apex, 아파치 Beam, 아파치 Flink, 아파치 Spark, 아파치 Storm, 아파치 NiFi와 같은 외부 스트림 처리 시스템과 함께 작동한다.

카프카는 하나 이상의 서버(브로커라고 함) 클러스터에서 실행되며, 모든 토픽의 파티션은 클러스터 노드에 분산된다. 또한 파티션은 여러 브로커에 복제된다. 이러한 아키텍처를 통해 카프카는 내결함성 방식으로 대량의 메시지 스트림을 전달할 수 있으며 JMS, AMQP 등과 같은 기존 메시징 시스템을 대체할 수 있게 했다. 0.11.0.0 릴리스부터 카프카는 Streams API를 사용하여 정확히 한 번 스트림 처리를 제공하는 트랜잭션 쓰기를 제공한다.

카프카는 일반 토픽과 압축 토픽의 두 가지 유형의 토픽을 지원한다. 일반 토픽은 보존 시간 또는 공간 제한으로 구성할 수 있다. 지정된 보존 시간보다 오래된 레코드가 있거나 파티션에 대한 공간 제한이 초과되면 카프카는 오래된 데이터를 삭제하여 저장 공간을 확보할 수 있다. 기본적으로 토픽은 7일의 보존 시간으로 구성되지만 데이터를 무기한 저장하는 것도 가능하다. 압축 토픽의 경우 레코드는 시간 또는 공간 경계에 따라 만료되지 않는다. 대신 카프카는 이후 메시지를 동일한 키를 가진 이전 메시지에 대한 업데이트로 취급하고 키당 최신 메시지를 절대 삭제하지 않도록 보장한다. 사용자는 특정 키에 대한 null 값으로 소위 툼스톤 메시지를 작성하여 메시지를 완전히 삭제할 수 있다.

카프카에는 다섯 가지 주요 API가 있다.

  • 프로듀서 API – 애플리케이션이 레코드 스트림을 게시하도록 허용한다.
  • 컨슈머 API – 애플리케이션이 토픽을 구독하고 레코드 스트림을 처리하도록 허용한다.
  • 커넥트 API – 토픽을 기존 애플리케이션에 연결할 수 있는 재사용 가능한 프로듀서 및 컨슈머 API를 실행한다.
  • 스트림 API – 이 API는 입력 스트림을 출력으로 변환하고 결과를 생성한다.
  • 어드민 API – 카프카 토픽, 브로커 및 기타 카프카 객체를 관리하는 데 사용된다.


컨슈머 및 프로듀서 API는 기본 메시징 통신 프로토콜을 통해 카프카의 핵심 기능에서 분리된다. 이를 통해 카프카와 함께 제공되는 자바 API만큼 효율적인 모든 프로그래밍 언어로 호환 가능한 API 계층을 작성할 수 있다. 아파치 카프카 프로젝트는 이러한 타사 API 목록을 유지 관리한다.

Kafka 개요

3. 2. 내결함성

카프카는 하나 이상의 서버(브로커) 클러스터에서 실행되며, 모든 토픽의 파티션은 클러스터 노드에 분산된다. 또한 파티션은 여러 브로커에 복제된다. 이러한 아키텍처를 통해 카프카는 내결함성 방식으로 대량의 메시지 스트림을 전달할 수 있으며 JMS, AMQP 등과 같은 기존 메시징 시스템을 대체할 수 있게 했다.[1] 0.11.0.0 릴리스부터 카프카는 Streams API를 사용하여 정확히 한 번 스트림 처리를 제공하는 ''트랜잭션 쓰기''를 제공한다.[1]

3. 3. 고성능

카프카는 하나 이상의 서버(브로커라고 함) 클러스터에서 실행되며, 모든 토픽의 파티션은 클러스터 노드에 분산된다. 또한 파티션은 여러 브로커에 복제된다. 이러한 아키텍처를 통해 카프카는 내결함성 방식으로 대량의 메시지 스트림을 전달할 수 있으며 JMS, AMQP 등과 같은 기존 메시징 시스템을 대체할 수 있게 했다. 카프카 성능을 추적하는 여러 모니터링 플랫폼이 있으며, JConsole을 포함하여 자바와 함께 제공되는 도구를 사용하여 카프카 데이터를 수집할 수도 있다.[10][11][12]

3. 4. 확장성

카프카는 하나 이상의 서버(브로커) 클러스터에서 실행되며, 모든 토픽의 파티션은 클러스터 노드에 분산된다. 또한 파티션은 여러 브로커에 복제된다. 이러한 아키텍처를 통해 카프카는 내결함성 방식으로 대량의 메시지 스트림을 전달할 수 있으며 JMS, AMQP 등과 같은 기존 메시징 시스템을 대체할 수 있게 했다.[1] 0.11.0.0 릴리스부터 카프카는 Streams API를 사용하여 정확히 한 번 스트림 처리를 제공하는 ''트랜잭션 쓰기''를 제공한다.[1]

카프카는 일반 토픽과 압축 토픽의 두 가지 유형의 토픽을 지원한다. 일반 토픽은 보존 시간 또는 공간 제한으로 구성할 수 있다. 지정된 보존 시간보다 오래된 레코드가 있거나 파티션에 대한 공간 제한이 초과되면 카프카는 오래된 데이터를 삭제하여 저장 공간을 확보할 수 있다. 기본적으로 토픽은 7일의 보존 시간으로 구성되지만 데이터를 무기한 저장하는 것도 가능하다. 압축 토픽의 경우 레코드는 시간 또는 공간 경계에 따라 만료되지 않는다. 대신 카프카는 이후 메시지를 동일한 키를 가진 이전 메시지에 대한 업데이트로 취급하고 키당 최신 메시지를 절대 삭제하지 않도록 보장한다. 사용자는 특정 키에 대한 null 값으로 소위 툼스톤 메시지를 작성하여 메시지를 완전히 삭제할 수 있다.[1]

3. 5. 영속성

카프카는 "프로듀서"라고 불리는 여러 프로세스에서 오는 키-값 메시지를 저장한다. 데이터는 서로 다른 "토픽" 내의 "파티션"으로 분할될 수 있다. 파티션 내에서 메시지는 오프셋(파티션 내 메시지 위치)에 따라 정렬되고, 타임스탬프와 함께 인덱싱되어 저장된다. "컨슈머"라고 불리는 다른 프로세스는 파티션에서 메시지를 읽을 수 있다. 스트림 처리를 위해 카프카는 카프카에서 데이터를 소비하고 결과를 카프카로 다시 쓰는 자바 애플리케이션을 작성할 수 있게 해주는 Streams API를 제공한다. 아파치 카프카는 아파치 Apex, 아파치 Beam, 아파치 Flink, 아파치 Spark, 아파치 Storm, 아파치 NiFi와 같은 외부 스트림 처리 시스템과 함께 작동한다.

카프카는 하나 이상의 서버(브로커라고 함) 클러스터에서 실행되며, 모든 토픽의 파티션은 클러스터 노드에 분산된다. 또한 파티션은 여러 브로커에 복제된다. 이러한 아키텍처를 통해 카프카는 내결함성 방식으로 대량의 메시지 스트림을 전달할 수 있으며 JMS, AMQP 등과 같은 기존 메시징 시스템을 대체할 수 있게 했다. 0.11.0.0 릴리스부터 카프카는 Streams API를 사용하여 정확히 한 번 스트림 처리를 제공하는 ''트랜잭션 쓰기''를 제공한다.

카프카는 일반 토픽과 압축 토픽의 두 가지 유형의 토픽을 지원한다. 일반 토픽은 보존 시간 또는 공간 제한으로 구성할 수 있다. 지정된 보존 시간보다 오래된 레코드가 있거나 파티션에 대한 공간 제한이 초과되면 카프카는 오래된 데이터를 삭제하여 저장 공간을 확보할 수 있다. 기본적으로 토픽은 7일의 보존 시간으로 구성되지만 데이터를 무기한 저장하는 것도 가능하다. 압축 토픽의 경우 레코드는 시간 또는 공간 경계에 따라 만료되지 않는다. 대신 카프카는 이후 메시지를 동일한 키를 가진 이전 메시지에 대한 업데이트로 취급하고 키당 최신 메시지를 절대 삭제하지 않도록 보장한다. 사용자는 특정 키에 대한 null 값으로 소위 툼스톤 메시지를 작성하여 메시지를 완전히 삭제할 수 있다.

4. 구성 요소



카프카는 "프로듀서"라고 불리는 여러 프로세스에서 오는 키-값 메시지를 저장한다. 데이터는 "토픽" 내에서 "파티션"으로 분할된다. 파티션 내에서 메시지는 오프셋(파티션 내 메시지 위치)에 따라 정렬되며, 타임스탬프와 함께 인덱싱되어 저장된다. "컨슈머"는 파티션에서 메시지를 읽을 수 있다. 스트림 처리를 위해 카프카는 Streams API를 제공하며, 카프카에서 데이터를 가져와 결과를 다시 카프카에 쓰는 자바 애플리케이션을 작성할 수 있도록 돕는다. 아파치 카프카는 아파치 Apex, 아파치 Beam, 아파치 Flink, 아파치 Spark, 아파치 Storm, 아파치 NiFi와 같은 외부 스트림 처리 시스템과 함께 작동한다.

카프카는 일반 토픽과 압축 토픽 두 가지 유형을 지원한다. 일반 토픽은 보존 시간 또는 공간 제한으로 구성할 수 있다. 기본적으로 7일 보존 시간으로 구성되지만, 데이터를 무기한 저장하는 것도 가능하다. 압축 토픽의 경우 레코드는 시간 또는 공간 경계에 따라 만료되지 않는다. 대신 카프카는 이후 메시지를 동일한 키를 가진 이전 메시지에 대한 업데이트로 취급하고 키당 최신 메시지를 삭제하지 않는다. 사용자는 특정 키에 대한 null 값으로 툼스톤 메시지를 작성하여 메시지를 완전히 삭제할 수 있다.

카프카에는 다섯 가지 주요 API가 있다.[1]


  • '''프로듀서 API''': 애플리케이션이 레코드 스트림을 게시하도록 허용한다.
  • '''컨슈머 API''': 애플리케이션이 토픽을 구독하고 레코드 스트림을 처리하도록 허용한다.
  • '''커넥트 API''': 토픽을 기존 애플리케이션에 연결할 수 있는 재사용 가능한 프로듀서 및 컨슈머 API를 실행한다.
  • '''스트림 API''': 입력 스트림을 출력으로 변환하고 결과를 생성한다.
  • '''어드민 API''': 카프카 토픽, 브로커 및 기타 카프카 객체를 관리하는 데 사용된다.


컨슈머 및 프로듀서 API는 기본 메시징 통신 프로토콜을 통해 카프카의 핵심 기능에서 분리되어 있다. 이를 통해 모든 프로그래밍 언어로 호환 가능한 API 계층을 작성할 수 있다. 아파치 카프카 프로젝트는 이러한 타사 API 목록을 유지 관리한다.[1]

4. 1. 브로커 (Broker)

카프카는 하나 이상의 서버(브로커라고 함) 클러스터에서 실행되며, 모든 토픽의 파티션은 클러스터 노드에 분산된다. 또한 파티션은 여러 브로커에 복제된다. 이러한 아키텍처를 통해 카프카는 내결함성 방식으로 대량의 메시지 스트림을 전달할 수 있으며 JMS, AMQP 등과 같은 기존 메시징 시스템을 대체할 수 있게 했다.[1] 0.11.0.0 릴리스부터 카프카는 Streams API를 사용하여 정확히 한 번 스트림 처리를 제공하는 ''트랜잭션 쓰기''를 제공한다.[1]

카프카는 1대 이상의 "브로커"라고 불리는 서버로 구성된 클러스터에서 동작하며, 모든 토픽의 파티션이 클러스터 노드에 분산된다. 게다가, 파티션은 여러 브로커에 복제된다. 이 아키텍처를 통해 카프카는 대량의 메시지 스트림을 내결함성 방식으로 전달할 수 있으며, JMS나 AMQP 등의 기존 메시징 시스템의 일부를 대체할 수 있게 되었다.[1] 버전 0.11.0.0에서 트랜잭션 쓰기가 구현되어 Streams API를 사용한 exactly-once 스트림 처리가 가능해졌다.[1]

4. 2. 프로듀서 (Producer)

카프카는 "프로듀서"라고 불리는 프로세스에서 전송되는 키-값 메시지를 저장한다. 데이터는 서로 다른 "토픽" 내의 서로 다른 "파티션"으로 분할될 수 있다. 프로듀서는 프로듀서 API를 통해 레코드 스트림을 게시할 수 있다.[1]

프로듀서 API는 기본 메시징 통신 프로토콜을 통해 카프카의 핵심 기능에서 분리되어 있다. 이를 통해 카프카와 함께 제공되는 자바 API만큼 효율적인 모든 프로그래밍 언어로 호환 가능한 API 계층을 작성할 수 있다. 아파치 카프카 프로젝트는 이러한 타사 API 목록을 유지 관리한다.[1]

4. 3. 컨슈머 (Consumer)

컨슈머 API는 애플리케이션이 토픽을 구독하고 레코드 스트림을 처리하도록 허용한다. 컨슈머 API는 기본 메시징 통신 프로토콜을 통해 카프카의 핵심 기능에서 분리되어 있다. 이를 통해 카프카와 함께 제공되는 자바 API만큼 효율적인 모든 프로그래밍 언어로 호환 가능한 API 계층을 작성할 수 있다. 아파치 카프카 프로젝트는 이러한 타사 API 목록을 유지 관리한다.[1] "컨슈머"라고 불리는 다른 프로세스는 파티션에서 메시지를 읽을 수 있다.[1]

4. 4. 토픽 (Topic)

카프카는 ''프로듀서''라고 불리는 임의의 수많은 프로세스에서 오는 키-값 메시지를 저장한다. 데이터는 서로 다른 "토픽" 내에서 서로 다른 "파티션"으로 분할될 수 있다. 파티션 내에서 메시지는 오프셋(파티션 내 메시지의 위치)에 따라 엄격하게 정렬되며, 타임스탬프와 함께 인덱싱되어 저장된다. "컨슈머"라고 불리는 다른 프로세스는 파티션에서 메시지를 읽을 수 있다.

카프카는 일반 토픽과 압축 토픽, 두 가지 유형의 토픽을 지원한다. 일반 토픽은 보존 시간 또는 공간 제한으로 구성할 수 있다. 지정된 보존 시간보다 오래된 레코드가 있거나 파티션에 대한 공간 제한이 초과되면 카프카는 오래된 데이터를 삭제하여 저장 공간을 확보할 수 있다. 기본적으로 토픽은 7일 보존 시간으로 구성되지만, 데이터를 무기한 저장하는 것도 가능하다. 압축 토픽의 경우 레코드는 시간 또는 공간 경계에 따라 만료되지 않는다. 대신 카프카는 이후 메시지를 동일한 키를 가진 이전 메시지에 대한 업데이트로 취급하고 키당 최신 메시지를 절대 삭제하지 않도록 보장한다. 사용자는 특정 키에 대한 null 값으로 소위 툼스톤 메시지를 작성하여 메시지를 완전히 삭제할 수 있다.

4. 5. 파티션 (Partition)

카프카는 데이터를 서로 다른 "토픽" 내의 서로 다른 "파티션"으로 분할한다. 파티션 내에서 메시지는 오프셋(파티션 내 메시지의 위치)에 따라 엄격하게 정렬되며, 타임스탬프와 함께 인덱싱되어 저장된다. "컨슈머"라고 불리는 다른 프로세스는 파티션에서 메시지를 읽을 수 있다. 스트림 처리를 위해 카프카는 카프카에서 데이터를 소비하고 결과를 카프카로 다시 쓰는 자바 애플리케이션을 작성할 수 있게 해주는 Streams API를 제공한다.

카프카는 하나 이상의 서버(브로커라고 함) 클러스터에서 실행되며, 모든 토픽의 파티션은 클러스터 노드에 분산된다.[1] 또한 파티션은 여러 브로커에 복제된다.[1]

압축 토픽의 경우 레코드는 시간 또는 공간 경계에 따라 만료되지 않는다.[2] 대신 카프카는 이후 메시지를 동일한 키를 가진 이전 메시지에 대한 업데이트로 취급하고 키당 최신 메시지를 절대 삭제하지 않도록 보장한다.[2] 사용자는 특정 키에 대한 null 값으로 소위 툼스톤 메시지를 작성하여 메시지를 완전히 삭제할 수 있다.[2]

4. 6. 오프셋 (Offset)

파티션 내에서 메시지는 오프셋(파티션 내 메시지의 위치)에 따라 엄격하게 정렬되며, 타임스탬프와 함께 인덱싱되어 저장된다. "컨슈머"라고 불리는 다른 프로세스는 파티션에서 메시지를 읽을 수 있다.

4. 7. 주키퍼 (ZooKeeper)

카프카는 주키퍼를 사용하여 브로커, 소비자 및 프로듀서의 메트릭을 추적하고 엔드투엔드 성능을 모니터링한다.[10][11] 카프카 성능을 추적하는 여러 모니터링 플랫폼이 있으며, JConsole을 포함하여 자바와 함께 일반적으로 번들로 제공되는 도구를 사용하여 카프카 데이터를 수집할 수도 있다.[12]

5. API

카프카는 5가지 주요 API를 제공한다:


  • Producer API: 메시지를 발행한다.
  • Consumer API: 토픽을 구독하고 메시지 스트림을 처리한다.
  • Connector API: 기존 애플리케이션에 토픽을 연결한다.
  • Streams API: 입력 스트림을 출력으로 변환하고 결과를 생성한다.
  • Admin API: 토픽, 브로커 및 기타 카프카 객체를 관리한다.


Consumer API와 Producer API는 기본 메시징 통신 프로토콜을 통해 카프카 핵심 기능에서 분리되어 있다. Java 이외의 언어로도 Consumer API 및 Producer API와 호환되는 API를 성능 저하 없이 구현할 수 있다. 아파치 카프카 프로젝트는 이러한 서드 파티 API 목록을 관리한다.

5. 1. Producer API



프로듀서 API는 애플리케이션이 레코드 스트림을 게시할 수 있도록 허용한다. 카프카는 "프로듀서"라고 불리는 임의의 수의 프로세스에서 전송되는 키-값 메시지를 저장한다. 데이터는 서로 다른 "토픽" 내의 서로 다른 "파티션"으로 분할될 수 있다. 파티션 내에서 메시지는 오프셋(파티션 내에서의 메시지 위치) 순서로 기록되며, 타임스탬프와 함께 인덱싱되어 저장된다.

컨슈머 및 프로듀서 API는 기본 메시징 통신 프로토콜을 통해 카프카의 핵심 기능에서 분리되어 있다. 이를 통해 카프카와 함께 제공되는 자바 API만큼 효율적인 모든 프로그래밍 언어로 호환 가능한 API 계층을 작성할 수 있다. 아파치 카프카 프로젝트는 이러한 타사 API 목록을 관리한다.[1]

5. 2. Consumer API

애플리케이션이 토픽을 구독하고 레코드 스트림을 처리하도록 허용한다. 컨슈머 API는 기본 메시징 통신 프로토콜을 통해 카프카의 핵심 기능에서 분리되어 있다. 이를 통해 카프카와 함께 제공되는 자바 API만큼 효율적인 모든 프로그래밍 언어로 호환 가능한 API 계층을 작성할 수 있다. 아파치 카프카 프로젝트는 이러한 타사 API 목록을 관리한다.

5. 3. Streams API

카프카 스트림즈(Kafka Streams, 또는 스트림 API)는 자바로 작성된 스트림 처리 라이브러리이다. 이 라이브러리는 카프카 0.10.0.0 릴리스에 추가되었다. 이 라이브러리를 사용하면 확장 가능하고, 탄력적이며, 완전한 내결함성을 갖춘 상태 저장 스트림 처리 애플리케이션을 개발할 수 있다. 주요 API는 필터, 맵, 그룹화, 윈도잉, 집계, 조인 및 테이블 개념과 같은 고수준 연산자를 제공하는 스트림 처리 도메인 특화 언어(DSL)이다. 또한, 프로세서 API를 사용하여 보다 낮은 수준의 개발 접근 방식으로 사용자 지정 연산자를 구현할 수 있다. DSL과 프로세서 API를 혼합하여 사용할 수도 있다. 상태 저장 스트림 처리를 위해, 카프카 스트림즈는 로컬 연산자 상태를 유지하기 위해 RocksDB를 사용한다. RocksDB는 디스크에 쓸 수 있으므로, 유지 관리되는 상태는 사용 가능한 주 메모리보다 클 수 있다. 내결함성을 위해 로컬 상태 저장소에 대한 모든 업데이트는 카프카 클러스터의 토픽에도 기록된다. 이를 통해 해당 토픽을 읽고 모든 데이터를 RocksDB에 공급하여 상태를 다시 생성할 수 있다.[8][9]

스트림 처리를 위해 카프카는 카프카에서 데이터를 소비하고 결과를 카프카로 다시 쓰는 자바 애플리케이션을 작성할 수 있게 해주는 Streams API를 제공한다. 아파치 카프카는 또한 아파치 Apex, 아파치 Beam, 아파치 Flink, 아파치 Spark, 아파치 Storm, 아파치 NiFi와 같은 외부 스트림 처리 시스템과 함께 작동한다. 0.11.0.0 릴리스부터 카프카는 Streams API를 사용하여 정확히 한 번 스트림 처리를 제공하는 ''트랜잭션 쓰기''를 제공한다.

카프카에는 다섯 가지 주요 API가 있는데, 이 중 스트림 API는 입력 스트림을 출력으로 변환하고 결과를 생성한다.

5. 4. Connect API

카프카 커넥트(Kafka Connect)는 카프카 0.9.0.0 버전에 추가된 기능으로, 다른 시스템에서 데이터를 가져오거나 내보내는 프레임워크이다. 커넥트 API는 내부적으로 프로듀서(Producer) 및 컨슈머(Consumer) API를 사용하며, "커넥터"를 실행하여 다른 시스템에서 데이터를 읽고 쓰는 실제 로직을 구현한다.

커넥트 API는 사용자 지정 커넥터를 구축하기 위한 프로그래밍 인터페이스를 정의한다. 이미 다양한 데이터 시스템을 위한 오픈 소스 및 상용 커넥터가 제공되지만, 아파치 카프카 자체에는 프로덕션 준비가 완료된 커넥터가 포함되어 있지 않다.

5. 5. Admin API

카프카 토픽, 브로커 및 기타 카프카 객체를 관리하는 데 사용되는 API이다.

6. 활용 사례

다음은 카프카를 사용하는 대표적인 기업 목록이다.

기업
애플[28]
Betfair[29]
시스코 시스템즈[30]
Cloudflare[31]
Conviva[32]
카카오 (기업)[33]
이베이[34]
Hyperledger Fabric[35]
HubSpot[36]
넷플릭스[37]
뉴욕 타임스[38]
페이팔[39]
핀터레스트[40]
세일즈포스닷컴[41]
Shopify[42]
스포티파이[43]
티켓마스터[44]
Uber[45]
월마트[46]
Yelp[47]
플립카트[48]



아파치 카프카는 커밋 로그를 기반으로 하며, 사용자는 이를 구독하여 임의의 수의 시스템이나 실시간 애플리케이션에 데이터를 게시할 수 있다. 카프카의 채택 사례로는 우버에서의 승객과 운전기사 매칭 관리, 브리티시 가스(British Gas)의 스마트 홈 서비스에서의 실시간 분석 및 예지 보전 제공, 링크드인 전체에서 다수의 실시간 서비스 실행 등이 있다.[7][19]

7. 성능

엔드투엔드 성능을 모니터링하려면 브로커, 소비자 및 프로듀서의 메트릭을 추적해야 하며, 소비자의 조정을 위해 카프카가 사용하는 주키퍼도 모니터링해야 한다.[10][11] 현재 카프카 성능을 추적하는 여러 모니터링 플랫폼이 있다. 이러한 플랫폼 외에도, JConsole을 포함하여 자바와 함께 일반적으로 번들로 제공되는 도구를 사용하여 카프카 데이터를 수집할 수도 있다.[12]

8. 버전 호환성

카프카 브로커는 0.9.x 버전까지는 구형 클라이언트와의 하위 호환성만 지원했지만, 0.10.0.0 버전부터는 새로운 클라이언트와의 상위 호환성도 지원한다. 새로운 클라이언트가 구형 브로커에 접속하는 경우, 브로커가 지원하는 기능만 사용할 수 있다. Streams API는 0.10.1.0 버전부터 완전한 호환성을 제공한다. 0.10.1.0 버전의 카프카 스트림즈 애플리케이션은 0.10.0 버전 또는 구형 브로커와 호환되지 않는다.[1]

참조

[1] 웹사이트 Apache Kafka at GitHub https://github.com/a[...] 2018-03-05
[2] 웹사이트 Open-sourcing Kafka, LinkedIn's distributed message queue https://blog.linkedi[...] 2016-10-27
[3] 웹사이트 Efficiency https://kafka.apache[...] 2019-09-19
[4] 웹사이트 He Left His High-Paying Job At LinkedIn And Then Built A $4.5 Billion Business In A Niche You've Never Heard Of https://www.forbes.c[...] Forbes 2021-06-08
[5] 웹사이트 Apache Incubator: Kafka Incubation Status https://incubator.ap[...] 2022-10-17
[6] 서적 Kafka: The Definitive Guide https://books.google[...] O'Reilly 2017
[7] 웹사이트 What is Apache Kafka https://www.confluen[...] 2018-05-04
[8] 웹사이트 Apache Kafka https://kafka.apache[...] 2021-09-10
[9] 웹사이트 Apache Kafka https://kafka.apache[...] 2021-09-10
[10] 웹사이트 Monitoring Kafka performance metrics https://www.datadogh[...] 2016-04-06
[11] 뉴스 Monitoring Kafka performance metrics https://www.datadogh[...] 2016-04-06
[12] 웹사이트 Collecting Kafka performance metrics - Datadog https://www.datadogh[...] 2016-04-06
[13] 웹사이트 Apache Kafka at GitHub https://github.com/a[...] 2018-03-05
[14] 웹사이트 Open-sourcing Kafka, LinkedIn's distributed message queue https://blog.linkedi[...] 2016-10-27
[15] 웹사이트 Efficiency https://kafka.apache[...] 2019-09-19
[16] 문서 Li, S. (2020).
[17] 웹사이트 Apache Incubator: Kafka Incubation Status https://incubator.ap[...] 2023-02-06
[18] 웹사이트 What is the relation between Kafka, the writer, and Apache Kafka, the distributed messaging system? https://www.quora.co[...] 2023-02-08
[19] 웹사이트 What is Apache Kafka https://www.confluen[...] 2018-05-04
[20] 웹사이트 Monitoring Kafka performance metrics https://www.datadogh[...] 2016-04-06
[21] 웹사이트 Monitoring Kafka performance metrics https://www.datadogh[...] 2016-04-06
[22] 웹사이트 Collecting Kafka performance metrics - Datadog https://www.datadogh[...] 2016-04-06
[23] Github Repository Mirror at GitHub https://github.com/a[...]
[24] 웹인용 Open-sourcing Kafka, LinkedIn's distributed message queue https://blog.linkedi[...] 2016-10-27
[25] 블로그 Monitoring Kafka performance metrics https://www.datadogh[...] Datadog Engineering Blog 2016-05-23
[26] 블로그 The Log: What every software engineer should know about real-time data's unifying abstraction http://engineering.l[...] LinkedIn Engineering Blog 2014-05-05
[27] 웹인용 LinkedIn engineers spin out to launch 'Kafka' startup Confluent http://fortune.com/2[...] 2015-02-10
[28] 웹인용 Kafka Summit London https://kafka-summit[...]
[29] 웹인용 Exchange Market Data Streaming with Kafka https://betsandbits.[...]
[30] 웹인용 OpenSOC: An Open Commitment to Security http://blogs.cisco.c[...] 2016-02-03
[31] 웹인용 More data, more data https://blog.cloudfl[...] 2018-10-21
[32] 웹인용 Conviva home page http://www.conviva.c[...] 2017-02-28
[33] 웹인용 S2Graph : A Large-Scale Graph Database with HBase http://apachebigdata[...]
[34] 웹인용 Kafka Usage in Ebay Communications Delivery Pipeline https://www.youtube.[...]
[35] 웹인용 Cryptography and Protocols in Hyperledger Fabric https://www.zurich.i[...] 2017-01-01
[36] 웹인용 Kafka at HubSpot: Critical Consumer Metrics https://web.archive.[...] 2018-10-21
[37] 웹인용 Netflix: Integrating Spark at Petabyte Scale http://apachebigdata[...]
[38] 웹인용 Publishing with Apache Kafka at The New York Times https://web.archive.[...] 2017-09-19
[39] 웹인용 PayPal: Creating a Central Data Backbone: Couchbase Server to Kafka to Hadoop and Back (talk at Couchbase Connect 2015) https://web.archive.[...] 2016-02-03
[40] 웹인용 Pinterest: Using Kafka Streams API for predictive budgeting https://medium.com/@[...] 2018-02-21
[41] 웹인용 How Apache Kafka Inspired Our Platform Events Architecture https://engineering.[...] 2018-02-01
[42] 웹인용 Shopify - Sarama is a Go library for Apache Kafka https://github.com/S[...]
[43] 웹인용 How Apache Drives Spotify's Music Recommendations http://apachebigdata[...]
[44] 웹인용 CTOs to Know: Meet Ticketmaster's Jody Mulkey https://web.archive.[...] 2018-10-21
[45] 웹인용 Stream Processing in Uber http://www.infoq.com[...] 2015-12-06
[46] 웹인용 Apache Kafka for Item Setup https://medium.com/w[...] 2017-06-12
[47] 웹인용 Streaming Messages from Kafka into Redshift in near Real-Time https://web.archive.[...] 2017-07-19
[48] 웹인용 Near Real Time Search Indexing at Flipkart https://tech.flipkar[...]

관련 사건 타임라인

( 최근 20개의 뉴스만 표기 됩니다. )


본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.

문의하기 : help@durumis.com