행복한디벨로퍼

데이터 엔지니어로 살아가기 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을 통해 실시간으로 로그를 쏴주는 스크립트를 작성 후 

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

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

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

데이터 엔지니어로 살아가기 100일 째 축하축하?

한 동안 이슈들이 너무 많이 발생해서 정신이 하나도 없었다.

최근 리타겟팅 광고 데이터가 인코딩이 깨져 적재되는 이슈와 관련해 복구작업을 하느라 6월6일 휴일도 반납한채 열심히 복구작업을 진행했다.

문제에 원인은 크론탭으로 jar를 실행할 때 실제 리눅스 시스템 설정파일들을 물고 들어가지 않아서 파일 인코딩 값이 

utf-8이 아닌 다른 값이 들어갔었던 걸로 확인이되었다. 이 부분은 추후에 포스팅으로 남기도록 하겠다.

해당 이슈도 이슈지만 특정 광고주 폰(안드로이드 Galaxy7)에서만 광고텍스트가 깨지는 현상도 발생하는 문제도 있었다.

이부분에 대해서는 좀 더 확인이 필요할 것 같다.

요즘 드는 생각은 시스템 개발도 중요하지만 더 중요한 것은 시스템에 대한 모니터링 그리고 데이터 엔지니어들에게는

데이터에 대한 모니터링이 훨씬 더 중요하다고 생각된다.

하루빨리 실시간 데이터들을 모니터링을 개발해 현재 시스템들에 적용하도록 해야겠다.

매일 블로그에 글을 1나씩 써나가는게 목표인데 요즘 일하랴 운동하랴...정신이 없다.

욕심부리지말고 하루에 글 하나씩이라도 적어볼 수 있도록 습관을 만들어보도록 하자.

6월 한달도 화이팅!

"최고의 제품을 만드는 것 외에 다른 생각을 하는 사람들은 결코 최고의 최고의 제품을 만들지 못한다."

이에 따라 에버노트는 마케팅을 고려 대상에서 제외하고, 그 예산을 모두 제품 개발에 쏟아 부었다. 

이 때문에 처음에는 브랜드가 확실히 느리게 형성되었지만 기대했던 성과를 만들었다.  어떻게 된 것 일까?

에버노트는 지구상에서 최고로 뛰어난 생산성 향상과 노트 작성 애플리케이션이기 때문이다. 

현재 에버노트는 제품 자체가 실질적인 마케팅 수단이다.

[ - 그로스 해킹 중 -  ]

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

오늘 하루는 어제 마무리 짓지 못했던  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도 많이 부족하다는 걸 느낀다. 

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

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

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

오늘은 카프카에서 hdfs로 데이터를 적재하는 카뮤(camus)에 대해서 학습하고 생각해보는 시간을 가졌다.

아직 카뮤? 카뮈? 내부 아키텍쳐가 어떻게 설계되어져 있는지 다 확인하지는 못했지만 카뮈를 이용하면 카프카에서 생각보다 쉽게 hdfs에 적재가 가능하다. 카뮈가 아니였다면? 자바로 카프카 컨슈머를 구현하고 hdfs에 적재하는 로직처리를 해줘야 겠지?

그렇게 어플리케이션을 개발하더라도 카뮤에서 카프카 offset을 확인해 데이터 누락을 최소화해주는 부분에 대한 구현은 힘들었을 것 같다.

물론 자바로도 할수 있겠지만....카프카에서 offset정보를 가져와서 처리할 수 있는 api를 제공하는지는 잘모르겠다.

아무쪼록 좀 더 깊이 파고들어 카뮤를 이해하고 실제로 카프카 토픽의 데이터를 받아오는 작업을 진행해보자!

백문이불여일행