행복한디벨로퍼

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

데이터 엔지니어로 살아가기 112일째(분산환경 로깅)

spark yarn-cluster에서 돌아가고 있는 실시간 작업들에 대한 로깅이 정상적으로 log4j파일의 위치에 남지 않아 한참을 헤맸다.

실제로는 분산환경에서는 작업 뿐만아니라 로깅또한 driver와 각 executor가 동작하는 데이터노느들에 분산되어 저장되게 된다.

yarn logs -applicationId (appilicationId) 를 통해서 확인을 할 수 있었지만 실제로 오랫동안 실시간으로 돌아가고 있는

시스템에 대한 로그들이 워낙 큰고 빠르게 쌓이기 때문에 확인하기가 어려웠다.

그리고 왜 실제로그는 실시간 어플리케이션이 실행될 때 한 번만 찍히고 이 후 동작하는 stream들에 대해서는

로그가 안남는것인지 원인을 찾지 못하였다.

아직 갈길이 험난하고도 먼 것 같다.

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

오늘은 어제 미처 다 끝내지 못한 프로젝트 로컬셋팅 및 배포 프로세스를 잡는데 대부분의 시간을 할애했다.

관심사 타겟팅의 프로젝트의 경우 submodule로 카산드라에 벌크업로드를 하는 프로젝트가 물려있어 생각보다 셋팅 후 배포 프로세스를 만드는데 까지 시간이 오래 걸렸다. 

submodule인 카산드라 벌크업로드 프로젝트의 경우 maven dependency에서 사용하는 하둡 라이브러리들이 알파와 리얼에 jar로 묶여 있어 로컬에서 빌드를 따로 수행하지 못하고 소스코드만 배포 시스템으로 그대로 서버로 옮겨놓은 후 해당 서버에서 직접 'mvn package'명령을 주어 빌드를 실행해주어야 했다.

간만에 젠킨스 셋팅부터 시작해서 사내 배포시스템을 사용하여 빌드 배포를 쉽게할 수 있도록 작업하였다.

그 후에 시간이 좀 남아 실시간 스트리밍 spark job중에 log4j가 프로젝트에 셋팅되어있는데 실제로 로그가 남지 않아 해당 이슈를 찾아보다가 해결을 하지 못하고 오늘 하루를 마무리 하였다. 내일 출근하자마자 관련 부분 확인해서 처리하고 알파에서도 데이터 파이프라인에 데이터들이 실시간으로 흘러다닐 수 있는 환경을 구축하도록 해야겠다.

갈수록 배움의 즐거움이 커진다.

데이터 엔지니어로 살아가기 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도 많이 부족하다는 걸 느낀다. 

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

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

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