요즘 웹 서비스를 하나 만들면서 아마존 웹 서비스(Amazon Web Service - 이하 AWS) 를 이용하고 있다. 서버가 필요할 때 간단하게 EC2 인스턴스(한 대의 PC라고 생각하면 된다)를 하나 실행하고 필요한 라이브러리들을 설치하고 애플리케이션을 배치하고 서버를 시작하면 된다.
말은 간단하지만 EC2 이용 방법이 좀 까다로워서(서버를 직접 만질 수 있는 상황에 비해), 이를 자동화할 수 있는 스크립트를 따로 만들거나 별도의 라이브러리를 설치하거나 RightScale같은 도구 서비스를 이용하기 전까지는 애를 먹게 된다. EC2 계정 등록을 하고 public key와 private key를 다운받은 후 keypair를 생성하고 이를 이용해 EC2 인스턴스에 SSH로 접속할 수 있다.
RightScale을 이용하면 인스턴스 실행과 SSH콘솔 접속을 클릭 몇 번으로 할 수 있지만 그 콘솔이 윈도우나 리눅스 기본 터미널이 아니라 자바로 애뮬레이팅 한 것이라서 디스플레이에 문제가 있다. 그래서 개인적으로는 인스턴스 관리만 RightScale로 하고, 터미널에서 ssh 명령어를 통해 직접 접속을 한다.
Window는 SVN 저장소 설치에서부터 어려움이 많지만 ssh 접속에서도 장애물이 있었는데 Window에서 ssh 접속을 하려면 PuTTY를 이용해야 한다. PuTTY는 아마존에서 생성하는 keypair 포멧을 사용할 수 없어서 PuTTY Gen을 통해 keypair 포멧을 변형해줘야 한다는데 난 변형된 keypair로 EC2 인스턴스에 접속하는 데 실패했다.
그래서 생각한 꼼수는 VMWare로 우분투 리눅스를 게스트OS로 실행한 다음, 우분투의 터미널로 SSH 접속을 하는 것인데 지금은 만족하면서 사용하고 있다. VMWare가 야기할 수 있는 시스템 부하가 걱정되긴 하지만 우분투에서는 콘솔과 파일 브라우져만 사용할 것이기 때문에 아직까지는 문제없다.
아마존에서 기본적인 EC2 번들 이미지를 제공한다. 이미지는 OS 환경이라고 할 수 있다. 이미지의 인스턴스를 실행하면 그 OS 환경을 한 대의 서버로서 사용할 수 있게 된다. 인스턴스를 여러개 실행할 수 있는데 이는 동일한 환경의 서버를 여러 대 운용할 수 있게 됨을 의미한다. 개발자들은 자신이 직접 세팅한 OS를 이미지로 마운트해서 사용할 수 있다. 이 이미지를 S3에 업로드하고 private으로 사용하거나 public 이미지로 공개할 수 있다.
나는 이미지를 직접 마운트하거나 아마존에서 제공하는 이미지를 사용하지 않고 ec2onrails를 이용한다. Paul Dowman이 Ubuntu - Apache - Mongrel Cluster - Rails 구조로 세팅된 이미지를 public으로 공개해서 많은 호응을 얻었었는데, 그 이미지를 개선시키고 Capistrano Task와 묶어서 프로젝트로 발전시켰다.
나는 ec2onrails task들을 사용하지 않고 이미지만 사용한다. ssh 접속이나 svn 저장소 접근, gem 등 라이브러리 설치 등을 직접 한다. 반복적으로 수행해야 할 명령이 많아지면 인스턴스 내에서 .sh 파일로 만들어 실행할 생각이지 개발PC에서 원격으로 실행시키는 task에는 아직 익숙지 못한 것 같다. 하지만 곧 익숙해지지 않을까.
지금 일하는 방식은, 애플리케이션을 개발하다가 로컬의 SVN 저장소에 commit하고, EC2 인스턴스에서 그것을 update한 다음 seesaw::bounce 해주는 형태이다. 아마도 capistrano task를 만든다면 이 부분을 자동화하게 될 것 같다. seesaw를 이용해 서비스를 중단하지 않고 몽그렐 클러스터들을 재시작할 수 있다. bounce 중간에 아파치가 몽그렐 클러스터를 제대로 가리키지 못하는 문제가 있었는데 cypher님의 조언으로 해결이 되었다.
EC2는 호스팅 비용 치고 저렴한 편은 아니다. 그리고 인스턴스가 종료되면 모든 데이터가 날아간다. DB까지. 그래서 만약 데이터베이스나 사용자 업로드 파일을 EC2에 저장하고 있다면 반드시 주기적인 백업을 해주어야 한다. 실제로 올초에 EC2 인스턴스 중 일부가 집단으로 맛탱이가 가버려서 백업에 소홀했던 이들은 큰 피해를 입었다.
그럼에도 EC2를 사용해볼만한 가치가 있는 이유는 확장성과 트레픽-비용 비례 관계 때문이다. 일반 서버 호스팅을 받더라도 서버는 늘릴 수 있고, 대수가 늘어남에 따라 비용이 증가하는 건 마찬가지이지만 EC2는 그것을 굉장히 자유롭게 부담없이 할 수 있다. 오늘 단돈 몇 센트로 나만의 서버를 가질 수 있고, 다중서버 환경을 테스트하기 위해 10대의 서버를 구동해볼 수도 있다.
내가 지불해야 할 돈은 서버 10대의 가격이 아니라 시간 당 몇 센트와 트래픽 당 몇 센트의 비용이다. 그리고 트래픽이 증가해 지불해야 할 금액이 많아질 때가 온다면 아마 나는 그 트래픽(= 돈을 지불하거나 광고를 클릭해줄 사용자)만큼 돈을 벌고 있거나 적어도 내 서비스의 시장 가격은 훨씬 올라가 있을 것이라는 심리가 EC2를 선택하는 사람들에게 있지 않을까.
말은 간단하지만 EC2 이용 방법이 좀 까다로워서(서버를 직접 만질 수 있는 상황에 비해), 이를 자동화할 수 있는 스크립트를 따로 만들거나 별도의 라이브러리를 설치하거나 RightScale같은 도구 서비스를 이용하기 전까지는 애를 먹게 된다. EC2 계정 등록을 하고 public key와 private key를 다운받은 후 keypair를 생성하고 이를 이용해 EC2 인스턴스에 SSH로 접속할 수 있다.
RightScale을 이용하면 인스턴스 실행과 SSH콘솔 접속을 클릭 몇 번으로 할 수 있지만 그 콘솔이 윈도우나 리눅스 기본 터미널이 아니라 자바로 애뮬레이팅 한 것이라서 디스플레이에 문제가 있다. 그래서 개인적으로는 인스턴스 관리만 RightScale로 하고, 터미널에서 ssh 명령어를 통해 직접 접속을 한다.
Window는 SVN 저장소 설치에서부터 어려움이 많지만 ssh 접속에서도 장애물이 있었는데 Window에서 ssh 접속을 하려면 PuTTY를 이용해야 한다. PuTTY는 아마존에서 생성하는 keypair 포멧을 사용할 수 없어서 PuTTY Gen을 통해 keypair 포멧을 변형해줘야 한다는데 난 변형된 keypair로 EC2 인스턴스에 접속하는 데 실패했다.
그래서 생각한 꼼수는 VMWare로 우분투 리눅스를 게스트OS로 실행한 다음, 우분투의 터미널로 SSH 접속을 하는 것인데 지금은 만족하면서 사용하고 있다. VMWare가 야기할 수 있는 시스템 부하가 걱정되긴 하지만 우분투에서는 콘솔과 파일 브라우져만 사용할 것이기 때문에 아직까지는 문제없다.
아마존에서 기본적인 EC2 번들 이미지를 제공한다. 이미지는 OS 환경이라고 할 수 있다. 이미지의 인스턴스를 실행하면 그 OS 환경을 한 대의 서버로서 사용할 수 있게 된다. 인스턴스를 여러개 실행할 수 있는데 이는 동일한 환경의 서버를 여러 대 운용할 수 있게 됨을 의미한다. 개발자들은 자신이 직접 세팅한 OS를 이미지로 마운트해서 사용할 수 있다. 이 이미지를 S3에 업로드하고 private으로 사용하거나 public 이미지로 공개할 수 있다.
나는 이미지를 직접 마운트하거나 아마존에서 제공하는 이미지를 사용하지 않고 ec2onrails를 이용한다. Paul Dowman이 Ubuntu - Apache - Mongrel Cluster - Rails 구조로 세팅된 이미지를 public으로 공개해서 많은 호응을 얻었었는데, 그 이미지를 개선시키고 Capistrano Task와 묶어서 프로젝트로 발전시켰다.
나는 ec2onrails task들을 사용하지 않고 이미지만 사용한다. ssh 접속이나 svn 저장소 접근, gem 등 라이브러리 설치 등을 직접 한다. 반복적으로 수행해야 할 명령이 많아지면 인스턴스 내에서 .sh 파일로 만들어 실행할 생각이지 개발PC에서 원격으로 실행시키는 task에는 아직 익숙지 못한 것 같다. 하지만 곧 익숙해지지 않을까.
지금 일하는 방식은, 애플리케이션을 개발하다가 로컬의 SVN 저장소에 commit하고, EC2 인스턴스에서 그것을 update한 다음 seesaw::bounce 해주는 형태이다. 아마도 capistrano task를 만든다면 이 부분을 자동화하게 될 것 같다. seesaw를 이용해 서비스를 중단하지 않고 몽그렐 클러스터들을 재시작할 수 있다. bounce 중간에 아파치가 몽그렐 클러스터를 제대로 가리키지 못하는 문제가 있었는데 cypher님의 조언으로 해결이 되었다.
EC2는 호스팅 비용 치고 저렴한 편은 아니다. 그리고 인스턴스가 종료되면 모든 데이터가 날아간다. DB까지. 그래서 만약 데이터베이스나 사용자 업로드 파일을 EC2에 저장하고 있다면 반드시 주기적인 백업을 해주어야 한다. 실제로 올초에 EC2 인스턴스 중 일부가 집단으로 맛탱이가 가버려서 백업에 소홀했던 이들은 큰 피해를 입었다.
그럼에도 EC2를 사용해볼만한 가치가 있는 이유는 확장성과 트레픽-비용 비례 관계 때문이다. 일반 서버 호스팅을 받더라도 서버는 늘릴 수 있고, 대수가 늘어남에 따라 비용이 증가하는 건 마찬가지이지만 EC2는 그것을 굉장히 자유롭게 부담없이 할 수 있다. 오늘 단돈 몇 센트로 나만의 서버를 가질 수 있고, 다중서버 환경을 테스트하기 위해 10대의 서버를 구동해볼 수도 있다.
내가 지불해야 할 돈은 서버 10대의 가격이 아니라 시간 당 몇 센트와 트래픽 당 몇 센트의 비용이다. 그리고 트래픽이 증가해 지불해야 할 금액이 많아질 때가 온다면 아마 나는 그 트래픽(= 돈을 지불하거나 광고를 클릭해줄 사용자)만큼 돈을 벌고 있거나 적어도 내 서비스의 시장 가격은 훨씬 올라가 있을 것이라는 심리가 EC2를 선택하는 사람들에게 있지 않을까.
댓글을 달아 주세요