행복한디벨로퍼

데이터 엔지니어로 살아가기 182일째(nginx ssl인증서 교체) 

오늘의 주요 업무는 로그수집서버 (nginx 8대)들의 ssl 인증서 교체해주는 작업을 진행하였다.

로그수집서버 프로젝트를 로컬에 받아 인증서를 교체 후 알파에 먼저 테스트를 진행하였다.

예전 웹서버 개발할때 많이 하던 작업인데 오랜만에 하려니 가물가물하였다.

로컬에 알파 로그수집서버 ip와 호스트명을 박아놓고 확인하니 정상적으로 요청이 잘갔다.

보통 변경된 인증서의 정보가 잘못되거나 인증서의 비밀번호가 유효하지 않다면 nginx 재시작시 문제가 발생한다.

알파에서 테스트 완료후 리얼서버 8대 한대 한대 l4를 내리고 배포하는 작업을 진행하였다.

최근 custom targeting 작업을 진행하느라 정신없었는데 ssl인증서 작업이 끝나니 홀가분하다.

좀더 custom targeting작업에 집중할 수 있겠다:)

데이터 엔지니어로 살아가기 163일째(kafka, camus) 

기존에 kafka가 2개의 broker로 동작하고 있었는데 broker한대를 추가하게 되었다.

broker추가와 동시에 partition, replica 설정을 변경하는 작업을 하였다.

알파에서 테스트가 진행되었고 리얼에 적용을 하였는데 특정 topic으로 데이터를 처리하지 못하는 이슈가 발생하였다.

topic중 nginx - fluentd를 통해서 들어오는 데이터는 정상적으로 받고 있었지만

api서버에서 kafkaAppender로 로그를 produce하고 있는 topic이 정상적으로 동작하지 않았다.

원인은 api서버의 hosts파일에 kafka브로커들의 ip와 hostname이 등록되어 있지 않았기 때문이다.

기본적으로 api통신을 할 경우 acl이 뚫려 있고 어플리케이션 내부에서 ip로 목적지가 등록이 되어 있는 경우

문제없이 동작하여야 하지만 클라우데라를 통해 운영되고 있는 주키퍼, 카프카 등 하둡에코시스템이 호스트네임을 기반으로

서로 통신을 하고 있었기 때문에 ip정보만으로는 카프카 브로커를 찾아가지 못하는 문제가 있었다.

이번 문제로 많은 시간을 삽질을 하게되었지만 카프카 offset부터 camus가 어떤식으로 offset을 관리하고 있는지에 대해서

좀 더 깊게 들여다 볼수 있는 시간이 되었다.

camus는 현재 gobblin이라는 프로젝트로 넘어가 관리되고 있는 듯 싶었다.

카프카 특정 topic의 데이터를 hdfs에 적재해야한다면 gobblin을 검토해보면 좋을 듯 싶다.

이상~

앞으로라도 간단히 데이터 엔지니어로서 일을 하면서 경험했던 것들 생각들을 가볍게 공유해보고자 한다.

오늘은 데이터 유입쪽에 대한 파악작업을 진행하였다. 

nginx http요청으로 매체쪽 태그매니저로부터 들어오는 로그들이 어떻게 처리되는지

nginx 설정은 어떻게 되는지에 대해서 확인했다. 

기존 웹 서버 개발할 때는 아파치만 쓰다가 nignx를 보니 뭐 정확하게 어떻게 돌아가는지 정확한 이해는 안갔지만

대충 설정들을 보니 예상정도는 할 수 있었다. 

오늘 이해하고 파악한 부분은 nginx -> fluentd -> kafka 로 통하는 flow에 대한 전반적인 이해를 하였고

실제 알파 클러스터에서 설정을 변경해보며 이것저것 테스트해보았다. 

생각보다 td-agent 쪽에서도 offset 작업이 잘 이루어져 실제 nginx로 데이터가 들어왔을 때 td-agent가 죽어 있었더라도

다시 td-agent를 시작하게되면 읽어오지 않은 데이터부터 읽어 카프카로 전송하더라

아직 유입쪽에 쿠키발급부분이라던지 확인할 부분이 많지만 전반적인 유입 flow와 설정들을 이해한것만으로도 굉장히 뿌듯하다.