- 돌고 돌아 다시 헬스 시작
헬스장을 원래 1주일에 2~3회는 가다가, 8월에 이용권이 끝나고 나서 잠깐 안가게 되었었다.
대신에, 8~10월 동안 취미로 볼링에 미쳐서 00시만 되면 볼링치러 가고.. 1시간(3~5게임) 치고 자고 출근하고, 이렇게 1주일에 1~2번은 꼭 볼링을 쳤었다.
(왜 늦은 시간인 00시에 볼링을 치냐? 00시에 가면 심야 할인 이벤트로 겜당 비용이 싸진다.. 볼링 비싸..)
새벽 맹 훈련(?) 덕분에 에버리지 120정도였던 실력이 150이상은 되었다.!
한창 볼링 맨처음 배울 때, 친구들한테 돈내면서 배우는거라고 핸디캡 받고 볼링비 내기로 엄청 돈 나갔었는데..이놈들…ㅋ
이제 나도 공짜볼링 칠 준비정도는 된거 같다.
근데 10월 지나니까 날씨가 추워지기 시작하고.. 볼링장이 너무멀어서 점점 안가게 되었다.
결국엔 다시 집근처 헬스장을 끊고 운동 시작..!
- Airflow 테스트 클러스터 환경 구축
저번 회고록에 TODO로 남았었던 Airflow 멀티테넌시 구축 작업을 완료했다.
줌인터넷 5월 ~ 8월 회고 (빅데이터팀)
저번에 이어서 5월 ~ 8월까지의 회고록이다. 이왕 이렇게 된거 3개월 주기로 쓸까 한다~ 5월 ~ 8월은 여러모로 새로운 경험을 많이~ 하는 시기였다. 가장 충격적이였던 경험은.. 평생 살았던 신림역
kangprog.tistory.com
어떻게 구성하려 했는지, 구성하면서의 과정들, 삽질들 블로그에 정리해서 포스팅도 해놨다!.
Airflow 멀티테넌시 환경 구축하기
나 같은 쭈니어 데이터엔지니어가 Airflow 멀티테넌시 환경을 구축하게 될 때, 도움이 되고자 구축했던 경험을 글로 남겨 공유한다.! 회사에서 신규 프로젝트로 Airflow를 처음으로 사용하게 되었다
kangprog.tistory.com
내가 뭘했는지, 어떻게 했는지 나중에 볼 수 있도록 기록하는 용도로 쓰긴했지만,
같은 고민을 하는 누군가에게 조금이나마 도움이 되었으면 하는 바램도 있다.(Airflow 테스트 클러스터 환경 구축에 관련해서 좋은 글들이 많지만…!)
-로그 수집부터 처리, 저장까지 작업
로그 수집, 처리, 저장 개발하는 이슈가 나한테 할당되었다.
이슈 내용은, 새로 출시될 네이티브 앱에서 발생하는 컨텐츠 View 로그들을 가지고, 각 컨텐츠의 인기 순위 TOP10 를 만들어 제공하기다.
신규 앱개발 프로젝트의 인기순위 데이터를 만들기 위해서, 기획 단계, 각 팀간 프로토콜 등
기획자, 앱개발자, 백앤드개발자와 커뮤니케이션하면서 일을 해보는 좋은 기회였다.
내가 했던 일들은,
- 어떻게 로그를 전달, 저장 할 건지?
- 어떤 포맷의 로그를 전송하고 받을 건지?
- 인기순위 데이터의 기준 주기는 어떻게 할건지?
- 인기순위 데이터는 어떻게 만들건지?
- 백앤드팀과 어떻게 API를 개발할건지? 어떻게, 어떤 형태로 인기순위 데이터를 전달할건지?
- 등등등…
아직 개발 진행중이고, 출시되지 않은 앱이여서 결과물에 대한 스크린샷은 없지만,
다음 회고록때는 앱이 출시되어서 내가 개발한 기능을 스크린샷찍어서 올릴 수 있으면 좋겠다.!
-하둡 HDFS 오픈소스 분석
회사에서 운영중인 Hadoop HDFS에서 몇년 전부터 있었던 버그로 보인다.
(이전 담당자가 찾으려다가 찾지 못한 이력이 보임..)
어떤 버그냐면, HDFS, YARN 구성 중 리소스 매니저(RM)와 일부 데이터 노드(DN)가 동작하는 서버에 CLOSE_WAIT 소켓이 점점 쌓이는거다.
하둡 HDFS의 경우 데이터노드에 읽기, 쓰기하는 과정에서 소켓 통신을 하는데, 이 과정에서 무언가 문제가 있는 것으로 보인다.
(하둡 Jira 티켓을 보면, 2.x.x 버전대에서 비슷한 버그가 발생하다가 3.x.x에서는 수정된걸로 보이는데…
우리회사에서 사용하는 하둡은 3.x.x 버전인데도 버그가 발생하고 있다.)
이전 담당자는 버그 발생원인을 찾으려다가 결국, 재부팅해서 CLOSE_WAIT을 없앴던 걸로 보았다…
근본적인 문제 해결을 하기 위해 각 HDFS 프로세스들(NM, RM, DN)의 로그를 보고 몇가지 조치를 취했다.
지금까지 조치를 한 부분은 2가지다.
- 데이터노드의 JVM Heap Size 조절 (데이터노드의 데이터 블록 100만개당 1GB정도 할당)
- Ambari 에이전트 ↔ 리소스 매니저 간 Health Check를 하는데, 리소스 매니저에서 저장하고 있는 완료 작업 기록이 너무 많아서 응답이 느려지는 경우가 있음. 완료 작업 기록의 저장 Limit을 줄임.
하지만 아직 CLOSE_WAIT 소켓은 쌓이고 있고..
그러다 보니 데이터노드의 읽기, 쓰기 오픈 소스를 보며 상세 동작을 파악하는 중이다.
지금까지 파악된 걸 잠깐 써보자면..
데이터노드에 데이터를 쓰는 과정 중에 다른 데이터노드와 소켓 연결을 맺고 데이터 블록을 전송하는데(replication)
이 과정에서 데이터 노드간 broken pipe가 발생했고, 주 원인은 EOF(end of file), OOM(out of memory)였다.
데이터 노드간 CLOSE_WAIT이 발생하는 문제는 데이터 노드의 JVM Heap Size를 조절해서 해결되었다.
근데 문제는, 리소스매니저와 데이터노드간에 발생하는 CLOSE_WAIT이다.
이부분은 아직 시간날때마다 오픈소스를 보고있는 중이다.
"핵고수가 나타나서 이거 때문에 발생하는 에러에요. 이거 관련해서 찾아보고, 수정하면되요. 라고 해주면 좋겠다.."