블로그 이미지
평범하게 살고 싶은 월급쟁이 기술적인 토론 환영합니다.같이 이야기 하고 싶으시면 부담 말고 연락주세요:이메일-bwcho75골뱅이지메일 닷컴. 조대협


Archive»


 
 

구글 클라우드 MySQL서비스의 흥미로운 가격 정책

조대협 (http://bcho.tistory.com)


구글 클라우드의 MySQL 서비스인 CloudSQL을 보다보니, 신기한 가격 정책이 있어서 정리해놓고자 한다.

1세대와 2세대의 가격 정책이 다른데, 1세대의 가격 정책이 재미있는점이 있다.


기본 가격 정책


1,2세대 모두 기본 적인 가격 정책은 다음과 같다


저장량 + 인스턴스 기동 비용 + 네트워크 비용

  • 저장량은 말 그대로 저장된 데이타의 양에 따라 과금이 된다
  • 네트워크 비용은 outbound로 나가는 트래픽만 과금이 되는데, 이것도 같은 리전 안의 구글 클라우드에서 호출하는 경우에는 과금이 되지 않는다. 과금이 되는 경우는 구글 클라우드를 쓰더라도 다른 대륙의 인스턴스가 호출을 하거나 또는 다른 클라우드 서비스에서 호출을 하는 경우에만 과금이 되기 때문에, 일반적인 상황에서는 거의 네트워크 트래픽 비용이 과금이 되지 않는다.
  • 인스턴스 기동 비용은 인스턴스가 떠있는 동안데 받는 비용인데 이 부분이 흥미롭다.
인스턴스 가동 비용

1세대 CloudSQL 경우 Package plan 과 Pay per use plan 두가지가 있다.
Package Plan은 일단위 과금이며, 인스턴스가 기동이 되어 있는 일 기준으로 과금이 된다. 이건 모 일반적인 것이고
흥미로운 가격 정책이라고 하는것은 Pay per use plan이다. Pay per use plan은 인스턴스가 떠 있는 시간동안 분당 과금을 하는 것이다. 일반적인 분당 과금 처럼 보일 수 있지만 재미 있는 것은 Cloud SQL 인스턴스 생성시 activation policy (활성화 정책) 이라는 것을 설정할 수 있는데, 이 활성화 정책을 ALWAYS(항상) 으로 해놓으면, 인스턴스를 수동으로 내리지 않는 이상은 항상 떠 있는 케이스이다. 여기까지가 일반적인것이고
활성화 정책중 ON DEMAND(요청시)로 해놓으면, MySQL이 15분 동안 아무 Request가 없으면 해당 MySQL 인스턴스는 자동으로 비활성화 되고 인스턴스 비용이 과금되지 않는다. 비활성화 상태에서 요청이 들어오면 자동으로 활성화 상태가 된다. ON DEMAND는 활성화 상태에서 사용량을 분당으로 과금한다.

아래 그림은 CloudSQL 인스턴스를 생성할때, ON DEMAND 활성화 정책 + 사용량에 따른 청구 방식으로 설정하는 화면이다.




쉽게 설명하면, 서버에 요청이 없으면 자동으로 대기 상태로 들어가면서 데이타 저장 비용만 과금이 되고, 인스턴스 비용은 과금이 되지 않는다는 이야기이다.

이는 항상 서버가 돌아도 되지 않는 일 배치나 또는 개발 환경등에 유용하게 사용될 수 있다. 
물론 이렇게 인스턴스가 될때만 과금하게 하는 것은 수동으로 데이타를 백업 받고 인스턴스를 내렸다가 사용할때 인스턴스를 새로 올리고 데이타를 부어도 되고 또는 수동으로 일일이 인스턴스를 껐다 켰다 해도 유사한 효과를 볼 수 는 있지만, AWS의 경우 시간당 과금이기 때문에, 개발 환경처럼 수분을 쓰고 마는 환경에서는 분당 과금인 CloudSQL에 비해서 금액 절약효과를 보기가 어렵고, 무엇보다 귀찮다.

아래는 20GB 용량을 하루에 4시간 정도 D32 인스턴스로(32GB 메모리 머신) , 300만 IO가 발생하는 일배치를 돌리는 시나리오에서 추가 IO가 없다고 가정할때 가격 시뮬레이션 한 케이스인데 Package plan을 이용할 경우 약 한달에 1116$, Pay per use plan을 사용할 경우 약 338$ 로 약 3.4배 정도의 가격 차이가 있는 것을 확인할 수 있다. 
(참고, Package Plan의 D32 인스턴스는 300만 IO까지는 무료이며, Pay Per Plan의 경우 무조건 100만건당 0.1$가 과금된다. 아래 계산 결과는 Pay per use는 모든 IO 가 과금이 되기 때문에 # of IO를 300만으로 입력하였고, Package Plan은 무료 IO를 넘는 부분에 대해서만 입력하기 때문에, 현재 계산에서 300만 IO는 D32 인스턴스 크기에서는 무료이기 때문에 별도 입력하지 않았다.)




1세대의  Pay per use plan을 사용하면 딱 트렌젝션을 돌릴때만 분당 과금을 할 수 있기 때문에 가격이 저렴해진다.
단 주의 할점은 오랜 시간 서버를 돌리는 경우에는 Pay per use plan 보다는 당연히 Package plan이 저렴하기 때문에 일정 시간 이상 인스턴스를 사용하는 경우는 Pay per use 보다는 package plan을 사용하기 바란다.

가격 정책에 대한 자세한 내용은 https://cloud.google.com/sql/pricing 에 있다. 
어떤 정책이 유리한지는 가격 시뮬레이션을 해보면 되는데 시뮬레이션용 계산기는 https://cloud.google.com/products/calculator/ 를 사용하기 바란다.



Vagrant를 이용한 개발환경 관리(간단한 VM관리)

ALM | 2013.10.24 00:48 | Posted by 조대협

Vagrant

시작하기

Vagrant는 한마디로 이야기 하면, “간소화된, VM 관리 서비스이다”. 이미 Virtual Machine 환경은 보편화 되서 사용되고 있고, VMWare Oracle Virtual Box등을 이용하면 PC에서도 손쉽게 VM 환경을 구축할 수 있다. 그러나 문제점은, Virtual Box와 같은 Hypervisor가 있다고 해도, VM을 생성하는 것 자체가 번거로운 작업이라는 것이다.

 Hypervisor에서 논리적인 가상 하드웨어 머신을 생성하고 가상머신에 OS를 설치하고, 일일이 설정을 해줘야 한다. 이런 반복적인 작업을 조금더 손쉽게 자동화 할 수 없을까? 하는 아이디어에서 시작한 것이 Vagrant이다.

먼저 이해를 돕기 위해서 예제를 실행해보자.

Vagrant VM 관리도구 이기 때문에, 먼저 Hypervisor 부터 인스톨을 해야 한다.

https://www.virtualbox.org/ 에서 Virtual Box를 다운로드 받아서 설치하자.

다음으로 http://www.vagrantup.com/ 에서 vagrant를 받아서 인스톨한다. 이제 준비가 끝났다.

아래와 같이 vagrant init precise32 http://files.vagrantup.com/precise32.box 를 실행하면, Ubuntu Linux VM의 실행하기 위한 설정들을 자동으로 가지고 온다. 그리고 vagrant up 명령어를 실행하면 해당 설정에 따른 VM 을 자동으로 다운받아서 설치하고 Virtual Box를 통해서 해당 VM을 기동 시킨다. Putty를 이용하여 SSH localhost:2222 번으로 접속 (id:vagrant, passwd:vagrant)를 입력하면, 생성된 VM에 로그인할 수 있다. 또는 간단하게 “vagrant ssh”라고 실행하면, 현재 생성된 VM에 자동으로 SSH로 연결된다.



Vagrant 없이 Virtual Box에서 직접 Ubuntu VM을 설치하려면 VM을 만들고, Ubuntu OS를 설치해야 한다. 그러나 Vagrant가 있으면 이렇게 간단하게 두줄의 명령어로 VM을 만들고 실행시킬 수 있다.

Box 개념 이해하기

앞에서 vagrant init 명령을 실행할때, preceise32.box라는 파일을 지정하였다. box 파일은 VM을 만들기 위한 기본 OS 이미지를 포함한 VM 설정(CPU,메모리 사이즈등)에 대한 기본 템플릿이다. (사이즈가 보통 수백 메가가 나간다.)

http://www.vagrantbox.es/ 에 보면 공개된 box 파일들이 있다. Ubuntu, Debian 등 다양한 Linux OS 버전의 VM 들에 대한 box 파일들이 있다.

Vagrant file

Vagrant init을 하면, 해당 디렉토리에 “Vagrantfile” 이라는 이름으로 생성되는 파일인데, Box VM 생성을 위한 기본 템플릿이라면, Vagrant file은 생성될 VM에 대한 세부 설정을 정의한다. VM을 생성할때, 어떤 box 파일을 사용할 것인지, VM에 대한 하드웨어 설정 예를 들어 CPU,메모리 사이즈,네트워크, 네트워크 포트포워딩 설정등을 여기서 재정의 할 수 있다.

아래는 Oracle Virtual Box실행시 preceise32 box 이미지를

http://files.vagrantup.com/precise32.box 에서 읽어와서, CPU 2, 512M를 가진 “Terry_vargrant0”이라는 VM을 생성하는 Vagrantfile이다. 아래와 같이 파일을 생성한후에, vagrant up 명령을 수행시키면 설정한 정보 대로 VM이 생성된다.

VAGRANTFILE_API_VERSION = "2"

 

Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|

  config.vm.box = "precise32"

  config.vm.box_url = "http://files.vagrantup.com/precise32.box"

  # config.vm.network :forwarded_port, guest: 80, host: 8080

  # config.vm.network :private_network, ip: "192.168.33.10"

  # config.vm.network :public_network

  # config.ssh.forward_agent = true

  config.vm.provider "virtualbox" do |vm|

        vm.customize [

               "modifyvm",:id,

               "--memory","512",

               "--name","Terry_vagrant0",

               "--cpus","2",

                       ]

  end

end

 

Vagrant + Provisioning

Vagrant를 이용하면, VM을 쉽게 만들 수 있다. 그런데 개발환경을 구축하자면, OS가 인스톨된 VM 뿐만 아니라, 그위에 웹서버,DB등 미들웨어들을 설치해야 하고, 그리고 거기에 맞는 Configuration을 해야 한다. 물론 미리 VM 이미지에 웹서버등을 설치해놓고, 필요에 따라서 vagrant를 이용해서 해당 VM들을 설치해서 사용해야 하지만 그 경우에는 설정마다 매번 다른 VM이미지를 만들어놔야 하기 때문에 번거롭다. 만약에 OS 만 설치된 VM에다가, 설정에 따라서 소프트웨어와 설정을 하는 부분을 분리한다면?

이런 접근을 지원하는 기능이 Vagrant provisioning이라는 기능이 있다. VM을 기동한 후에, vagrantfile에 정의된 provisioning script를 수행해준다. 다음 예제를 보자. 다음 예제는 VM이 기동된 후에, apt-get 명령을 이용해서 apache2 (웹서버)를 자동으로 설치하는 설정이다.

VAGRANTFILE_API_VERSION = "2"

 

Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|

  config.vm.box = "precise32"

  config.vm.box_url = "http://files.vagrantup.com/precise32.box"

config.vm.provision :shell, :inline => "sudo apt-get install -y apache2"

 

end

위의 예제는 VM이 기동될때 마다 shell 명령어를 수행하도록 한것인데, 명령어말고도 shell스크립트를 수행하게 할 수 도 있고, puppet이나 chef와 같은 configuration management 도구를 이용해서, 제품을 설치하게 할 수 도 있다.

한 가지 주의할점은 Vagrantfile provision 부분에 정의된 명령어는 vagrant up, reload, provision 3개의 명령어가 실행될때 마다 매번 실행된다. up에서도 매번 실행되기 때문에, 스크립트내에, 해당 소프트웨어가 미리 설치되었는지 확인한 후에, 설치가 안되어 있을 경우에만 설치하도록 스크립트를 짜는 것이 좋다.

Provisioning에 대한 자세한 방법은 http://docs.vagrantup.com/v2/provisioning/index.html 를 참고하면 된다.

Vagrant를 이용한 개발 환경 구축

그러면 Vagrant를 이용해서 개발환경을 어떻게 구축할 수 있는지 살펴보도록 하자



크게 그림과 같이 2개의 repository가 필요하다. Box image repository에는 기본 이미지가 인스톨된 box image들을 저장해놓는다.

그리고 svn이나 git와 같은 VCS 툴에 vagrantfile을 저장해놓는다. (아니면 간단하게 웹서버에 저장해놔도 된다.) Vagrantfile에는 box 파일들을 저장해놓은 repository pointing 하도록 하고, 필요에 따라서

1.  Ubuntu + Apache

2.  Ubuntu + MySQL

3.  Ubuntu + Tomcat

와 같이 다양한 설정을 만들어 놓고, 필요에 따라서 Vagrantfile이 받은 후에, 간단하게 “vagrant up” 명령어만 수행하면 간단하게 개발환경에 필요한 VM을 만들어낼 수 있다.

지금까지 간략하게 Vagrant에 개념과 사용법에 대해서 알아보았다.Vagrant는 그외에도, Vagrant는 단일 VM 뿐만 아니라 multi vm을 단일 vagrantfile에서 설정이 가능하고, Oracle Virtual Box뿐만 아니라,VMWare Amazon EC2 클라우드 까지 지원한다. 간단하게는 개발환경에서 부터,응용하면, QA,스테이징,운영환경 배포용으로도 활용할 수 있다.

자세한 내용들은 http://docs.vagrantup.com/ 를 참고하기 바란다

Cloud Front

조대협

Cloud Front CDN (Contents Delivery Network) 서비스 이다. 이미지나 동영상 같은 정적인 컨텐츠들을 서비스하는데, 서버가 있는 데이타 센터에서 서비스를 하게 되면, 네트워크 latency 때문에 성능이 저하가 되기 때문에, 전세계의 여러 개의 데이타 센터에 서버(이를 edge node 또는 edge server라고 함) 를 넣고, 클라이언트와 가까운 데이타 센터로 부터 컨텐츠를 제공하는 서비스 이다.

얼마나 많은 지역별 데이타 센터에 edge node를 설치하고 서비스를 제공하느냐, edge node의 네트워크 대역폭이나 용량은 충분하느냐가 서비스의 품질을 결정하는데, 세계적으로 Akamai Limelight 등의 업체가 유명하다.

아마존의 경우에도 얼마전부터 Cloud Front라는 이름으로 CDN 서비스를 제공하는데, 아마존 인프라와 융합되어 몇 가지 특별한 기능들을 제공한다.

아래 http://media.amazonwebservices.com/FS_WP_AWS_CDN_CloudFront.pdf 그림은 Frost & Sullivan 이라는 곳에서 작성한 CDN의 성능 비교표로, 아마존 Cloud Front가 다른 경쟁사에 비해서 성능적으로 우세거나 동등 수준으로 나온다. 물론 테스트 환경이나 시나리오에 따라 다소 다르겠지만, 아마존도 계속 해서 edge node를 증설하고 있는 상황이기 때문에 상용 수준의 CDN 성능을 제공할 수 있을 것이라고 본다.



 

Cloud Front 동작 시나리오

그럼 먼저 Cloud Front가 어떻게 작동하는 지를 살펴보도록 하자.



   Client가 웹사이트에 접속한다. 웹사이트를 www.terry.com이라고 하자.

   Client DNS 서버를 통해서 www.terry.com 의 주소를 look up 한다. 이 때, www.terry.com cloud front URL로 맵핑이 되어있어야 하는데, CNAME 레코드를 이용하여 www.terry.com을 해당 사이트에 대한 Cloud Front URL 로 맵핑 해놓는다. 여기서는 asdf.cloudfront.net이라고 가정하자

   Client asdf.cloundfront.net 의 주소를 다시 look up을 하는데, Route53에 의해서, Client와 가장 가까운 위치에 있는 Cloud Front edge node 주소를 리턴 받게 된다.

   Client는 리턴 받은 ip를 가지고 Cloud Front edge server로 접속을 한다.

   Cloud Front에는 URL에 따라서 resource의 위치를 RULE로 정해놓는데, 위의 예에서는 /image 디렉토리의 파일은 S3에 원본을 두고 Cloud Front에 캐슁하도록 하고, /css/ 아래 파일들은 원격지에 있는 (Amazon이 아닌) 서버에 두고 캐슁을 하도록 하였다. 그리고 *.jsp 파일은 캐슁 없이 직접 원본 서버로 가도록 하였다.

   만약에 /image/ /css/에 있는 파일을 Client가 요청 하였을 경우 edge node의 캐쉬를 체크해보고, 캐쉬에 내용이 없으면 원본 서버로 부터 파일을 읽어서 캐쉬에 저장한 후에, Client에 리턴한다. 캐쉬에 있을 경우에는 바로 리턴을 한다.

Origin Server

앞에서 설명한 시나리오에서 원본 파일이 저장되는 곳을 Origin Server라고 한다.

Origin Server AmazonS3 bucket이나 EC2 인스턴스 또는 Amazon 밖의 서버가 될 수 있다.

서비스가 가능한 컨텐츠의 종류

Cloud Front를 통해서 서비스가 가능한 컨텐츠의 종류는 다음과 같다.

Ÿ   Download Distribution : HTTP 프로토콜을 이용해서 다운로드 받을 수 있는 이미지나 기타 정적인 리소스 파일

Ÿ   Streaming Distribution : HTTP Progressive Down load RTSP(Real Time Streaming Protocol)을 지원하는 동영상 컨텐츠

Cache 동작

CDN은 기본적으로 컨텐츠를 edge node에 캐쉬 해놓는 것을 기능으로 한다. 캐쉬이기 때문에 유지 시간 TTL이 있는데, 기본 TTL 시간은 24시간이고 최대 1시간으로 까지 줄일 수 있다.

그런데 만약 파일을 잘못 올렸거나, 수정이 필요할 때 캐쉬의 TTL 시간에 의해서 수정이 edge node에 반영되는 시간까지 최소 1시간이 소요된다.

이런 문제를 해결하기 위해서 Cloud Frontinvalidation API (특정 파일을 캐쉬에서 지우는 기능)을 제공하는데, 한번에 3개의 invalidation request밖에 실행할 수 없으며, invalidation request는 최대 1000개의 파일까지만 지원한다. 그리고 invalidation request는 모든 edge node에 반영되어야 하기 때문에, 보통 5~10 분 정도의 시간이 소요된다.

그래서 조금 더 빠르게 캐쉬에서 컨텐츠를 업데이트 하기 위해서는 버전을 사용하기를 권장하는데, 쉽게 이야기 해서 파일명을 바꾸도록 하는 것이다. /image/photo.png가 있을때, 이 파일이 변경되기를 원할 경우, HTML 원본에서 해당 이미지 명을 /image/photo_v2.png로 변경하고,새로운 파일명도 photo_v2.png로 저장을 하면 별도의 cache invalidation 작업 없이 바로 변경 내용을 반영할 수 있다.

 

또는 파일명을 바꾸는 게 부담 스러울 경우에는 Query String을 사용할 수 있다.

예를 들어 /image/photo.png?version=1.0 으로 HTML에서 이미지 경로를 걸어 놓으면, Cloud Front "photo.png?version=1.0"을 키로 캐쉬에 파일을 저장한다. Origin server에 이렇게 파일을 요청하게 되면, 이 파일은 정적인 컨텐츠이기 때문에, Query String은 무시 되고, Origin Sever "photo.png" 파일만 리턴한다. 원본 컨텐츠가 바뀌었을 경우, 원본 컨텐츠의 파일명은 변환할 필요가 없이 똑같이 "photo.png" 파일로 저장을 하되, HTML의 참조명을 /image/photo.png?version=2.0으로만 바꿔 주면, Cloud Front입장에서는 resource의 이름이 아까와 다른 이름이기 때문에, Cache에서 찾지 못하고 다시 Origin Server로 요청하게 된다

(Query String을 버전명으로 사용하기 위해서는 Cloud Front설정에서 Query String by pass 기능을 on 해줘야 한다.)

비공개 컨텐츠에 대한 접근 제어

다음으로 이런 정적인 컨텐츠를 다루다 보면 특정 사용자에게만 서비스를 제공해야 하는 경우가 있다. 예를 들어 유료 앱 다운로드나, 유료 동영상 서비스같은 것이 좋은 예가 되는데, Cloud Front Signed URL이라는 기능을 이용해서, CDN 컨텐츠에 대한 접근 제어 기능을 제공한다.

원리는 간단하다. CDN의 특정파일에 대한 접근 권한을 {ip 주소, 다운로드 가능 시간 시작~} (접근 권한의 각 필드는 필수가 아니라 선택 사항이다. 또한 ip 주소는 특정 ip ip 주소 대역으로도 정할 수 있다.) 으로 정하고, URL을 생성한 후 암호화 하여 사용자에게 제공하는 것이다.

그러면 그 URL CDN내의 컨텐츠를 접근하면, 접근 권한에 정의된 조건을 충족하면 다운로드를 할 수 있도록 해준다.

아래는 아마존 웹사이트에서 발췌한 Signed URL 샘플이다.


1) 이 부분의 resource 파일명을 정의한다.

2),3) Query String을 정의 하는 부분이다. 원본 파일(Origin Server)로 전달되는 Query String이다.

4) Policy 로 앞에서 언급한 접근 가능 정책 {ip 주소, 접근 가능 기간} JSON으로 정의한후에 encoding string이다.

5) HMAC과 유사하게 이 URL이 변조되는 것을 막기 위해서 URL에 대한 Signature Base64 encoding을 이용해서 생성해서 붙인 부분이다. (일종의 Hash값으로, URL에 대한 Hash URL이 변조되면 이 Hash 값과 맞지 않는다.)

6) Key로 아마존 Cloud Front 사용을 위해서 발급된 키이다.

Signed URL 이외에 사용자 계정을 통해서 접근을 제어할 수 있는 방법이 있는데, 이 계정은 아마존 계정 서비스인 IAM을 통해서 생성된 계정만을 통해서만 가능하다. 참고로 IAM 계정 서비스는 최대 5000개의 계정만 생성 및 관리가 가능하기 때문에, 대외 서비스에는 적절하지 않고, 소규모 대내 서비스나 또는 내부 관리 용도로 CDN 접근 제어를 할대 유용하게 사용할 수 있다.

부가적인 기능

그 밖에도 몇가지 부가적인 기능들이 있다. SSL을 통해서 컨텐츠를 서비스 하는 기능이나, 또는 컨텐츠 서비스 내용을 HTTP access 로그로 남겨서 S3에 저장하는 기능들이 있다.

성능 향상 방법

Cloud Front를 사용하는데 있어서 몇 가지 성능을 향상 시킬 수 있는 테크닉이 있어서 소개하고자 한다.

1) Domain Sharding : 일반적으로 웹브라우져는 하나의 도메인 주소에 대해서 동시에 열 수 있는 네트워크 Connection 수가 제한이 있다. IE7의 경우에는 한 도메인당 2, Chrome IE8/9 6, Fire Fox의 경우에는 8개이다. 그런데 일반적인 웹 페이지에서 동시에 로딩되는 리소스는 대략 20~50개 정도가 된다.즉 웹브라우져가 여는 Connection 수로는 한꺼번에 모든 리소스 로딩이 어렵다는 것이다. 일반적인 CDN에서도 적용될 수 있는 기법인데, 하나의 시스템에 여러개의 도메인을 적용하는 것이다. 예를 들어 서버의 주소가 210.113.119.210 이라고 하고, 도메인 명이 www.terry.com 이라고 하자.CNAME으로 image.terry.com, resource.terry.com, css.terry.com 등 여러개의 도메인을 같은 URL을 가리키도록 해놓고, HTHL에서도 image url "src="http://image.terry.com/img/myimage.png" 식으로 지정해놓게 되면 브라우져 입장에서는 전혀 다른 사이트로 인식하기 때문에, 별도의 네트워크 Connection을 열 수 있다. 이 방법을 사용하면 브라우져의 Connection을 최대로 열어서 전체적인 웹사이트 Loading Time을 증가시킬 수 있다.

 

2) Compression : CDN은 네트워크에 관련되는 서비스이기 때문에 당연히 원본 컨텐츠의 사이즈가 작으면 성능이 사용하는 대역폭도 작아지고, 성능도 더 잘 나온다. 압축 기능을 사용하기 위해서는 Origin server apache와 같은 웹서버인 경우에는 gzip compression 기능을 웹서버에 적용해주면 되지만, S3 Origin server로 사용하는 경우에는 S3 자체에는 gzip compression 기능을 가지고 있지 않기 때문에, 컨텐츠를 할때 gzip으로 압축해서 올리고 "Content-Encoding" gzip으로 명기해주면 된다.

 

가격 체계

Cloud Front edge node의 위치에 따라서 가격이 다르다. 과금은 Out bound traffic을 기준으로 하는데, 아래 그림과 같이 South Africa가 다른 region에 비해서 가격이 월등하게 비싸다. Cloud Front를 사용하기 전에, 먼저 서비스를 하고자 하는 국가등을 미리 고려한 후에, 가격과 함께 사용지역을 고려하기를 권장한다.



'클라우드 컴퓨팅 & NoSQL > Amazon Web Service' 카테고리의 다른 글

Auto scaling out  (1) 2013.09.11
Amazon의 CDN 서비스 Cloud Front  (0) 2013.09.10
Amazon Route 53 DNS 서비스  (0) 2013.09.09
Amazon Elastic Load Balancer  (2) 2013.09.09
Amazon Direct connect  (0) 2013.09.06
Amazon VPC (Virtual Private Cloud) 소개  (3) 2013.08.18

Amazon Route 53 DNS 서비스

조대협

Route53은 아마존에서 제공하는 DNS 서비스 이다. 일반 DNS와 다르게 몇 가지 아마존에 특성화된 몇 가지 기능을 가지고 있는데, 특화 기능에 앞서서 DNS 의 일반 개념을 먼저 정리해 보자.

DNS domain name (www.example.com) ip 주소로 바꿔 주는 일종의 dictionary 서비스 이다.

이러한 맵핑 정보를 저장해 놓는 파일을 DNS Zone file이라고 한다.

 

이 서비스는 DNS 서버에 저장해놓은 파일을 기반으로 주소를 변환하는데, 여기에 정의되는 레

코드들 중에서 대표적은 레코드는 다음과 같다.

 

   SOA 레코드 : 해당 DNS 서버 자체의 설정 정보를 정의 한다.

Ÿ   DNS 서버는 Primary/Secondary 구조로 장애 대응을 할 수 있는 구조인데, 이를 위해서 SOA 레코드에는 이를 위한 설정이 반영되어 있다.

Ÿ   serial # - revision # Zone 파일이 업데이트 될때 마다 증가하는 일종의 버전

Ÿ   refresh - secondary server primary server로 부터 업데이트를 하는 주기

Ÿ   retry - primary server로 부터의 query가 실패하였을때, 다음 retry 까지 시간.

Ÿ   expire : secondary server에서 zone 파일을 유지 하는 시간

Ÿ   TTL : DNS 응답을 받아가는 서버가 해당 레코드 응답을 얼마나 유지해야 하는 TTL 시간

   NS 레코드 : DNS 서버가 참조하는 다른 DNS 서버이다. DNS 서버 자신에서 domain name에 대한 주소를 알아 내지 못할때, NS 레코드에 정의된 서버로 가서 주소를 알아dhsek.

   CNAME 레코드: 도메인명을 다른 도메인과 맵핑할때 사용 (일종의 alias)

   A 레코드:도메인을 ip로 맵핑

   PTR 레코드 : ip를 도메인으로 맵핑 (Reverse Zone에서 사용)

 

DNS 서버의 특성중에서 주의깊게 봐야 하는 특성은 캐슁이다.

보통 DNS 서버는 클라이언트가 사용하는 로컬 네트워크에 있는 DNS를 사용하게 된다. 회사 네트워크라면 회사내의 DNS 서버,집에서 사용하는 경우 해당 통신사의 DNS서버, 모바일을 사용할 경우, 해당 통신사의 DNS 서버를 사용한다. DNS 서버들은 look up을 요청한 목적 서비스 서버에 대한 ip 주소를 다른 클라이언트가 요청할 때 응답을 빠르게 하기 위해서 자체적으로 캐슁하고 있다.

예를 들어 구글의 A라는 서비스가 있다고 하자. 이 서비스 A는 구글의 DNS 서버에 주소가 정의되었을 것이다. 만약 한국의 사용자가 스마트 폰을 이용하여 이 서비스의 URL을 접근하게 되면, 해당 한국 통신사의 DNS 서버를 통해서 주소를 look up 하게 될 것이고, 이 한국 DNS 서버는 구글의 DNS 서버에 주소를 물어본 후에, 다음 서비스를 위해서 자신의 Cache를 업데이트 한다.

이 캐쉬가 지워지고 다시 업데이트 되는 시간이 TTL 시간인데, TTL은 이후에도 설명하겠지만, 동적으로 DNS 주소를 업데이트하거나 변경하였을때, 로컬의 DNS서버의 캐쉬가 업데이트 되지 않아서 실제 주소가 바뀌더라도 이전 서버의 주소를 리턴하는 경우가 있어서 주소 변경을 어렵게 한다.

이제 Route 53의 고유 기능을 살펴보도록 하자.

Health check & DNS Fail Over

Route53은 자체적으로 Health check 기능을 가지고 있다. 하나의 DNS 명에 대해서 multiple ip address return할 수 있는데, 해당 ip의 서버의 상태를 체크해서 장애 상태인 경우에는 list에서 제외하고, 장애가 복구 되면 다시 리스트에 추가하는 형태이다.

앞에서 언급했듯이 이 기능의 경우 local DNS들의 캐슁 때문에, Route53이 장애를 인지하고 바로 list에서 제외한다 하더라도 local DNS에서 캐쉬가 업데이트 되는 시간이 필요하기 때문에 바로 fail over는 되지 않는다. 되도록 빠른 fail over를 하기 위해서는 Route53에서 TTL 시간을 짭게 주는 것이 좋은데, 아마존의 경우 60초이하 의 값을 권장하고 있다.

Latency based routing

Route53의 기능 중에 상당히 흥미로운 기능중의 하나인데, Route53에 하나의 DNS 주소에 대해서 여러개의 서비스 ip binding 되어 있을 경우, Route53은 클라이언트로 부터 DNS 주소에 대한 look up 요청을 받았을 경우, 클라이언트로 부터 가장 빠른 응답시간을 보장하는 (거리가 가까운) 서버의 ip 주소를 리턴하는 기능이다.

 원리를 설명해보면 다음과 같다. 아마존 인프라는 각 데이타센터로부터 다른 ip주소 대역까지의 네트워크 latency 값을 주기적으로 수집해서 데이타 베이스화 해서 가지고 있다. 예를 들어 미국 아마존 데이타 센터에서 전세계에 대한 latency를 아마존을 가지고 있다. 한국,중국,유럽 등등. 이렇게 latency 자료를 가지고 있다가, DNS look up 요청이 오면, 요청을 한 클라이언트쪽의 ip를 기반으로 내부 데이타 베이스내의 latency를 체크해여 가장 가까운 아마존 데이타 센터의 ip를 리턴하게 되는 원리이다.

이 때 Route 53으로 request를 보내는 클라이언트는 end user browser나 모바일 기기등이 아니라 end user가 접속된 네트워크의 로컬 DNS 서버가 되게 된다.

 Latency based routing의 경우 로컬 DNS가 클라이언트가 접속하는 망내에 있는 것을 전제로 한다.

 

'클라우드 컴퓨팅 & NoSQL > Amazon Web Service' 카테고리의 다른 글

Auto scaling out  (1) 2013.09.11
Amazon의 CDN 서비스 Cloud Front  (0) 2013.09.10
Amazon Route 53 DNS 서비스  (0) 2013.09.09
Amazon Elastic Load Balancer  (2) 2013.09.09
Amazon Direct connect  (0) 2013.09.06
Amazon VPC (Virtual Private Cloud) 소개  (3) 2013.08.18

 

Elastic Load Balancer

 조대협

ELB는 아마존에서 제공하는 일종의 L4와 같은 로드 밸런서이다. 내부적으로 VM위에서 동작하는 소프트웨어 로드밸런서이고, 아마존 환경에 맞춰서 최적화 되어 있다.

 



Multiple zone support

ELB는 기본적으로 multiple zone을 지원한다. ELB 생성시, ELB를 배포할 Amazon Availability Zone을 지정할 수 있다. 여러 개의 zone multiple ELB instance가 배포 되기 때문에 ELB 인스턴스는 기본적으로 ip 주소를 가지지 않는다. 대신 DNS 주소를 가지는데, 테스트를 해보면 알겠지만, ELB DNS 주소는 경우에 따라서 1개 이상의 주소를 리턴하게 된다.

이는 multiple zone을 지원하기 위해서 뿐만 아니라, ELB의 용량이 모자르게 되면 내부적으로 자동으로 scaling을 하는데, 먼저 ELB scale up을 해서 인스턴스 크기를 키우고, 모자르다면 다른 ELB 인스턴스를 만들어서 추가 하는 scaling out 작업을 수행한다.

여러개의 ELB를 하나의 end point로 묶기 위해서 DNS 리스트 방식을 사용하게 된다.

SSL Termination

ELB SSL 기반의 HTTPS 프로토콜을 지원할 수 있다.ELB 설정에 SSL 인증서를 세팅해놓으면 Client --> ELB SSL, ELB --> 백엔드 EC2까지는 HTTP로 통신을 하게 된다.

X-forwarded for Header

ELB EC2 인스턴스 앞에서 로드밸런싱을 하게 되면 EC2 입장에서 incoming address ELB의 주소로 인식하게 된다. 애플리케이션에 따라서 client ip를 알아야 할 경우가 있는데, EC2 입장에서는 ELB request를 하는 주체가 되기 때문인데, 이러한 문제를 해결하기 위해서 ELB는 원래의 client ip X-forwarded-for (XFF) 헤더 안에 실어서 보내준다. EC2에서는 이 XFF HTTP Header를 열어 봄으로써 원본 client ip를 알아낼 수 있다.

Sticky Session

ELB가 추가적으로 제공하는 기능중에 하나가 sticky session이라는 기능이다. 이 기능은 client로 부터 들어오는 http request를 항상 같은 ec2 인스턴스로 라우팅을 해주는 기능인데, ELB sticky session의 원리는 cookie를 사용한다.

Sticky session 기능을 on 해놓으면, http response cookie를 세팅하여, 해당 client가 가는 ec2 instance에 대한 정보를 저장해 놓는 방식이다.

몇 가지 추가 설정이 필요한데, 애플리케이션이 이미 http cookie를 사용하고 있으면, 해당 cookie 명을 넣어서 사용중인 애플리케이션 cookie를 사용하게 하고, 만약에 애플리케이션이 cookie를 사용하지 않으면, 별도로 ELB cookie를 만들도록 한다.



위의 그림과 같이 sticky session 기능은 cookie를 사용하기 때문에, multiple ELB 상황에서도 항상 같은 request를 같은 ec2 인스턴스로 라우팅할 수 있게 해준다.

Health Check

ELB ELB에 연결된 EC2 인스턴스에 대한 자체적인 Health Check 기능을 가지고 있다. 사용자 설정에서 정해진 옵션에 따라서 주기적으로 EC2 인스턴스에 Health Check 메세지를 보내고, 만약에 EC2 인스턴스가 장애로 판단되면, 해당 인스턴스를 로드밸런싱 리스트에서 제외한다.

반대로, 제외되었던 인스턴스라도, 주기적으로 체크해서 정상화가 되면 다시 로드 밸런싱 대상에 추가하게 된다.

DNS Fail Over

다음으로 ELB 간의 HA이다. Load Balancing은 앞에서 언급한 바와 같이 DNS Round Robin 을 사용한다. 마찬가지로 HA 역시 DNS 방식을 사용하는데, Amazon DNS ELB 인스턴스들의 상태를 감시하다가 문제가 생기면, DNS 리스트에서 제외를 한다.

DNS 방식이기 때문에, TTL 시간을 가지고 있고, TTL 시간이 지나야 리스트가 클라이언트에 업데이트 되기 때문에, TTL 시간이 지나기 전까지는 client가 계속 장애가 난 인스턴스로 로드가 밸런스 될 수 있다. 그래서 Load Balancer 기반의 Fail Over 보다는 넘어가는 시간이 느리다.

VPC & ELB

앞서 VPC에 대한 개념에 대해서 설명하였는데, ELB 역시 VPC 안쪽이나 바깥쪽 양쪽에 배포가 가능하다. VPC 바깥쪽에 배포를 하여 public ip를 가지고 VPC 안쪽의 EC 인스턴스에 대해서 로드밸런싱이 가능하며, 또한 VPC 안쪽에 배포를 하여 private ip를 가지고 EC 인스턴스에 대해서 로드 밸런싱이 가능하다.

주의해야할점

마지막으로 ELB 사용 및 테스트시 주의할점을 몇가지 언급해보면 다음과 같다.

ELB로 성능 테스트를 하다 보면, 부하가 일정 수준으로 못 올라가는 경우에 ELB에서 Network In/Out bound 쪽에서 병목이 있는 것을 발견할 수 있는데, 이는 ELB의 용량이 충분하지 않기 때문이다. ELB는 자체적으로 scaling을 하기는 하지만, scaling이 그리 빠르지 않다. 그래서 성능 테스트를 할 경우에는 wramp up 기간을 둬서 충분히 부하를 줘서 인위적으로 ELB scaling하게 해 놓은 후에, 부하 테스트를 해야 ELB 단의 병목을 피할 수 있다.

또는 wramp up 이 되었는지 여부가 확실 하지 않으면 DNS look up으로 몇 개의 ELB 인스턴스가 생성되었는지 확인해보거나, 제일은 Amazon쪽에 부하 테스트 기간을 알려주면 미리 Amazon 쪽에서 ELB scaling 해 준다.

그리고 부하테스트를 하다 보면, 특정 EC2 Instance나 특정 Availability Zone으로 몰리는 현상이 있을 수 가 있다. 특정 Zone으로 부하가 몰리는 현상은 흔히 발생하는 데, ELB 자체가 부하를 골고루 분산해 주지 않는다. 다만 특정 Zone이나 Instance로 몰리는 현상이 아주 심할 경우에는 몇 가지 요인을 생각해볼 수 있는데, 먼저 부하 테스트 쪽의 DNS 캐쉬를 의심해볼 수 있다.

ELB간의 로드밸런싱은 DNS Round Robin을 사용하기 때문에, 클라이언트 쪽의 캐쉬를 지워주지 않으면 그 시간동안 계속해서 특정 ELB 인스턴스에만 부하를 주게 된다.

특정 인스턴스로 몰리는 현상의 경우 Sticky Session을 사용하는 경우, 클라이언트 쪽의 Cookie를 지워 주지 않아서, Cookie를 참조해서 계속 같은 EC2 인스턴스로 부하가 가는 경우가 많다.

 

그래서 ELB 기반의 부하테스트를 할 때에는 고성능 적은 수의 클라이언트 보다는 많은 수의 저성능 클라이언트를 사용하는 것이 부하를 골고루 나눠 지게 할 수 있다.

 

Amazon S3 (Simple Storage Service)

AWS S3 (Simple Stoage Service)는 파일을 저장하기 위한 스토리지이다. 일반적인 파일시스템의 개념과는 약간 다르고, 파일 이름을 대표하는 key와 파일 자체로 구분되는 Object Storage이다.

용량 저장할 수 있는 파일의 크기는 개당 1byte~5TB이고, 총 저장 용량에는 제한이 없다. 디렉토리와 비슷한 개념으로, bucket이라는 개념을 가지고 있다.

기본적으로 3 copy를 지원하여, 데이타를 복제하고, 이 복제는 Amazon availability zone (AZ) 단위로 복제가 되기 때문에 데이타 센터 장애에 대한 대응성을 가지고 있다. region 간 복제는 지원하지 않는다. 복제에 관련된 옵션으로는 RRS (Reduced Redundancy Storage)라는 것이 있는데, 이 옵션을 적용하면, 2 copy (원본 + 백업)만을 저장하기 때문에, 가격이 훨씬 더 저렴하다. 3 copy를 저장할 경우, S3에 대한 데이타 신뢰도는 99.999999999% 보장하고, 서비스에 대한 가용성은 99.99% 보장한다.

S3에 접근하기 위한 인터페이스는 일반적은 file io api등은 사용할 수 없으며, REST/HTTP 기반의 프로토콜만 지원한다. 그래서, 성능이 다른 파일 시스템에 비해서 느리다.

그 외에 기타 부가적인 기능들을 살펴 보면 다음과 같다.

     Retaining 기능 : 다른 주목할만한 기능 은 retain 기간을 지정할 수 있다. 즉 파일의 저장 기간을 지정할 수 있고, 그 기간이 지나면 자동으로 삭제가 된다.

     Versioning : 저장된 파일에 대해서 여러 버전을 저장 및 관리할 수 있다. 참고로 이전 버전으로 저장된 파일 역시 똑같이 과금 되기 때문에, 금액 부분에 대해서 신경을 쓰기 바란다.

     Encryption : S3는 상당히 다양한 형태의 암호화를 지원한다. HTTPS를 이용한 전송단의 암호화에서 부터, Server에서 저장될때 암호화를 적용할 수 있으며, Client에서 전송할때나 받을때, 암호화된 형태로 데이타를 주고 받을 수 있다.

타 시스템과 연동 관점에서 S3 서비스는 AWS 내에서 대용량 데이타를 저장하기 가장 알맞은 저장소이다. 그래서 다른 AWS의 서비스 (EMR CloudFront, Glacier )에 자연스럽게 연동될 수 있는 기능을 제공하며, 다른 서비스들과 상호보완적인 관계를 갖는다. 예를 들어 SQS와 같은 큐 서비스에는 큰 객체(파일)을 저장할 수 없기 때문에 이벤트 메세지는 SQS에 저장하고, 실제 큰 파일은 S3에 저장해서 레퍼런스를 하던가, Dynamo와 같은 NoSQL DB도 레코드당 데이타 한계로 인해서, 메타 데이타는 Dynamo에 저장하고, 파일과 같은 큰 바이너리 데이타는 S3에 저장하고 레퍼런스를 하게 할 수 있다.


Partitioning

S3를 사용하면서 데이타의 양이 늘어나게 되면 성능이 떨어지게 되는 것을 체감할 수 있다.

S3는 내부적으로 여러개의 파일을 저정하기 위해서 물리적으로 파일을 여러개의 디스크에 분할 저장하는데, 이 분할 하는 로직을 파일명을 가지고 해쉬를 사용한다. 그래서 파일명이 유사하게 되면, 같은 파티션(디스크)에 파일이 써지기 때문에, 하나의 파티션에 많은 물리적인 IO를 유발하고 결과적으로 성능이 떨어지게 되는 것이다.

S3는 파일명을 가지고 hashing을 하여 파일을 분산 저장한다고 했다. 더 정확하게 이야기 하면 파일명의 앞부분인 prefix를 가지고 분산 키로 사용한다.

즉 예를 들어 파일명이

server.2012-12-31

server.2012-12-30

server.2012-12-29

server.2012-12-28

과 같이 앞의 prefix가 같다면, 파일은 같은 파티션에 저장될 가능성이 많다.

그래서 앞의 file prefix를 다양한 이름으로 바꿔 주는 것이 좋다.

예를 들어 일정 디렉토리 (디렉토리명으로도 파티셔닝이 된다.)로 다음과 같이 구분한다

a/server.2012-12-31

b/server.2012-12-30

c/server.2012-12-29

d/server.2012-12-28

위와 같은 구조를 취하면, 최소 4개 파티션에 분할 저장된다.

또는 위의 파일명의 경우 맨 마지막이 날짜로 rotation되는 형태이기 때문에, 다음과 같은 파일명으로 저장해도 파티셔닝 효과를 볼 수 있다.

13-21-2102.server

03-21-2102.server

92-21-2102.server

S3에서 내부적으로 어떤 원리로 partitioning을 하는지는 정확하게 나와 있지 않다. 단지 prefix를 이용한다고만 나와 있는데, 최소한 파일명(또는 디렉토리명)을 다른 문자로 시작하게 하면, 골고루 파티션에 분산하여 저장할 수 있다고 가이드 하고 있다.

최소한 50 TPS 이상의 S3 IO를 요구할 경우에는 파티션을 권장하고 있다.

     참고 : http://aws.typepad.com/aws/2012/03/amazon-s3-performance-tips-tricks-seattle-hiring-event.html

이 키 기반의 파티셔닝은 단지 S3 뿐만 아니라, NoSQL이나 HDFS와 같은 분산 파일 시스템에도 동일한 원리로 적용되기 때문에 반드시 참고하기 바란다.


Bucket의 위치에 대해서

성능 관련해서 가장 기본적인 부분인데, 많이 실수하는 부분이 S3 Bucket을 만들때 애플리케이션과 다른 Region Bucket을 만드는 경우가 있는데, 이 경우 성능 저하가 매우 심하게 발생한다.

Bucket을 만들때는 반드시 같은 애플리케이션이 실행되는 region과 반드시 같은 region을 사용하도록 한다.

http://blog.takipi.com/2013/03/20/aws-olypmics-speed-testing-amazon-ec2-s3-across-regions/

문서를 참고해보면, region간의 평균적인 속도가 나오니 참고하기 바란다



Multipart uploading

S3에는 파일을 업로드 할때, multipart uploading이라는 기능을 제공한다. ( http://aws.typepad.com/aws/2010/11/amazon-s3-multipart-upload.html )

파일을 하나의 Connection에서 쭈욱 올리는 것이 일반적인 방법이라면



파일을 여러개의 블럭으로 나눠서 동시에 여러개의 Connection을 통해서 업로드 하는 방법이다. 이 경우 업로드가 Parallel하게 이루어지기 때문에 상당 부분의 성능 향상을 가지고 올 수 있다.



또 다른 장점은 큰 파일 하나를 여러개의 블럭으로 나눠서 전송하기 때문에, 만약에 전송중에 특정 블럭 전송이 실패하면, 전체 파일을 재 전송할 필요가 없이 실패한 특정 블럭만 다시 전송하면 된다. multipart 업로드 기능을 구현은 SDK 형태로 재공되는 라이브러리를 사용하면 된다.

http://docs.aws.amazon.com/AmazonS3/latest/dev/uploadobjusingmpu.html

아마존 가이드에서는 100MB 이상의 파일 전송시에 권장하고 있는데, 사용해본 결과 꼭 100MB가 아니더라도 그 이하의 크기의 파일 전송에서도 충분한 성능 증가를 볼 수 있으니, 대규모의 업로드를 사용하는 경우 single upload vs multipart upload 성능을 테스트해보고 결정하기를 권장한다.

 

사용법이 매우 간단한 서비스이기는 하지만, 쉽고 안전하며, 데이타 저장소로써 필수적인 기능등은 거의 다 갖추고 있으며, 저렴한 가격에, 다른 서비스와 연계성이 높기 때문에, 필히 익혀둬야 하는 서비스이다. S3를 이용한 시스템 설계시에는 일반 파일 시스템과 같은 형태로 접근을 하면 안된다. HTTP 형식으로 접근을 하기 때문에, 성능이 그만큼 나오지 않는다. 이 부분에 대한 고려만 충분히 하면 AWS에서 EC2 다음으로 가장 가치가 높은 서비스가 아닐까 싶다.

매우 기본적인 부분인데, 함정(?)이 있어서 메모해놓습니다.


aws에서는 S3 버킷을 만들때 위와 같이 Region을 정할 수 있습니다.

그런데 US Standard라는 Region이 있는데, 이는 실제 존재하는 region이 아닙니다. Oregon이나 Ireland와 같이 실제 S3가 배포될 region을 명시적으로 정하는 것이 좋습니다. (특히 미국의 경우..)

EC2를 US West Oregon에서 사용하실거면, 반드시 S3도 같은 Region에 생성을 해야 속도가 빠릅니다.


http://blog.takipi.com/2013/03/20/aws-olypmics-speed-testing-amazon-ec2-s3-across-regions/


문서를 보면 region가 S3 속도가 나옵니다.



원본 : http://aws.typepad.com/aws/2012/03/amazon-s3-performance-tips-tricks-seattle-hiring-event.html


아마존 S3를 이용하는 시스템에 대한 성능 테스트를 할때, 성능이 Leanear 하게 증가하지 않는데, 그 원인을 보면 다음과 같은 원리가 작용한다.


원인 분석

S3는 내부적으로 여러개의 파일을 저정하기 위해서 물리적으로 파일을 여러개의 디스크에 분할 저장하는데, 이 분할 하는 로직을 파일명을 가지고 해쉬를 사용한다. 그래서 파일명이 유사하게 되면, 같은 파티션(디스크)에 파일이 써지기 때문에, 하나의 파티션에 많은 물리적인 IO를 유발하고 결과적으로 성능이 떨어지게 되는 것이다.


원리

S3는 파일명을 가지고 hashing을 하여 파일을 분산 저장한다고 했다. 더 정확하게 이야기 하면 파일명의 앞부분인 prefix를 가지고 분산 키로 사용한다.

즉 예를 들어 파일명이

server.2012-12-31

server.2012-12-30

server.2012-12-29

server.2012-12-28

과 같이 앞의 prefix가 같다면, 파일은 같은 파티션에 저장될 가능성이 많다.

그래서 앞의 file prefix를 다양한 이름으로 바꿔 주는 것이 좋다.

예를 들어 일정 디렉토리 (디렉토리명으로도 파티셔닝이 된다.)로 다음과 같이 구분한다

a/server.2012-12-31

b/server.2012-12-30

c/server.2012-12-29

d/server.2012-12-28

위와 같은 구조를 취하면, 최소 4개 파티션에 분할 저장된다.
또는 위의 파일명의 경우 맨 마지막이 날짜로 rotation되는 형태이기 때문에, 다음과 같은 파일명으로 저장해도 파티셔닝 효과를 볼 수 있다.
13-21-2102.server
03-21-2102.server
92-21-2102.server
:
S3에서 내부적으로 어떤 원리로 partitioning을 하는지는 정확하게 나와 있지 않다. 단지 prefix를 이용한다고만 나와 있는데, 최소한 파일명(또는 디렉토리명)을 다른 문자로 시작하게 하면, 골고루 파티션에 분산하여 저장할 수 있다고 가이드 하고 있다.

최소한 50 TPS 이상의 S3 IO를 요구할 경우에는 파티션을 권장하고 있다.
이 키 기반의 파티셔닝은 단지 S3 뿐만 아니라, NoSQL이나 HDFS와 같은 분산 파일 시스템에도 동일한 원리로 적용되기 때문에 반드시 참고하기 바란다.


Amazon Opsworks 소개

시스템에 설치와, 애플리케이션을 자동화

배경

얼마전에, Amazon에서 새로운 클라우드 서비스인 Opsworks를 발표하였다.

[출처:Amazon Opsworks 소개 페이지]

비단 클라우드 뿐만 아니라, 서버 시스템을 개발하다보면, 당면 하는 과제중의 하나가, 소프트웨어 설치와, 애플리케이션의 배포이다.

예전에야 큰 서버 한대에, WAS 하나 설치하고, DB를 다른 서버에 설치해서  사용했지만, 요즘 같은 시대에는 x86 서버 여러대에 WAS를 분산 배치하고, 여러 솔루션들 설치해서 사용하고, 시스템의 구조 역시 훨씬 더 복잡해 졌다. 그래서, 이러한 제품 설치를 자동화 하는 영역이 생겼는데, 이를 Configuration Management(이하 CM)이라고 한다. CM의 개념은 Microsoft System Center Configuration Manager의 제품 소개나 White Paper를 보면, 정리가 잘 되어 있다. Unix 진영의 Configuration Management 영역은 오픈소스로 Puppet이나 Chef가 주류를 이룬다. 그중에서 Chef Recipe 라는 것을 제공하여, 특정 제품에 대해서 설치를 자동화 하는 스크립트를 제공한다. 일일이 제품마다 설치 스크립트를 만들지 않아도, Recipe만 입수하면 손 쉽게 제품을 설치할 수 있다. 특히나 클라우드 환경에서는 개발 환경이나 스테이징,QA 환경을 다이나믹하게 만들었다가 없앴다 하기 때문에 더군다나, 이러한 Configuration Management가 아주 중요하다.

 기존에는 Amazon 이미지인 AMI를 이용하여, 솔루션이 미리 설치된 AMI를 만들어 놓고, bootstrap 기능을 이용하여, 서버가 기동 될때, 특정 환경 변수를 설정하게 하거나

CloudFormation을 이용하여 설치를 자동화 할 수 있었다. 그러나 AMI 방식은 너무 단순해서 복잡한 설정이 어렵고 처음에는 반드시 직접 설치해야 하는 부담이 있었고, CloudFormation은 그 복잡도가 너무 높아서 사용이 어려웠다.

이번에 발표된 Opsworks는 이 중간즘 되는 솔루션으로 보면 된다.

Stack, Layer 그리고 Instance의 개념

Opsworks는 기본적으로 오픈소스 Chef를 이용하여 구현되었다. Chef를 이용해서 아마존에 맞게 개념화 해놓았는데, 먼저 Opsworks의 개념을 보자. Opsworks를 이해하려면 3가지 개념, Stack, Layer 그리고 Instance의 개념을 이해해야 한다.

우리가 PHP 웹서버 + MYSQL로 이루어진 웹 애플리케이션을 개발한다고 하자, 그리고 앞단은 HAProxy를 사용해서 로드 밸런싱을 한다고 하면, 이 애플리케이션은 크게, HA Proxy로 이루어진 Load Balancer Layer 그리고, PHP 웹서버를 사용하는 Application Server Layer 그리고, MySQL로 이루어진 DB Layer 3가지 계층으로 이루어진다.

3 가지 계층은 (HAProxy+PHP Web Server+MySQL) 다른 웹 개발에도 반복적으로 사용될 수 있다.


이렇게 각 계층을 Layer라고 하며, 이 전체 계층을 반복적으로 재사용하기 위한 묶음을 Stack이라고 한다. 그리고, 각 계층에 실제 서버를 기동했을 경우 각 서버를 Instance라고 한다. 예를 들어 하나의 HA Proxy 서버를 띄우고, 이 아래 4개의 PHP Web Server를 기동했다면, 이 시스템은 PHP Web Server로 된 Application Server 계층에 4개의 Instance를 갖는게 된다.

Chef & Predefined Cookbook
Opsworks
는 앞에서 언급했듯이 Chef (http://www.opscode.com/chef/기반이다.

Chef에 사용되는 설치 스크립트는 Ruby 언어로 되어 있으며, Opsworks에서는 콘솔에서 편리하게 사용할 수 있도록 Pre-defined Layer를 정해놨다.

Layer

Product

Load Balancing

HAProxy

Applications & Web Server

Node.js RubyOnRails, static web server, PHP

DBMS

MySQL

Cache

Memcached

Monitoring

Ganglia

 이외의 부분은 Custom Layer라고 해서 사용자가 직접 정의해야 하며, Chef를 만든 OpsCode Receipe를 참고하여 설정할 수 있다.

애플리케이션의 배포

이렇게 Stack 구성이 완료되면, 기동후에, 여기에 배포되는 애플리케이션을 배포할 수 있다. 자바로 치면 war, ear 파일등이 된다.

아마존이 충분히 서비스를 고려했다는 점은, 여기서도 나오는데, 애플리케이션 배포중에 중요한 일중 하나가, 배포가 잘못되었을때 기존 버전으로 roll back이 가능해야 한다는 것이다. 이를 지원하기 위해서 보통 배포 서비스를 설계할때는 애플리케이션을 저장할 수 있는 repository를 별도 설계해서, 여러 버전을 저장해놓고, 필요할 경우 Roll Back을 하는데, Opsworks는 이를 지원하기 위해서 다양한 Repository를 지원한다.-AWS S3, 일반 HTTP URL, GitHub ,Subversion

현재 Opsworks에서 지원하는 배포 가능한 앱은 Ruby on rails, PHP, JavaScript(Node.js), Static등을 지원하며, Custom App을 통해서 여러 앱 타입을 지원하도록 할 수 있다.

더 살펴봐야 할것

Opsworks 스크립트를 통해서 할 수 없는 것중 하나는 ELB(Elastic Load Balancer)등의 세팅을 할 수 없다. 오로지 EC2위에 설치하는 것만 가능하다. 설치와 배포를 AWS 인프라와 어떻게 엮어서 할 수 있을까가 과제이다.

아직 베타 서비스이고 사례가 많지는 않지만, 설치와 배포가 중요한 클라우드 환경에서, Chef라는 주요 오픈 소스를 기반으로한 서비스인 만큼 시간을 가지고 지켜볼만한 하다.

 

참고 : http://docs.aws.amazon.com/opsworks/latest/userguide/walkthroughs.html

Dynamo는 새롭게 소개된 AWS의 NoSQL서비스이다.
Key-Value 형태로 대용량의 데이타를 저장할 수 있으며, 고속의 데이타 access를 제공한다.

데이타 모델
먼저 데이타 모델을 살펴보자, RDBMS의 일반적인 테이블 구조와 유사하지만, 조금 더 유연성을 가지고 있다.
RDBMS와 똑같이 테이블이라는 개념을 가지고 있으며, 테이블은 테이블명과 각각의 ROW로 구성된다.
테이블은 Unique한 Primary Key를 가지고 있다. 이를 Key라고 정의한다.
테이블의 ROW에 해당하는 내용은 item이라고 부르는데, 각 item은 key에 의해서 구분된다.
RDBMS와는 다르게, 각 ROW는 똑같은 Column을 갖는 것이 아니라, 각  row 마다 다른 column을 가질 수 있다
그래서, 각 컬럼을 name = value 식으로 정의하는데, 이 각각을 attribute라고 정의한다.



이 개념을 도식화 해보면 위의 그림과 같다.
아마존 웹사이트에 나와 있는 예제를 한번 살펴보자.
ProductCatalog 라는 테이블이 있다고 하자, 이 테이블의 Primary Key는 Id라는 필드를 사용한다. 이 Primary Key 필드는 모든 item들이 가지고 있어야 한다.

Item 1
{ 
   Id = 101                                       
   ProductName = "Book 101 Title"
   ISBN = "111-1111111111"
   Authors = [ "Author 1", "Author 2" ]
   Price = -2
   Dimensions = "8.5 x 11.0 x 0.5"
   PageCount = 500
   InPublication = 1
   ProductCategory = "Book" 
} 
Item 2
{ 
Id = 201
ProductName = "18-Bicycle 201"
Description = "201 description"
BicycleType = "Road"
Brand = "Brand-Company A"
Price = 100
Gender = "M"
Color = [ "Red", "Black" ]
ProductCategory = "Bike"
}

위의 예를 보면 알겠지만, 모든 Item들은 Id라는 Key 필드를 가지고 있지만, 각각의 Column들은 내용이 다르다. Item 1에는 ISBN 필드가 있지만, Item 2에는 ISBN 필드가 없다.

Dynamo는 RDBMS와는 다르게 Index 필드가 없다. (다른 NoSQL도 Index가 없는 경우가 많지만) 대신 range query나 sorting을 지원하기 위해서 range key라는 추가적인 키를 제공한다. Primary Key를 정의시 Unique한 Key 필드 하나만 정의하거나 (이를 Hash Key라고 한다.) 또는 이 range key를 추가로 지정하면, 쿼리 결과가 ascending 순서로 sorting이 되며, 쿼리 역시 이 range key를 기반으로 특정 범위의 데이타만 query 할 수 있다.
이 range key는 table 생성시에 hash key와 함께 정의한다.

성능

내부적으로 SSD 디스크를 이용하기 때문에, 높은 IO 성능을 보장할 수 있으며 read / write 성능을 보장하는 옵션을 가지고 있다.
Read/Write Unit이라는 옵션인데, 1KB item 1개를 1초동안 쓰거나 읽는 단위가 1 Unit이다. 2 Write Unit은 1K 데이타를 1초동안 2개 Write할 수 있는 성능 지표이다.

Units of Capacity required for reads = Number of item reads per second x item size (rounded up to the nearest KB)
Units of Capacity required for writes = Number of item writes per second x item size (rounded up to the nearest KB)
ReadUnit = [초당 읽는 item(row) 수] * [ item 크기 (kb로 반올림) ]
WriteUnit = [초당 쓰는 item(row) 수] * [ item 크기 (kb로 반올림) ]

1 ReadUnit은 초당 1KB짜리 1개의 Item을 읽을 수 있는 성능 단위이다.
예를 들어, 21.5 kb 짜리 item을 초당 100개를 읽는 성능이 필요하다면, Read Unit = 100 * 22 (반올림) = 2200 이 필요하다.
쓰기 성능도, 마찬가지 방식으로 WriteUnit이라는 단위로 지정한다.
각각 최대 10,000 Unit 까지 지원하며, 이 이상을 원할 경우, Amazon Support에 신청하면, 더 높은 Unit으로 올릴 수 있다. (최대 한계는 나와있지 않음)
Unit의 개념은 성능을 보장한다는 개념에서 긍정적이지만, 반대로 성능을 제약한다는 문제를 가지고 있다.
즉 정해진 Unit 보다 많은 read나 write가 발생할 경우, Dynamo는 이를 처리하지 않고 error 처리를 해버린다.
"ProvisionedThroughputExceededException" 그래서 Spike 형태의 request가 들어올 때는 문제가 된다.
프로그램 로직상에서 "ProvisionedThroughputExceededException" 에 대한 처리가 필요한데, 이 에러가 발생하였을 경우에는 프로그램적으로 retry를 하도록 하는 로직을 포함하는 것을 권장한다.

일관성 보장 옵션
Dynamo와 같은 NoSQL 계열의 데이타베이스는 데이타를 여러개의 노드에 나눠서 저장하고, 백업을 위해서 다른 노드로 복제하기 때문에, 복제가 완료되기 전에 클라이언트가 다른 노드에서 데이타를 읽으면 예전의 데이타를 읽을 수 있다. 이런 문제가 일관성 문제인데, 일반적인 NoSQL은 이러한 일관성을 보장하지 않는다. 복제할 때까지 시간이 걸린다는 것을 가정하고, (시간 자체는 짧으나) 그 시간동안은 일관성이 보장이 안되는데, 이러한 일관성 보장 정책을 Eventually Consistent Read라고 한다. 반대로, 데이타를 쓴 다음 모든 노드에서 데이타를 읽었을때, 같은 데이타를 바로 리턴하게 할 수 있는데, 이 경우에는 데이타가 써진 후에, 다른 노드 까지 replicated될때까지 기다려야 한다. 그래서 당연히 Read 응답시간이 Eventually Consistency Read보다 느리다. 이러한 일관성 정책을 Strongly Consistent Read라고 한다. Strong Consistency의 경우 Eventually Contentency와 같은 성능을 보장하려면, 더 빨리 data write를 발생시켜야 하기 때문에, 내부적으로 더 높은 write unit이 필요하게 된다. 그래서, Eventually Consistency의 경우 Strong Consistency에 비해서 가격이 50% 정도 저렴하다.

Query
데이타베이스이기 때문에, 데이타에 대한 Query를 지원한다.
Primary Key를 가지고 get이 가능할 뿐더러, range key를 이용하여, subset을 query하는 range query가 가능하다.
쿼리 후 list(set) 형태의 데이타가 리턴되었을 경우, 한번에 리턴할 수 있는 데이타 set의 최대 크기는 1MB이다.
1MB가 넘을 경우에는 pagenation을 해야 하는데, 1MB 가 넘는 경우 LastEveluatedKey라는 값을 리턴하여, (일종의 DB cursor와 같은 역할) 다음번 read시 부터는 이 키 부터 리드할 수 있도록 pointing을 해준다
또는 명시적으로 Limit 라는 parameter를 이용하여, Query에서 리턴되는 수를 정할 수 있다. (SQL의 "top"과 같은 개념) 전체 쿼리 결과가 1000개라도 Limit 10 으로 하면, 소팅된 순서에서 상위 10개의 item 만 리턴한다.
다음으로는 "Count"라는 parameter가 있는데, 이 Count는 RDBMS의 select count(*)와 같은 개념이다. Query 결과로 리턴되는 총 Item의 수를 리턴한다.
주의할점은 Dynamo는 NoSQL이다. RDBMS와 다르다.
key 기반의 select와, range query는 지원하지만, group by, where, index등의 쿼리 기능은 없다. (데이타 모델 설계 자체를 RDBMS와 다르게 해야 한다.)

Scan
Scan 기능은 테이블의 모든 Item을 순차적으로 읽어오는 기능으로, Query와 마찬가지로, 한번 API call에 1MB까지만 읽어올 수 있고, LastEvaluatedKey 값을 이용해서 다음 데이타를 연속적으로 읽어올 수 있다. 처음부터 테이블을 Scan 하기 때문에, 당연히 많은 시간이 소요된다.

'클라우드 컴퓨팅 & NoSQL > Amazon Web Service' 카테고리의 다른 글

Amazon의 설치 배포 자동화 솔루션 Opsworks  (0) 2013.02.26
간단한 S3 Performance Test  (3) 2013.01.25
아마존의 SSD의 NoSQL 서비스 Dynamo  (0) 2012.12.07
Amazon S3 서비스 소개  (0) 2012.12.06
EMR 특징  (1) 2012.12.06
Dynamo 특징  (0) 2012.12.06

AWS S3 (Simple Stoage Service)는 파일을 저장하기 위한 스토리지이다. 일반적인 파일시스템의 개념과는 약간 다르고, 파일 이름을 대표하는 key와 파일 자체로 구분되는 Object Storage이다.

저장할 수 있는 파일의 크기는 개당 1byte~5TB이고, 총 저장 용량에는 제한이 없다. 디렉토리와 비슷한 개념으로, bucket이라는 개념을 가지고 있다.

S3에 접근하기 위해서는 일반적은 file io api등은 사용할 수 없으며, REST/HTTP 기반의 프로토콜만 지원한다. 그래서, 성능이 다른 파일 시스템에 비해서 느리다.

기본적으로 3 copy를 지원하여, 데이타를 복제하고, 이 복제는 Amazon availability zone (AZ) 단위로 복제가 되기 때문에 데이타 센터 장애에 대한 대응성을 가지고 있다. 단 region 간 복제는 지원하지 않는다. 복제에 관련된 옵션으로는 RRS (Reduced Redundancy Storage)라는 것이 있는데, 이 옵션을 적용하면, 2 copy (원본 + 백업)만을 저장하기 때문에, 가격이 훨씬 더 저렴하다.

3 copy를 저장할 경우, S3에 대한 데이타 신뢰도는 99.999999999% 를 보장하고, 서비스에 대한 가용성은 99.99%를 보장한다.

다른 주목할만한 기능 은 retain 기간을 지정할 수 있다. 즉 파일의 저장 기간을 지정할 수 있고, 그 기간이 지나면 자동으로 삭제가 된다.

또한 파일에 대한 versioning 기능을 가지고 있어서, 잘못되었을 경우, 기존의 파일 내용으로 roll back이 가능하다. S3 서비스는 AWS 내에서 대용량 데이타를 저장하기 가장 알맞은 저장소이다. 그래서 다른 AWS의 서비스 (EMR 나 CloudFront, Glacier 등)에 자연스럽게 연동될 수 있는 기능을 제공하며, 다른 서비스들과 상호보완적인 관계를 갖는다. 예를 들어 SQS와 같은 큐 서비스에는 큰 객체(파일)을 저장할 수 없기 때문에 이벤트 메세지는 SQS에 저장하고, 실제 큰 파일은 S3에 저장해서 레퍼런스를 하던가, Dynamo와 같은 NoSQL DB도 레코드당 데이타 한계로 인해서, 메타 데이타는 Dynamo에 저장하고, 파일과 같은 큰 바이너리 데이타는 S3에 저장하고 레퍼런스를 하게 할 수 있다.

매우 간단한 서비스이기는 하지만, 데이타 손실 가능성이 적고, 사용이 간략하며, 다른 서비스와 연계성이 높기 때문에, 필히 익혀둬야 하는 서비스이다.

I have summarized some of the follow-ups below as discussed: User Data and Meta Data – that can be used for bootstrapping as we discussed and I showed you a demonstration of - documentation: http://docs.amazonwebservices.com/AWSEC2/latest/UserGuide/AESDG-chapter-instancedata.html IP Addresses in VPC Auto Scaling Groups: Auto Scaling will automatically assign IP addresses using the DHCP provider when a new instance is launched. However, you could bootstrap it to assign additional IP addresses, using the Elastic Network Interface. Please be sure to consider the following too: http://docs.amazonwebservices.com/AWSEC2/latest/UserGuide/using-instance-addressing.html#MultipleIP Scaling Down Policies: For Auto Scaling Group policies, please use the following syntax when defining the scale down policy (notice how the negative adjustment value requires an "=" sign to work correctly: as-put-scaling-policy policy_scaledown1 --type ChangeInCapacity --auto-scaling-group koreaASG --adjustment=-1 --region ap-southeast-1 AWS Labs: Please download the AWS Labs that I showed you from the following location. It has step-by-step instructions for many scenarios and is a good way to get "your hands dirty" with the various services. It covers Auto Scaling as well as VPN connectivity to VPC using software-VPN. https://aws-labs.s3.amazonaws.com/latest/AWS%20Labs%20Workbook%20v2.2.zip?AWSAccessKeyId=AKIAI4BYU4OOGEEU5JZQ&Expires=1356896712&Signature=70P0jfBWqZkHy%2BO9hREOYJb5zWY%3D Custom Metrics: I have attached the step-by-step exercise we talked about for setting up custom metrics monitoring. These scripts are written in Perl, but you can use your own favorite language (I believe your preference is Java). For Java you can use the PutMetricDataRequest API. Custom metrics cost USD 0.50 per metric per month. Chef and CloudFormation: Please see below for the article on using CloudFormation with Chef configuration management: https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0CC8QFjAA&url=https%3A%2F%2Fs3.amazonaws.com%2Fcloudformation-examples%2FIntegratingAWSCloudFormationWithOpscodeChef.pdf&ei=GKqpUKGlEcbprQeY84GYAg&usg=AFQjCNE8MEewryO9PWVzBC5e086rEWYAwA&cad=rja Also see this link for a range of CloudFormation articles: http://aws.amazon.com/cloudformation/aws-cloudformation-articles-and-tutorials/ CloudFormation Services Not Supported: These are some of the services not supported by CloudFormation (at least not yet). You can see the up-to-date list of supported resources here. Not supported are: Elastic MapReduce, Amazon Fulfillment Web Services, CloudSearch, Simple Workflow Service, Simple Email Service, AWS Direct Connect, Flexible Payment Services, Simple Pay, DevPay, Glacier, Import/Export, Storage Gateway, Alexa, Mechanical Turk. I am still trying to confirm the roadmap for SWF global expansion and Provisioned IOPS. Thanks. Oyvind

AWS (Amazon Web Service) 사용시 주의 사항


1. IP가 매번 바뀐다.

aws의 ec2 instance는 restart시 마다 ip가 매번 바뀐다. ip를 바꾸지 않으려면 EIP (Elastic IP)를 사용해야 하는데, 비용이 크다. 그래서 이런 경우에는 aws에 자체 dns 서버를 세팅하고, instance 가 start up 될때 마다, 고유 서버의 dns 이름을 새로 binding된 ip와 맵핑해서 dns서버에 등록하도록 스크립트를 짜 놓으면 유용하다.


2. io bandwidth를 믿지 마라

aws의 가장 큰 어려운 점이, 네트워크 대역폭이다. 아무래도 공유 서비스이다 보니 네트워크 대역폭이 매우 느리다. 즉 내부 서버간 예를 들어 application server - dbms 또는 application server간에 네트워크 대역폭이 느리고 또는 일정하지 않기 때문에 대 부분의 병목이 여기서 발생한다.

이를 해결하기 위한 방법은 큰 ec2 instance를 사용하면 높은 대역폭을 사용할 수 있으며,

Provisioned IOPS를 지원하는 ec2 instance의 경우에는 일정 수준의 IOPS를 보장해준다. (물론 돈을 내야 한다.)

또는 고 성능의 IOPS를 보장하는 인스턴스를 사용하는 것도 방법이 된다.

다른 방법으로는 Placement group이라는 옵션을 사용할 수 있다. 이는 clustering이 필요한 솔루션 (Nosql이나 cache 솔루션)을 사용할때 이 placement group을 이용하면, 해당 서버들을 가능하면 물리적으로 가까운 곳에 위치 시켜서, network 지연을 최소화 한다.

참고 http://bcho.tistory.com/630


3. 미리 resource를 확보해라.

EIP는 5개, EC instance는 20개가 처음 계정을 만들었을때 디폴트 값이다. 테스트 환경을 사용하거나 몬가 하다보면 eip나 ec2 instance가 모자르게 되는데, 미리 미리 확장에 대비해서 확보해놓는 것도 중요하다. 신규 신청시 시간이 걸리기 때문에 미리 신청해놔야 하며, 상품에 따라서 미리 확보해놓으면 과금이 될 수 있다. 아래는 디폴트로 확보되는 자원의 수이다.

EIP – 5
EC2 instance – 20
EBS Volumes – 5,000 volumes or an aggregate size of 20 TiB (max volume size is 1TB)
PIOPS - 10,000 Provisioned IOPS or an aggregate size of 20 TiB (whichever is smaller) S3 Buckets – 100 
Route53 - 100 Hosted Zones and 10,000 Resource Record Sets per Hosted Zone 
ELB - 10 concurrent load balancers 
RDS – 20 RDS MySQL instances (each instance has hard limit max 1024GB) and up to 5 Read Replica instances can be created from a Master. 
VPC – 5 VPCs, 20 subnets each, 50 Security Groups each, 50 rules per Security Group and 5 Security Groups per instance. 10 Network ACLS per VPC, 20 rules per ACL. 10 Route Tables per VPC and 20 entries per route table


4. 가급적이면 VPC를 사용하자.

VPC는 Virtual Private Cloud의 약자로 10.x.x.x 와 같은 내부 ip 대역을 사용할 수 있게 해준다. 이는 논리적으로 다른 서비스(다른 사용자의)와 분리하게 해줄뿐더러, ip를 고정으로 사용할 수 있게 해주시 때문에 위의 1번 문제를 회피할 수 있도록 해준다.


5. 과금에 관련해서.

안쓸때는 꺼놔라. 다 과금 된다.

1시간5분을 사용하더라도 2시간으로 과금된다. 서버의 startup과 down은 시간 단위로 하자.


6. RDS

최대 용량이 1TB이다. 장점은 AZ(Zone)간의 HA를 기본적으로 지원한다.

replica는 db당 최대 5개 까지만 지원한다.


7. multicast

AWS는 multicast를 지원하지 않는다. 상당수의 클러스터링 솔루션이 muticast를 사용하는 경우가 많다.(Oracle RAC) 이경우에는 AWS에서 클러스터를 사용할 수 없다.


8. ELB는 고정 IP가 아니다.

ELB는 HA와 확장성을 지원하기 위해서 DNS Round Robine 방식으로 연결된다. 즉 고정 IP를 사용할 수 없다. 시스템에 대한 접근 IP(방화벽등을 위해서)가 필요할 경우 ELB 앞단에 HA Proxy등 별도의 Proxy를 둬야 한다.


9. AWS에는 IDS가 없다.

기본적으로 탑재된 침입 탐지등의 ids/ips 솔루션이 없기 때문에, 보안이 중요한 경우 이를 사전 고려 해서 ec2 위에서 기동 될 수 있는 ids/ips 솔루션을 탑재하는 것이 좋다.


10. 장기적인 이용에는 on-demand instance를 이용하지 마라.

on-demand instance는 그때 그때 사용하기는 좋지만 과금 모델이 가장 비싸다. 어느정도 기간을 가지고 이용할 예정이면 reserved instance나 spot instance를 이용하는 것이 저렴하다.







Amazon RDS 성능은 물리 서버의 30% 정도일 뿐!

Amazon RDS에서 DB 테이블 재구성하는 이슈가 있어서 물리 장비 테스트 후 

Amazon RDS에 적용한 적이 있습니다. 사용하고 있는 Amazon RDS 인스턴스가 성

능이 나쁘지 않은만큼 물리 장비 대비 크게 뒤쳐지지 않을 것이라고 예상을 했습니다.

그러나, 실제 적용해본 결과, 물리 서버 대비 30%정도 퍼포먼스만 발휘하는 결과가 

나왔습니다. 로컬 물리 DB에서 15분 걸리던 작업이, Amazon RDS에서는 45분 이상 

소요가 된 사례가 있습니다. 예상 시간보다 상당히 오래 걸려서 크게 당황을 했었죠.

무엇보다 MySQL은 단일 쓰레드에서 Nested Loop 방식으로 SQL을 처리하기 때문

에, CPU의 성능이 전체적인 DB 퍼포먼스에 직접적인 영향을 미칩니다. 병렬 처리가 

없다는 MySQL 특성이 Amazon RDS에서 가장 큰 병목이 되는 것입니다.


http://dev.kthcorp.com/wp-content/uploads/2012/11/H3_2012_double_sided.pdf

403페이지 내용中

대용량 시스템 레퍼런스 디자인


SSAG - Face book Server Side Architecture Group

http://www.facebook.com/groups/serverside

조대협 (bwcho75 골뱅이 지메일닷컴)


I. 배경

웹로직,JBOSS 가 유행이던, J2EE 시대만 하더라도, 웹서버+WAS+RDBMS면 대부분의 업무 시스템을 구현할 수 있었다. 오픈소스가 유행하면서 부터는 프레임웍 수는 다소 많기는 했지만 Spring,IBatis or Hibernate,Struts 정도면 대부분 구현이 가능했다.

그러나 근래 수년 동안 벤더 중심에서 오픈소스 중심에서 기술의 중심이 구글,페이스북이 주도하는 B2C 기반의 서비스의 유행과 더불어 대규모 분산 시스템을 위한 대용량 아키텍쳐가 유행하게 되었는데, 이 아키텍쳐의 특징이 오픈소스 중심에 상당히 다양한 수의 솔루션이 사용 되었다.


II. 내용

이 글에서는 일반적인 대용량 시스템을 구축하기 위한 레퍼런스 아키텍쳐를 소개한다.

일반적인 웹이나 서버 플랫폼을 개발할 수 있는 레퍼런스 아키텍쳐이며, 자주 사용되는 오픈 소스 솔루션을 조합하였다.


또한 이 아키텍쳐는 데이타 분석등의 용도가(OLAP)이 아니라 온라인 트렌젝션 처리 (OLTP)성 업무를 위해서 디자인된 아키텍쳐이다.


III. 레퍼런스 아키텍쳐



1. Reverse Proxy Layer - Routing & Load Balacing

첫번째 계층은 Reverse Proxy 계층으로, 첫번째에 들어오는 HTTP Request에 대한 관문 역할을 한다.

이 Reverse Proxy에서는 초기 Request에 대한 Logging, 필요하다면, Authentication & Authorization 처리를 수행하고, 뒷쪽에 Request를 보낼때, 뒷단의 Node로 Routing 또는 Load Balancing을 한다.

뒷단에 클러스터가 업무에 따라서 여러 클러스터로 나뉠 수 있기 때문에 이에 대한 라우팅을 수행하거나, 같은 업무에 대해서는 단일 클러스터에 대해서 여러 서버에 대한 로드 밸런싱을 수행한다.


뒤에 살아 있는 서버에 대한 리스트나 클러스터에 대한 정보는 ZooKeeper에 저장하며, Scale In/Out시 또는 장애시에는 이 정보를 ZooKeeper에 업데이트 하여, ZooKeeper에 저장된 클러스터 정보를 기준으로 라우팅을 한다.


사용할만한 솔루션으로는 Apache,NginX,HA Proxy등이 있다.

성능 상으로는 NginX가 가능 높다. 그러나 NginX는 대용량 HTTP Request에 대해서 아직 제대로 지원하지 않는 부분이 있다. 파일 업다운 로드의 경우 성능이 급격하게 떨어지는 부분이 있다. 위에서 설명한 ZooKeeper연동이나 Routing 기능들은 module을 구현하여 plug in해야 한다.


2. [Optional] Enterprise Service Bus (ESB) Layer - Cross Cutting Concern, Mash up,Routing,MEP (Message Exchange Pattern Converting),Integration, SLA management,Protocol Converting

이 계층은 필요에 따라 넣거나 뺄 수 있는 Optional 한 부분이다. Enterprise Service Bus는 시스템으로 들어오는 메세지에 대해서 좀 더 확장된(진보된) 기능을 제공하는 계층으로, SOA (Service Oriented Architecture)에서 따온 계층이다. 키 포인트는 성능이다. BY PASS의 경우 10~50ms 이내에 통과(IN/OUT 포함), 몬가 작업을 할 경우에는 100ms 이하에 통과되어야 한다.

ESB 계층에서 다루어야 하는 일들은 다음과 같다.

  • Cross Cutting Concern 처리 : Cross Cutting Concern는 횡종단 처리라고 하는데, 모든 메세지에 대해서 뒷단의 비지니스 로직이 공통적으로 처리해야 하는 부분을 이야기 한다. 대표적인 예로, Logging, Authentication & Authorization 등이 있다. 
  • Routing 처리 : Reverse Proxy 보다 향상된 Routing 기능을 제공할 수 있다. 보통 Reverse Proxy에서는 HTTP Header나 URI등의 최소한의 정보를 바탕으로 라우팅을 하는데 반해서, ESB 계층에서는 Message 본문의 Header나 Message 자체의 내용을 가지고 라우팅을 할 수 있다. 예를 들어 VIP 회원에 대해서는 Dedicated 된 서버로 라우팅을 하는지 등의 처리가 가능하다.
  • Protocol Converting : ESB 계층에서는 또한 Protocol 변환을 할 수 있다. 예를 들어 뒷단의 비지니스 컴포넌트가 XML/REST를 지원하는데, 전체 표준을 JSON/REST를 사용한다면, ESB 계층에 프로토콜 변환 기능을 넣어서 JSON to XML 변환을 수행할 수 도 있고, 또 다른 예로는 통신사의 경우 종종 HTTP 메세지를 손을 대는 경우가 있다. Header에 통신사 고유의 헤더를 삽입하는 등의 일이 있는데, 이런 경우 범용으로 디자인 된 시스템은 
  • Mash Up : Mash Up은 뒤의 비지니스 로직 여러개를 합쳐서 하나의 비지니스 로직을 만들어 내는 것을 이야기 한다. 쉬운 예로 기존 서비스가 "구매" 라는 Function이 있었는데, "포인트 적립" 이라는 기능이 새롭게 추가 되었을때, 비지니스 로직 자체를 변경하는 것이 아니라 기존 "구매" 라는 기능에 +"포인트 적립" 이라는 기능을 Mash up으로 더해서 기능을 변경하는 것이다. 이렇게 하면 비지니스 로직 변화 없이 새로운 기능을 구현할 수 가 있다.
  • MEP Converting : MEP란 Message Exchange Pattern의 약자로 메세지의 호출 방식을 이야기 한다. 쉽게 말하면 Sync,Async 와 같은 호출 방식을 정의하는데, 비지니스 로직이 Long Running 하는 Sync 형식의 서비스 였을 때, ESB를 이용하여, Sync 호출을 Async 형태로 변경할 수 있다. (ESB에서 응답을 먼저 보내고, ESB에서 비지니스 컴포넌트로 ASync로 보내는 형태)
  • Integration : 타 시스템과의 통합을 이야기 한다. 일종의 EAI (Enterprise Application Integration) 기능인데, 앞에서 언급된 Mash up + Protocol Conversion + MEP Converting을 합쳐놓은 기능과도 비슷하다. 크게 대내 시스템간의 통합과 대외 시스템과의 통합등으로 나뉘어지며, 대내 시스템과의 통합은 Legacy (SAP와 같은 ERP, Siebel과 같은 CRM과 같은 패키지 형태의 Application)과 통합 하는 경우가 많으며 이런경우 전용 아답터를 사용하는 경우가 많다. 대외 시스템 통합의 경우 예를 들어 전자 결재나 PUSH 서비스 등과  통합하는 경우이며 이 경우 필요에 따라 프로토콜 변환이나 Authentication & Authorization 처리를 하는 경우가 많으며 특히 과금이 연동되는 경우에는 향후 Audit을 위해서 로그를 기록하고 향후 비교하는 경우가 많다.
  • SLA management : SLA (Service Level Agreement)로, Service의 품질을 보장 하는 기능이다. 정확하게는 SLA를 보장한다기 보다는 SLA에 문제가 생겼을때 이를 빠르게 감지하여 후처리를 할 수 있다. ESB는 시스템으로 들어오는 모든 메세지에 대한 관문 역할을 하기 때문에 응답 시간이나 TPS에 대한 변화가 생겼을때 이를 검출할 수 있는 단일 지점으로, 장애 상황에 대한 검출이 있었을때 이에 대한 후처리를 하도록 관리자에게 통보할 수도 있고, 또는 ZooKeeper를 통해서 성능이 떨어지는 노드들에 대한 Scale Out등을 지시할 수 있다.

ESB는 설계시에 적용을 해놓으면 후에 시스템의 변화가 있을 경우에 도움이 많이 되는 계층이다. 시스템 초기 운영시에는 오히려 큰 이득을 보지 못한다. 왜냐하면 처음에는 모든 비지니스 컴포넌트가 초기 요구 사항에 맞춰서 구현이 되었고, 위의 기능들은 시스템을 운영하면서 요구사항이나 환경적인 변화에 따라 발생하는 요구 사항이기 때문이다. 

앞에서도 언급했으나, ESB는 메세지가 지나가는 중간에 위치 하기 때문에 전체 시스템의 성능에 영향을 주게 되기 때문에 성능에 각별한 신경을 써서 디자인을 해야 하며, 특히 메세지의 파싱하는 과정과 메세지 자체 설계에 신경을 많이 써야 한다. 예를 들어 일반적인 경우 메세지의 BODY 부분을 파싱할 일이 없는데 모든 요청에 따라서 BODY 부분을 파싱하게 한다면 이에 대한 오버로드가 상당히 크게된다.


사용 가능한 솔루션으로는 Apache Mule이나 Oracle사의 Oracle Service Bus등이 있고, 재미있는 장비중의 하나는 Oracle Service Bus 제품중에 XML 기반의 메세징을 파싱하는 부분을 Hardware로 구현해놓은 제품이 있다. Oracle Service Bus도 내부적으로 JAXP 기반의 XML Parser를 이용하는데, 이 구현 부분을 ASIC으로 구현해 놓은 제품이 있는데 이 제품의 경우 메세지 처리 속도를 많이 높일 수 있다.


3. WAS Layer - Business Logic

이 계층은 비지니스 로직을 핸들링 하는 계층이다.

Web Application Server (WAS)로 구현이 가능하며, 고속 멀티플렉싱 기반의 고속 처리가 필요한 경우나 대규모 Stateful Connection이 필요한 경우에는 Netty와 같은 네트워크 서버를 사용한다.

이 계층 구현시 중요한점은 Shared Nothing 아키텍쳐를 적용하는 것을 권장한다.

Shared Nothing이랑 WAS 인스턴스끼리 클러스터링등을 통해서 묶지 않고 각각의 WAS를 독립적으로 돌아가게 설계하는 것이다. (대표적으로 Session Clustering을 사용하지 않는것)

이렇게 하는 이유는 특정 인스턴스가 장애가 났을 때 클러스터를 타고 전파되는 현상을 방지하고 또한 횡적인 확장 (Horizontal Scalability )를 보장하기 위해서이다.

참고 자료 

- WAS 기반의 아키텍쳐 http://bcho.tistory.com/373

- J2EE 그리드 아키텍쳐 http://bcho.tistory.com/330


4. Async message Handling

WAS 계층이 Sync 형태의 동기 (Request/Response) 메세지를 처리한다면, 비동기 메세징 처리나 Publish/Subscribe와 같은 1:N 기반의 비동기 메세지 처리를 하는 계층이 필요하다.

예전에는 MQ나 JMS를 많이 사용했으나, 근래에는 좀더 향상된 프로토콜인 AMQP를 기반으로 한 RabbitMQ가 많이 사용된다.


RabbitMQ의 경우에도 수억명의 사용자를 커버하기에는 클러스터의 확장성이 문제가 있기 때문에 이런 경우에는 MySQL등의 DBMS의 테이블을 큐 처럼 사용하고, 메세지를 읽어가는 부분을 Quartz등을 이용해서 주기적으로 읽어가서 처리하는 구조로 만들게 되면 확장성을 보장할 수 는 있으나, 복잡한 비동기 메세징 (에러처리, Pub/Sub)을 구현하기에는 난이도가 높기 때문에, RabbitMQ를 복수의 클러스터로 묶는 Sharding이나 분산큐(Distributed Queue) 개념을 고려할 필요가 있다.


5. Temporary Storage Layer - Temporary space

다음 계층은 Temporary Storage Layer - 작업 공간이다.

이 작업 공간은 4번의 WAS들이 서로 데이타를 공유할 수 있는 "휘발성", 작업 공간이다. 

필수 조건은 높은 성능을 보장해야 하며, 모든 WAS Node가 접근할 수 있어야 한다. 저장 매체가 Memory냐, Disk냐에 따라서 다음과 같이 나눠볼 수 있다.


1) Data Grid (Memory)

데이타 그리드는 쉽게 생각하면 자바의 HashTable 같은 Key/Value Store 기반의 메모리 Store이다. 단.. 이 그리드는 클러스터 구성을 통해서 용량 확장이 가능하고, 별도의 서버 클러스터로 구성되어 여러개의 WAS 노드들이 접근할 수 있다. 일종의 WAS간의 공유 메모리라고 생각하면 된다.

솔루션으로는 Oracle Coherence (예산만 넉넉하다면 이걸 쓰는게 맘편하다), Redis, memecahed, Terracota 등이 있다.

참고 자료 

- Redis 소개 - http://bcho.tistory.com/654

- Coherence를 활용한 아키텍쳐 설계 - http://bcho.tistory.com/327


2) Working Space (DISK)

트렌젝션을 처리하다 보면, 종종 임시적인 작업 공간이 필요할때가 있다. 예를 들어 드롭 박스와 같은 파일 서비스를 이야기 해보자, 드롭박스는 이미지 파일을 하나 올리면, 모바일 디바이스의 화면 해상도에 맞게 5개의 썸네일 이미지를 재 생산한다. 이런 작업을 하기 위해서는 이미지 파일을 저장하기 위해서 임시로 저장해놨다가 썸네일을 추출하는 공간이 필요한데 이를 임시 작업 공간이라고 한다.

데이타 그리드와 마찬가지로, 여러 노드들이 해당 공간을 공유할 수 있어야 한다. 그래서 NFS (Network File System)이 많이 사용되며, Gluster와 같은 소프트웨어 기반의 NFS나 NetApp社의 NFS appliance server (하드웨어) 등이 있다.

참고 자료

- Amazon에서 Gluster 성능 비교 자료 - http://bcho.tistory.com/645


6. Persistence Layer

다음은 영구 저장 공간이다. 영구 저장 공간은 우리가 일반적으로 생각하는 데이타가 저장되는 공간이라고 보면된다.  쉽게 예를 들 수 있는 공간으로는 데이타 베이스와 파일 시스템을 들 수 있다. 이러한 영구 저장소는 대용량 B2C 시스템의 유행과 함께 새로운 DBMS들이 등장하였는데, DBMS 측면에서는 Key Value Store 기반의 NoSQL이나, 대용량 파일을 저장할 수 있는 Object Store등을 그 예로 들 수 있다.


1) Relational Data

개체간의 관계가 있는 경우에 대한 데이타를 관계형 데이타라고 하고, 이를 핸들링 하기 위해서는 관계형 데이타 베이스 RDBMS를 사용한다. 우리가 지금까지 일반적으로 사용해왔던 데이타 베이스가 이 RDBMS이다. RDBMS는 대용량 서비스를 위해서는 태생적인 한계를 가지고 있는데, 예를 들어 MySQL의 경우 하나의 데이타베이스에서 저장할 수 있는 레코드의 수가 10억개 정도가 최적이다. 

이런 문제를 해결하기 위해서는 대용량 시스템에서 몇가지 기법을 추가로 사용하는데 "Sharding" 과 "Query Off Loading"이다.


Sharding이란, 데이타의 저장용량의 한계를 극복하기 위한 방안으로

데이타를 저장할때 데이타를 여러 데이타 베이스에 걸쳐서 나눠 저장하는 방법이다. 예를 들어 "서울","대구","대전"등 지역별로 데이타베이스를 나눠서 저장하거나(이를 횡분할 Sharding) 또는 10대,20대,30대 식으로 데이타를 나눠서 저장하는 방식(이를 수직분할 Sharding)을 사용한다. 이러한 Sharding은 데이타베이스 계층에서 직접적으로 지원하기가 어렵기 때문에, 애플리케이션 레벨에서 구현해야 한다.


다음으로 Query Off Loading이라는 기법으로, 이 기법은 성능의 한계를 높이기 위한 기법이다. 

"Master DB → Staging DB → Slave DB 1,Slave DB 2,....N"

    1. Create/Update/Write/Delete는 Master DB에서 수행하고
    2. Master DB의 데이타를 Staging DB로 고속 복사한후
    3. Staging DB에서 N개의 Slave DB로 데이타를 복사한다.
    4. Read는 Slave DB에서 수행한다.

일반적인 DBMS 트렌젝션은 10~20% 정도가 Update성이고, 나머지 80~90%가 Read성이기 때문에, Read Node를 분산함으로써, 단일 DBMS 클러스터의 임계 처리 성능을 높일 수 있다.


이때 Master/Staging/Slave DB로 데이타를 복제하는 방식이 매우 중요한데, 여기서 일반적으로 사용하는 방식을 CDC (Change Data Capture)라고 한다.

RDBMS는 데이타 베이스 장애에 대한 복구등을 위해서 모든 트렌젝션을 파일 기반의 로그로 남기는 데 이를 Change Log라고 한다. CDC는 이 Change Log를 타겟 DB에 고속으로 복사해서 다시 수행(Replay)하는 형태로 데이타를 복제한다.


MySQL의 경우 Clustering에서 이 CDC 기능을 기본적으로 제공하고 있고, Oracle의 경우 Oracle Golden Gate라는 솔루션을 이용한다. (비싸다..) 중가격의 제품으로는 Quest의 ShareFlex들을 많이 사용한다.


2) Key/Value Data

다음으로 근래에 들어서 "NoSQL"이라는 간판을 달고 가장 유행하는 기술중의 하나가 Key/Value Store이다.

데이타 구조는 간단하게 Key에 대한 데이타(Value)를 가지고 있는 형태이다. RDBMS와 같이 개체간의 관계를 가지지 않는다.

오로지 대용량,고속 데이타 억세스,데이타에 대한 일관성 에만 초점을 맞춘다. (이중에서 보통 2개에만 집중한다. 이를 CAP 이론 - Consistency, Availability, Performance)


이 기술은 태생 자체가 B2C 서비스를 통해서 탄생하였다.

블로그나 트위터, 페이스북 처럼 데이타의 구조 자체가 복잡하지 않으나 용량이 많고 고성능이 필요한 데이타들이다. 태생 자체가 이렇기 때문에 복잡한 관계(Relationship)을 갖는 복잡한 업무 시스템에는 잘 맞지 않는 경우가 많으며, 트렌젝션 처리나 JOIN, SORTING 등이 어렵기 때문에 애플리케이션의 구현 복잡도가 올라간다.


참고 자료

- 사람들은 왜 NoSQL에 열광하는가? - http://bcho.tistory.com/658

- Amazon Dynamo 계열의 NoSQL 장단점 - http://bcho.tistory.com/622

- NoSQL Riak - http://bcho.tistory.com/621

- NoSQL 계보 정리 - http://bcho.tistory.com/610

- Cassandra 소개 - http://bcho.tistory.com/440


3) Object Data

Object Data는 File과 같이 대용량 데이타 파일 저장을 할 수 있는 Storage이다.

10M,1G와 같은 대용량 파일을 저장할 수 있는 저장소로, Amazon의 S3, Openstack SWIFT등이 대표적인 예이며, 하드웨어 어플라이언스 장비로는 애플의 iCloud로 유명해진 EMC의 isilion등이 있다.

Object Data 저장에 있어서 중요하게 생각하는 부분은 대용량의 데이타를 저장할 수 있는 용량에 대한 확장성과 데이타 저장에 대한 안정성이다. 

이러한 Object Data는 Quorum이라는 개념을 적용하여, 원본을 포함하여 N개의 복사본을  유지한다. 일반적으로는 N+3 (3개의 복사본)을 저장하여 데이타에 대한 안정성을 보장한다. 


4) Document Data

Document Data는 Key/Value Store에서 조금 더 발전한 데이타 저장 방식으로

Key 자체는 동일하나 Value에 해당하는 부분이 Document가 저장된다. Document 는 JSON이나 XML 문서와 같이 구조화된 데이타를 저장한다.

RDBMS가 다양한 select, where, group, sorting,index 등 여러가지 데이타에 대한 기능을 제공한다면, Key/Value Store는 이런 기능은 거의 제공하지 않는다. Document Data를 저장하는 제품들은 RDBMS와 Key/Value Store의 중간정도에서 데이타에 대한 핸들링 기능을 제공한다. (부족한 Indexing 기능, 부족한 Group 기능, 부족한 Sorting 기능등)


대표적은 솔루션으로는 MongoDB,CouchDB, Riak등이 있다.


요즘 들어서 자주 사용되는 대표적인 Persistence Store에 대해서 간단하게나마 집고 넘어갔지만, 사실 이 보다 더 많은 형태의 Persistence Store들과 기능들이 있다.


7. Configuration management & Coordinator

대용량, 분산 시스템으로 발전하면서 풀어야되는 문제중의 하나가 "분산되어 있는 노드들에 대한 설정(Configuration)정보를 어떻게 서로 동기화하고 관리할것인가? (이를 Configuration Management라고 한다.) " 인다. 거기에 더해서 클라우드 인프라를 사용하면서 "전체 클러스터내의 서버들의 상태를 모니터링 해서, 서버의 수를 느리고 줄여야 하며 서버들간의 통신을 중재해야 한다. (이를 Coordination 이라고 한다.)"  


여기에 필요한 기능이 작은 량의 데이타(Configuration Data)를 여러 서버가 공유해서 사용할 수 있어야 하며, 이 데이타의 변화는 양방향으로 클러스터 노드내에 전해져야 한다.

즉 Configuration 정보를 각 서버들이 읽어올 수 있어야 하며, 이 Configuration 정보가 바뀌었을 경우 다른 서버들에게 데이타가 변했음을 통지해줄 수 있어야 하며, 중앙 집중화된 Configuration 정보 뿐만 아니라, 서버의 상태가 변했음을 다른 서버들에게 빠르게 알려줄 수 있어야 한다.


이런 역할을 하는 대표적인 솔루션으로는 ZooKeeper 많이 사용된다.


8. Infrastructure

마지막으로 이런 소프트웨어 스택을 구동하기 위한 하드웨어 인프라가 필요한데, 예전에는 일반적인 서버를 Co-Location이나 Hosting 형태로 사용하는 것이 일반적이었으나, 요즘은 가상화 기술을 기반으로 한 클라우드 (Infrastructure as a service)를 사용하는 경우가 많다.

클라우드의 특징은 "Pay-as-you-go" 로 자원을 사용한 만큼에 대해서만 비용을 지불하는 구조이다. CPU를 사용한 만큼, 디스크를 사용한 만큼, 네트워크 대역폭을 사용한 만큼만 비용을 지불한다.


Amazone WebService (AWS), Microsoft Azure, Google App Engine등이 대표적인 예인데, 이러한 클라우드의 장점은 Time To Market (시장 진입 시간)이 매우 짧다는 것이다. 앉아서 신용카드와 PC만 있다면 인터넷에 접속해서 30분내에 서버,디스크,네트워크등을 설정해서 사용할 수 있다.

단 이러한 클라우드 인프라는 Public 한 서비스 형태로 공유되서 서비스 되기 때문에 일반적인 호스팅과는 달리 성능등에 대한 한계를 가지고 있다. 예를 들어 서버와 디스크간의 네트워크 대역폭이 보장되지 않기 때문에 디스크 IO가 많은 애플리케이션 (DBMS와 같은)에 대한 성능을 보장하기가 쉽지 않고, LAN 설정이 자유롭지 않기 때문에 UDP등을 이용해서 클러스터링을 하는 제품의 경우 클러스터링을 사용할 수 없는 경우가 있다.  이런 이유로, 클라우드위에서 구현되는 시스템의 경우에는 해당 클라우드의 기술적인 특징을 제대로 이해하고 구현해야 한다.


또한 클라우드가 "Pay-as-you-go" 형태로 사용한만큼 비용을 지불한다는 것이 어떻게 보면 "싸다"라고 느껴질 수 있지만, 네트워크,IP 등등 모든 자원에 대해서 비용을 지불하기 때문에 실제적으로 계산해보면 싸지 않은 경우도 많고 기술적인 제약 때문에, 초기 시장 진입을 하는 경우에는 클라우드를 사용하는 경우아 많지만 규모가 커진 서비스의 경우에는 다시 자체 데이타 센타를 구축하는 경우가 많다. (예 소셜 게임 서비스인-Zinga, VOD 서비스인-Netflix)


운영 측면에서 인프라에 대한 관리를 클라우드 업체에 대행시킴으로써 얻는 이득도 있지만 불필요한 비용이 낭비되지 않게 클라우드 인프라에 대한 배포 구조를 끊임 없이 최적화 하는 노력도 필요하다.


IV. 결론

지금까지 현재 유행하는 대용량 고성능 시스템에 대한 레퍼런스 아키텍쳐에 대해서 설명하였다. 사실 이 글을 정리한 이유는 글을 쓰는 본인도 기술이 변화함을 느끼고 있었고, 이에 대한 공부와 개념 정리가 필요하다고 느껴서인데, 확실하게 기술 구조는 변했다. 유행하는 기술도 변했다. 대용량 시스템은 이런 구조로 구현하는게 하나의 모범 답안 (정답이 아니라는 이야기)은 될 수 있으나, 대부분의 IT 시스템은 이런 대용량 아키텍쳐 구조 없이도 WAS + RDBMS 구조만으로도 충분히 구현이 가능하다.

그럼에도 불구하고 이러한 레퍼런스 아키텍쳐에 대한 글을 쓴 이유는 레퍼런스 아키텍쳐를 이해하고, 이런 아키텍쳐가 왜 필요한지 어디에 쓰이는지를 이해한 후에 제대로 적용하기를 바라는 마음에서 정리 하였다. 이러한 대용량 기술은 유용한 기술임에는 분명하지만, 닭잡는데 소잡는 칼을 쓸 필요는 없지 않은가?


누락된 부분

※ node.js 를 이용한 Long Running Connection Service : 예-Push 등을 추가 할것.

※ Map & Reduce를 이용한 분산 처리

※ 데이타 분석을 위한 Hadoop 또는 OLAP성의 처리 아키텍쳐


P.S. 요즘 제 포스팅들이 읽이 어려운가요? 내용은 어떤지요? 피드백을 못 받아서 궁금합니다. 요즘 글들이 축약적인 내용이나 추상적인 개념들을 많이 이야기 하는 것 같아서요. 


어제 발표된 Microsoft Azure의 IaaS 서비스와 Amazon의 AWS 서비스 사이에 가격 비교를 해봤다.

아래 내용은 네트워크 비용이나 Blob Storage 등 부가 서비스를 제외하고 EC2 서비스 만을 비교한 것이다.

 

 

요약 - Linux VM의 경우 동일, Windows VM의 경우 MS가 저렴

Linux VM의 경우 동등 인스턴스 크기에서는 Amazon과 Azure 양쪽 가격이 같다. Azure가 레퍼런스해서 만든 느낌이 가득하다. 

 

Azure 장점 

- Windows Server VM의 경우 Amazon 대비 저렴. Amazon은 Windows VM에 대해서 별도의 가격 정책을 책정하나, Azure의 경우 Linux와 Windows를 모두 동일하게 가져감

 

Azure 단점

- 인스턴스 종류가  XS,S,M,L,XL 로 4개로 한정, 이에 반면 Amazon은 용도에 맞게 High-Memory Instance, High CPU Instance, Cluster Compute Instance, Cluster GPU Instance등을 다양하게 제공

 

결론

Instance의 실제 성능이나 IO 성능등은 테스트해서 비교해봐야겠으나, 일단 가격 정책상으로는 서로 경쟁할만한 위치에 왔다고 보여짐.

 

참고 자료

AWS 가격 - http://www.ec2instances.info/

Azure 가격 - http://www.windowsazure.com/ko-kr/pricing/calculator/?scenario=virtual-machines

 

원문 : http://www.isi.edu/~gideon/publications/JuveG-DataSharing.pdf

 

아마존에서 과학관련 HPC 분산 컴퓨팅 시에, 공유 스토리지 (NFS, Shared Storage)에 대한 성능 비교 및 Cost 비교를 해 놓은 문서 입니다. EBS나 Local Disk와 같은 스토리지가 아니라 공유 스토리지에만 한정합니다.

 

Amazon S3, Gluster, NFS, PVFS를 중심으로 비교했는데,

결론 적으로 GlusterFS(NUFA Configuration)이 성능도 높은편에 속하고 Cost도 저렴합니다.

 

그림 1. Cost 비교 

 

 

그림 2. 성능 비교 

 

저도 Gluster를 AWS에서 사용했는데, 무엇보다 AWS에 Gluster를 Deployment하기 위한 Best Practice 문서등이 잘 되어 있습니다.

 

참고하세요.

 

요즘 일이 바뻐서 블로그 포스팅을 거의 못하고 있습니다.
많이 버는 만큼, 그동안 충전해왔던 지식이나 노하우를 주로 방전하는 느낌입니다.

어쨌거나, 클라우드의 양대 산맥인 아마존 AWS와 Microsoft Azure에 대한 이야기를 해보려고 하는데..
Azure vs AWS의 승자가 누구이냐? 인데. 결론 부터 이야기 하면 AWS의 손을 들어주고 싶습니다.
Blob Storage나 DB 서비스와 같은 액세사리성 서비스는 양쪽다 어느정도 구색을 갖춰 놨다고 했을 때, 핵심인 Compute Service가 문제인데.
기본적으로 Azure는 .NET 기반의 PaaS만 지원하지만, Amazon은 모든 플랫폼을 올릴 수 있는 IaaS 수준 서비스를 제공합니다.
이말인즉슨, 내가 필요한 소프트웨어를 마음대로 올릴 수 있다는 겁니다. 단순하게 Java냐, .Net이냐 차이가 아니라
서비스를 하다보면 NFS가 필요할 수 도 있고, 제공해주는 NoSQL 서비스의 성능 문제로, Mongo나 Cassandra를 쓰고 싶을 수 도 있고, 빌드 환경을 만들어보고 싶을 수 도 있고, 여러가지 요구 사항이 존재하는데, Azure는 그게 안되고, 그냥 딱!! .NET 개발만 해야 한다는 것인데, 단순한 웹 애플리케이션 시나리오라면 모르겠지만
요즘과 같이 빅데이타나 분산 아키텍쳐가 유행하는 시절에 이것만으로는 부족하다는 말입니다.

기술적으로 Azure가 상당히 뛰어난점도 많은데, IaaS 단으로 오픈을해서, 조금 더 선택의 폭을 넓혀 줬으면 합니다.
이상 사견이었습니다.
Amazon EC2의 내부 구조에 대한 고찰이 있는 글이 있어서 링크
http://openfoo.org/blog/amazon_ec2_underlying_architecture.html

1. Xen Server 쓰는 건 다 아는 사실이고
2. EBS를 iSCSI 기반 GNDB (http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/3/html/GFS_6.0_Administration_Guide/ch-gnbd.html) 를 쓴다는 게 참고할만한 내용

Elastic Block Store

The characteristics of the Elastic Block Store (EBS) lead to the conclusion that it is probably a SAN-based setup. I have guessed that they probably use iSCSI volumes exported to the nodes, and I was surprised that they use something different: Global Network Block Device (GNBD). The backend device of a EBS is listed as something like params = "/dev/gnbd89". Of course I don’t know how the block device exporter is designed and what kind of storage system they use on that side. Some more information about GNBD can be found here, which could also lead to the conclusion that Amazon uses RedHat’s cluster suite.




Amazon EC2 Auto Scale out 아키텍쳐http://docs.amazonwebservices.com/AutoScaling/latest/DeveloperGuide/index.html?Welcome.html

  1. Cloud Watch를 통해서, 이미 기동중인 Instance를 모니터링 한다.
  2. Instance의 CPU나 Throughput을 기반으로 해서 Scale out 여부를 결정한다
  3. Scale out을 하게 되면, 해당 Instance의 AMI를 추가로 Provisioning 한다.
  4. Elastic Load Balancer에 새롭게 추가된 Instance를 연결해준다.

기본적인 아키텍쳐인데, 전형적인 Scale Out 방식이고, Image에 올라가 있는 (VM)의 Application의 Scale out은 지원하지 않고, 개발자 스스로 대비해야 한다.
Apache와 같은 웹서버나, 클러스터링이 되어 있지 않은 Tomcat과 같은 WAS는 가능하겠지만, 아래 글에서 처럼, Oracle이나 MySQL과 같은 DBMS나 JMS등은 Scale out 자체가 불가능 하기 때문에, 자체로 클라우드 대비 아키텍쳐로 디자인 해야 한다.