행복한디벨로퍼

2018년 개발자 라이프 회고 (데이터엔지니어)

앞으로 조금 귀찮고 힘들더라도 개발자로서 한 해를 마무리하는 글과 새해 목표에 대해서 남겨보려고 한다.

크게 전공관련 목표는 네 가지 정도로 세웠던 것 같다.

1. 블로그 꾸준히 운영하기

일년동안 총 56개의 기술포스팅을 진행했다. 목표치에는 부족했지만 꾸준히 쓰려고 노력했다. 예전 포스팅을 너무 잘작성하려는 욕심 때문인지 어느 순간부터 글쓰는데 대한 부담감을 느끼고 한동안 글을 쓰지 않았던 적이 있다. 그 이후로 네이버 블로그에서 티스토리로 넘어오면서는 너무 포스팅을 잘하려고?심도있게 잘 작성해야한다는 압박으로부터 벗어나 간단하게라도 포스팅을 하자라고 생각이 바뀌었다. 포스팅에 대한 부담감을 느끼지 않고 꾸준히 하는것이 중요하다고 생각했기 때문이다. 주로 실무에서 삽질한 경험, 새롭게 알게된 지식, 책 학습을 통한 내용을 포스팅했다. 내년에는 IT기술 및 개발자의 삶 전반에 대한 고찰과 생각들도 글로 써보고 싶다. 

일년동안 3만 명이 넘는 분들이 블로그에 방문해 주셨고 총 4만5천 페이지 뷰가 발생하였다. 아무래도 심도있는 포스팅이 많지 않고 다른 연관관계에 있는 글들이 많지 않아 방문자수에 비해 페이지수가 낮게 집계된 듯 하다. 앞으로는 연관 포스팅에는 링크도 걸고 포스팅의 질도 높여 세션시간과 방문자수 대비 페이지뷰가 더 늘어날 수 있도록 실행해 보아야겠다. 내가 다른 분들의 블로그들을 통해 도움을 받고 지식을 얻듯 다른 분들도 내 블로그를 통해 도움을 받을 수 있다면 좋겠다.

2. 토이프로젝트 운영하고 광고수익 창출하기

실제로 토이프로젝트를 운영해보고 싶다는 생각은 일을 시작하고 2년차쯤부터 계속해서 가지고 있었다. 그 생각이후 2년 후에 실행하게 된데 대해 반성해본다. 지금은 개발자로 일한지 5년차이다. 토이프로젝트로 무엇을 만들어볼까 하다가 2018년 초기 당시 열풍이 불었던 코인정보들을 한데 모아 보여주는 사이트를 운영해보면 재미있을 것 같다는 생각이 들었다. 그렇게 2018년 1월 중순 회사퇴근하고 새벽 2~3시까지 개발을 했고 약 2주 정도에 걸쳐 사이트를 완성하고 오픈하게 되었다. 최대한 페이지 정보를 가리지 않는선에서 광고도 달아보았다. 그렇게 구글 애드센스를 통해 벌어들인 수익은 약 700달러 정도 되었고 중간에 페이지에 배너광고를 달고 싶다는 요청에 30만원을 받고 게재를 해주었다. 

돈의 액수를 떠나 토이프로젝트를 통한 광고 수익이 발생했다는 것에 가장큰 기쁨을 느꼈다. 그리고 사이트를 운영하는 것은 생각보다 더 힘들다는 것과 홍보 및 마케팅 분야에 대한 중요성에 대해서도 느끼게 된 경험이였다. 2018년에는 또 다른 토이프로젝트를 진행해 볼 생각이다.

3. 개발자들을 위한 컨텐츠 제작

외국에는 개발자들을 위한 유머? 컨텐츠들이 많은 것 같은데 국내에서는 많이 보지 못한것 같아 운영해보고 싶다는 생각이 들었다. 그리고 나 자체가 좀 엉뚱한 생각을 많이하기도 하고 내가 괜찮다고 생각이드는 아이디어가 남들에게는 어떻게 반응할지에 대해 궁금하기도 하였다. 인스타 계정 @happydeveloper 을 새로 하나 만들고 현재 계속해서 운영중이다. 욕심 부리지 않고 내 머릿속에 있는 생각들을 조금씩 컨텐츠로 만들어나가도록 해야겠다.

4. Scala, Spark에 대한 심도 있는 학습

사실 제일 아쉬운 부분이 이부분이다ㅎㅎ생각만큼 스칼라공부를 심도 있게 하지 못했고 기존 운영하던 Spark프로젝트를 계속해서 유지보수하고 기능을 추가하였지만 애초 목표였던 java spark -> scala spark으로 프로젝트를 변경해보지 못했다. 일단 이 부분은 업무의 영역과도 관련있기 때문에 내 마음대로 진행하지 못한 점이 크지만 많이 아쉬움으로 남는다. 공부는 끝이 없다....내년에는 scala도 좋지만 원초적인 프로그래밍에 필요한 기본적인 지식들을 좀 더 심도있게 쌓는데 중점을 두고 싶다.

이렇게 2018년도 가고 내일이면 2019년의 시작이다. 2018년 개인적으로 굉장히 다사다난한 일들이 많이 발생했었다. 그럼에도 불구하고 이정도의 실행을 할 수 있었던 건 연초에 목표를 세우고 눈에 보이는 곳에 항상 붙여놓았던 부분이 크다고 생각한다. 2019년 목표도 정리해서 포스팅 할 수 있도록 해야겠다. 

'어디로 가고 있는지 모르고 있다면, 결국 가고 싶지 않은 곳으로 간다.'

긴 글 읽어주셔서 감사합니다.

스파크와 맵리듀스  성능차이 그리고 엘라스틱서치

최근 업무하면서 경험했던 이슈들에 대해서 정리해볼까 한다.

Episode1. 스파크(Spark)와 하둡 스트리밍 MR작업의 성능 이슈

함께 업무를 하던 과장님께서 하둡 맵리듀스로 된 작업을 스파크로 변경하셨었다.

그런데 스파크로 코드를 작성하고 테스를 하시더니 맵리듀스 보다 1분 30초나 느리다는 것이다.

이 무슨 말이란 말인가??? 스파크가 하둡MR 보다 성능이안나온다니!

그래서 함께 코드를 봤더니 코드는 뭐 딱히 문제가 될 만한 부분도 없을만큼 단순한 코드였다.

단순히 파일을 rdd로 읽어서 parsing해서 결과파일을 쓰는....

그래서 다시 과장님이 스파크 어플리케이션을 돌리실동안 클라우데라에 들어가 잡이 돌아가는 상황을

Application Master로 보았더니 굉장히 많은 shuffle이 일어나고 있었고 순간 spark-submit할 때

어떤 옵션들이 들어있는지에 대한 의문이 들었다.

확인을 해보니….하둡 스트리밍 MR작업을 돌릴 때는

해당 옵션이 있었고 새로만든 스파크 작업에는 해당 옵션을 주지 않고 spark-submit이 이루어졌던 것이다.

결과적으로 하둡 스트리밍MR은 클러스터의 사용가능한 충분한 executor를 사용하여 작업이 이루어진 반면에

스파크작업은 10개 이내의 executor들을 사용해 작업이 진행되었던 것이다.

같은 옵션을 주고 다시 테스트를 해보니 당연히 스파크의 승리!!! 약 20초정도 더 빨랐던 것 같다. 

데이터가 커지고 로직이 더 복작해지면 질수록 이 성능은 더 차이가 많이 나지 않을까 생각한다.

Episode2. 엘라스틱서치(elastic search)와 키바나(cabana)

최근 데이터 유입쪽과 카프카-camus를 통해 hdfs 적재되는 데이터량을 쉽게 확인할 수 있는 시스템?을 개발하였다.

기존에는 데이터유입부분과 실제 hdfs에 데이터가 적재되는 양을 비교할 수 없어 데이터가 정상적으로 유입부터 적재까지

이루어지고 있는지 확인할 수 있는 방법이 없었다. 가 아니라 실제 데이터들을 다 까서 로그들의 개수를 읽어서 매칭시켜보는 방법이 있었다....(노가다...)

따라서 이부분에 대한 모니터링 작업이 필요한 상황이였다.

그래서 파이썬스크립트로 데이터유입서버와 hdfs에 적재되는 커맨드 서버에서 로그파일의 row수를 세서 시간별로 데이터 row count를 

엘라스틱서치(elastic search)에 적재하도록 하였다. 이렇게 쌓인 데이터는 키바나(kibana)를 통해 쉽게 시각화할 수 있게 함으로써 

편하게 확인할 수 있도록 작업을 진행하였다.

작업을 진행하면서 느낀것은 역시 써보지 않은 tool을 사용해 작업을 하는 것은 쉽지 않고 간단한 작업이라도 꽤나 시간을 많이 잡아 먹는다는 것이다.

하지만 새로운 도구를 경험하고 사용하면서 경험적인 측면에서 한 단계 성장해나가는 것 같은 기분이들어 좋았다.

생각보다 elasticsearch-kibana 를 사용하는데 많이 힘들진 않았지만 elastic search 인덱스를 만드는 부분과 kibana에서

index=true로 되어있지 않은 데이터들에 대해서는 그래프의 지표로 쓸수 없다는 부분을 깨닫는데까지 많은 삽질을 했던게 가장 기억에 남는다.

앞으로도 사용하고 있는 tool, framework에만 의존하기 보다는 다양한 도전과 시도를 통해 여러 문제에 대해 적합한 솔루션을 제공할 수 있도록

항상 여러 기술에 관심을 가지고 사용해볼 수 있도록 노력해야겠다는 생각이 들었다.

엘라스틱서치(ElasticSearch)와 키바나(Kibana)

데이터를 다루는 사람이라면 한번쯤은 ELK(ElasticSeach + LogStash + Kibana)를 들어봤거나 다루고 있을 것이다.

내가 지금 만지고 있는 시스템에서는 nginx, fluentd, kafka, cassandra로 데이터를 처리하고 있다보니 ELK를 다룰 기회가 없었다. 

최근 nginx를 통해 유입되는 데이터량과 카프카 + 카뮈(camus, 카프카에서 hdfs로 데이터를 배치로 옮겨주는 역할)의 데이터량에 대한 

모니터링이 필요할 것 같다는 생각이 들었다. 

뭐 금방하겠지 생각하고 로컬에 엘라스틱서치(ElasticSearch), Kibana설치하고 데이터 놓고 그래프 그리려는데 생각보다는 쉽지 않았다.

엘라스틱서치(ElasticSearch)과 키바나(Kibana) 설치 및 실행까지는 굉장히 쉬웠고 단조롭게 진행되었다.

curl로 엘라스틱서치(ElasticSearch)에 데이터를 넣고 키바나로 그래프를 그리는 부분에서 많은 시간을 소모하게 되었다.

아무래도 누군가의 설명과 도움없이 진행하다보니 시행착오를 많이 겪었다.

결국 내가 원하는대로 데이터를 넣고 그래프를 넣는데 까지는 성공을 했지만 

좀 더 효율적으로 엘라스틱서치(ElasticSearch)와 키바나를 사용하기 위해서는 학습이 필요하겠다라는 생각이 들었다.

앞으로 엘라스틱서치(ElasticSearch)와 좀 더 가까워 질 것 같다는 느낌이 들었고 

짧게 만져봤지만 앞으로 새로 구축하는 시스템에는 검색 및 데이터스토리지로도 활용하는 것도 굉장히 좋을 것 같다는 생각이 들었다.

일단 책부터 지르자~gogo!!!

데이터 엔지니어로 살아가기 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작업에 집중할 수 있겠다:)

데이터 엔지니어로 살아가기 135일째(카산드라) - 0713목요일

역시 꾸준한게 제일 어려운 것 같다...못해도 3일에 한번씩은 기록하고자 마음먹었는데 생각보다 쉽지 않다.

그래도 잊지말고 앞으로라도 꾸준히 써나가도록 하자.

최근에는 알파 환경에서 리얼환경처럼 데이터가 유입되도록 하는 작업을 진행했었다.

실제 데이터 파이프라인은 구축이 되어있었지만 알파환경에서는 작동하는 태그매니저들이 없기 때문에

데이터가 실제로 유입이되지 않고 있었고 데이터가 없어 spark job들에 대해서도 매번 테스트하기가 너무 힘들었다.

이럴거면 알파환경을 도대체 왜쓰는가? 서버비 아깝게...

그래서 실제 리얼 태그매니저들을 통해 들어오는 데이터의 일부를 rsync로 알파서버에 daily로 받아오게 하여

알파 수집서버로 api를 호출하도록 작업하였다.

요즘은 CustomTargeting 프로젝트를 진행하고 있다.

기획부터 시스템설계까지 진행을 하고 있고 구글의 빅쿼리를 모티베이션 삼아 진행하고 있다.

관심사 추출하는 로직과 기존 클러스터 환경상 java7로 스파크작업을 하는데 삽질을 많이 하고 있긴 하지만

스칼라로 작업을 할 때보다 map, flatmap 등 연산작업들의 내부 구현에 대해 좀더 자세히 배우고 있는 느낌이든다.

요즘은 일하는게 너무 재밌어서 시간가는 줄 모르고 일하는 것 같다.

일도 일이지만 데이터 처리하는 기술들에 대해 공부에 대한 욕심도 많이 생긴다.

너무 욕심부리지 말고 천천히 꾸준히 일도 공부도 운동도 열심히 하도록 하자~!

데이터 엔지니어로 살아가기 113일째(카산드라) - 0621

실시간으로 데이터를 처리해서 카산드라에 밀어넣고 있는데 알파에 같은 환경을 구축해서 데이터파이프라인 구축하는게 생각보다 너무 오래걸리고 있다. 그동안 알파환경이 관리가 제대로 되고 있지 않아 생각보다 여러가지 문제들에 부딪히며 해결하고 있는 중이다.

오늘 실시간 잡 로그를 보던 중 마이크로배치(10초)단위로 데이터를 읽어와 처리할 때마다 카산드라 커넥션을 맺었다 끊는 작업을 하고 있었다. 당연히 커넥션풀을 이용해 처리가 될 줄 알았는데...

무튼 알파환경에서도 리얼 환경과 동일한 데이터 파이프라인을 구축해 실제 테스트를 진행할 수 있도록 해야겠다.

알파환경이 구축되는 대로 카산드라와 HBASE에 대한 학습이 좀 더 체계적으로 필요할 듯 싶다.