developerWorks에 처음 로그인하면 developerWorks프로파일이 생성됩니다.귀하의 프로파일에서 동의하신 내용이 공개되지만 이 사항은 언제든지 변경 가능합니다. 귀하의 성명(숨김으로 체크되어 있어도 표시됩니다)과 디스플레이 이름은 게시한 컨텐츠나 사이트 엑세스시 표시됩니다.

모든 정보가 안전하게 전송되었습니다.

처음 developerWorks에 로그인할 때 프로파일이 작성되므로, 이를 위해 디스플레이 이름을 선택해야 합니다. 선택하신 디스플레이 이름은 developerWorks에 게시한 컨텐츠에 표시됩니다.

3글자 이상 31글자 이하의 길이로 사용 가능합니다. dW커뮤니티 내에서는 보안상 이메일주소를 제외한 다른 이름을 지정하셔야 합니다.

모든 정보가 안전하게 전송되었습니다.

My developerWorks：

나의 통지：

로그아웃

언어 선택：

Amazon 클라우드에 Linux 애플리케이션 마이그레이션하기, Part 1: 초기 마이그레이션

클라우드에 애플리케이션을 마이그레이션하는 방법

Sean A. Walberg, Senior Network Engineer

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.

요약： 클라우드 컴퓨팅과 IaaS(Infrastructure as a Service)에 대해서는 문서화가 잘 되어 있지만 애플리케이션을 클라우드 환경에서 실행하는 방법에 대해서는 다루고 있는 문서가 많지 않습니다. 이 시리즈에서는 애플리케이션을 클라우드로 이동하는 방법과 이 설정이 제공해야 하는 기능을 활용하는 방법에 대해 설명합니다. Part1에서는 실제 서버에서 클라우드 서버로 직접 마이그레이션하는 방법에 대해 살펴봅니다.

여기에 태그 달기!

원문 게재일: 2010 년 7 월 13 일
번역 게재일: 2010 년 11 월 02 일
난이도: 중급
영어로: 보기
PDF: A4 and Letter (79KB | 21 pages)Get Adobe® Reader®
페이지뷰： 4194 회
의견：

이 시리즈의 정보

이 기사 시리즈에서는 단일 실제 서버에 있는 웹 애플리케이션을 Amazon EC2(Amazon Elastic Compute Cloud)로 마이그레이션하는 과정을 설명한다. 또한 애플리케이션을 클라우드 환경에 적합하게 수정하는 방법과 클라우드에서 제공해야 하는 기능을 활용하는 방법에 대해서도 살펴본다.

IaaS(Infrastructure as a Service)는 컴퓨팅 자원을 사용하고 그에 따라 비용을 지불한다는 아주 좋은 개념이다. 더 많은 컴퓨팅 성능이 필요하면 비용을 더 지불하면 된다. 이 모델의 단점은 보지도 못하고 많이 알지도 못하는 컴퓨터를 사용해서 작업한다는 것이다. 하지만 이러한 단점을 극복하고 나면 IaaS를 통해 많은 것을 얻을 수 있다.

IaaS 모델은 서버를 구매하는 일반적인 모델과 매우 다르기 때문에 사용자의 가상 컴퓨터를 관리하는 방법이 바뀌게 된다. 사용자의 애플리케이션을 클라우드에서 실행하는 방법도 바뀐다. 협상 가능한 서버 간 지연 시간과 같이 지금까지 고려했던 사항을 전혀 고려하지 않아도 된다.

Amazon EC2 작업하기

Amazon EC2에서는 API(Application Programming Interface)를 통해 서버를 켜고 끌 수 있으며 사용 시간을 기준으로 서버 사용 비용을 신용 카드로 결제할 수 있다. 다양한 유형의 서버와(주된 관심사인 메모리, 디스크 또는 CPU 성능에 따라) 지속적 디스크부터 로드 밸런서에 이르는 추가 기능 스위트를 선택할 수 있다. 그리고 비용은 사용한 자원에 대해서만 지불한다.

Amazon EC2 오퍼링 외에도 무엇보다도 결제 처리, 데이터베이스 및 메시지 큐잉 등을 제공하는 다양한 서비스가 있다. 이 기사 시리즈에서는 사용량에 따라 비용을 지불하는 디스크 공간에 대한 액세스를 제공하는 Amazon S3(Amazon Simple Storage Service)를 사용한다.

위로

예제 애플리케이션

이 시리즈에서 예제로 사용하는 웹 애플리케이션은 Ruby on Rails 프레임워크와 PostgreSQL 백엔드를 사용하여 작성된 SmallPayroll.ca라는 급여 서비스이다. 일반적인 여러 웹 애플리케이션과 마찬가지로 이 애플리케이션에도 데이터베이스 계층과 애플리케이션 계층이 있고 CSS(Cascading Style Sheet) 및 JavaScript 파일과 같은 정적 파일 세트가 있다. 사용자는 다양한 양식을 이용하여 데이터를 입력 및 조작하고 보고서를 생성한다.

다음과 같은 다양한 컴포넌트가 사용된다.

Nginx. 정적 파일을 위한 프론트엔드 서버이며 중간 계층에 대한 밸런서이다.
Mongrel. 애플리케이션 서버이다.
Ruby. 애플리케이션을 작성하는 데 사용된 언어이다.
Gems. 데이터베이스 암호화부터 애플리케이션 레벨 모니터링에 이르는 모든 기능을 위한 써드파티 플러그인 및 라이브러리이다.
PostgreSQL. SQL(Structured Query Language) 데이터베이스 엔진이다.

사이트 사용량이 사이트가 있는 단일 서버의 용량을 초과했다면 지금이 바로 새 환경으로의 마이그레이션을 고려할 적절한 시기이며 이는 곧 클라우드로 이동할 수 있는 최상의 기회이기도 하다.

원하는 기능 향상

하지만 단순히 한 서버에서 소수의 클라우드 기반 서버로 이동하는 것은 클라우드에서 수행할 수 있는 기능을 충분히 활용하는 것이 아니며 흥미로운 읽을거리가 되지도 못한다. 따라서 이동하는 동안 다음과 같은 기능 향상 작업을 수행할 것이며, 이러한 기능 중 일부는 클라우드 환경에서만 가능하다.

신뢰성 향상. 클라우드에서 실행할 서버의 크기를 선택할 수 있으므로 여러 개의 작은 서버를 실행하여 중복성을 강화할 수 있다.
확장 및 축소가 가능한 용량. 서비스의 성장에 따라 서버가 점진적으로 풀에 추가된다. 하지만 서버 수를 단기적인 트래픽 폭증에 대비하기 위해 늘리거나 정기적으로 트래픽이 적은 기간 동안 줄일 수도 있다.
클라우드 스토리지. 애플리케이션 데이터를 Amazon S3에 백업할 수 있으며, 이렇게 하면 테이프 스토리지를 사용하지 않아도 된다.
자동화. 서버, 스토리지 및 로드 밸런서를 포함한 Amazon 환경의 모든 것을 자동화할 수 있다. 애플리케이션 관리 시간이 줄어든다는 것은 다른 생산적인 작업에 더 많은 시간을 투자할 수 있다는 것을 의미한다.

이 기사 시리즈에서는 이러한 기능 향상 작업을 점진적으로 수행한다.

위로

테스트 및 마이그레이션 전략

애플리케이션을 처음 배치할 때는 일반적으로 프로덕션 트래픽에 대한 부담 없이 편안하게 테스트하고 수정할 수 있다. 이에 반해 애플리케이션을 마이그레이션할 경우에는 사이트에 로드를 발생시키는 사용자를 고려해야 한다. 새 환경에서 프로덕션 트래픽이 발생하게 되면 사용자는 모든 것이 올바르게 작동하는 것으로 간주한다.

마이그레이션으로 인한 중단 시간이 반드시 0일 필요는 없다. 임시로 서비스를 오프라인 상태로 유지할 수 있다면 작업이 훨씬 더 쉬워진다. 이 중단 시간을 사용하여 최종 데이터 동기화를 수행하고 네트워크 변경 사항을 안정화시킬 수 있다. 새 환경에 처음 배치할 경우에는 이러한 시간을 사용해서는 안 된다. 왜냐하면 새 환경은 애플리케이션 마이그레이션이 시작하기 전에 작동 상태에 있어야 하기 때문이다. 이 점을 염두에 둔 상태에서 핵심 사항은 환경과 네트워크 변경 사항 사이의 데이터 동기화이다.

마이그레이션 전략을 계획할 때는 먼저 현재 환경을 살펴보는 것이 좋다. 다음 질문에 응답해 보자.

애플리케이션을 실행하기 위해 서버에서 사용하는 소프트웨어는 무엇인가?
애플리케이션 및 서버 자원을 관리 및 모니터링하기 위해 서버에서 사용하는 소프트웨어는 무엇인가?
모든 사용자 데이터는 어디에 저장되어 있는가? 데이터베이스? 파일?
이미지, CSS 및 JavaScript 파일과 같은 정적 자원은 어디에 저장되어 있는가?
애플리케이션에 필요한 다른 시스템과의 접점은 무엇인가?
최근에 모든 데이터를 백업했는가?

사용자에게 알리기

중단 시간이 예정되어 있지 않더라도 일반적으로 사용자에게 알리는 것이 좋다. SmallPayroll.ca 애플리케이션의 경우에는 사용자가 2주 결제 주기에 따라 일정한 간격으로 사이트를 사용하는 경향이 있기 때문에 2주 단위 알림이 합리적인 기간이다. Google 광고 플랫폼의 관리 인터페이스인 Google AdWords와 같은 사이트에서는 1주 단위로 알림을 제공한다. 1시간 동안 중단되더라도 사용자의 불만이 크지 않는 뉴스 사이트라면 중단 당일에 알림을 제공할 수도 있다.

또한 알림의 양식은 사이트의 특성과 사용자와 현재 통신하는 방법에 따라 다양하다. SmallPayroll.ca의 경우에는 사용자가 로그인할 때 눈에 띄는 메시지를 표시하는 것만으로도 충분하다. 예를 들어, "2010년 6월 24일 오전 12시 01분부터 오전 1시까지(동부 표준시 기준) 시스템을 사용할 수 없습니다. 이 시각 이전에 입력한 모든 내용은 저장됩니다. 자세한 정보를 보려면 여기를 클릭하십시오."라는 메시지를 표시할 수 있다. 이 메시지는 사용자가 알아야 하는 다음과 같은 세 가지 핵심 정보를 제공한다.

중단이 발생하는 시간(시간대 포함)
데이터가 안전하게 저장될 것임을 알리는 보장
추가 정보에 대한 링크

오전 12시, 오후 12시 또는 자정과 같은 용어는 사용하지 않는 것이 좋다. 많은 사람들이 6월 17일 자정이 이른 아침(오전 12시 1분)인지 아니면 매우 늦은 저녁(오후 11시 59분)인지를 확신하지 못하기 때문에 이러한 용어를 사용하면 혼동할 수 있다. 마찬가지로 정오가 오전 12시인지 오후 12시인지 혼동하는 사람이 많으므로 분을 추가하여 명확한 시간을 알려 주는 것이 훨씬 쉽다.

세부 사항은 다양할 수 있으며 특히, 중단 시간 동안 부분 작동이 예상되는 경우에 더욱 그러하다. 뉴스 사이트처럼 중단 시간 동안에만 알림을 제공하기로 결정한 경우에는 동일한 정보가 도움이 될 것이다. 필자가 자주 사용하는 사이트 중단 화면에는 "유지보수를 위해 사이트가 중단되었으며 오후 3시경에(EST) 다시 시작됩니다. 기다리는 동안 Asteroids 게임을 즐기십시오."라는 메시지가 표시된다.

내부 사용자도 무시해서는 안 된다. 계정 담당자가 있을 경우 클라이언트가 문의할 때 알려 줄 수 있다.

DNS 고려사항

DNS(Domain Name System)는 www.example.com과 같은 이름을 192.0.32.10과 같은 IP 주소로 변환한다. 컴퓨터는 IP 주소에 연결하므로 이 변환이 중요하다. 한 환경에서 다른 환경으로 마이그레이션할 경우 두 환경이 같은 건물에 있지 않는 한 대부분의 경우 다른 IP 주소를 사용해야 한다.

컴퓨터에서는 전체 응답 시간을 줄이기 위해 TTL(Time To Live)이라는 일정 기간 동안 이름-IP 맵핑을 캐싱한다. 한 환경에서 다른 환경으로 전환하게 되면서 IP 주소가 변경될 경우 캐싱된 DNS 항목을 가진 사용자는 계속해서 기존 환경을 사용하려고 시도한다. 애플리케이션의 DNS 항목 및 연관된 TTL은 주의 깊게 관리해야 한다.

TTL은 일반적으로 1시간부터 1일 사이이다. 마이그레이션을 준비할 경우에는 TTL을 5분 정도의 짧은 시간으로 설정해야 한다. 컴퓨터는 이름-IP 맵핑과 함께 TTL을 가져오므로 주소를 변경하려고 예정한 시간보다 적어도 한 번의 TTL 기간 전에 이 변경 작업을 수행해야 한다. 예를 들어, www.example.com의 TTL이 86,400초(1일)라면 적어도 마이그레이션 1일 전에 TTL을 5분으로 다시 설정해야 한다.

기존 환경과 새 환경 분리하기

마이그레이션 전에 새 환경을 완벽하게 테스트해야 한다. 모든 테스트는 프로덕션 환경과 분리된 상태에서 수행되어야 하며 새 환경을 충분히 테스트하기 위해 주로 프로덕션 데이터의 스냅샷을 이용한다.

프로덕션 데이터의 스냅샷을 이용하여 전체 테스트를 수행하는 데는 두 가지 목적이 있다. 첫 번째 목적은 실제 데이터를 사용하면 오류를 더 쉽게 찾아낼 수 있기 때문이다. 왜냐하면 실제 데이터가 개발 중에 사용된 테스트 데이터보다 더 예측할 수 없기 때문이다. 실제 데이터는 사용자가 실수로 복사하지 않은 파일이나 마무리 중에 잊어버린 특정 구성이 필요한 파일을 참조할 수 있다.

두 번째 이유는 프로덕션 데이터를 사용하면 데이터를 로드하는 동시에 마이그레이션을 실습할 수 있기 때문이다. 실제로 환경을 전환하는 것만 제외하면 마이그레이션 계획의 대부분을 검증할 수 있다.

새 환경을 프로덕션 환경인 것처럼 모의 환경으로 만들 수는 있지만 하나의 환경만 애플리케이션의 호스트 이름에 연관시킬 수 있다. 이 요구사항을 가장 쉽게 해결하는 방법은 hosts 파일에서 DNS 대체 항목을 작성하는 것이다. UNIX®의 경우에는 /etc/hosts에 이 파일이 있으며, Windows®의 경우에는 C:\windows\system32\drivers\etc\hosts에 있다. 기존 행의 형식에 따라 애플리케이션의 호스트 이름을 미래의 IP 주소로 가리키는 항목을 추가한다. 한 가지 명심할 점은 이동할 이미지 서버를 비롯한 모든 항목에 대해서도 동일한 작업을 수행해야 한다는 것이다. 아마도 브라우저를 다시 시작해야 하겠지만 그 이후에는 프로덕션 URL을 입력하여 새 환경에 액세스할 수 있다.

위로

Amazon EC2 기초

Amazon EC2 서비스를 사용하면 VM(Virtual Machine)에 대한 비용을 시간 단위로 지불할 수 있다. Amazon에서는 여러 다양한 유형의 시스템을 제공하며 이러한 시스템은 CPU, 메모리 및 디스크 프로파일에 따라 분류된다. Amazon에서는 메모리 및 디스크 사용량을 기가바이트 단위로 측정하며 CPU 사용량을 Amazon ECU(EC2 Compute Units)로 측정한다. 여기서, 1ECU는 대략 1.0 - 1.2GHz 수준의 AMD Opteron 또는 Intel® Xeon® 프로세서이다(2007년 기준). 예를 들어, 표준 소형 인스턴스는 1.7GB의 메모리, 160GB의 디스크 공간 및 1ECU의 CPU를 제공한다. 이 기사를 집필하던 당시 가장 큰 시스템은 68.4GB의 메모리, 1.7TB의 디스크 공간 및 8개의 가상 코어에 분산된 26개의 ECU를 제공하는 High-memory Quadruple Extra Large이다. 가격 범위는 최소형의 경우 시간당 8.5센트이고 최대형의 경우 시간당 2.40달러이다.

Amazon EC2 인스턴스는 VM을 빌드하는 데 사용되는 템플리트인 AMI(Amazon Machine Image)로 시작된다. Amazon에서는 일부 AMI를 게시하고 있으며 사용자가 고유한 AMI를 빌드하여 다른 사용자와 공유할 수도 있다. 이러한 사용자 작성 AMI 중 일부는 무료로 사용할 수 있으며, 일부는 Amazon의 시간당 비용과는 별도로 시간당 비용이 발생할 수 있다. 예를 들어, IBM에서는 시간 단위로 라이센스 비용을 지불하는 여러 개의 유료 AMI를 게시하고 있다.

VM을 부팅하려면 먼저 시스템 유형과 AMI를 선택해야 한다. AMI는 Amazon S3에 저장되어 있으며 사용자가 인스턴스를 시작할 때 VM의 루트 파티션으로 복사된다. 루트 파티션은 항상 10GB이다. 시스템 유형과 연관된 스토리지 공간은 인스턴스 스토리지나 임시 스토리지라고 하며 사용자의 VM에 별도의 드라이브로 제공된다. 임시 스토리지라고 하는 이유는 사용자가 인스턴스를 종료할 때 정보도 영원히 삭제되기 때문이다. 따라서 데이터 손실을 방지하려면 데이터를 주기적으로 백업해야 한다. 이는 또한 인스턴스를 실행하는 실제 호스트에서 충돌이 발생하여 인스턴스가 종료될 경우에도 임시 디스크가 없어진다는 것을 의미한다.

AMI(Amazon Machine Image)

모든 AMI에는 Amazon에서 지정한 ID(예: ami-0bbd5462)가 있다. Amazon에서 일부 공용 AMI를 제공하며 있으며 사용자가 자신의 AMI를 공용으로 설정한 경우도 있다. 처음에 공용 AMI를 선택한 다음 원하는 수정 사항을 적용하거나 처음부터 직접 시작할 수도 있다. AMI의 루트 파일 시스템을 변경할 때마다 루트 파일 시스템을 새 AMI로 저장할 수 있으며, 이를 리번들링이라고 한다.

이 시리즈에서는 다른 이미지를 선택할 수도 있지만 공개적으로 사용할 수 있는 CentOS 이미지를 사용하여 시작한다. 약간의 시간을 투자해서 사용할 이미지를 살펴보면서 추가 계정이 없고 패키지가 업데이트되었는지 확인할 수 있다면 더욱 좋을 것이다. 또한 처음부터 고유한 AMI를 작성할 수도 있겠지만 이 작업은 이 기사의 범위를 벗어난 내용이다.

Amazon API

Amazon EC2 클라우드를 시작, 중지 및 사용하는 데 필요한 모든 기능은 웹 서비스를 통해 사용할 수 있다. Amazon에서는 웹 서비스에 대한 스펙을 게시하고 있으며 명령행 도구 세트도 제공한다. 계속 진행하기 전에 이러한 도구를 다운로드해야 한다(참고자료 참조). 또한 빠른 시작 안내서(참고자료 참조)를 보고 환경을 설정하면 많은 입력 작업을 줄일 수 있다.

보안 신임 정보를 사용하여 API에 인증한다. 이러한 신임 정보는 AWS(Amazon Web Services) Management Console(참고자료 참조) 내의 Account 링크에 있다. 사용자의 X.509 인증서 파일과 액세스 키가 필요하며, 이 파일과 액세스 키는 안전하게 보관해야 한다. 이 파일과 액세스 키만 있으면 누구라도 AWS 자원을 사용할 수 있으며, 이 경우 사용자에게 비용이 부과된다.

첫 번째 인스턴스를 시작하기 전에

첫 번째 인스턴스를 시작하기 전에 새 인스턴스에 인증하기 위해 SSH(Secure Shell) 키를 생성한 다음 인스턴스를 보호하기 위해 가상 방화벽을 설정해야 한다. Listing 1에서는 ec2-add-keypair 명령을 사용하여 SSH 키 쌍을 생성하는 방법을 보여 준다.

Listing 1. SSH 키 쌍 생성하기

	
[sean@sergeant:~]$ ec2-add-keypair main
KEYPAIR main    40:88:59:b1:c5:bc:05:a1:5e:7c:61:23:5f:bc:dd:fe:75:f0:48:01
-----BEGIN RSA PRIVATE KEY-----
MIIEpAIBAAKCAQEAu8cTsq84bHLVhDG3n/fe9FGz0fs0j/FwZiDDovwfpxA/lijaedg6lA7KBzvn
...
-----END RSA PRIVATE KEY-----
[sean@sergeant:~]$ ec2-describe-keypairs
KEYPAIR main    40:88:59:b1:c5:bc:05:a1:5e:7c:61:23:5f:bc:dd:fe:75:f0:48:01

첫 번째 명령은 Amazon에게 main이라는 이름의 키 쌍을 생성하도록 지시한다. 결과의 첫 번째 행에 이 키의 해시 값이 표시된다. 출력의 나머지 부분은 암호화되지 않은 PEM 개인용 키이다. 이 키를 예를 들어, ~/.ssh/main.pem와 같은 위치에 저장해 두어야 한다. Amazon에서는 키의 공용 부분을 보유하며, 이 공용 부분은 사용자가 실행하는 VM에 사용할 수 있다.

두 번째 명령인 ec2-describe-keypairs는 Amazon에 현재 키 쌍 목록을 요청한다. 명령의 결과로 키 쌍의 이름과 해시가 차례로 표시된다.

각 인스턴스는 초기에 아무 것도 허용하지 않는 가상 방화벽에 의해 보호된다. Amazon EC2에서는 이러한 인스턴스를 보안 그룹이라고 하며, 보안 그룹을 조작하는 데 사용할 수 있는 API 호출 및 명령을 제공한다. 앞으로 적절한 시점에 이에 대해 자세히 살펴볼 것이다. 한편 Listing 2에서는 현재 그룹을 보는 방법을 보여 준다.

Listing 2. 현재 보안 그룹 표시하기

	
[sean@sergeant:~]$ ec2-describe-group
GROUP   223110335193    default default group

Listing 2에서는 "default group"이라는 설명이 있는 default라는 그룹을 보여 준다. 이 그룹에 연관된 사용자 ID는 223110335193이다. 이 그룹에는 규칙이 없다. 규칙이 있을 경우에는 왼쪽 열의 GROUP 아래에 PERMISSION이라는 단어를 사용하여 설명된다.

위로

클라우드 환경 준비하기

가장 먼저 수행할 작업은 애플리케이션을 테스트할 클라우드 환경을 준비하는 것이다. 새 환경은 현재 프로덕션 환경을 모방한다.

먼저 ID가 ami-10b55379인 AMI를 실행한다. Listing 3에서는 실행 중인 AMI와 검사 상태를 보여 준다.

Listing 3. CentOS AMI 실행하기

	
[sean@sergeant:~]$ ec2-run-instances ami-10b55379 -k main
RESERVATION  r-750fff1e  223110335193  default
INSTANCE  i-75aaf41e  ami-10b55379  pending  main  0  m1.small
2010-05-15T02:02:57+0000 us-east-1a  aki-3038da59  ari-3238da5b  monitoring-disabled
instance-store  
[sean@sergeant:~]$ ec2-describe-instances i-75aaf41e
RESERVATION  r-750fff1e  223110335193  default
i-75aaf41e  ami-10b55379  pending  main  0  E3D48CEE  m1.small
2010-05-15T02:02:57+0000 us-east-1a  aki-3038da59  ari-3238da5b  monitoring-disabled
instance-store  
[sean@sergeant:~]$ ec2-describe-instances i-75aaf41e
RESERVATION  r-750fff1e  223110335193  default
INSTANCE  i-75aaf41e  ami-10b55379  ec2-184-73-43-141.compute-1.amazonaws.com
domU-12-31-39-00-64-71.compute-1.internal  running  main  0  E3D48CEE  m1.small
2010-05-15T02:02:57+0000  us-east-1a  aki-3038da59  ari-3238da5b  monitoring-disabled
184.73.43.141  10.254.107.127  instance-store

첫 번째 명령은 ami-10b55379 AMI를 사용하여 인스턴스를 실행하며 Listing 1에서 생성된 키 쌍을 사용하여 시스템에 인증할 것이라고 지정한다. 이 명령은 여러 정보를 제공하지만 그 중에서 가장 중요한 정보는 Amazon EC2 클라우드에 있는 시스템의 ID인 인스턴스 ID(i-750fff1e)이다. 두 번째 명령인 ec2-describe-instances 명령은 실행 중인 모든 인스턴스를 나열한다. Listing 3을 보면 명령행에서 인스턴스 ID가 전달된다. 이렇게 하면 해당 인스턴스에 대한 정보만 표시된다. 인스턴스의 상태는 pending으로 나열된다. 이는 인스턴스가 여전히 시작 중임을 의미한다. IBM AMI는 크기 때문에 일반적으로 시작하는 데 5-10분이 걸린다. 조금 뒤에 동일한 명령을 실행하면 상태가 running으로 표시되며 외부 IP 주소 184.73.43.141이 지정된 것을 볼 수 있다. 10으로 시작하는 내부 IP 주소는 Amazon EC2 클라우드 내에서 통신하는 데 유용하지만 지금은 적합하지 않다.

그런 다음 앞에서 생성한 키를 사용하여 SSH를 통해 서버에 연결한다. 하지만 먼저 SSH(22/TCP)를 허용해야 한다. Listing 4에서는 연결을 인증하고 새 서버에 로그인하는 방법을 보여 준다.

SSH 키 이해하기

SSH 키에 익숙하지 않은 개발자의 경우 SSH를 통해 비밀번호 대신 키를 사용하여 사용자를 인증할 수 있다는 것을 알고 있으면 많은 도움이 될 것이다. 공용 키와 개인용 키로 구성된 키 쌍을 생성한다. 개인용 키는 안전하게 보관하고 공용 키는 $HOME/.ssh 디렉토리에 있는 authorized_keys 파일에 업로드한다. SSH를 통해 서버에 연결하면 클라이언트가 이 키를 사용하여 인증하려고 시도한다. 인증이 성공하면 로그인된다.

키 쌍의 한 가지 특성은 두 키 중 한 키를 사용하여 암호화된 메시지는 나머지 다른 한 키를 사용해서만 암호 해독할 수 있다는 것이다. 서버에 연결할 때 서버는 authorized_keys 파일에 저장된 공용 키를 사용하여 메시지를 암호화할 수 있다. 사용자의 공용 키를 사용하여 메시지를 암호 해독할 수 있으면 서버는 사용자를 비밀번호 없이 로그인할 수 있는 권한이 있는 사용자로 인식한다.

이제 논리적으로 "authorized_keys 파일이 어떻게 Amazon에 저장된 공용 키로 채워졌는가?"라는 질문을 던질 수 있을 것이다. 각 Amazon EC2 인스턴스는 http://169.254.169.254에 있는 Amazon EC2의 웹 서버와 통신하여 인스턴스에 대한 메타데이터를 검색할 수 있다. 이러한 URL 중에는 이미지에 연관된 공용 키를 리턴하는 http://169.254.169.254/latest/meta-data/public-keys/0/openssh-key가 있다.

AMI는 시작할 때 공용 키를 검색하여 authorized_keys에 저장한다. 이 작업은 예제 AMI의 /etc/init.d/getssh에서 수행되며, rc.local에서처럼 쉽게 발생할 수 있다.

인스턴스 메타데이터는 이미지에 정보를 전달하는 데도 사용된다. 웹 서버나 백그라운드 작업 서버 역할을 수행하는 일반 AMI를 사용하면서 인스턴스에서 이미지를 시작할 때 사용자가 전달한 매개변수에 따라 시작할 서비스를 결정할 수 있다.

Listing 4. 인스턴스에 연결하기

	
[sean@sergeant:~]$ ec2-authorize default -p 22 -s $MYIP/32
...
[sean@sergeant:~]$ ssh -i ~/.ssh/main.pem root@184.73.43.141
The authenticity of host '184.73.43.141 (184.73.43.141)' can't be established.
RSA key fingerprint is af:c2:1e:93:3c:16:76:6b:c1:be:47:d5:81:82:89:80.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '184.73.43.141' (RSA) to the list of known hosts.
...

첫 번째 명령은 소스 IP 주소에서 포트 22(TCP가 기본 옵션임)를 사용하도록 허용한다. /32는 호스트만 허용되고 전체 네트워크는 허용되지 않는다는 의미이다. ssh 명령은 개인용 키를 사용하여 서버에 연결한다.

Ruby 설치하기

CentOS에는 구버전의 Ruby가 포함되어 있으므로 1.8.7 버전의 Ruby와 호환되는 고성능 Ruby 인터프리터인 REE(Ruby Enterprise Edition)가 설치된다. 고급스러운 이름에도 불구하고 이 소프트웨어는 오픈 소스이다. Listing 5에서는 REE를 설치하는 방법을 보여 준다.

Listing 5. REE 설치하기

	 
# rpm -e ruby ruby-libs
# yum -y install gcc-c++ zlib-devel openssl-devel readline-devel
...
Complete!
# wget http://rubyforge.org/frs/download.php/71096/ruby-enterprise-1.8.7-2010.02.tar.gz
...
# tar -xzf ruby-enterprise-1.8.7-2010.02.tar.gz
# ruby-enterprise-1.8.7-2010.02/installer -a /opt/ree

Listing 5의 처음 두 명령은 기본 Ruby 설치를 제거하고 C 컴파일러와 몇 가지 필요한 개발 패키지를 설치한다. wget은 최신 REE tarball을 다운로드하며, 이 tarball은 tar에 의해 압축 해제된다. 마지막으로 마지막 명령은 모든 기본값을 승인하고 결과를 /opt/ree에 저장하는 옵션을 사용하여 설치 프로그램을 실행한다. 사용자를 배려하는 설치 프로그램이기 때문에 일부 패키지가 없을 경우 사용자가 실행해야 하는 명령을 알려 준다. 따라서 설치가 진행되지 않을 경우에는 출력을 자세히 살펴보기 바란다.

Ruby를 설치한 후에는 export PATH="/opt/ree/bin:$PATH"를 사용하여 bin 디렉토리를 사용자의 경로에 추가한다. 이렇게 하면 시스템 전체의 /etc/bashrc 디렉토리나 사용자의 홈 디렉토리 내에 있는 .bashrc 디렉토리에 배치할 수 있다.

PostgreSQL 설치하기

PostgreSQL 서버는 CentOS 배포판의 일부이므로 yum 유틸리티를 사용하여 설치하기만 하면 된다. Listing 6에서는 PostgreSQL을 설치하고 부팅 시에 시작되는지 확인하는 방법을 보여 준다.

Listing 6. PostgreSQL 설치하기

	
# yum -y install postgresql-server postgresql-devel
...
Installed: postgresql-devel.i386 0:8.1.21-1.el5_5.1 
   postgresql-server.i386 0:8.1.21-1.el5_5.1
Dependency Installed: postgresql.i386 0:8.1.21-1.el5_5.1 
   postgresql-libs.i386 0:8.1.21-1.el5_5.1
Complete!
# chkconfig postgresql on

yum 명령은 저장소에 있는 패키지를 설치한다. Listing 7에서는 PostgreSQL 서버 컴포넌트와 개발 라이브러리를 설치한다. 이 작업을 수행하면 코어 데이터베이스 유틸리티와 필요한 기타 패키지가 자동으로 설치된다. 아직은 개발 패키지가 필요하지 않지만 Rails와 PostgreSQL을 통합할 때 postgresql-devel 내의 라이브러리가 필요하다.

기본적으로 데이터베이스는 루트 파일 시스템의 일부인 /var/lib/pgsql/data에 해당 파일을 저장한다. Listing 7과 같이 이 디렉토리를 /mnt에 있는 인스턴스 스토리지로 이동한다.

Listing 7. PostgreSQL 데이터 저장소를 /mnt로 이동하기

	 
# mv /var/lib/pgsql/data /mnt
# ln -s /mnt/data /var/lib/pgsql/data
# service postgresql start

Listing 7의 명령을 입력한 후에는 PostgreSQL이 /mnt를 사용하여 실행된다.

다음으로 payroll_prod 데이터베이스(다음 단계에서 작성함)에 대한 비밀번호 로그인을 설정해야 한다. 기본적으로 PostgreSQL은 비밀번호를 사용하지 않고 내부 ID 시스템을 사용한다. /var/lib/pgsql/data/pg_hba.conf의 맨 위에 간단히 다음 구문을 추가한다.

host    "payroll_prod" all  127.0.0.1/32   md5

이제 다음 명령을 실행한다.

su - postgres -c 'pg_ctl reload'

그러면 변경 사항이 적용된다. 이 구성에서 일반적인 PostgreSQL 로그인에는 비밀번호가 필요하지 않다. 따라서 reload 명령이 비밀번호를 요청하지 않는다. 하지만 급여 데이터베이스에 액세스하려면 비밀번호가 필요하다.

마지막 단계는 명령행에서 Rails 데이터베이스를 설정하는 것이다. su - postgres -c psql을 실행한 후 Listing 8의 명령을 실행한다.

Listing 8. 사용자 및 데이터베이스 작성하기

	
postgres=# create user payroll with password 'secret';
CREATE ROLE
postgres=# create database payroll_prod;
CREATE DATABASE
postgres=# grant all privileges on database payroll_prod to payroll;
GRANT

이제 데이터베이스가 작성되었다.

데이터 마이그레이션하기

테스트를 위해 테스트에 사용할 특정 시점의 프로덕션 환경에 대한 데이터베이스 덤프를 작성해야 한다. SmallPayroll 애플리케이션에서는 데이터베이스와 파일 시스템에 데이터를 저장한다. 데이터베이스는 PostgreSQL의 pg_dump 명령을 사용하여 덤프를 작성하며 파일 시스템 데이터는 rsync를 사용한다. 마이그레이션하려면 데이터베이스 덤프의 특성으로 인해 데이터베이스를 정리하고 다시 전송해야 하지만 파일 시스템 데이터는 rsync가 변경되지 않은 파일을 발견할 수 있기 때문에 새 파일과 변경된 파일만 전송하면 된다. 따라서 계획 중 테스트 부분을 수행하면 대부분의 데이터가 미리 준비되기 때문에 마이그레이션 시간을 단축할 수 있다.

데이터베이스를 가장 빠르게 복사하는 방법은 프로덕션 시스템에서 다음 명령을 실행하는 것이다.

pg_dump payroll_prod | gzip -c > /tmp/dbbackup.gz

그런 다음 dbbackup.gz를 클라우드 서버에 복사하고 다음 명령을 실행한다.

zcat dbbackup.gz | psql payroll_prod

이 명령은 단순히 한 서버의 압축된 데이터베이스 덤프를 작성한 다음 다른 서버에서 모든 트랜잭션을 다시 수행한다.

rsync는 매우 간단하다. 프로덕션 서버에서 다음 명령을 실행한다.

rsync -avz -e "ssh -i .ssh/main.pem" /var/uploads/ root@174.129.138.83:/var/uploads/

이 명령은 현재 프로덕션 서버의 /var/uploads에 있는 모든 컨텐츠를 새 서버로 복사한다. 이 명령을 다시 실행하면 변경된 파일만 복사되므로 나중에 동기화 시간을 절약할 수 있다.

데이터베이스를 복사하고 있으므로 Rails 마이그레이션을 먼저 적용하지 않아도 된다. 사용자가 schema_migrations 테이블을 복사했기 때문에 Rails에서는 데이터베이스를 최신 상태로 간주한다.

Rails 애플리케이션 배치하기

지금까지 기본 서버를 설정했지만 애플리케이션을 설정하지는 않았다. 이제 애플리케이션을 실행하기 전에 일부 기본 gem과 애플리케이션에 필요한 gem을 설치해야 한다. Listing 9에서는 gem을 업데이트하는 명령을 보여 준다. 이 경우 Rails 애플리케이션의 루트에 있어야 하며 서버로 먼저 복사해야 한다.

Listing 9. RubyGems 업데이트 및 사용자의 gem 설치하기

	
# gem update --system
Updating RubyGems
Nothing to update
# gem install rails mongrel mongrel-cluster postgres
Successfully installed rails-2.3.8
Building native extensions.  This could take a while...
Successfully installed gem_plugin-0.2.3
Successfully installed daemons-1.1.0
Successfully installed cgi_multipart_eof_fix-2.5.0
Successfully installed mongrel-1.1.5
Successfully installed mongrel_cluster-1.0.5
Building native extensions.  This could take a while...
Successfully installed postgres-0.7.9.2008.01.28
7 gems installed
...
# rake gems:install
(in /home/payroll)
gem install haml
Successfully installed haml-3.0.12
1 gem installed
Installing ri documentation for haml-3.0.12...
Installing RDoc documentation for haml-3.0.12...
gem install money
...

첫 번째 명령은 RubyGems 자체가 최신 상태인지 확인한다. 두 번째 명령은 다음과 같은 일부 유용한 gem을 설치한다.

rails. Ruby on Rails 프레임워크이다.
postgres. PostgreSQL을 ActiveRecord와 함께 사용할 수 있도록 지원하는 데이터베이스 드라이버이다.
mongrel. Rails 애플리케이션을 호스트하는 데 사용되는 애플리케이션 서버이다.
mongrel_cluster. mongrel 그룹을 동시에 시작 및 중지하는 기능을 제공하는 유틸리티이다.

마지막 명령은 Rails 태스크를 실행하여 애플리케이션에 필요한 모든 추가 gem을 설치한다. config/environment.rb 파일에 config.gem 지시문이 없는 경우에는 gem install gemname 명령을 직접 실행하여 추가 gem을 설치해야 한다.

RAILS_ENV=production script/console 명령을 사용하여 애플리케이션을 시작한다. 이 명령이 성공하면 애플리케이션을 중지하고 다음 명령을 사용하여 mongrel 팩을 실행한다.

mongrel_rails cluster::start -C /home/payroll/current/config/mongrel_cluster.yml

첫 번째 명령이 실패한 경우에는 문제점을 찾는 데 도움이 되는 여러 오류 메시지가 표시되며, 일반적으로 gem 또는 파일이 없다는 문제점이 발생한다. 이 기회를 살려서 앞으로 gem을 잃어버리지 않도록 누락된 config.gem 지시문을 추가한다.

프론트엔드 웹 서버 설치하기

Nginx는 많은 가상 환경에서 사용하고 있는 웹 서버로, 오버헤드가 낮고 mongrel과 같은 백엔드 서비스에 대한 연결을 프록시하는 데 유용하다. Listing 10에서는 nginx를 설치하는 방법을 보여 준다.

Listing 10. nginx 설치하기

	
# rpm -Uvh http://download.fedora.redhat.com/pub/epel/5/i386/epel-release-5-3.noarch.rpm
...
# yum install nginx
...
Running Transaction
Installing     : nginx                                             [1/1]
Installed: nginx.i386 0:0.6.39-4.el5
Complete!
# chkconfig nginx on

Listing 11에서는 EPEL(Extra Packages for Enterprise Linux®) 저장소를 설치하고 nginx를 설치한 다음 시작 시에 올바르게 시작되는지 확인한다.

Listing 11. Rails 애플리케이션을 위한 nginx 구성

	
# Two mongrels, balanced based on least connections
upstream mongrel-payroll {
	fair;
	server 127.0.0.1:8100;
	server 127.0.0.1:8101;
}

server {
	listen 80;
	server_name  app.smallpayroll.ca;

	root   /home/payroll/current/public;
	gzip_static on;

	access_log  /var/log/nginx/app.smallpayroll.ca_log  main;
	error_page  404       /404.html;

	location / {
		# Because we're proxying, set some environment variables indicating this
		proxy_set_header X-Real-IP  $remote_addr;
		proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
		proxy_set_header Host $http_host;
		proxy_redirect false;
		proxy_max_temp_file_size 0;


		# Serve static files out of Root (eg public)
		if (-f $request_filename) {
			break;
		}

		# Handle page cached actions by looking for the appropriately named file
		if (-f $request_filename.html) {
			rewrite (.*) $1.html;
			break;
		}

		# Send all other requests to mongrel
		if (!-f $request_filename) {
			proxy_pass http://mongrel-payroll;
			break;
		}
	}
	error_page   500 502 503 504  /500.html;
	location = /500.html {
		root   /home/payroll/current/public;
	}
}

상당히 일반적인 nginx 구성을 보여 주는 Listing 11에서는 Rails 페이지 캐싱을 처리하고 동적 요청을 업스트림 mongrel에 전송하는 몇 가지 요소가 포함되어 있다. 필요한 경우 여기에서 다른 URL을 파일 이름에 맵핑할 수 있다.

구성을 완료한 후 service nginx start를 실행하면 웹 서버가 시작된다.

테스트하기

테스트를 위해서는 애플리케이션의 일반 도메인 이름을 사용하여 클라우드 인스턴스를 참조할 수 있으면 좋다. 왜냐하면 프로덕션 사이트가 아닌 테스트 사이트를 사용 중이라는 것을 보장할 수 있기 때문이다. 이 작업은 로컬 DNS 대체를 통해 수행한다. Windows의 경우 C:\windows\system32\drivers\etc\hosts를 편집하고, UNIX의 경우 /etc/hosts를 편집한다. 다음 행을 추가한다.

x.x.x.x  app.smallpayroll.ca

여기서, x.x.x.x는 클라우드 서버의 IP 주소이고, app.smallpayroll.ca는 애플리케이션의 이름이다. 브라우저를 다시 시작하고 사용자의 웹 사이트로 이동한다. 이제부터 애플리케이션의 클라우드 버전을 사용하고 있다. (프로덕션 버전으로 돌아가려면 방금 전 추가한 행을 주석으로 처리해야 한다.)

이제 프로덕션 버전뿐만 아니라 클라우드 버전의 애플리케이션이 정상적으로 작동하는지 테스트할 수 있으며 발견된 문제점이 있으면 해결한다. 두 번째 서버를 실행할 때도 활용할 수 있으므로 발견된 모든 문제점을 자세히 기록해 둔다. 클라우드 버전의 애플리케이션을 사용하고 있으므로 사용자에게 불편을 주지 않고 데이터베이스를 삭제 및 복원할 수 있다.

새 AMI 번들링하기

마지막으로 수행할 작업은 AMI를 다시 번들링하는 것이다. 새 인스턴스를 시작할 때마다 /mnt의 모든 컨텐츠가 삭제되고 루트 파티션이 AMI에 있는 디렉토리로 다시 설정된다. 아직까지는 /mnt 문제점을 해결할 수 있는 방법이 없지만 리번들링을 수행하여 AMI를 종료 시점의 상태로 유지할 수 있다.

시작 중인 AMI에 AMI 도구가 없는 경우에는 다음 명령을 실행하여 이러한 도구를 설치할 수 있다.

rpm -i --nodeps http://s3.amazonaws.com/ec2-downloads/ec2-ami-tools.noarch.rpm

AMI 번들링은 다음 3단계 프로세스로 진행된다.

인스턴스 자체에서 이미지를 작성한다.
이미지를 Amazon S3에 업로드한다.
AMI를 등록한다.

다음 단계를 진행하기 전에 먼저 열려 있는 파일이 올바르게 처리되었는지 확인하기 위해 mongrel 및 PostgreSQL 인스턴스를 종료한다. 또한 Amazon Console에 있는 X.509 키를 서버의 /mnt로 복사해야 한다. Listing 12에서는 VM 자체에서 수행되는 번들링 작업의 처음 두 단계를 보여 준다.

Listing 12. AMI 번들링하기

	
# ec2-bundle-vol -d /mnt -e /mnt --privatekey /mnt/pk-mykey.pem  \
--cert /mnt/cert-mycert.pem --user 223110335193 -p centos-ertw
Please specify a value for arch [i386]:
Copying / into the image file /mnt/centos-ertw...
...
Generating digests for each part...
Digests generated.
Creating bundle manifest...
ec2-bundle-vol complete.
# ec2-upload-bundle -b ertw.com -m /mnt/centos-ertw.manifest.xml \
--secret-key MYSECRETKEY --access-key MYACCESSKEY
Creating bucket...
Uploading bundled image parts to the S3 bucket ertw.com ...
...
Uploaded centos-ertw.part.37
Uploading manifest ...
Uploaded manifest.
Bundle upload completed.

첫 번째 명령은 번들을 생성하며 -e 및 -d 옵션을 사용하여 /mnt를 무시하고 번들을 /mnt에 저장하도록 지정한다. -k, --cert 및 --user 옵션은 보안 신임 정보와 AWS 사용자 ID를 가리킨다. 이러한 정보는 모두 AWS Management Console의 계정 설정에 있다. 마지막 옵션인 -p는 다른 AMI와 구별하기 위해 이 AMI의 이름을 지정하는 데 사용된다.

첫 번째 명령은 약 10분 동안 실행되며, 루트 파티션의 사용량에 따라 달라질 수 있다. 두 번째 명령은 번들을 Amazon S3에 업로드한다. -b 옵션은 버켓 이름을 지정하며, 같은 이름의 버켓이 없을 경우 새로 작성된다. -m 옵션은 마지막 단계에서 작성된 매니페스트 파일을 가리킨다. 마지막 두 옵션은 AWS Management Console에서 X.509 신임 정보 오른쪽 옆에 표시되는 Amazon S3 신임 정보이다. X.509 신임 정보는 Amazon EC2 조작에 사용되는 반면 Amazon S3에서는 텍스트 키를 사용한다는 점을 기억하기 바란다.

마지막으로 다음 명령을 실행한다.

ec2-register ertw.com/centos-ertw.manifest.xml

그러면 AMI가 등록되고 지금부터 사용할 수 있는 AMI ID가 표시된다. ec2-register 명령은 AMI와 함께 제공되지 않는다. 따라서 원본 AMI를 시작했던 서버에서 이 명령을 실행하는 것이 가장 쉬운 방법이다. 또한 Amazon EC2 인스턴스에 Amazon EC2 도구를 설치할 수 있다.

위로

마이그레이션 수행하기

지금까지 클라우드 환경을 실행하는 방법을 살펴보았다. 마이그레이션 자체는 훨씬 간단한 작업이다. 모든 기능이 정상적으로 작동하는지 확인했으므로 이제 데이터를 다시 동기화하고 나머지 작업을 차례대로 진행하면 된다.

마이그레이션 전에 수행할 태스크

마이그레이션 전에 도메인 이름 레코드의 TTL을 5분으로 낮추었는지 확인한다. 또한 모든 항목을 이동하는 과정에서 수행할 단계에 대한 점검 목록, 모든 기능이 작동하는지 확인하기 위해 실행할 테스트 및 필요한 경우 변경 사항을 취소할 절차를 마련해 두어야 한다.

사용자에게 마이그레이션을 알렸는지 확인한다.

마이그레이션 직전에 클라우드 환경이 동기화할 준비가 되어 있고 프로덕션 트래픽을 처리할 수 있는지 다시 한번 확인한다.

애플리케이션 마이그레이션하기

애플리케이션을 마이그레이션하려면 다음 단계를 수행한다.

사이트 특성에 따라 현재 프로덕션 사이트를 사용하지 않도록 설정하거나 읽기 전용 모드로 전환한다.
대부분의 SmallPayroll 요청에는 데이터베이스나 파일 시스템에 쓰는 작업이 포함되어 있으므로 사이트를 사용할 수 없다. Capistrano 개발 gem에는 유지보수를 위해 사이트가 종료되었음을 사용자에게 알리는 유지보수 페이지를 사이트에 배치하는 cap deploy:web:disable 태스크가 있다.
데이터 마이그레이션을 준비하기 위해 mongrel 프로세스를 종료하여 클라우드 환경의 애플리케이션 서비스를 중지한다.
테스트와 동일한 방법으로 데이터베이스를 복사한다.
필요한 경우 rsync를 다시 실행한다.

다음 명령을 사용하여 애플리케이션 서버를 다시 시작한다.

mongrel_rails cluster::start -C /home/payroll/current/config/mongrel_cluster.yml

hosts 파일이 클라우드 환경을 가리키고 있는지 확인하고 몇 가지 스모크 테스트를 수행한다. 사용자가 사이트에 로그인하여 탐색할 수 있는지 확인한다.

DNS 업데이트하기

스모크 테스트를 통과한 후에는 클라우드 환경을 가리키도록 DNS 레코드를 변경할 수 있다. 이 시점에서 웹 서버의 로그 파일에 대해 tail -f를 실행 중인 상태로 유지하면 사이트에 액세스하는 사용자를 확인할 수 있기 때문에 유용하다.

로컬 DNS 서버에는 기존 정보가 이후 5분 동안 캐싱된 상태로 유지되어 있으므로 dig 명령을 사용하여 이 정보를 확인할 수 있다(Listing 13 참조).

Listing 13. DNS 서버가 쿼리를 캐싱하고 있는지 확인하기

	
# dig  app.smallpayroll.ca @172.16.0.23

; <<>> DiG 9.3.4 <<>> app.smallpayroll.ca @172.16.0.23
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38838
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 13, ADDITIONAL: 0

;; QUESTION SECTION:
;app.smallpayroll.ca.           IN      A

;; ANSWER SECTION:
app.smallpayroll.ca.    251     IN      A       69.164.205.185
...

ANSWER 섹션을 보면 항목이 251초 만에 만기된다는 것을 알 수 있다. 현재는 hosts 파일이 DNS를 대체하고 있으므로 dig, host 또는 nslookup과 같은 도구를 사용하여 DNS를 확인하는 것이 중요하다. ping을 사용하여 hosts 내의 항목을 확인할 수도 있다.

DNS가 전파하기를 기다리면서 최종 승인 테스트를 수행한다.

위로

결론

지금까지 애플리케이션을 클라우드에 마이그레이션했다. 기본 절차는 다음과 같다.

새 환경을 설정한다.
프로덕션 데이터의 사본을 사용하여 테스트한다.
기존 환경을 끈다.
프로덕션 데이터를 새 환경에 복사한다.
새 환경을 가리키도록 DNS를 변경한다.

"클라우드에" 있음에도 불구하고 아마도 애플리케이션의 성능이 예전보다 좋지 않을 것이다. 다음과 같은 사항을 생각해 보자.

애플리케이션이 여전히 하나의 서버에서 실행되고 있다.
서버에서 충돌이 발생할 경우 모든 데이터가 손실된다.
실제 서버를 사용할 때보다 성능을 제어할 수 있는 기능이 적다.
시스템 및 애플리케이션이 잠기지 않는다.

다음 기사에서는 이러한 문제점을 극복하고 강력한 애플리케이션 환경을 빌드하는 방법에 대해 살펴본다.

참고자료

교육

developerWorks의 Cloud Computing 영역에서 클라우드용 애플리케이션을 개발하고 배치하는 데 필요한 자원을 얻을 수 있으며 최신 클라우드 개발 정보도 확인할 수 있다.
Amazon EC2 인스턴스에서 인스턴스 메타데이터를 요청하여 사용해야 하는 SSH 키와 사용자 지정 정보를 비롯하여 인스턴스에 대한 정보를 얻을 수 있다.
AWS Management Console을 살펴보면서 클라우드 모험을 시작하자.
Amazon EC2에서 작업하고 있다면 Amazon에서 제공하는 다양한 안내서에 익숙해져야 한다.
s from Amazon의 관점과 IBM의 관점에서 IBM AMI에 대해 자세히 알아보자.
developerWorks에 실린 Sean의 모든 기사를 살펴보자.
Linux에서는 수백 개의 기술자료 목록과 함께, Linux 개발자와 관리자를 위한 다양한 다운로드, 토론 포럼 및 다른 참고자료를 찾을 수 있다.
developerWorks 기술 행사 및 웹 캐스트를 통해 다양한 IBM 제품 및 IT 산업 주제에 대한 최신 정보를 얻을 수 있다.
무료 developerWorks Live! briefing을 통해 최신 IBM 제품 및 도구에 대한 정보뿐만 아니라 IT 업계의 최신 경향까지도 빠르게 확인할 수 있다.
developerWorks on-demand demos에서는 입문자를 위한 제품 설치 및 설정부터 숙련된 개발자를 위한 고급 기능까지 망라된 다양한 데모를 제공한다.
Twitter의 developerWorks를 팔로우(follow)하거나 developerWorks에 대한 Linux 트윗(tweet)의 피드를 구독하자.

제품 및 기술 얻기

Ruby Enterprise Edition은 그 자체로 또는 Phusion Passenger와 함께 사용하여 Apache 또는 nginx와 통합할 수 있는 고성능 Ruby 구현이다. 어느 방법을 사용하더라도 빠르게 메모리를 관리하고 가비지 콜렉션의 성능을 향상시킬 수 있다.
IBM Industry Application Platform AMI for Development Use에 등록하여 다양한 IBM 제품을 클라우드에서 사용할 수 있다. 체크아웃 프로세스를 거쳐야 하지만 제품을 사용하기 전까지는 비용이 부과되지 않는다. ami-90ed0ff9를 사용할 수도 있다.
Amazon EC2 API Tools는 인스턴스를 시작 및 종료하고 새 인스턴스를 리번들링하기 위해 Amazon API와 통신하는 데 사용된다. Amazon EC2에 새 기능이 도입되기 때문에 이러한 도구는 주기적으로 업데이트되고 있으므로 제품 발표 후 이 페이지에서 업데이트를 확인하는 것이 좋다. 나중에 로드 밸런싱 기능을 사용할 것이므로 적어도 2009-05-15 업데이트가 필요하다.
자신에게 가장한 적합한 방법으로 IBM 제품을 평가해 보자. 시험판 제품을 다운로드하거나, 온라인으로 제품을 사용해 보거나, 클라우드 환경에서 제품을 사용하거나, SOA Sandbox에서 SOA(Service Oriented Architecture)를 효과적으로 구현하는 방법을 배울 수 있다.