반응형

데이터 엔지니어로 살아가기 104일째 (곰발바닥 뭔가 귀엽다...)


오늘 하루는 오전에는 브루클린이라는 키워드 타겟팅 시스템에서 사용하는 알파 RabbitMQ의 큐들을 모두 priority큐들로 바꿔서 테스트 하는 작업을 진행하였다. priority를 높게준 메세지들부터 정상적으로 consume 하는 것을 확인을 하며 RabbitMQ가 제공해주는 모니터링 관리 페이지부터 시작해서 꽤나 괜찮은 메세지큐라는 생각을 다시 한 번 했다. 기존에 ActiveMQ를 잠깐 사용했을 때는 별도의 관리 페이지를 제공해주지 않아 불편함이 있었는데 요즘은 지원해주려나???


오후즈음에는 실시간 관심사 타겟팅 로직에서 카산드라에 데이터를 넣을 때 에러 처리가 하나도 되어 있지 않아 실제로 데이터가 들어가지 않아도 관리자 입장에서는 알 수 있는 방법이 딱히 없다. 그래서 해당 부분에 에러처리를 해서 정상적으로 데이터가 upsert되지 않았을 경우 알림을 받도록 기능을 추가하고자 마음먹고 Git 에서 소스코드를 받아 로컬환경에 셋팅을 하기 시작하였다. 기존 작업을 하셨던 분이 repository를 잘관리하지 않으시고 실제로 배포 프로세스를 따르지 않고 실제 서버에서 수정해서 사용하기도 했던 것 같다. 따라서 소스코드를 다운받았을 때 메이븐 디펜던시며 소스코드들이 피를 토해내고 있었다...어쩜 이렇게 관리가 안될 수 있는지..왜 컴파일은 자바5버전으로 되도록 메이븐에 설정되어있는건지...왜 위키페이지에는 별도의 내용이 하나도 없는건지...답답함 투성이였다. 

실시간 관심사쪽과 실시간 리타겟팅쪽 코드를 같이 셋팅했는데 생각보다 리타겟팅쪽 코드들은 빠르게 셋팅하고 .gitignore도 등록해주었다. 기존에는 .gitignore도 없이 어떻게 사용하신건지...그냥 빌드되는 target 모든 jar파일과 class파일들을 서버에 반영하고 사용하셨던 것 같다....


이번 한 주는 관리하고 있는 프로젝트들에 대한 소스코드 및 배포 프로세스를 바로 잡는데 시간을 많이 보내야 할 것 같다.

그럼 오늘 하루도 안녕~

반응형
반응형

큐잉 시스템과 카프카가 다른점

분명히 카프카는 메시지들이 수신된 순서대로 처리되도록 보장하기 위해 많은 문제를 겪는 ActiveMQ나 RabbitMQ 같은 큐잉 시스템이 아니다.

카프카의 파티셔닝 시스템은 이런 구조를 유지하지 않는다. 특정한 토픽의 파티션에 대한 쓰기와 읽기 순서에 대한 정의가 없으므로 클라이언트는 메시지가 쓰여진 순서와 다르게 파티션에서 읽을 수도 있다. 게다가 생산자를 비동기로 구현하는 일이 흔해서 한 파티션으로 보내진 메시지는 (비록 응답대기시간이나 비결정적 이벤트의 차이로 인해 먼저 발생하더라도) 또 다른 파티션으로 보내진 메시지 이후에 쓰여질 수도 있다.


카프카는 또한 메시지 소비자를 다루는 방법에서도 많은 큐잉 시스템과는 다르다. 대부분의 큐잉 시스템에서 메시지는 소비되었을 때 시스템에서 제거된다. 카프카는 메시지를 제거하는 메커니즘이 없는 대신, 소비한 마지막 메시지의 오프셋을 지속적으로 파악하기 위해 소비자에 의존한다. 로그는 카프카 설정의 log.retention.hours 설정에 의해 삭제된다.


[ 참고 ] 실시간 분석의 모든 것


반응형

'Bigdata > Kafka' 카테고리의 다른 글

카프카(KAFKA) 데이터 처리방식의 특화된 기능  (1) 2017.08.30

+ Recent posts