[Kafka] 1장 들어가며

아파치 카프카 어플리케이션 With Java 책을 정리하여 쓴 글입니다 😎

[Kafka] 들어가며...

카프카의 탄생

• 카프카는 링크드인에서 제작됨

• 파편화된 데이터 파이프라인의 복잡도를 낮춰주는 아키텍쳐를 위해 설계됨.

  • 기존의 링크드인 시스템은 소스 <-> 타깃 어플리케이션간의 연결하는 파이프라인 갯수가 많아지면서 소스코드 및 버전관리 에서 이슈가 생김
  • 아래는 기존의 링크드인 시스템 출처

  

  • 아래는 카프카를 사용한 시스템 아키텍쳐

  

• 즉, 카프카는 기업의 대용량 데이터를 수집하고 이를 사용자들이 실시간 스트림으로 소비할 수 있게 만들어줌.

• 카프카를 사용함으로써 소스 어플리케이션과 타깃 어플리케이션의 Coupling이 느슨해짐

• 카프카 내부에 데이터가 저장되는 파티션 의 동작은 FIFO 방식의 큐 자료구조와 유사하다.

• 큐에 데이터를 보내는 것이 프로듀서 이고 큐에 데이터를 가져가는 것이 컨슈머 이다.

• 카프카를 통해 전달할 수 있는 데이터 포맷은 사실상 제한이 없다.

  • 직렬화(Serialize), 역직렬화(Deserialize 를 통해 Byte Array 로 통신하기 때문에 자바에서 선언 가능한 모든 객체를 지원한다.
  • 카프카 클라이언트에서는 기본적으로 ByteArray, ByteBuffer, Double, Long, String타입에 대응한 직렬화, 역직렬화 클래스가 제공된다.
  • 만약 필요할 경우 카프카에서 제공하는 커스텀 직렬화/역직렬화 클래스Serializer<T>, Deserializer<T> 를 상속받아 개발에 사용할 수 있다.

• 카프카는 최소 3대 이상의 서버(브로커)에서 분산 운영하여 프로듀서를 통해 전송받은 데이터를 파일 시스템에 안전하게 기록한다.

  • 서버 3대 이상으로 이루어진 카프카 클러스터 중 일부 서버에 장애가 발생하더라도 데이터를 지속적으로 복제(Replica?) 하기 때문에 안전하게 운영할 수 있다.
  • 또한 데이터를 묶음 단위로 처리하는 배치 전송 을 통해 낮은 지연과 높은 데이터 처리량도 가지게 되었다.

빅데이터 파이프라인에서 카프카의 역할

• 데이터 레이크(Data Lake) : 이름에서 유추할 수 있듯, 데이터가 모이는 저장공간을 뜻함

  • 운영되는 서비스로부터 수집가능한 모든 데이터를 모으는 것

  데이터 웨어하우스 (Data Ware house)와는 다르게 필터링되거나 패키지화되지 않은 데이터가 저장된다는 점이 특징이다.

• 카프카는 데이터 레이크를 모으기 위한 안정적인 데이터 파이프라인 역할을 할 수 있는 이유는 다음과 같다.

  • 높은 처리량

    • 카프카는 프로듀서가 브로커로 데이터를 보낼때와 컨슈머가 브로커로부터 데이터를 받을 때 모두 묶어서 전송한다 많은 양의 데이터를 송수신할 때 맺어지는 네트워크 비용은 무시할 수 없는 규모다. 따라서 네트워크 통신횟수를 최소한으로 줄임으로써, 동일 시간내에 더 많은 데이터를 전송할 수 있다. 많은양의 데이터를 묶음 단위로 처리하기 때문에 대용량의 실시간 로그 데이터를 처리하는데에 적합하다. 또한 파티션 단위를 통해 동일 목적의 데이터를 여러 파티션에 분배하고 데이터를 병렬 처리할 수 있다.

  • 확장성

    • 카프카는 요청이 가변적인 환경에서 안정적으로 확장 가능하도록 설계(Scale-in/out)할 수 있다. 처리해야할 데이터의 양이 많아지면 클러스터의 브로커 개수를 자연스럽게 늘려 스케일 아웃할 수 있고, 반대로 데이터 개수가 적어지고 추가 서버들이 더는 필요 없어지면 브로커 개수를 줄여 스케일 인 할 수 있다.

  • 영속성

    • 영속성이란 데이터를 생성한 프로그램이 종료되더라도 사라지지 않은 데이터의 특성을 뜻한다. 카프카는 다른 메시징 플랫폼과는 다르게 전송받은 데이터를 메모리에 저장하지 않고 파일 시스템에 저장한다. 카프카는 운영체제 레벨에서 파일 시스템을 최대한 활요하는 방법을 적용하였다. 파일 I/O 성능 향상을 위해 페이지 캐시(Page cache) 영역을 메모리에 따로 생성하여 사용한다. 페이지 캐시 메모리 영역을 사용하여 한번 읽은 파일 내용은 메모리에 저장시켰다가 다시 사용하는 방식이기 때문에 카프카가 파일 시스템에 저장하고 데이터를 저장,전송하더라도 처리량이 높은 것이다. 또한 디스크 기반의 파일 시스템을 활용한 덕분에 브로커 어플리케이션에 장애가 발생으로 인해 급작스럽게 종료되더라도 프로세스를 재시작하여 안전하게 데이터를 다시 처리할 수 있다.

  • 고 가용성

    • 3개 이상의 서버들로 운영되는 카프카 클러스터는 일부서버에 장애가 발생하더라도 무중단으로 안전하고 지속적으로 데이터를 처리할 수 있다. 클러스터로 이루어진 카프카는 데이터의 복제(Replication)을 통해 고가용성의 특징을 가지게 되었다. 프로듀서로 전송받은 데이터를 여러 브로커 중 1대의 브로커에만 저장하는 것이 아니라 또 다른 브로커 에도 저장하는 것이다. 따라서 한 브로커에 장애가 발생하더라도 복제된 데이터가 나머지 브로커에 저장되어 있으므로 저장된 데이터를 기준으로 지속적으로 데이터 처리가 가능한 것이다.

데이터 레이크 아키텍처와 카프카의 미래

• 데이터 레이크 아키텍처의 종류는 2가지가 있다.

  1. 람다 아키텍쳐(Lambda Architecture)

     

     출처 : http://lambda-architecture.net/img/la-overview_small.png

     • 람다 아키텍쳐는 3가지 레이어로 나뉜다.

     • 레이어 종류	역할	비고
       배치 레이어	배치 데이터를 모아서 특정시간, 특정 타이밍마다 일괄 처리한다.
       서빙 레이어	가공된 데이터를 사용자, 서비스 어플리케이션이 사용할 수 있도록 데이터가 저장된 공간이다.
       스피드 레이어	서비스에서 생성되는 원천 데이터를 실시간으로 분석하는 용도로 사용된다. 배치 데이터에 비해 낮은 지연으로 분석이 필요한 경우 스피드 레이어를 사용한다.

       람다 아키텍쳐에서 카프카는 스피드 레이어에 위치한다.

       • 서비스 어플리케이션들의 실시간 데이터를 짧은 지연시간으로 처리, 분석할 수 있기 대문이다.
       • 카프카 스트림즈와 같은 스트림 프로세싱 도구는 윈도우 함수, 상태 기반 프로세싱, 무상태 기반 프로세싱 등이 있다.

     • 장점

       • 데이터를 배치 처리하는 레이어와 실시간 처리하는 레이어를 분리하여, 처리방식을 명확히 나눌 수 있음

     • 단점

       • 말그대로 레이어가 2개로 나뉘기 때문에 데이터를 분석, 처리하는데 필요한 로직이 2벌로 각각의 레이어에 따로 존재해야 한다.
       • 또한 배치 데이터와 실시간 데이터를 융합하여 처리할 때 다소 유연하지 못한 파이프라인을 생성화해야 한다.

  2. 카파 아키텍쳐(Kappa Architecture)

     

     출처 : https://blog.voidmainvoid.net/407

     • 카파 아키텍처는 람다 아키텍쳐에서 단점으로 부각되었던 로직의 단편화, 디버깅, 배포 운영 분리 에 대한 이슈를 제거하기 위해 배치 레이어를 제거했다.

     • 스피드 레이어에서 데이터를 모두 처리할 수 있었으므로 엔지니어들은 더욱 효율적으로 개발과 운영에 임할 수 있게 되었다.

     • 그런데 카파 아키텍처는 스피드 레이어에서 모든 데이터를 처리하므로 서비스에서 생성되는 모든 종류의 데이터를 스트림 처리해야된다.

       사실 이 부분이 현재 잘 이해되지 않는다. 나중에 2번 보게 될 때 해결될 문제겠지?

     • 배치 데이터를 어떻게 스트림 프로세스로 처리할 수 있게 된 것일까?

       

       • 모든 데이터를 log로 바라보는 것에서 시작됨

       • 여기서 말하는 log는 텍스트 로그가 아니고, 데이터의 집합을 뜻함

       • 이 데이터는 지속적으로 추가가 가능하며 각 데이터에는 일정한 번호(또는 타임스태프)가 붙는데 이는 배치 데이터를 스트림으로 표현하기에 적합

         일반적으로 데이터 플랫폼에서 데이터를 표현할 때는 각 시점의 전체 데이터를 백업한 스냅샷 데이터를 뜻했다. 그러나 배치 데이터를 로그로 표현할 때는 각 시점의 배치 데이터의 변환 기록을 시간 순서대로 기록함으로써 각 시점의 모든 스냅샷 데이터를 저장하지 않고도 배치 데이터를 표현할 수 있게 되었다.

 **람다 아키텍쳐 -> 카파 아키텍처를 거쳐 앞으로의 카프카는 어떤 카프카일까?**

스트리밍 데이터 레이크의 제안

• 2020년 카프카 서밋에서 제이 크랩스는 카파 아키텍쳐에서 서빙 레이어를 제거한 아키텍처인 스트리밍 데이터 레이크(Streaming Data Lake)를 제안 했다.

• 카파 아키텍쳐에서는 스트림 데이터를 서빙 레이어에 저장하는 것을 알 수 있다. 서빙 레이어는 하둡 시스템 오브젝트 스토리지와 같이 데이터 플랫폼에서 흔히 사용되는 저장소이다.

• 굳이 카프카를 통해 분석하고 프로세싱한 데이터를 다시 서빙 레이어의 저장소에 저장할 필요가 있을까? 하는 생각에서 발달됐고, 스피드 레이어로 사용되는 카프카에 분석과 프로세싱을 완료한 거대한 용량의 데이터를 오랜 기간 저장하고 사용할 수 있다면 서빙레이어는 제거 되어도 된다. 라는 생각이다.

• 따라서 서빙 레이어와 스피드 레이어가 이중으로 관리되는 운영 리소스를 줄일 수 있다는 것이다.

• 아직은 카프카를 스트리밍 데이터 레이크로 사용하기 위해 개선해야 하는 부분이 있다. 자주 접근하지 않는 데이터를 굳이 비싼자원에 유지할 필요가 없다. 카프카 클러스터에서 자주 접근하지 않는 데이터는 오브젝트 스토리지와 같이 저렴하면서도안전한 저장소에 옮겨 저장하고 자주 사용하는 데이터만 브로커에서 사용하는 구분 작업이 필요하다.