[DEMO]
[동기]
모 앱스토어에서 결제시스템을 운영하면서 크고작은 많은 문제들이 발생을 하였고,
제니퍼와 같은 기존의 서버 모니터링 툴로는 위험 상황을 감지하기 힘든 상황이 계속해서 발생하게 됩니다.
[운영 장애 사고의 유형]
- 예측하기 힘든 트래픽
- 자동화된 툴 혹은 인위적인 서비스 취약점 공격
[요구사항 원칙]
- 앱스토어를 통해 배포된 앱별로 모니터링이 가능할 것
- 배포된 앱별 사용자수와 앱의 이벤트 시점에 따라서 트래픽이 급증하는 상황이 발생
- 특정사용자 혹은 사용자군의 모니터링이 가능할 것
- Velocity Check
- 통상적인 수치를 벗어나는 상황에 대한 인지가 필요 (QA나 혹은 인지할 수 없는 오류 혹은 장애 확인 필요)
- FDS 시스템과 연동 등을 고려 (특정 API에 대해서 일정 수준이하의 응답 시간 확보)
[고려사항 및 설계]
- 로그 수집을 통한 실시간 혹은 대량의 데이터에 대한 MR 분석이 가능할 것
- 별도 plugin 설치등 Live 서비스에 영향을 주지 않고 각 was 인스턴스의 로그만 수집하는 agent만 가동
- 특정 기능에 대해서 일정수준 실시간 성을 지원하여 허용 시간 범위내에서 데이터 분석이 가능할 것
- MR을 활용한 대량의 데이터를 분석하여 원사는 데이터를 추출 할 수 있을 것
- 다양한 데이터 분석 결과에 대응할 수 있는 Chart를 지원할수 있을 것
- 개발과 운영 비용의 최소화
- IT회사가 아니기 때문에 장비 지원은 항상 최소를 고려 (ㅠㅠ)
- 시스템 운영으로 장애 및 피해 예방을 통하여 비용확보 필요
- 기존 업무를 하면서 남는 시간을 활용하여 개발 진행, 초기 운영까지도.. 개인 업무 Capacity 고려
[개발 stack]
- Java 8
- SpringBoot Web (with thymeleaf)
- d3.js
- Hbase 1.2
[참고 자료]
- OpenTSDB
- Hbase를 활용하여 시계열(time series) 데이터 처리를 위한 sheme 설계에 참고
- D3.js
- 다양한 정적 or 동적 차트 처리를 위해 도입
[시스템 구조]
- LogCrawlAgent
- 각 Live 서버상의 로그를 실시간으로 전송(http keepalive socket)
- jar console application
- TXD (Transaction Deamon)
- 실시간 모듈 : API, 실시간 처리, UI 제공
- Batch 모듈 : 앱 전체의 통계 및 Report 추출
[데이터 스키마]
- 총 6개의 Table로 구성되며,
- 실시간 시계열 데이터 처리를 위한 tsTable은 아래와 같이 OpenTSDB 유사 scheme 적용 (아래)
- 사용자 데이터의 Velocity Check의 응답 속도 보장을 위한 별도의 table에 scheme 적용
- MR처리 효율상 특정 부분은 bit가 아닌 String, Number 등의 데이터 Type 적용
| 범주 | RowKey | |||||
| 구성 | metricId:3byte | baseTimeStamp:4byte | key1:3byte | value1:3byte | keyN:3byte | valueN:3byte |
| 각주 | 정의된 metric | 시단위까지의 변환값 | 추가정보 key값 | 추가정보 value값 | 추가정보 | 추가정보 |
| 범주 | Column | |
| 구성 | qualifer | value |
| 데이터 구조 | time offset:4byte | String or Long |
| 각주 | 시단위 미만 시간값 | 임의 등록 가능 |
[Major Features]
- 메인화면
- 상단 Traffic Chart는 30초 주기로 갱신 (Cubism.js 적용)
- 트래픽, 결제 상위 앱들의 랭킹을 최근 10분 및 일간 누적 기준으로 제공
- 고 결제빈도 사용자 군 랭킹 추출
- 실시간 로그 확인
- 각 API별 트래픽의 갱신주기를 사용자가 정의할 수 있도록 하여 긴급 상황 대응
- 트래픽 비교
- 양일간 특정 트래픽의 추이 비교를 통하여, 감지되지 않은 장애상황 및 프로모션 등 이벤트 등 마케팅 분석에 활용
- 앱별 트래픽
- 특정 트래픽을 기준으로 앱별 & 시간대별 순위를 추출하여 차지하는 비중을 확인
- 상위 결제 유저
- 자동화 툴 혹은 악의적(실험적)의도의 사용자 트래픽의 분석 확인
[개발과 운영을 하면서]
- Hbase는 실시간 및 대량 Batch(MR)의 두마리 토끼를 잡을 수는 있으나,
- 잘못된 Scheme 적용시 Data 증가에 따라 응답 속도가 기하급수적으로 느려질 수 있음 (당연한 이야기 이겠지만..)
- Scheme 디자인시 철저히 데이터 실시간 요구사항에 근거해야 하며, 이외의 기능은 MR로 커버 가능
- MR자체의 성능은 Hadoop의 RawData 직접 처리보다는 느리다 (2,3배 정도)
- 성능 및 효율을 위해서는 Bit 단위의 data 를 기반으로 하는 scheme 적용이 필요하나,
- Hadoop Eco 시스템 기반의 쿼리 등의 다양한 툴을 적용하기에 어려움이 있으며,
- 경우에 따라서는 별도의 공용(범용) Query Lang혹은 API 제공이 필요할 듯 보이며,
- 개발 자체의 어려움도 수반하니 신중을 기해야 하겠다
- D3.js는 정말 훌륭하다
- 부하량은,
- Agent의 부하는 CPU사용률 1%이내로 Live 시스템에 미치는 영향이 거의 없으나,
- TXD의 특정 쿼리의 실시간 처리를 위해 CPU사용률이 최대 20%가량 치솟는 경우도 있었음
- 실시간 통계 처리를 위해서는 Cache등의 적용이 필요할 듯 (사용자가 늘어나면..)
- Hbase
- StandAlone 모드로 300tps 수준 로그 적제시에도 CPU 사용률은 최대 3%를 넘지않은 미미한 수준
- TBD
'Expired > Hadoop Hbase Nutch2' 카테고리의 다른 글
| Hbase JSON API 사용하기 (0) | 2015.01.04 |
|---|---|
| Nutch Cycle Step (0) | 2015.01.03 |
| 하둡 이클립스 플러그인(Hadoop1.1.0 Eclipse Plugin) (0) | 2012.11.17 |
hadoop-eclipse-plugin-1.1.0.jar