Azure 클라우드 아키텍처 특징
본 장에서는 기존 SI 프로젝트의 대상이 된 On-Premise 환경 대비 클라우드 환경이 가지고 있는 클라우드 환경만의 특징을 사전에 파악하고, 클라우드 환경에서 아키텍처 설계를 위하여 필요한 설계 원칙에 대하여 설명한다.
1 클라우드 환경의 이해
클라우드 환경에 대한 이해를 위하여 가장 먼저 이해하여야 하는 개념은 하나의 리소스(서버, 스토리지와 같은 HW, 어플리케이션과 같은 SW 및 데이터베이스)를 다수의 사용자가 공유하여 사용하는 개념인 멀티 테넌시(Multi-Tenancy)이다.
즉, Private 클라우드를 포함한 클라우드 솔루션 제공업체가 사전에 정의하고 커스터마이징을 수행한 하드웨어 환경/소프트웨어 환경을 해당 클라우드를 사용하고자 하는 사용자가 공유하여 사용하도록 구성한다는 개념이다.
이러한 멀티 테넌시가 하나의 리소스를 다수의 사용자가 공유하여 사용한다면, 싱글 테넌시(Single-Tenancy)는 서비스를 사용하고자 하는 사용자의 요청에 따라 독립된 서버/소프트웨어 및 데이터 환경을 구성하는 개념이라고 할 수 있다.
멀티 테넌시와 싱글 테넌시의 장단점은 아래와 같이 간략하게 정의할 수 있다.
항목 | 장점 | 단점 |
멀티 테넌시 | 다수의 사용자가 하나의 시스템을 공유하여 사용하여, 시스템/어플리케이션 등 수정 시 다수의 사용자가 동시에 같은 효과을 얻을 수 있음. | 장애에 대한 영향이 전체 사용자에게 전이됨. |
싱글 테넌시 | 다수의 사용자에게 각기 다른 서비스 제공 가능. | 특정 정보, 시스템에 대한 오류 수정 시 각 테넌시에게 할당된 자원에 적용 필요. |
이러한 멀티 테넌시 환경은 기본적으로 하드웨어/소프트웨어 가상화(Virtualization)을 이용하여 구성하거나, 하나의 서버/어플리케이션 인스턴스 하에서 사용자 권한에 대한 분리, 접속 포트 등에 대한 분리 등을 이용하여 구성하게 되며, 특히 데이터베이스의 경우 멀리 테넌시를 구성하기 위하여 데이터 보안이 강화된 데이터 아키텍처를 수립하여 구성하게 된다.
2 On-Premise vs. Cloud
미국 기술 표준 연구소(NIST, National Institute of Standards and Technology)는 클라우드 환경에 대하여 아래와 같이 정의하고 있다.
항목 | 내용 |
On-demand Self-Service | 클라우드 서비스는 저장 공간과 프로세싱 용량 등을 사람의 작업 없이 필요에 따라 늘리거나 줄일 수 있어야 함. |
광범위한 네트워크 접근 | 휴대전화, 노트북과 다른 장치들이 웹 브라우저 혹은 어플리케이션 같은 클라이언트를 이용해 서비스에 접근 할 수 있어야 함. |
자원 공유 | 사용자들은 공유된 컴퓨팅 자원들과 데이터 저장 공간을 나누어 사용함. 클라우드 사용자 들은 데이터가 저장될 장소를 정할 수 있지만(데이터가 저장되는 지역별 위치 등), 어플리케이션이나 데이터 저장 공간의 정확한 위치를 알 수 없음. |
빠른 탄력성 | 클라우드 서비스가 쓸 수 있는 저장 공간, 네트워크 대역폭과 컴퓨팅 용량은 거의 실시간으로 증가 또는 감소가 가능하여야 함. 이를 통하여 솔루션이 가장 최적화된 자원 이용율을 확보할 수 있어야 함. |
서비스 측정 | 클라우드 시스템은 처리되는 업무와 자원의 이용을 측정할 수 있어야 함. 더불어 쉽고 명확한 벙법으로 사용 현황을 모니터링, 제어 및 보고할 수 있어야 함. |
이러한 클라우드 환경에 대한 정의는 On-Premise에서도 동일하게 적용될 수 있으나, 클라우드 환경이 가지고 있는 특징 중 On-Premise와 가장 크게 다른 부분은 물리적인 리소스에 대한 제어 권한을 사용자가 갖고 있는지 여부이다.
즉, On-premise 환경의 경우 사용자가 직접 물리적인 환경/리소스를 구매/구성하고 이 환경하에서 사용자의 어플리케이션을 직접 운영하는 환경이었다면, 클라우드 환경은 이 중 물리적인 리소스 및 이에 대한 직접적인 제어는 클라우드 환경 제공자가 수행하고, 사용자는 해당 환경 중 사용하는 리소스의 용량과 사용 시간에 대한 비용을 제공자에게 지불하는 것이라 할 수 있다.
앞서 언급한 특징 이외에 클라우드 환경이 가지고 있는 특징에 대하여 살펴보면 아래와 같다.
항목 | 내용 |
모든 리소스는 프로그래밍 가능한 형태로 존재 | 전통적인 On-Premise 환경과 다르게 클라우드 환경하의 모든 리소스(서버/데이터베이스/스토리지 등)는 프로그래밍 가능한 리소스로 구성되어있음. 다시 말해, On-Premise 환경에서 물리적으로 실체가 존재하는 리소스를 이용하여 환경을 구성하였다면, 클라우드 환경에서는 앞서 언급한 모든 리소스들이 논리적인 형태로 존재하고, 이를 이용하여 환경을 구성함. 해당 리소스는 관리화면을 이용하여 생성/구성이 가능하고, 또한 각 리소스 별 설정 가능한 파라미터를 이용하여 용량의 증설/축소/생성/폐기 및 기타 다양한 설정을 변경할 수 있다. |
글로벌한, 가용한, 무제한 용량 | On-Premise 환경은 초기 설계된 용량과 제한된 위치(센터 등)에서만 사용 가능한 리소스들이 클라우드 환경에서는 좀 더 유연하게 확장된 형태로 구성가능함. 즉, 최종 사용자의 위치에 따라 가장 적합한 지역을 판단하고 해당 지역에 인프라 환경을 구성할 수 있으며, 각 지역에 구성된 인프라 환경 간의 자유로운 어플리케이션/데이터의 공유가 가능하여 하나의 지역에 발생한 장애에도 유연하게 대응 가능함. 그리고, 각 환경을 구성하는 자원은 사용자/업무 증감에 따라 자유롭게 수평적 또는 수직적으로 확장/축소할 수 있음. |
높은 수준의 관리 서비스 | 클라우드 환경에서의 모든 리소스는 앞서 설명한 바와 같이 논리적인 형태로 존재하며, 이 리소스들은 클라우드 솔루션 업체(ex. Amazon)의 관리하에 존재함. 즉, 사용자는 해당 리소스에 대한 모니터링/관리 등을 위하여 요구되는 솔루션/인력 비용을 절감할 수 있음. |
보안 기능 내장 | 하나의 물리 서버에 불특정 다수가 사용하는 다수의 가상 환경을 구성할 수 있는 클라우드 특성 상 보안 관련 기능이 강화되어있으며 기본 서비스로 제공함. 이러한 보안 기능은 앞서 설명한 바와 같이 관리자가 설정 가능한 파라미터 형태로 존재하며, 해당 기능을 이용하여 보안 관련 솔루션/인력에 투자되는 비용을 절감할 수 있음. |
표 1. 클라우드 환경 특징
클라우드 환경 하에서 인프라 아키텍처를 설계하는 방안은 기존 On-Premise 환경에서의 설계와 동일한 절차를 갖는다. 하지만 위에서 언급한 클라우드 환경의 특징으로 인하여 On-Premise와는 세부적인 구성이 달라 질 수 있음을 인지하여야 한다.
3 클라우드 아키텍처 구조
클라우드 솔루션 업체에서 제공하는 클라우드 환경은 네가지 Layer로 구분할 수 있으며, 해당 Layer 구분에서 어느 Layer까지 사용자가 클라우드 솔루션 업체로부터 서비스를 제공받는지에 따라 클라우드 서비스 모델이 결정된다고 할 수 있다.
항목 | 내용 |
Physical Layer | 물리적인 서버/스토리지/네트워크 등과 이러한 시스템 인프라가 존재하는 IDC 등 데이터 센터. |
Logical Layer | 물리적인 시스템 인프라를 서비스를 이용하고자 하는 사용자에게 할당할 수 있도록 논리적으로 분리하여 구성한 상태. |
Platform Layer | 논리적으로 분리된 시스템 인프라 위에 WAS/DBMS와 같이 사용자가 개발한 어플리케이션을 실행할 수 있는 주요 엔진 등을 포함. 또한 클라우드 솔루션 업체가 제공하는 이러한 주요 서비스를 사용하기 위하여 개발에 필요한 SDK/Runtime등을 포함. |
Service Layer | 클라우드 솔루션 업체가 제공하는 Ready-Made된 어플리케이션으로 사용자가 요구하는 기능이 구현된 어플리케이션을 사용자가 직접 설정을 통하여 사용하도록 구성한 상태. IaaS/PaaS 사용 시 제공되는 관리 환경과 보안 환경을 포함함. |
표 2. 클라우드 환경 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와 크게 다르지 않음을 알 수 있다.
4 클라우드 서비스 모델
클라우드 솔루션 업체가 제공하는 클라우드 서비스 모델은 앞서 설명한 클라우드 아키텍처 중 클라우드 제공자의 관리 영역에 따라 크게 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)을 제공. 사용자는 서비스 제공업체가 제시하는 서비스 중 필요한 것을 선택하여 설정 후 사용할 수 있는 환경을 제공. |
표 3. 클라우드 서비스 모델
클라우드 환경으로 아키텍처 설계 시 IaaS/PaaS 및 SaaS를 선택하는 기준은 특별하게 존재하지 않으며, 또한 하나의 서비스 모델만을 선택하여 적용할 수 도 없다. 즉, 업무 어플리케이션의 경우 IaaS 기반으로 개발하여 구성하고, 일부 업무는 PaaS로, 관리 영역의 서비스는 SaaS로 구성하는 경우도 흔히 발생 할 수 있다.
따라서, 아키텍처 설계 시 이러한 점을 고려하여 클라우드 솔루션 업체가 제공하는 서비스를 사용하는 영역을 사전에 정의하고 이를 기반으로 아키텍처 설계가 수행되어야 한다.
5 클라우드 아키텍처 전환 모델
일반적으로 기존 고객이 보유하고 있는 업무 어플리케이션 또는 고객의 요구사항을 클라우드 환경으로 전환할 때 수행되는 전환 방식에 따라 아래와 같은 전환 모델이 존재한다.
항목 | 내용 |
Rehost | Rehost는 일반적으로 기존 구성되어있는 환경 중 하드웨어의 교체만을 의미 하드웨어 변경에 따른 어플리케이션/응용 프로그램들에 대한 일부 수정을 제외하고는 기존 어플리케이션에 대한 변경이 거의 없이 새로운 하드웨어 환경으로 이전 구성됨 |
Replatform | Replatform은 Rehost의 확장된 개념으로 Rehost가 기존 보유한 소프트웨어 환경과 해당 라이선스를 적극적으로 재활용하는 개념이라면, Replatform은 클라우드에 적합한 소프트웨어로 변경하여 구성하는 것을 의미 변경되는 소프트웨어는 On-premise환경과 동일하게 사용자가 직접 설치하여 구성하거나, 클라우드 솔루션에서 제공하는 Managed Service를 활용하여 구성할 수 있음 또한 이로 인하여 어플리케이션 코드 수정/사용자 데이터 Migration등은 필수적으로 수행되어야 함 |
Refactor | Refactor는 업무 요건을 만족하기 위하여 필요한 솔루션 (DBMS/Middleware 등)에 대하여 클라우드 솔루션에서 제공하는 Managed Service를 적극적으로 활용하는 것을 의미 기존 어플리케이션 개발을 위한 개발 언어/Framework 등은 유지할 수 있으나, 클라우드 솔루션에 맞게 어플리케이션 코드 수정 및 사용자 데이터의 Migration/Conversion 등이 필수 코드 변경 정도에 따라 Revise(일부 개정) 또는 Rebuild(전면 재개발)로 구분할 수 있음 |
표 4. 클라우드 전환 모델 3가지
이러한 전환 모델 중 특정 현장에 적용 할 모델을 결정하는 것은 고객의 요구사항과 AS-IS 인프라 현황, 그리고 향후 비용 등의 항목을 가지고 판단하여야 하며, 이는 고객과의 인터뷰를 통하여 최종 결정하는 것이 바람직하다. 그러나, 위 모델 중 특정한 하나의 모델만 적용 가능한 것은 아니며, 구성요소 별로 여러 모델의 조합을 통하여 하나의 시스템 인프라가 구성된다 할 수 있다.
6 설계 시 고려사항
6.1 Amazon AWS설계 원칙
Amazon Web Service(이하 AWS)는 Amazon이 그들의 AWS를 다수의 고객에게 클라우드 서비스를 제공하면서 축적한 경험을 기반으로 AWS Well-Architected Framework를 정의하고 있다. 해당 Framework은 보안/안정성/성능 효율성과 비용 최적화의 네가지 기반을 바탕으로 하며, 각각에 대한 세부 내용은 아래와 같다.
기반 이름 | 내용 |
보안 | 위험평가 및 완화 전략을 통해 정보, 시스템 및 자산을 보호하는 동시에 비즈니스 가치를 제공하는 능력 |
안정성 | 인프라 또는 서비스 장애를 복구하고, 수요에 따라 컴퓨팅 리소스를 탄력적으로 확보하고, 구성 오류나 일시적 네트워크 문제 같은 중단 사태를 완화할 수 있는 시스템의 능력 |
성능 효율성 | 컴퓨팅 리소스를 시스템 요구 사항에 맞게 효율적으로 사용하고, 수요 변화 및 기술 진화에 맞게 그러한 효율성을 유지하는 능력 |
비용 최적화 | 불필요한 비용 또는 최선이 아닌 리소스 사용을 피하거나 제거하는 능력 |
표 5. 아마존 AWS 설계 원칙
또한 Well-Architected Framwork은 다음과 같은 아키텍처 설계 시 필요한 설계 원칙을 제시 하고 있다.
설계 원칙 | 내용 |
필요 용량에 대한 추측 중단 | 필요한 인프라 용량을 추측할 필요 없이, 필요한 만큼의 리소스 용량을 많이 또는 적게 사용하도록 구성하고, 운영 상황에 맞게 자동으로 확장/축소할 수 있음. |
운영환경 규모의 테스트 시스템 | 클라우드 기반의 아키텍처에서는 On-Demend 방식으로 중복된 환경을 구성하고 테스트 수행이 가능하며, 테스트 수행 완료 후 해당 리소스를 폐기할 수 있음. |
아키텍처 변경에 따르는 위험 감소 | On-Premise 환경에서 구성이 어려운 운영환경과 동일한 규모의 테스트 환경 구성이 가능하며, On-Demend 방식으로 다수의 테스트 환경 구성이 가능하여 테스트 직렬화 등을 해소할 수 있음. |
아키텍처 실험을 간편하게 할 수 있는 자동화 | 자동화를 통하여 수작업 없이 시스템 환경을 구성하고, 복제할 수 있으며, 자동화 과정의 변경 사항 추척, 감사 및 환경 복구 등이 가능함. |
아키텍처의 지속적인 혁신 | 지속적으로 변화하는 비즈니스 요구 사항을 IT 인프라가 신속하게 대응할 수 있도록 On-Demend 방식의 자동화/테스트 기능이 있으며, 이를 이용하여 아키텍처 설계 변경에 따르는 위험을 사전에 테스트/제거 할 수 있음. |
표 6. 아마존 Well-Architectured Framework설계 원칙
6.2 Microsoft Azure 설계 원칙
Azure 솔루션을 제공하는 Microsoft에서는 AWS와 마찬가지로 자신의 클라우드 환경 하에서 아키텍처를 설계하기 위하여 고려하여야 하는 설계 기반과 설계 원칙을 제시하고 있으며, 이를 통하여 클라우드 환경이 가지고 있는 확장성, 신속성 및 관리 용이성을 극대화 하고자 한다.
기반 이름 | 내용 |
확장성 | 예상치 못한 업무 증가에 대응할 수 있는 아키텍처 구성. |
가용성 | 업무 서비스가 정상적으로 수행되는 시간의 비율. |
탄력성 | 발생한 장애로부터 신속하게 복구하여 업무를 정상적으로 처리할 수 있는 아키텍처의 능력. |
관리 | 아키텍처 환경 내에서 수행되는 어플리케이션이 정상적으로 수행될 수 있도록 유지/관리하는 능력. |
보안 | 설계/구현 및 운영에 이르는 전체 어플리케이션 Lifecycle에 걸친 보안. |
설계 원칙 | 내용 |
장애에 대한 자동조치 | 분산 환경을 구성하고 있는 모든 구성요소에 예상치 못한 장애가 발생할 경우 이를 자동으로 조치할 수 있도록 구성하여야 함. |
모든 구성요소의 다중화 | 업무 요청 또는 데이터 흐름이 되는 모든 구간에 대하여 SPoF를 제거하여야 함. |
시스템 확장을 고려한 어플리케이션 설계 | 시스템에 대한 수평적 확장이 자유롭게 수행될 수 있도록 어플리케이션과 데이터베이스에 대한 설계를 수행하여야 함. |
수평적 확장 고려 | 아키텍처를 구성하는 구성요소에 대하여 업무 요건/처리량에 따라 추가/삭제가 가능한 Scale-out이 가능하여야 함. |
작은 단위로의 파티셔닝 | 데이터베이스를 포함하여 서버, 네트워크 등 모든 구성요소에 대하여 업무 요청을 다수의 시스템이 분산하여 처리가 가능하도록 설계하여야 함. |
운영에 대한 고려 | 클라우드 환경 하에서 구성된 아키텍처에 대하여 모든 것을 모니터링하고 이에 대한 감사/추적이 가능하도록 설계하여야 함. |
Managed services 사용 | 클라우드 솔루션 제공업체에서 제공하는 클라우드 관련 서비스를 사용하여, 아키텍처를 자동화하고 이를 관리하기 위하여 투입되는 비용을 절감할 수 있도록 설계하여야 함. |
업무 성격에 맞는 데이터 저장소 | 업무 성격 또는 업무 서비스가 사용하는 데이터의 성격에 맞는 데이터 저장 방식/데이터 처리 엔진을 선택하여 설계하여야 함. |
업무요건에 대한 신속한 반영 고려 | 업무 요구사항에 대한 변경 또는 진화를 신속하게 반영할 수 있는 어플리케이션 및 시스템 아키텍처 설계를 수행하여야 함. |
업무 요구사항을 반영한 아키텍처 | 모든 설계의 기본은 업무 요구사항을 만족하는 것이며, 이를 위하여 업무 요구사항에 대한 명확화, Workload에 대한 분석, 성장율 등에 대한 분석 결과를 반영한 설계를 수행하여야 함. |
6.3 클라우드 아키텍처 설계 시 고려사항
클라우드 아키텍처 설계는 각 현장의 요구사항을 앞서 설명한 클라우드 솔루션 업체가 제시한 아키텍처 Framework과 설계 원칙을 기반으로 아키텍처를 설계한다. 하지만, 클라우드 솔루션 업체가 제시하는 아키텍처 Framework/설계 원칙의 경우 현장의 요구사항을 반영하기에는 일반적인 내용이라 할 수 있다.
따라서, 위의 내용을 기반으로 실제 고객의 요구사항을 만족할 수 있는 아키텍처 설계 시 고려하여야 할 내용을 정리하면 다음과 같으며, 그 외에 상세한 아키텍처 설계 시 고려사항은 [3. 통합 아키텍처 설계]에서 기술한다.
설계 시 고려사항 | 내용 |
서비스 설계 우선 | 기존 어플리케이션들이 클라우드 환경으로 전환 또는 신규 개발 시 개별 Service들의 연계 방안과 데이터베이스에 대한 분산 설계 등 서비스 설계를 우선적으로 수행하여야 함. |
데이터 흐름 기반 | On-Premise환경에서도 동일하지만, 클라우드 환경하에서는 데이터 흐름을 사전에 파악하고 이를 이용한 아키텍처 구성이 필수임. 아키텍처 구성 전 시스템을 사용하는 사용자를 내부/외부 사용자로 구분하고, 각 사용자별로 시스템 접점으로부터 최종 데이터까지의 데이터 흐름을 사전에 정의하고, 이를 기반으로 고가용성/분산 등을 고려하여 아키텍처 구성요소를 설계함. |
분산 데이터베이스 | 하나의 데이터베이스 서버가 보유할 수 있는 리소스(CPU/Memory 등)에 한계가 존재하고, 흔히 사용하는 DBMS 솔루션(ex.Oracle)과 같이 Write I/O에 대한 다중 노드에서의 동시 처리가 불가하므로, 이를 고려하여 데이터베이스 서버와 데이터베이스 인스턴스를 설계함. |
업무 간 인터페이스 | 클라우드 환경 하에 구성된 업무 서버들의 수가 증가하거나 축소될 수 있으며, 이로 인하여 인터페이스 대상 서버들의 수도 함께 증가/축소될 수 있음. 따라서, 직접 인터페이스 방식이 아닌 Queue 또는 API 방식을 이용하며, 이를 이용하여 각 업무 어플리케이션 간 인터페이스는 Loose하게 연결하도록 설계. |
제도/법 | 국내 제도/법에 의하여 반드시 각 사용자가 보유하고 있는 센터/서버에 환경을 구성하여야 하는 인프라 환경이 존재함. 따라서, 클라우드 환경으로 기존 환경의 이전 구축 또는 신규 구축 시 해당 제도/법에 근거하여 클라우드 환경에 구축할 수 있는 인프라 환경을 구분하여야 함. |
솔루션 업체 서비스 이용 | 클라우드 솔루션에서 제공하는 서비스는 일정 수준 이상의 가용성을 제공하도록 구성되어있어, 최대한 이러한 서비스를 이용하여 아키텍처 구성. 고객의 요구사항을 분석하여 클라우드 솔루션 업체가 제공하는 서비스 중 이용 가능한 범위를 명확화 함. |
보안 설계 | 클라우드 환경은 기본적으로 인터넷에 공개된 환경으로 불특정 다수의 사용자가 접근 가능함. 따라서, On-Premise 환경에서 네트워크 기반의 보안 설계를 좀 더 확장하여, 모든 사용자를 역할로 구분하고 각 역할별로 수행 가능한 행위들을 사전에 정의하고 이를 바탕으로 아키텍처 설계가 수행되어야 함. |
리소스 용량 산정 | 초기 구축한 시스템의 용량 확장 절차가 길게 소요되는 On-Premise와 다르게 용량 확장이 신속하게 수행되고 사용량으로 비용이 청구되는 클라우드 환경 특성 상, 개별 리소스(서버 등)에 대한 용량 산정은 초기 On-Premise와 동일하게 수행하며, 향후 통합테스트/성능테스트 시 해댱 용량에 대한 검증 및 비용에 대한 산정을 수행. |
수평적 용량 확장 | 동일 기능을 수행하는 서버의 수를 운영 중 동적으로 확장/축소가 가능하므로, 이를 기반으로 서버의 용량산정 및 부하 분산을 고려하여 설계함. 내부 자원을 증설하여 용량을 확장하는 수직적 확장은 대상 리소스가 수행중인 업무/서비스를 정지 후 가능하여, 가급적 지양함. |
고정된 사용량 기반 | CPU사용율/네트워크 사용율과 같이 업무 증감에 따라 변경이 잦은 리소스보다는 메모리 사용량과 같이 업무 증감에 민감하지 않은 리소스 사용량을 기반으로 서버 설계. |
표 7. 클라우드 환경 아키텍처 설계 시 고려사항
댓글
댓글 쓰기