행복한디벨로퍼

하둡 클러스터를 운영하다보면 데이터 노드마다 데이터 분포의 불균형 상태가 생길 수 있는데 이 때 실행시켜주어야 하는 작업이 '밸런서(balancer)'이다.

밸런서(balancer)에 대한 내용을 포스팅 해보겠다. 해당 내용은 '하둡 완벽 가이드(4판)'을 정리한 내용이다.

[ 하둡 밸런서 ] 

하둡 클러스터는 시간이 지남에 따라 데이터노드 사이의 블록의 분포는 불균형 상태가 될 수 있고 불균형 상태의 클러스터는 맵리듀스의 지역성(locality)에 영향을 받게 되므로 자주 사용되는 데이터노드에 큰 부하를 주게 된다. 따라서 불균형 상태가 되지 않도록 해야 한다.

밸런서란?

밸런서 프로그램은 블록을 재분배하기 위해 사용률이 높은 데이터노드의 블록을 사용률이 낮은 데이터노드로 옮기는 하둡 데몬이다. 블록 복제본을 다른 랙에 두어서 데이터 유실을 방지하는 블록 복제본 배치 정책은 그대로 고수한다. 밸런서는 클러스터가 균형 상태가 될 때까지 블록을 이동시킨다. 여기서 균형 상태란 각 데이터노드의 사용률(노드의 총 가용 공간과 사용된 공간의 비율)이 클러스터의 사용률(클러스터의 총 가용 공간과 사용된 공간의 비율)과 비교하여 지정된 임계치 비율 이내일 때를 의미한다. 

밸런서는 다음과 같이 실행할 수 있다.

-threshold 인자에는 클러스터의 균형 상태를 의미하는 임계치 비율을 지정한다. 이 플래그는 선택사항이며, 지정하지 않으면 임계치는 10%다. 클러스터에는 오직 하나의 밸런서만 실행될 수 있다. 

밸런서는 클러스터가 균형 상태가 될 때까지 수행된다. 더 이상 블록을 이동시킬 수 없거나 네임노드와 통신이 단절될 수 있기 때문에 표준 로그 디렉터리에 로그파일을 생성하고 재분배 작업이 순환될 때마다 기록을 남긴다. 아래는 작은 클러스터에서 아주 짧은 시간 동안 밸런서를 실행한 결과다.

밸런서는 클러스터에 부담을 주는가???

밸런서는 클러스터에 과도한 부하를 주지 않고 클러스터를 사용하는 다른 클라이언트에 방해가 되지 않기 위해 백그라운드로 실행되도록 설계되었다. 밸런서는 한 노드에서 다른 노드로 블록을 복제할 때 필요한 대역폭을 제한할 수 있다. 기본값은 1MB/s지만 hdfs-site.xml 파일의 dfs.datanode.balance.bandwidthPerSec 속성에 바이트 단위로 값을 지정하면 대역폭을 변경할 수 있다. (대역폭을 늘린 순 있겠지만 늘리게 되면 클러스터에 미치는 영향이 커질 수 있음을 주의하자.)

실제로 경험상 밸런서를 실행하면 생각보다 수행시간이 오래걸린다.(20대 하둡 클러스터 기준) 하루 이상은 걸렸던 걸로 기억한다.

읽어 주셔서 감사합니다.

데이터 엔지니어로 살아가기 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가 존재해 작업을 해준다는 것이다.

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

데이터 엔지니어로 살아가기 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는 뗄래야 뗄 수 없는 관계

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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