5. 카프카 사례
05. 카프카 사례
메시지큐, 제품/로그 수집, 제품/ETL 도구 등 대량의 데이터 처리를 실시간 처리 / 높은처리량에 목표를 둠
카프카의 대표적 기능
각 기능에 대한 필요에 따른 선택권이 다양하여, 유연한 구조로 형성되어 있음
데이터허브 : 이기종 시스템 간
데이터 상호 교환로그 수집 : 다양한 로그 수집. 인고징능 분석, 리포팅 등 여러 서버에서 로그 수집 -> 데이터 저장위치
연결웹 로그 분석 : 실시간 대시보드, 이상 탐지/부정 검출 등 웹에서의
사용자활동실시간 분석사물인터넷 : 센서 및 디바이스에 의한 데이터 수신 -> 처리 -> 디바이스에 전송
이벤트 소싱 : 일련의 이벤트를 순차 기록 및
CQRS방식으로 대령의 이벤트를 유연하게 처리
카프카 특징 회고
카프카는 대량의 데이터를 높은처리량으로 실시간으로 처리하기 위한 솔루션이다.
데이터 상호교환을 위한 기반으로 발전
현재 카프카 -> 데이터 전달하는 파이프라인 그 자체를 구성하기 위한 기반이라고 일컬을 정도.
카프카의 실현
확장성 : 여러 서버로 확장(
스케일아웃) 구성할 수 있기 때문에 데이터 양에 따라시스템 확장 가능영속성 : 수신한 데이터를
디스크에 유지(기본 7일)가능 -> 언제든 데이터 Read 가능유연성 :
연계가능한 제품이 다수(Spark, Hadoop, ES 등) -> 시스템 연결하는허브 역할신뢰성 :
메시지전달보증->데이터 무손실
데이터 허브 뿐 아니라, 카프카의 기능과 다른 제품 결합 -> 실시간으로 높은 처리량의 데이터를 처리 스트림 처리의 기반으로 사용도 가능.
펍/섭 메시징 모델 기반-> 동일한 메시지를여러곳에 전달(동보전송)가능파티션단위 한정 ->
순서 보증 가능
카프카 각 기능과 특징이 중시 되는 상황 정리
실시간 : 데이터를
즉시 사용동보전송 : 동일 데이터 ->
여러 후속 시스템에서 사용영속성 :
데이터 버퍼링경우 or처리 시간 가격이 다른 복수의 처리와 관련된 경우다수의 제휴제품 : 사용되는
제품이 균일하지 않고,다양한 접속이 필요한 경우송수신 보증 :
데이터 손실이 허용되지 않는 경우순서 보증 : 데이터 출발지에 있어
데이터의 생성 순서를 중시하여순서에 따른 판단과 제어를 수반하는 경우
데이터 허브에서 해결 과제
확장
사일로화 : 시스템간의 연계를 효율적으로 할 수 없는 상황
새로운 송신처의 확장
새로운 생산자의 확장
사일로화 해결과제
데이터 소스에서
생성된 동일한 데이터를여러 시스템에서 이용후속 시스템마다 데이터를 필요로 하는 시기와 빈도가 다르다
접속원이나 연결 시스템에서 이용되는
연계 방식이 제각각이다. (ex, FTP전송에 의한 파일 연계규칙이 시스템마다 상이, JDBC 연결 DBMS 제품이 여러종류)데이터 분실을 허용하지 않는다
카프카로 데이터 허브 구현
데이터 허브 아키텍처
카프카를
중개자 역할로 하여 모든 시스템이 데이터허브에 데이터를 전송하고, 데이터허브에서 데이터를 받도록 설계M:N 접속 -> 데이터 허브(카프카에 연결)
동보전송:pub/sub 메시징 모델로 착안했기 때문에 해결영속화: 데이터 필요시기, 빈도 -> 후속 시스템마다 다른 문제에 대해 카프카는 데이터를 영속화하고 버퍼링함으로써임의의 시기에 추출 가능다수의 연계 제품:Kafka Connect로연계할 수 있는 제품이 다수 존재-> 접속원 or 연결시스템에서 사용하는 제품이 다수라 해도 대응이 가능송수신 보증:데이터 무손실가능.At Least Once, Exactly Once등 서로 다른 수준의 송수신 보증으로 대응
로그 수집
로그 수집으로 실현하고자 하는 것
여러서버에 존재하는 로그파일 ->
중앙집중화하고자 하는 경우Logstash 같은 역할이 가능
ELK의 조합까지 필요하지 않는 경우에 선택
서버가 증가할 때마다
로그를 중앙에서 수집이 가능여러 웹서버 로그 -> 로그중앙수집(카프카) -> HDFS에 로그 저장
로그수집시 해결해야할 과제
여러 데이터소스와 연결
데이터소스의 제품이 다양할 수 있음 ->
다양한 제품과 연계가능성염두일괄적으로 일정 간격마다 축적 / 버퍼가 넘쳐 로그를 잃는 일이 벌어지면 안됨 ->
일정하게 집약하고 버퍼링하기 위한 장치 필요로그 전달시,
로그를 잃어서는 안됨(전달보증)-> 약간의 손실을 허용할 수 도 있겠으나, 엄격한 트랜잭션 관리까지는 아니더라도,로그 무손실이 요구사항
카프카로 로그 수집
다수 연계 제품 : Producer API / 단순 서버로그 수집 -> Fluentd + 카프카 조합
영속화 : 디스크 영속화 -> 큰 데이터도
메모리에서 손실되더라도 차후에 디스크에서 Read가 가능. 메모리 공간을 넘는큰용량의 버퍼로이용 할 수 있다는 점이 장점송수신보증 :
At Least Once(적어도 한 번은 보내기)수준 -> 송수신보증, 약간의 손실을 허용하는 경우는 Ack를 반환하지 않음으로써 데이터 소스쪽의 처리를 줄여 성능향상을 우선 할 수 있음. 필요에 따라 수준은 조정이가능Scribe, Flume 같은 제품도 있으나, 카프카만의 장점 -> 우수한 성능, 복제가능(내장애성), 종단간 지연 시간 낮음
웹 활동 분석
사이트 방문 하는
사용자의 행동분석을 통해마케팅에 활용클릭한 페이지의 로그 ->
이동경로 파악
활용 예
페이지 뷰와 전환율(성공율/구매율)파악
개인화된 권장사항
로얄 고객 파악, 고객 클러스터링?
A/B 테스트에 의한 웹사이트 개선
웹활동분석 해결 과제
실시간실현하기 위한 구조여러 데이터 소스와 접속
데이터 분실 방지 : At Least Once (데이터 분실은 허용하지 않지만, 중복은 최소 허용) 수준이 다수
순서보증
카프카로 웹활동 분석
실시간 : Kafka Stream, Spark Stream -> 실시간 발생하는 데이터
간헐적 수신 및 수신데이터 즉시처리가 가능. 배치처리와는 다른 어려움 존재
스트림 이란
일정기간마다 보내는(배치)가 아니라
작은단위로 지속적으로 데이터를 보냄실시간 생성되는 데이터를
순차적으로 처리
사물인터넷
사물인터넷으로 실현
다양한 디바이스가 인터넷 접속-> 대량의 데이터 생산
모든 디바이스에 데이터 수집 -> 관리/모니터링
디바이스 모니터링 : 디바이스 상태 체크
예방보전, 예측보전/사전 감지 : 고장전에 탐지 -> 교환
품질개선 : 성능저하 파악 -> 제품 개발 피드백 -> 품질향상
원격제어 : 디바이스에서 얻은 정보 -> 피드백 -> 디바이스 동작 원격 제어
실현하기 위한 과제 및 카프카 적용
순간 대량 발생 데이터 처리 방안 필요
실시간 데이터 교환 및 여러 디바이스 접속 지원 필요
MQTT라는 프로토콜 전송되는 경우가 많음, 대응 고려대상
이벤트 소싱
상태 변화 하나하를
이벤트로 취급-> 발생하는이벤트를 순서대로 기록해두는 것기록된 이벤트 -> 도메인 객체 구체화 하여 -> 경위도 확인
메시지는 로그로 순차적으로 기록 ->
카프카의 아키텍처 그자체->이벤트 소싱에 적합
CQRS 개념
Command Query Responsibility Segregation (
커맨드 쿼리 책임 분리)데이터의 갱신과 문장의 처리를 분리하는 개념의 아키텍처커맨드 :
데이터의 명령. 갱신처리-> create/update/delete쿼리 :
데이터의 문의, 참조 처리커맨드 ->
데이터 갱신에만 관심, 처리쿼리 ->
적절한 결과반환만책임
이벤트 소싱과 CQRS로 해결해야 할 과제
애플리케이션의 기록과 읽기의 엑세스패턴이 다를 수 있음
대량의 데이터가 시계열로 기록되어도, 읽을 때는 시계열이 아닌 특정 ID단위로 읽고자 할 수 있음
데이터는 동일하더라도, 그 데이터를 다양한 목적으로 사용 -> 집계하는 단위가 목적마다 다양한 경우
CQRS 개념 예->데이터 쓰기와 읽기 분리
이벤트 소싱 + CQRS에 카프카 사용하기
갱신처리 / 참조처리 분리를 위해
카프카 아키텍처 사용카프카 -> 이벤트 저장소, 이벤트 전달허브
CQRS : 카프카가 데이터소스 에서 시계열 데이터 받아 기록 -> 커맨드역할, 카프카가 데이터 싱크에 데이터 전달 -> 수신쪽 : 자신의 쿼리에
참조효율이 좋은 형식으로 데이터 변환커맨드 : 갱신처리의 순차기록
데이허브 : 데이터 전달
이벤트 -> 카프카(이벤트 소싱, 수신)<커맨드> -> 이벤트처리 및 결과반환<쿼리>
Last updated