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가 다운되기 전에 무슨 일이 있었던걸까요?

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

opensurvey (IDINCU) 성능 개선기 – (짧은 동영상)

오픈서베이의 성능 개선 이야기 with WhaTap !

오픈서베이의 성능 개선기를 카드뉴스, 텍스트 등 다양한 방식으로 보여드렸습니다.

이번에는 동영상이 궁금하지만 시간이 없는 분들을 위해, 파트별로 분리된 동영상들을 준비했습니다. 필요한 부분만 골라서 보세요.

blog_signup_banner_b (3)

서비스 소개 및 도입 계기

여느 스타트업처럼 빠르게 시장에 침투하기 위해 SSA(Single Service Architecture)로 출발을 하였습니다. 글로벌 서비스로 성장하면서 MSA(Micro Service Architecture)로 전환이 필요하게 되었고, 그 여파로 시스템은 더 복잡해졌습니다.

결국 병목 지점을 더 찾기가 힘들어졌고, 문제의 원인을 찾을 만한 여유가 없어 서버를 재시작하고, Scale Out 즉 용량을 늘리는 문제로 해결을 했습니다. 하지만 메모리를 비롯한 서버 비용에 대한 부담이 증가하였습니다.

문제를 해결하기 위해 다양한 방법을 시도하였으나…

VisualVM, Observium, Graylog, ELK stack 등 다양한 시스템을 도입해 문제들을 개선하긴 했지만, 이것조차 한계에 부딪혔습니다.

기존의 모니터링 시스템들은 대부분 실시간 기반이기 때문에, 문제가 생겼을 때 해당 시스템을 켜서 보고 있어야 합니다. 그러나 실제 상황에서는 시스템을 보고 있을 시간도 없고 확실성도 떨어졌습니다.  구축하는데 개발자들의 자원도 많이 들어갔고요. 

 

opensurvey (IDINCU) 성능 개선기 – (짧은 동영상) 더보기

opensurvey (IDINCU) 성능 개선기 – (상세 내용)

오픈서베이의 성능 개선 이야기 with WhaTap !

 

 

blog_signup_banner_b (3)

이번 글을 시작으로 와탭 모니터링을 이용한 성능 개선 사례들을 종종 공유하고자 합니다. 첫 번째 주인공은 IDINCU입니다.

 

IDINCU(아이디인큐)의 제품 소개

product_lineup_idincu_img

IDINCU는 국내 모바일 설문조사에서 선두를 달리고 있는 스타트업으로, 오픈서베이와 오베이라는 두 가지 제품을 제공합니다.

오픈서베이는 설문을 만들고, 설문의 타겟을 설정하고, 설문 결과를 보여줄 수 있는 플랫폼이며, 오베이는 패널들이 설문에 응답할 수 있는 플랫폼입니다.

글로벌하게 두 가지 서비스가 함께 운영되다 보니 사업적인 모델뿐만 아니라 내부 시스템 도 복잡해졌습니다. 

 

도입 계기

여느 스타트업처럼 빠르게 시장에 침투하기 위해 SSA(Single Service Architecture)로 출발을 하였습니다. 글로벌 서비스로 성장하면서 MSA(Micro Service Architecture)로 전환이 필요하게 되었고, 그 여파로 시스템은 더 복잡해졌습니다. 이 과정에서 원래 사용하던 legacy system을 한 번에 걷어내는 것은 쉽지 않았기 때문에 legacy와 새로운 시스템이 공존하게 되었습니다.

결국 병목 지점을 더 찾기가 힘들어졌고, 문제의 원인을 찾을 만한 여유가 없어 서버를 재시작하고, Scale Out 즉 용량을 늘리는 문제로 해결을 했습니다. 하지만 메모리를 비롯한 서버 비용에 대한 부담이 증가하였습니다.

 

문제를 해결하기 위해 다양한 방법을 시도하였으나…

VisualVM, Observium, Graylog, ELK stack 등 다양한 시스템을 도입해 문제들을 개선하긴 했지만, 이것조차 한계에 부딪혔습니다.

기존의 모니터링 시스템들은 대부분 실시간 기반이기 때문에, 문제가 생겼을 때 해당 시스템을 켜서 보고 있어야 합니다. 그러나 실제 상황에서는 시스템을 보고 있을 시간도 없고 확실성도 떨어졌습니다.  구축하는데 개발자들의 자원도 많이 들어갔고요. 

 

opensurvey (IDINCU) 성능 개선기 – (상세 내용) 더보기