[발 번역] 클라우드 컴퓨팅 시스템 아키텍처 다이어그램

해당 블로그는 KT UCloud 의 지원을 받고 있습니다.

해당 글은 http://support.rightscale.com/12-Guides/EC2_Best_Practices/EC2_Site_Architecture_Diagrams 글을 발 번역한 것입니다. 오역에 주의하시기 바랍니다.  해당 내용을 보면 RightScale을 이용해서 구성하는 구조라고 나옵니다. 그렇다면, 제가 RightScale 를 쓰기를 추천해서 해당 글을 선택한 것은 아니라, RightScale을 이용하든 안하든, 실제로 클라우드 기반 설계를 하게되면, 아래에서 보여주는 형태로 하게 되기 때문입니다. RightScale은 여러가지 클라우드 설정을 쉽게하고 구축을 도와주는 것이므로, 실제로, 최종 결과물은 우리가 꼭 해당 기술을 이용하지 않더라도 따라가야하는 모습입니다. 이번에 또, 아마존의 버그로 인해서 몇몇 유명 사이트(instagram, heroku, pinterest, raddit ) 이 사이트가 제대로 동작하지 않는 이슈가 있었습니다. 그에 대비하는 것이 Multi Cloud나 Hybrid Cloud 가 될 것입니다. 물론, 이런 클라우드 서버 시스템의 구조를 따르기 전에, 자신의 서비스나 데몬이 장애에 대응 가능하게 구성되어 있는지를 꼭 먼저 체크하시기 바랍니다.

Table of Contents

  1. 1. Overview
  2. 2. Things to Consider
  3. 3. Example Reference Diagrams
    1. 3.1. Single “All-in-one” Server
    2. 3.2. Single Cloud Site Architectures
      1. 3.2.1. Non-Redundant 3-Tier Architecture
      2. 3.2.2. Redundant 3-Tier Architecture
      3. 3.2.3. Multi-Datacenter Architecture
      4. 3.2.4. Autoscaling Architecture
      5. 3.2.5. Scalable Architecture with Membase
      6. 3.2.6. Scalable Multi-Tier Architecture with Memcached
      7. 3.2.7. Scalable Queue-based Setups
        1. 3.2.7.1. Number of Jobs
        2. 3.2.7.2. Time
        3. 3.2.7.3. Internal Hybrid Setup
        4. 3.2.7.4. Alert-based and Queue-based Scalable Setup
    3. 3.3. Hybrid Cloud Site Architectures
      1. 3.3.1. Scalable MultiCloud Architecture
      2. 3.3.2. Failover MultiCloud Architecture
      3. 3.3.3. MultiCloud Disaster Recovery Architecture
      4. 3.3.4. Cloud and Dedicated Hosting Architecture

Overview

아래에서 RightScale Platform을 이용해서 public, private 클라우드 인프라스트럭처를 이용하는 클라우드 기반 솔루션의 샘플 다이어그램을 몇개 찾을 수 있을것 입니다.  해당 아키텍처의 대부분은 MultiCloud Marketplace에서 존재하는 ServerTemplates를 이용해서 구성할 수 있을 것입니다.  각각의 어플리케이션은 유일하고, 요구사항에 대해서, 목적에 맞게 수정된 것들입니다. 아래의 시스템 아키텍처 다이어그램의 목적은 클라우드에서 자신만의 시스템 아키텍처를 디자인 해야 할 때, 기본 참고 아키텍처로 사용할 수 있는 실제 예제를 알려주기 위해서 입니다. 만들고자 하거나, 수정하거나, 자체 프로젝트의 요구사항에 따라서 변경해야 할 때, 필요로 하는 것과 비슷한 시스템 아키텍처를 찾을 수 있습니다. 다이어그램들은 장애 복구(DR)나 멀티 클라우드 배포와 같은 특별한 컨셉으로 디자인되었습니다. 자기 만의 솔루션 아키테처를 디자인 할 때, 아래에 묘사된 여러 컨셉과의 연관에 대해서 고려하시기 바랍니다.

Things to Consider(고려사항)

여기에 자신만의 클라우드 기반의 시스템 아키텍처를 설계하려고 한다면 깊이 고려해야 하는 여러가지 요소들이 있습니다. 특히 멀티 Cloud/Region 아키텍처를 고려중이라면 더더욱 그렇습니다.

  • Cost – 사이트/어플리케이션을 설계 하고, 서비스를 시작하기 전에, 사용할 클라우드 인프라스트럭처에서 제공하는 가격 모델과 SLA에 대해서 명확하게 이해하고 있어야 합니다. private 과 public 클라우드는 각각 다른 비용이 소모됩니다. 예를 들어, AWS에서는 같은 데이터센터( 같은 Availability Zone ) 에서는 데이터 전송비용이 무료입니다. 그리고 같은 EC2 Region 내의 데이터 통신이 다른 Region의 클라우드나 자체 데이터센터와의 통신보다 쌉니다.
  • Complexity – 고도로 맞춤화된 하이브리드 클라우드 솔루션 아키텍처를 구축하기 전에, 해당 어플리케이션의 동작에 필요한 요구사항(SLA 등등)에 대해서 확실하게 이해해야 합니다. 간결한 아키텍처는 항상 디자인하기도 쉽고 관리하기도 편하게 만듭니다. 좀 더 복잡한 아키텍처는 오직 간결한 버전이 충분하지 않을 때만 사용되어야 합니다. 예를 들어, 멀티 클라우드(Region들)로 분산된 시스템 아키텍처는 아키텍처 레벨에서 복잡성이 늘어나고, 다른 클라우드간 장애 대응을 위해서 마이그레이션 되는 데이터베이스와 통신하거나 좀 더 반응시간에 안정적이기 위해서 어플리케이션 레벨에서도 많은 변화가 필요할 것입니다.
  • Speed – 클라우드는 웹 사이트와 어플리케이션의 속도나 반응속도에 좀 더 유연함을 제공합니다. 예를 들어서, 어플리케이션의 필요에 따라서 서로 다른 종류의 인스턴스를 시작할 수 있습니다. 높은 메모리나 높은 CPU 타입의 인스턴스가 필요하다면? 유저의 위치에 따라서 지역적으로 가까운 클라우드에서 낮은 레이턴시를 제공하고 싶다면? CDN이나 캐시 서비를 이용하는 것이 비용이 싸거나, 필요하다면? 멀티 클라우드간의 통신 때문에, 추가적인 레이턴시가 필요하다면, 어플리케이션에 따라서 용납하지 못할 수도 있습니다.
  • Cloud Portability – 클라우드 서비스에서 제공하는 툴이나, 서비스, 예를 들어, 로드밸런서나 데이터 베이스 서비스를 사용하는 것이 쉽긴 하지만, 아키텍처의 일부분을 다른 클라우드 서비스로 옮겨야 할 필요가 있을 때, 아키텍처를 변경해야 한다는 것을 깨닫는 것은 매우 중요합니다.  Service Template 은 클라우드 종류에 상관없이 사용이 가능하므로, 이것을 이용해서 이동 가능한 유연한 클라우드 아키텍처를 만들 수 있습니다.
  • Security – 멀티 클라우드 시스템 아키텍처에서, 클라우드 간 통신이 일반 인터넷으로 수행된다는 것을 아는 것은 매우 중요합니다. 그러므로 VPN이나 암호화를 이용해서 보안에 대해서 생각을 해야합니다.

Example Reference Diagrams

아래의 아키텍처 다이어그램은 간단한 것에서 좀 더 복잡한 레퍼런스 아키텍처를 보여줍니다.(역자 주: 자신의 기준에 맞춰서 간단한 거 일 수록 유지보수가 편하겠죠?)

Single “All-in-one” Server

“All-in-one” Server Template 들 중에 하나를 사용하면, 예를 들어, LAMP(Linux, Apache, Mysql, PHP) Server Template를 하나의 서버에서 구동하면, 해당 서버는 Apache 웹 서버와, PHP, Mysql을 포함하고 있습니다. 신규 RightScale 유저와 기본적인 데모에 유용한 간단한 “All-in-one” Server Template 들을 MultiCloud 마켓플레이스에서 쉽게 찾을 수 있을 겁니다.

diag-System_Architecture-1.png

Single Cloud Site Architectures

표준적인 3-Tier 웹 사이트 아키텍처에서는, 시스템의 각 티어마다 적어도 한대 이상의 서버가 있습니다.(Load Balancing Server, Application Server, Database Server)

Non-Redundant 3-Tier Architecture

아키텍처의 각 티어간의 상호 테스팅이 목적이라면, 비용과 리소스를 아끼기 위해서, 이중화 되지 않은 시스템 아키텍처를 원할 것입니다. 개발 목적이나 간단한 테스트를 위해서 이러한 이중화 되지 않은 시스템 아키텍처를 주로 원합니다. 아래 예제 다이어그램에서, 각 어플리케이션이나 사이트의 티어마다 서버들이 있습니다. 실제 서비스 환경에서는 해당 아키텍처는 권장하지 않습니다.

diag-System_Architecture-2.png

Redundant 3-Tier Architecture

클라우드에서 실행되는 모든 실 서비스 환경은 장애회복을 위해서 이중화되어야 합니다. 일반적으로 클라우드에서 Auto Scaling의 장점을 취하기 위해서 해당 어플리케이션 티어에서 서버를 여러 대 추가할 수 있는 형태로 사용할 것입니다. 그러나, 어플리케이션이 auto scale 되도록 고혀하지 못한 시나리오가 몇 개 있을 것입니다. 이런 경우에도, 아래 레퍼런스 아키텍처의 각 티어에서 이중화 된 것을 보고, 이중화된 멀티 티어 아키텍처를 만들 수 있습니다.  아래의 예제를 보면, 두 개의 로드밸런서 서버, 두 대의 어플리케이션 서버, 마스터, 슬레이브 데이터 베이스가 있습니다. 이중화된 아키텍처는 웹이나 어플리케이션을 시스템 다운으로 부터 보호하는 것을 돕습니다.(역자 주: 클라우드를 사용하지 않을 때는 물리적 시스템 구성에도 신경을 써야 합니다. 최소 라우터 두 개, 스위치 두 개를 이용해서 LoadBalancer 를 연결해 두고 각 서버단에 연결을 해두어야 장비 장애시 안전성을 보장해줍니다.)

아래의 샘플 다이어그램은 데이터베이스 티어에서 분리된 볼륨 셋을 사용한 것을 보여줍니다. 만약 데이터베이스가 크고, 빠른 백업이 필요하다면, 데이터 스토리지를 위한 불리된 볼륨 셋을 고려하는 것을 권장합니다.

diag-System_Architecture-3.png

Multi-Datacenter Architecture

현재 사용하는 클라우드 인프라스트럭처가 다중 데이터센터(Zone) 을 지원한다면, 시스템 아키텍처를 이중화 레이어를 다중 데이터센터를 이용해서 펼쳐 놓기를 권장합니다. 클라우드의 각 데이터센터는 같은 지역 클라우드 내에서 분리된 지역에 위치하도록 설계되었습니다. 만약 하나의 데이터센터에 전력 장애가 발생하면, 다른 데이터센터는 영향을 받지 않습니다. 예를 들어서, AWS의 각 EC2 Region(cloud)는 다수의 Availability Zone들을 가지고 있습니다. 다중 데이터센터를 사용하는 장점은 특정 데이터센터의 네트웍이나 전력 장애, 또는 리소스의 부족, 서비스 용량 초과 등의 안좋은 상황에서 전체 웹사이트나 어플리케이션을 보호할 수 있다는 것입니다.

좋은 사례로써, 클라우드 인프라스트럭처에서 지원이 된다면, 레퍼런스 아키텍처처럼 다중 데이터센터 간에 연결이 되도록 해야 합니다. 아래의 다른 레퍼런스 아키텍처 다이어그램에서 처럼, 명시적으로 다중 데이터센터 사용이 보여지지 않더라도, 다중 데이터 센터를 사용하는 것을 권장합니다.

Note: 추가적인 비용은 다른 데이터센터간에 데이터 전송이 얼마나 발생하는 가에 달려있습니다.

diag-System_Architecture-4.png

Autoscaling Architecture

시간에 따른 어플리케이션이나 웹사이트의 필요에 따른 수평 적인 확장 능력은 클라우드이 주요 장점중에 하나입니다.( 운영 중인 서버 자원을 늘리거나, 줄일 수 있는) RightScale 과 함께라면, 아키텍처의 특정 티어를 미리 정의된 조건에 따라 기반해서 자동으로 확장가능한 서버 구조로 사용할 수 있습니다. Autoscaling은 클라우드 레퍼런스 아키텍처의 어플리케이션 티어에서 가장 흔히 사용되고 있습니다.

diag-System_Architecture-5.png

Scalable Architecture with Membase

Master-Slave 구성의 Mysql 셋팅을 원한다면, 데이터베이스 티어를 위해서 모든 Membase 노드들 간에 데이터를 리플리케이션 하는 분산 NoSQL 데이터베이스인 Membase(Couchbase)를 이용할 수 있습니다. 기업용 버전을 사용하길 원한다면, 아래에서 보여주듯이 각 노드마다 볼륨을 붙일 수 있습니다. 커뮤니티 버전의 경우는 볼륨의 사용이 불가능합니다.

diag-System_Architecture-7.png

Scalable Multi-Tier Architecture with Memcached

어플리케이션과 웹 사이트를 위해서 많은 스태틱 파일을 서비스 해야하고, 많은 읽기가 필요해서, 읽기가 많은 데이터베이스의 부하를 줄이기 위해, 클라우드 시스템 아키텍처에 Memcached 레이어를 추가하기를 원할 수 있습니다.  Memcached는 오픈 소스 분산 메모리 객체 캐싱 시스템으로 데이터베이스의 부하를 감소시켜서 동적 웹 어플리케이션의 속도를 높이기 위해서 만들어졌습니다. 아래의 샘플 다이어그램을 보면, 어플리케이션 서버들은 여전히 데이터베이스에 쓰기를 하고 있지만, 많은 흔히 사용되는 객체들은 마스터 DB 서버 대신에 memcached 서버들 중에 하나에서 서비스 되고 있습니다.

diag-System_Architecture-6.png

Scalable Queue-based Setups

(AWS only)

RightScale의 Grid Edition 은 아마존 EC2 같은 클라우드 컴퓨팅 인프라스트럭처의 확장 기능의 장점을 가짐으로써, 효과적인 잡 처리를 위한 효과적인 솔루션으로 백엔드 배치 프로세싱 프레임워크를 제공합니다. 큐 안의 작업 수에 기반하거나 큐 안에 얼마나 오래 샘플 잡들이 체류했는가에 기반해서, 확장가능한 Grid 어플리케이션을 생성합니다.

Number of Jobs

큐 안의 작업 수에 기반해서 배치 프로세싱 어플리케이션을 확장하는 것은 가장 일반적인 방법입니다.

rightgrid_number_jobs.gif

Time

큐 안에 샘플 잡들이 얼마나 오래 처리되지 않았는지를 기반으로 Grid 어플리케이션을 생성합니다. 이 셋팅에서, 큐 안에 10개의 아이템 중에 하나를 무작위로 샘플로 선택합니다.  서버들은 큐 안의아이템의 평균 체류 기간이나, 가장 오래된 아이템에 기반해서 확장하게 될 것입니다.

rightgrid_time.gif

Internal Hybrid Setup

이미 Grid 아키텍처를 쓰고 있거나 여전히 사용하길 원하는 내부 컴퓨팅 리소스가 이미 있다면, AWS Region 안에 필요할 때 확장 가능한 하이브리드 모델을 만들 수 있습니다. 해당 셋팅은 내부 자원의 사용과 클라우드의 제한 없는 컴퓨팅 리소스를 사용할 수 있는 유연성을 제공합니다.

rightgrid_internal_hybrid.gif

Alert-based and Queue-based Scalable Setup

같은 배포에 여러개의 서버를 붙일 수 있기 때문에, 확장가능한 프론트 엔드, 백 엔드 서버군들을 가지는 두 개의 확장 가능한 아키텍처 역시 만들 수 있습니다.

site_grid_array_diagram_v1.png

Hybrid Cloud Site Architectures

클라우드의 웹 사이트, 어플리케이션을 보호하는 다른 방법은 여러 개의 public/private 클라우드 인프라스트럭처 와 개별적으로 호스팅된 서버를 하이브리드한 클라우드 사이트 아키텍처를 디자인하는 것입니다. RgihtScale 플랫폼의 주요 장점중에 하나는 클라우드 이동성입니다. 같은 설정 정보들을 이용해서(ServerTemplate과 RightScripts 등등) 같은 기능의 서버들을 여러 public/private 클라우드에서 시작할 수 있습니다. 클라우드 Lock-In을 피하기 위해서, 하나의 클라우드 대신에 여러 클라우드 리소스 풀을 사용할 수 있도록 아키텍처를 디자인해야 합니다. 유사하게, 내/외부 데이터 센터에 호스팅된 다른 서버들과 클라우드 내의 웹서버가 통신하도록 하이브리드 클라우드 아키텍처로 디자인할 수 있습니다.

Scalable MultiCloud Architecture

아래의 샘플을 보면, 웹사이트, 어플리케이션을 위해서 하나의 클라우드 인프라 스트럭처를 이용할 수 있습니다. 그러나, 다른 클라우드 인프라스트럭처의 어플리케이션 티어의 Auto Scaling을 위해서 서버들을 셋팅할 수도 있습니다. 예를 들어, 퍼블릭 클라우드 인프라스트럭처에서 서버를 구동함으로써, 비용을 발생하기 전에, 개인적인 클라우드 서버를 사용할 수 있습니다. 아래의 멀티클라우드 아키텍처 다이어그램은  어플리케이션을 개인 클라우드 인프라스트럭처에 호스팅하고, 필요하면 추가적인 서버 용량을 위해 퍼블릭 클라우드로 Auto Scale 하는 것을 보여주고 있습니다.

diag-System_Architecture-9.png

Failover MultiCloud Architecture

아래의 샘플 다이어그램에서 같은 ServerTemplate과 스크립트들은 Cloud X, Y에 상관없이 설정과 서버 시작에 사용되어 집니다. 멀티 클라우드에서  동작하는 클라우드 시스템 아키텍처를 디자인하고 있다면, 알아야할 몇 가지 고려사항이 있습니다. 아래의 다이어그램에서 Slave-DB 서버는 “Warm Backup” 상태로 동작하고 있습니다. 그래서 마스터 DB와의 리플리케이션은 Private IP가 아니라 공인 IP를 이용하고 있습니다. 오직 같은 클라우드 인프라스트럭처 내에서만 private IP로 통신할 수 있습니다. 그러나, 장애나 다른 문제로 인해서 클라우들를 변경해야 할 때, 멀티 클라우드 아키텍처는 쉽게 웹사이트나 어플리케이션을 이전하는 것을 도와줍니다. 레퍼런스 아키텍처에서 다른 티어들은 이미 설정이 되어 있고, Cloud X에서 Y로 실 서비스를 옮겨야 할 필요가 있을 경우 쉽게 시작할 준비가 되어 있습니다. public/private 클라우드의 어떠한 조합이라도, RightScale 계정안에서 가능하다는 것을 기억하는 것은 중요합니다.

diag-System_Architecture-8.png

다른 두 클라우드 서버간에 안전한 방법을 통해서 데이터를 전송/수신하기를 원한다면, 다른 두 클라우드 인프라스트럭처 사이에 전송되는 공인 IP로 전송되는 모든 데이터들에, 데이터 암호화나  VPN 을 사용할 수 있습니다.(각각 클라우드 내부는 제외하고), 아래의 다이어그램에서, 데이터 복제는 안전한 VPN 터널을 이용해서 다른 두 클라우드 서버들 간에 퍼블릭 인터넷을 거쳐서 이루어지고 있습니다.

diag-System_Architecture-10.png

MultiCloud Disaster Recovery Architecture

RightScale 관리 플랫폼의 주요 장점 중에 하나는 자동적으로 멀티 클라우드 장애 복구 솔루션을 ServerTemplate들을 이용해서 좋은 사례를 따라함으로써 간단히 사용할 수 있다는 것입니다. 어떤 클라우드도 장애에 검증되지 않았습니다. 서버와 서비스들은 갑자기 다운되므로, 다양한 장애 복구 시나리오를 다룰 수 있도록 시스템 아키텍처가 구축되어 있는것은 중요합니다. 예를 들어, 현재 배포된 실 서비스가 돌고 있는 클라우드가 용량 부족이 갑자기 발생한다면 무슨 일이 벌어질까요? 전통적인 서버 호스팅 모델에서는 호스팅 업체가 문제를 해결해 줄 때 까지 기다리고, 동작 가능하도록 서버 상태를 되돌리는 방법밖에 없었습니다. 그러나 클라우드에서는 웹사이트가 적절히 설계되어 있다면, 즉시 반응할 수 있고, 스스로 웹사이트를 복구할 수 있습니다.   예를 들어서, RightScale의 ServerTemplate들을 사용해서, 실 서비스를 배포했다면, 다른 여러 클라우드에도 같은 ServerTemplate을 이용해서 같은 서버들을 배포할 수 있습니다.  그래서 클라우드에서 서비스가 문제가 발생해도(예를 들어, AWS US-East), 다른 클라우드나 Region 에 바로 실서비스를 재구축 할 수 있습니다. 만약, ServerTemplate들 대신에, 현재 배포된 AWS Region에서 사용한 AMI를 사용한다면, 아래에 묘사된 상황에서는 장애를 복구하지 못할 것입니다.

 아래에 묘사된 다이어그램은 RightScale 관리 시스템을 통해서만  가능한 두 가지 장애 복구 솔루션을 보여줍니다.

  1.  해당 예제에서, 스냅샷은 기본적으로 일정 시간마다 백업되고 있습니다. 그러나 수동으로 데이터베이스의 LVM 백업을 해야 합니다. 그러므로 클라우드 장애시에 데이터베이스 이전을 수행해야 합니다. LVM bakcup을 이용해서 다른 클라우드나 Region에 데이터베이스 서버를 재 시작할 수 있습니다. 데이터베이스 서버가 LVM 백업으로 부터 동작하기 시작하면, 정기적으로 데이터베이스의 백업은 계속 될 것입니다. Note: 현재 다이어그램에서는 하나의 데이터베이스는 데이터베이스 스토리지를 위해서 하나의 볼륨만 이용하고 있는 것을 보여주고 있습니다. 로컬 서버에도 데이터를 저장할 수 있습니다.
  2. 해당 예제에서, LVM 백업은 다른 클라우드 스토리지에 저장됩니다.(e.g. RackSpace Cloud Files Contaner) 그리고 다른 클라우드에서 실해되는 데이터베이스 서버를 복구하는 데 사용됩니다.( e.g. Rackspace Cloud Servers) 데이터베이스 서버가 동작하면, 정기적으로 데이터베이스는 백업을 시작합니다.

Note: 현재 ServerTemplate은 이런 동작은 베타 서비스중입니다.

diag-System_Architecture-13.png

Cloud and Dedicated Hosting Architecture

하이브리드 클라우드 솔루션 아키텍처의 다른 형태는 public/private 클라우드 리소스를 내/외부의 데이터센터에 있는 자원들과 함께 사용하는 것입니다. 예를 들어서, 데이터베이스는 서버는 민감한 유저 정보와 중요한 데이터들을 가지고 있으므로, 물리적 위치에 엄청난 제약 조건이 있을 것입니다. 이런 경우에, 어플리케이션이나 웹 사이트의 다른 티어들은 같은 종류의 제약조건이 없을 때, 데이터 베이스는 클라우드 인프라스트럭처에 호스팅되지 않을 수 있습니다. RightScale 플랫폼을 이용해서 클라우드 서버와 호스팅된 서버 사이의 공인 IP 사이에 안전한 터널을 생성하는 VPN 솔루션을 이용한 하이브리드 시스템 아키텍처를  만들 수 있습니다.

diag-System_Architecture-11.png