카프카의 특징을 복습하면서 카프카 적용 사례를 통해 카프카가 적합하게 사용된 이유를 알아보았다.
BI
도구를 이용한 리포팅과 인공지능 분석을 위해 여러 서버에서 생긴 로그를 수집하고 축적할 곳에 연결한다.CQRS
방식으로 대량의 이벤트를 유연하게 처리한다.카프카는 대량의 데이터를 '높은 처리량'으로 '실시간' 처리하기 위한 제품이다. 현재 카프카가 데이터를 전달하는 파이프라인 그 자체를 구성하기 위한 기반이라고 말할 정도로 발전했다. 카프카로 실현할 수 있는 4가지를 다시 복습하고 추가적인 부분도 알아본다.
이러한 사항을 바탕으로 대량의 데이터를 처리해야 하는 전제하에, 카프카의 각 기능과 특징이 중시되는 상황을 정리하면 다음과 같다.
카프카가 데이터 허브로 활용된 사례를 알아본다. 데이터 허브란 여러 곳의 데이터 소스가 되는 시스템에서 데이터를 수집하여 여러 시스템에 전달하는 아키텍처를 의미한다.
비즈니스에 있어서 IT
시스템은 IT
전문 기업뿐만 아니라 일반 기업에서도 많이 사용한다. 특히 사업 부문별로 업무 시스템화를 추진한 조직에는 부서마다 개별 시스템이 있는데, 이러한 개별 시스템은 각각 독립적으로 최적화되어 운용되는 경우가 많다. 이렇게 독립적으로 존재하는 시스템 사이에서는 효율적인 데이터 전달이 필요하다.
데이터허브가 없는 경우 어떤 문제가 있을지 알아본다. 독립된 시스템이 많은 회사는 시스템 간 데이터 연계라는 큰 과제가 있다. 어떤 시스템에 있는 데이터를 다른 3개의 시스템으로 전송해야 하는 경우 3개의 시스템별로 데이터 연계 방식을 조정해야 한다. 연계 시스템 간의 조정을 추가할 시스템에도 적용하고 기존의 시스템에도 수정을 거쳐 안정적으로 가동시켜야 한다. 시스템이 많으면 많을수록 시스템 간의 접속 패턴과 변형이 많아져서 힘들어진다. 데이터 허브가 해결해야 할 과제는 다음과 같다.
사일로화를 해결하기 위한 개념의 하나로 데이터 허브 아키텍처가 있다. 데이터 허브 아키텍처에서는 시스템을 일대일로 연결하는 대신 모든 시스템이 데이터 허브에 데이터를 보내고 데이터 허브에서만 데이터를 받을 수 있도록 되어 있다. 이렇게 하면 시스템은 데이터를 데이터 허브에 보내는 것만 생각하면 되고, 데이터를 수신하는 시스템도 데이터 허브에서 데이터를 받는 것만 생각하면 된다.
Kafka Connect
로 연계할 수 있는 제품이 다수 있기 때문에 접속원이나 연결 시스템에서 사용하는 제품이 다수라고 하더라도 이에 대응할 수 있는 가능성이 높다.카프카가 로그 수집에 활용된 사례를 알아본다.
여러 서버에 존재하는 로그 파일을 한 곳에서 보관하고 싶은 경우가 있다. 로그 수집을 간단한 것으로 생각할지도 모르겠지만 애플리케이션이 늘어나면서 외부와의 연계가 증가하면 로그 수집을 위한 노력도 증가한다. 이를 보다 편하게 하고 싶다는 생각이 자연스럽게 든다.
로그 수집에 카프카가 유용한 점은 다음과 같다.
Producer API
가 있어 이를 이용하여 카프카와 접속하는 애플리케이션을 만들 수도 있다. At Least Once
수준의 송수신은 보증한다.카프카를 웹 활동 분석에 적용한 사례를 알아본다.
웹 활동 분석은 웹사이트를 방문하는 사용자의 해동을 파악하여 마케팅에 활용하기 위한 작업이다. 웹 활동 분석의 대표적인 사례는 다음과 같은 것이 있으며, 이를 통해 실현하고 싶은 것 또한 매우 다양하다.
A/B
테스트에 의한 웹사이트 개선사용자의 행동을 실시간으로 파악해 즉시 대응하려는 요구의 전형적인 예는 다음과 같다.
카프카는 '실시간', '다수의 연계 제품', '송수신 보장', '순서 보증'의 기능에 있어 유효하다. 실시간으로 처리하는 부분은 Kafka Streams
를 이용하는 방법도 있고, 카프카 뒤에서 스파크의 처리를 위한 구성 요소인 Structured Streaming
을 사용하는 방법도 있다.
실시간 발생하는 데이터를 간헐적으로 수신하고, 수신한 데이터를 바로 처리하기 때문에 이른바 스트림 처리가 가능하다.
카프카를 사물인터넷에 적용한 사례를 알아본다.
사물인터넷이란 통신 기능이 있는 다양한 디바이스가 인터넷을 통해 서로 연결되어 있는 상태를 말한다. 센서나 통신 기기의 소형화, 저전력화에 따라 다양한 디바이스가 인터넷에 접속할 수 있게 됐다. 다양한 디바이스가 인터넷을 통해 연결되어 있어서 모든 디바이스에서 정보를 수집해 디바이스를 관리하거나 모니터링할 수 있게 되었다. 사물인터넷 이용 사례로 다음과 같은 것들이 있다.
카프카를 이용하여 이를 어떻게 실현하는지 10장에서 배운다고 한다.
카프카를 이벤트 소싱에 적요한 사례를 알아본다.
이벤트 소싱은 상태의 변화 하나하나를 이벤트로 취급하여 발생하는 이벤트를 순서대로 기록해두는 것이다. 사용자는 기록된 이벤트에서 도메인 객체를 구체화할 수 있으며 경위도 확인할 수 있다.
CQRS(Command Query Responsibility Segregation)
(커맨트 쿼리 책임 분리)란 데이터의 갱신과 문의 처리를 분리하는 개념의 아키텍처다.
커맨튿란 데이터의 create
/update
/delete
등 데이터 갱신 처리에 해당한다. 쿼리란 데이터 문의, 즉 참조 처리에 해당한다. CQRS
는 Command
(갱신)와 Query
(참조)의 책임을 분리한다는 의미다.
제공하는 서비스 특성에 따라 애플리케이션에서 기록할 때와 읽을 때의 엑세스 패턴이 크게 다를 수 있다. 대량의 데이터가 시계열로 기록되어도 읽을 때는 시계열이 아니라 특정 ID
단위로 받고 싶은 경우도 있을 수 있다.
또한 기록되는 데이터는 동일하더라도 그 데이터를 여러 목적으로 사용하고 싶은 경우도 있다. 예를 들어 축적된 데이터를 집계하는 단위가 목적마다 다른 경우가 있다. 기존 BI
시스템 중에서도 데이터 웨어하우스에 목적별로 데이터 마트를 여럿 만들어 각 데이터 마트에서 리포팅을 실시하는 경우가 종종 있다.
만약 데이터 처리의 부하가 높지 않다면 1대의 DB
서버 안에서 쓰기 전용과 읽기 전용의 데이블을 2개 준비해서 테이블의 형식을 변환하는 방법을 생각할 수 있다. 그러나 쓰기와 읽기 모두 처리 부하가 높은 경우에는 성능을 높이기 위한 튜닝의 난이도가 높아진다. 이를테면 메모리 사용법에 있어 쓰기 전용 버퍼 공간을 많이 확보할 것인지 읽기 전용 캐시 공간을 많이 확보할지 메모리 사용을 어떻게 해야 할지 망성리게 된다. 이런 상황일 때 등장하는 것이 데이터 쓰기와 읽기를 분리하는 CQRS
개념이다.
CQRS
개념인 갱신 처리와 참조 처리의 분리를 위해 카프카를 아키텍처로 사용한다. 카프카는 이벤트를 저장하는 저장소이며 이벤트를 전달하는 허브로 간주할 수 있다. CQRS
는 다음과 같은 형태로 구현한다.
예를 들면 카프카는 커맨드에 해당하는 갱신 처리로 이벤트를 받는 역할을 한다. 쿼리에 해당하는 참조를 처리하기 위한 형식 변환은 카프카와 분리된 별도의 기반에서 담당한다. 참조를 위한 DBMS
를 뒤편에 준비해 카프카와 분리한다. 이때 카프카는 커맨드(갱신 처리)의 순차 기록과 데이터 허브로서 데이터를 전달하는 두 가지 역할을 담당한다. 또한 읽기와 쓰기 처리를 분리만 하는 것이 아니라 읽기 형식이 여럿이거나 여러 시스템이 존재하는 등 다양한 요구 사항에도 대응이 가능하다.
이렇듯 이벤트 소싱과 CQRS
개념을 조합함으로써 애플리케이션에서 쓰기와 읽기 엑세스 패턴이 다르더라도 유연하게 대응할 수 있다. 이벤트를 여러 용도로 사용하는 경우에도 각각의 요구 사항에 적합한 데이터 모델을 적용할 수 있다.