이 시리즈의 첫 번째 기사에서는 단일 실제 서버를 실제 단일 클라우드 서버로 마이그레이션하는 방법을 살펴보았다. 모든 작업을 마치긴 했지만 여러 단일 오류 지점이 발생하여 애플리케이션의 성능이 크게 향상되지 않았다.

단일 실제 서버라고 하더라도 중복 전원 공급장치, 오류 수정 RAM, 중복 디스크 및 오류 전 표시기를 이용한 다양한 모니터링 기능을 사용할 수 있다. 클라우드 서버에서는 사용자가 사용자에게 제공된 기능 더 나아가 사용자가 액세스할 수 있는 기능에 대해 모르고 있다. 클라우드 서버는 일반적으로 신뢰할 수 있지만 주의를 기울이는 것이 현명하다. 특히, Amazon에서는 신뢰성 향상을 위해 추가 서비스를 제공하고 있기 때문이다.

클라우드 환경에 배치할 경우에는 가상 인스턴스가 언제라도 손실될 수 있다는 점을 염두에 두어야 한다. 이는 클라우드 서비스가 신뢰할 수 없는 서비스라는 의미가 아니며, 단지 발생하는 오류의 유형이 실제 환경에서 자주 발생하던 오류와 다르다는 의미이다. 따라서 애플리케이션에 지능을 불어넣어서 통신 손실을 처리하고 여러 서버로 확장해야 한다. 이렇게 생각하면 빌드 중인 환경의 유형에 상관 없이 보다 나은 애플리케이션을 빌드할 수 있다.

이 기사에서는 Amazon EBS(Elastic Block Store)를 사용하여 데이터베이스의 임시 스토리지를 향상시키는 방법에 대해 설명한다. 백업을 설정하여 데이터 보호 성능을 향상시킬 수 있다. 여러 인스턴스를 이용한 로드 밸런싱을 수행하면 다양한 오류로부터 복구할 수 있으며, 결과적으로 애플리케이션 서버 손실을 방지할 수 있다.

그림 1에서는 지난 기사에서 마무리했던 시점의 애플리케이션 아키텍처를 보여 준다.

모든 기능이 하나의 Amazon EC2(Amazon Elastic Compute Cloud) 인스턴스에 있다. 프론트엔드 웹 서버인 nginx는 여러 mongrel 인스턴스에 대한 요청을 프록시하거나 정적 파일 자체를 제공한다. mongrel 애플리케이션 서버는 같은 호스트에 있는 PostgreSQL 데이터베이스에 액세스한다.

지속적 디스크 구성하기

인스턴스 스토리지는 Amazon EC2와 VMware 및 Xen 같은 가상 기술 사이의 가장 큰 차이점이다. Amazon EC2 인스턴스는 고정된 10GB 용량의 루트 파티션과 실행된 인스턴스의 유형에 따라 크기가 결정되는 인스턴스 디스크를 제공한다. 루트 파티션은 부팅할 때 AMI(Amazon Machine Image)에서 복제되고 인스턴스 저장소는 비어 있다. 서버를 종료하면 인스턴스 저장소가 삭제된다.

Amazon에서는 초기에 사용자에게 서버를 Amazon S3(Amazon Simple Storage Service)에 자주 백업하도록 안내했다. 서버에서 충돌이 발생할 경우 다른 서버를 사용하여 로드를 처리하거나 Amazon S3에서 사용자의 데이터를 가져올 수 있다. 마침내 Amazon에서는 지속적 디스크를 제공하는 서비스인 EBS를 사용하여 이 문제를 해결했다. 서버에서 충돌이 발생할 경우 EBS 볼륨을 다른 서버에 다시 연결할 수 있다. Amazon에서는 백업을 지원하기 위해 스냅샷 메커니즘도 개발했다.

SmallPayroll 애플리케이션에서 데이터베이스 서버와 관련하여 주된 문제점은 데이터베이스 서버가 단일 오류 지점이라는 것이다. 이 문제점을 해결하는 데는 일반적으로 두 가지 방법이 사용된다. 첫 번째 방법은 서로를 대체할 수 있는 두 개의 데이터베이스 서버를 빌드하는 것이며, 두 번째 방법은 잠재적 중단 시간을 합리적인 수준으로 낮추는 것이다. 첫 번째 방법의 경우에는 중단 시간이 최소화되지만 복잡하다. 두 번째 방법은 이 상황에서 훨씬 더 실용적이다. 데이터베이스 서버에서 충돌이 발생할 경우 새 인스턴스가 시작되어 기존 인스턴스를 대체한다. EBS가 데이터를 안전하게 유지한다. 새 데이터베이스 서버를 실행하고 클라이언트를 다시 지정하는 데 걸리는 총 시간은 오류가 통지된 시간부터 10분 미만이어야 한다. 마지막 보너스로 EBS 스토리지는 인스턴스 스토리지보다 높은 I/O 용량을 제공한다.

EBS를 사용하려면 다음 단계를 수행한다.

1. ec2-create-volume 명령을 사용하여 볼륨을 작성한다.
2. ec2-attach-volume 명령을 사용하여 볼륨을 실행 중인 인스턴스에 연결한다.
3. 볼륨에 파일 시스템을 작성한다.
4. 파일 시스템을 디렉토리에 마운트한다.

처음으로 EBS 설정하기

EBS를 설정하려면 먼저 볼륨을 작성하고 싶다는 사용자의 의사를 Amazon에 알려야 한다. 이를 위해서는 두 가지 사항 즉, 이미지 크기(GB 단위)와 이미지를 사용할 가용성 영역을 알아야 한다. 가용성 영역은 서버의 위치를 설명하기 위해 Amazon에서 사용하는 용어이다. us-east로 시작하는 영역은 북 버지니아 주에 있으며 총체적으로 지역이라고 부른다. 현재 us-east 지역에는 us-east-1a, us-east-1b 및 us-east-1c라는 세 개의 영역이 있다. 각 가용성 영역은 다른 가용성 영역의 오류에 영향을 받지 않도록 설계되었다. 동일한 지역 내의 영역은 서로 가깝기 때문에 지연 시간도 짧다.

EBS의 한 가지 제한사항은 볼륨이 작성된 가용성 영역에서만 볼륨을 마운트할 수 있다는 것이다. 여러 가지 방법으로 볼륨을 이동할 수는 있지만 서버와 동일한 가용성 영역에 볼륨을 작성해야 한다.

다음 명령을 실행한다.

ec2-create-volume -s 20 -z us-east-1a

그러면 us-east-1a 영역에 20GB 볼륨이 작성된다. 서버의 위치를 모르는 경우에는 ec2-describe-instances 명령을 실행하여 서버의 위치를 알 수 있다. ec2-run-instance에 동일한 -z 매개변수를 사용하여 서버의 실행 위치를 지정할 수 있다. Listing 1에서는 이 명령과 해당 출력을 보여 준다.

	
$ ec2-create-volume -s 20 -z us-east-1a
VOLUME  vol-c8791ca1    20              us-east-1a      creating     
2010-07-01T02:52:52+0000

Listing 1의 출력을 보면 볼륨이 작성 중이고 볼륨 ID가 vol-c8791ca1이라는 것을 알 수 있다. 서버의 인스턴스 ID와 서버에서 볼륨으로 인식할 장치를 알고 있으면 이 정보를 사용하여 볼륨을 실행 중인 Amazon EC2 인스턴스에 연결할 수 있다. 다음 명령을 실행한다.

ec2-attach-volume vol-c8701ca1 -i i-fd15e097 -d /dev/sdj

그러면 새로 작성된 이 볼륨이 서비스 인스턴스 i-fd15e097에 연결된다. 인스턴스 ID는 ec2-describe-instances 명령을 통해 확인할 수 있으며 볼륨 목록은 ec2-describe-volumes를 사용하여 확인할 수 있다.

이제 가상 서버에 일반적인 하드 디스크처럼 보이는 /dev/sdj라는 디스크가 표시된다. 디스크를 사용하려면 먼저 원시 디스크에 파일 시스템을 작성해야 한다. 필요에 따라 다음과 같은 여러 방법을 사용할 수 있다.

• 표준 ext3(third extended) 파일 시스템을 작성한다.
• XFS 파일 시스템을 작성한다. 이렇게 하면 파일 시스템을 고정한 상태에서 백업 목적의 스냅샷을 작성할 수 있다.
• 디스크와 파일 시스템 사이에 LVM(Logical Volume Manager)을 배치한다. 이렇게 하면 EBS 볼륨을 나중에 확장할 수 있다.
• Linux® 소프트웨어 RAID를 사용하여 여러 EBS 볼륨을 스트라이프하고 RAID 세트 위에 XFS 또는 ext3를 배치한다. 이렇게 하면 디스크 성능이 향상된다.

RAID와 LVM의 기능이 흥미롭기는 하지만 비교적 작은 EBS 볼륨일 경우에는 XFS가 가장 쉬운 옵션이다. XFS의 고정 기능과 EBS 스냅샷을 함께 사용하여 일관된 백업을 작성할 수 있다. Listing 2에서는 XFS 파일 시스템을 작성하고 호스트에 마운트하는 방법을 보여 준다.

	
# mkfs.xfs /dev/sdj
meta-data=/dev/sdj               isize=256    agcount=8, agsize=32768 blks
         =                       sectsz=512   attr=0
data     =                       bsize=4096   blocks=262144, imaxpct=25
         =                       sunit=0      swidth=0 blks, unwritten=1
naming   =version 2              bsize=4096
log      =internal log           bsize=4096   blocks=2560, version=1
         =                       sectsz=512   sunit=0 blks, lazy-count=0
realtime =none                   extsz=4096   blocks=0, rtextents=0
# mkdir /ebsvol
# mount /dev/sdj /ebsvol

Listing 2에서는 mkfs.xfs 명령을 실행하여 /dev/sdj를 포맷한다. (mkfs.xfs 명령이 없으면 gem install -y xfsprogs를 실행한다.) 이 명령의 출력은 파일 시스템의 매개변수를 설명한다. 출력에 오류가 없으면 무시할 수 있다. Listing 2의 마지막 두 명령은 /ebsvol이라는 마운트 지점을 작성한 다음 파일 시스템을 마운트 지점에 마운트한다.

이제 파일 시스템을 사용할 수 있다. /ebsvol에 있는 모든 파일은 서버가 종료되도 유지된다.

EBS 볼륨 사용하기

이제 EBS 볼륨이 /ebsvol에 마운트되어 있으며 PostgreSQL 데이터를 이동해야 한다. 이 작업을 가장 간단하게 수행하는 방법은 기존 데이터 저장소를 복사한 후 symlink를 사용하여 수정하는 것이다. 이 방법을 사용할 수도 있겠지만 EBS 볼륨의 데이터를 /var/lib/pgsql로 복제하는 것이 가장 확실한 방법이다. Listing 3에서 이 절차를 보여 준다.

	
# service postgresql stop
# mv /var/lib/pgsql /ebsvol
# mkdir /var/lib/pgsql
# chown postgres:postgres /var/lib/pgsql
# mount /ebsvol/pgsql /var/lib/pgsql -o bind
# service postgresql start

Listing 3의 명령 시퀀스는 다음과 같다.

1. 데이터 일관성을 보장하기 위해 PostgreSQL 디먼을 중지한다.
2. 전체 디렉토리 트리를 EBS 저장소로 이동한다.
3. PostgreSQL 디렉토리를 다시 작성한다.
4. PostgreSQL 디렉토리의 소유권을 다시 설정한다.
5. mount의 bind 옵션을 사용하여 /ebsvol/pgsql을 /var/lib/pgsql에 마운트한다.
6. 데이터베이스를 다시 시작한다.

mount의 bind 옵션은 첫 번째 디렉토리를 두 번째 디렉토리에 복제한다. 한 디렉토리의 변경 사항이 다른 디렉토리에도 표시된다. 결국, 두 디렉토리는 동일한 디스크에 있는 동일한 블록이다. bind를 사용하는 것은 전체 파일 시스템 대신 서브디렉토리를 마운트할 수 있다는 점에서 동일한 장치를 두 번 마운트하는 것과 다르다.

충돌로부터 복구하기

서버에서 충돌이 발생한 경우 다음 단계를 수행한다.

1. 사용자의 AMI를 사용하여 새 인스턴스를 시작한다.
2. ec2-attach-volume을 사용하여 EBS 볼륨을 인스턴스에 연결한다.
3. EBS 장치를 /ebsvol에 마운트한다.
4. Listing 3의 마지막 네 개의 명령을 수행한다.

AMI를 최근에 번들링했다면 데이터베이스 시스템도 최신 상태이다.

위로

애플리케이션 서버 작업하기

클라우드 컴퓨터의 장점 중 하나는 서버 용량에 쉽게 액세스할 수 있다는 것이다. 현재 SmallPayroll.ca 환경에서는 데이터베이스 및 애플리케이션 서버가 동일한 가상 인스턴스에 있다. 이는 Amazon EC2로 마이그레이션하기 전과 같다. 다음으로 수행할 단계는 애플리케이션 서버와 데이터베이스 서버를 분리하는 것이다.

확장 및 로드 밸런싱

확장이라는 용어는 일반적으로 용량과 관련된다. 애플리케이션을 확장할 수 있다는 말은 애플리케이션을 확장하여 더 많은 사용자 로드를 처리할 수 있다는 것을 의미한다. 서버를 추가하여 확장하는 경우를 수평적 확장이라고 하며, 서버를 더 큰 서버로 교체하여 로드를 처리하는 경우를 수직적 확장이라고 한다.

수평적 및 수직적 확장은 서로 결합하여 사용할 수 있다. 더 큰 서버와 빠른 디스크를 사용하여 데이터베이스 용량 문제점을 해결하고 여러 서버에 계산 로드를 분산시키는 것이 더 쉬울 것이다. 수평적 또는 수직적 확장의 가능성은 주로 애플리케이션 설계에 달려 있다. 여러 컴퓨터에 분산시킬 수 없는 애플리케이션도 있었으며, 컴퓨터의 속도와 상관 없이 일정 수준의 시간이 소요되는 작업도 있다. 또한 일부 애플리케이션의 경우에는 병목 현상으로 인해 서버 추가의 장점을 얻을 수 없는 수준까지 수평적으로 확장할 수 있다.

애플리케이션을 여러 서버에 분산시킬 경우 수신 요청을 분배하는 방법과 관련된 문제가 발생한다. 이 작업을 수행하는 데 주로 사용되는 장치가 로드 밸런서이다. 이 장치는 외부에서 들어오는 요청을 받아서 사용 가능한 다음 애플리케이션 서버로 전달하는 역할을 수행한다. 이 작업은 집약적인 태스크가 아니기 때문에 단일 장치가 많은 수의 연결을 처리할 수 있으며, 소프트웨어로도 이 기능을 처리할 수 있다.

Amazon EC2에서는 대부분의 용도에 적합한 Elastic Load Balancing이라는 클라우드 로드 밸런서를 제공한다. 이 밸런서는 요청을 분배하고, API를 통해 서버를 추가 또는 제거하도록 재구성할 수 있으며, 백엔드 서버에 대한 상태 검사를 수행한다.

Elastic Load Balancing을 사용하는 대신 Amazon EC2 인스턴스에서 HAProxy 또는 Varnish(자세한 정보는 참고자료의 링크 참조)와 같은 사용자의 로드 밸런싱 소프트웨어를 실행할 수도 있다. 이 프로세스는 Elastic Load Balancing을 사용할 때보다 복잡하지만 사용자의 트래픽에 대해 높은 수준의 제어가 가능하다. Elastic Load Balancing은 SmallPayroll.ca와 같은 애플리케이션에 더 적합하다.

그림 2에서는 SmallPayroll.ca 애플리케이션의 새 설계를 보여 준다.

수신 요청은 Elastic Load Balancing을 거쳐서 두 서버 중 하나로 전송된다. 서버 자체에서는 nginx를 실행하여 정적 요청을 처리하고 동적 요청을 mongrel 인스턴스로 프록시한다. mongrel은 단일 데이터베이스 서버에 연결되어 있다.

애플리케이션 서버 중 하나가 작동하지 않으면 Elastic Load Balancing이 모든 트래픽을 다른 서버로 리디렉션한다.

새 인스턴스 실행하기

별도의 애플리케이션 서버를 빌드하려면 두 개 이상의 인스턴스를 실행해야 한다. 이 경우에는 앞에서 사용한 AMI를 사용할 수 있다. 왜냐하면 이 AMI에 필요한 모든 데이터가 포함되어 있기 때문이다. 동시에 두 개 이상의 인스턴스를 실행할 수 있다. Listing 4에서는 하나의 명령으로 두 개의 인스턴스를 실행하는 방법을 보여 준다.

	
$ ec2-run-instances ami-147f977d -k main -z us-east-1a \
-d 'role=web,db=10.201.207.180' -n 2
RESERVATION     r-9cc240f7      223410055806    default
INSTANCE        i-81ee2eeb      ami-147f977d    pending main ...
INSTANCE        i-87ee2eed      ami-147f977d    pending main ...

ec2-run-instances 명령은 과거에 사용했던 명령과 유사하다. 데이터베이스 서버가 같은 지역에 있기 때문에 가용성 영역이 -z us-east-1a로 선택된다. 이 경우 지연 시간과 대역폭 비용을 줄이기 위해 데이터베이스 서버와 애플리케이션 서버를 같은 가용성 영역에 둘 수 있다.

하지만 -d 및 -n 매개변수는 새로운 매개변수이다. -n 2 매개변수는 두 개의 인스턴스를 실행하도록 Amazon에 지시하며, 출력을 통해 결과를 확인할 수 있다. -d 매개변수는 인스턴스에 정보를 전달하는 데 사용된다. Listing 5에서는 새 인스턴스에서 이 정보를 검색하는 방법을 보여 준다.

	
[root@domU-12-31-39-0C-C5-B2 ~]# DATA=`curl -s http://169.254.169.254/latest/user-data`
[root@domU-12-31-39-0C-C5-B2 ~]# echo $DATA
role=web,db=10.201.207.180

curl 명령은 Amazon EC2 서비스에서 사용자 데이터가 포함된 웹 페이지를 검색한다. 이 방법은 이 시리즈의 이전 기사에서 서버의 SSH(Secure Shell) 키를 검색했던 방법과 비슷하다.

애플리케이션 서버 구성하기

복제된 AMI에 로컬 데이터베이스에 대해 애플리케이션을 실행할 수 있는 기능이 이미 갖추어져 있기 때문에 애플리케이션 서버에서 수행할 작업은 많지 않다. Rails 애플리케이션은 애플리케이션에게 사용할 데이터베이스를 알려 주는 config/database.yml에서 데이터베이스 구성을 읽어온다. 기본적으로 애플리케이션은 localhost에 연결한다.

먼저 /etc/hosts에 항목을 추가하여 DNS 별명을 작성한다. 예를 들어, 10.201.207.180 dbserver는 dbserver라는 이름을 IP 주소인 10.201.207.180의 별명으로 설정한다. 여기에서 중요한 점은 사용자가 연결한 공용 주소 대신 eth0에 지정된 개인용 주소를 데이터베이스의 주소로 사용해야 한다는 것이다. 동일한 영역 내에서 Amazon EC2 인스턴스의 개인용 주소 간 트래픽은 무료이지만 Amazon EC2 인스턴스와 다른 인스턴스의 공용 주소 간의 트래픽에는 비용이 부과된다.

다음으로 애플리케이션을 가리키는 database.yml 파일을 앞에서 작성한 DNS 별명에 추가한다. 그러한 구성을 Listing 6에서 보여 준다.

	
production:
  adapter: postgresql
  encoding: utf8
  database: payroll_prod
  pool: 5
  username: payroll
  password:  secret
  host: dbserver

Rails 애플리케이션을 실행하고 애플리케이션 서버의 공용 IP 주소를 통해 이 애플리케이션에 연결할 수 있어야 한다. 오류가 발생할 경우에는 다음을 확인한다.

• PostgreSQL이 모든 인터페이스에서 청취하고 있는가? postgresql.conf 파일에 listen_addresses="*"와 같은 행이 있어야 한다.
• pg_hba.conf 파일에서 MD5 인증을 이용한 10/8 주소 연결을 허용하는가?
• 사용자의 Amazon 보안 그룹에서 데이터베이스 서버에 대한 연결을 허용하는가?

로드 밸런서 작성하기

Elastic Load Balancing은 상당히 단순한 로드 밸런서이다. 이 로드 밸런서는 수신된 요청을 풀에 있는 사용 가능한 서버로 전달한다. Elastic Load Balancing에서는 작동하지 않는 서버에 요청을 전달하는 경우를 피하기 위해 웹 서버에 대한 기본적인 상태 검사를 수행할 수 있다. 또한 사용자를 동일한 백엔드 서버에 유지할 수 있도록 지원하는 기본적인 친화성 메커니즘을 가지고 있다. URL 기반의 리디렉션과 같은 고급 기능은 아직까지 지원되지 않는다.

Elastic Load Balancing은 다음 세 단계 프로세스를 통해 구성한다.

1. 로드 밸런싱 인스턴스를 작성한다.
2. 상태 검사를 정의한다.
3. Elastic Load Balancing 이름을 가리키도록 DNS를 구성한다.

Listing 7에서는 처음 두 단계를 보여 준다.

	
$ elb-create-lb smallpayroll-http \
	--listener "lb-port=80,instance-port=80,protocol=HTTP" \
	--availability-zones us-east-1a
DNS_NAME  DNS_NAME
DNS_NAME  smallpayroll-http-706414765.us-east-1.elb.amazonaws.com
$ elb-configure-healthcheck smallpayroll-http --target "HTTP:80/" \
     --interval 30 --timeout 3 --unhealthy-threshold 2 --healthy-threshold 2
HEALTH_CHECK  TARGET    INTERVAL  TIMEOUT  HEALTHY_THRESHOLD  UNHEALTHY_THRESHOLD
HEALTH_CHECK  HTTP:80/  30        3        2                  2

Listing 7에서는 두 가지 명령을 보여 준다. 첫 번째 명령인 elb-create-lb는 로드 밸런서를 작성한다. 첫 번째 매개변수는 사용자에게 고유한 로드 밸런서의 이름이다. --listener 매개변수는 공용 포트가 80이고, 인스턴스의 포트 80에 연결되며, 사용 중인 프로토콜이 HTTP임을 알려 준다. 이 명령의 출력은 DNS 이름이며, 이 경우에는 smallpayroll-http-706414765.us-east-1.elb.amazonaws.com이다. 대부분의 로드 밸런서와는 달리 연결할 공용 IP 주소가 제공되지 않는다. Amazon에서 고유한 IP 주소를 지정하며 사용자는 DNS 별명을 통해 연결한다.

두 번째 명령인 elb-configure-healthcheck는 먼저 로드 밸런서의 이름을 참조한 다음 루트 URL을 사용하여 포트 80의 HTTP 프로토콜을 통해 상태 검사를 수행할 것임을 지정한다. 또한 /status와 같은 별도의 제어기와 조치를 작성하여 검사를 처리할 수도 있지만 이 경우에는 루트 URL이 애플리케이션의 올바른 실행을 충분히 보장한다.

두 번째 행의 매개변수에서 지정하는 내용을 차례로 살펴보면 다음과 같다.

• --interval 30. 30초마다 테스트한다.
• --timeout 3. 테스트 실패 전까지 애플리케이션에서 응답을 기다려야 하는 시간이다.
• --unhealthy-threshold 2. 테스트가 두 번 연속 실패하면 해당 서버가 서비스를 제공하지 않는 것으로 표시된다.
• --healthy-threshold 2. 실패한 서버가 풀에 다시 포함되려면 두 번의 검사에 연속해서 성공해야 한다.

다음으로 수행할 단계는 인스턴스를 로드 밸런서에 연결하는 것이다(Listing 8 참조). 사용자 마음대로 인스턴스를 추가 및 제거할 수 있다.

	
$ elb-register-instances-with-lb smallpayroll-http --instances i-87f232ed,i-85f232ef
INSTANCE_ID  INSTANCE_ID
INSTANCE_ID  i-85f232ef
INSTANCE_ID  i-87f232ed
$ elb-describe-instance-health smallpayroll-http --headers
INSTANCE_ID  INSTANCE_ID  STATE      DESCRIPTION  REASON-CODE
INSTANCE_ID  i-85f232ef 	InService  N/A					N/A
INSTANCE_ID  i-87f232ed		InService  N/A					N/A

Listing 8에서는 먼저 두 개의 인스턴스를 smallpayroll-http 로드 밸런서에 추가한다. elb-describe-instance-health 명령을 실행하여 풀에 있는 각 서버의 상태를 확인한다. InService는 서비스가 로드 밸런서를 통해 수신되는 요청을 처리할 수 있다는 것을 의미한다.

마지막으로 로드 밸런서의 DNS 이름으로 이동한다. 두 서버에서 작동 중인 애플리케이션이 보여야 한다. 로드 밸런서가 애플리케이션의 실제 DNS 이름에 해당하는 작업을 수행하도록 하기 위해 애플리케이션의 DNS 레코드를 A 레코드에서 로드 밸런서의 DNS 이름을 가리키는 CNAME으로 변경한다. 일부 경고를 포함하여 DNS 요구사항에 대한 자세한 정보를 보려면 참고자료를 참조한다. DNS 방법이 번거롭기는 하지만 이 방법을 사용하면 Amazon EC2 인스턴스에 로드 밸런서를 빌드하여 예전보다 훨씬 더 많은 수의 요청을 처리할 수 있다. 서비스 중단이 없을 것이므로 DNS 변경이 언제라도 발생할 수 있다.

위로

데이터 백업하기

이제 애플리케이션이 두 노드에 설치되어 있고 30분 이내에 데이터베이스 서버를 처음부터 시작할 수 있다. 이러한 구성은 가용성에 많은 도움이 되지만 관리자가 실수로 중요 데이터를 삭제하거나 EBS 볼륨이 실패할 경우에는 도움이 되지 못한다. 다행스럽게도 이러한 문제점을 해결할 수 있는 솔루션이 있다.

데이터베이스 백업하기

EBS에는 볼륨 사본을 Amazon S3에 저장하는 스냅샷 기능이 있다. 정확히 말해서 EBS 스냅샷은 마지막 스냅샷 이후의 차이점을 저장한다. 데이터베이스는 문제를 복잡하게 만든다. 왜냐하면 데이터베이스는 일부 디스크 쓰기를 캐싱하는데 이로 인해 일관되지 않은 스냅샷이 작성될 수 있기 때문이다. 따라서 모든 내용이 디스크에 일관된 상태로 있는지 확인해야 한다(Listing 9 참조). 백업의 순서는 다음과 같다.

1. PostgreSQL에게 백업 모드로 전환하도록 지시한다.
2. 파일 시스템을 고정한다.
3. Amazon에 스냅샷을 요청한다.
4. 파일 시스템을 고정 해제한다.
5. PostgreSQL에게 백업 완료를 알린다.

이 절차는 1-2분 밖에 소요되지 않지만 Amazon에서는 백그라운드로 스냅샷을 Amazon S3에 스풀링한다. 하지만 3단계 이후에 적용된 변경 사항은 스냅샷에 반영되지 않는다.

	
#!/bin/sh
export EC2_HOME=/usr/local/
export JAVA_HOME=/usr
export EC2_CERT="/root/.ec2/cert.pem"
export EC2_PRIVATE_KEY="/root/.ec2/pk.pem"
echo "select pg_start_backup('snapshot')" | su - postgres -c psql
/usr/sbin/xfs_freeze -f /ebsvol/
/usr/local/bin/ec2-create-snapshot vol-93f77ffa --description "`date`"
/usr/sbin/xfs_freeze -u /ebsvol/
echo "select pg_stop_backup('snapshot')" | su - postgres -c psql

ec2-describe-snapshots 명령을 사용하여 스냅샷의 상태를 확인할 수 있다(Listing 10 참조).

	
$ ec2-describe-snapshots --headers
                SnapshotId      VolumeId        Status          StartTime
SNAPSHOT        snap-298cb741   vol-93f77ffa    completed       2010-06-29T02:50:55
SNAPSHOT        snap-a2b959c9   vol-93f77ffa    completed       2010-07-13T15:14:54

Listing 10에서는 두 개의 완성된 스냅샷과 해당 시간을 보여 준다.

cron에서 Listing 9를 실행하여 스냅샷 작성을 자동화해야 한다. 또한 ec2-delete-snapshot 명령을 사용하여 스냅샷 목록을 주기적으로 삭제해야 한다.

데이터베이스 복원하기

EBS 볼륨이 실패하거나 EBS의 기존 데이터를 복원해야 하는 경우에는 마지막 스냅샷을 사용해서 복원해야 한다. EBS 볼륨을 복원하는 절차는 새 볼륨을 작성하는 것과 거의 동일하다. Listing 11에서는 Listing 10의 마지막 스냅샷을 복원하는 방법을 보여 준다.

	
$ ec2-create-volume --snapshot snap-a2b959c9 -z us-east-1a -s 20
VOLUME  vol-d06b06b9    20      snap-a2b959c9   us-east-1a      creating

그런 다음 이 볼륨을 인스턴스에 마운트하여 데이터를 복원할 수 있다.

파일 백업 및 복원하기

서버의 파일을 손쉽게 백업하는 방법은 파일을 Amazon S3에 복사하거나 사용자의 AMI에 포함시키는 것이다. 두 번째 방법은 2진 및 소프트웨어 패키지에 적합한 반면 Amazon S3에 복사하는 방법은 사용자 데이터에 적합하다. S3Sync 도구는 사용하기 쉬운 rsync 형태의 유틸리티와 함께 몇 가지 명령행 Amazon S3 도구를 제공한다.

S3Sync 유틸리티를 다운로드한다(참고자료에서 링크를 볼 수 있다). Listing 12에서는 백업을 위한 버켓을 작성하는 방법과 파일을 Amazon S3에 업로드하는 방법을 보여 준다.

	
$ s3cmd.rb  createbucket smallpayroll-backup
$ s3cmd.rb listbuckets
ertw.com
smallpayroll-backup
$ s3sync.rb  -r /var/uploads smallpayroll-backup:`date +%Y-%m-%d`
$ s3cmd.rb list smallpayroll-backup:2010-07-12
--------------------
2010-07-12/uploads
2010-07-12/uploads/file1.txt

Listing 12에서는 먼저 smallpayroll-backup이라는 버켓을 작성한다. 다른 시간에 다른 백업을 같은 버켓에 안전하게 저장할 수 있으므로 이 단계는 한 번만 수행한다. 두 번째 명령은 버켓이 작성되었음을 확인한다. 방금 작성한 버켓과 AMI가 있는 ertw.com bucket 버켓을 볼 수 있다.

s3sync.rb 명령은 /var/uploads 디렉토리를 백업 버켓에 재귀적으로 복사하면서 모든 파일의 접두부에 현재 날짜를 추가한다. 마지막 명령은 버켓 내의 모든 파일을 보여 준다.

파일 복원은 매우 간단하다. 예약된 매개변수와 함께 S3Sync를 사용하거나 Amazon S3 File Manager(참고자료 참조)와 같은 또 다른 도구를 통해 개별 파일을 검색할 수 있다.

위로

결론

SmallPayroll 애플리케이션은 클라우드에서 실행되고 있으며 향후 확장을 고려하여 설계되었다. 하드웨어 오류 간의 평균 시간이 변경되지는 않았지만 백업 및 스크립트가 보강되었으므로 데이터를 안전하게 보호할 수 있고 필요한 경우 환경을 빠르게 다시 빌드할 수도 있다.

클라우드에 직접 마이그레이션하는 작업에서 발견되었던 대부분의 단점이 해결되었다. 하지만 현재는 환경의 상태에 대한 가시성이 없는 상태이며 더 나아가 수요에 따라 서버 자원을 확장할 수 있으면 더욱 좋을 것이다. 이러한 문제점은 이 시리즈의 다음 두 기사에서 해결한다.

참고자료

교육

• RightScale on EBS: RightScale 전문가가 EBS에 대한 자세한 설명과 함께 스냅샷 및 가용성 영역에 대한 자세한 정보를 제공한다.
  
  
• EBS performance: 여러 EBS 볼륨을 하나의 서버에 연결할 수 있다. MySQL 성능 블로그에서는 RAID를 사용한 EBS 성능 향상에 대한 훌륭한 비교 결과를 보여 준다. 이 결과는 다른 데이터베이스와도 관련된다.
  
  
• PostgreSQL online backups: 이러한 백업은 매우 유용하지만 일관성을 보장하기 위해 약간의 이해가 필요하다.
  
  
• Using Instance Data: Amazon EC2 인스턴스에는 인스턴스가 환경을 파악하는 데 도움이 되는 몇 가지 인스턴스 메타데이터가 있다. Amazon EC2 문서의 이 장을 살펴보면서 어떤 작업을 수행할 수 있을지 생각해보자.
  
  
• Introduction to Elastic Load Balancing: Elastic Load Balancing 서비스는 기존의 익숙한 방법과는 다르게 동작한다. 특히, DNS CNAME을 사용하여 애플리케이션에 Amazon 호스트 이름으로 사용할 별명을 지정해야 한다.
  
  
• ELB and CNAMEs to the root apex discussion: Elastic Load Balancing을 사용하여 도메인의 루트(예: example.com, 루트 아펙스라고도 함)에 대한 로드 밸런싱을 수행할 경우에는 Amazon Web Services 토론 포럼에 실린 이 토론을 통해 문제점과 해결 방법을 알아볼 수 있다.
  
  
• developerWorks의 Cloud Computing 영역에서 클라우드용 애플리케이션을 개발하고 배치하는 데 필요한 자원을 얻을 수 있으며 최신 클라우드 개발 정보도 확인할 수 있다.
  
  
• Linux에서는 수백 개의 기술자료 목록과 함께, Linux 개발자와 관리자를 위한 다양한 다운로드, 토론 포럼 및 다른 참고자료를 찾을 수 있다.
  
  
• developerWorks 기술 행사 및 웹 캐스트를 통해 다양한 IBM 제품 및 IT 산업 주제에 대한 최신 정보를 얻을 수 있다.
  
  
• 무료 developerWorks Live! briefing을 통해 최신 IBM 제품 및 도구에 대한 정보뿐만 아니라 IT 업계의 최신 경향까지도 빠르게 확인할 수 있다.
  
  
• developerWorks on-demand demos에서는 입문자를 위한 제품 설치 및 설정부터 숙련된 개발자를 위한 고급 기능까지 망라된 다양한 데모를 제공한다.
  
  
• Twitter의 developerWorks를 팔로우(follow)하거나 developerWorks에 대한 Linux 트윗(tweet)의 피드를 구독하자.
  
  

제품 및 기술 얻기

• HAProxy 및 Varnish: Elastic Load Balancing의 대안을 찾고 있다면 이러한 두 프로젝트를 찾아보기 바란다. HAProxy는 이벤트 지향적 역방향 프록시인 반면 Varnish는 스레드 모델을 사용하고 캐싱을 수행한다.
  
  
• Amazon S3 File Manager: 이제 Amazon S3 내에 여러 개의 AMI가 있으므로 오래된 AMI를 정리하고 싶을 것이다. Amazon S3 File Manager는 여러 독립형 애플리케이션 또는 브라우저 플러그인의 기능과 견줄만한 웹 기반 파일 관리자이다. AMI를 삭제한 경우에는 ec2-deregister를 실행하는 것도 잊지 말기 바란다.
  
  
• S3Sync: S3Sync는 파일을 Amazon S3에 복사하는 작업뿐만 아니라 버켓을 조작하는 작업에 유용한 도구이다.
  
  
• 자신에게 가장한 적합한 방법으로 IBM 제품을 평가해 보자. 시험판 제품을 다운로드하거나, 온라인으로 제품을 사용해 보거나, 클라우드 환경에서 제품을 사용하거나, SOA Sandbox에서 SOA(Service Oriented Architecture)를 효과적으로 구현하는 방법을 배울 수 있다.
  
  

토론

• developerWorks community에 참여한다. 개발자가 이끌고 있는 블로그, 포럼, 그룹 및 wiki를 살펴보면서 다른 developerWorks 사용자와 의견을 나눌 수 있다.
  
  

필자소개

Sean Walberg has been working with Linux and UNIX systems since 1994 in academic, corporate, and Internet service provider environments. He has written extensively about systems administration over the past several years. You can contact him at sean@ertw.com.

Sean Walberg は 1994年以来、学界、企業、およびインターネット・サービス・プロバイダー環境で Linux および UNIX システムに取り組んできました。この数年の間は、システム管理に関する広範な著作活動を行っています。

아티클 순위

의견

위로

목차

• 지속적 디스크 구성하기
• 애플리케이션 서버 작업하기
• 데이터 백업하기
• 결론
• 참고자료
• 필자소개
• 의견