행복한디벨로퍼

데이터 엔지니어로 살아가기 229일째(데이터야놀자 컨퍼런스 후기) 

오늘은 이틀전(20171013, 금요일)에 다녀온 '데이터야놀자' 컨퍼런스에 다녀온 후기에 대해서 작성하려고 한다.

먼저 '데이터야놀자' 컨퍼런스를 통해 크게 느낀점 네가지를 정리하자면 다음과 같다.

하루 종일 30분 정도로 진행되는 11개의 세션들을 들으며 많은 생각이 들었지만 그 중 핵심적인 생각은 위의 4가지로 요약할 수 있을 것 같다.

먼저 '데이터야놀자'라는 컨퍼런스는 데이터를 다루는 사람들의 소통의 장을 마련하고 축제의 분위기를 만들고 싶어하는 것 같았다.

그에 따라 세션이후에는 공연도 준비가 되어있었고 다양한 종류의 간식거리 및 맥주를 무료 제공하였다.

내가 들은 11개의 세션 중 가장 기억에 남았던 3개의 세션에 대해서 얘기해보려고 한다.

먼저 첫 번째 세션은 라인게임즈의 '백정상'님이 발표했던 "쌓는다고 다 데이터인가? (로그 맛깔나게 쌓는 방법)" 이다.

세션의 주제를 잘 정해서인지 많은 수의 인원들이 해당 세션을 듣기 위해 자리를 빈틈없이 꽉꽉 채웠다.

역시 주제 선정이 중요성에 대해서 다시 한 번 느끼게 되었다.

해당 세션에서 그 동안 경험했던 타부서팀들과의 경험담을 유쾌하게 잘 설명해주셨고 무작정 쌓은 데이터들과 잘 선별해 쌓은 데이터의 차이를

쓰레기수거장과 분리수거통의 사진으로 비유해 설명해주신게 특히 맘에 와닿았다. 

한 마디로 요약하자면 '데이터를 쌓을 때 어떤 데이터를 어떻게 활용할 것인지에 대해 생각해보는 것이 중요하다'는 내용이 주를 이루었다.

인상깊었던 두 번째 세션은 카카오 선물하기 팀의 '전수현'님이 발표해준 "커머스 로그 통합 시스템"이였다.

여자 발표자 분이라서 그런지 발표하는 내내 상당히 부드러운 느낌을 많이 받았고 중간중간 떠는 모습, 거기에 대해 솔직하게 토로하시는 부분에 

대해 굉장히 인간적인 면모를 많이 느꼈고 유쾌한 웃음과 솔직한 모습은 세션공간의 개발자들간의 경계를 많이 허물어 주셨다.

그리고 현재 내가 하고 있는 업무의 내용과 가장 비슷한 내용들이라서 더 집중하며 들었던 것 같다.

해당 세션에서 새롭게 알게 된 내용으로는 Apache Nifi가 있었는데 현재 우리 시스템에서 kafka to hdfs, monitoring을 담당해주는 새로운 대안

이 될 수 있을 것 같다는 생각이들었다. 

마지막 세번째 세션으로는 현재 구글에 계시는 조대협님의 '머신러닝 무엇이 중요한가?'라는 주제의 세션이였다.

솔직히 해당 세션에 대한 궁금증보다는 '조대협'님 자체가 너무 궁금했다. 개발을 하는 분이라면 한번쯤은 그의 블로그를 접해봤을거라는 생각이 

든다. 나 또한 하루에도 여러번 조대협 님의 블로그를 방문하고 글을 읽어 왔기 때문에 그 분의 말하는 방식 생각이 너무 궁금해 묻지도 따지지도 

않고 해당 세션을 들었다. 블로그 글들만 봤을 때는 기술에만 관심있는 기술쟁이라는 생각이 들었지만 의외로 말씀도 굉장히 유쾌하게 하시고 

ppt구성이나 발표능력도 상당히 수준급이라는 느낌을 받았다. 그리고 항상 말에는 자신감이 있었고 질문을 하기 힘든 답변에는 시원하게 

'그건 해봐야 안다. 잘모르겠다'라는 말을 서스럼 없이 하는 모습에  신뢰감이 들었다...보통은 연사자가 저런 답을 하면 신뢰감이 떨어지기 

마련인데 그 동안 접해왔던 조대협님의 여러 기술을 주제로한 글들로 인해 '저 사람은 대단한 사람'이라는 생각이 이미 스며들었는지도 모른다.  

어찌되었든 조대협님의 세션을 들으며 나도 그와 같이 추후에는 다른 기업에 '컨설팅'도 다니고 기술적인 부분에도 연사로 서있는 나의 모습을 

상상하게 되었다. 그러기 위해 꾸준히 학습하고 배우는 것들에 대한 블로깅, 끊임없이 배우려는 노력, 지속적인 목표 설정과 실천이 

가장 중요하다는 생각이 든다.

마지막으로 이번 '데이터야놀자' 컨퍼런스의 세션들을 들으며 기술적으로 더 학습해야겠다고 느낀 항목들을 적어본다.

항상 이런 컨퍼런스들에 관심을 가지고 참여할 수 있도록 하자. 일상에 큰 활력을 불어넣어준 하루였다.

아! 그리고 마지막으로 '데이터야놀자' 세션을 들으며 스스로 다짐했던 내가 듣는 세션에 '질문 꼭 하나씩 하기' 목표를 실천해서 뿌듯하다:)

데이터 엔지니어로 살아가기 198일째(실시간 타겟팅 모니터링 시스템)

기존에 실시간으로 스트림으로 처리되고 있는 관심사, 리타겟팅의 경우 실제로 데이터가 잘들어갔는지 확인 할 수 있는 방법이 없었다.

데이터저장소로 카산드라를 사용하고 있는데 카산드라에서는 mysql처럼 테이블의 데이터 count를 쿼리로 확인하기 힘들다.

따라서 실시간타겟팅들이 정상적으로 동작을 안하고 있는 경우에도 알아차리기 힘들다는 문제가 있었다.

매번 타 부서를 통해 '정상적으로 리타겟팅이 안되는 것 같다' 라는 요청이 오는 경우에 한해 확인해보고 있었고

심각한 경우 하루 이상 실시간 리타겟팅 데이터가 카산드라에 적재되지 않았던 적도 있었다...

이런 문제를 해결하고자 한 시간 단위로 실시간 타겟팅에서 사용하는 데이터를 hdfs에서 가져와 실제로 들어가있는지

샘플로 몇개만 추출해 확인하는 시스템을 만드는 작업을 하였다.

이번 작업을 하며 느낀점은 항상 어떤 시스템을 만들때 만들었다는 그 자체보다는 정상적으로 시스템이 돌아가고 있는지에 대한

모니터링이 잘 작동하고 문제 발생 시 이를 감지할 수 있는 장치가 마련되어있어야 한다는 것이다.

그렇지 않고서는 좋은 시스템이라고 절대 말할 수 없을 것 같다.

꾸준히 포스팅을 하고 싶은데 마음처럼 쉽지 않다. 아마 막상 쓰게 되면 잘써야한다는 심리적 부담감이 어느 정도 작용하는 듯도 하다.

앞으로는 간단하게라도 자주 내 발자취를 기록해 나가도록 해야겠다.

먼 후에 봤을 때 좋은 기억 추억이 될 수 있도록...

아 그리고 오늘 새롭게 안사실은 Hadoop Balancer말고 Disk Balancer가 따로 존재한다는 사실이다.

Hadoop Balancer는 데이터 노드들간의 블럭정도를 balancing해주는 역할을 하고 해당 데이터노드에서 디스크간 balancing을 해주는 역할은

별도의 disk balancer가 존재해 작업을 해준다는 것이다.

이 부분은 나중에 기회가 되면 포스팅을 하도록 하겠다.

데이터 엔지니어로 살아가기 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을 검토해보면 좋을 듯 싶다.

이상~

데이터 엔지니어로 살아가기 149일째(spark2.1.1) 

오늘 문득 spark2.1.1버전에서 java8 람다식을 활용한 데이터 처리 속도와 

spark1.5(현재 클러스터에서 사용버전)에서 java7을 통한 spark 데이터 처리 속도가 얼마나 나는지 궁금해졌다.

덤으로 scala spark이 동일한 데이터 처리 프로세스를 가지고 spark1.5, spark2.1.1버전에서 돌았을 때 성능도 궁금해져

간단히 70만 라인의 텍스트 파일로 파싱하고 필터링 처리를 하고 text파일과 orc파일로 변환해 적재하는 테스트를 진행하였다.

아직 scala를 spark2.1.1에서 테스트하는 부분은 확인하진 못했지만 확실히 spark2.1.1대 버전에서 java8 람다식을 활용해 처리하는 것

이 제일 빨랐다. 이부분은 좀더 테스트 후 포스팅 하도록 하겠다.

그리고 오전에는 딥러닝에 대한 세미나를 들었다. 세미나 발표를 통해 큰 깨달음이나 감명을 받진 못했지만

꾸준히 관심을 가지고 학습해 추후에 지금 처리하고 있는 데이터들에도 적용할 수 있는 방법을 연구해보면 좋을 것 같다.

아 그리고 틈틈히 scala공부도 하도록하자!

데이터 엔지니어로 살아가기 143일째(커스텀타겟팅) - 0721금요일

광고주 태그매니저에서 들어오는 데이터들을 orc로 적재하는 작업을 마무리하였다.

camus를 통해 kafka에서 데이터를 가져와 매시간 데이터를 적재하고 있지만

커스텀타겟팅에 사용하기에는 부적합하다는 판단에 orc로 적재하기로 결정하였다.

작업을 완료하기까지 많은 수행착오를 겪었다. 인입되는 로그에서 실제 bid별 관심사를

추출해 적재하기로 사전에 얘기가 되었지만 실제로 작업을 완료하고 확인해보니 

생각보다 관심사를 추출하는 부분에서 처리시간이 많이 소모되었다. 

관심사 추출 후 date, action별로 partitioning하여 적재하는 시간이 단순 컬럼으로만 분리해서

적재했을 때의 시간보다 15배정도의 시간이 더 걸렸다.t.t

결국에는 일단 orc로 적재한 후 관심사 데이터가 필요할 경우 bid별 관심사 추출데이터와

join해서 사용하는 편이 리소스 활용측면이나 확장성 측면에서 더 효율적이겠다는 결정을 내렸고 

scala spark으로 다시 orc 적재하도록 마무리하였다.

orc적재 작업을 진행하면서 java-spark에 어느정도 더 익숙해졌고 관심사 추출로직에 대해

심도있게 파악할 수 있었다는 점에서 삽질도 많이했지만 좋은 기회가 되었던 것 같다.

이제 실제 커스텀타겟팅 메인 프로젝트 작업에 슬슬 시동을 걸어봐야겠다~

아! 그리고 틈틈히 scala공부를 하도록하자~scala 와 spark는 뗄래야 뗄 수 없는 관계

데이터 엔지니어로 살아가기 140일째(커스텀타겟팅) - 0718화요일

저번주 후반부터 이번주 계속해서 광고주 데이터를 orc로 적재하는 프로젝트 작업을 진행하고 있다.

단순 로그를 orc로 적재하는라면 scala spark을 통해서 쉽게 할 수 있겠지만 tag manager를 통해

유입된 요청들의 url에 매핑되어 있는 상품정보들을 형태소 분석기를 통해 관심사 번호와 매핑작업이 필요하기에

scala spark으로 작업을 진행 할 수 없었다. 

형태소 분석모듈과 관심사를 뽑아내는 로직이 자바로 되어져 있었기에 자바스파크로 작업을 진행중이다.

현재 관심사 추출 후 orc 적재하는 프로젝트가 80%이상 완성이 되었고 그 이후 spark sql을 통해

Custom Targeting을 진행할 메인 프로젝트 진행이 필요한 상황이다.

구글의 빅쿼리와 같이 쿼리 한번으로 사업측이나 기획측이 타겟팅하고 싶어하는 대상들의 uv를 뽑아내는 것이

목표이기 때문에 UI, 요청 처리하는 프로세스, API등 생각해봐야 할 문제들이 한 두 가지가 아니다.

오늘 하루 집에오는 길 내내 어떻게 시스템 구성 및 전체적인 custom타겟팅의 처리 flow들에 대해서 생각했던 것 같다.

그만큼 할 일은 많지만 요즘은 일이 너무 재밌다.

좀 더 불태워보자 화이팅:)