반응형

[ 100번의 도전 ] 운동&식단 일지 (170531-하체운동)


하체운동


하체는 힘들어....


레그익스텐션(3), 스쿼트(5), 레그프레스(5), 레그컬(3), 레그익스텐션(3)



반응형
반응형

[ 100번의 도전 ] 운동&식단 일지 (170530-1일차)


시작이 반이다


가슴운동, 삼두운동



반응형
반응형

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

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


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

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


반응형
반응형

큐잉 시스템과 카프카가 다른점

분명히 카프카는 메시지들이 수신된 순서대로 처리되도록 보장하기 위해 많은 문제를 겪는 ActiveMQ나 RabbitMQ 같은 큐잉 시스템이 아니다.

카프카의 파티셔닝 시스템은 이런 구조를 유지하지 않는다. 특정한 토픽의 파티션에 대한 쓰기와 읽기 순서에 대한 정의가 없으므로 클라이언트는 메시지가 쓰여진 순서와 다르게 파티션에서 읽을 수도 있다. 게다가 생산자를 비동기로 구현하는 일이 흔해서 한 파티션으로 보내진 메시지는 (비록 응답대기시간이나 비결정적 이벤트의 차이로 인해 먼저 발생하더라도) 또 다른 파티션으로 보내진 메시지 이후에 쓰여질 수도 있다.


카프카는 또한 메시지 소비자를 다루는 방법에서도 많은 큐잉 시스템과는 다르다. 대부분의 큐잉 시스템에서 메시지는 소비되었을 때 시스템에서 제거된다. 카프카는 메시지를 제거하는 메커니즘이 없는 대신, 소비한 마지막 메시지의 오프셋을 지속적으로 파악하기 위해 소비자에 의존한다. 로그는 카프카 설정의 log.retention.hours 설정에 의해 삭제된다.


[ 참고 ] 실시간 분석의 모든 것


반응형

'Bigdata > Kafka' 카테고리의 다른 글

카프카(KAFKA) 데이터 처리방식의 특화된 기능  (1) 2017.08.30
반응형

인프라 없는 알고리즘은 (아마도) 흥미로운 연구 논문은 될 수 있어도 완성된 시스템이 될 수는 없다.

애플리케이션 없는 인프라는 대부분 자원의 낭비일 뿐이다.


- 실시간 분석의 모든 것 중-


데이터를 다양한 사용자에게 제공해 줄 수 있는 애플리케이션과

신속하게 사용자들이 원하는 데이터들을 ETL 할 수 있는 체계적인 인프라 시스템이

구축되어 있을 때 비로서 성공적인 프로젝트?가 되리라 생각한다.


반응형
반응형

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


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


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


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


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


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


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


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


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


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


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


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


6월 한달도 화이팅!

반응형
반응형

그로스 해킹을 읽고 내 나름대로 '그로스 해킹(Growth Hacking)'에 대해서 정의해보았다.


내가 정의하는 Growth Hacking이란?

기존의 보편화된 마케팅 방식(단순한 TV, 신문, 미디어)등을 벗어나 사용자들의 피드백 데이터 혹은 시장반응 지표들을 통해

새로운 인사이트를 도출하고 다양한 방식과 참신한 시도들을 통해 ROI(Return On Investment)를 높이고 새로운 가치를 만들어 내는 행위


뭐 다른 책이나 기사들을 읽다보면 또 다른 해석들이 존재하겠지만

내 나름의 생각을 정리해보는건 참 좋은 일인 것 같다.


반응형

+ Recent posts