자원 선택 및 아키텍처 설계

자원 선택 기준

과금 모델에 따른 자원 선택

아키텍처를 설계할 때에는 서비스의 과금 방식이 중요한 고려 요소로 작용하며, 과금 방식은 클라우드 자원의 배포 방식에 따라 달라질 수 있습니다.

Provisioning 방식은 특정 사양 또는 서비스를 지정하여 자원을 배포하는 방식입니다.

이 경우에는 실제 자원이 사용되지 않더라도 과금 주기(시간, 일, 월)에 따라 비용이 청구됩니다.

반면, Pay-as-you-go 방식은 자원이 실제로 사용되기 전까지는 비용이 발생하지 않으며, 사용한 용량이나 호출 횟수 등에 따라 과금됩니다.

Provisioning 방식과 Pay-as-you-go 방식을 혼합하여 과금하는 서비스도 존재합니다.

아래 그림에 제시된 두 아키텍처는 이미지 서비스를 제공하는 모바일 Application을 Provisioning 방식과 Pay-as-you-go 방식으로 구현한 사례입니다.

왼쪽의 Provisioning model 기반 3계층 웹 Application 방식은 개발자와 운영자에게 익숙한 전통적인 구축 방식으로, 기존 Application을 전환하거나 신규 Application을 개발할 때 일반적으로 선택되는 구성입니다.

이 아키텍처는 사용량과 관계없이 월 단위로 일정한 비용이 청구되므로, 부하 변동이 적은 워크로드에 적용할 경우 비용 효율성을 높일 수 있습니다.

오른쪽 아키텍처는 요청당 과금되는 Serverless Computing 서비스로 대부분 구성되어 있으며, 왼쪽의 Virtual Server 중심의 구성과는 대조적입니다.

Serverless Computing 아키텍처는 API Gateway의 API 라우팅, Cloud Functions의 함수 처리, Object Storage의 REST API 작동 방식에 대한 이해가 필요하며, 기술적인 과제를 수반합니다.

하지만, 호출당 또는 용량당 과금이 이루어지기 때문에, 실제 사용이 발생한 경우에만 비용이 청구됩니다.

따라서 요청 부하가 주기적으로 증가하거나 부하 예측이 어려운 환경에서는, 해당 아키텍처를 적용함으로써 비용 효율적으로 부하를 처리할 수 있습니다.

이처럼 자원을 선택할 때는 사용 사례와 조직의 기술 역량을 함께 고려해야 합니다.

클라우드 자원은 서비스 특성에 따라 다양한 과금 모델을 제공하므로, 이를 적절히 활용해 비용을 최적화할 수 있도록 아키텍처를 설계해야 합니다.

자원 유형, 크기, 수량 선택

온프레미스 환경에서는 시스템 구축 초기 단계에서 미래 수요를 신중하게 예측한 후 하드웨어 규모를 결정해야 하며, 일단 구매가 완료되면 변경이 어렵기 때문에 초기 설계가 매우 중요합니다.

반면, 클라우드 환경에서는 자원을 언제든지 확장하거나 축소할 수 있어 초기 자산 투자 부담을 최소화하여 시작할 수 있습니다.

이러한 클라우드의 특성을 활용해 비용 효율성을 높이려면, 요청당 과금되는 자원이나 컨테이너처럼 자원 효율성과 민첩성이 높은 기술을 선택하는 것이 유리합니다.

다만, Serverless Computing이나 컨테이너 기술을 도입하기 위해서는 조직 내부의 기술 역량이 뒷받침되어야 하므로, 이에 대한 비용과 리스크를 함께 고려해야 합니다.

서버 타입을 선택할 때에는 초기부터 큰 규모로 시작하기보다는, 소규모로 시작한 후 점진적으로 사양을 높이거나 배포 수량을 늘리는 방식이 바람직합니다.

클라우드 환경에서는 언제든지 서버 타입을 변경할 수 있으므로, 초기에는 작은 용량의 서버를 배포하고 소프트웨어 및 코드가 안정적으로 작동하도록 사양을 조정하는 단계를 거치는 것이 일반적입니다.

단위 서버의 용량을 최적화한 후에는 부하 테스트를 통해 서버 수를 확장하는 작업을 수행합니다.

관리 및 Application 통합 측면에서는 하나 또는 두 개의 서버에 여러 소프트웨어를 배포하는 방식이 용이할 수 있으나, 클라우드 환경에서는 작은 용량의 서버 여러 대를 활용하는 방식이 비용과 확장성 측면에서 더 유리합니다.

예를 들어, 큰 서버 2대보다 작은 서버 3대를 사용하는 것이 더 높은 가용성과 자원 활용률을 제공하며, 신속한 확장을 지원할 수 있습니다.

요금 모델 선택

요금제 선택

Samsung Cloud Platform에서는 약정 요금제, Cost Savings, Planned Compute 등의 요금제를 선택하여 적용할 수 있습니다.

아래 표는 요금제와 요금제에 해당하는 서비스를 설명합니다.

할인을 적용하기 위한 요금제는 Cost Savings, Planned Compute으로 구성됩니다.

Cost Savings와 Planned Compute를 계약할 경우 해당되는 서비스에 할인이 적용되며, 1년, 3년 기간을 선택하여 할인을 받을 수 있습니다.

특히, Planned Compute는 인스턴스 타입을 기준으로 약정이 이루어지며, 해당하는 무약정 인스턴스에 대해 할인을 적용할 수 있습니다.

서비스별로 무약정, 1년/3년 할인이 적용된 요금을 확인하고자 할 경우 요금계산기를 활용할 수 있습니다.

지난 1년간의 월평균 사용 시간이 아래와 같고, 향후 1년간의 사용량도 동일하다고 가정할 경우, 아래 표와 같이 요금제를 설계할 수 있습니다.

표에 기재된 상시 가동 Virtual Server는 약정 요금제를 통해 할인이 적용되었습니다.

GPU Server(g2v48h4)는 최소 1대에서 최대 4대까지 사용되며, 월간 총 사용 시간이 1,460시간으로 나타납니다.

이러한 경우에는 Planned Compute 약정을 통해 해당 서버 타입에 대한 할인을 적용할 수 있습니다.

비정기적으로 가동되는 Virtual Server, 정기적 부하를 처리하는 Auto-Scaling VM, 수직 확장 가능성이 있는 Database의 경우에는 모두 Cost Savings 요금제를 적용합니다.

Cost Savings를 적용할 때 주의해야 할 점은 보수적으로 약정 금액을 결정해야 한다는 것입니다.

과도하게 금액을 설정할 경우 사용하지도 않았는데 비용을 지불해야 하는 경우가 발생할 수 있으므로 보수적으로 시작한 후 점진적으로 최적화하는 방식이 바람직합니다.

소프트웨어 라이선스

앞서 언급한 것처럼, 큰 서버 여러 대보다 작은 서버 여러 대로 워크로드를 처리하는 전략은 소프트웨어 라이선스 측면에서도 비용 효율적으로 작용합니다.

Application 서버에서는 소프트웨어 사용량이 많은 편이며, 온프레미스 환경에서는 하드웨어 비용 절감을 위해 대용량 서버에 여러 소프트웨어를 설치하여 통합을 간소화하는 방식이 일반적이었습니다.

그러나 클라우드 환경에서는 이러한 방식이 오히려 비효율적일 수 있습니다.

작은 서버에 소프트웨어를 분리하여 설치하면 서버 사양이 낮아져도 문제가 되지 않으며, 소프트웨어 라이선스 구매 비용도 절감할 수 있습니다.

그리고, 소프트웨어 라이선스에서 고려해야 할 추가적인 요소는 BYOL(Bring Your Own License)입니다.

Samsung Cloud Platform의 Database, Analytics 등의 서비스에서 BYOL 소프트웨어를 지원하고 있으며, 배포하려는 소프트웨어의 라이선싱 조건을 확인한 후 서버 배포 방안을 검토해야 향후 예상하지 못한 예산 초과 상황을 피할 수 있습니다.

또한 마켓플레이스에서 구매할 수 있는 3rd Party 소프트웨어의 라이선스 및 기술 지원팩을 검토하는 것도 라이선스 비용 뿐만 아니라 기술 적용 측면에서도 비용 효율성을 높이는 좋은 방안입니다.

아키텍처 선택

수요 기반 탄력적 자원 구성 아키텍처 설계

Samsung Cloud Platform은 탄력적으로 서버를 조정할 수 있는 Auto-Scaling을 구성할 수 있습니다.

Auto-Scaling을 통해 수요에 따라 자원을 사용할 수 있는 수요 기반 비용 모델을 구성할 수 있습니다.

Auto-Scaling은 임계치 기반과 스케줄 기반의 수평 확장 및 축소 정책을 제공합니다.

임계치 기반 확장/축소 정책은 CPU usage, Memory usage, Network in/out 등의 지표에 대해 최소값, 최대값, 평균값을 기준으로 임계치를 설정하여 서버 수량을 조절합니다.

정책 설정 시에는 확장 작업을 빠르게 시작하여 부하에 선제적으로 대응하고, 축소 작업은 지연시켜 부하 재증가에 대비하는 것이 일반적입니다.

Serverless Computing 아키텍처를 통한 임시 부하 처리

Auto-Scaling은 부하 증가 속도가 VM 생성 속도보다 느릴 때 적합한 컴퓨팅 아키텍처입니다.

만약 부하 증가 속도가 VM 생성 속도보다 빠르다면 Auto-Scaling 기반 VM보다 다른 대안을 검토해야 합니다.

이럴 경우 우선적으로 검토할 수 있는 대안은 관리형 서비스인 Serverless Computing 아키텍처입니다.

부하의 증가 속도나 규모를 예측하기 어려운 경우에는 관리형 서비스를 활용하여 인프라의 고가용성 운영 부담을 덜어내는 것이 효과적입니다.

클라우드에서 제공되는 자원이 무제한 부하를 처리할 수 있는 것은 아니지만, 예측 불가능한 부하에 대해 안정적인 가용성을 확보할 수 있는 대안이 될 수도 있습니다.

아래 그림은 Auto-Scaling에 Serverless Computing 컴포넌트를 추가하여 임시 부하를 처리하는 아키텍처입니다.

평상 시 부하는 상단의 Auto-Scaling으로 처리하고, 급격한 부하 증가는 하단의 임시 서비스를 가동하여 처리하는 구조입니다.

이러한 아키텍처는 온라인 쇼핑몰의 한정 제품 프로모션이나 티켓 예약 사이트의 인기 공연 예매처럼, 이벤트 시작 시 순간적으로 부하가 급증했다가 재고나 좌석이 소진되면 부하가 감소하는 상황에서 활용됩니다.

1. Terraform 등의 IaC 도구나 CLI를 활용하여 서비스를 배포하거나 가동합니다. 일부 서비스는 요청 기반 과금 방식이 적용되므로 사전 배포가 가능하지만, CacheStore(DBaaS)와 같이 Provisioning이 필요한 서비스는 사전에 새로 배포한 후 정지 상태로 준비해두는 방식이 필요합니다.
   임시 워크로드용 서비스 배포에서 유의할 점은 부하 발생 개시 전 어느 정도 여유 시간이 필요하다는 점입니다.
   Cloud Functions와 같은 서비스는 요청을 처리하기 위해 Cold Start라고 하는 사전 가동 시간이 필요합니다.
   서비스 배포 시에는 이 가동 시간을 고려하여 요청 개시 시점 이전에 준비가 완료되도록 해야 합니다.

2. API Gateway를 통해 요청을 분배합니다.

3. Web 요청은 Object Storage의 버킷에 저장된 Web 자산을 통해 응답합니다.

4. 재고 확인 및 주문 처리는 Cloud Functions를 통해 수행합니다.

5. 빠른 쿼리 및 주문 저장을 위해 CacheStore(DBaaS)를 임시 데이터 저장소로 활용하며, 모든 처리가 완료된 후에는 데이터를 주 Database로 배치 저장합니다.

모든 처리가 완료된 후에는 자원을 삭제하거나 중지하여 비용 지출을 최소화합니다.

데이터 전송 비용 최소화 네트워크 설계

클라우드 설계 및 구축 초기에는 Compute 자원에 대해 주의를 기울여야 합니다.

이는 실제 클라우드 비용에서 Compute 자원이 가장 큰 비중을 차지하고, 잘못 설계하면 과도한 비용이 발생할 수 있기 때문입니다.

운영이 시작된 이후에는 예상하지 못한 비용이 발생할 수 있는데, 대표적인 예가 Internet Outbound Traffic 비용입니다.

인터넷 상에서 VPC 내부의 서버에 데이터를 요청하기도 하고, VPC 내의 서버가 인터넷으로 데이터를 송수신하기도 합니다.

이때 VPC 외부로 전송되는 데이터에 요금이 과금되는 것을 유의해야 합니다.

네트워크 아키텍처를 구성할 때, 특히 멀티 VPC 아키텍처를 설계할 경우, 인터넷을 경유하는 트래픽을 최소화할 수 있도록 주의를 기울여야 합니다.

여러 VPC의 서버 간 연결이 필요한 경우 인터넷을 경유하는 것을 지양하고 VPC Peering(두 VPC간 연결) 또는 Transit Gateway로 연결하여 프라이빗 통신을 구성하는 것이 비용을 최적화할 수 있는 방법이 될 수 있습니다.

이에 더해서, 프라이빗 연결을 통해 두 지점 네트워크의 연결에 대한 보안이 향상됩니다.

공통 서비스 영역 구성

다중 VPC 또는 다중 프로젝트 기반으로 여러 정보시스템을 운영하는 경우, 각 시스템의 기능은 상이하더라도 공통적으로 사용하는 서비스가 존재할 수 있습니다.

이러한 경우에는 공통 서비스를 별도의 영역으로 구성하고, 각 정보시스템이 이를 공유하여 사용하는 방식으로 아키텍처를 설계할 수 있습니다.

특히 상용 소프트웨어가 설치된 서버는 공통 서비스 영역으로 구성하면 경제적 효율성을 극대화할 수 있습니다.

예를 들어, 전국에 여러 지사를 보유한 조직이 본사와 지사의 홈페이지를 클라우드로 통합 마이그레이션하는 경우를 가정할 수 있습니다.

각 지사의 홈페이지 서버는 독립적으로 운영할 수 있지만, 웹 서비스에 필요한 구성 요소는 공통 서비스로 묶어 공유 존으로 설계함으로써 비용 절감 효과를 기대할 수 있습니다.

다음 그림은 클라우드 비용 절감을 목적으로 공통 서비스를 공통 VPC에 배치하여 구성한 아키텍처 예시입니다.

1. 본사, 지사 A, 지사 B의 시스템을 각각의 VPC에 배치하고, 공통 서비스용으로 별도의 VPC를 구성합니다.
   본사 및 지사의 VPC는 공통 서비스 VPC와 허브 앤 스포크(Hub-and-Spoke) 방식으로 VPC Peering을 수립합니다.

2. 각 VPC에서 공통적으로 필요한 소프트웨어를 VM에 탑재하여, 모든 시스템이 이를 공유할 수 있도록 구성함으로써 비용을 절감합니다.
   예시의 아키텍처에서는 각 홈페이지에서 사용하는 영상 서비스 및 지도 서비스를 공통 서비스로 구성하였습니다.

3. Bastion Server, Logging 서버 등 외부 접근 또는 정보보호 목적의 관리 서버를 별도로 구성하여, 외부 접점을 단일화할 수 있습니다.
   단, 이러한 단일 접점은 외부 침해에 대한 대비가 필요하며, 보안상 단일 취약점이 될 수 있으므로 주의가 요구됩니다.

이처럼 유사한 워크로드를 가진 여러 시스템을 호스팅하는 프로젝트에서는 공통 서비스를 활용한 아키텍처 구성을 통해 자원 및 라이선스 비용의 중복 투자를 방지할 수 있습니다.

또한 관리의 용이성과 아키텍처 확장성 측면에서도 추가적인 이점을 얻을 수 있습니다.