본문 바로가기

2011
마이크로소프트웨어

글: 허광남 | kenu.heo@gmail.com / 2011-08


<COVER STORY 3>

서비스 in the 클라우드
이벤트 급증에 대한 트래픽 분산 사례


2011년 최고의 키워드인 모바일과 클라우드 그리고 서비스 측면에서 얘기할 수 있는 트위터, 페이스북과 같은 소셜 네트워크 서비스(Social Network Service). 귀에 못이 박히게 듣고 있다. 이러한 플랫폼이 자리 잡고 있는 지금, 올드하게 홈페이지와 ftp 얘기하면서 개발을 언급하는 것은 아주 나이가 지긋한 사람처럼 고루하게 들린다. 이렇게 수많은 키워드들이 우리를 질리게 해도 그것을 이용해 서비스를 만든다는 것은 현재를 살아가는 개발자로서 살맛나는 재밌는 일인 것은 사실이다.


필자는 새로운 스타트업 기업에서 정해진 광고를 보고 이벤트에 참여해 선착순으로 광고를 본 상품을 경품으로 받는 모바일 광고 서비스‘랙션’을 만드는 일에 참여하게 됐다. 스마트폰의 중력가속도 센서를 이용해 월, 수, 금 오후 1시에 광고를 본 사람들이‘흔들기’이벤트에 응모해 선착순 80명과 탈락자 중에서 복권으로 당첨된 20명을 바로 랭크에 보여주는 서비스다.


아이폰과 안드로이드 애플리케이션을 개발∙배포하고 그 애플리케이션을 설치한 사람들이 광고를 보고 참여할 수 있는 서비스다. 모바일 광고 마켓 플레이스를 제공하는 Admob이나 Cauly 같은 다른 애플리케이션의 일정 영역에 배너광고를 하는 모바일 광고가 일반적인데 반해 공짜 이벤트 기반의 스마트폰 광고 채널이라는 오프라인 상품 중심의 서비스라는 것이 가장 큰 특징이다.


이 서비스의 기술적인 특징이라면 두 가지가 있다. 스마트폰 클라이언트에서 중력센서를 사용한 것과 동시다발적으로 들어오는 요청을 받아들여 1분 안에 랭킹이 참가한 모든 사람들에게 보여줄 수 있는 서버 쪽의 기능이다.


화면 1. 필자가 참여한 프로젝트의 컨셉트
<화면 1> 필자가 참여한 프로젝트의 컨셉트


클라우드에 둥지를 틀면서

2004년, 웹크롤러가 수집한 대용량의 웹페이지를 분산된 컴퓨터 시스템에서 빠른 시간 안에 분석해 인덱싱할 수 있는 기술인 구글의 파일 시스템에 대한 논문이 공개됐다. 이 내용을 토대로 하둡(http://hadoop.apache.org)이라는 오픈소스가 만들어졌고, 야후가 본격적으로 이 프로젝트를 사용했다.


분산 데이터 처리와 함께 클라우드 컴퓨팅의 또 하나의 축으로 가상화 기술이 있다. 리눅스 또는 윈도우 서버 같은 OS를 가상머신으로 쉽게 만들어서 관리하면 물리적 서버의 남는 자원을 효과적으로 활용할 수 있다. 이를 최초로 상용화한 서비스가 아마존의 EC2(Elastic Compute Cloud, aws.amazon.com/ec2/)다.


화면 2. 아마존 EC2 웹페이지
<화면 2> 아마존 EC2 웹페이지


웹페이지를 통해 기존의 웹호스팅 또는 서버를 임대하는 코로 케이션 서비스보다 저렴하고 쉽고 빠르게 리눅스 또는 윈도우 운 영체제의 가상머신을 생성∙관리할 수 있게 됐 다. 비용은 시간 단위로 책정되기 때문에 한 시 간만 사용하고 결제할 수도 있다. 이것은 실험 적인 서비스를 테스트하고자 할 때 장비를 사지 않아도 되기 때문에 많은 아이디어들을 쉽게 테 스트할 수 있는 환경을 만들어 줬다.


KT가 이같은 서비스를 벤치마킹해서 올해 3 월에 시작한 서비스가 있다. 바로 유클라우드 (uCloud)다. cs.ucloud.com 페이지에 접속하면 아마존 EC2와 동일한 서비스를 한국어로 제공 하기 때문에 쉽고 저렴하게 클라우드 서비스를 이용할 수 있다.


화면 3. 클라우드 서버 관리 화면
<화면 3> 클라우드 서버 관리 화면


앞서 말한 모바일 광고 채널 서비스를 위해 1 월부터 서버를 통해 작업했다. 당시에는 아마존 을 사용했다. 싱가폴에 있는 서버를 이용했기 때문에 국내에서 체감하는 느린 네트워크 지연 속도가 이슈가 됐고, 3월 일본에 대지진이 일어 나기 전까지는 일본에 새롭게 생긴 아마존 EC2 를 이용할 수 있었다.


4월 초에 KT의 클라우드 서비스가 오픈하면 서 외국에 있는 클라우드보다 빠르다는 것과 한 국어로 돼 있는 서비스라는 것이 큰 장점으로 다가왔다. 초창기 월 단위 계약이었지만 얼마 되지 않아 서버의 가동시간에 따른 시간단위 과 금도 가능하게 됐을 정도다.


아마존과 KT 유클라우드 서비스를 간략히 비 교해 보자. 제공하는 기능면에서는 몇 년 앞선 아마존이 우위다. 하지만 국내 네트워크를 이용 하기 때문에 네트워크 속도가 월등하고, 모든 매뉴얼이 한국어로 돼 있다는 점에서 국내에서 는 KT의 서비스가 유리하다. 서비스 지역이 국 내냐 외국이냐에 따라 클라우드 서버의 지리적 위치가 제법 중요한 결정요인으로 작용한다.


1월 말 아마존 EC2 싱가폴
2월 초 KT 유클라우드
3월 초 아마존 EC2 도쿄
4월 초 KT 유클라우드
  - ractionAppServer(8코어, 16GB 램 : 325,000원/월)
  - ractionWebServer(4코어, 8GB 램 : 182,000원/월)
<표 1> 클라우드 서비스 이전과 서버 사양별 과금

클라우드 서비스를 이용하면서 서버의 사양을 어떻게 결정할 것인가에 대해 경험을 토대로 얘기하려고 한다.


서비스 초기에는 사용자가 생각보다 많이 몰리지 않는다. 서비 스 오픈부터 몇만 명씩 접근하는 경우는 아이폰 접수와 같이 사 회적인 관심이 많은 이슈가 아니라면 거의 없다고 봐도 과언이 아니다. 벤처기업의 최초 서비스라면 더욱 더 그렇다. 때문에 클 라우드에서 제공하는 최소 사양으로 시작할 것을 권장한다. <표 1>에서와 같이 서버의 CPU 코어 수와 메모리 크기에 따라 과금 되는 금액이 다르다. 아마존의 최소 단위는 1코어 613MB 메모리에 root 계정을 제공받는 micro 서비스의 경우 한 달에 3,000원 정도면 된다.


그림 1. 이미지 서비스를 분산시킨 랙션 시스템 아키텍처
<그림 1> 이미지 서비스를 분산시킨 랙션 시스템 아키텍처


트래픽 폭증에 따른 서버 다운과 대책

서비스를 운영하면서 프로모션 차원에서 아이패드2 10대를 경품으로 내건 날이 있었다. 5월23일이었다. 서비스의 증가 그래프를 계속 모니터링하고 있었기 때문에 안정적인 서비스가 가능할 것이라고 생각했었는데 확실히 사회적 관심을 받는 제품이었기 때문에 트래픽이 몰렸다. 오후 1시 정각이 되기 전에 광고 이미지와 동영상을 배포하는 서버에서 더이상 서비스가 불가능하게 됐다. 12시 58분 48초에 서비스가 정지됐고 긴급회의를 통해 24시간 후인 다음 날 이벤트를 다시 열기로 정하고 트위터와 홈페이지 등을 통해 공지했다. 그날 밤은 시간이 그리 빨리 지나갈 수가 없었다. 다행히 클라우드 서비스에서 제공하는 CDN과 로드밸런서(LB) 구성이 가능해 이미지 서버를 <그림 1>과 같이 분산 서비스가 가능하도록 변경했다.


클라우드 서비스를 이용하지 않았다면 24시간이라는 시간 내에 빨리 서비스를 재개하기 힘들었을 것이라고 지금도 회고하고 있다. 서버와 LB 장비를 구매한 후 IDC에 있는 랙에 설치하고 OS 설치와 애플리케이션 배포 등 여러 절차들 중에서 OS 설치 이전의 일을 처리하는 데 걸리는 시간을 절약할 수 있었다.


화면 4. 정상 서비스와 트래픽 폭증에 대한 초단위 접속 수 비교
<화면 4> 정상 서비스와 트래픽 폭증에 대한 초단위 접속 수 비교


<화면 4>의 그래프는 12시 50분부터 12시 58분 48초까지 App 서버에 남겨진 로그의 추이를 그린것이다. 세로축은 초당 로그의 라인수다. 5월 20일에 비해 2~3배 정도 높은 접속율을 보인다.


화면 5. 네트워크 구성 변경을 통한 스케일 아웃 이후 초단위 접속 수 비교
<화면 5> 네트워크 구성 변경을 통한 스케일 아웃 이후 초단위 접속 수 비교


드디어 다음 날 아이패드2 10대가 걸린 이벤트 시간이 다가왔다. 다행히 밤세워 이미지 서버의 분산 구성을 바꾼 효과가 있었다. 이벤트 시간에 몰린 트래픽을 성공적으로 커버할 수 있었다. 이벤트를 무사히 마치고 로그 분석을 했는데 예상 외로 <화면 5>와 같은 결과의 그래프가 나왔다. 장애 시 발생한 트래픽에 가깝다기보다는 지난 5월 20일 이벤트 트래픽보다 50% 정도 증가한 그래프 결과를 얻었다. 여기서 추론할 수 있는 것은 장애 시 트래픽이 몰린 이유가 사용자들이 2~3번 정도 애플리케이션을 껐다가 키면서 시도한 재시도의 흔적이 서버에 더 부하를 줬기 때문이라는 것이다.



부하 분산에 관해

서비스가 정착되고 입소문을 타고 인기를 끌게 되면 필연적으로 서버 구성의 변화가 필요하다. <그림 2>는 통계를 내기 위해 애플리케이션의 분산 처리를 설계했던 것 중의 하나를 그린 것이다. 하나의 앱 서버에서 처리하던 것을 여러 앱 서버로 분산하고, 분산된 앱 서버에서 필터링된 후보들을 통합 서버에서 취합한 다음 DB에 넣는다는 의미다.


그림 2. 애플리케이션 분산 처리 아키텍처의 예
<그림 2> 애플리케이션 분산 처리 아키텍처의 예


현재 운영되는 것과는 차이가 있지만 이런 분산처리 방식을 적용하는 데 클라우드 시스템의 유연함은 최적의 환경이라고 할 수 있다.



예상치 못한 병목

앞서 장애가 발생했던 이미지 서버의 경우는 서비스에서 모니터링을 하지 않았었다. 오히려 스마트폰에서 직접 접근하는 앱 서버의 부하만을 크게 생각했다. 병의 목 부분에서 나타나는 원활하지 않는 흐름을 병목현상(Bottle Neck)이라고 한다. 서비스 운영에 있어서 로그를 쌓고 그 쌓인 로그를 분석하는 것은 병목이 발생하기 전에 징후를 알아차릴 수 있는 중요한 수단이다. 또한 장애 발생 시에도 로그의 분석은 중요한 정보를 찾을 수 있게 한다. 시스템의 임계점을 찾는 작업은 로그를 통해 보다 쉽게 접근할 수 있다. 시스템의 성능이라는 것이 복잡한 상관관계에서 좌우되므로‘이것 때문이다 저것 때문이다’명확히 얘기하기는 어렵지만 부하를 증가시키면서 상대적인 임계점을 찾아낸다면 해당 서버의 한계에 미리 대비할 수 있는 좋은 정보가 된다.



스케일 아웃∙스케일 업

서비스 확장에는 스케일 아웃(scale out)과 스케일 업(scale up) 두 가지 방법이 있다. 전자는 서버의 수를 늘려서 확장하는 것이고, 후자는 메모리 확장이나 서버의 튜닝 그리고 애플리케이션의 최적화를 통해 단위서버의 성능을 높이는 것이다.


애플리케이션이 분산처리가 가능하도록 설계돼 있다면 스케일 아웃은 쉽게 적용할 수 있다. 트래픽의 증가에 따라 서버만 증가 시키면 되기 때문이다. 일반적으로 L4 스위치라고 하는 장비를 앞단에 붙이고 이 장비에 동일한 기능의 여러 서버를 붙이는 것이 분산처리의 일반적인 방법이었다.


스케일 업의 경우는 스케일 아웃에 비해 노력과 시간이라는 비용이 더 필요하다. 시스템의 성능은 프로그래밍이 얼마나 스마트하게 돼 있느냐에 크게 좌우된다. 같은 결과를 산출하는 데 현명한 프로그래머와 그렇지 않은 프로그래머의 실력 차이가 현저하기 때문이다.


데이터베이스의 쿼리 결과가 일정시간 동안 일정하다면 매번 SELECT 문으로 값을 가져오기보다는 메모리에 올려서 DB 접속 없이 서비스하는 방법이 일반적으로 사용된다. 자바에서는 EHCACHE, OSCACHE 등의 오픈소스 라이브러리를 사용하는 경우가 많다.


화면 6. 클라우드 서비스에서 제공하는 CDN 서비스 관리 화면
<화면 6> 클라우드 서비스에서 제공하는 CDN 서비스 관리 화면



CDN

동영상이나 이미지를 서비스할 경우에 부하를 분산할 목적으로 서비스되는 것이 CDN(Content Delivery Network)이다. 원본 서버를 지정하면 배포되는 중계 서버에 콘텐츠가 복사되고 그 콘텐츠 배포 서버에서 요청을 대신 처리한다. <화면 6>은 클라우드 서비스에서 제공하는 CDN 관리 화면이다.



그림 3. 로드 밸런서의 동작 구조
<그림 3> 로드 밸런서의 동작 구조


로드 밸런서

앞서 이미지 서버 세 대 앞에 붙어 있는 로드 밸런서(Load Balancer)에 대해 언급했다. <그림 3>은 로드 밸런서의 동작 구조를 보여준다. 공인 IP를 통해 들어오는 요청에 대해 내부 서버 인스턴스에 연결해서 서비스하는 구성이다. 일반적으로 연결된 서버들의 성능이 동일하다면 라운드 로빈이라고 불리는 요청을 하나씩 서버로 고르게 분배하는 방식으로 부하를 분산한다.


화면 7. 클라우드에서 제공하는 공인 IP와 로드 밸런서
<화면 7> 클라우드에서 제공하는 공인 IP와 로드 밸런서


<화면 7>은 클라우드에서 제공하는 공인 IP와 이 IP에 연결된 로드 밸런서 관리 화면이다. 공인 IP의 경우는 월 일정액의 과금이 이뤄진다. 클라우드 시스템 사용 시 서버 인스턴스는 클라우드 시스템에서 제공하는 내부 IP를 갖게 된다. 하지만 이 내부에서 제공되는 아이피는 외부에서 접근되지 않는다. 때문에 공인 IP를 신청해야 하며 이 공인 IP를 통해 외부 서비스가 가능하다. 다만 주의할 것은 클라우드 내의 서버끼리 연결할 경우는 공인 IP보다는 내부 IP를 통해 접근해야 한는 것이다.



소스 배포의 자동화

클라우드 서비스를 이용할 때 새로운 서버 인스턴스를 만들고 애플리케이션 서버의 설치를 마치면 소스의 배포가 신속하게 이뤄져야 한다. 이 때 서브 버전이나 git과 같은 소스 저장소를 통해 최신 소스를 활용할 수 있다. 수동으로 배포할 경우에는 시간과 노력이 많이 들지만 Ant, Maven과 같은 빌드 스크립트를 이용해 자동화하고 젠킨스 CI(jenkins-ci.org/)와 같은 지속적인 통합도구를 사용한다면 굉장히 쉽게 늘어나는 서버들과 소스의 배포 관리가 가능하게 된다.



부하 테스트 JMeter

개발과 서비스에 있어서 부하를 테스트하는 도구로 JMeter(jakarta.apache.org/jmeter/)를 추천한다. 아파치 벤치 등을 통해 간단히 테스트도 가능하지만 JMeter를 통해 테스트할 경우 더 정교한 테스트가 가능하다.


모든 응답에 대해서 원하는 텍스트가 있는지 확인할 수 있고 개별 요청에 대해 타임아웃 옵션을 줘서 지정된 시간을 초과할 경우 어떻게 반응하는지도 테스트할 수 있다. 또한 서버에 보낼 파라미터를 패턴에 따른 랜덤값으로 보내는 기능도 있기 때문에 다양한 테스트가 가능하다.


서버의 부하 테스트를 할 경우 한 대의 클라이언트에서 요청하는 것보다 다수의 클라이언트에서 동시에 부하를 발생시키는 방법이 필요한데 이에 대한 기능도 지원한다. 또한 한 사무실에서 원격의 서버에 부하를 테스트하는 경우 사무실과 서버 사이 망의 대역폭 한계가 있다는 사실에 대해서도 인지하고 있어야 한다.



화면 8. 부하 테스트를 위한 JMeter
<화면 8> 부하 테스트를 위한 JMeter


클라우드 세계로

아마존의 클라우드 서비스가 여러 기능을 지원하고 미국이나 유럽 쪽에서 서비스 할 경우 좋은 선택이 될 것이라고 한다면 국내의 클라우드 서비스를 처음 시작한 KT의 서비스는 한국어로 쉽게 접근할 수 있고 국내에서 빠른 네트워크 속도를 지원한다는 장점이 있다. 실제로 제공되는 매뉴얼을 통해 시스템을 설정하고 관리하는 데 무리가 없을 정도로 잘 돼 있다.


OKJSP


클라우드가 막연했던 분들에게 이 글이 조금이라도 도움이 돼서 좋은 서비스를 시작할 수 있길 바란다.


마지막으로 랙션 서비스를 통해 좋은 경험을 할 수 있게 해 준 팀원들과 KT의 유클라우드 서비스에 감사하고 싶다. 랙션 블로그에 KT클라우드를 무작정 따라할 수 있도록 만든 문서가 있다.

다음 링크를 통해 클라우드의 세계를 체험해 보자.

http://raction.tistory.com/tag/startucloud



[참고자료]
1. KT 유클라우드 - http://cs.ucloud.com/
2. 아마존 EC2 - http://aws.amazon.com/ec2



/필/자/소/개/

필자 허광남

허광남 | kenu.heo@gmail.com

OKJSP.pe.kr 운영자다. 1984년 프로그래밍 경진대회에 참여하며 프로그래머의 인생을 시작했으며, 1999년부터 웹개발자로 월급 받아 생계를 유지하고 있다. 최근 모바일 개발에 뛰어들었으나 팀원들 관리하느라 코드는 주로 훈수를 두고 있으며 ALM 관점에서 trac을 잘 사용하고 있다.




※ 본 내용은 (주)마소인터렉티브(http://www.imaso.co.kr/)의 저작권 동의에 의해 공유되고 있습니다.
    Copyright ⓒ Maso Interactive Corp. 무단전재 및 재배포 금지

맨 위로
맨 위로