5장. 카프카 사례

문법식·2022년 9월 1일
0

카프카의 특징을 복습하면서 카프카 적용 사례를 통해 카프카가 적합하게 사용된 이유를 알아보았다.

카프카

카프카의 대표적 기능

  • 데이터허브
    여러 시스템 사이에서 데이터를 상호 교환한다.
  • 로그 수집
    BI 도구를 이용한 리포팅과 인공지능 분석을 위해 여러 서버에서 생긴 로그를 수집하고 축적할 곳에 연결한다.
  • 웹 활동 분석
    실시간 대시보드와 이상 탐지/부정 검출 등 웹에서의 사용자 활동을 실시간으로 파악한다.
  • 사물 인터넷
    센서 등 다양한 디바이스에서 보낸 데이터를 수신해서 처리한 후 디바이스에 송신한다.
  • 이벤트 소싱
    데이터에 대한 일련의 이벤트를 순차적으로 기록하고 CQRS 방식으로 대량의 이벤트를 유연하게 처리한다.

카프카 특징

카프카는 대량의 데이터를 '높은 처리량'으로 '실시간' 처리하기 위한 제품이다. 현재 카프카가 데이터를 전달하는 파이프라인 그 자체를 구성하기 위한 기반이라고 말할 정도로 발전했다. 카프카로 실현할 수 있는 4가지를 다시 복습하고 추가적인 부분도 알아본다.

  • 확장성: 여러 서버로 확장 구성할 수 있기 때문에 데이터 양에 따라 시스템 확장이 가능하다.
  • 영속성: 수신한 데이터를 '디스크에 유지'할 수 있기 때문에 언제라도 데이터를 읽을 수 있다.
  • 유연성: '연계할 수 있는 제품이 많기' 때문에 제품이나 시스템을 연결하는 허브 역할을 한다.
  • 신뢰성: '메시지 전달 보증'을 하므로 데이터 분실을 걱정하지 않아도 된다.
  • 스트림 처리: 카프카의 기능과 다른 제품을 결합함으로써 실시간으로 높은 처리량의 데이터를 처리할 수 있다. 따라서 간헐적으로 발생하는 데이터를 수신하여 그때마다 순차 처리하는 스트림 처리의 기반으로 카프카를 사용할 수 있다.
  • 동보 전송: 카프카는 확장성, 영속성, 유연성, 신뢰성을 실현하기 위한 아키텍처로 펍/섭 메시징 모델 기반이라는 점에서 큐 모델과 달리 동일한 메시지를 여러 곳에 전달하는 동보 전송도 가능하다.
  • 메세지 순서 보증: 메시지를 토픽에 포함된 파티션 단위로 한정하면 메시지의 순서 보증의 실현 또한 가능하다.

이러한 사항을 바탕으로 대량의 데이터를 처리해야 하는 전제하에, 카프카의 각 기능과 특징이 중시되는 상황을 정리하면 다음과 같다.

  • 실시간
    긴급성이 요구되거나 데이터를 즉시 사용하는 경우
  • 동보 전송
    하나의 동일한 데이터를 후속의 여러 시스템에서 사용하는 경우, 데이터를 전달하는 관계 시스템이 단계적으로 증가하는 경우
  • 영속성
    데이터를 버퍼링해야 하는 경우나 처리 시간 간격이 다른 복수의 처리와 관련된 경우
  • 다수의 제휴 제품
    사용되는 제품이 균일하지 않고 다양한 접속을 필요로 하는 경우
  • 송수신 보증
    데이터 손실이 허용되지 않는 경우
  • 순서 보증
    데이터 소스에 있어 데이터의 생성 순서에 따른 판단과 제어를 수반하는 경우

데이터 허브

카프카가 데이터 허브로 활용된 사례를 알아본다. 데이터 허브란 여러 곳의 데이터 소스가 되는 시스템에서 데이터를 수집하여 여러 시스템에 전달하는 아키텍처를 의미한다.

데이터 허브로 실현하고자 하는 것

비즈니스에 있어서 IT 시스템은 IT 전문 기업뿐만 아니라 일반 기업에서도 많이 사용한다. 특히 사업 부문별로 업무 시스템화를 추진한 조직에는 부서마다 개별 시스템이 있는데, 이러한 개별 시스템은 각각 독립적으로 최적화되어 운용되는 경우가 많다. 이렇게 독립적으로 존재하는 시스템 사이에서는 효율적인 데이터 전달이 필요하다.

데이터 허브에서 해결해야 할 과제

데이터허브가 없는 경우 어떤 문제가 있을지 알아본다. 독립된 시스템이 많은 회사는 시스템 간 데이터 연계라는 큰 과제가 있다. 어떤 시스템에 있는 데이터를 다른 3개의 시스템으로 전송해야 하는 경우 3개의 시스템별로 데이터 연계 방식을 조정해야 한다. 연계 시스템 간의 조정을 추가할 시스템에도 적용하고 기존의 시스템에도 수정을 거쳐 안정적으로 가동시켜야 한다. 시스템이 많으면 많을수록 시스템 간의 접속 패턴과 변형이 많아져서 힘들어진다. 데이터 허브가 해결해야 할 과제는 다음과 같다.

  • 데이터 소스에서 생성된 동일한 데이터를 여러 시스템에서 이용한다.
  • 후속 시스템마다 데이터를 필요로 하는 시기와 빈도가 다르다.
  • 접속원이나 연결 시스템에서 이용되는 연계 방식이 제각각이다.
  • 데이터 분실을 허용하지 않는다.

카프카로 데이터 허브 구현하기

사일로화를 해결하기 위한 개념의 하나로 데이터 허브 아키텍처가 있다. 데이터 허브 아키텍처에서는 시스템을 일대일로 연결하는 대신 모든 시스템이 데이터 허브에 데이터를 보내고 데이터 허브에서만 데이터를 받을 수 있도록 되어 있다. 이렇게 하면 시스템은 데이터를 데이터 허브에 보내는 것만 생각하면 되고, 데이터를 수신하는 시스템도 데이터 허브에서 데이터를 받는 것만 생각하면 된다.

  • 동보 전송
    데이터 소스에서 생성된 동일 데이터를 여러 시스템이셔 이용할 수 있다. 이는 펍/섭 메시징 모델로 착안했기 때문에 실현 가능하다.
  • 영속화
    데이터를 필요로 하는 시기와 빈도가 후속 시스템마다 다른 문제에 대해 카프카는 데이터를 영속화하고 버퍼링함으로써 임의의 시기에 추출할 수 있다.
  • 다수의 연계 제품
    Kafka Connect로 연계할 수 있는 제품이 다수 있기 때문에 접속원이나 연결 시스템에서 사용하는 제품이 다수라고 하더라도 이에 대응할 수 있는 가능성이 높다.
  • 송수신 보증
    카프카는 데이터 분실이 허용되지 않는 요구 사항에 대해 송수신을 보증한다.

로그 수집

카프카가 로그 수집에 활용된 사례를 알아본다.

로그 수집으로 실현하고자 하는 것

여러 서버에 존재하는 로그 파일을 한 곳에서 보관하고 싶은 경우가 있다. 로그 수집을 간단한 것으로 생각할지도 모르겠지만 애플리케이션이 늘어나면서 외부와의 연계가 증가하면 로그 수집을 위한 노력도 증가한다. 이를 보다 편하게 하고 싶다는 생각이 자연스럽게 든다.

로그 수집에서 해결해야할 과제

  • 로그 수집은 우선 여러 데이터 소스와 연결돼야 한다.
  • '일괄적으로 일정 간격마다 축적'하는 것과 함께 '버퍼가 넘쳐 로그를 잃는 일'이 벌어지면 곤란하므로 대량의 로그를 받아 일정한 모음으로 집약하고 버퍼링하기 위한 장치가 필요하다.
  • 로그 전달 시 로그를 잃어서는 안 된다는 점이 있다.

카프카로 로그 수집하기

로그 수집에 카프카가 유용한 점은 다음과 같다.

  • 다수의 연계 제품
    카프카에는 Producer API가 있어 이를 이용하여 카프카와 접속하는 애플리케이션을 만들 수도 있다.
  • 영속화
    카프카는 데이터를 디스크에 영속화한다. 메모리 공간보다 더 큰 데이터라면 이를 디스크에 보관해 혹여 메모리 안에서 손실되거나 제외되더라도 나중에 읽을 수 있도록 되어 있다.
  • 송수신 보증
    At Least Once 수준의 송수신은 보증한다.

웹 활동 분석

카프카를 웹 활동 분석에 적용한 사례를 알아본다.

웹 활동 분석으로 실현하고자 하는 것

웹 활동 분석은 웹사이트를 방문하는 사용자의 해동을 파악하여 마케팅에 활용하기 위한 작업이다. 웹 활동 분석의 대표적인 사례는 다음과 같은 것이 있으며, 이를 통해 실현하고 싶은 것 또한 매우 다양하다.

  • 페이지 뷰와 전환율(성공율/구매율) 파악
  • 개인화된 권장 사항
  • 로얄 고객을 파악하는 고객 클러스터링
  • A/B 테스트에 의한 웹사이트 개선

사용자의 행동을 실시간으로 파악해 즉시 대응하려는 요구의 전형적인 예는 다음과 같다.

  • 상태 업데이트가 시시각각 표시되는 실시간 대시보드 구축
  • 실시간 이상 탐지/부정 검출
  • 실시간으로 사용자의 행동을 추적하여 서비스 이탈 방지

웹 활동 분석에서 해결해야 할 과제

  • '실시간'을 실현하기 위한 구조
    긴급성과 즉시성을 필요로 하기 때문에 이를 실현하기 위한 구조가 필요하다.
  • 여러 데이터 소스와 접속
  • 데이터 분실 방지
    예를 들어 이상 탐지, 부정 검출을 해야 하는데 데이터 레코드가 손실됐을 경우 확인할 방법이 없다. 따라서 레코드를 잃지 않기 위한 송수신 보증이 필요하다.
  • 순서 보증
    순서 보증의 경우 온라인 게임에서 사용자 이탈 방지 사례가 이해하기 쉽다. 게임을 즐기는 사용작의 동작을 추적한 데이터는 서비스 개선에 활용할 수 있을 뿐만 아니라 사용자가 현재 어떤 상황에 있는지도 분석할 수 있다. 데이터를 잘 활용하면 사용자가 게임에 실증난 상태를 감지할 수 있다는 의미다. 이를 활용하여 사용자 이탈을 막기 위해 실증난 상태를 감지하면 즉시 특별 이벤트를 실시하거나 귀중한 아이템을 주는 등 사용자의 이탈 방지를 위한 조치를 할 수 있다. 이때 '사용자가 현재 어떤 상황에 있는지'를 파악하는 아이디어로 사용자의 행동 순서를 고려하는 방법이 있다.

카프카로 웹 활동 분석하기

카프카는 '실시간', '다수의 연계 제품', '송수신 보장', '순서 보증'의 기능에 있어 유효하다. 실시간으로 처리하는 부분은 Kafka Streams를 이용하는 방법도 있고, 카프카 뒤에서 스파크의 처리를 위한 구성 요소인 Structured Streaming을 사용하는 방법도 있다.
실시간 발생하는 데이터를 간헐적으로 수신하고, 수신한 데이터를 바로 처리하기 때문에 이른바 스트림 처리가 가능하다.


사물인터넷

카프카를 사물인터넷에 적용한 사례를 알아본다.

사물인터넷으로 실현하고자 하는 것

사물인터넷이란 통신 기능이 있는 다양한 디바이스가 인터넷을 통해 서로 연결되어 있는 상태를 말한다. 센서나 통신 기기의 소형화, 저전력화에 따라 다양한 디바이스가 인터넷에 접속할 수 있게 됐다. 다양한 디바이스가 인터넷을 통해 연결되어 있어서 모든 디바이스에서 정보를 수집해 디바이스를 관리하거나 모니터링할 수 있게 되었다. 사물인터넷 이용 사례로 다음과 같은 것들이 있다.

  • 디바이스 모니터링
    개별 디바이스에서 정보를 직접 수집하고 디바이스 상태를 파악한다.
  • 예방 보전, 예측 보전/사전 감지
    디바이스의 상태를 시계열로 수집하고 수집한 데이터를 분석하여 디바이스의 고장을 파악해 고장 전에 교환한다.
  • 품질 개선
    디바이스 모니터링을 실시해 시간 경과에 대한 성능 저하를 파악한 후 이를 제품 개발에 피드백하여 품질을 개선한다.
  • 원격 제어
    디바이스에서 얻은 정보를 바탕으로 디바이스에 피드백함으로써 디바이스 동작을 원격으로 제어한다.

사물인터넷을 실현하기 위한 과제와 카프카 적용

  • 매 순강 대량으로 발생하는 데이터를 어떻게 처리할 것인가
  • 실시간으로 데이터를 교환하는 것
  • 여러 디바이스와 접속하는 것
  • 원격 제어처럼 상태에 따라 즉시 실행을 요구하는 상황에서는 디바이스 데이터를 실시간으로 수집할 뿐만 아니라 해당 요구에 실시간으로 처리한 후 전달하는 구조가 필요

카프카를 이용하여 이를 어떻게 실현하는지 10장에서 배운다고 한다.


이벤트 소싱

카프카를 이벤트 소싱에 적요한 사례를 알아본다.

이벤트 소싱이란?

이벤트 소싱은 상태의 변화 하나하나를 이벤트로 취급하여 발생하는 이벤트를 순서대로 기록해두는 것이다. 사용자는 기록된 이벤트에서 도메인 객체를 구체화할 수 있으며 경위도 확인할 수 있다.

CQRS란?

CQRS(Command Query Responsibility Segregation)(커맨트 쿼리 책임 분리)란 데이터의 갱신과 문의 처리를 분리하는 개념의 아키텍처다.
커맨튿란 데이터의 create/update/delete 등 데이터 갱신 처리에 해당한다. 쿼리란 데이터 문의, 즉 참조 처리에 해당한다. CQRSCommand(갱신)와 Query(참조)의 책임을 분리한다는 의미다.

이벤트 소싱과 CQRS로 해결해야 할 과제

제공하는 서비스 특성에 따라 애플리케이션에서 기록할 때와 읽을 때의 엑세스 패턴이 크게 다를 수 있다. 대량의 데이터가 시계열로 기록되어도 읽을 때는 시계열이 아니라 특정 ID 단위로 받고 싶은 경우도 있을 수 있다.
또한 기록되는 데이터는 동일하더라도 그 데이터를 여러 목적으로 사용하고 싶은 경우도 있다. 예를 들어 축적된 데이터를 집계하는 단위가 목적마다 다른 경우가 있다. 기존 BI 시스템 중에서도 데이터 웨어하우스에 목적별로 데이터 마트를 여럿 만들어 각 데이터 마트에서 리포팅을 실시하는 경우가 종종 있다.
만약 데이터 처리의 부하가 높지 않다면 1대의 DB 서버 안에서 쓰기 전용과 읽기 전용의 데이블을 2개 준비해서 테이블의 형식을 변환하는 방법을 생각할 수 있다. 그러나 쓰기와 읽기 모두 처리 부하가 높은 경우에는 성능을 높이기 위한 튜닝의 난이도가 높아진다. 이를테면 메모리 사용법에 있어 쓰기 전용 버퍼 공간을 많이 확보할 것인지 읽기 전용 캐시 공간을 많이 확보할지 메모리 사용을 어떻게 해야 할지 망성리게 된다. 이런 상황일 때 등장하는 것이 데이터 쓰기와 읽기를 분리하는 CQRS 개념이다.

이벤트 소싱 + CQRS에 카프카 사용하기

CQRS 개념인 갱신 처리와 참조 처리의 분리를 위해 카프카를 아키텍처로 사용한다. 카프카는 이벤트를 저장하는 저장소이며 이벤트를 전달하는 허브로 간주할 수 있다. CQRS는 다음과 같은 형태로 구현한다.

  • 카프카가 데이터 소스에서 시계열 데이터를 받아 기록한다. 이것은 커맨드 쪽 역할을 한다.
  • 카프카가 데이터 싱크에 데이터를 전달한다. 받은 쪽은 자신의 쿼리에 있어서 참조효율이 좋은 형식으로 데이터를 변환하여 사용한다.
  • 이렇게 해서 커맨드와 쿼리의 분리가 가능해진다.

예를 들면 카프카는 커맨드에 해당하는 갱신 처리로 이벤트를 받는 역할을 한다. 쿼리에 해당하는 참조를 처리하기 위한 형식 변환은 카프카와 분리된 별도의 기반에서 담당한다. 참조를 위한 DBMS를 뒤편에 준비해 카프카와 분리한다. 이때 카프카는 커맨드(갱신 처리)의 순차 기록과 데이터 허브로서 데이터를 전달하는 두 가지 역할을 담당한다. 또한 읽기와 쓰기 처리를 분리만 하는 것이 아니라 읽기 형식이 여럿이거나 여러 시스템이 존재하는 등 다양한 요구 사항에도 대응이 가능하다.
이렇듯 이벤트 소싱과 CQRS 개념을 조합함으로써 애플리케이션에서 쓰기와 읽기 엑세스 패턴이 다르더라도 유연하게 대응할 수 있다. 이벤트를 여러 용도로 사용하는 경우에도 각각의 요구 사항에 적합한 데이터 모델을 적용할 수 있다.

profile
백엔드

0개의 댓글