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

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

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

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

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

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 – 다운 샘플링이 가져오는 왜곡 현상들 더보기

누워서 보는 웹 애플리케이션 성능에 필요한 수학 I – 분포와 평균

애플리케이션 성능 향상을 위해 알아야 하는 여러 개념들을 소개하고, 왜 와탭 APM이 실시간 모니터링, 분포도를 표현하는 히트맵 등을  도입했는지, 철학에 기반을 둔 여러 이론들을 하나 둘씩 설명하도록 하겠습니다.  이번 글은 분포와 평균에 대해 다루고자 합니다.

제목으로 누워서 본다는 글을 적었는데 최대한 쉽게, 특별한 수학적 배경이 없어도 알 수 있도록 차근차근 알려드리도록 하겠습니다.

성능의 기준은 LogNormal이 기본

이미지 참조 사이트 - https://www.unc.edu/courses/2007spring/enst/562/001/docs/lectures/lecture6.htm
그림 1. Normal과 Lognormal

예전 수학시간에 많은 것들이 정규분포를 가진다고 배웠습니다. 위 그림에서 보시면, Normal은 정규분포를 의미합니다. 특정 기준값(위 그림에선 0)에 수렴하며 +, -의 값이 균등한 분포를 가지면서 0에 수렴하는 것을 가집니다. 하지만 웹 서버의 성능에 대한 지표는 정규분포를 가지면 안 됩니다. 응답시간에서 -(마이너스)는 존재하지 않으며, 모든 트랜젹선의 응답시간이 한없이 0에 가까워야 되기 때문입니다.

그래서 오른쪽 그림의 LogNormal(로그 정규분포)이 성능이 추구하는 분포에 훨씬 가까우며, 이로 인해 성능 관련 블로그들이나 글들을 보면 자주 LogNormal이라는 단어들이 등장하는 것을 보실 수 있습니다. 심지어 lognormal이라는 이름의 성능 관련 회사도 있습니다.

누워서 보는 웹 애플리케이션 성능에 필요한 수학 I – 분포와 평균 더보기

자바 웹 애플리케이션­­­ 성능에 영향을 미치는 대표적인 문제 유형

웹의 시대에서는 막대한 트래픽(요청)이 발생하면 그 만큼의 수익이 나는 것이 어느 정도 가능했으며(광고 수익, 제품 구매 등…), 흔히 말하는 Enterprise 기업들을 위한 제품 Oracle과 여러 상용 WAS를 구입하여 많은 문제(예: 세션 클러스터링 등…)를 기본적으로 해결된 전제에서 시작했습니다.

하지만 모바일의 시대가 대두되면서, 사용자가 늘어난 만큼 매출이 발생되지 않는 상황이 발생했습니다. 금액적인 압박이 훨씬 크기 때문에 Oracle과 상용 제품을 쓸 수 없으니, 다양한 오픈소스를 활용하게 되었으며, Micro Service Architecture 등이 하나의 패러다임으로 많은 개발자들에게 논해지면서 더욱더 백엔드의 복잡도가 증가되는 것이 현재의 상황입니다.

그림 1. 백엔드의 어려움을 표현한 그림

이러한 상황을 풍자한 재미난 그림도 있습니다.

백엔드의 성능이 저하되거나 장애가 발생하면 서비스의 품질이 낮아지고 고객 이탈을 유발하기 때문에 갈수록 성능 모니터링 역시 중요해지고 있습니다. (사족: 실례로 MSA를 적용한 기업들을 만났을 때 가장 고통스러워하는 것이 하나의 긴 트랜잭션에서 병목구간이 어딘지 알 수 없다는 것이었습니다.  그래서 Zipkin과 같은 오픈소스를 활용하여 병목구간을 찾기위해 여러 노력을 하시는 분도 있습니다.)

와탭은 오랜 경험을 거쳐 백엔드 성능에 영향을 주는 대표적인 문제 유형들을 설명 드리고자 합니다. 그 중에서도 자바 웹 애플리케이션에서 발견되는 대표적인 문제 유형들에 대해 소개하겠습니다.

자바 웹 애플리케이션­­­ 성능에 영향을 미치는 대표적인 문제 유형 더보기