2018 아마존(서울) aws 발표 중 좋았던 내용은 community에 있었다...


https://aws.amazon.com/ko/summits/seoul/on-demand/community/


Posted by '김용환'
,




OpenTSDB를 사용하고 있는 모니터링 장비를 개발하고 있다.


모니터링하는 전체 장비 이름(hostname) 목록을 얻어 API에서 suggest할 때 바로 장비 이름이 나오고


"서비스 이름-장비 이름" 매핑에 대한 값을 아주 신속하게 처리할 수 있도록 해야 하는 일이 있었다.


15분짜리 배치 잡을 1초의 배치 잡으로 바꾼 practice를 소개하고자 한다.




OpenTSDB의 아키텍처는 Hbase 기반이고 TSD라는 데몬을 사용하고 있다. 

(특히 downsampling이라는 훌륭한 개념을 탑재하고 있다는 장점을 갖고 있다.  )




1. 문제 해결 #1

15분짜리 배치에서는 OpenTSDB의 suggest API를 통째로 읽어오는 일을 하는 데 10분의 시간이 소요되었다.


http://opentsdb.net/docs/build/html/api_http/suggest.html api는 오래전에 만들어진 플랫폼이라.. pagination이 없다.


이 부분을 OpenTSDB가 아니라 HBase Client Libarary를 사용해 직접 읽고 ES에 저장했다. 


http://opentsdb.net/docs/build/html/user_guide/backends/hbase.html#uid-table-schema


  • metrics for mapping metric names to UIDs
  • tagk for mapping tag names to UIDs
  • tagv for mapping tag values to UIDs.

Within the id column family is a row with a single byte key of \x00



그리고 매번 모두 읽지 않도록 zookeeper에 읽고 난 뒤의 정보를 zk에 저장했다.



2. 문제 해결 #2

opentsdb에 서비스 이름-호스트 이름 매핑 구조를 알 수 있지만, 모든 정보를 다 읽을 수는 없다.


"서비스이름-호스트 이름" 매핑 DB 정보를 따로 읽는 부분이 있었고 소요시간은 2분 30초였다.


이를 모두 DB 커넥션에 매번 읽는 구조가 아닌 Connection Pool을 사용했고 역시 테이블을 사용할 때 읽고 난 뒤의 index를 zookeeper에 저장했다. 


그랬더니. 2분 30초 배치가 0.3초로 줄어들었다.



증분 배치의 개념은 "증분 백업" 개념과 동일하다.





<결론>

문제 해결 #1,#2 보면 Divide & Conquor, 증분(increment) 방식을 사용했다.

(모든 데이터를 읽는 게 최대한 회피한다!!)



그리고 zk에 저장된 데이터에 실제 처리 시간을 작성해 시간이 밀리거나 동작이 안되면 jenkins에서 모니터링 잡에서 노티가 오도록 했다.



chronos를 이용해 30초마다 배치 잡을 돌리는데. 1초만에 배치 잡 동작이 완료되었다.. 







Posted by '김용환'
,