메뉴 건너뛰기

Bigdata, Semantic IoT, Hadoop, NoSQL

Bigdata, Hadoop ecosystem, Semantic IoT등의 프로젝트를 진행중에 습득한 내용을 정리하는 곳입니다.
필요한 분을 위해서 공개하고 있습니다. 문의사항은 gooper@gooper.com로 메일을 보내주세요.


*출처 : http://jays1204.github.io/kafka/2017/07/12/kafka-caution.html


카프카 사용시 주의 사항

현재 개발에서 여러가지 데이터 전송을 위해 카프카를 사용하고 있다.
카프카를 사용하면서 겪은(주의하지 못해) 문제를 이야기 하려 한다.

메세지 중복 consume, At-least-once

카프카에 메세지를 보내고(publish), 받아오는(consume) 과정을 진행할 때 주의해야 할 사항이 있다.
우선 기본적으로 한 파티션에는 그룹의 하나의 컨슈머만 메세지를 가져올 수 있다.

이제 카프카의 토픽에 메세지 A가 담겨있다고 가정해보자.
이때 특정 그룹의 컨슈머는 토픽에 대해 메세지를 컨슘하고 이에 대해 특정 일을 처리하고 commit을 할 것 이다.
이러한 일련의 작업을 하다보면 이미 처리했다고 생각한 메세지 A가 다시 한번 컨슘되는 현상이 발생한다.
이것은 카프카가 기본적으로 메세지 전송에 대해 at-least-once 정책이기 때문이다.
‘적어도 한번’은 메세지를 보낸다는 것으로 동일 메세지에 대해 전송이 1번 혹은 그 이상이 될 수 있음을 말한다.

메세지 중복 consume이 발생할 수 있는 상황

1. 클라이언트가 메세지를 보내길 시도했는데 네트워크 에러가 발생하였다. 이에 대한 재시도가 잠재적으로 중복 메세지를 쌓을 수 있다.  만일 메세지가 전송되기 전에 네트워크 장애가 일어났다면 중복은 발생하지 않을 것이다. 그러나 메세지가 카프카의 로그에 쌓인 이후지만 로그에 쌓였음의 응답이 publisher에 돌아오기 전의 상황에 네트워크 장애가 발생하였다면 메세지 중복이 발생할 수 있다.  
2. 컨슈머가 토픽으로부터 메세지를 읽었는데 크래시가 발생하였다. 컨슈머가 재시작하거나 또는 다른 인스턴스가 consume을 하려할때 이미 읽은 메세지부터 다시 읽게 된다.    
    - 카프카에서 메세지를 컨슘해서 이에 대한 task A을 처리하였다.  
    - 일을 완료후 해당 메세지의 offset까지 처리하였음을 의미하는 commit을 하길 원했다.  
    - commit 도중에 어떠한 이유로 장애가 발생하였다.  
    - 이미 해당 메세지에 대해 task A를 처리하였는데 동일 메세지가 다시금 consume되었다.  
    - 혹은 리밸런싱(rebalancing)시에 발생할 수도 있다. 컨슈머 그룹내에 변동이 생기면 파티션과 짝을 맞출 컨슈머를 다시 재분배하는 것을 의미한다.  

이와 같은 이유로 메세지를 받아 이를 처리할 땐 해당 메세지가 이전에 받아온 메세지인지 여부를 알 수 있어야 한다.
예를 들면 DB table의 pk를 메세지에 포함시켜서 해당 메세지에 대한 일이 처리되면 DB에 업데이트를 하여 컨슈머에서 중복 여부를 알 수 있게 할 수 있다.

consume 메세지의 순서

보통 카프카의 토픽을 구성할 땐 여러개의 파티션을 이용하기 마련이다.
timestamp를 순서대로 보내는 publisher가 있다고 가정하고 이를 10개의 파티션으로 구성된 토픽에 전송하고 이를 동일 컨슈머 그룹의 10개의 컨슈머가 컨슘하고 있다고 가정을 해보자.
순서대로 보낸 timestamp메세지는 각 파티션에 차례대로 쌓일 것이다. 
하지만 막상 10개의 컨슈머에서 consume해온 기록을 종합해서 보다 보면 consume해온 timestamp의 순서가 보낸 순서와 완벽하게 일치 하지 않을 수 있다. 
이는 카프카가 단일 파티션내에선 쌓인 순서대로 메세지를 consume하도록 보장을 해주는 반면 서로 다른 파티션에 대해서는 순서를 보장해주지 않기 때문이다.
모든 메세지를 정말로 순서대로 가져가길 원한다면 파티션을 하나로 구성할 수 있다.
혹은 publish할때마다 파티션을 지정해서 메세지를 전송하여 일부 순서를 보장할 수 있다.

References

번호 제목 글쓴이 날짜 조회 수
637 kudu rebalance수행 command예시 총관리자 2022.01.17 80
636 Kudu tablet이 FAILED일때 원인 확인 방법 총관리자 2022.01.17 88
635 Failed to write to server: (no server available): 총관리자 2022.01.17 32
634 Soft memory limit exceeded (at 100.05% of capacity) 오류 조치 총관리자 2022.01.17 174
633 not leader of this config: current role FOLLOWER 오류 발생시 확인방법 총관리자 2022.01.17 22
632 Oracle NLOB type의 데이터를 import하는 경우 No Java type for SQL type 2011 for column rst와 같은 오류 발생시 조치사항 총관리자 2022.01.14 35
631 kudu 테이블 metadata강제 삭제시 발생하는 오류 메세지 총관리자 2022.01.12 106
630 hadoop nfs gateway설정 (Cloudera 6.3.4, CentOS 7.4 환경에서) 총관리자 2022.01.07 115
629 oracle 12에 sqoop해서 데이터 import하기 (console에서 sqoop import하는 방법) 총관리자 2021.12.31 45
628 python2.7.4에서 Oracle DB(11.2)를 사용하기 위한 설정(RPM을 이용하여 RHEL 7.4에 설치) 총관리자 2021.11.26 320
627 클러스터내의 전체 workflow및 coordinator현황을 사용자별로 추출하는 방법 총관리자 2021.11.25 23
626 hue.axes_accessattempt테이블의 username컬럼에 NULL 혹은 space가 들어갈수도 있음. 총관리자 2021.11.03 2838
625 Query Status: Sender xxx.xxx.xxx.xxx timed out waiting for receiver fragment instance: 1234:cdsf, dest node: 10 의 오류 원인및 대응방안 총관리자 2021.11.03 76
624 hive metastore db중 TBLS, TABLE_PARAMS테이블 설명 총관리자 2021.10.22 258
623 kudu hms check 사용법(예시) 총관리자 2021.10.22 65
622 Hue Load Balancer를 L4로 L/B하는 경우는 L4쪽 도멘인으로 발행된 인증서를 TLS/SSL항목에 설정해주어야 한다. 총관리자 2021.10.08 99
621 TLS/SSl설정시 방법및 참고 사항 총관리자 2021.10.08 82
620 you are accessing a non-optimized hue please switch to one of the available addresses 총관리자 2021.10.06 42
619 CM의 Impala->Query tab에서 FINISHED query가 보이지 않는 현상 총관리자 2021.08.31 35
618 tablet별 disk사용량 확인하는 방법 총관리자 2021.08.27 110

A personal place to organize information learned during the development of such Hadoop, Hive, Hbase, Semantic IoT, etc.
We are open to the required minutes. Please send inquiries to gooper@gooper.com.

위로