클라우드를 도입한다면, 꼭 알아야 하는 것들.

이 글은 DBGuide에 와탭의 손영수님이 기고하신 글입니다.  클라우드 도입시 고려해야 하는 것들을 쉽게 적었으니 편하게 읽어주세요

클라우드 꼭 해야 하나?

클라우드 바람이 불고 있다.  개발자나 DBA 입장에서는 서버를 빌려쓰는 것으로 이해할 수 있지만, 전통적인 시스템 운영자에게는 그 이상이다.    클라우드의 현 시장 상황과  도입시 고려해야 되는 것을 공유드리고자 한다.

미국은 클라우드 전환 율이 5:5 이지만 한국은 이제 8:2 -> 7:3으로 넘어가고 있는 상황이다. 혹자는 낮은 클라우드 전환 율이 해외에 비해 경쟁력이 없다, 뒤쳐지고 있다 라는 이야기를 하고 있다.

엄격하게 말하면, 이러한 상황은  한국 시장의 특성때문에 그렇다. 미국,중국은 내국 서비스라고 해도 미국 전역에 서비스를 배포해야 한다.   개별 IDC 업체들을 돌아가며 IDC 특성에 맞추어가며 배포하는 것보다, AWS, Azure, GCE와 같은 글로벌 밴더사의 클라우드 플랫폼에서 운영 배포하는 것이 유지보수가 훨씬 쉽기 때문에,  미국, 중국 전역 또는 글로벌한 서비스들은  클라우드로  빠르게 전환되고 있는 추세다.

현재 한국은 중견 기업 이상급들이 비용 절감을 위해 오픈 스택, Private Cloud 도입을 하고 있는 추세이다.   하지만 글로벌에 나갈때는  멀티 리전, 멀티 존에 대한 운영이나 경험들에 대해 부족해 어려움을 겪고 있는 현실이며, 이러한 경험을 가진 인력을 구하기는 쉽지 않다.

클라우드는 공유 제한

cloud instance
그림 1. 클라우드는 공유자원

개발자, 운영자 DBA가 클라우드가 가져오는 가장 큰 제약은 클라우드는 공유자원이라는 것이다. 하나의 머신에, 가상화된 여러개의 인스턴스를 올려 놓은 것이다.   즉 다시 말하자면, 우리는 공유자원을 빌려 쓰는 것이므로 오늘 잘 동작한다고 해서 내일 잘 동작한다는 것을 보장할수 없다.

iops queue length.png
그림 2. 클라우드 장애의 단골 손님 –  IOPS 부족 문제

국내 서비스중인  안정적인 게임이 중국에 클라우드에서 배포되고 나서 발생한 장애사례이다. 한국에서는 실제 물리서버에서 배포를 했었는데, 중국 진출 후 클라우드를 처음 도입하였다.   그런데 두개의 리전에 로그인 서비스를 배포 했는데, 특정 시간대에 한쪽 리전에서만 계속 로그인이 제대로 되지 않아 튕기는 문제가 발생했다.

장애시 개발팀은 이미 몇 년동안 검증된 로직인데, 원인을 찾기 힘들어 했었고, 문의가 들어와 확인을 해보니 클라우드 인프라의 문제였다.  바로 클라우드에 가장 장애로 많이 이어지는 IOPS (초당 발생하는 IO) 가 대표적인 예이다.  위 그림을 보면 IOPS가 초당 250으로 제한이 되어있는 것처럼 볼수 있으며, 실제 IOPS 요청에 비해 부하가 반영이 되지 않아 Write Queue에 요청이 쌓여 있는 것을 볼수 있다.

왜 이러한 현상이 발생했을까? 앞서 언급한 것 처럼 클라우드는 공유자원이다.   즉 하나의 Host 머신에서 우리 서비스 이외에 다른 서비스들도 입점 할수  있으며,이 서비스가 특정 시간마다 과도한 자원을 사용한다면 (IO가 많이 필요한 배치 작업을 돌린다면), 우리 서비스에 영향을 줄수 있다는 것이다.  그래서 기존 서비스를 쾌적한 다른 존으로 배치하고 나서 장애는 해결되었다.

클라우드를 도입한다면, 꼭 알아야 하는 것들. 더보기

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 – 분포와 평균 더보기