반응형

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


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


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

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


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

그럼 오늘 하루도 안녕~

반응형
반응형

데이터 엔지니어로 살아가기 101일 째


어제(0609 금요일) 하루는 최근 회사 내에서  IDC 네트워크 장애에 대해 공유하는 시간을 가졌다. 

서버룸중 특저 서버룸의 스위치가 문제를 일으키며 해당 룸의 서버들의 네트워크 통신이 정상적으로 되지 않았다. 

사내에서 서비스하는 서비스들 모두가 장애시간동안 정상동작 하지 않았던 대형 이슈였다.

큰 장애가 터진 문제의 시발점은 access switch OS 버그에서 기인했다고 설명해주셨다. 

네트워크적인 지식이 많이 부족해 공유된 내용 모두를 이해하진 못했지만 사소한 버그들이 맞물려 큰 사고로 이어졌고 이에 대한 대응책등을 공유하는 시간을 가졌다.


오후에 저번주 리타겟팅 시스템 장애로 작업이 진행되지 못했던 실시간 모니터링 시스템에 대한 작업을 진행하였다.

실시간으로 처리되고 있는 데이터들이 정상적으로 데이터를 카산드라에 적재하고 있는지 모니터링 하기 위한 시스템이다.

작업을 하면서 어려움을 느꼈던 부분은 현재 알파 클러스터와 리얼클러스터에서 스파크 버전이 1.5에 맞춰져 있어 kafka stream, spark의 maven dependency버전 맞추는 부분에서 시간을 많이 빼앗겼다. 스칼라로 작업했으면 훨씬 빠르게 했을 것을 다른 시스템과의 연동이 많이 필요할 것 같아 자바(java8 이 아닌 java7)로 스파크 작업을 하다보니 시행착오를 많이 겪었다.


알파 클러스터에는 실시간으로 데이터들이 적재되지 않고 있기 때문에 curl을 통해 실시간으로 로그를 쏴주는 스크립트를 작성 후 

카프카에서 실시간 처리하는 시스템 작업으로 생각보다 고려할점들이 많았다.


간만에 시스템 설계부터 코딩작업에 시간은 잘갔던 것 같다. 

시행착오들, 경험들이 쌓여 이후 작업에서는 시스템 설계와 구현시 같은 이유로 시간을 많이 빼앗기지 않도록 열심히 배우고 공부하자.


반응형
반응형

오늘은 금요일~~~~ 날씨도 너무 좋고 기분좋은 금요일이다.


오늘 하루는 어제 마무리 짓지 못했던  xx번가 EP 비교 작업을 끝냈다.


하루치끼리 비교한 결과 18기가에서 1.7기가로 사이즈가 확 줄었고 라인수도 500만개로 줄었다.


어떻게 하루만에 상품차이가 500만개나 나는지.....사람이 일일히 상품등록하고 하진 않겠지?.....


아무튼 비교를 잘 끝내고 전체 EP업데이트가 아닌 부분 EP업데이트 하는 부분으로 진행하는 부분에 대해서는 협의가 필요할 듯 싶다.


아무래도 전체 프로세스를 조금씩 손보아야 하기 때문에....

그리고 준형 선임님과 승완씨가 오후 반차로 나와 실장님만 남아 오후를 보내게 되었다.


오후에는 리타겟팅 전반에 대해 flow를 따라가며 파악작업을 진행하였고 중간중간 xx번가 EP가 잘 돌고 있는지 확인하는 작업을 진행하였다.


리타겟팅이 프로세스를 따라가며 파악작업을 진행하며 가장 크게 느낀점은 데이터를 기반으로 한 광고시스템은 너무 매력적이라는 것이다.


실시간으로 사용자의 행동들이 광고 시스템에 반영이되고 그 내부적으로 돌아가는 프로세스와 데이터 flow들을 보고나니 새삼 더 느끼게 되었다. 


EP작업도중 고질적으로 발생하는 실시간 리타겟팅 잡이 정상적으로 돌지 못하는 문제가 또 다시 발생하였다. 


하루 빨리 EP 프로세스를 수정해 큰 데이터를 처리할 때에도 이런 현상이 발생하지 않도록 개선해야 될 것 같다.


실장님과 커피도 한 잔하면서 데이터엔지니어로써의 방향이나 서로의 생각들을 말하며 즐거운 티타임도 가졌다.


퇴근 후 운동도 열심히 잘했고 이제 어느 정도 리타겟팅 흐름도 머릿속에 쫘~악 그려지고 너무 뿌듯했던 금요일 하루를 보냈다.


오늘의 한마디 '데이터 기반의 광고 시스템은 생각보다 훨씬 매력적이다'


반응형
반응형

오늘은 목요일 25일 월급날^^ 5월은 왜이렇게도 길던지.,.태국여행에 어버이날 자동차 보험 갱신 등등 일들이 굉장히 많았던 것 같다.

무튼 출근해서 광고주들 상품정보가 들어 있는 EP처리 문제에 대해 고민했다. 


XX번가 EP의 경우 상품도 워낙 많고 데이터도 크다 보니(약 18G) EP를 처리해서 HBASE에 매일 BULK INSERT를 하다보니 항상 그 시간에 HBASE의 REGION중 일부가 워닝상태가 되고 데이터노드에서 GC가 발생하다보니 해당 시간에는 정상적으로 리타겟팅이 나가지 못하는 문제에 직면하고 있었다.


이에 생각해 낸게 매일 EP를 새로 밀어넣기 보다는 하루 전날 EP와 DIFF를 떠서 새로 생긴 EP들에 대해서만 UPSERT를 하면 좋을 것 같다는 생각이들었고 맥스 EP 차이를 고려해 1주일 정도 차이가 나는 EP 파일 두개를 스파크로 비교해 보았다.


파일들은 6000만 라인정도 되었고 실제 이 두 파일을 비교해 DIFF를 떠서 OUTPUT파일로 쓰는데에는 4~5분 정도 밖에 시간이 소요되지 않았다. 별다른 튜닝없이도 4~5분만에 끝나는걸 보며 역시 '스파크는 스파크다'라고 생각을 하며 DIFF뜬 파일을 보았더니 약 절반정도 줄어든 것을 확인할 수 있었다. 만약 하루 전 EP와 DIFF를 떴다면 1/10정도로 줄어들지 않았을까 하는 생각이 들었다. 

하지만 안타깝게도 전날 파일이 없어 내일로 미루고 리타겟팅 프로세스 파악에 들어갔는데 뭐가 이리도 복잡한지....


아직 광고에 대한 도메인 KNOWLEDGE도 많이 부족하다는 걸 느낀다. 


해야할 일도 많고 공부할 것도 너무 많고 운동도 열심히해야되고 정말 하루하루가 훅훅 지나가 버린다.

맘편히 일주일정도 카페에 앉아 하고싶은 공부나 실컷했으면 좋겠으려만...


무튼 오늘의 결론은 '인생은 공부의 연속'

반응형
반응형

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


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


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


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


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


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


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


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


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


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


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





반응형

+ Recent posts