[오픈스택 데이 발표자료] 클라우드 시대의 모니터닝및 성능 이야기

지난 오픈스택 데이 2017에 클라우드 시대의 모니터링및 성능 이야기 라는 주제로 와탭의 손영수님이 발표를 해주셨습니다.   많은 분이 자료를 요청해주셔서 공유를 해 드립니다.

와탭은 현재 15000대의 서버와  500개의 어플리케이션을  모니터링 하고 있으며,  국내 최조로 SaaS형 모니터링 솔루션을 개발해, 장애및 성능에 대한 많은 경험치를 가지고 있습니다.  와탭 팀원들의 여러  경험을 담아 만든 자료라고 보시면 됩니다.

직접 모니터링 솔루션을 구축하실때 어떠한 부분들을 고려하셔야 되는지 와탭의 고민과 경험들을 공유드립니다!

직접 구축하는 비용및 유지 보수 비용을 생각하신다면, 이러한 철학들이 반영된 와탭의 인프라스트럭쳐 모니터링과 어플리케이션 모니터링을  사용하시는게 좋겠죠.

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)

이번 글을 시작으로 와탭 모니터링을 이용한 성능 개선 사례들을 종종 공유하고자 합니다. 첫 번째 주인공은 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) 성능 개선기 – (상세 내용) 더보기

누워서 보는 웹 애플리케이션 성능 II – 다운 샘플링이 가져오는 왜곡 현상들

이전 글(누워서 보는 웹 애플리케이션 성능 – 평균과 분포)에서는 개별 응답시간을 평균 응답시간으로 표현할 경우 왜곡 현상이 발생되는 것을 다루었습니다. 간단히 말해 Y축의 데이터를 평균화 시키면서 나타나는 왜곡 현상입니니다. 이번 글에서는 샘플링 주기(X축의 데이터 왜곡 현상)가 가져 오는 문제점 및 와탭이 APM/SMS 서비스를 운영하면서 만난 유사한 문제들과 그 해결책을 공유하고자 합니다.

APM에서 발생하는 샘플링 문제 

N사의 APM을 사용하면서 고객들이 가지는 몇몇 고충들이 있었는데요…

  • 장애가 난 후 적게는 몇 분에서, 많게는 몇십 분이 지난 후에 장애를 인지하게 된다.
  • 성능에 대한 문제가 발생했음에도 불구하고 응답시간이 낮은 트랜잭션의 비율이 많으면  문제가 안 보인다.

실제 Quora에 올라온 글입니다.

newrelic issue

간단히 요약하면, ‘N사는 1분 평균의 데이터를 보여주기 때문에 최근 20초 동안 애플리케이션에 문제가 발생하더라도, 나머지 40초 간의 정상적인 트랜잭션으로 인해 데이터가 평균화 되면서 실제 문제를 못 보는 경우가 발생한다.’라는 것입니다.

누워서 보는 웹 애플리케이션 성능 II – 다운 샘플링이 가져오는 왜곡 현상들 더보기