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

이 글은 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가 많이 필요한 배치 작업을 돌린다면), 우리 서비스에 영향을 줄수 있다는 것이다.  그래서 기존 서비스를 쾌적한 다른 존으로 배치하고 나서 장애는 해결되었다.

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

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

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

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

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

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

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

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