Twitter의 좌충우돌 모니터링 만들기!

트위터는 왜 두번이나 모니터링 시스템을 직접 개발 하였을까요?   모니터링 전문업체인  와탭 입장에서는 참 궁금했는데요.  그 이야기를 공유해 드리겠습니다.

Twitter 모니터링 초창기 시스템 아키텍처

트위터 모니터링 1.0 시스템의 아키텍처
트위터 모니터링 1.0 시스템의 아키텍처

첫 모니터링 솔루션은 위와 같이 아키텍처를 수립하였습니다. (현재 오픈소스 솔루션과 유사하죠)     1.0 시스템은 다음과 같은 컴포넌트로 구성되어 있습니다.  (트위터의 모니터링 시스템이 오픈소스로 공개되지 않아서, 전적으로 발표자료에 의존해 설명이 구체적이지 않습니다. )

  • Agent  – 데이터를 수집하는 Agent로 시스템 성능에 필요한 여러 지표를 수집.
  • Collector & Storage API – 수집부에서 데이터를  모아  Storage API 를 통해 Time Series Database( Manhattan으로 추정)에 저장하고, 그정보를 Cassandra에 저장.
  • Monitoring – Query 엔진으로 데이터를 긁어와 여러 지표를 모니터링.
  • Dashboard –  Alert 과 Dashboard 를 쉽게 구성할수 있는 Config, DSL을 제공.
  • Ad Hoc Queries – 상황에 따라 적합한 쿼리를 던질수 있음.

트위터는 왜 모니터링 2.0 시스템을 만들어야 했나?

하지만 트위터의 급격한 성장으로 인해, 위 아키텍처로는 더 이상 모니터링을 할수 없는 상황이 되었습니다.

  • 1분당 수집되는 메트릭이 3년 만에 3억개(300M)-> 14배로 43억개(4.3B)으로 증가.
  • 발생하는 알럿의 증가 –  1분당 2500개 -> 1분당 3만개로 증가.

1분당 수집되는 트위터 성능 지표 수집 수

Twitter의 좌충우돌 모니터링 만들기! 더보기

2년동안 못 찾은 모바일 뱅킹의 장애원인을 진단하다!

 

이번 포스팅에서 소개드릴 케이스는 장기간 동안 원인을 알 수 없는 장애와 싸워온 모바일뱅킹 사례입니다.  저희를 부르기 이전까지 해결 할 때까지 어떤 일들이 있었을까요?

casestudy_mobilebanking_2

서버의 댓수를 늘려, 응급 처방을 한 사례 

먼저, 해당 솔루션은 도입에 2년 6개월정도 걸린 모바일 뱅킹 솔루션이었습니다. 사실 오래 전에 끝났어야 하는 프로젝트인데 원인을 알 수 없는 장애가 발생하여 프로젝트가 마무리되지 못했고, 이 장애를 해결하기 위해 6개월정도를 국내 J사와 P사의 APM 솔루션을 통해서 성능 진단을 하고 장애 원인에 대해 추적을 하고 있었죠. 이 과정에서 완전한 해결은 하지 못했지만 물리적 서버 용량을 늘리는 형태로 응급 처방이 진행됐습니다. 기존 시스템이 IBM AIX 코어로 8코어정도를 쓰고 있었는데, 무려 40코어나 사용하는 굉장히 큰 문제가 발생한거죠.

엄청난 비용

IBM 2코어 당 6천달러 정도로 계산을 해보면, 단순히 코어 수로만 비용 계산을 했는데도 다섯 배나 차이가 납니다. 여기에 보통 비용 계산을 할 때 더하는 유지보수비용 10%와 5년 TCO까지 고려를 하면 이 은행이 지출한 비용은 120,000 달러라는 천문학적인 숫자라고 할 수 있죠.

2년동안 솔루션을 개발했고, 6개월동안 컨설팅을 진행했음에도 불구하고 문제가 해결되지 않자 은행은 심각한 상황에 놓였습니다. 하지만 솔루션 공급사도 별 대책이 없었습니다. 그렇다면 도대체 8코어로 동작되는 시스템과 40코어로 동작하는 시스템은 어떤 차이가 있었을까요?

casestudy_mobilebanking_6

사실 신규 시스템에 많은 기능이 추가된 것은 아니었습니다. 통합 테스트 중 문제가 발생해 시스템의 기능은 MVP 수준으로 축소되었습니다. 그럼에도 불구하고 이렇게 비대해진 리소스는 정말 심각한 문제였죠. 이러한 문제를 장애로 봐야 할까요, 성능으로 봐야 할까요? 기존 동작하던 시스템에 몇 가지 기능만 추가되었음에도 불구하고 어마어마한 리소스를 요구하는 케이스는 성능 문제입니다.

2년동안 못 찾은 모바일 뱅킹의 장애원인을 진단하다! 더보기

광군제를 사수해라! – 중국 클라우드 마이그레이션시 발생한 장애 대응기.

blog_signup_banner_b (3)

배경 설명

casestudy_china.002

유명한 K쇼핑몰은, 한국 물리적 서버(Dedicated Server)에 운영중이던 서비스를, 중국 진출을 위해 클라우드로 마이그레이션을 진행했습니다.

그런데 마이그레이션을 한 이후에 성능 저하가 발생했고, 다가오는 광군제(중국의 블랙프라이데이와 같은 큰 이벤트)를 위해 성능 이슈를 반드시 해결해야 하는 상황이었습니다. 이렇게 급박한 상황에서 밤 사이에 WAS(Web Application Server)가 다운되는 장애가 발생해 K사는 와탭에 성능 모니터링을 요청하게 됩니다.

casestudy_china.003

와탭 기술지원팀이 처음 갔을 때 분위기는 위 그림과 같이 심각했습니다. 광군제는 트래픽이 평소의 열 배 정도로 증가하기 때문에 매출을 대폭 상승시킬 수 있는 절호의 기회입니다. 그런데 이 때 서버의 성능 이슈가 발생해 큰 손실로 이어질 수 있는 정말 심각했던 상황이었던거죠.

그렇다면 WAS가 다운되기 전에 무슨 일이 있었던걸까요?

광군제를 사수해라! – 중국 클라우드 마이그레이션시 발생한 장애 대응기. 더보기

모바일 앱 리뉴얼 이야기 – 10,000개 이상의 데이터 처리와 차트 반응성 올리기

중국 진출의 고민 – ‘모바일에서도 문제의 원인을 파악할 수 있도록’ 데이터를 어떻게 보여 줄까?

기존의 WhaTap 모바일 앱은 WebView 기반으로 차트를 보여줬습니다. 서버 상태를 확인하고, 장애 알림을 받는데 집중을 하였죠.

와탭은 중국 진출을 앞두고 있으며, 중국에서는 웹 보다 모바일을 더 많이 사용합니다. 즉 Mobile-Native 여야만 살아 남을 수 있죠. 그래서 모바일 앱의 중요성이 대두되었으며, 모바일에서도 모든 문제 상황을 판단할 수 있도록 만들어야 했습니다.

그래서 이번 모바일 앱 1.5 신 버전에는 ‘어떻게 빠짐없이 모든  문제 상황을 잘 보여 줄 수 있을까?’를 고민했고, 결국 그 해답으로 차트 표현에 집중하게 되었습니다.

즉, 웹에서 느끼지 못 하는 모바일만의 사용자 경험을 드리는데 많은 고민을 했습니다.

 

10,000개 이상의 데이터를 Native Chart로 보여 주기 위해 생긴 고민들…

하루를 표현하는 1분 데이터는 1,440개. 물려 있는 서버의 수집 단위 (CPU, Memory, Network Card 별 트래픽, 무수한 프로세스 정보, 무수한 디스크 정보)가 많으면 하나의 서버에서도 10,000개 이상의 데이터를 다뤄야 하는 상황이 발생했습니다.

또한 리뉴얼을 진행한 안드로이드 앱은 다양한 디바이스의 상황에 맞게 설계해야 했습니다. 안드로이드는 다양한 사양과 화면의 디바이스들이 있기 때문에 최소 사양과 다양한 화면 비율까지 지원해야 합니다.

하지만, 10,000개가 넘는 데이터를 수집하여 차트를 그리려면 기본적으로 디바이스의 CPU와 Memory를 많이 사용하기 때문에, 사용자의 시나리오를 고려해 어떻게 데이터를 수집하고 표현할지 많은 고민을 했습니다.

모바일 앱 리뉴얼 이야기 – 10,000개 이상의 데이터 처리와 차트 반응성 올리기 더보기

WhaTap이 보내드리는 장애 보고서

이번 글에서 WhaTap의 성능 분석 보고서에 대해 소개하고자 합니다. 많은 서비스 회사들이 서비스 운영 중에 부딪히는 장애로 어려움을 겪고 있으며, 장애를 미리 예측하거나 감지하여 보고해 줄 수 있는 도구들을 찾고 있습니다.  하지만 시스템의 많은 문제를 발견하게 되면 무엇부터 잡아야 할까요?

APM 사용에 익숙해지면 괜찮지만, 처음 사용하시는 분들이 많은 지표 중에 무엇이 문제인지, 장애가 될 수 있는 잠재적 요인을 미리 안다는 것은 어려운 일입니다. 

WhaTap은 이러한 문제를 해결하기 위해, 생성한 프로젝트의 사용자에 help@whatap.io를 추가해 주시면 모니터링 하면서 장애가 발생하거나, 장애가 예상되는 부분에 대해 보고서를 보내드립니다.   

 

성능 / 장애 보고서 

이 보고서는 OpenSurvey 서비스를 운영하시는  IDINCU 제품 총괄 분께서 흔쾌히 실제 사례를 사용해도 좋다고 허락해 주셨습니다.  정말 감사드립니다.

(슬라이드 상에서는 공간의 제약 문제로 보고서의 이미지가 잘 보이지 않으니, 불편하시더라도 슬라이드를 확대하여 자세히 보시는 것을 추천합니다.)

WhaTap이 보내드리는 장애 보고서 더보기