클라우드 아키텍처란 무엇일까요?
클라우드 컴퓨팅은 지난 20년 동안 빠르게 성장해 왔으며 계속해서 놀라운 속도로 확장되고 있습니다. 기본적인 SaaS(Software as a Service)와IaaS(Infrastructrue as a Service) 제품에서 시작한 것이 서버부터 쿠버네티스 클러스터까지 모든 것을 위한 방대한 클라우드 기반의 솔루션 생태계로 발전했습니다.
이번 문서에서는 클라우드 아키텍처 (또는 클라우드 컴퓨팅 아키텍처)와 관련하여 클라우드 아키텍처를 구성하는 구성요소, 다양한 클라우드 컴퓨팅 모델, 클라우드의 장점, 온프레미스 앱을 클라우드로 전환하는 방법과 정보에 입각한 결정을 내리는 방법 등을 집중적으로 알아보겠습니다.
클라우드 아키텍처란 무엇일까요?
그렇다면 클라우드 아키텍처란 무엇일까요? 또한 클라우드 컴퓨팅 아키텍처란 무엇일까요? 클라우드 아키텍처와 클라우드 컴퓨팅 아키텍처의 뜻은 동일합니다. 두 용어 모두 클라우드 컴퓨팅 환경의 인프라 구성요소에 대한 설계를 정의하는 ‘청사진’을 뜻합니다.
클라우드 아키텍처를 개념화하는 방법에는 여러 가지가 있습니다. 예를 들어 클라우드 서비스 사업자의 관점에서 클라우드 아키텍처는 다음과 같이 구성됩니다.
- 하드웨어 레이어: 베어 메탈 서버, 네트워킹 장비 및 스토리지 디바이스가 포함됩니다.
- 가상화 레이어: 물리적 리소스를 가상화하기 위한 하이퍼바이저와 SDN(Software-Defined Networking)이 포함됩니다.
- 서비스 레이어: 공급업체가 사용자에게 제공하는 클라우드 리소스가 포함됩니다.
개발자와 DevOps 엔지니어 같은 사용자가 생각하는 클라우드 아키텍처 구성요소에는 다음이 포함됩니다.
- 프런트 엔드:클라우드 서비스에 접속할 수 있도록 하는 웹 콘솔, API(Application Programming Interface), CLI(Command-Line Interface), 모바일 앱 또는 기타 클라이언트를 말합니다.
- 백엔드: 서비스를 가능하게 하는 컴퓨팅, 스토리지, 소프트웨어 리소스를 제공합니다.
- 네트워크: DNS 레졸루션과 같이 클라우드 리소스와 서비스 간의 연결을 제공합니다.
클라우드 환경 아키텍처의 역할은 모든 구성요소가 서로 연계되고 통신하는 방식을 지정하는 것입니다. 그림 1에서 클라우드 기반 문서 관리 시스템의 아키텍처를 확인할 수 있습니다.
이러한 구성요소를 설계하고, 구축하고, 사용자에게 제공하는(또는 추상화하는) 정확한 방법은 클라우드 제공 모델과 클라우드 컴퓨팅의 종류에 따라 달라집니다. 예를 들어 프라이빗 클라우드의 가상 머신 에서 실행되는 웹 앱의 아키텍처는 분산된 쿠버네티스 기반 애플리케이션과 다릅니다.
모든 클라우드 구축에 있어 동일한 점은 클라우드가 사용자에게 어느 정도 복잡성을 줄여주는 플랫폼 이라는 점입니다. 예를 들어 AWS(Amazon Web Services) EC2 인스턴스와 같은 IaaS 제품은 하드웨어 복잡성을 추상화합니다. Google Docs와 같은 SaaS 앱은 더욱 고도의 추상화가 가능하며 운영 체제, 미들웨어, 애플리케이션 유지 관리를 포함한 모든 것이 사용자로부터 숨겨집니다.
클라우드 인프라의 주요 물리적 구성요소
클라우드 컴퓨팅은 추상화 레이어 아래에 온프레미스 IT 인프라와 마찬가지로 세 가지 기본 레이어가 있습니다.
- 컴퓨팅 CPU, RAM, GPU 리소스
- 네트워킹 네트워크 인터페이스 같은 리소스
- 스토리지 SSD 및 HDD 같은 리소스
IaaS와 같은 모델에서는 이러한 범주의 리소스 사용량을 기준으로 요금이 청구되는 경우가 많습니다.
참고: 클라우드 아키텍처와 네트워크 아키텍처를 혼동하면 안 됩니다. 클라우드 아키텍처 에는 관련 네트워크 아키텍처가 포함되어 있습니다. 예를 들어 기업 환경의 클라우드 아키텍처에는 SD-WAN, SDN, DNS 서비스가 모두 포함될 수 있습니다.
기본 클라우드 배포 모델: 퍼블릭 클라우드와 프라이빗 클라우드
사용자에게 제공되는 두 가지 기본 클라우드 서비스 모델은 퍼블릭 클라우드 와 프라이빗 클라우드입니다(표 1). 퍼블릭 클라우드 플랫폼은 일반 대중이 사용할 수 있으며, 인프라는 클라우드 서비스 사업자가 관리합니다. 프라이빗 클라우드 플랫폼은 단일 기업 전용입니다.
퍼블릭 클라우드와 프라이빗 클라우드는 단순성(퍼블릭 클라우드)과 제어(프라이빗 클라우드)의 측면에서 장단점이 있습니다. 퍼블릭 클라우드 사용자는 서비스를 소비하기만 하면 되고, 서비스 공급업체가 유지 관리와 인프라 프로비저닝을 처리합니다. 하지만 이 때문에 퍼블릭 클라우드 사용자는 본질적으로 서비스 공급업체가 제공하는 기능에 제한을 받습니다. 또한 퍼블릭 클라우드 데이터는 서비스 공급업체의 데이터 센터에 상주하므로 컴플라이언스와 데이터 주권에 영향을 줍니다.
반대로 프라이빗 클라우드 사용자는 인프라와 기능을 완전히 제어할 수 있습니다. 단점은 사용자 또는 사용자를 대신하는 써드파티가 인프라 유지 관리, 설정, 패치의 복잡한 작업을 처리해야 한다는 점입니다.
프라이빗 클라우드가 퍼블릭 클라우드보다 안전할까요?
일반적으로 프라이빗 클라우드는 퍼블릭 클라우드에 비해 두 가지 보안 장점이 있습니다.
- 프라이빗 클라우드는 단일 기업 전용으로 사용됩니다.
- 프라이빗 클라우드는 일반적으로 공용 인터넷을 통해 직접 접속할 수 없습니다.
따라서 프라이빗 클라우드가 퍼블릭 클라우드보다 더 안전하다는 주장을 종종 볼 수 있습니다. 이론적으로 프라이빗 클라우드를 유지 관리하는 기업이 설정과 유지 관리에 보안 모범 사례 를 적용한다면 이것이 합리적인 이야기일 것입니다. 더불어 프라이빗 클라우드의 격리는 보안상의 장점이 있습니다.
그러나 많은 기업은 대규모 클라우드 공급업체와 동일한 수준으로 인프라를 강화하고, 패치하고, 검사하고, 관리할 수 있는 사내 보안 전문 지식과 리소스가 부족합니다. 프라이빗 클라우드에 패치가 적용되지 않거나 부적절하게 설정되면 퍼블릭 클라우드보다 더 안전하지 않을 수 있으므로, 기업은 리스크를 평가할 때이를 고려해야 합니다.
고급 클라우드 배포 모델 - 하이브리드 클라우드와 프라이빗 클라우드
퍼블릭 클라우드와 프라이빗 클라우드 외에도 여러 가지 다양한 클라우드 배포 모델이 있습니다. 예를 들어 미국 국립표준기술연구소의 정의에 따르면 커뮤니티 클라우드 는 ‘우려 사항을 공유하는 기업의 특정 소비자 커뮤니티가 독점적으로 사용하도록 제공되는 클라우드 인프라’입니다. 그러나 가장 일반적인 두 가지 고급 클라우드 아키텍처 배포 모델은 다음과 같습니다.
하이브리드 클라우드: 기업 내 여러 클라우드 배포 모델의 조합입니다. 예를 들어 퍼블릭 클라우드와 프라이빗 클라우드에 데이터베이스를 복제하는 팀은 하이브리드 클라우드 모델을 사용합니다.
멀티클라우드: 기업 내에서 여러 개의 서로 다른 퍼블릭 클라우드 공급업체를 사용하는 것입니다. 예를 들어 AKS(Azure Kubernetes Service)와 Amazon EKS(Elastic Kubernetes Service)에서 클러스터를 실행하는 비즈니스는 멀티클라우드 모델을 사용하고 있습니다.
XaaS: 클라우드 컴퓨팅의 종류
다양한 배포 모델 외에 다양한 클라우드 컴퓨팅 서비스 모델도 있습니다. 이러한 모델을 통상적으로 XaaS(‘Anything as a Service’)라고 합니다. XaaS 모델에서는 공급업체가 사용자에게 구독 기반 요금제로 클라우드 컴퓨팅 서비스를 제공하는 경우가 많습니다.
가장 일반적인 세 가지 XaaS 서비스 모델은 SaaS, PaaS(Platform as a Service ), IaaS입니다(그림 2).
이 세 가지 클라우드 컴퓨팅 서비스 모델은 서비스 공급업체와 사용자가 담당하는 부분에서 차이점이 있습니다. 표 2는 모델별로 클라우드 인프라의 다양한 측면을 제어하는 주체에 대해 자세히 설명합니다.
IaaS 플랫폼은 사용자에게 가장 많은 제어 권한을 제공하며 관리와 유지 관리가 가장 복잡합니다. 사용자는 운영 체제 선택부터 패치 적용까지 모든 작업을 담당합니다. 반면에 Google Docs와 Slack 같은 SaaS 플랫폼은 애플리케이션 레이어를 제외한 모든 것을 추상화합니다.
PaaS 플랫폼은 중간 형태로서, 사용자에게 애플리케이션 및 데이터 레이어를 제어할 수 있는 권한을 부여합니다. 예를 들어 PaaS 플랫폼에서 사용자는 MySQL 데이터베이스에 직접 접속할 수 있지만 기본 MySQL 버전이나 운영 체제에 대한 패치는 처리하지 않습니다.
IaaS, PaaS, SaaS를 넘어서
IaaS, PaaS, SaaS는 클라우드 서비스 모델의 시작에 불과합니다. 지난 10년 동안 다양한 사용 사례를 포괄하는 새로운 클라우드 서비스 제품이 폭발적으로 증가했습니다.
이에 다음과 같은 새로운 클라우드 서비스 모델들을 알아두시는 것이 좋습니다.
- AaaS(Authentication as a Service) 플랫폼은 Okta와 Duo처럼 MFA(Multi-Factor Authentication)와 SSO(Single Sign-On) 등의 서비스를 제공합니다.
- DaaS(Desktop as a Service) 플랫폼은 Amazon Workspaces와 Azure Virtual Desktop처럼 클라우드에서 매니지드 가상 데스크톱을 제공합니다.
- CaaS(Containers as a Service) 플랫폼은 Google Cloud Run와 Microsoft ACI(Azure Container Instance)처럼 클라우드 플랫폼에서 컨테이너화된 앱을 배포하고 관리하는 프로세스를 간소화합니다.
- 매니지드 쿠버네티스 플랫폼은 AKS와 EKS처럼 클라우드에서 쿠버네티스 클러스터의 자동 오케스트레이션을 위해 호스팅된 쿠버네티스 서비스를 제공합니다.
- 서버리스 컴퓨팅 은 사용자가 기본 인프라를 관리하지 않고도 기능을 실행할 수 있는 컴퓨팅 리소스에 대한 ‘온디맨드’ 접근 방식을 허용합니다.
클라우드 컴퓨팅의 장점
클라우드 컴퓨팅은 소비자와 기업 모두에게 유용합니다. 기존의 온프레미스 컴퓨팅과 비교했을 때 클라우드 컴퓨팅 의 주요 장점은 다음과 같습니다.
- 매니지드 인프라: 서버, 스위치, 랙, 전원, 냉각 장비를 설치하고, 설정하고, 유지 관리하는 데는 많은 비용과 시간이 소요됩니다. 클라우드 서비스는 인프라 관리의 복잡성 없이 솔루션이 비즈니스에 제공하는 혜택을 누릴 수 있습니다.
- 탄력적인 리소스: 퍼블릭 클라우드는 클라우드 사용량을 매우 간단하게 늘리거나 줄일 수 있습니다. 이러한 탄력성을 통해 기업은 병목 현상을 피하고 하드웨어에 과도하게 투자하는 리스크 없이 빠르게 확장할 수 있습니다.
- 포괄적인 관측 기능: 클라우드 플랫폼에는 관측 툴과 대시보드가 포함된 경우가 많습니다.
- 기본 제공되는 모범 사례: 서비스 공급업체는 성능, 보안, 사용 편의성사이에서 적절한 균형을 유지하는 것이 유리합니다. 또한 고객이 규모의 경제를 누리도록 할 수 있습니다. 결과적으로 사용자는 올바른 클라우드 플랫폼을 사용하는 것만으로도 인프라 모범 사례의 혜택을 누릴 수 있습니다.
클라우드 아키텍처로 전환
클라우드에서 새 프로젝트를 시작하는 것과 기존 워크로드를 클라우드로 전환하는 것은 별개의 문제입니다. 모든 사용 사례에 적합한 일률적인 접근 방식은 없지만, 올바른 접근 방식을 사용하는 데 도움이 되는 일반적인 원칙과 모범 사례를 참고할 수 있습니다.
- 클라우드 전환의 타당성 확인: 모든 워크로드가 클라우드 워크로드일 필요는 없습니다. 비즈니스 사례를 생성해 클라우드 전환 비용과 워크로드를 완전히 폐기하거나 온프레미스에 그대로 두는 데 드는 비용을 비교하세요.
- 클라우드 공급업체의 현명한 선택: 기능과 비용도 중요하지만, 그것만 고려해서는 안 됩니다. 공급업체를 선택할 때는 비기능적 요구 사항, 지원, 서비스 수준 협약, 벤더사 평판 등을 고려하세요.
- 적합한 서비스 및 배포 모델 선택: 퍼블릭 클라우드와 프라이빗 클라우드, IaaS, PaaS, SaaS는 제어, 기능, 벤더사 종속 면에서 서로 다른 장단점을 가지고 있습니다. 특정 모델에 종속되기 전에 장단점을 평가하세요. 예를 들어, 온프레미스 Exchange 서버를 IaaS 플랫폼의 유사한 가상 머신으로 전환하는 것이 논리적으로 보일 수 있지만, Office 365 이메일(SaaS)이 더 나은 솔루션일 수도 있습니다.
- 예산 통제: 클라우드 비용은 빠르게 상승할 수 있습니다. 대부분의 주요 클라우드 공급업체는 고객이 합리적인 견적을 얻고 예상치 못한 상황을 피할 수 있도록 클라우드 비용 계산기 를 제공합니다. 이와 더불어 가능하다면 예산 알림을 설정하고 명세서를 면밀히 확인하세요. 비용 추적을 위한 체계적인 접근 방식을 구축해 예산 범위 내에서 지출을 관리하세요.
- 비상 계획 확보: 백업, 롤백 계획, 사전 프로덕션 테스트를 진행하면 클라우드로 전환할 때 데이터 손실과 다운타임으로 인한 리스크를 방어할 수 있습니다. 중요한 워크로드를 전환할 때는 ‘여러 번 재고 한 번에 결단하는’ 접근 방식을 취해야 합니다.
- 복잡한 모놀리식 애플리케이션의 점진적 세대 교체 고려: 리프트 앤 시프트(Lift and Shift)가 모든 경우에 적합한 것은 아닙니다. 팀에서 복잡한 모놀리식 앱을 클라우드로 전환해야 하는 경우 애플리케이션의 점진적 세대 교체를 통해 시간이 지남에 따라 클라우드 기반 마이크로서비스로 점차 전환하는 방식을 고려해 보세요.
결론
클라우드 아키텍처는 복잡한 주제이며 배워야 할 것이 많습니다. 하지만 여기서 다룬 내용을 통해 클라우드 컴퓨팅의 기본적인 내용, 이유, 방법 에 대한 확실한 이해가 있어야 합니다.