[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:3bytebaseTimeStamp:4bytekey1:3bytevalue1:3bytekeyN:3bytevalueN:3byte
각주정의된 metric 시단위까지의 변환값추가정보 key값추가정보 value값추가정보추가정보

범주Column
구성qualifervalue
데이터 구조time offset:4byteString 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

+ Recent posts