AWS 클라우드 아키텍처 특징

 본 장에서는 기존 SI 프로젝트의 대상이 된 On-Premise 환경 대비 클라우드 환경이 가지고 있는 클라우드 환경만의 특징을 사전에 파악하고, 클라우드 환경에서 아키텍처 설계를 위하여 필요한 설계 원칙에 대하여 설명한다. 

1. On-Premise vs. Cloud

---

클라우드 환경이 가지고 있는 여러가지 특징 중 On-Premise와 가장 크게 다른 부분은 물리적인 리소스에 대한 제어 권한을 사용자가 갖고 있는지 여부이다. 즉, On-premise 환경의 경우 사용자가 직접 물리적인 환경/리소스를 구매/구성하고 이 환경하에서 사용자의 어플리케이션을 직접 운영하는 환경이었다면, 클라우드 환경은 이 중 물리적인 리소스 및 이에 대한 직접적인 제어는 클라우드 환경 제공자가 수행하고, 사용자는 해당 환경 중 사용하는 리소스의 용량과 사용 시간에 대한 비용을 제공자에게 지불하는 것이라 할 수 있다. 
앞서 언급한 특징 이외에 클라우드 환경이 가지고 있는 특징에 대하여 살펴보면 아래와 같다. 

항목	내용
모든 리소스는 프로그래밍 가능한 형태로 존재	전통적인 On-Premise 환경과 다르게 클라우드 환경하의 모든 리소스(서버/데이터베이스/스토리지 등)는 프로그래밍 가능한 리소스로 구성 On-Premise 환경에서 물리적으로 실체가 존재하는 리소스를 이용하여 환경을 구성하였다면, 클라우드 환경에서는 앞서 언급한 모든 리소스들이 논리적인 형태로 존재하고, 이를 이용하여 환경을 구성 해당 리소스들은 웹콘솔 뿐만 아니라 CLI/SDK 등 프로그래밍적 접근으로도 생성/구성이 가능하고, 각 리소스 별 설정 가능한 파라미터를 이용하여 용량의 증설/축소/생성/폐기 및 기타 다양한 설정 변경 가능
글로벌한, 가용한, 무제한 용량	On-Premise 환경은 초기 설계된 용량과 제한된 위치(센터 등)에서만 사용 가능한 리소스들이 클라우드 환경에서는 좀 더 유연하게 확장된 형태로 구성가능 최종 사용자의 위치에 따라 가장 적합한 지역을 판단하고 해당 지역에 인프라 환경을 구성할 수 있으며, 각 지역에 구성된 인프라 환경 간의 자유로운 어플리케이션/데이터의 공유가 가능하여 하나의 지역에 발생한 장애에도 유연하게 대응 가능 각 환경을 구성하는 자원은 사용자/업무 증감에 따라 자유롭게 수평적 또는 수직적으로 확장/축소 가능
높은 수준의 관리 서비스	클라우드 환경에서의 모든 리소스는 앞서 설명한 바와 같이 논리적인 형태로 존재하며, 이 리소스들은 클라우드 솔루션 업체(ex. Amazon)의 관리하에 존재 사용자는 해당 리소스에 대한 모니터링/관리 등을 위하여 요구되는 솔루션/인력 비용을 절감할 수 있음
보안 기능 내장	하나의 물리 서버에 불특정 다수가 사용하는 다수의 가상 환경을 구성할 수 있는 클라우드 특성 상 보안 관련 기능이 강화되어있으며 기본 서비스로 제공 이러한 보안 기능은 앞서 설명한 바와 같이 관리자가 설정 가능한 파라미터 형태로 존재하며, 해당 기능을 이용하여 보안 관련 솔루션/인력에 투자되는 비용을 절감할 수 있음.

표 1. 클라우드 환경 특징

이런 특징들로 클라우드 환경은 시스템 구축에 걸리는 리드타임을 극단적으로 줄이는 것이 가능하고 서비스 부하에 유연한 대응이 가능한 자원 효율성이 높은 시스템을 운영할 수 있다. 따라서, 기존 On-Premise 환경에서의 설계와 동일한 절차로 설계를 진행하더라도 위에서 언급한 클라우드 환경의 특징을 감안하여 클라우드 환경의 이점을 활용하기 위해서는 기존 On-Premise 환경의 아키텍처와는 다른 개념으로 접근하여야 한다.

• 하나의 거대한 모노리틱 서비스 대신 작고 기능별로 분해된 서비스가 서로 API 또는 비동기 메시징 등을 통해 이벤트를 주고 받는 응용 프로그램
• 설계 단계에서 Peak 치의 부하까지 예상해서 용량산정을 하는 것이 아니라 수평적 확장이 가능하도록 애플리케이션을 설계하여 수요가 필요할 때 새로운 리소스를 인프라에 추가 등

on-premises	클라우드
Monolithic, centralized Design for predictable scalability RDBMS Strong consistency 순차적/동기(Serial/Sync) 처리 Design to avoid failures (MTBF) Occasional big updates Manual management Snowflake servers	Decomposed, de-centralized Design for elastic scale Polyglot persistence (mix of storage technologies) Eventual consistency 병렬적/비동기(Parallel/Asnyc) 처리 Design for failure (MTTR) Frequent small updates Automated self-management Immutable infrastructure

표 2. 환경 별 아키텍처 특징 비교

2. 클라우드 아키텍처 구조

---

클라우드 솔루션 업체에서 제공하는 클라우드 환경은 네가지 Layer로 구분할 수 있으며, 해당 Layer 구분에서 어느 Layer까지 사용자가 클라우드 솔루션 업체로부터 서비스를 제공받는지에 따라 클라우드 서비스 모델이 결정된다고 할 수 있다. 

항목	내용
Physical Layer	물리적인 서버/스토리지/네트워크 등과 이러한 시스템 인프라가 존재하는 IDC 등 데이터 센터.
Logical Layer	물리적인 시스템 인프라를 서비스를 이용하고자 하는 사용자에게 할당할 수 있도록 논리적으로 분리하여 구성한 상태.
Platform Layer	논리적으로 분리된 시스템 인프라 위에 WAS/DBMS와 같이 사용자가 개발한 어플리케이션을 실행할 수 있는 주요 엔진 등을 포함. 또한 클라우드 솔루션 업체가 제공하는 이러한 주요 서비스를 사용하기 위하여 개발에 필요한 SDK/Runtime등을 포함.
Service Layer	클라우드 솔루션 업체가 제공하는 Ready-Made된 어플리케이션으로 사용자가 요구하는 기능이 구현된 어플리케이션을 사용자가 직접 설정을 통하여 사용하도록 구성한 상태. IaaS/PaaS 사용 시 제공되는 관리 환경과 보안 환경을 포함함.

표 3. 클라우드 환경 Layer 구분

위의 구분 중 Physical Layer와 Logical Layer는 물리적인 인프라 측면에서의 구분이며, Platform Layer 및 Service Layer는 소프트웨어 측면에서의 구분이라 할 수 있다. 일반적으로 클라우드 솔루션을 제공하는 업체의 경우 위의 구분 중 Logical Layer와 Platform Layer의 경우 Platform Layer로 구분하고 있다.

대표적인 클라우드 솔루션 업체인 Amazon의 경우 그들의 클라우드 솔루션인 Amazon Web Service(이하 AWS)의 Layer를 아래와 같이 정의하고 있다.

그림 1. Amazon Web Service Layer 정의

또한 Azure라는 클라우드 서비스를 제공하는 Microsoft의 경우 AWS와 유사한 형태의 Layer를 아래와 같이 정의하고 있다.

그림 2. Azure Service Layer 정의

일반적으로 두 클라우드 솔루션 업체 모두 표현의 방식은 다르나, 위에서 설명된 4가지 Layer와 크게 다르지 않음을 알 수 있다. 

3. 클라우드 서비스 모델

---

클라우드 솔루션 업체가 제공하는 클라우드 서비스 모델은 앞서 설명한 클라우드 아키텍처 중 클라우드 제공자의 관리 영역에 따라 크게 IaaS, PaaS, SaaS의 세가지로 구분할 수 있다. 

그림 3. 클라우드 서비스 모델 구성도

항목	내용
IaaS (Infrastructure as a Service)	IaaS는 전체 인프라를 구성하는 구성 요소 중 시스템 인프라(Physical/Logical Layer)를 서비스로 제공하는 것으로 서버, 스토리지, 데이터베이스, 네트워크 등 컴퓨팅 환경의 인프라를 제공함. 서버 구축 등 초기비용과 유지비용이 들지 않고 사용한 만큼만 지불하면 되기 때문에 비용과 편리성 측면에서 장점.
PaaS (Platform as a Service)	PaaS는 IaaS에서 제공하는 시스템 인프라 외에 소프트웨어 개발을 위한 개발 환경과 이를 이용한 서비스 환경(Physical/Logical/Platform Layer)을 제공. 사용자는 클라우드 제공업체가 구성한 OS/DBMS/WAS 및 소프트웨어 배포 환경을 이용하여 자신의 어플리케이션을 개발하고 이를 서비스 할 수 있어, 환경 구축에 필요한 비용/시간 등을 절감할 수 있음.
SaaS (Software as a Service)	SaaS는 사용자가 필요로 하는 서비스를 바로 선택하여 사용할 수 있는 Ready-Made된 어플리케이션(전체 Layer)을 제공. 사용자는 서비스 제공업체가 제시하는 서비스 중 필요한 것을 선택하여 설정 후 사용할 수 있는 환경을 제공.

표 4. 클라우드 서비스 모델

클라우드 환경으로 아키텍처 설계 시 IaaS/PaaS 및 SaaS를 선택하는 기준은 특별하게 존재하지 않으며, 또한 하나의 서비스 모델만을 선택하여 적용할 수 도 없다. 즉, 업무 어플리케이션의 경우 IaaS 기반으로 개발하여 구성하고, 일부 업무는 PaaS로, 관리 영역의 서비스는 SaaS로 구성하는 경우도 흔히 발생 할 수 있다.

따라서, 아키텍처 설계 시 이러한 점을 고려하여 클라우드 솔루션 업체가 제공하는 서비스를 사용하는 영역을 사전에 정의하고 이를 기반으로 아키텍처 설계가 수행되어야 한다. 

4. 클라우드 아키텍처 전환 모델

---

일반적으로 기존 고객이 보유하고 있는 업무 어플리케이션 또는 고객의 요구사항을 클라우드 환경으로 전환할 때 수행되는 전환 방식에 따라 아래와 같은 전환 모델이 존재한다. 

항목	내용
Rehost	Rehost는 일반적으로 기존 구성되어있는 환경 중 하드웨어의 교체만을 의미 하드웨어 변경에 따른 어플리케이션/응용 프로그램들에 대한 일부 수정을 제외하고는 기존 어플리케이션에 대한 변경이 거의 없이 새로운 하드웨어 환경으로 이전 구성됨
Replace (Repurchase)	Replace는 기존 구성되어있는 모든 하드웨어/어플리케이션 환경에 대하여 사용자 데이터를 제외하고 클라우드 환경 및 클라우드 솔루션으로 대체하는 것을 의미 기존 어플리케이션/응용 프로그램과 동일한 기능을 제공하는 클라우드 솔루션 또는 상용 패키지를 적극적으로 이용
Refactor	Refactor는 Rehost와 Replace의 중간의 개념이며, 업무 요건을 만족하기 위하여 필요한 솔루션(DBMS/Middleware 등)에 대하여 클라우드 솔루션을 적극적으로 활용하는 것을 의미 기존 어플리케이션 개발을 위한 개발 언어/Framework 등은 유지할 수 있으나, 클라우드 솔루션에 맞게 어플리케이션 코드 수정 및 사용자 데이터의 Migration/Conversion 등이 필수 코드 변경 정도에 따라 Revise(일부 개정) 또는 Rebuild(전면 재개발)로 구분할 수 있음

표 5. 클라우드 전환 모델 3가지

이러한 전환 모델 중 특정 현장에 적용 할 모델을 결정하는 것은 고객의 요구사항과 AS-IS 인프라 현황, 그리고 향후 비용 등의 항목을 가지고 판단하여야 하며, 이는 고객과의 인터뷰를 통하여 최종 결정하는 것이 바람직하다. 그러나, 위 모델 중 특정한 하나의 모델만 적용 가능한 것은 아니며, 구성요소 별로 여러 모델의 조합을 통하여 하나의 시스템 인프라가 구성된다 할 수 있다. 

5. 설계 시 고려사항

5.1. Amazon AWS설계 원칙

본 가이드가 기초하고 있는 Amazon Web Service(이하 AWS)는 Amazon이 그들의 AWS를 다수의 고객에게 클라우드 서비스를 제공하면서 축적한 경험을 기반으로 AWS Well-Architected Framework를 정의하고 있다. 해당 Framework은 보안/안정성/성능 효율성과 비용 최적화의 네가지 기반을 바탕으로 하며, 각각에 대한 세부 내용은 아래와 같다. 

기반 이름	내용
보안	위험평가 및 완화 전략을 통해 정보, 시스템 및 자산을 보호하는 동시에 비즈니스 가치를 제공하는 능력
안정성	인프라 또는 서비스 장애를 복구하고, 수요에 따라 컴퓨팅 리소스를 탄력적으로 확보하고, 구성 오류나 일시적 네트워크 문제 같은 중단 사태를 완화할 수 있는 시스템의 능력
성능 효율성	컴퓨팅 리소스를 시스템 요구 사항에 맞게 효율적으로 사용하고, 수요 변화 및 기술 진화에 맞게 그러한 효율성을 유지하는 능력
비용 최적화	불필요한 비용 또는 최선이 아닌 리소스 사용을 피하거나 제거하는 능력

표 6. 아마존 AWS 설계 원칙

또한 Well-Architected Framwork은 다음과 같은 아키텍처 설계 시 필요한 설계 원칙을 제시 하고 있다.

설계 원칙	내용
필요 용량에 대한 추측 중단	필요한 인프라 용량을 추측할 필요 없이, 필요한 만큼의 리소스 용량을 많이 또는 적게 사용하도록 구성하고, 운영 상황에 맞게 자동으로 확장/축소할 수 있음.
운영환경 규모의 테스트 시스템	클라우드 기반의 아키텍처에서는 On-Demend 방식으로 중복된 환경을 구성하고 테스트 수행이 가능하며, 테스트 수행 완료 후 해당 리소스를 폐기할 수 있음.
아키텍처 변경에 따르는 위험 감소	On-Premise 환경에서 구성이 어려운 운영환경과 동일한 규모의 테스트 환경 구성이 가능하며, On-Demend 방식으로 다수의 테스트 환경 구성이 가능하여 테스트 직렬화 등을 해소할 수 있음.
아키텍처 실험을 간편하게 할 수 있는 자동화	자동화를 통하여 수작업 없이 시스템 환경을 구성하고, 복제할 수 있으며, 자동화 과정의 변경 사항 추척, 감사 및 환경 복구 등이 가능함.
아키텍처의 지속적인 혁신	지속적으로 변화하는 비즈니스 요구 사항을 IT 인프라가 신속하게 대응할 수 있도록 On-Demend 방식의 자동화/테스트 기능이 있으며, 이를 이용하여 아키텍처 설계 변경에 따르는 위험을 사전에 테스트/제거 할 수 있음.

표 7. 아마존 Well-Architectured Framework설계 원칙

해당 내용은 특정 클라우드 솔루션 기반의 설계 이외에도 일반적인 클라우드 환경에서 아키텍처를 설계할 때 기준이 되는 내용이라 할 수 있다. 

5.2. 클라우드 아키텍처 설계 시 고려사항

클라우드 아키텍처 설계는 각 현장의 요구사항을 앞서 설명한 클라우드 솔루션 업체가 제시한 아키텍처 Framework과 설계 원칙을 기반으로 아키텍처를 설계한다. 하지만, 클라우드 솔루션 업체가 제시하는 아키텍처 Framework/설계 원칙의 경우 현장의 요구사항을 반영하기에는 일반적인 내용이라 할 수 있다. 
따라서, 위의 내용을 기반으로 실제 고객의 요구사항을 만족할 수 있는 아키텍처 설계 시 고려하여야 할 내용을 정리하면 다음과 같다. 

설계 시 고려사항	내용
서비스 설계 우선	기존 어플리케이션들이 클라우드 환경으로 전환 또는 신규 개발 시 개별 Service들의 연계 방안과 데이터베이스에 대한 분산 설계 등 서비스 설계를 우선적으로 수행하여야 함.
데이터 흐름 기반	On-Premise환경에서도 동일하지만, 클라우드 환경하에서는 데이터 흐름을 사전에 파악하고 이를 이용한 아키텍처 구성이 필수임. 아키텍처 구성 전 시스템을 사용하는 사용자를 내부/외부 사용자로 구분하고, 각 사용자별로 시스템 접점으로부터 최종 데이터까지의 데이터 흐름을 사전에 정의하고, 이를 기반으로 고가용성/분산 등을 고려하여 아키텍처 구성요소를 설계함.
분산 데이터베이스	하나의 데이터베이스 서버가 보유할 수 있는 리소스(CPU/Memory 등)에 한계가 존재하고, 흔히 사용하는 DBMS 솔루션(ex.Oracle)과 같이 Write I/O에 대한 다중 노드에서의 동시 처리가 불가하므로, 이를 고려하여 데이터베이스 서버와 데이터베이스 인스턴스를 설계함.
업무 간 인터페이스	클라우드 환경 하에 구성된 업무 서버들의 수가 증가하거나 축소될 수 있으며, 이로 인하여 인터페이스 대상 서버들의 수도 함께 증가/축소될 수 있음. 따라서, 직접 인터페이스 방식이 아닌 Queue 또는 API 방식을 이용하며, 이를 이용하여 각 업무 어플리케이션 간 인터페이스는 Loose하게 연결하도록 설계.
제도/법	국내 제도/법에 의하여 반드시 각 사용자가 보유하고 있는 센터/서버에 환경을 구성하여야 하는 인프라 환경이 존재함. 따라서, 클라우드 환경으로 기존 환경의 이전 구축 또는 신규 구축 시 해당 제도/법에 근거하여 클라우드 환경에 구축할 수 있는 인프라 환경을 구분하여야 함.
솔루션 업체 서비스 이용	클라우드 솔루션에서 제공하는 서비스는 일정 수준 이상의 가용성을 제공하도록 구성되어있어, 최대한 이러한 서비스를 이용하여 아키텍처 구성. 고객의 요구사항을 분석하여 클라우드 솔루션 업체가 제공하는 서비스 중 이용 가능한 범위를 명확화 함.
보안 설계	클라우드 환경은 기본적으로 인터넷에 공개된 환경으로 불특정 다수의 사용자가 접근 가능함. 따라서, On-Premise 환경에서 네트워크 기반의 보안 설계를 좀 더 확장하여, 모든 사용자를 역할로 구분하고 각 역할별로 수행 가능한 행위들을 사전에 정의하고 이를 바탕으로 아키텍처 설계가 수행되어야 함.
리소스 용량 산정	초기 구축한 시스템의 용량 확장 절차가 길게 소요되는 On-Premise와 다르게 용량 확장이 신속하게 수행되고 사용량으로 비용이 청구되는 클라우드 환경 특성 상, 개별 리소스(서버 등)에 대한 용량 산정은 초기 On-Premise와 동일하게 수행하며, 향후 통합테스트/성능테스트 시 해댱 용량에 대한 검증 및 비용에 대한 산정을 수행.
수평적 용량 확장	동일 기능을 수행하는 서버의 수를 운영 중 동적으로 확장/축소가 가능하므로, 이를 기반으로 서버의 용량산정 및 부하 분산을 고려하여 설계함. 내부 자원을 증설하여 용량을 확장하는 수직적 확장은 대상 리소스가 수행중인 업무/서비스를 정지 후 가능하여, 가급적 지양함.
고정된 사용량 기반	CPU사용율/네트워크 사용율과 같이 업무 증감에 따라 변경이 잦은 리소스보다는 메모리 사용량과 같이 업무 증감에 민감하지 않은 리소스 사용량을 기반으로 서버 설계.

표 8. 클라우드 환경 아키텍처 설계 시 고려사항