소셜 네트워크 어플을 개발할 때, 필연적으로 사용자들의 데이터를 처리를 위해서 백엔드 서버(backend server)를 사용하게 된다. 요즘 백엔드 서버는 RESTful API 형태로 요청을 받고 사용자 어플에게 응답한다. 나 역시 백엔드 서버가 필요했기에 간단하게 서버 구성을 시도해보았다.
백엔드 서버를 돌리기(running) 위해서는 크게 하드웨어 서버 장비와 이 장비 위에서 수행될 소프트웨어 서버 솔루션이 필요하다. 요즘은 많은 경우 비싼 서버 장비를 구매하여 IDC 센터에서 돌리지 않고, Amazon Web Service(이하 AWS), Joyent, goole AppEngine 같은 클라우드 서비스를 이용해서 간접적으로 서버를 돌리는 것 같다. 장비를 직접 구매하는 것에 비해 초기 자본이 거의 발생하지 않기 때문에 대부분의 스타트업은 클라우드 서비스를 선택하는 추세이고, 서버 스케일링이나 로드밸런싱, 하둡기반 분산처리가 안정적으로 이뤄지기 때문에 기존 업체들도 클라우드 서비스로 이동을 하고 있다. AWS 대표적인 사례는 아래와 같다.
http://aws.amazon.com/ko/solutions/case-studies/
클라우드 서비스 시장에서는 AWS가 대략 25%로 1위이다. 구글이나 IBM 등 경쟁 업체들에 비해 일찍 시작한 이유도 있겠지만 단지 그 이유때문이겠는가. 클라우드 서비스의 질이나 사용성이 다른것들에 비해 편리하거나 다른 무언가가 있지 않을까 늘 궁금했었다. 그래서 이번에 클라우드 서비스를 선택할 때 주저 없이 AWS를 사용해보기로 결심했다. AWS에는 아래와 같이 상당히 많은 하위 서비스들이 존재한다. 와우..
이 중 Amazon EC2 가이드를 따라 했더니 내 서버가 금방 만들어졌다.
http://docs.aws.amazon.com/gettingstarted/latest/computebasics-linux/getting-started.html
- AWS 계정 생성,
- Auto Scaling 커맨트라인 툴 설치,
- Debian linux AMI로 가상서버 인스턴스 생성,
- 서버 시큐리티 그룹 생성,
- custom AMI 생성,
- Load Balancer 생성,
- Auto Scaling 으로 서버 생성/종료하기
가상화 기술을 이용해서 AWS가 내가 있는 동북 아시아 쪽에 위치한 서버장비에서 가상서버 인스턴스를 한개 생성해주었다. 아마존 서버 인프라는 전세계 8개 지역(Region)에 흩어져 있고, 각 지역은 몇개의 가용존(Availability Zone)을 가지고 있다. 가용존에 실제 아마존 서버들이 위치해 있다. 한국이 있는 동북 아시아의 지역(Region)은 도쿄가 본부이고(에잇!), 가용존은 2개가 있다.
AMI (Amazon Machine Image) 는 가상서버 인스턴스가 실행될 때 바라보는 운영체제 이미지인데 아마존이 제공하는 것 외에도 AWS Marketplace 에 수많은 AMI가 올라와있다. AWS를 사용하는 개인 또는 기업, 커뮤니티들이 각자의 용도에 맞게 서버 설정을 해놓은 것들을 AMI 로 만들어서 공유가 되고 있다. 가령 설치형 WordPress AMI 이나 다음 포스팅 주제인 node.js + mongo db AMI 등을 들수있다. 오픈소스 기반의 AMI는 대부분 무료이다. 나는 debian7 wheezy AMI로 서버 인스턴스를 생성했다. 서버 인스턴스마다 public DNS와 IP가 할당되지만 기본적으로 인스턴스를 재부팅하면 이 값들은 바뀐다. 그래서 서버 인스턴스가 고정 IP를 받으려면 먼저 Elastic IP 서비스로 요청해야 한다.
Auto Scaling과 Load Balancer 는 각각 서버 인스턴스 갯수를 조절하고 트래픽을 분산시키는 서비스를 의미한다. 소셜 네트워크 어플의 특성상 갑자기 많은 유저들이 접속을 할 수가 있는데, 그런 트래픽을 빠르게 처리할 방법이 필요하다. 클라우드 환경에서는 AMI같은 이미지를 이용해 가상 서버 인스턴스를 쉽게 생성하거나 반대로 제거할 수 있기 때문에 트래픽 상황에 맞게 인스턴스 갯수를 줄였다 늘였다 할 수 있다. 이것이 중요한 이유는 사용한 만큼 내는 AWS의 가격정책 때문이다. 트래픽이 없는데도 서버 인스턴스를 많이 생성해놓는다면 불필요하게 요금이 청구될 수 있다. 사용자는 aws 커맨드를 이용해서 Auto Scaling 그룹과 정책을 지정할 수 있으며 이후엔 아마존 클라우드 환경이 이 설정에 따라 auto scaling을 수행하게 된다. 딱 필요한 만큼 서버 인스턴스를 돌리자.
ssh를 이용해서 각 서버 인스턴스에 접속할 수 있으며 sudo 그룹의 유저 또는 루트로 로그인이 되니 각종 패키지를 설치/삭제할수 있고 서버 환경을 자신의 서비스에 맞게 설정할 수 있다. 테스트를 위해서 apache2, php5, php5-mysql extension, mysql을 설치한 후 WordPress 최신 버전을 설치해봤다. 뭐 예상대로 잘 나왔다.
소셜 네트워크 어플을 준비하는 단계에서는 서버 인스턴스 하나로 충분히 기능 검증이 가능하기에 Auto Scaling과 Load Balancer는 어플서비스 런칭 직전으로 미루어도 될 것 같다. 클라우드 서비스를 이용하기 때문에 개발 초기에 트래픽을 예측하고 미리 서버 및 네트워크 환경을 구성해야 하는 머리 아픈 상황을 피할 수 있다. 참으로 스타트업이 활성화되기에 좋은 환경이다.
직접 AWS의 일부 서비스를 써보니 사용성과 속도면에서 매우 만족스러웠다. 많은 스타트업과 기업들이 이용하는 이유를 어느 정도 이해할 것 같다. 당분간은 내 AWS 서버 인스턴스에 많이 접속할 듯.
AWS 관련하여 유용한 자료 몇개를 링크한다.
http://docs.aws.amazon.com/gettingstarted/latest/computebasics-linux/getting-started.html
http://opentutorials.org/course/608/3004
My name is Yunchan Cho. I love web and its technology. I hope that my life makes peoples to be inspired and encouraged. twitter: @yunchancho
Vine Brancho 
Leave a comment