클라우드 서비스에서의 분산서버 처리 기술 (Draft)

과연 분산처리 시스템이 필요한가?

먼저 내가 도입하려는 시스템이 과연 분산처리 시스템이 필요한가 부터 생각해 볼 필요가 있다.

만약에 다음과 같은 서비스류라면  당장 뒤로가기 버튼을 누르기 바란다.

  1. 워드프레스등의 CMS(Contents Management System)으로 동작하는 홈페이지
  2. 여행사 홈페이지
  3. 회사소개 홈페이지
  4. 하루 방문자 10000명 이하로 예상되는 서비스

트래픽이 많지 않은 웹 또느 앱 서비스에서 굳이 오버스펙을 갖출필요는 없다.  하지만 클라우드가 대세라하여, 많은 개발자들이 필수적으로 분산서버처리를 하려고 하는 경향이 있는 듯 하다. 하지만 서버 한대로 동작해도(혹은 웹호스팅으로 동작해도 충분한) 될 정도인 경우가 대부분이다.
너무 많은 도입 사례가 있고, AWS 도입 사례가 과연 자신의 서비스에 맞는지 다시 확인해 볼 필요가 있을 것이다.
너무 많은 클라우드 만능주의가 팽배한 것 같다. 클라우드를 도입한다고 해서 모든 트래픽을 처리할 수 있다는 것은 사실이 아니며, 요금이 저렴한 것이 아니다.

많은 개발자/경영자들이 오해하는 것이 저렴한 서비스를 위해서 클라우드 서비스를 도입한다고 한다. 하지만 이는 무조건 맞지 않는 말이며, 클라우드 서비스에서 제공하는 제품들을 잘 연계시키고 잘 튜닝을 해야 요금의 절약과 더불어 급증하는 트래픽을 감당할 수 있다.

한마디로 말하면 분산처리 시스템을 만드는 시간에 본 서비스를 더 가다듬는 편이 나을 수도 있다. (시간을 아끼자)

다음의 경우라면 분산처리 시스템 도입을 고려가 있는 류이다.

  1. 메시징앱
  2. 폭발적으로 성장할 수 있을만한 앱
  3. 많은 트래픽을 처리해야 하는 웹서비스
  4. 게임

메시징앱이라면 당연히 분산서버처리 기술을 가지고 있어야 하는 것이 당연하다. 언제 폭발적으로 증대할 지 모르는 것에 대비하는 것이 당연할 것이다. 만약 내부 채팅으로 사용하는 경우라면, 이용할 사용자가 이미 정해져 있기 때문에 단일 서버 구성으로 하여도 충분할 것이다.

만약 글로벌을 대상으로 포토앱을 만든다 하면, 당연히 분산서버처리 기술은 필수불가결할 것이다. 역시나 많은 트래픽을 대비하기 위함이고, 시간이 지나면 지날수록 증대되어가는 저장공간을 갖추어야(대비해야) 할 것이다.

게임도 마찬가지로, 분산서버 처리는 필수라고 할 수 있겠다. 아키텍처적으로 이러한 구조로 만들지 않는다면 급급할 수 있다. php 로 게임 서버 만든경우를 봤는데 당연히 대용량 트래픽에는 대비하기 힘들다. 가능하지 않다고는 말을 못하겠지만 훨씬 더 나은 대안들이 많이 있으므로 게임서버에서의 php는 자제하는 편이 좋다.

분산서버 처리를 위한 기술들

로드 밸런싱
흔히 L4장비라고 불리우는 로드 밸런싱은 분산서버 처리를 위한 뼈대를 이루는 장치라고 할 수 있겠다. 로드 밸런싱 장비에 IP가 부여가 되며, 이 로드밸런서에 연결되어 있는 N개의 장치 중 한곳으로 라우팅 시킨다. 이 때 서버가 사용할 수 없는 상태인 서버를 회피하여 연결하게 되는데 이로 인해 이용할 수 없는 서버로 라우팅 되는 것을 방지해준다.
AWS를 사용한다면 Elastic Load Balancer를 사용할 것이며 대부분의(모든) 클라우드 서비스 제공 업체가 로드밸런서를 지원하기 때문에 이를 기반으로 N개의 서버를 연결시키게 할 수 있다.

Auto Scaling
대부분의 클라우드 서비스 제공 업체들이 오토스케일링을 지원하며, 작동방식은 비슷하다.
서버의 부하(CPU Load, RAM 여유) 등을 체크하여 서버를 생성하는 방식이다. 이 때 미리 만들어놓은 가상 이미지로 서버를 생성하게 된다. 최근에는 Docker 와 함께 Auto Scaling 서버 구성을 많이 하는 편이다.

Stateless 설계
Stateless 를 간단히 설명하자면 상태가 없다는 의미이다.
다음의 내용을 고려하여 자신의 서비스에 맞는 적용 방법을 만들어보자.

1. 세션을 로컬 파일구조로 사용하지 않는다. 대안방법은 Redis나 MongoDB를 이용하여 세션을 쓰는 방법이 있다.
2. 파일 저장시 로컬에 사용하지 않는다. AWS의 S3를 사용하거나, MongoDB의 GridFS 등이 대안이다.
3.  Apache 는 피하고 보다 Scalable하게 구성할 수 있는 Nginx를 이용한다.
4. 내부 서버에서만 동작하는 서비스(예를 들면 socket.io) 의 stateless 여부를 확인하자(내부적으로 로컬에서 쓰는 부분을 DB를 사용하게 하면 해결된다.) socket.io의  경우 socket.io-redis 나 socket.io-mongodb 패키지를 이용하면 해결된다.
5. 데이터베이스는 분리하여 구성하자.

데이터베이스의 샤딩
웹/앱서버를 분산시켰다고 해서 끝은 아니다. 데이터베이스 또한 확장이 가능한 구조가 필요하다.
대부분의 데이터베이스가 샤딩(Sharding)을 통한 Scale-out 을 지원한다. Mysql 등의 대부분의 상용 및 오픈소스 데이터베이스에서 지원한다.
샤딩을 사용해야 하는 이유는 DB 저장 공간을 scale-out 하게 쓰기위함이다. 더불어, 쓰기 성능 또한 향상된다.
레플리카(Replica)도 거의 필수로 구축을 해야 하는데, 이는 가용성, 무결성, 두가지를 모두 만족시킨다. 즉, 안정적 운영과 함께 잘 안깨지게 구성이 가능하다. 읽기 성능이 좋아지는 것은 레플리카 구축되었을 시의 전리품이다.
처음 서비스 시작할 때는 단일 Master-Slave 구조 또는 레플리카셋(Replica-set) 로 구성한 후에 샤딩이 가능한 구조로 시작하는 편이 비용면에서 이득이다. (DB는 웹서버 보다 오래 버티기에 처음에는 적은 수로 구성해도 문제없다.)

그럼 어떤 클라우드 서비스를 쓰면 되나 ?

Auto Scaling과 Load Balancing 이 지원되는 클라우드 서비스를 선택하면 된다.
가장 많이 쓰는 AWS를 추천하며(가장 많이 쓴다는 것은 그만큼 개발자들의 레퍼런스도 많다는 의미이므로 자료를 구하기 수월하다)
최근에 한국 리전이 생긴 Microsoft 의 Azure를 선택하거나 (같은 요금대의 스펙이 AWS보다 약간 좋은 장점) , 최고의 가성비를 자랑하는 Google Cloud Platform을 사용할 수 있다. 요금이 가장 저렴한 Digital Ocean 으로는

국내에서만 서비스 하길 원한다면, 약간 더 저렴하게 이용할 수 있는데 KT의 Ucloud, 스마일서브의 iwinV  등의 클라우드 서비스를 이용할 수 있다. 물론 레퍼런스는 적기에 많은 시행착오가 필요할 것이다.


다음번에 실제로 node.js 를 이용한 Stateless 구조의 웹서버를 구축해보겠다. (아마 한참 걸릴 수도)

추신 : 요청 오면 바로 올릴 생각입니다. 아직 찾는 사람이 많지 않아.. 게으르기에..

오늘은 여기까지.