FinOps 공부를 하다보니 가장 어려운 개념이 Showback, Chargeback이라는 용어인 것 같습니다. 두개 다른 프로세스에 대하여 정리를 해보려고 합니다.

Showback 및 Chargeback은 사내 조직 별로 클라우드 비용을 할당하고 추적하는 데 사용되는 두개의 다른 FinOps 프로세스입니다. 몇 가지 유사점을 공유하지만 서로 다른 목적으로 사용되며 뚜렷한 특성을 가지고 있습니다.

## 쇼백(Showback)

쇼백은 조직이 클라우드 비용을 추적하고 내부 부서 또는 사업부에 전달하는  프로세스입니다. 쇼백의 주요 목적은 투명성을 제공하고 실제로 비용을 청구하지 않고도 다양한 부서에서 얼마나 많은 리소스나 서비스가 소비되고 있는지에 대한 인식을 높이는 목적으로 사용하는 프로세스입니다. 쇼백의 주요 특징은 다음과 같습니다.

- **투명성(Transparent):** 쇼백은 클라우드 비용에 대해 여러 부서 또는 사업 단위 간에 인식을 높이는 데 도움이 됩니다. 이를 통해 클라우드 비용이 재정적으로 미치는 영향을 이해할 수 있습니다.
- **실제 청구 없음(No Actual Billing):** 쇼백에서는 실제 인보이스나 청구서가 각 부서로 전송되지 않습니다. 대신 클라우드 사용 비용을 표시하는 보고서나 명세서가 생성되므로 부서는 자원 소비에 대해 정보를 바탕으로 결정을 내릴 수 있습니다.
- **비용 할당(Cost Allocation):** 쇼백은 비용 할당 목적으로 자주 사용되어 조직이 리소스가 어떻게 배포되는지 이해하고 부서에서 리소스 사용량을 최적화하도록 장려합니다.

## 차지백(Chargeback)

반면, 차지백은 실제 클라우드 비용을 해당 내부 부서 또는 비즈니스 단위에 할당하고 청구하는  프로세스입니다. Chargeback에서는 미리 결정된 요율이나 비용 모델을 기준으로 부서에서 소비하는 클라우드 비용 청구서가 발행됩니다. 차지백의 주요 특징은 다음과 같습니다.

- **실제 청구(Actual Billing):** Showback과 달리 Chargeback에서는 클라우드 사용에 대한 부서의 실제 청구서를 발행합니다. 이는 해당 서비스 제공과 관련된 비용을 회수하기 위해 수행됩니다.
- **비용 회수(Cost Recovery):** Chargeback은 클라우드 서비스 제공 시 발생한 비용을 회수하려는 경우 비용 회수 수단으로 자주 사용됩니다.
- **예산 관리(Budget Control):** Chargeback은 부서가 소비하는 리소스에 대해 책임을 지도록 하여 더 책임감 있는 사용으로 이어질 수 있으므로 더 나은 예산 관리에 도움이 될 수 있습니다.

요약하면, **쇼백(Showback)은 클라우드 비용을 청구하지 않고 내부 부서에 투명하게 제시하는 프로세스인 반면, 차지백(Chargeback)은 해당 비용을 실제로 청구하여 비용을 회수하고 책임있게 클라우드 자원사용을 장려하는 프로세스**입니다. 쇼백과 차지백 사이의 선택은 조직의 목표, 예산 책정 , 클라우드 비용 관리에서 달성하려는 목표, 비용 통제 및 투명성 수준에 따라 달라질 수 있습니다.

## 차지백과 쇼백 중 어느 것이 더 낫나요?

표면적으로 차지백과 쇼백은 매우 유사하게 보입니다. 두 가지 모두 각 부서가 자체 클라우드 리소스 사용에 대해 책임을 지도록 장려하는 효과적인 방법입니다. 둘 사이의 유일한 차이점은 차지백을 사용하면 부서가 클라우드 사용 비용을 지불해야 하는 반면, 쇼백을 사용하면 비용에 미치는 영향만 알 수 있다는 점입니다.

그러나, 두 접근 방식에서 기대할 수 있는 결과는 매우 다릅니다. 우선 차지백은 일반적으로 쇼백보다 더 성실하고 책임있는 클라우드 사용  습관을 정착시킬 수 있지만 클라우드 사용에 있어서 긴장과 마찰의 위험이 따릅니다.

이러한 마찰은 청구서를 갑자기 해당 부서에 지불하도록 요청하는 임원 사이에서 발생할 수 있습니다.  불공정성 비용 청구에 대하여 반발과 주장이 나올 수도 있습니다. 마찬가지로, 효과적으로 운영하기 위해 더 많은 자원이 필요하기 때문에 한 부서가 갑자기 다른 부서보다 훨씬 더 많은 비용을 지불해야 한다면 분쟁이 발생할 수 있습니다.

모든 팀의 평화로운 협력 관계를 유지하는 것이 회사의 최우선 과제라면 모든 차지백 정책을 잘 계획하고 신중하게 실행해야 합니다.

쇼백 혹은 차지백 중 어떤 프로세스를 도입을 할 것인지는 목표에 따라 달라질 수 있습니다.

단순히 비용 관리에 대한 인식을 높이고 싶다면 쇼백 정책을 선택하는 것이 더 간단하고 위험도가 훨씬 낮습니다. 그러나 비용이 통제할 수 없을 정도로 높아져 낭비가 심해질때는 차지백 정책이 효과적입니다.

부서별로 비용을 분류하는 데 익숙하지 않고 클라우드 비용에 대한 이해가 낮을 경우 차지백보다는 쇼백으로 시작하는 것이 현명할 것입니다. 많은 기업에서는 차지백을 구현한다는 궁극적인 목표를 갖고 있지만 중간 단계로 쇼백을 사용하는 것을 권고합니다. 특히 비용을 정확하게 분석하는 능력에 대해 완전히 확신할 때까지 쇼백 프로세스를 사용하는 것이 좋습니다.

## 참고
https://visualstorageintelligence.com/chargeback-vs-showback/

https://www.cloudzero.com/blog/chargeback-vs-showback

new_Torii_App_Rationalization_FI.jpeg

Showback vs. Chargeback

이 글은 nuvento에서 발행한 “Leveraging AI for Efficient Cloud management” 글을 바탕으로 내용을 읽기 쉽게 의역 및 축약, 내용 수정이 있음을 알려드립니다. (참고: [원문](https://nuvento.com/blog/leveraging-ai-for-efficient-cloud-management/))

---


 




 


지속적인 클라우드 컴퓨팅의 성장과 최근 인공지능(AI)까지 가장 필수적인 기술로 떠오르면서 미래를 선도해 나가고 있는데요. 예를 들면 Siri, Google Home, Alexa와 같은 디지털 어시스턴트는 클라우드와 인공지능을 완벽하게 융합된 형태로 우리의 일상적인 삶을 개선하고 있죠. 

이제 클라우드는 단순한 온디맨드 스토리지 및 컴퓨팅 리소스 제공자 그 이상이며, 인공지능은 클라우드 솔루션을 보다 효율적으로 만들어줍니다. 인공지능의 발전은 기업의 업무 방식에서 혁신적인 변화를 가져오고 있고, 업무 최적화, 데이터 분석, 클라우드 사용자 경험 개선 등에 대한 통찰력을 제공하고 있습니다.

### 그런데 **클라우드가 비효율적이라는 생각해보셨나요?**

**2025년까지 세계의 데이터의 절반(100 Zettabyte)이 클라우드에 저장될 것으로 예측합니다.** 기업들은 빠르게 클라우드를 채택하고 있고, 이는 퍼블릭 클라우드, 프라이빗 클라우드, 하이브리드 클라우드 및 멀티 클라우드 모델로 이루어져있죠.

클라우드 도입은 기업의 혁신을 주도할 수 있지만, 독자적인 문제점도 가지고 있습니다. 클라우드 관리(82%), 보안(83%) 및 거버넌스(79%)은 가장 중요한 문제점으로 대두되는데요. [The Flexera 2022 State of the Cloud Report](https://www.flexera.com/about-us/press-center/2022-state-of-the-cloud-report-by-flexera)에 따르면 거의 30%의 클라우드 예산이 낭비되고 있는 것도 큰 문제입니다.

**클라우드 도입 초기 단계에서는 쉽게 제어할 수 있지만, 기업 전체에 클라우드로 적용하면서 부터는 비효율성이 발생하기 시작합니다.** 예를 들면 예약 인스턴스 또는 절감 계획과 같은 용량 관리, 가시성 및 클라우드 사용 모니터링, 프로비저닝 및 사용되지 않은 데이터와 같은 리소스 낭비도 포함될 수 있습니다.

DevOps는 기한 및 출시의 높은 요구 때문에 워크로드를 예측하기 어려울 수 있으며, 리소스의 과다 프로비저닝을 초래할 수도 있죠. 이러한 문제를 해결하는 데 인공지능이 도움이 될 수 있지만 인공지능은 거대한 컴퓨팅 파워, 인재, 대량의 데이터셋 액세스 및 리소스가 필요하기 때문에, 작은 기업들의 경우에는 감당하기 어려운 것이 현실입니다. 

이런 점에서 클라우드 컴퓨팅은 모든 사람들에게 인공지능을 더욱 접근 가능하게 만들어주는데요. **인공지능과 클라우드는 서로를 공생하는 관계라 할 수 있습니다.**

그럼 인공지능을 클라우드 관리에 활용하는 방법을 살펴보겠습니다.

 



 



 


 ![](https://cdn.grumatic.com/strapi/6_ways_efficient_cloud_management_using_ai_cover_813b7a5751.png) 

**인공지능을 활용하면 클라우드 비효율성이 관리 가능해집니다**

인공지능은 지능적으로 리소스 프로비저닝, 클라우드 비용 절감 및 성능 최적화를 통해 클라우드 비효율성을 관리할 수 있습니다. 자동화는 인간의 오류를 방지하는 가장 좋은 방법 중 하나이자, 인공지능이 클라우드에 미치는 영향을 이론적으로 설명할 수 있습니다. 

Kubernetes와 같은 클라우드 네이티브 솔루션은 철저한 규칙을 가지고 있기 때문에 자동화에 이상적인데요. 클라우드 자동화는 클라우드 워크로드를 프로비저닝, 스케일링, 관리 및 모니터링하는 데 꼭 필요한 도구입니다. 그리고 인공지능은 자동화를 위해 아래와 같은 작업을 할 수 있습니다.


 


 


## 1. **24x7 모니터링**

엔지니어가 정확도를 잃지 않고 클라우드를 시계열로 모니터링하는 것은 어렵거나 거의 불가능합니다. 

그러나 AI 알고리즘을 사용하면 클라우드를 정확하고 효율적으로 24x7 모니터링하고 분석할 수 있습니다. 이 방법으로 **클라우드는 실시간으로 사용량을 측정하고 최적의 용량에서 작동함을 보장할 수 있습니다.**


 


 


## 2. **클라우드 리소스의 자동 스케일링**

클라우드 환경은 항상 변하고 요구 사항의 변화는 예측하기 어렵습니다. 인간이 이러한 변경에 대응하는 것은 어려울 수 있지만, 인공지능은 즉시 변화를 파악하고 대응할 수 있습니다. **인공지능은 모든 리소스를 모니터링하고 분석하여 실시간으로 자원을 프로비저닝하고 조정할 수 있습니다.**

인공지능의 도움으로 필요에 따라 새로운 인스턴스를 생성하거나 인스턴스를 제거하는 것도 가능합니다.


 




 


## 3. **클라우드 낭비 줄이기**

클라우드 컴퓨팅의 가장 큰 문제점 중 일부는 초과 프로비저닝, 사용이 없거나 연결이 없는 인스턴스 및 리소스가 계정에 포함되지 않은 그림자와 같은 IT 프로젝트입니다. 이러한 "좀비" 인스턴스 및 인프라는 여전히 활성화되어 청구되는데요. 

**인공지능의 도움으로 클라우드 환경을 자동화하면 이를 모니터링하고 분석하고 적절한 조치**를 취하여 클라우드 낭비를 방지하고 대규모 클라우드 청구를 피할 수 있습니다.


 



 



## 4. **EBS 관리**

EBS 또는 전자 블록 스토리지를 수동으로 관리하는 것은 매우 복잡합니다. 사용하지 않는 볼륨이 있거나 필요한 것보다 더 높은 성능으로 비용을 지불할 수도 있습니다. **인공지능은 사용되지 않는 EBS를 식별하고 사용률 추세를 예측할 수 있기 때문에 볼륨을 자동으로 병합하거나 분리함으로써 최적의 디스크 활용률을 보장**하는데 도움이 됩니다.


 




 


## 5. **예측 지능 및 예측**

인공지능을 사용하는 가장 큰 이점 중 하나는 **클라우드의 과거 데이터와 동작을 분석하여 트래픽 증가나 인프라 성장에 대한 요구 사항을 예측할 수 있다는 것**입니다. 머신 러닝 모델은 대용량 데이터셋에서 학습하고 요구 사항을 정확하게 예측이 가능합니다.


 



 



## 6. **인프라 자동화**

IT 인프라는 구성 파일에서 정의되며, 배포 중에 이와 일치하는 구성으로 자동 시작되어 환경을 유지합니다. 운영 환경을 최적으로 유지하기 위해 소스 코드처럼 처리, 관리, 개발, 테스트 및 버전 관리해야 합니다.

**코드형 인프라(IaC)를 자동화함으로써, 자동화 프로세스는 공통 구성 요소(가상 머신 또는 VPN)를 정의하고 이러한 구성 요소에 응용 프로그램 구성 요소와 서비스를 로드하고 최적의 운영 환경을 생성**하기 위해 이를 조합할 수 있습니다.


 



 



 



 


## AI를 **클라우드 관리에 사용할 때 장점**
---

**데이터, 보안, 비용 또는 성능 관련 문제가 있을 경우, 인공지능은 사용자가 정의하는 최적의 클라우드 사용 지표를 최적화하는 데에도 도움이 됩니다.** 많은 기업이 멀티 클라우드 환경을 사용하고 있는데요. 적절한 AI 모델을 사용하면 리소스를 통합하여 클라우드 성능을 최적화할 수 있습니다.

AI를 클라우드 관리에 활용하는 몇 가지 방법에 대해 알아보았는데요. AI가 클라우드 관리에 작용하는 장점도 알아보겠습니다.

 ![](https://cdn.grumatic.com/strapi/ai_benefit_cloud_6186d7d1a8.png "출처: https://nuvento.com") 

 




 




 


### **1. 비용 절감**

**Gartner에 따르면, 기업이 클라우드를 도입함에 있서 범할 수 있는 실수를 모르는 경우, 비용이 20~50% 증가한다고 합니다.**

오토스케일링, 사용하지 않는 리소스 및 동적 프로비저닝은 클라우드 재정에 대한 어려움을 초래할 수 있으며 클라우드 예산을 초과할 수도 있습니다. **여기서 인공지능과 머신 러닝을 사용하면 지능적인 자동화로 낭비되거나 초과하는 비용을 예방할 수 있습니다.**

예를 들어, AI Ops를 사용하여 개발 인스턴스의 전원을 주말에 끄도록 자동화할 수 있습니다. 또 다른 방법은 AWS Lambda와 같은 클라우드 전용 AI 도구를 사용하여 Amazon EC2 예약 인스턴스 구매 과정을 자동화할 수도 있습니다.


 




 


### **2. 데이터 관리**

기업에서 생성된 데이터를 수집, 카탈로그화 및 관리하는 것은 큰 과제입니다. AI 도구는 데이터 처리의 특정 측면에서 사용할 수 있습니다. **데이터를 수집, 업데이트 및 관리되는 방식을 단순화하여 사용자에게 정확하고 실시간으로 제공할 가능합니다.**

**AI는 이상 감지 및 부정 행위 검출에도 도움이 됩니다.** 특히 금융업, 마케팅, 보험, 고객 서비스 및 공급망 관리와 같은 산업 분야에 큰 도움이 될 수 있죠.


 




 


### **3. 생산성 향상**

인공지능은 반복적인 작업을 자동화하는데도 큰 역할을 합니다. **클라우드 환경 내의 작업 부하를 최적화하여 생산성을 향상시키는 것이죠.** 결국 클라우드의 미래는 인간 개입 없이 모니터링, 관리 및 자동 수정하는 인공지능의 역할로서 성장할 수 밖에 없습니다.


 




 


### **4. 보안 강화**

클라우드 방어벽 침애 중 88%는 클라우드 제공업체가 아닌 휴먼 에러(Human Error) 때문이라는 사실 아셨나요? **클라우드 보안 문제 중 가장 중요한 것은 클라우드 인프라의 잘못된 구성, 무단 접근, 보안이 미약한 API, 계정, 서비스 또는 트래픽의 해킹 및 외부 데이터 공유 등이 있습니다.**

**AI는 24시간 365일 모니터링하여 보안 위험 요소와 궁극적으로 보안 취약점을 식별하고 적시에 경고를 주는 것이 가능**하며 대응까지 할 수있습니다.


 




 


### **5. Compliance 규정 준수**

AI를 사용하면 모든 클라우드 리소스가 PCI-DSS, GDPR, ISO 27001 및 HIPAA와 같은 규정 사항을 충족하는 적절한 보안 규정 설정으로 프로비저닝됩니다.

AI Ops를 사용하면 **클라우드 제공 업체에서 실시간 구성 관리 데이터를 사용하여 비즈니스 리스크를 감소시키고 규정에서 요구하는 사항을 충족시킴으로써 기업의 컴플라이언스 준수를 보장할 수 있습니다.**

예를 들면 규정 요구 사항을 충족시키지 못하면 프로비저닝자에게 즉각적인 경고를 발행하거나 시스템 종료와 같은 조치를 취할 수 있습니다.


 



 



 


요즘 들어 AI의 관심과 개발이 더 활발하게 이루어지고 있는데요. 클라우드 역시 그 여정에 필연적으로 함께할 수 밖에 없습니다. AI의 고도화를 통해 클라우드 역시 더 발전하고 있으니 계속해서 인사이트를 놓치지않는 것이 중요합니다.

CostClipper 역시 **클라우드와 관련된 소식과 도움이 되는 인사이트를 개발자분들을 위해 지속적으로 소개드리도록 노력**하겠습니다.


 



 


이 글은 nuvento에서 발행한 “Leveraging AI for Efficient Cloud management” 글을 바탕으로 내용을 읽기 쉽게 의역 및 축약, 내용 수정이 있음을 알려드립니다. (참고: [원문](https://nuvento.com/blog/leveraging-ai-for-efficient-cloud-management/))

milad_fakurian_58_Z17ln_VS_4_U_unsplash.jpeg

AI를 활용하여 클라우드 관리하는 6가지 방법

지난 편에 이어서 남은 세가지 직무에 대해서도 알아보겠습니다.


 


 


## 4. 개발 리드 - 비즈니스의 요구사항과 빠르고 좋은 품질의 서비스를 제공
엔지니어링과 운영 팀의 경우 클라우드의 성능 지표를 확인하고 모니터링하는 것처럼 비용도 중요 지표로 도입하는 것이 중요합니다. 팀에서 올바른 크기 조정(Rightsizing, 클라우드 리소스를 워크로드 요구에 맞추어 사이즈를 재조정하는 과정)이나 컨테이너 비용 할당, 사용하지 않는 스토리지와 컴퓨터 파악, 이상 비용 확인 등과 같은 활동을 전개하면서 리소스의 사용을 효율적으로 설계하고 사용합니다.


| 목표 (Objectives) | 방해 요소 (Frustrations) | Key Metrics | FinOps Benefits |
| --- | --- | --- | --- |
| • 애플리케이션/서비스에 대한 책임을 가진 개발팀에게 재무적 책임감 유도 • 변칙과 베스트 프랙틱스를 정의함으로써 엔지니어링 팀이 효과적인 애플리케이션/서비스를 제공하도록 가이드 제공 • 가능한 비용 방지와 비용 감소를 정의하여 엔지니어링 팀이 협업 • 비용 분배 | • 워크로드를 증가하도록 유지하는 것이 만족스럽지 못할 때 • 예산에 영향을 주는 것을 예측하지 못하는 상황 • 서비스나 애플리케이션에 대한 책임 정의의 어려움 • 새로운 기능과 프로덕트 개발과 비용을 밀접하게 예측할 수 없음 | • 인프라 비용대비 매출 • IT 비용의 쇼백(Showback) & 차지백(Cahsrgeback)* | • 클라우드 비용에 대한 가시성 증대 • 유닛 이코노믹스와 클라우 비용 간의 연결 • 사용률에 대한 책임감 부여 |


쇼백(Showback)과 차지백(Chargeback)이 궁금하다면 [여기](https://www.costclipper.io/blog/5-tagging-strategies-cloud-cost-management)를 참고하세요.

 



 



 


## 5. IT 재무 담당자 - 클라우드 비용의 정확한 예산 설정 및 예측과 보고

재무 계획 및 분석 관리자와 같은 재무팀은 핀옵스 팀이 제공하는 보고서를 활용하여 비용 할당, 쇼백 할당, 예측을 진행합니다. 핀옵스 팀과 긴밀하게 협력하여 이전의 청구 데이터를 이해하고, 더 정확한 비용 모델을 만들어 관리하는 것을 목표로 합니다.

| 목표 (Objectives) | 방해 요소 (Frustrations) | Key Metrics | FinOps Benefits |
| --- | --- | --- | --- |
| • 비용 지출 및 예산 유지/ 보수 • 정확한 예측 준비 • 실제 비용 및 트렌드 보고 • 지출 예측성 표준화 | • 예측하기 어렵거나 복잡한 클라우드 비용 • 클라우드 비용 책임의 분산으로 인한 팀의 혼란 • 레거시 재무 모델의 당면 과제(자본적 지출 vs 운영 지출) | • 매출 성장률 • 순이익 성장률 • 매출 원가 (COGS, Cost of Goods Sold) • 유닛 이코노믹스 • 클라우드 예산 및 예측의 투명성과 정확성 | • 할당되지 않은 비용 식별 • 쇼백/차지백을 촉진하여 재무적 책임성 증대 • 예산 및 예측 정확도 향상 • 팀이 클라우드에 대한 투자를 효과적으로 수행할 수 있도록 가이드 가능 |

 



 





 

## 6. 조달 관리자 - 클라우드 플랫폼과의 계약 및 유지 관리

기업의 조달 관리자는 회사에 필요한 물품 혹은 서비스를 구매, 계약, 관리까지 모두 담당하는데요. 사용하는 클라우드 서비스(CSP)를 비롯해 연관된 클라우드 관리 플랫폼(Cloud Management Platform) 등의 구매부터 계약, 유지까지 클라우드 서비스 조달을 담당하기 때문에 클라우드 비용 측면에서도 중요한 역할이라고 할 수 있습니다.

| 목표 (Objectives) | 방해 요소 (Frustrations) | Key Metrics | FinOps Benefits |
| --- | --- | --- | --- |
| • 최상의 상생(win-win을 위한 클라우드 계약 협상 • 엔터프라이즈 할인/물량 보장 프로그램 계약 • 클라우드 플랫폼 공급자와의 관계 관리 | • 클라우드 비용 데이터에 대한 가시성 부족 • 클라우드 약속을 정하고 관리하는 중앙 집중식 프로세스 부족 | • 소프트웨어 라이센스 최적화 • 라이센스당 비용 • 팀당 라이센스 활용 • 가능한 통합 기회를 제공하기 위한 벤더당 비용 또는 IT 지출 | • 가장 효과적인 클라우드 비용 절감 • 청구 데이터를 비용을 기반 하는 활동으로 전환 • 가시성을 제공하고 기술 라이센스 및 계약별 비용을 이해할 수 있도록 지원 |

 



 



 



 



## 클라우드 비용 관리와 최적화는 더 이상 개발팀만의 과제가 아닙니다.

클라우드 비용 관리에 관여하는 중요한 직무를 살펴보았는데요. 핀옵스 방식을 도입하면서 직무과 역할에 대한 이해가 필요한 이유는 **클라우드 비용 관련 의사 결정을 제안, 승인, 논의 등과 같은 단계를 진행하면서 보다 효율적으로 진행 가능하기 때문입니다.** 

또한 각 직무 입장에서 어떤 가치를 목표로 하는지 정확하게 이해하면서 핀옵스 방식을 효과적으로 활용할 수 있습니다. **핀옵스의 핵심은 클라우드에 대한 재무적 책임의 범위를 개발자만이 아닌 비즈니스, 재무팀까지 넓히는데 있습니다.** 그리고 **모든 이해관계자가 클라우드 비용 관리와 최적화는 비즈니스의 목표와 매출에 긴밀한 영향을 주는 투자라는 것을 이해하는 것이 보다 중요합니다.**

우리 기업에서 클라우드 비용이 개발팀에게만 주로 초점이 맞춰있지는 않으신가요? 혹은 다른 팀에게도 재무적 책임을 가지게 하도록 노력하고 있는지 내부적으로 점검이 필요합니다. 클라우드 확대와 사용도 중요하지만 글에서 소개한 내용을 기반으로 클라우드를 비용 효율적으로 활용하시길 바랍니다.

이 글은 FinOps Foundation에서 “****FinOps Personas****” 글을 바탕으로 내용을 읽기 쉽게 의역 및 내용 수정이 있음을 알려드립니다. (참고: [원문](https://www.finops.org/framework/personas/#finops))

 



 

 


앞으로도 유용한 클라우드/AWS 정보와 함께 찾아오겠습니다.

효율적인 AWS 인프라 관리부터 비용 절감까지, CostClipper가 함께합니다.

milad_fakurian_Lfbh_DPH_3_q_Y_unsplash.jpg

클라우드 비용 관리는 개발팀만의 과제? No! [2편]

클라우드의 성장은 IT 인프라에 많은 변화를 가져왔는데요. 기존과 다른 인프라 방식인 만큼 온프레미스와 클라우드를 동시에 운영하거나, 클라우드로 이전하면서 완전히 클라우드 환경에서 운영하는 등의 업무의 형태가 달라지면서 업무의 범위도 확장되었습니다.

특히 클라우드는 사용하는 만큼 비용을 지불하기 때문에 **인프라 비용 대비 수익에 대한 지표를 측정하기 어려워졌습니다.** 비즈니스를 운영함에 있어 **투자 대비 이익**은 기업의 가장 큰 관심사이자 핵심 지표인데요. 실제로 [딜로이트 조사](https://www.forbes.com/sites/joemckendrick/2015/09/12/should-you-trust-your-ceo-with-cloud-computing-decisions/?sh=3789d1641173)에 따르면, 500명의 미드 마켓 임원 중 60% 이상이 기술 관련 의사 결정에 참여하고 있다고 밝혔습니다. 그 중 46%는 적극 참여 중이라고 하는데요.

앞으로도 CEO, CFO가 IT 의사 결정에 참여하는 비율은 더 높아질 것으로 예상됩니다. 결국 클라우드 비용 관련에서는 특히기업의 예산, 투자 대비 수익 등을 위해 임원들도 기술을 이해하고 엔지니어와 함께 일하는 협업이 중요해질 것입니다.

**그렇다면 엔지니어링 팀은 어떤 직무의 경영진과 긴히 협업하고 커뮤니케이션해야할까요? 그리고 직무 별로 클라우드 비용의 어디까지 알고 책임을 져야하는 걸까요?** 

오늘은 **클라우드 비용 관리에 필요한 기업 내 이해 관계자들이 누구이고, 각 직무별로 어떤 가치에 집중해야 하는지 알아보겠습니다.**


 




 




 


### FinOps란?
---

재무 (Finance) + 데브옵스 (DevOps)의 합성어인 **‘핀옵스 (FinOps)’는 재무팀과 엔지니어링 팀의 커뮤니케이션과 데이터를 기반으로 협업하는 일종의 워크 플로우 혹은 업무 방식을 말합니다.** 클라우드 비용과 관련해서 각 팀간의 원할한 의사소통을 통해 클라우드를 보다 비용 효율적으로 사용하도록 하고 비즈니스적 성과와 비교하며 클라우드 사용 및 비용을 최적화해나갑니다.

아직 국내에서는 완전히 정착되지 않았지만 글로벌에서는 전문 기관과 커뮤니티가 활성화되고 있는 상황입니다. [**핀옵스 공식 재단**](https://www.finops.org/introduction/what-is-finops/)에서는 아래 그림 처럼 핀옵스 문화 정착을 위해 기업에서 필요한 원칙, 단계와 같은 기본적인 체계를 연구하고 교육하고 있습니다.** 관련된 교육도 개인 및 기업에게 제공하고 있어 실제로 많이 알려진 VMware, Google Cloud, IBM, Deloitte, Cloudability, CloudZero 등이 파트너를 맺고 있습니다.

 ![](https://cdn.grumatic.com/strapi/what_is_finops_6598bf35be.png) 


 



 


### 클라우드 비용 관리에 필요한 이해 관계자
---

앞서 설명드린 핀옵스 재단에서는 클라우드 관리를 비용 효율적으로 하기위해 필요한 이해관계자를 페르소나로 설명하고 있는데요. 즉 ‘**핀옵스라는 문화 혹은 워크플로우를 정착시키기 위한 직무와 각 역할**’이라고 생각하면 이해가 더 쉽습니다.

- [핀옵스 전문가 (****FinOps Practitioner)****]
- [경영진 (****Executives)****]
- [비즈니스/ 프로덕트 오너 (****Business/Product Owner)****]
- [개발 및 운영 담당자 (****Engineering and Operations)****]
- [재무 담당자 (****Finance)****]
- [조달 관리자 (****Procurement)****)


 


 ![](https://cdn.grumatic.com/strapi/finops_org_struct_c792b60720.png)


위의 그림은 조직이 핀옵스 모델이 어떻게 운영해야하는지 보여줍니다. 결국 핀옵스는 단순한 팀의 협업을 넘어서 **기업의 클라우드 비용 관리 ‘문화’를 바꾸는 작업이기 때문에 많은 이해 관계자와 긴밀한 커뮤니케이션이 필요하고 재무적 책임에 대한 분산을 각 직무가 가지는 것이 중요합니다.**


 



 



 



 


## 1. 핀옵스 전문가
---

기존에는 클라우드 비용 관리를 인프라 관리자나 데브옵스 엔지니어가 맡아하는 경우가 많았는데요. 핀옵스 문화가 국내에도 도입되기 시작하면서 ‘핀옵스 엔지니어’를 따로 채용하는 사례도 많아지고 있습니다. 

핀옵스 전문가의 구체적인 목표와 가치는 이렇습니다.

::table{.expand-min}

| 목표 (Objectives) | 방해 요소 (Frustrations) | 핵심 지표 (Key Metrics) | 이점 (FinOps Benefits) |
| --------- | --------- | --------- | --------- |
| • 문화 정착을 리드 • 클라우드 비용 관리에 필요한 모범 사례 구축 • 팀의 기준 및 목표 설정 • 클라우드 비용에 대한 가시성과 투명성 확보 • 클라우드 예산 설정 및 예측하여 공유 | • 클라우드 사용 및 비용 데이터에 대한 접근성 부족 • 재무적 책임의 분산 • 엔터프라이즈 규모에서의 핀옵스 도입 • 필요한 기능이 빠진 툴에 대한 의존성 | • 정확한 클라우드 예산 • 정확한 클라우드 사용 및 비용 예측 • 유닛 이코노믹스* 중심 • 할인/ 예약 충당률 • 태그 지정이 필요한 리소스 비율 • 클라우드 효율성 기회 발굴 | • (단일 혹은 멀티) 클라우드환경에서 중앙 집중식 클라우드 비용 관리 • 클라우드에 대한 재무적 책임 분배 및 조정 • 클라우드 예산 및 예측에 대한 정확성 증대 • 조직내 커뮤니케이션 향상



핀옵스 전문가는 주로 비즈니스 팀과 개발팀, 재무팀을 연결하며 클라우드 사용 및 비용과 같은 데이터를 기반으로 클라우드 사용을 최적화를 이끄는 역할입니다. 앞서 언급했듯이 핀옵스는 기존과는 다른 업무 방식이자 새로운 워크 플로우입니다. 각 **이해 관계자들에게 핀옵스 프레임 워크와 원칙을 교육하고 문화를 정착시키면서 재무적 책임을 분배하는 역할에 핵심이라고 할 수 있습니다. 핀옵스팀을 중심으로 중앙 집중식 방식으로 팀 간의 커뮤니케이션을 효율적이고 명확하게 만듭니다.** 빠르게 변하는 클라우드 지출을 효과적으로 관리하여 비즈니스 성과의 극대화하는 역할인 것이죠.

:::toggle
::summary[*유닛 이코노믹스 (Unit Economics)란?]
**유닛 이코노믹스란 비즈니스 모델의 가치를 창출하는 단위(Unit)를 정하여, 그 단위가 비즈니스에 기여하는 수익성을 측정하는 방식을 말합니다.** 이해를 위해선 간단한 배경 이해가 필요합니다.

매출을 구성하는 몇가지 비용이 있는데 그 중에서도 **변동비란 제작, 생산량의 증감의 따라 함께 연동되어 변하는 비용을 말합니다.** 예를 들면 매출이 증가할수록 함께 증가하는 금액들이 있겠죠. 때문에 매출액이 커지더라도 변동비를 조절하지 못한다면 오히려 손해가 되기도 합니다.

 ![](https://cdn.grumatic.com/strapi/Unit_economics_5fbce6a010.png) 

이 변동비에 해당하는 항목 중 하나가 바로 **클라우드 비용**입니다. 비즈니스의 성장과 함께 증가하는 성향을 가졌지만 관리하거나 예측하기 어렵고, 인프라 투자라는 생각에 놓치기 쉽습니다. 


 


하지만 공헌 이익이 마이너스가 된다면 수익성과 비즈니스 모델의 지속 가능성에 어려움을 겪고 있다고도 할 수 있습니다.


 


물론 클라우드 비용과 매출 간의 상관관계가 명확한 상관관계가 있는 것은 아닙니다. 매출에 기여하는 유닛에따라 클라우드 지출은 증가할 수도 감소할 수도 있습니다. 예를 들면, SaaS 기업의 경우 ‘고객의 수’가 증가하면 인프라의 증축이 필요해지면서 클라우드 비용이 증가하겠지만, 전통적인 온프레미스를 주로 사용하는 기업의 경우 ‘고객의 수’가 증가한다고 클라우드 비용이 증가하지 않을 수 있습니다. 같은 유닛이라고 해도 산업의 특성에 따라 클라우드 비용과 일관된 상관 관계는 없다는 의미입니다.


 


때문에 산업의 특성과 규모에 따라 매출에 기여하는 유닛을 어떻게 설정하느냐에 따라서 달라지고 **클라우드 비용과의 상관관계를 가지는 유닛을 찾아 정의하는 것이 중요합니다.** 결국 유닛 이코노믹스 방식으로 회사는 매출과 예산에 따라 클라우드 리소스를 어떻게 얼만큼 배분할 것인지 정하고, 최적화가 가능한 기회를 지속적으로 찾고 관리해야 하기 때문입니다.


 


이 방식은 복잡한 비즈니스 모델의 단위화시켜 직관적이고 경제적인 의사결정을 가능하게 하고 지속적인 비즈니스 모델의 수익성과 지속 가능성을 측정하는 지표입니다. 핀옵스는 유닛 이코노믹 방식을 기반으로 적용하는 워크 프레임으로 클라우드 사용 및 비용에 대한 데이터 기반 의사결정을 가능하게 합니다.

핀옵스 재단에서는 [클라우드 유닛 이코노믹스가 무엇인지 언제, 어떻게 시작해야하는지 자세히 설명하고 있습니다.](https://www.finops.org/project/introduction-cloud-unit-economics/) 다음 콘텐츠에서 더 자세히 다루어보겠습니다.
:::

 



 



 


## 2. 경영진
---

핀옵스는 비즈니스 모델의 수익성과 직결되어있고 클라우드 비용에 대한 재무적 책임을 분산하고 직무마다 적절하게 할당하는 것이 핵심입니다. 때문에 CTO, CIO는 물론이고 CFO, CEO 역시 클라우드 비용에 대한 관여가 필요하며 정해진 예산안에서 팀의 책임감을 높이고, 투명성을 만드는데 집중하여 효율적으로 관리할 수 있도록 설득합니다.


 


#### CEO - 비즈니스 목표에 맞는 클라우드에 예산 설정

| 목표 (Objectives) | 방해 요소 (Frustrations) | Key Metrics | FinOps Benefits |
| --- | --- | --- | --- |
| • 기업의 YoY* 성장 • 전략적인 경쟁력 보 • 빠른 시장 선점 • 혁신적이고 선두적인 솔루션을 비용 효율적으로 제공 | • 예측하기 어렵거나 복잡한 클라우드 비용 • 엔지니어 팀의 계획과 비즈니스 목표 간의 관련성 어려움 • 클라우드 투자에 대비 수익 확신의 어려움 | • 매출 성장률 • 순이익 성장률 • 매출 원가* (COGS, Cost of Goods Sold) • 유닛 이코노믹스 | • 리스크 관리 • 비즈니스 성과과 엔지니어링의 의사결정 간의 연결 • 비즈니스 성장에따라 클라우드 비용이 어떻게 변화하는지 파악 가능 • 조직이 적절한 클라우드 투자를 할 수 있도록 가이드 | 

*YoY: year-on-year, 전년 동기 대비 증감율

*매출 원가는 특정 기간에 수익을 창출하는데 소요되는 비용을 측정하는 것입니다.


 


#### CTO/CIO - 최상의 기술을 제공함으로써 비즈니스에 경쟁 우위 제공

| 목표 (Objectives) | 방해 요소 (Frustrations) | Key Metrics | FinOps Benefits |
| --- | --- | --- | --- |
| • 기업의 YoY* 성장 • 전략적인 경쟁력 확보 • 빠른 시장 선점 • 혁신적이고 선두적인 솔루션을 비용 효율적으로 제공 | • 클라우드 비용에 대한 합리적 근거 제시와 비용 최적화에 대한 압박 • 클라우드 지출에 대한 기준이 불명확 • 처리되지 않은 개발 • 비즈니스 지속성 • 신뢰성 혹은 확실성 부족 | • 매출 성장률 • 순이익 성장률 • 매출 원가 (COGS, Cost of Goods Sold) • 유닛 이코노믹스 • 새로운 기능 및 서비스 출시 기간 • 개발 생산성 • R&D와 프로덕션 지출 간의 비교 트래킹 • 예산 범위 내에서의 운영 유지 | • 비즈니스 성장에따라 클라우드 비용이 어떻게 변화하는지 파악 가능 • 조직이 적절한 클라우드 투자를 할 수 있도록 주도 • 엔지니어링 조직이 새로운 클라우드 기술을 보다 자유롭게 활용하고 솔루션을 보다 신속하게 시장에 제공할 수 있도록 지원 가능 |

 


#### CFO

| 목표 (Objectives) | 방해 요소 (Frustrations) | Key Metrics | FinOps Benefits |
| --- | --- | --- | --- |
| • 비용 가시성과 정확성 • 전체 유닛당 비용 및 매출 원가 감소| • 예측하기 어렵거나 복잡한 클라우드 비용 • 클라우드 투자에 대비 수익 확신의 어려움| • 매출 성장률 • 순이익 성장률 • 매출 원가 (COGS, Cost of Goods Sold) • 유닛 이코노믹스 • 예측가능성 | • 클라우드 비용에 대한 재무적 책임 증대 • 비용 모델을 예측하고 예산 설정에서 신뢰성 증대 |




 


 



 



## 3. 프로덕트 오너 - 정확한 가격으로 새로운 프로덕트와 기능을 빠르게 출시
클라우드 최적화 관리자, 클라우드 분석가, 비즈니스 운영 매니저와 같은 비즈니스/프로덕트 오너도 재무적 책임을 가집니다. PO(Product Owner)는 개발자와 디자이너와 한 팀으로 공동의 목표를 가지고 프로덕트를 지속적으로 고도화하는 직무로 서비스의 일정과 우선순위와 비즈니스 목표를 가장 잘 아는 사람입니다. 핀옵스와 관련이 없는 직무처럼 보일 수 있지만 하나의 비즈니스 목표를 이루기 위함이라는 점에는 변함이 없습니다. 

결국은 기업이 유닛 이코노믹스의 방식으로 비즈니스를 운영한다면 프로덕트에 대비 수익을 측정하고 클라우드 투자 비용과 프로덕트 투자 비용 간의 비교가 필요합니다. 결국은 비즈니스를 효율적으로 운영하기 위함이기 때문이죠.

| 목표 (Objectives) | 방해 요소 (Frustrations) | Key Metrics | FinOps Benefits |
| --- | --- | --- | --- |
| • 프로덕트 YOY 성장 • 시장 출시 기간 단축 • 혁신적이고 선두적인 솔루션을 비용 효율적으로 제공| • 예측하기 어렵거나 복잡한 클라우드 비용 • 새로운 기능과 프로덕트 | • 매출 성장률 • 순이익 성장률 • 매출 원가 (COGS, Cost of Goods Sold) • 유닛 이코노믹스 → 고객당 비용(CAC), 프로덕트/기능당 비용 | • 리스크 관리 • 비즈니스 결과와 프로턱트 의사 결정을 연결 • 클라우드 인프라 비용이 기능/프로덕트 가격에 미치는 요인을 예측 가능 • 조직이 적절한 클라우드 투자를 할 수 있도록 가이드 |

 



 



 

남은 직무는 2편에서 계속됩니다!

milad_fakurian_tac7_TY_2_It_GA_unsplash.jpg

클라우드 비용 관리는 개발팀만의 과제? No! [1편]

### 태그 관리의 중요성

생성한 모든 태그는 유지 및 관리가 필수인데요. 태그는 시간이 지남에 따라 혹은 리소스에 따라 계속 수정되고 많아지기 때문에 태그를 삭제하거나 관리하는 프로세스가 필요합니다. 즉 변화하는 기업의 요구 사항에 따라 태깅 전략을 주기적으로 검토하고 수정하고 재설계해야 합니다.

특히 대규모 리소스를 사용하는 환경에서는 수천 개의 태그 키(Key)가 있기떄문에 올바른 태그를 지정하는데 혼란이 발생할 수 있습니다. 이와 같은 이유로 적절히 태깅된 리소스들을 계속 유지하기 위해서는 지속적으로 모니터링해야합니다. 

이번 글에서는 태깅을 유지하고 관리하는 가이드를 알려드립니다.

태깅에 대한 개념은 [이 글](https://www.costclipper.io/blog/5-tagging-strategies-cloud-cost-management)을 참고해주세요.


 



 



 



## 태그 관리 가이드
---

 ![](https://cdn.grumatic.com/strapi/tagging_strategy_guidance_a1e9f4dd29.png "가트너 제공")

## 1. 주기적인 태그 점검

주기적인 점검은 현재 어떤 태그가 사용되고 있고, 어떤 태그가 적절하지 않은지 확인하는데 도움이 됩니다. 그러려면 비용 & 사용 리포트를 보면서 각 태그의 키를 확인 하고, 사용하지 않는 태그를 언제든지 비활성화 할 수 있습니다.

또한 태그 시스템이 깨끗한지 확인해야합니다. 태그 환경이 더러워지면, 불완전한 데이터를 기반으로 의사 결정의 정확성이 떨어지기 때문입니다.

아래 사항을 꼭 확인해보시길 바랍니다.

- **잘못된 철자**
- **변화형 유의**
- **잘못된 약어**

이런 사항들은 자동화를 통한 태깅 정책을 강화하면서 개선이 가능합니다.

일부 리소스들은 불가피하게 누락되거나 잘못된 태그로 생성될 수 있기 때문에 더욱 태그를 표준화하고 정책화하여 클라우드 서비스에도 상관없이 잘 작동하도록 하는 것이 중요합니다.

 



 



 



## 2. 필요시 태그 업데이트

여러분의 팀의 대약폭이 연중 다양할 수 있지만 태그를 검토하는 “적절한” 시기가 반드시 있는 것은 아닙니다. 만약 기업에서 부서 통합과 같은 어떤 중요한 변화가 있다면 태그를 검토하고 업데이트하는 것이 가장 우선순위가 될 수 있습니다. 

주기적인 태그 점검과 함께 중요한 이슈나 변화가 있는 상황에도 태그를 업데이트 하는 것을 잊지마세요.
 

 




 




 


## 3. 태그 자동화

여러분의 조직에 맞는 태그를 표준화했다면, 자동화하여 그 표준을 실행할 수 있습니다. 먼저 누락된 태그 혹은 잘못 적용된 태그가 있는 리소스를 식별하는 것으로 시작합니다. 그 다음에는 리소스 담당자가 태깅 이슈를 해결하는 것이 좋습니다.


 




 



 


## 4. 태그 성능 측정

조직 내에서 태그 작업 방식을 확인하기 위해서는 태그가 잘못 적용된 곳를 식별하는 보고서가 있어야합니다. 태그 충당률은 할당된 태그와 할당되지 않은 태그와 함께 클라우드 비용을 기반으로 측정하는 것을 추천드립니다. 예를 들면 비용이 비싼 클라우드 리소스에 태그가 적용이 되었는지 확인하는 것입니다.

모든 리소스에 태그를 지정할 수 있는 것은 아니기 때문에 95%를 목표로 두고 태그가 지정되지 않은 남은 5% 프로세스를 개선하는 것이 더 현실적인 방법입니다.

이러한 종류의 보고서를 사용하면 팀에서 후속 조취 시에 자동화를 업데이트하거나 태그를 수동으로 수정 할 수 있습니다. 또한 시간이 지날수록 표준화된 태그와 일치하지 않는 리소스 수를 추적하여 내부적으로 태그 현황을 파악할 수 있습니다. 모든 사람이 볼 수 있도록 문제의 태그들을 리스트화하면 올바른 태깅 지정하도록 행동을 이끌어 내는데 도움이 되는거죠.

추가로 벤치마킹을 사용하면 태그를 지정하고 측정하는 것을 자연스럽게 향상시킬 수 있는데요. 또한 KPI(Key Performance Indicator)는 시간에따라서 리소스 사용과 이에 대한 가시성을 파악하는데 유용합니다.

예를 들면 아래와 같은 KPI를 만들 수 있습니다:

1. **(태깅이 가능한 리소스 중) 태그가 지정된 리소스의 %**

2. **표준을 준수하는 태그의 %**

3. **할당된 총 클라우드 비용의 %**

4. **할당된 공동 비용의 %**

5. **태그를 달 수 없거나 태그가 없는 비용의 할당 %**

위와 같은 예시를 바탕으로 태그에 대한 성과 혹은 성능을 측정해햐합니다. 클라우드 도입 초기 단계의 일반적인 목표는 80%리며 좀 더 성숙한 운영 단계에서는 90% 이상을 목표로 합니다. 더 나아가 자동화를 활용하여 표준화를 준수하지 않은 태그의 배포가 일어나면 워크로드 소유자에게 알림을 주는 것도 도움이 됩니다.


 



 



 


## 5. 태그가 지정되지 않은 리소스 수정

대부분의 클라우드 리소스는 태그 지정이 가능합니다. 올바른 프로세스 및 태그 지정 전략이 수립되면 태그 자동화를 통해 배포하는 동안 대부분의 태그 지정 가능한 리소스에 태그가 달립니다. 문제는 태그가 지정되지 않은 레거시 리소스에는 각 리소스에 레이블을 지정하고 추적하는 메타데이터를 수동으로 추가해야 한다는 점입니다.

이 "누군가"가 클라우드 지출에 대한 걱정보다 구축 및 코딩에 더 집중하는 엔지니어라면 대부분의 회사 시스템에서 리소스가 태그 없이 사용될 가능성이 크죠.

하지만 태그가 지정되지 않은 리소스의 비율은 회사의 태깅 전략에 따라 달라질 수 있습니다. 일부 회사는 클라우드 서비스에서 기본적으로 제공되는 태그를 그대로 사용합니다. 이러한 "기본 제공" 태그는 광범위한 항목을 포함하는 경우가 많기 때문에 수동 작업은 덜 필요하지만 세부 정보와 사용자 지정 측면에서는 부족합니다.

하지만 다른 한 쪽에서는 매우 상세하고 사용자 지정된 태그를 계속 사용할 수도 있습니다. 이 방법은 각 항목을 추적할 방법을 정확하게 선택할 수 있다는 점에서 유용하지만, 이러한 태그를 수동으로 선택하여 모든 개별 리소스에 할당해야 하는 경우에는 시간과 노력이 많이 들어갑니다.

다행히 태그가 달리지 않은 수 많은 리소스들에 사용자 지정 태그를 적용하다가 어려움이 생기면 언제든지 클라우드 서비스의 기본 태그로 되돌릴 수 있습니다.

수행하려고 했던 세부 정보는 손실되지만 태그가 지정된 항목의 비율을 빠르게 증가시키고 혼란을 해결하는 좋은 방법 중 하나입니다.


 



 



 


## 6. 태그를 달 수없는 리소스 수정

100% 목표 달성을 위한 최선의 노력에도 불구하고 완벽히 목표를 달성하기에는 어렵습니다. 물론 사용자의 잘못은 아닙니다. 그 이유는 일부 클라우드 리소스의 약 5%~10%는 태그를 지원하지 않기때문에 다른 항목과 동일한 방식으로 표시 및 추적할 수 없는 경우가 발생합니다.

여기서 문제를 더욱 복잡하게 만드는 것은 대부분의 클라우드 서비스의 인터페이스에서 태그가 지정되지 않은 리소스를 식별하는 것이 어려운 경우가 많다는 것인데요. 예를 들어 AWS는 태그 지정을 지원하지 않는 항목을 식별하는 명확한 방법을 제공하지 않습니다.

태그가 지정되지 않은 리소스를 추적하려면 일반적으로 태그가 지정되지 않은 리소스와 관련된 총 지출을 다른 범주에 할당해야 합니다. 이것은 담당자가 어떻게 지정하느냐에 따라 달라집니다.

예를 들어, 재무 담당자는 태그가 지정되지 않은 지출을 "오버헤드(Overhead) "와 같은 버킷으로 분류하기를 원할 수 있습니다. 그러면 "오버헤드"에는 태그가 지정되지 않은 리소스가 포함될 수도 있죠. 반면 엔지니어는 이런 특정 카테고리에 크게 신경쓰지 않습니다. 엔지니어는 태그가 달린 프로젝트의 비용과 태그를 달 수 없는 인프라를 묶은 비용과 비교하여 태그가 지정된 프로젝트의 비용이 어느 정도인지 알고싶어 합니다.

즉 재무 담당자와 엔지니어 사이의 서로 원하는 데이터와 태깅의 분류 방식도 다를 수 있기 때문에 방식을 함께 논의하여 정책을 정하는 것을 추천드립니다.

결국 그 이상으로 태그를 지정할 수 없는 비용에 대해서는 분석하기에는 어렵지만, 이 일반화된 정보를 통해 비용을 적절히 할당하고 알 수 없는 비용이 계속 발생하지 않도록 할 수는 있습니다.

**오버헤드, 인프라 또는 기타 유사한 버킷으로 정렬할 수 없는 항목은 기본 범주를 할당하는 것이 좋은데요.** 이렇게 하면 태그가 지정되지 않은 모든 항목이 지정된 범주에 모두 깔끔하게 들어맞지 않더라도, 완전히 주소가 없는 상태로 남아 있지는 않기 때문입니다.

**또한 태그 없는 지출을 하나의 버킷으로 묶는 대신 다양한 제품 또는 팀에 분산시킬 수도 있습니다.** 모든 팀과 제품에 태그 없는 지출을 균등하게 배분하여 비용 부담을 일부 감당하도록 하는 것입니다. 이러한 방식으로 태그가 없는 비용은 공유 오버헤드로 처리됩니다.

또는 자신에게 적합한 특정 범주에 비례하는 양을 할당할 수 있습니다. 예를 들어, 어느 한 팀에서 클라우드에 가장 많은 비용을 지출하는 경우 태그 없이 적절한 금액을 부담할 수 있습니다.


 




 



 


### 결론
정확한 데이터 및 비용 할당을 보장하려면 퍼블릭 클라우드 태깅을 유지하는 것이 중요합니다. 여기에는 주기적으로 태그를 감사하고, 필요할 때 태그를 업데이트하고, 자동화를 사용하여 태그 표준을 적용하고, KPI를 통해 태그 성능을 측정하는 작업이 포함됩니다. 수동으로 메타데이터를 추가하거나 기본 범주를 할당하여 태그 없는 리소스 및 태그 없는 리소스를 수정할 수도 있습니다. 팀에서 태그를 지정하는 것의 중요성을 알리고 태그 지정 현황을 지속적으로 모니터링하고 추적하여 개선해야 할 부분을 식별하는 것이 중요합니다.


 




 




 


앞으로도 유용한 클라우드/AWS 정보와 함께 찾아오겠습니다.

효율적인 AWS 인프라 관리부터 비용 절감까지, CostClipper가 함께합니다.

milad_fakurian_gph_L7_D_r_Mp_M_unsplash.jpg

퍼블릭 클라우드 태깅 관리 6단계 가이드

AWS EC2는 기본적으로 사용한만큼 요금을 지불하는 온디맨드로 제공되지만, 예약 인스턴스(Reserved Instance) 혹은 Savings Plan같은 할인 플랜을 구매하면 최대 66 -72%까지 비용 절감 가능합니다. 

두 가지 플랜에 대한 자세한 분석 및 비교는 [이 글](https://www.costclipper.io/rireserved-instance-vs-savings-plan)에서 보실 수 있습니다.

그런데 RI/SP 구매만하면 기업의 1년 혹은 3년 동안 비용 걱정이나 관리는 안해도 될까요?

그렇지 않습니다!

할인 정책을 구매시에는 구매 옵션에 따라 인프라 지출 금액이 달라지기 때문에 비용 계산 시 주의가 필요합니다.

**선택하는 기간(1년/3년)과 결제 방식(선결제 없음/부분 선결제/전체 선결제)에 따라 월간/연간 인프라 지출의 금액도 크게 달라진다는 것인데요.** 때문에 AWS에서는 할인 정책 구매에 따라 비용 이해를 돕고자 5가지의 데이터 세트를 제공하고 있습니다. 

- 비혼합 비용 (Unblended costs)
- 분할 납부 비용 (Amortized costs)
- 혼합 비용 (Blended costs)
- 순 비혼합 비용 (Net unblended costs)
- 순 분할 납부 비용 (Net amortized costs)

하지만 많은 기업에서는 단순히 RI를 구매하고 사용만하는 경우가 대다수인데요. 이 5가지 데이터 세트를 이해하면 더 정확한 비용 파악 및 관리가 가능하기 때문에 AWS 비용 구조를 자세히 이해할 필요가 있습니다.

![](https://cdn.grumatic.com/strapi/aws_cost_options_0cebc3002a.png "AWS Cost Explorer, AWS Budgets 설정 가능") 

AWS는 비용에 대해 5가지 옵션을 설정하여 볼 수 있도록 제공하고 있으며 [AWS Cost Explorer](https://docs.aws.amazon.com/ko_kr/cost-management/latest/userguide/ce-what-is.html), [CUR](https://docs.aws.amazon.com/cur/latest/userguide/what-is-cur.html)(Cost and Usage Report), [AWS Budgets](https://docs.aws.amazon.com/ko_kr/cost-management/latest/userguide/budgets-managing-costs.html)에서 확인 및 옵션 적용이 가능합니다.
> 


 



 



 


### Contents

:::toc
[1. AWS 비용 및 계정 구조](#aws-cost-structure)
[2. 비혼합 요금 (Unblended costs) vs 혼합 요금 (Blended costs)](#unblended-cost-vs-blended-cost)
[3. 비혼합 비용 (Unblended costs) vs 분할 납부 비용 (Amortized costs)](#unblended-cost-vs-amotized-cost)
[4. 순 비혼합 비용 (Net unblended costs)](#net-unblended-costs)
[5. 순 분할 납부 비용 (Net Amortized Costs)](#net-amortized-costs)
[6. 기업에서 중요한 비용 집계는?](#which-is-important)
:::

 



 



 


## 1. AWS 비용 및 계정 구조 {#aws-cost-structure}

---

비용 옵션을 이해하기 위해서는 AWS에서 사용하는 기본적인 계정과 비용 구조 이해가 필요합니다.

AWS는 전체 계정의 요금 및 사용량, 예약 인스턴스 등 모든 비용을 하나의 청구서에 합치는 **통합 결제 (Consolidated Billing)** 방식을 가지고 있습니다. 즉 **하나의 계정으로 통합하여 결제하는 것**입니다.

 ![](https://cdn.grumatic.com/strapi/account_diagram_2b6213727c.png "AWS 웹사이트 제공") 


그리고 계정을 하나의 청구서로 통합하여 결제하는 경우 일부 서비스(EC2, S3 등)의 시간당 유효 요금을 낮춰주는 **대량 할인**(Volume Disccount)을 제공합니다. **사용량이 많은 서비스의 경우 티어별로 할인을 해주는 것**입니다.

AWS는 두 가지 계정으로 이루어져 있습니다.

- 전체 멤버 계정의 비용을 지불하는 **관리 계정(Payer Account)**
- 서비스를 사용하는 **멤버 계정(Linked Account)**

RI를 사용하는 경우 통합 계정에 연결된 계정에도 공유가 가능합니다. 구매한 RI 속성과 일치하는 인스턴스에 자동으로 적용 되며, SP 또한 동일하게 다계정 간의 혜택이 공유됩니다. 

이러한 이유로 할인 적용 점위에 따라 계정별 요금이 달라 질수 있기 때문에 각 비용을 정확히 파악하는 것이 중요합니다.


 




 



 



 


## 2. 비혼합 요금 (Unblended costs) vs 혼합 요금 (Blended costs) {#unblended-cost-vs-blended-cost}

---

### 비혼합 요금이란?

비혼합 요금(Unblended costs)이란 **AWS에서 사용한 리소스의 사용량에 따라 과금되는 요금 체계**를 의미합니다. 즉, **사용한 만큼 비례하여 요금이 부과되는 것**입니다. AWS Cost Explorer와 AWS Budgets 에서 기본으로 적용되는 옵션입니다.

비혼합 요금의 경우는 RI나 대량 할인을 분리해서 보여주기 때문에 계정별로 혹은 서비스별로 할인 항목을 볼 수 있습니다. 예를 들어 부서 혹은 팀에 따라 계정을 다르게 사용하는 경우에는 부서별로 비용을 파악하기에 용이합니다.

때문에 AWS에서는 대부분의 서비스에서 비혼합 요금을 적용하고 있으며, 비혼합 요금을 잘 이해하고 파악해야 비용을 낭비하지 않고 효율적으로 사용할 수 있습니다.


 




 


### 혼합 요금이란?

혼합 요금(Blended costs)이란 **사용한 시간에 따라 청구되는 비용을 RI 할인, 대량 할인 등의 할인 요소를 모두 반영한 요금**입니다.

즉, AWS에서 제공하는 서비스를 사용하면서 발생하는 비용을 종합적으로 계산하여 청구하는 방식인데요. 이 방식은 서로 다른 서비스를 사용하면서 발생한 비용을 하나의 청구서로 합산하여 고객에게 청구합니다.

MSP(Managed Service Provider)를 이용하는 고객의 경우 MSP를 통해 할인이 적용된 후의 총 금액을 결제하는데 고객사가 결제하는 이 금액이 바로 혼합 요금입니다. MSP가 (할인 적용 전에) 보는 고객사의 금액은 비혼합 요금입니다.


 




 



 



 


## 3. 분할 납부 요금 (Amortized) vs 비혼합 요금 (Unblended) {#unblended-cost-vs-amotized-cost}

---

### 분할 납부 요금이란?

**분할 납부 비용**(Amortized cost)이란 **RI 비용을 구매한 사용 기간(1년 or 3년)에 맞추어 균등하게 분배한 금액**입니다.

분할 납부 비용은 RI를 전체 선결제/부분 선결제로 구매한 경우에 용이한 옵션으로, 연간 인프라 비용을 월/일별로 계산하여 서버 운영 금액의 추이를 정확하게 볼 수 있습니다.

예를 들면 , 1년 동안 전체 선결제로 RI를 $365를 지불하고 분할 납부 비용을 적용하면 해당 인스턴스는 하루에 $1의 비용을 지불하고 사용하는 것입니다. 그리고 이것을 시간으로 나누면 일별로 나누어 $0.416으로 계산합니다.


 



 


### 비혼합 요금 (Unblended) vs 분할 납부 요금 (Amortized)

두 가지 방식에는 각기 장단점이 있지만, RI를 사용하는 경우 **정확한** **클라우드 비용 관리를 위해서는 분할 납부 비용을 함께 보는 것이 정확합니다.** 쉬운 이해를 위해 두 가지 방식을 간단하게 비교해보겠습니다.

기업에서 아래와 같은 옵션으로 EC2 RI를 구매했다고 가정해봅시다.

- **1년**
- **$ 12,000**
- **전체 선결제 (All Upfront)**

 ![](https://cdn.grumatic.com/strapi/cost_comparison_37f4c3a6fd.png) 

비혼합 비용으로 본다면 전체 선결제로 구매했기 때문에 1월 지출로 잡힐 것입니다. 이 방식은 현금 흐름을 쉽게 추척할 수 있다는 점에서 간단하고 쉬운 방법입니다. 

반면 분할 납부 비용으로 보았을 때는 RI 사용을 1년/전체 선결제옵션으로 구매했기 때문에 비용을 사용 기간만큼 균등하게 배분하여 월 비용을 $ 1,000으로 집계합니다.

예시는 이해를 돕기 위해 단순하게 가정했지만 다른 서비스도 함께 이용하는 경우는 어떻게 될까요?

비혼합 비용의 경우 1월만 비약적으로 높은 비용이 청구되고 남은 월은 다른 서비스만 집계될 것입니다. 남은 11개월 간 RI를 사용하고 있지만 비용은 0으로 잡히기 때문에 다른 서비스 비용만 집계 되어 추이를 알기에는 어렵습니다.

![](https://cdn.grumatic.com/strapi/cost_example_be8a7d18c5.png "AWS 웹사이트 제공") 

위의 예시처럼, 분할 납부으로 집계하면 균등하게 분배된 RI에 다른 서비스 비용이 함께 계산되기 때문에 **월 별 서비스 지출 증감에 대한 흐름을 더 정확하게 확인 가능합니다.** 

흐름을 파악할 수있다는 건 **기간별 비용과 미래 현금 흐름 예측도 더욱 명확하게 가능하다는 장점이 있습니다. 또한 특정 기간의 경영 성과 즉 매출 대비 인프라 비용 파악에도 용이한 방식으로 볼 수 있습니다.**


인프라 비용 관리에 있어서 월별/일별 사용량 및 지출을 파악하는 것은 IT 예산을 수립하거나 예측함에 있어 매우 중요한 부분입니다. 

**클라우드를 직접 사용 및 관리하는 IT팀과 회계팀 간의 혹은 이해관계자 사이에서 보다 정확한 논의를 위해서 이제는 비혼합 비용만이 아닌 분할 납부 비용도 함께 비교하며 활용하시길 추천드립니다.**



 




 



 



 


## 4. 순 비혼합 비용 (Net unblended costs) {#net-unblended-costs}

순 비혼합 비용(Net unblended costs)은 **EDP (Enterprise Discount Program), 크레딧과 같은 할인을 적용한 비용**을 말합니다.

여기서 **EDP란** **AWS에서 제공하는 할인 프로그램**으로 (정확한 할인율은 명시하고 있지는 않으나) RI 혹은 SP를 대량으로 구매하는 경우 추가적으로 제공하는 할인을 말합니다.


 




 



 



 


## 5. 순 분할 납부 비용 (Net amortized costs) {#net-amortized-costs}

순 분할 납부 비용(Net amortized costs)은 **선결제 및 월별 RI 요금을 분할할 때, RI 대량 구매 할인 혹은 EDP (Enterprise Discount Program) 같은 할인을 적용한 비용**입니다.


 




 



 



 


## 6. 기업에서 봐야하는 비용 데이터는? {#which-is-important}

결론적으로는 예약 인스턴스를 사용하는 기업이라면 **비혼합 비용 (Unblended costs)과 분할 납부 비용 (Amortized costs)을 함께 비교하는 것이 좋습니다.** 

**실제 현금 흐름과 인프라 비용 추세를 함께 확인할 수 있기 때문이죠. 보다 정확한 클라우드 비용 관리를 위해서는 꼭 필요한 비교군입니다.**

**반면 RI를 사용하지 않는다면 비혼합 비용을 보시는 것을 추천드립니다.** 기업의 규모가 크거나 전문적인 클라우드 전담팀이 있는 경우에는 혼합 비용을 포함한 **세 가지 집계 방식을 모두 활용하여 비용을 분석하는 것이 필요합니다.**


 




 



 


이번 글에서는 클라우드 비용 관리에 있어 보다 정확한 이해를 위해 AWS 비용 구조를 분석해보았습니다.

바로 적용 가능한 비용 최적화 방법을 아는 것도 중요하지만 

AWS에서 제공하는 비용 관련 용어나 서비스를 이해하고 활용해보는 것도 좋은 시작입니다.


 




 


앞으로도 유용한 클라우드/AWS 정보와 함께 찾아오겠습니다.

효율적인 AWS 인프라 관리부터 비용 절감까지, CostClipper가 함께합니다.

milad_fakurian_0_O_Dr49s_X_Vk_A_unsplash.jpg

AWS 혼합, 비혼합, 분할 납부 비용 차이점

태깅의 일관성은 클라우드 관리를 위한 가장 중요한 전략 중 하나입니다. 주요 클라우드 서비스 공급자가 태깅에 대한 정책 및 표준 개발을 지원하기 위한 지침과 고려 사항을 제공하지만 범용 클라우드 태깅에 대한 "*글로벌 표준*"은 없습니다. 본 블로그에서는 효과적인 태깅 관리를 위한 태깅 표준의 예시를 소개하고자 합니다.


 




 


### 태깅 표준화의 필요성
---

태그를 가장 효과적으로 사용하는 회사는 일반적으로 비즈니스 관련 태그 그룹을 생성하여 기술, 비즈니스 및 보안 차원에 따라 리소스를 구성합니다. 비용 할당은 클라우드 재무 관리에 필수적입니다. 태그, 연결된 계정, 폴더 또는 레이블을 통해 효과적으로 수행할 수 있습니다. 태그, 레이블 및 계정은 많은 이점을 제공하지만 한 가지 주요 이점은 비용 할당을 위해 청구 데이터에 비즈니스 차원과 컨텍스트를 추가한다는 것입니다. 비용 할당 측면에서 리소스에 태그를 지정하는 두 가지 주요 방법인 범주화 및 계층적 접근 방식을 소개하려고 합니다.



 




 


### 태그 분류
---

#### 1. 기술 태그

엔지니어가 리소스를 식별하고 작업하는 데 도움이 됩니다. 여기에는 애플리케이션 또는 서비스 이름, 환경 또는 버전 번호가 포함될 수 있습니다.

| Keys | Definition |
| --- | --- |
| Name | Identify individual resources |
| Application ID | Identify resources that are related to a specific application |
| Application Role | Describe the function of a particular resource (such as web server, message broker, database) |
| Cluster | Identify resource farms that share a common configuration and perform a specific function for an application |
| Environment | Distinguish between development, test, and production resources |
| Version | Help distinguish between versions of resources or applications |


 


 


#### 2. 자동화 태그
계정의 각 리소스에 대한 정리, 종료 또는 사용 규칙을 자동화하는 데 사용할 수 있습니다. 예를 들어 더 이상 사용하지 않는 샌드박스 서버에 태그를 지정하고 스크립트를 실행하여 삭제할 수 있습니다.

| Keys | Definition |
| --- | --- |
| Date/Time | Identify the date or time a resource should be started, stopped, deleted, or rotated |
| Opt In/Opt out | Indicate whether a resource should be included in an automated activity such as starting, stopping, or resizing instances |
| Security | Determine requirements, such as encryption or enabling of Amazon VPC flow logs; identify route tables or security groups that need extra scrutiny |


 




 


#### 3. 비즈니스 태그
비지니스 태그를 이용하여 이해 관계자는 비용과 각 리소스를 담당하는 팀 또는 비즈니스 단위를 분석할 수 있습니다. 예를 들어 작년에 출시한 새 제품에 클라우드 비용 중 몇 퍼센트가 사용되는지 알고 싶을 수 있습니다. 그러면 해당 노력의 투자 수익을 확인할 수 있습니다.

| Keys | Definition |
| --- | --- |
| Project | Identify projects that the resource supports |
| Owner | Identify who is responsible for the resource |
| Cost Center/Business Center | Identify the cost center or business unit associated with a resource, typically for cost allocation and tracking |
| Customer | Identify a specific client that a particular group of resources serves |


 




 

#### 4. 보안 태그 
보안 태그는 규정 준수 및 보안 표준이 조직 전체에서 충족되도록 합니다. 이러한 태그는 액세스를 제한하거나 많은 규정 준수에 대한 특정 데이터 보안 요구사항을 나타내는 데 사용될 수 있습니다.


 

| Keys | Definition |
| --- | --- |
| Confidentiality | An identifier for the specific data confidentiality level a resource supports |
| Compliance | An identifier for workloads that must adhere to specific compliance requirements |


 




 




 


### 계층 기반 접근 방식
---

계정은 상호 배타적이지만 태그는 그렇지 않습니다. 계정은 기본 색인으로 사용해야 하며 라벨은 보조 색인으로 상인합니다. 일반적인 모범 사례에서 조직은 계정을 사용하여 가장 중요한 기본 부서를 분할한 다음 태그를 사용하여 보다 세분화된 가시성을 위해 해당 계정을 더욱 깊이 분석할 수 있습니다.

 ![](https://cdn.grumatic.com/strapi/account_diagram_2b6213727c.png) 

계정을 사용하여 개별 제품 및 해당 환경을 분류할 수 있습니다. 서로 다른 제품 또는 애플리케이션은 종종 서로 다른 비용 센터 또는 예산을 나타내기 때문에 이는 중요합니다. 일부는 COGS 비용이고 일부는 R&D이므로 별도의 환경(개발, 생산, 스테이징 등)은 재무 팀에서 다르게 설명해야 할 수 있습니다. 또한 다양한 팀에서 생산 비용과 개발 비용을 함께 그룹화하여 자금이 어디로 가는지 확인하거나 비용 최적화를 위해 서로 다른 정책을 적용할 수 있습니다.


 




 




 

### 리소스 이름 지정 표준화
---

범용 클라우드 리소스에 이름을 할당하는 것은 고려해야하는 중요한 태깅 전략입니다. 불행히도 모든 회사에 대한 공통 표준은 없습니다. 리소스에 대한 명명 표준을 개발하면 리소스를 체계적으로 유지하는 데 도움이 되며 클라우드 비용 보고서에서 관련 리소스를 함께 그룹화하는 데 사용할 수 있습니다.

각 태그는 각 자산에 대한 고유 ID와 리소스에 추가된 다른 모든 태그를 이해할 수 있는 링크를 제공해야 합니다. 다중 테넌트 다중 클라우드 환경의 일반적인 예는 다음과 같습니다.

**[CSP]-[business unit]-[application id]-[environment]-[sequence]**

| Value | Description | # characters | Source | Description |
| --- | --- | --- | --- | --- |
| CSP | cloud service provider: aws, gcp, azr, etc | 3 | Fixed | CSP name |
| Business Unit | grp, uk, de, es, it.. | 2 | Fixed | Highest level of organization mapping |
| Application id | application id (web, wrk..) | 2-10 | Selected | Optional as it could change over time |
| environment | environment: prd, dev, stg | 3 | selected | use acronyms or abbreviations aligned to environment strategy |
| sequence | numerical sequence: 01, 02, 03 etc | 2 | selected | delimited numbers make each resource unique |

Example:

***aws-kr-web-prd-01***


 




 




 


### 멀티 클라우드의 어려움
---
각 클라우드 공급자는 서로 다른 용어와 서로 다른 태그 제한을 사용합니다. 예를 들어 AWS는 "키(Key)/값(Value)" 쌍을 "태그(Tag)"로 참조하고 GCP는 "라벨(Label)"을 사용합니다. 다중 클라우드 서비스를 사용하는 경우 여러 클라우드 서비스에서 리소스에 대한 일관적인 가시성를 제공해 줄 수 있는 좋은 다중 클라우드 관리 도구가 있어야 합니다.

주요 클라우드 서비스 회사에서 사용하는 태그의 주요 차이점은 아래 표에 요약되어 있습니다. 모든 클라우드 서바스에서 사용할 수 있는 공통적인 부분을 멀티 클라우드 전략으로 만들어야 합니다.

| | AWS | Google Cloud Platform | Microsoft Azure |
| --- | --- | --- | --- |
| Hierarchy | Linked accounts | Folders and projects | Subscriptions |
| Key/value pairs | Tags | Labels | Tags |
| Number of tags per resource | 50 (some services allow only 10) | 64 | 50 (some services allow only 15) |
| Tag key length | 128 | 63 | 512 |
| Tag value length | 256 | 63 | 256 |
| Format | unicode characters
(UTF-8 and .:+-@_/-(hyphen) | alphanumeric
(UTF-8 and - _ can include international character) | |
| Excluded | | | cannot contain: <, >, %, & , \, ?, / |
| Tags automatically allocated to your detailed billing data | NO - manual selection required | Yes - some limit apply | Yes - some limits apply |


 


 


## 태그 표준 문서
---
클라우드 태깅 규칙은 문서화되어야 하며 회사에서 사용하는 태깅 전략의 정책을 다루어야 합니다. 이 문서는 주로 사용 중인 태그, 태그 책임자 및 각 태그에 포함된 값을 나열해야 합니다.

또한 태깅 정책이 무엇이고 무엇을 하는지 문서화해야 합니다. 이 문서는 중앙화되어 공유되고 책임자에게 승인을 받아야 합니다.

이상적으로 FinOps 팀이 태깅 정책, 해당 문서 및 구현 진행 상황에 대한 개요를 제공하기 위한 중앙 도구를 갖추고 있는 것이 좋습니다. 이 중앙 리포지토리는 팀이 회사의 태깅 전략 및 거버넌스의 완전성을 보장하는 데 도움이 됩니다.

아래 표는 태깅 및 라벨링 표준의 예시입니다.

| Key | Compliance | Description | Attachment | Allowed Values | Relevance | Example |
| --- | --- | --- | --- | --- | --- | --- |
| name | mandatory | | Account and Resources | Naming convention | Biz, Dev, Sec, Ops | aws-kr-web-prd-01 |
| application_id | recommended | Application ID | Account or Resources | variable | dev | web_worker_1 |
| application_role | mandatory | Application Role | Account or Resources | variable | dev | worker |
| cluster | recommended | Cluster name | Account or Resources | Naming conventions | dev | web |
| env | mandatory | Environment | Account or Resources | production, staging, development | dev | development |
| tech_owner | recommended | Architect or Technical Lead | Account or Resources | email address | dev | tech@example.com |
| project_owner | recommended | Delivery Lead | Account or Resources | email address | biz | porj@example.com |
| budget_owner | recommended | Person or team responsible for payments | Account or Resources | email address | biz | budget@example.com |
| project | mandatory | Project name | Account or Resources | variable | biz | web server |
| cost_center | mandatory | cost allocation and reporting | Account or Resources | variable | biz | GRMT1093 |
| confidentiality | mandatory | Data Classification | Account or Resources | C1, C2, C3, C4, Secret | sec | c1 |
| tag_version | mandatory | Naming, labeling and tagging policy version | Account or Resources | vX_X | ops | v1_0 |

필수 태그는 모든 계정과 리소스에 적용되어야 하며 권장 태그는 필요한 경우 적용됩니다. 선택적 태그에는 특정 유형의 리소스 또는 사용 사례에만 적용될 수 있는 리소스 관련 키가 포함될 수 있습니다. 준수 수준은 자동화된 보고 분류 및 준수 위반의 심각도를 정의합니다. 경우에 따라 컴퓨팅 또는 스토리지와 같은 공통 리소스에 대한 특정 하위 표준을 정의할 수 있습니다. 여기에는 이러한 리소스 관리에 도움이 되는 보다 자세한 보안 및 운영별 레이블이 포함될 수 있습니다.


 




 




 


### 결론
태깅 업무는 중앙화된 표준 문서가 필요합니다. 표준 문서에 따라서 태그의 생성, 수정, 주기적인 유지/보수 및 오류 감시를 해야 하여 보다 정확한 태그를 클라우드 자원에 지정하도록 하는 것이 중요합니다. 정확한 태그를 유지해야 정확한 클라우드 비용 지출 데이터에 대한 가시성을 확보하고 올바른 의사결정이 가능합니다. 


 




 




 


앞으로도 유용한 클라우드/AWS 정보와 함께 찾아오겠습니다✨

nathan_watson_Qerg85_B7_JDI_unsplash.jpg

클라우드 비용 할당을 위한 태깅 표준화 방법

이 글은 Forbes에서 Bernard Marr가 기고한 “The Top 5 Cloud Computing Trends In 2023” 글을 바탕으로 내용을 읽기 쉽게 의역 및 내용 추가했음을 알려드립니다. [원문 보러가기 >](https://www.forbes.com/sites/bernardmarr/2022/10/17/the-top-5-cloud-computing-trends-in-2023/?sh=4ae596a94648)

---


 


[가트너에 따르면](https://www.gartner.com/en/newsroom/press-releases/2022-10-31-gartner-forecasts-worldwide-public-cloud-end-user-spending-to-reach-nearly-600-billion-in-2023), 2023년에는 클라우드 시장 규모가 5,918억 달러로 전년도 보다 18.8%나 증가할 것으로 예상했습니다. 최근 **국내의 경우** 금융권의 경우 내년 1월부터 클라우드 전환에 관련한 [규제 완화](https://www.dnews.co.kr/uhtml/view.jsp?idxno=202211211044028800654)가 예고되었고, [정부/공공](https://www.mk.co.kr/news/it/10437191) 부문도 올해 역대 최고치인 1조 2332억원의 규모로 성장하면서 클라우드는 더 넓은 산업으로 확대되고 있습니다.


 


2023년 초반의 경기 침체에도 불구하고 클라우드 컴퓨팅은 인공지능(AI), 증강 현실(VR/AR), 머신 러닝 등 혁신적인 기술의 핵심으로 디지털 혁신을 이끌어 가고 있는데요.


 


남은 2023년의 클라우드는 어떤 모습일까요?

**CostClipper가 포브스가 선정한 클라우드 트렌드를 쉽게 분석해드립니다.**


 



 


:::toc
[1. 클라우드 보안, 복원에 대한 투자 증가](#클라우드보완,복원에대한투자증가)
[2. 여전한 멀티 클라우드의 성장](#여전한멀티클라우드의성장)
[3. 클라우드 기반 AI와 ML](#클라우드기반AI와ML)
[4. 로우코드/노코드 클라우드 서비스](#로우코드/노코드클라우드서비스)
[5. 클라우드 게임의 혁신과 통합](#클라우드게임의혁신과통합)
:::


 


 


## 1. 클라우드 보안, 복원에 대한 투자 증가 {#클라우드보완,복원에대한투자증가}
---
 ![Cloud Security](https://www.securitymagazine.com/ext/resources/images/cloud-sec-freepik1170x658x4.jpg?1645204310 "출처: www.securitymagazine.com")

많은 기업이 클라우드로의 마이그레이션을 통해 디지털 확장과 효율성, 편의성을 가질 수 있습니다. 하지만 기존과는 다른 범위의 사이버 보안 위협에 노출되는 것도 사실입니다. 

여기에, 기업이 개인의 데이터를 어떻게 저장하고 사용할 것인지에 대한 법안이 계속 생기고 있는데요. 기업 입장에서는 고객의 신뢰를 잃거나 큰 금액의 벌금을 낼 수 있는 현실적이고 중요한 문제를 갖고 있습니다.

때문에 포브스는 **클라우드** **보안과 데이터 손실에 대한 대비책으로 복원 시스템을 구축하는 것**이 가장 우선 순위가 될 것으로 예측했습니다. 하지만 경기 침체 상황에서 많은 기업들의 클라우드 비용 절감이 예상됨에 따라, 보안을 유지하는데 비용 효율적인 방법을 찾는 것에 중점을 둘 것으로 보았습니다.

나아가 보안 및 복원 투자 증가는 문제가 발생하기 전에 탐지 가능한 AI와 예측 기술과 “서비스형 보안 기업, *S*ecurity-as-a-service(**SECaaS**)”의 성장을 예고했습니다.



 




 




 




 




 


## 2. 여전한 멀티 클라우드의 성장 {#여전한멀티클라우드의성장}
---
![](https://cdn.grumatic.com/strapi/multi_cloud_632711c481.png "VM웨어, 멀티 클라우드 성숙도 연구 보고서(Multi-Cloud Maturity Research Report")
 
2022년이 하이브리드 클라우드의 해였다면 2023년은 기존보다 향상된 유연성과 보안이 강점인 멀티 클라우드의 해가 될 것입니다.

멀티 클라우드는 조직이 하나의 특정 인프라에 의존하거나 얽매이는 것을 방지할 수 있습니다. 또한 이중화된 구조로 운영하면 서비스 운영에 장애나 오류 발생의 가능성을 줄일 수 있다는 큰 장점이 있죠.

결국 하나의 특정 클라우드 플래폼을 중심으로 애플리케이션 및 프로세스를 구축 시에 발생할 수 있는 문제에서 벗어날 수 있다는 의미인데요. 컨테이너형 애플리케이션의 인기가 증가함에 따라서 기업의 서비스가 바뀌거나 다른 CSP보다 더 비용 효율적인 솔루션을 사용하고 싶다면 애플리케이션을 새로운 플랫폼으로 신속하게 옮길 수도 있습니다.

2020년에는 많은 기업(70%)이 하나의 클라우드 서비스에 묶여 있었지만 보고서에 따르면 2023년까지 중견기업의 84%가 멀티 클라우드 전략을 선택했고 다음 해의 중요한 트렌드로 예측했습니다.

VM웨어 보고서에 따르면 멀티 클라우드가 주류로 자리잡으면서 아태지역 중에서도 한국이 다른 국가보다 멀티 클라우드 사용률이 높게 나타났습니다. 앞으로 한국에서의 멀티 클라우드는 더욱 성장하고 성숙해질 것으로 예측됩니다.


 




 




 




 


## 3. AI & ML기반 클라우드 {#클라우드기반AI와ML}
---
 ![](https://cdn.grumatic.com/strapi/AL_4e5e3acff6.png) 

인공지능(AI)과 머신러닝(ML)을 클라우드 서비스로 제공하는 것이 어려운 이유는 자체 AI 인프라를 구축할 수 있는 자원을 보유한 기업은 많지 않기 때문인데요. 데이터을 수집하거나 및 알고리즘을 학습시키려면 막대한 컴퓨팅 성능과 스토리지 공간이 필요합니다.

AWS, GCP, Azure와 같은 클라우드 제공 업체(CSP)에서도 많은 작업을 처리하기 위해 AI에 점점 더 의존하고 있습니다. 고객에게 스토리지 리소스를 제공하는데 필요한 광범위한 분산 네트워크 관리부터 데이터 센터의 전원 및 냉각 시스템을 통제하고 데이터를 안전하게 보관하는 보안 작업도 포함되어 있죠.

2023년에는 아마존, 구글, 마이크로소프트와 같은 초대형 클라우드 제공 업체들이 고객을 위해 보다 효율적인 클라우드 서비스를 만들기 위해 자체적인 AI 기술을 개발하고 적용하면서 이 분야의 지속적인 혁신을 기대하고 있습니다.

이미 Chat GPT의 등장으로 IT산업 전체가 큰 변화와 충격을 맞이했습니다. 시장 분석 기관인 세미애널리스에 따르면, Chat GPT를 만든 오픈 AI는 하루 최대 70만달러, 한화로는 거의 10억에 육박하는 클라우드 금액을 매일 지출하고 있는데요. 오픈 AI에 투자한 마이크로소프트는 애저 오픈 AI 서비스를 출시하면서 개발자가 Chat GPT를 유연하게 애플리케이션에 적용까지 가능합니다. 


 


이처럼 2023년 이후에도 AI와 클라우드는 더 긴밀한 관계를 맺어 갈것으로 예상됩니다.


 



 




 




 




 


## 4. 로우코드/노코드 클라우드 서비스 {#로우코드/노코드클라우드서비스}
---

 ![](https://cdn.grumatic.com/strapi/111_79d13de10a.png) 

이제는 누구나 컴퓨터 코드 없이도 애플리케이션을 만들고 데이터를 사용해 문제를 해결할 수 있는 툴과 플래폼이 더 인기가 많아 지고 있습니다. 기업에서 필요한 어떤 디지털 서비스를 디자인하거나 웹 사이트 혹은 웹 애플리케이션을 구축하는 툴 모두 로우코트/노코드로 가능한 범주가 되었습니다.

나아가 로우코트/노코드 솔루션으로 AI기반 애플리케이션을 만드는 정도까지 발전하여 기업에 AI, ML을 활용하고자 하는 진입 장벽또한 함께 낮아지고 있어요. 그런데 이런 서비스의 대부분은 클라우드 형태로 제공합니다.

즉, 사용자는 다음 작업에 필요한 컴퓨터 인프라를 가지고 있지 않아도 서비스로 접근 가능할 수 있습니다. 예를 들면 Figma, Airtable, Zoho와 같은 툴은 사용자들이 웹사이트 설계, 스프레드시트 작업 자동화, 웹 애플리케이션 구축 같은 작업을 이제는 코딩 없이 가능하게 해주죠. 2023년에도 계속해서 코딩 장벽을 낮춰주는 로우코드/노코드 솔루션의 기술은 더 발전할 것으로 예상됩니다.


 




 




 





 


## 5. 클라우드 게임의 혁신과 통합 {#클라우드게임의혁신과통합}
---

 ![](https://cdn.grumatic.com/strapi/cloudgame_3534d7552f.png) 
 
클라우드는 넷플릭스(Netflix)와 스포티파이(Spotify)와 같은 스트리밍 서비스를 가능하게 했고, 우리가 영화, TV, 음악을 소비하는 방식에 혁신을 일으켰습니다. 비디오 게임 스트리밍은 기반을 만드는데 시간이 조금 더 걸리지만 마이크로소프트(MS), 소니(Sony), 엔비디아(Nvidia), 아마존(Amazon)이 모두 이 분야에서 서비스를 제공하기 때문에 지속적으로 발전하고 있습니다.

하지만 모두 순조롭게 진행되는 건 아니었는데요. 구글은 스타디아 (Stadia) 스트리밍 게임을 개발하는데 수백만 달러를 썼지만 상업적으로 성공하지 못했고 올해 이 서비스를 중단했습니다. 큰 문제 중 하나는 네트워크였습니다.


비디오 게임 스트리밍은 음악이나 비디오보다 높은 대역폭이 필요하기 때문에 고품질의 초고속 인터넷 액세스를 가진 사람들에 한해서만 제공 가능합니다. 우리에게는 아직도 조금은 먼 얘기죠.

하지만 5G와 다른 초고속 네트워킹 기술의 지속적인 출시는 결국 이 문제를 해결하고 2023년은 클라우드 게임이 영향을 미칠 수 있는 해가 될 수 있을 것으로 예측했습니다.

구글은 스타디아를 지원하는 기본 기술은 게임 개발자가 고객에게 직접 스트리밍 기능을 제공하는 B2B 게임 스트리밍 서비스에 적용하여 계속 살아남을 것이라고 말했습니다. 비디오 스트리밍이 4G, 음악 스트리밍이 3G인 것처럼 클라우드 게임이 5G를 통해 “킬러 앱”으로 성장할 것으로 보입니다.


 




 


이번 글에서는 포브스 선정 2023 클라우드 트렌드를 분석해보았는데요. 클라우드 산업의 트렌드를 알아보고 새로운 비즈니스 기회를 발견하거나 경쟁력을 강화하는 인사이트를 얻는데 활용해보세요✨


 


앞으로도 유용한 클라우드/AWS 정보와 함께 찾아오겠습니다.

li_zhang_x_RR_Ql_R8_Qu_Y_unsplash.jpg

2023년 하반기 클라우드 TOP 5 트렌드

### 태그란 무엇인가?

---

AWS, Azure, Google GCP와 같은 대부분의 범용 클라우드 서비스는 사용자가 태그라는 형식으로 리소스에 메타 데이터를 지정할 수 있도록 합니다. ***태그란*** 사용자가 정의한 **키**(**Key**)와 클라우드 리소스를 보다 쉽게 관리할 수 있는 선택적 기술할 수 있는 **값**(**Value**)로 구성된 간단한 라벨입니다. 태그는 다양한 용도로 사용할 수 있습니다.

태그는 클라우드 리소스에 지정된 라벨입니다. 태그는 **키**(**Key**)와 **값**(**Value**)의 두 부분으로 구성됩니다.

예를 들자면,

![태그](https://cdn.grumatic.com/strapi/tag_description_10121852a0.png) 

태그에는 두 종류의 태그가 있습니다.

- **자동 생성 태그** - 이 태그는 범용 클라우드 서비스에서 생성하는 태그이므로 변경할 수 없습니다. AWS의 경우 접두사는 일반적으로 `aws:createdBy`로 시작하여 일반적으로 숫자와 문자의 문자열을 포함합니다. 예를 들면 이렇습니다.
 - *aws:createdBy=IAMUser:ABCD:userName*
 - *aws:createdBy=AssumedRole:ABCD:userRole*

- **사용자 정의 태그** - 사용자가 사용 사례 적합하다고 판단되는 대로 생성, 정의 및 구현할 수 있는 태그입니다. AWS에서는 단일 리소스에 50개의 태그를 추가할 수 있습니다. 예를 들면 이렇습니다.
 - *operation=backupEast*

 

 

 

### 태깅의 6가지 장점

---

범용 클라우드 서비스가 제공하는 태깅은 많은 이점이 있습니다. 대부분 기업에 기능 전반에 걸친 클라우드 사용 및 비용에 대한 높은 가시성을 제공합니다. 또한 팀간의, 예를 들어 재무와 DevOps 간에 부서 간, 클라우드 자원 관리 효율성을 높이는 데 도움이 됩니다.

#### 1. 리소스 조직화

기본적으로 범용 클라우드 공급자는 서비스별로 리소스를 구성할 수 있습니다. 태그는 리소스와 함께 표시할 클라우드 리소스를 구성하는 좋은 선택이며 검색 및 필터링이 가능합니다.

#### 2. 비용 할당과 리포팅

비용 할당은 종종 기업이 태그 지정 리소스의 우선 순위를 지정하는 주된 이유입니다. 적절한 태깅을 통해 클라우드 지출을 분류하고 조직, 애플리케이션, 환경 및 제품과 연결할 수 있습니다.

#### 3. 태그를 이용한 자동화

태깅을 통해 관리자는 자동화가 필요한 리소스를 확인할 수 있습니다. 특정 리소스 또는 서비스는 자동화 활동 중에 리소스를 필터링하는 데 사용할 수 있습니다. 태그를 사용하여 자동화된 작업을 옵트인(Opt-in) 또는 옵트아웃(Opt-out)하거나 보관, 업데이트 또는 삭제할 리소스의 특정 버전을 식별할 수 있습니다. 예를 들어, 여기에는 태그에 따라 인스턴스의 자동 시작 또는 종료가 포함될 수 있습니다.

#### 4. 운영 지원

태그는 관리자가 업데이트가 필요할 수 있는 리소스를 식별하는 데 도움이 될 수 있습니다. 예를 들면, 태깅 데이터를 확인하여 특정 리소스에 대한 백업을 예약할 수도 있습니다.

#### 5. 액세스 통제

대부분의 범 용요클우드 서비스에서 태깅을 통해 관리자는 계정 내의 리소스 또는 서비스에 대한 사용자 또는 역할의 액세스를 제한할 수 있습니다. 액세스 관리는 허용된 사용자만 허용된 리소스에 액세스할 수 있도록 보장함으로써 조직의 클라우드 거버넌스에서 중요한 역할을 할 수 있습니다.

#### 6. 보안

액세스 관리 외에도 태그는 개인 식별 정보를 보유할 수 있는 리소스를 식별하는 데 필수적입니다. 이러한 리소스를 추적하면 보안 정책의 위반을 더 쉽게 발견할 수 있습니다.

 

 

 

## 태그 관리를 위한 5 가지 전략

---

어디에서 돈을 낭비하고 있는지 알면 클라우드 비용 낭비를 더 쉽게 막을 수 있고, 지출하는 금액과 비용 최적화 전략을 쉽게 적용할 수 있는 곳을 알면 신속하게 비용 절감 결정을 내릴 수 있습니다.
그러나 클라우드 비용 낭비를 효율적으로 방지하려면 더 많은 정보가 필요하며 여기에서 비용 할당용 태그가 유용합니다. 비용 관리를 위한 효과적인 태깅 전략은 조직에서 연간 수천 달러를 절약할 수 있습니다.
비용 분석 목적으로 세부 정보를 수집하기 위해 다음 모범 사례들을 사용하여 성공적인 비용 할당 태깅 전략을 정의할 수 있습니다.

### 1. 태그의 표준화

태깅은 조직이 범용 클라우드에서 다양한 리소스를 식별할 수 있는 방법을 제공합니다. 회사가 사용량, 비용, 성능 등을 이해하는 데 도움이 될 수 있습니다. 조직에는 따라야 할 특정 규칙과 일반 관행을 정의하는 공통 태그 표준이 필요합니다. 이 표준은 팀이 태그를 사용하는 방법(적절한 형식 지정 포함), 태그를 생성해야 하는 사람 및 태그 지정 결정 방법을 정확히 알 수 있도록 도와줍니다. 또한 모든 클라우드 리소스에 일관된 방식으로 태그를 계속 지정하는 데 도움이 됩니다.

### 2. 작게 시작하여 지속적인 개선

처음부터 모든 리소스의 100% 태그를 보유하는 것은 불가능합니다. 회사내에서 태그 관리 요구 사항은 시간이 지남에 따라 발전할 것입니다. 시작단계에서는 단기적으로 필요한 작은 필수 태그 세트를 먼저 선택하고 필요에 따라 이를 기반으로 구축하십시오. 시작할때는 먼저 특정 유형의 태그를 선택할 수 있습니다. 최대한의 이점을 얻으려면 비용 보고를 위한 태그에 집중하십시오. 이러한 태그를 부서 또는 기능별과 같은 내부 보고 요구 사항에 맞추면 그에 따라 데이터를 필터링할 수 있습니다. 이렇게 하면 부서 전체의 클라우드 사용량을 확인하고 적절한 차지백(Chargeback)을 실현하는데 도움이 됩니다. 그런 다음 시간이 지남에 따라 더 많은 리소스에 더 많은 태그를 지정할 수 있습니다. 목표를 95% 태깅으로 설정하고 프로세스를 조금씩 발전시키는 것이 더 현실적입니다.

### 3. 태그 감사 및 유지 관리 유지

의심할 여지 없이 태그가 여전히 정확하고, 유용하게 사용하기 위해 주기적으로 태그를 다시 재검토해야 합니다. 배포하는 리소스의 수에 따라 매 분기마다 태그를 감사하도록 미리 알림을 설정하거나 매달 태그를 검토하고 업데이트하는 미팅을 하는 것이 좋습니다. 

### 4. 주기적으로 성능 측정 및 보고

클라우드 리소스에 적절하게 태그가 지정되었는지 여부를 쉽게 파악하는 것이 중요합니다. 특히 가장 비싼 클라우드 리소스에 대해 태그가 잘 적용되었는지 확인해야 합니다. 태그가 잘못 적용된 위치 또는 태그가 적용되지 않은 위치 등을 식별하는 보고서가 있어야 합니다. 보고서는 비용이 많이 드는 리소스에 태그가 부족하여 발생하는 문제를 즉시 식별하는 데 도움이 될 수 있습니다.

### 5. 태깅 프로세스의 자동화

수동으로 태그를 적용하는 것은 번거로울 수 있습니다. 수동 태깅은 시간이 많이 걸리고 인적 오류로 이어져 부정확한 보고가 발생할 수 있습니다. 또한, 수동 태깅은 일부 리소스가 태깅되지 않을 수 있으며, 이로 인해 보고된 정보에 차이가 발생하여 결국 불완전한 데이터를 기반으로 결정을 내리게 됩니다. 여기에서 태깅 프로세스는 자동화가 필요합니다. 자동화는 인적 오류를 줄이고 태그 지정에 많은 비용이나 시간이 소요되는 리소스 태깅 비용을 낮추고 보고 목적으로 클라우드 사용에 대한 더 많은 정보를 수집하는 데 도움이 됩니다.

 

 

 

## 태그를 이용한 비용 할당

---

클라우드 비용은 태그를 담당자에서 매핑하여 책임 소유자에게 할당해야 합니다. 그러나, 직원들은 입사나 퇴사등 기존 직원이 재배치되기 때문에 태그 소유자를 클라우드 자원에 직접 할당하는 것을 피해야 합니다.
왜냐하면, 클라우드 태그를 변경하는 것이 상대적으로 힘든 작업이기 때문입니다. 이상적으로는 해당 소유자를 신속하게 재할당할 수 있는 데이터베이스의 비즈니스 소유자에게 클라우드 태그를 매핑합니다.
쇼백(Showback) 및 차지백(Chargeback)의 경우 VP, 사업부 또는 비용 센터와 같은 높은 수준에서 클라우드 비용을 표시하는 것이 중요합니다. 그러나 예산 초과의 근본 원인을 파악하는 경우와 같이 문제 해결을 위해 개별 팀장이나 엔지니어에게 드릴다운할 수 있는 것도 유용합니다.

### 쇼백(Showback) vs. 차지백(Chargeback)

**쇼백(Showback)** 이란 비즈니스 단위, 애플리케이션, 사용자 또는 비용 센터와 같은 특정 단위에서 발생하는 비용의 표시, 계산 및 보고에 관한 것입니다. 예: "인프라 엔지니어링 팀은 지난 달 AWS 지출의 $X를 담당했습니다."

**차지백(Chargeback)** 이란 금융 시스템 같은 조직의 내부 회계 프로세스를 통해 발생한 비용을 해당 법인에 실제로 청구하는 것입니다. 예: "$X가 인프라 엔지니어링 팀의 AWS 예산에서 차감되었습니다."

두 경우 모두 리소스에 적절하게 태그를 지정하면 엔터티에 비용을 할당하는 데 도움이 될 수 있습니다. 유일한 차이점은 누군가가 지불할 것으로 예상되는지 여부입니다.

 

 

 

### 결론

---

태깅은 비용에 대해 자세히 알려줍니다. 올바른 태그를 사용하면 범용 클라우드 비용을 더 잘 관리할 수 있습니다. 핵심은 자원에 적용하는 것뿐만 아니라 비용 할당을 위해 재무적인 관점에서 매핑되는지 확인하는 것입니다.
전통적으로 대부분의 회사는 각 리소스에 수동으로 '환경', '부서' 등 추후에 재무 부서에서 비용을 분석하고 보고 사용할 수 있는 기타 여러가지 태그를 지정합니다. 이러한 수동 태깅 프로세스는 빈약한 태그 사용 체계 포함하여 여러 가지 문제를 야기하여 낭비적인 지출로 이어졌습니다. 
이러한 문제를 극복하고 엔터프라이즈 수준에서 팀 전체의 태깅 노력으로 확장하려면 올바른 비용 최적화 및 관리 전략이 마련되어야 합니다. '모두 태그' 접근 방식이 도움이 되지만 검증된 클라우드 비용 관리 플랫폼으로 보완하는 것이 좋습니다.

youzi_lin_Zega_znwi_LQ_unsplash.jpg

클라우드 비용 관리를 위한 5가지 태깅 전략

AWS에서 제공하는 대표적인 EC2 가격 할인 모델에는 예약인스턴스와 세이빙스 플랜이 있습니다. 이 두 가격할인 모델은 혼동하기 쉽고 어느 것을 구매해서 사용해야 비용 절감이 더 효과적인지 결정하는데 가격표, 사용율, 성능측정 데이터를 보고 판단하는 과정을 거쳐야 합니다. 많은 EC2 인스턴스를 운영하는 회사에서는 자동화툴없이 최적화는 수작업으로 하는 것은 거의 불가능합니다.

## 예약 인스턴스(Reserved Instances)

---

### 예약 인스턴스란?

예약인스턴스는 일명 RI(Reserved Instance)라고 하는데 1년 혹은 3년동안 특정 가용존(Availiability Zone)에 용량과 자원을 예약하여 사용하는 것을 의미합니다. 주로 EC2에 해당며 RDS에도 적용이 됩니다. 여기에서는 EC2만 다루겠습니다.

예약 인스턴스를 구매할때 1년 혹은 3년간을 기한으로 비용 지불에 동의하면 온디맨드보다 훨씬 낮은 가격에 EC2를 사용할 수 있습니다. RI는 단순히 비용절감 만을 의미하는 것이 아니라 **특정 존(Zone)에서 필요한 자원을 미리 예약**하여 사용할 수 있는 비용 절감 모델입니다.

약정 기간에 따라 다음과 같이 두개의 선택 사항이 있습니다.

- 1년
- 3년

결제 옵션에 따라 다음과 같은 3가지 선택 사항이 있습니다.

- 선결제 없음(No Upfront) – 매월 약정된 금액을 내고 시간 단위로 사용
- 부분 선결제(Partial Upfront) – 일부를 선결제하고 시간당 선결제 없음(No Upfront)보다 낮은 가격에 시간당 사용료를 지불
- 전체 선결제(All Upfront) – 약정 기간내에 사용금액을 모두 선지불하여 가장 낮은 가격으로 인스턴스 사용 

전환 가능 유무에 따라 다음 두가지 선택 사항이 있습니다.

- 표준형(Standard) – 약정 기간 동안 인스턴스 타입 변경이 불가능
- 전환형(Convertible) – 약정 기간 동안 인스턴스 패밀리, 운영체제, 테넌시 및 결제 옵션 변경 가능

그러므로 예약 인스턴스는 약정 기간에 따라 2가지, 결제에 따라 3가지, 전환 가능 선택 사항에 따라 2가지를 조합하여 구매해야 하므로 총 12가지 선택 사항이 있습니다. 12개중 현재 사용 패턴과 시스템에 가장 적합한 선택 사항을 조합하여 구매해야 합니다.

 
 

### 왜 예약 인스턴스를 사용하는가?

예약을 하는 가장 큰 이유는 온디맨드 가격보다 낮은 가격으로 EC2 인스턴스를 사용할 수 있는 점이다. 

### 1. 가격할인

EC2가 전체 클라우드 비용 중 차지하는 비중이 일반적으로 가장 크므로 RI는 비용 절감에 있어서 가장 유용한 툴이 된다. 이미 온디멘드로 사용 중인 EC2에 대하여 낮은 가격으로 사용할 수 있는 가장 효과적인 가격 정책이다. 기존 온디멘드로로 사용 중인 EC2를 RI로 전환할 것인가에 대한 결정을 할때 사용하는 지표가 사용율(Utilization rate)이다. 사용율이 낮은 인스턴스인 경우는 예약 인스턴스를 사용하면 더 많은 비용을 지불해야 할 수 있다. 

### 2. 용량 및 자원 예약

두번째 이유는 대용량으로 EC2를 사용하는 기업에서는 선택한 가용영역(Availability Zone)에서 자원의 예약을 할 수 있다는 장점입니다.   같은 지역내에서 보통 3~4개 가용영역을 제공하는데 지역간 혹은 가용영역 사이에 통신보다는 같은 가용영역내에서 링크는 지연시간(latency)가 작다는 장점이 있습니다. 대규모 서비스를 운영하면서 급작스러운 트래픽 증가로 대규모 서버 증설이 단시간내에 불가피할 경우 한 가용영역에서 자원을 예약하게 되면 하게되면 자원 고갈로 대처 못하는 상황을 피할 수 있습니다. 이러한 경우는 대용량을 사용하는 기업외에는 매우 드문 경우라고 얘기할 수 있습니다.

결론적으로 정리하면 예약인스턴스는 일반적으로 비용절약을 위해 많이 사용한다고 얘기 할 수 있습니다.

 

 

## 세이빙스 플랜(Savings Plan)

---

지금까지 EC2 할인 모델로 예약 인스턴스가 가장 널리 사용되어 왔습니다. 그러나 가장 문제점은 지역, 크기, 인터턴스 패밀리를 정하게되면 변경이 거의 불가능하다는 점이다. 전환형을 산다고 하더라도 인스턴스 패밀리를 변경하거나 지역을 변경할 수 없다는 단점이 있습니다. 이부분은 클라우드의 유연성과 탄력성이라는 장점에 반하는 가격 정책이었습니다. 또한, 아마존은 구매한 예약인스턴스 중 원하지 않는 인스턴스를 제2의 마켓에 판매를 할 수 있도록 허용하고 있으나 거래 성사를 이루기 쉽지 않습니다.

2019년 11월에 발표된 새로 발표된 세이빙스플랜은 인스턴스 패밀리, 크기, 운영체제, 데넌시(Tenancy), 지역에 관계없이 더 낮은 가격을 제공하고 있습니다. 특정 인스턴스, 인스턴스 패밀리와 지역에 적용하는 플랜으로 사이즈, 운영체제, 테넌시(Tenancy) 에 관계없이 할인을 적용받을 수 있습니다. 온디맨드 가격에 비해 최대 72%까지 낮은 가격으로 EC2 인스턴스를 사용할 수 있습니다. 

예약 인스턴스와 가장 큰 차이점은 사용자가 특정 기간에 특정 인스턴스타입 사용량을 약정하는 것이 아니라 **특정 인스턴스 패밀리의 일정비용을 지불**하겠다고 약정하여 할인을 받는 가격모델이다. 아마존에서 EC2의 온디맨드와 Fargate 컨테이너 서비스 사용 비용에 대하여 할인을 해주는 플랜입니다.

세이빙스 플랜(Savings Plan)에는 두가지 종류를 제공하고 있습니다. 두개를 비교하여 요약하면 다음과 같습니다.

- EC2 instance plan 
- AWS Compute Savings Plan

|EC2 Instance Savings Plan|AWS Compute Savings Plan|
|---|---|
|온디맨드 가격의 72%까지 할인가능 (표준 예약 인스턴스와 같은 가격)|온디맨드 가격의 66%까지 할인가능 (표준 예약 인스턴스와 같은 가격)|
|지정한 지역내에서만 인스턴스 변경 허용|**여러 지역**에 걸쳐 적용 가능|
|EC2 인스턴스의 같은 패밀리에만 적용 가능하면, 크기 변경, 운영체제 변경이 허용된다.|보다 유연하며, EC2 인스턴스 패밀리 혹은 운영체제 변경에 제한이 없다.|
|EC2 인스턴스에만 적용 가능|EC2와 Fargate에 적용 가능|
|유연성은 조금 낮으나 할인율이 조금 더 높음|유연성은 높으나 할인율이 조금 낮음|

결제 방법에 선택 사항은 다음과 같습니다.

- 선결제 없음(No Upfront) – 선결제 없이 약정한 금액을 사용 시간당 지불하는 모델
- 부분 선결제(Partial Upfront) – 일부 선결제를 하고 조금 더 낮은 요율에서 사용하는 시간당 지불하는 모델 
- 전체 선결제(All Upfront) – 미리 선결제하여 가장 낮은 가격으로 사용하는 모델

약정 기간에 따라 두가지 선택 사항이 주어집니다.

- 1년
- 3년

세이빙스 플랜(Savings Plan) 단점은 예약인스턴스와 달리 **재판매나 전환이 불가능**합니다. 그러므로 ,한번 구매하게 되면 계속 추가해야 되므로 신중하게 구매해야 합니다.

 

 

## AWS EC2 할인 정책 비교

---
::table{.vertical-header}

| |Reserved Instance|EC2 Savings Plan|Compute Savings Plan|
|---|---|---|---| 
|인스턴스 패밀리|지정|고정|가변|
|인스턴스 크기|지정|변경 가능|변경 가능|
|운영체제|지정|변경 가능|변경 가능| 
|지역|1 Region 지정|1 Region 지정|지역 무관|
|적용 가능한 서비스|EC2/RDS|EC2|EC2/Fargate|

AWS 예약 인스턴스(RI)와 세이빙스 플랜(SP) 비교

클라우드를 많이 사용하는 회사 중에는 Cloudfront 비용의 비중이 큰 회사가 많습니다. 특히, 미디어 서비스를 하는 회사나 비디오, 이미지, 오디오 데이터 전송 비중이 큰 서비스는 CF 비용이 부담스러울 수 밖에 없습니다. 

지금까지 Cloudfront을 많이 사용하는 기업에서는 비용을 대폭 절감할 수 있는 기법이 많지 않아 대용량을 사용하면 맞춤형 할인(Volume Discount)으로 가격을 낮추어 왔고, 대용량을 사용하지 않은 기업은 실요금을 모두 지불해야 했습니다. 2021년 2월 5일에 아마존에서 Cloudfront Security Savings Bundle라는 새로운 할인 정책이 발표되면서 새로운 비용 절감 방법이 생겼습니다. 이를 집중적으로 알아보도록 하겠습니다.

#### CloudFront 서비스란?

CloudFront는 아마존에서 제공하는 CDN(Content Delivery Network) 서비스로 AWS내에 서비스인 EC2, S3, ELB와 통합하여 사용할 수 있으며, AWS Shield, WAF(Web Application Firewall), Route 53와 통합하여 고급 보안 기능도 제공합니다.

**[ CloudFront 서비스 가격 선택사항 ]**

- **프리티어 (Free-Tier)** – 처음 AWS를 가입하면 매월 50GB와 2백만개 HTTP/HTTPS 요청을 1년 동안 무료로 사용할 수 있습니다.
- **온디맨드(On-Demand)** – 실제 사용량에 따른 비용이 청구됩니다.
- **요금 할인**
 - **맞춤형 요금 (Custom Pricing)** – 월 10TB이상이면 사용량을 약정하여 요금을 할인 받을 수 있습니다.
 - **Security Savings Bundle** – 월 일정 사용량을 1년간 약정하여 30%까지 요금을 할인 받을 수 있습니다.

 

 

 

### Cloudfront 가격 구성

---

Cloudfront의 가격은 크게 다음과 같은 비용으로 구성됩니다.

|Type |Price Range|Description|
|-----------------|------------|-----------|
|DTO(Data Transfer Out) to internet|$0.020 ~ $0.170|인터넷을 통해 엣지에서 사용자에게 데이터가 전달될때 부과되는 요금|
|Regional Data Transfer Out to Origin|$0.020 ~ $0.160 (GB 당)|사용자가 요청하여 데이터를 Origin으로 전달하는 비용 (즉, POST and PUT requests)|
|HTTP/HTTPS request|$0.0075 ~ $0.0220(10,000개당)|사용자로부터 HTTP 혹은 HTTPS 요청에 대한 요금 (10,000 개당)|
|Origin Shield Requests|$0.0075 ~ $0.0090(10,000개당)|HTTP 에 대한 Origin Shield 요청 요금|
|Invalidation request|$0.005(요청 경로당)|TTL(Time-to-live)가 만료되기전에 모든 엣지로부터 파일 삭제 요청에 요금|
|Field Level Encryption Requests|$0.02(10,000개 요청당)|HTTPS내에서 특정키를 사용하여 추가 암호화 비용|
|Real-time log requests|$0.01(1백만개당)|데이터 전송에 대한 실시간 요청 정보|
|Dedicated IP custom SSL|$600 per month for each customer SSL Certification|SNI(Server Name Indication)을 지원하지 않는 브라우저로 콘텐츠를 전송할 때 사용합니다. 각 사용자 지정 SSL 인증서에 대해 매월 600 USD를 지불합니다|

 

 

 

## Cloudfront 비용 최적화 방법

---

### 1. Cloudfront 클래스 조정

Cloudfront는 세가지의 클래스를 다음과 같이 제공합니다.

지역별로 엣지 로케이션이 다른 가격으로 책정이 되어 있습니다. 사용자의 데이터 전송 요청이 있을때 가장 가까운 엣지에서 데이터를 전송하는데 각 엣지별로 가격이 다릅니다.

|Edge Locations Included Within|**United States, Mexico, & Canada**|**Europe & Israel**|**South Africa, Kenya, & Middle East**| **South America**|**Japan**|**Australia & New Zealand**|**Hong Kong, Philippines, Singapore, South Korea, Taiwan, & Thailan**|**India**|
|----|----|----|----|----|----|----|----|----|
|DTO pricing|$0.085|$0.085|$0.110|$0.110|$0.114|$0.114|$0.140|$0.170|
|All Edge locations|Yes|Yes|Yes|Yes|Yes|Yes|Yes|Yes|
|Us, Canada, Europe, Asia and MEA|Yes|Yes|Yes|X|Yes|X|Yes|Yes|
|Only US, Canada and Europe|Yes|Yes|X|X|X|X|X|X|X|
|DTO pricing|$0.085|$0.085|$0.110|$0.110|$0.114|$0.114|$0.140|$0.170|
|DTO pricing|$0.085|$0.085|$0.110|$0.110|$0.114|$0.114|$0.140|$0.170|
|DTO pricing|$0.085|$0.085|$0.110|$0.110|$0.114|$0.114|$0.140|$0.170|

글로벌 서비스를 하는 경우 모든 엣지에 콘텐츠를 배포할 경우는 비용 절감을 할 수 없지만, latency 혹은 전송 속도가 문제 되지 않을 경우에는 미국, 캐나다 유럽 지역을 선택하게 되면 조금 더 낮은 가격의 엣지에서 데이터 전송을 하여 비용 절감을 할 수 있습니다.

 

 

### 2. Cache Control

각각 파일을 엣지와 브라우저에 최대한 오래 저장될 수 있도록 Cache-control and Expires header에 만료 기간을 너무 짧지 않게 설정해주는 것이 중요합니다. 적절하게 조절하면 Browser에 다운로드 하는 데이터양를 최대한 줄일 수 있습니다.

 

 

### 3. Cloudfront Security Savings Bundle

앞에서 소개한 두 방법은 모든 경우에 적용되지 않고 cache control 같은 방법은 설정하는데 너무 많은 노력이 필요합니다. Cloudfront 비용절감에 있어서 가장 효과적인 방법은 Savings Bundle를 활용하는 법입니다.

 

 

### 4. Savings Bundle 요약

- 일년간 일정 금액의 월간 요금(USD)을 약정해야 합니다.
- 매월 크레딧(Credit) 형태로 적용되어 최대 30% 할인이 가능합니다.
- 약정 금액의 최대 10%의 AWS WAF 크레딧을 받아서 사용할 수 있어서 WAF를 사용할 경우 추가 할인을 받을 수 있습니다.

#### Savings Bundle 예제

매월 $600을 사용할 경우 약정 금액은 다음과 같이 계산할 수 있습니다.

$600 * 70% = $420

월 $420을 약정하면 월 $180/년 $2160 을 절약할 수 있습니다. 또한 AWS WAF 크래딧은 월 $42을 받습니다.

 

 

 

#### Savings Bundle 약정 금액을 결정하는 방법

대부분의 회사의 월 Cloudfront 사용량이 일정하지 않고 약정금액을 결정하는 간단한 가이드라인을 제시해 보겠습니다.

- 약정금액을 모두 사용하지 않았을때 이월이 되지 않으므로 월단위로 약정금액을 모두 사용할 수 있도록 약정금액을 사용하는 것이 효과적 입니다.
- 지난 몇개월 비용 이력을 보고 월단위로 약정 금액을 모두 사용할 수 있는 금액을 결정하세요. 아래 그림과 같은 예에서는 $580 ~ $600 정도 약정금액을 정하는 것이 효과적 입니다.content/uploads/2021/03/Screen-Shot-2021-03-10-at-9.4
- 9.12-AM-1024x443.png)만일 2019년 9월 1일부터 $400을 약정했다면 용은 다음과 같이 됩니다.
- 약정 후 몇개월 단위로 cloudfront 비용을 검토하고 온디맨드 비용이 일정금액이상으로 지속될때는 추가 Savings Bundle 약정을 해서 추가 절감을 할 수 있습니다. 아래 그림에서 빨간색 선과 같을 경우 약 $300 정도 추가 약정을 하면 비용을 더욱 절감할 수 있습니다.
- 약정이 끝나고 재 약정을 하지 않으면 온디맨드 금액을 지불해야 하므로 약정 만료일을 확인하고 관리해야 합니다.

 

 

### 5. EC2혹은 S3 트래픽을 Cloudfront 사용하여 비용 최적화

EC2 혹은 S3에 트래픽 비용이 많이 나오는 경우 이를 고려해볼 필요가 있습니다. 예를 들어 EC2로 web service를 하는 경우 비용 측면에서 Cloudfront가 조금 비싸지만 Savings Bundle을 적용하면 비용을 절감 할 수 있습니다. S3 인경우에 cloudfront의 온디맨드 가격보다 비싸지만 Savings Bundle을 사용할 경우 더욱 저렴한 가격으로 훨씬 빠른 전송속도로 사용할 수 있습니다. 아래표는 서울리전의 각 서비스의 데이터 전송 비용을 비교해보았습니다. 전송 용량에 따라 가장 낮은 가격의 서비스는 노란색으로 표시했습니다. 아래표와 같이 CF Savings Bundle을 활용하면 데이터 전송 비용을 상당히 절약할 수 있습니다.

CloudFront 비용 최적화하기

애플리케이션 개발 후 AWS에 애플리케이션을 설치할 때 성능, 가용성, 확장성, 비용, 서비스 특성등 많은 요구사항들을 고려하여 복잡한 고민을 거쳐 EC2 인스턴스 사이즈등  AWS 자원들을 선택하게 됩니다. 그 중 중요한 요소 중 하나가 EC2인스턴스나 RDS에 연결되는 스토리지인 EBS(Elastic Block Storage)를 선택하는 일인데, 성능 및 비용까지 고려해서 선택하는 과정은 많은 고민을 할 수 밖에 없습니다.  EBS 볼륨의 크기를 정하는 것도 중요하지만 그것보다 더 중요한 것은 EBS 볼륨의 종류를 선택하고 성능과 비용 최적화 하는 것입니다. 

얼마나 빠른 EBS 볼륨을 선택하는냐에 따라 애플리케이션, 데이터베이스의 성능에 큰 영향을 미치게 됩니다. 또한 EBS 볼륨의 유형에 따라 비용이 크게 달라집니다.  그러므로 요구되는 성능과 비용을 고려하여 적절한 스토리지 유형과 크기를 현명하게 선택하여야 합니다. 이와 관련된 기본 지식과 약간의 노하우를 공유하고자 합니다.


 


### **IOPS(Input/Output Operation Per Second)란?**

Amazon 클라우드 저장장치의 성능을 나타내는 가장 중요한 지표가 **초당 입출력 속도인 IOPS** 입니다. 특히, RDS (Relational Database Service) 인스턴스 설정시 최대 IOPS가 정해진 스토리지를 선택하게 되는데 일단 선택이 되면 할당된 최대 IOPS를 넘을 수 없으므로 신중하게 선택해야 합니다.  IOPS는 RDS를 중심으로 먼저 설명해보겠습니다. RDS에서 한번에 전송할 수 있는 데이터 크기는 RDS 데이터베이스 엔진의 페이지 사이즈가 다릅니다. 

얼마나 많은 IOPS가 필요한지 이해하기 위해서는 먼저 얼마나 높은 처리량(Throughput)이 필요한지 먼저 이해해야 합니다. **MySQL과 MariaDB는 16KB 크기의 페이지**를 사용합니다. 그래서 입출력 한번 당 16KB 단위로 전송합니다. 반면 **Oracle, PostgreSQL, Microsoft SQL은 8KB 크기의 페이지**를 사용합니다. 그래서 16KB데이터를 전송하기 위해서는 두번의 입출력 동작이 필요합니다. 즉, 페이지 사이즈가 클수록 한번의 입출력 동작으로 더 많은 데이터를 전송할 수 있습니다.

예를 들면, 매초 102,400KB (100MB)의 읽기 동작이 필요한 애플리케이션인 경우 16KB 페이지 크기의 데이터 베이스를 사용할 경우 초당 6,400 번의 읽기 동작을 해야 합니다. 즉 6,400 IOPS 이상의 성능을 가진 EBS볼륨이 필요합니다.

 


 


## EBS 스토리지 유형

---

### **1. 범용(General Purpose) SSD (gp2)**

대부분의 애플리케이션에서는 gp2로 어느 정도 충분한 성능을 낼 수 있습니다. gp2는 지연시간(latency)이 한자리 밀리초(1 ~ 9 ms)가 가능한 매우 빠른 스토리지입니다. 볼륨크기는 16TB까지 가능하고 기가바이트 당 3배의 IOPS **(3 IOPS/GB)**를 할당할 받을 수 있으며 볼륨당 16,000 IOPS까지 가능합니다. 예를 들면, 100GB 크기의 볼륨을 설정하면 최대 300 IOPS를 할당 받습니다. 즉 볼륨크기가 클수록 더욱 빠른 IOPS를 할당 받을 수 있다는 의미입니다.

gp2의 최대 대역폭은 2,000 Mbps (250 MBps) 입니다. 이 속도를 내기 위해서는 몇가지 조건을 고려해야 합니다.  첫번째로 EC2 **인스턴스 타입**이 최대 처리량을 감당할 수 있을 정도의 충분한 크기이어야 합니다.  두번째로는 **충분한 IOPS**를 할당 받아야 합니다. 예를 들면, 페이지크기가 16KB (128Kb = 0.128 Mb)인 MariaDB를 사용할 경우 최대 대역폭을 페이지 사이즈로 나누면 15,625 IOPS가 필요합니다.

2,000 Mbps / 0.128 Mb = 15,625 IOPS

 

그러므로 최대 성능을 내려면 15,625 IOPS / 3 = 5,208.33 GB (약 5.2TB) 볼륨을 할당해야 합니다. 

만일 스토리지는 많이 필요하지 않으나 (1TB이하인 경우) 높은 IOPS가 가끔씩만 필요하다면 굳이 필요한 IOPS만큼 볼륨을 할당할 필요는 없습니다.  gp2의 IOPS는 버스트 버킷이라는 모델을 지원하고 있습니다.  Amazon에서는 크레딧 발란스를 이용하여 **최대 3000 IOPS 수준의 버스트 버킷**을 사용할 수 있습니다. 버스트 전송할 수 있는 시간을 계산하면 다음과 같습니다다.

Burst duration in seconds = (Credit balance)/ [3,000 – 3 * (storage size in GB)]

데이터베이스 인스턴스를 초기화하면  5,400,000 IOPS 크레딧 밸런스가 주어지는데요. 언제든 기본으로 주어진 IOPS이상을 사용할 수 있습니다다. 예를 들면, 200GB 볼륨 크기를 설정하면 

5,400,000 / [ 3,0000 – 3 * 200] = 2250초

2,250초  (37.5분) 동안 버스트를 사용할 수 있습니다. 

볼륨에 기준 성능 I/O 수준 이상이 필요한 경우 크레딧 밸런스에서 I/O 크레딧을 사용하여 최대 3,000 IOPS까지 필요한 성능 수준을 버스트할 수 있습니다. 아래 차트에서 1,000GiB 이상의 볼륨은 이미 기준 IOPS가 최대 버스트 성능 이상의 성능을 가지게 되므로 I/O 크레딧 밸런스는 차감되지 않습니다. 

크레딧은 매초 베이스라인의 기준 성능에 비례하여 추가가 되며, 주어진 크레딧을 다쓰게 되면 볼륨의 베이스라인으로 할당된 IOPS ( 3 IOPS/GB)이상 주어지지 않습니다. 

예를 들어, 200GB볼륨이면 베이스라인으로 600 IOPS가 주어지며 매초 600 IOPS씩 크레딧이 최대 5,400,000까지 쌓입니다.


 


### **2. 프로비전된(Provisioned) IOPS SSD(io1)**

gp2 스토리지는 성능을 계산하기 위해서는 버스트 벗킷이라는 매우 복잡한 구조를 가지고 있습니다. 버스트 버킷와 같은 머리 아픈 계산법 없이 단순하게 접근하려면 프로비젼된 IOPS SSD (io1)을 선택하면 매우 단순해집니다. 이 형태의 볼륨은 가장 비싼 형대로 지불한 만큼 미리 정해진 IOPS를 확보할 수있는 스토리지가 io1입니다. 이 스토리지는 지속적으로 낮은 응답 지연시간(Low latency)가 필요한 OLTP형 데이터베이스에 유용하게 사용할 수 있다. 스토리지 볼륨 크기와 프로비전된 IOPS양으로 비용이 청구되므로 사용할 때 비용 고민을 해야합니 다.

4,000 Mbps를 지원하는 표준 인스턴스를 사용하고 16KB 페이지 사이즈를 데이터베이스 엔진을 사용한다고 가정하면, (4,000 / 0.128 = 31,250) 최대 31,250 IOPS가 있어야 하므로 인스턴스를 생성할때 1,000정도를 더해서 32,000 IOPS로 프로비전을 해야 합니다. **IOPS와 스토리지 용량은 약 50:1 비율**로 정하도록 규정하고 있습니다. 예를 들면 32,000 IOPS를 원한다면 640GB 정도를 프로비전해야 합니다.

100 IOPS부터 nitro 인스턴스 패밀리에서는 볼륨당 최대 64,000 IOPS, 그리고 다른 인스턴스 패밀리에서는 최대 32,000 IOPS까지 프로비저닝할 수 있습니다.  최대 32,000 IOPS로 프로비저닝된 io1 볼륨은 최대 256KiB의 I/O 크기를 지원하고 최대 500MiB/s의 처리량을 제공합니다. I/O 크기가 최대일 때 2,000 IOPS에서 피크 처리량에 도달합니다. 

![io1 throughput](https://docs.aws.amazon.com/ko_kr/AWSEC2/latest/UserGuide/images/io1_throughput.png)

### **3. 처리량 최적화된(Throughput Optimized) HDD (st1)**

IOPS가 아닌 처리량(Throughput)으로 성능을 정의하는 저비용 HDD 스토리지로 AWS EMR, 빅데이터, Analytics 같은 애플리케이션에 적합합니다.

gp2는 IOPS 버스트 버킷 모델로 제공하는 반면 st1은 처리량에 대한 버스트 버킷 모델로 제공을 하고 있습니다. gp2와 비슷하게 볼륨 크기가 클수록 더 많은 기준 처리량(baseline throughput)과 버스트 처리량이 비례하여 결정됩니다.

 

![st1 burst bucket](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/images/st1-burst-bucket.png)

AWS에서 기준 처리량(baseline throughput)은 TiB당 40 MiB/s로 크레딧이 채워지며 크래딧은 최대 500 MiB/s까지 주어집니다.

Baseline throughput = Volume size per TiB * 40 MiB/s 

 

최대 버스트 처리량(Burst throughput)은 TiB당 250 MiB가 주어지면 최대 500 MiB/s까지 주어진다. 그러므로 2 TiB 이상의 볼륨은 최대 500 MiB/s 이상 넘을 수 없게됩니다. 

12.5 TiB이상의 볼륨 크기에서는 기본 처리량이 최대 500 MiB/s되므로 버스트 처리량이 의미가 없어집니다.

이를 그래프로 그려보자면 다음과 같습니다.

![st1 throughput](https://docs.aws.amazon.com/ko_kr/AWSEC2/latest/UserGuide/images/st1_base_v_burst.png)

### **4. Cold HDD (sc1)**

자주 액세스하지 않는 애플리케이션에 적합하고 처리량으로 성능을 정의하는 저비용 HDD 스토리지를 제공합니다. sc1은 대용량 데이터를 랜덤이 아닌 순차적으로 액세스하는 애플리케이션에 매우 적합니다.

sc1은 st1과 같이 처리량으로 버스트 버킷 모델로 제공을 하고 있습니다. gp2와 비슷하게 볼륨 크기가 클수록 더 많은 기준 처리량(baseline throughput)과 버스트 처리량이 비례하여 결정됩니다.

![sc1 ë²ì¤í¸ ë²í·](https://docs.aws.amazon.com/ko_kr/AWSEC2/latest/UserGuide/images/sc1-burst-bucket.png)

AWS에서 기준 처리량(baseline throughput)은 TiB당 12 MiB/s로 크레딧이 채워지며 크래딧은 최대 250 MiB/s까지 주어집니다.

Baseline throughput = Volume size per TiB * 12 MiB/s 

최대 버스트 처리량(Burst throughput)은 TiB당 80 MiB가 주어지면 최대 500 MiB/s까지 주어집니다. 그러므로 2 TiB 이상의 볼륨은 최대 250 MiB/s 이상 넘을 수 없게됩니다.  

![sc1 ê¸°ì¤ ë° ë²ì¤í¸ ì²ë¦¬ë ë¹êµ](https://docs.aws.amazon.com/ko_kr/AWSEC2/latest/UserGuide/images/sc1_base_v_burst.png)

## **EBS의 선택 방법**

EBS 선택 방법을 소개하기 전에 우선 EBS 볼륨 별로 요약을 해보겠습니다.

::table{.vertical-header}

|볼륨 유형|범용SSD(gp2)|프로비젼된IOPS SSD(io1)|처리량 최적화된 HDD(sc1)|Cold HDD(st1)|
|---|---|---|---|---|
|설명|다양한 워크로드에 사용할 수 있으며 가격 대비 성능이 우수한 범용 SSD 볼륨|지연 시간이 짧거나 처리량이 많은 미션 크리티컬 워크로드에 적합한 고성능 SSD 볼륨|자주 액세스하는 처리량 집약적 워크로드에 적합한 저비용 HDD 볼륨|자주 액세스하지 않는 워크로드에 적합한 최저 비용 HDD 볼륨| 
|사용예|대부분의 워크로드 추천 시스템 부트 볼륨 가상 데스크톱 지연 시간이 짧은 대화형 앱 개발 및 테스트 환경|지속적인 IOPS 성능이나 16,000 IOPS 또는 250MiB/s 이상의 볼륨당 처리량을 필요로 하는 중요한 비즈니스 애플리케이션 대용량 데이터베이스 MongoDB Cassandra Microsoft SQL Server PostgreSQL Oracle |저비용으로 일관되고 높은 처리량을 요구하는 스트리밍 워크로드 빅 데이터 데이터 웨어하우스 로그 처리 부트 볼륨이 될 수 없음|자주 액세스하지 않는 대용량 데이터를 위한 처리량 중심의 스토리지 스토리지 비용이 최대한 낮아야 하는 시나리오 |
|볼륨크기|1GiB – 16TiB|4GiB – 16TiB|500GiB – 16TiB|500GiB – 16TiB|
|최대 IOPS/볼륨|16,000|64,000|500|250|
|최대 처리량 볼륨|250 MiB/s|1,000 MiB/s|500 MiB/s|250 MiB/s

EBS 선택시 우선 개발한 애플리케이션이 IOPS 가 중요한지 처리량(Throughput)이 중요한지 먼저 고려를 해야합니다.

IOPS가 80,000 이상 요구 경우는 SSD 인스턴스 스토어 볼륨인 NVMe를 사용해야 하며 이를 지원하는 인스턴스인 i3, c5d, m5d, r5d등을 사용해야 합니다. 80,000 IOPS 이하인데 1 ms이하의 지연시간(latency)을 요구하는 경우에도 SSD인스턴스 스토어 볼륨을 사용해야 합니다. 지연시간이 수 ms 정도 빠른 응답속도를 원하는 경우에도 gp2나 io2를 사용하여 합니다. 지속적으로 고속의 IOPS를 요구하는 애플리케이션이 아닌 경우는 가격이 낮은 gp2사용하기를 권장드립니다.

만일 처리량이 중요한 경우 큰 데이터를 순차적으로 액세스하는 애플리케이션인 경우 HDD기반의 볼륨을 권합니다. 1,750 MiB/s이상인 경우 HDD 인스턴스 스토어 볼륨을 지원하는 h1, d2 인스턴스 사용을 권하고 그 외에는 sc1, st1을 가격과 성능을 비교하여 선택하세요.

![Screen Shot 2019-07-09 at 4.33.53 PM.png](https://ericygkim.files.wordpress.com/2019/07/screen-shot-2019-07-09-at-4.33.53-pm.png)

## EBS 종류별 가격 비교

기본적으로 애플리케이션의 IOPS성능에 따라 EBS 볼륨의 종류만 잘 선택해도 상당한 비용 절감을 할 수 있습니다. AWS의 프로비전된 볼륨인 gp2, io1은 빠르고 성능도 좋지만 상대적으로 비쌉니다.  그러나, 데이터 베이스 혹은 부트 디스크를 제외하고 대부분의 애플리케이션에서는 HDD인 sc1이나 st1으로도 충분히 성능을 만족시키는 경우가 많이 있습니다.  아래 도표를 보면 EBS 종류별로 서울 리전의 GB당 가격차이를 한눈에 비교할 수 있습니다.

io2를 선택할 때는 볼륨크기에 대한 비용과 **IO비용이 추가 부가**되기 때문에 선택할 때 매우 신중해야 합니다. gp2가 sc1에 비해 약 2.2배, st1에 비해 약 3.9배가 비쌉니다. 반대로 생각해보면 gp2를 sc1으로 변경할 수 있다면 EBS 볼륨 비용을 반이상 줄일 수 있습니다.


 


## 비용 최적화에 사용하는 유용한 툴

---

### CloudWatch

CloudWatch는 EBS동작에 관한 많은 수치들을 제공합니다. 비용 최적화에 있어서 다음과 같은 세가지 지표가 있습니다.

- **VolumeReadOps**: 주어진 시간당 총 읽기 동작 횟수
- **VolumeWriteOps**: 주어진 시간당 총 쓰기 동작 횟수
- **VolumeThroughputPercentage (Provisioned IOPS SSD only):** 프로비젼된 IOPS대비 IOPS 전달 횟수의 퍼센트

CloudWatch는 직접적으로 IOPS를 표시하지 않아서 표시된 수치들로 IOPS 계산을 해야 합니다. CloudWatch는 5분마다 데이터를 수집하므로 읽은 동작 횟수와 쓰기 동작횟수를 더한 후 300초(5분)으로 나누어야 IOPS를 계산 할 수 있습니다. 그래서 IOPS를 구하는 식은 다음과 같습니다.

**IOPS = (VolumeReadOps + VolumeWriteOps) / 300**

CloudWatch에 IOPS 값과 처리량 수치로 EBS 볼륨이 덜 사용되는지 초과 사용되는지 판단할 수 있습니다. 그리고 볼륨의 크기가 가격대비 성능의 적절한 균형을 가지고 있는지 볼륨 크기 조정이 필요한지 판단할 수 있는 기준이 되기도 합니다. 또한 작은 여러개의 볼륨을 합치거나 볼륨 형태를 바꾸거나 하는 판단의 기준이 됩니다.

특히, 프로비젼된 IOPS SSD인 io1은 고가이므로 항상 IOPS 소모 비용에 대하여 관심을 가지고 보면서 비용 절감 방법에 대하여 항시 검토해야 합니다.

#### **디스크 사용량(Disk Utilization)**

디스크 사용량은 AWS CloudWatch에서 지원하지 않는 수치 중 하나입니다. 프로비젼한 불륨을 얼마나 사용하는지 알기 위해서는 **Newrelic**이나 **Datadog**같은 툴을 사용하는 방법이 있습니다.

AWS 디스크 사용량 모니터링을 위해 수동으로 설치하여 동작시키는 스크립트를 제공합니다. 아래 웹사이트를 참조하세요.

[https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/mon-scripts.html](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/mon-scripts.html)

다시 한번 강조하지만 프로비젼된 IOPS SSD인 io1은 고가이므로 볼륨 사용량도 수시로 점검을 하고 최적화를 해야합니다.

아래 공개 소프트웨어는 AWS에서 제공하는 모니터링 툴로 참고 하시면 좋습니다.

[https://github.com/aws-samples/aws-elastic-volumes](https://github.com/aws-samples/aws-elastic-volumes)

 



 


## EBS 비용 최적화 방법

---

### 1. 사용하지 않는 볼륨과 스냅샷 삭제

가장 빠르고 쉽게 할 수 있는 비용 절감 방법이 사용하지 않은 볼륨과 볼륨의 스냅샷을 찾아내는 것입니다. 주기적인 스냅샷이 필요할 경우 스크립트나 Lambda서비스를 이용하여 주기적으로 스냅샷을 지우면 많은 비용 절감을 할 수 있습니다. 볼륨을 사용하지 않는 경우는 다음과 같이 두가지 경우가 있습니다.

-**EC2 인스턴스와 연결되어 있지 않은 경우** – 개발자들이 가장 실수를 많은 하는 부분으로 EC2 인스턴스를 제거하게 되면 디스크 볼륨도 지워질 것으로 생각하는 사람이 많습니다. EC2 인스턴스를 제거한 후에 반드시 연결되어 있던 디스크 볼륨도 지우세요. 그리고, 수시로 볼륨리스트를 보고 연결되지 않은 볼륨은 지우시기를 바랍니다.
-**사용하지 않는 경우** -볼륨 중에 한동안 IOPS 값과 사용량(Throughput)이 0인 볼륨을 찾아 보세요. 이런 한 볼륨은 지우거나 크기를 최소화하세요.

### 2. 볼륨의 유형 바꾸기

AWS 클라우드를 운영하다 보면 대부분의 애플리케이션이 sc1이나 st1으로 충분한 성능이 나옵니다. 그러나, 애플리케이션을 론치하는 초기에는 예상되는 요구성능에 대한 불확실성때문에 gp2로 시작하는 경우가 많습니다. 1~2개월 운영하다 보면 어느 정도 성능이 요구되는지 알게되므로 볼륨 유형을 낮출 수 있는지 판단됩니다. 이때 판단 기준이 필요합니다. 경험으로 비추어 보면, 평균 IOPS가 85를 넘지 않고 순간 최고 IOPS가 200을 넘지 않는 경우에 sc1이나 st1으로 볼륨 유형을 변경해보십시요. 해당 볼륨 비용이 반이하로 최적화할 수 있습니다.

### 3. 볼륨의 크기 조절

2017년 초에 Amazon에서는 탄력적 볼륨이라는 기능을 발표했습니다. 이전에는 볼륨의 크기를 조절하려면 EC2 인스턴스에서 동작하는 애플리케이션을 정지 시킨 후 볼륨 조정 후에 재시작을 했으나, 신세대 EC2 인스턴스에서는 애플리케이션 정지 없이 볼륨의 크기를 조절할 수 있습니다. 볼륨의 사용량과 볼륨 크기에 따라 결정되는 기본 IOPS를 수치를 확인하여 유동적으로 조절하십시요. 이를 통해 많은 비용을 절감할 수 있습니다.

### 4. io1의 집중관리

io1은 가장 비싼 볼륨으로 볼륨의 크기 뿐만 아니라 I/O연산량에 비례하여 비용을 지불해야 합니다. 상시 수 ms의 응답시간이 필요한지, 프로비젼된 볼륨을 대부분 사용하지는 수시로 확인하고 평균 IOPS와 순간 IOPS를 수시로 점검하여 gp2의 버스트 버킷으로 전환이 가능한지 항상 체크하시기를 바랍니다.

또한 볼륨 사용량을 수시로 체크하여 사용하지 않는 용량은 항시 AWS 탄력적 볼륨을 사용하여 수시로 조정할 수 있습니다.

AWS EBS 비용 최적화 방법

### 클라우드 효율성 문제 해결

클라우드 비용 최적화는 기업의 과제이자 주요 고충입니다. 따라서 클라우드 시장의 다양한 서비스와 솔루션은 인공 지능 (AI)을 사용하여 클라우드 비용 절감 혜택을 제공하려고 합니다.

이 블로그는 인공 지능이 전체 클라우드 비용을 줄이는 데 도움이 될 수 있는 방법을 탐색하고 AI 및 머신 러닝 기술을 사용하여 클라우드 비용 최적화를 위해 발전하고 있는 응용 사례를 소개하려고 합니다.

클라우드 비용 최적화는 클라우드 적응 초기 단계에서 처리 해야 하는 일회성 업무가 아닙니다 . 클라우드 비용 관리 전략을 효과적으로 수행하려면 클라우드 비용 지출을 지속적으로 검토하고 최적화 해야 합니다.

딥 러닝 및 머신 러닝과 같은 인공 지능 기술을 유용하게 사용할 수 있는 분야 중 하나가 클라우드 비용 최적화 분야라고 할 수 있습니다. 클라우드 비용 최적화에서 인공 지능 기술을 사용한 사례에는 리소스 관리와 같은 클라우드 효율성 문제 해결 , 운영 낭비 최소화, 다양한 목적의 예측 분석 활용 등이 포함됩니다.

즉, AI 기반 클라우드 관리 도구를 지능형 소프트웨어 자동화 도구로 사용하여 비즈니스 수준의 결정을 내리고 잠재적인 문제를 예측하거나 IT 팀의 운영 오버 헤드를 줄일 수 있습니다.

특히 인공 지능은 비용 급증을 감지하는 데 도움이 될 수 있습니다. 비용 절감 자동화 도구를 사용하는 것은 클라우드 비용 최적화에 새로운 것이 아닙니다. 리소스 풀링 및 자동 백업 과 같은 기능이 이미 존재합니다. 리소스 풀링 은 리소스 활용률을 높이고 필요한 리소스를 줄여 비용을 절감합니다.


 



 


## 1. 클라우드 비용 절감을 위한 리소스 관리
---
인공 지능 기술을 도입하면 사용하지 않는 리소스를 더 빨리 식별하여 중단하고 리소스를 자동으로 확장하는 등의 작업을 수행 할 수 있습니다. 머신 러닝은 클라우드 서비스에서 기본으로 제공되는 모니터링 서비스에서 데이터를 수집하고 알고리즘을 훈련 한 다음 새로 생성 된 모델을 미세 조정할 수 있습니다.

즉, 인공지능은 시스템에 더 많은 리소스가 필요한 시기를 학습 한 다음 증가하는 요구 사항을 충족하도록 자동으로 확장 될 수 있습니다. AI 머신은 리소스가 더 이상 필요하지 않은 시기를 학습하고 클라우드 비용을 최소화하기 위해 사용량을 줄일 수 있습니다.

이에 대한 유용한 예는 클라우드에서 고가용성 (HA)을 구현할때 발생하는 높은 비용을 관리하는 것입니다. 고가용성을 구현하기 위해 동일한 유형의 리소스를 사용하여 원하는 가용성 수준을 달성하기 때문입니다.대부분의 클라우드 서비스 공급자는 고객이 리소스를 동적으로 프로비저닝 할 수 있도록 허용하지만 이러한 기능은 고가용성 목적이나 비용 절감 을 염두에 두고 설계되어 있지 않았습니다 . 이로 인해 IT 팀은 수동 프로세스를 사용해야하므로 추가 클라우드 비용 절감을 위한 인공 지능 (AI)을 활용할 수 있습니다.


 



 


## 2. 클라우드 운영 낭비 최소화
---
AI는 클라우드 운영과 관련하여 클라우드 지출에 대한 예측 분석에도 도움이 될 수 있습니다. 하나의 실제 사례로 게임 산업의 예를 들 수 있습니다. 게임 산업의 경우 AI는 운영 비용도 줄일 수 있습니다. GPU는 시각적이고, 시간 집약적인 작업을 처리하고 디지털 그래픽 을 처리하도록 설계 되었기 때문에 고성능 컴퓨팅에서 중요한 역할을 합니다.

예를 들어 게임용 PC를 구축하고 가상 CPU 및 스토리지 수와 관련하여 비용 효율적인 클라우드 서버를 선택하려는 경우 인공 지능이 작동하여 운영 낭비와 그에 따른 클라우드 비용을 줄일 수 있습니다. Vast AI 와 같은 회사는 인공 지능을 사용하여 클라우드 컴퓨팅 비용을 줄이기 위해 GPU 대여 프로세스를 단순화하고 있습니다.


 


 


## 3. 예측 분석을 위한 인공 지능 (AI)
---
마지막으로 AI는 성능 문제를 사전에 예측하고 비즈니스에서 문제가 되기 전에 해결 함으로써 클라우드 비용을 절감 할 수 있습니다 . 예를 들어 AI 머신은 가동 시간 및 가동 중지 시간을 기록하는 일련의 기록 데이터에서 학습하고 서버 또는 시스템 이 향후 중단 될 시기를 식별하는 방법을 배울 수 있습니다. 장기적으로는 다운 타임에 비용이 많이들 수 있으므로 클라우드 비용 절감으로 이어질 수 있습니다.

AI 기술은 클라우드 지출도 예측할 수 있습니다. 클라우드 비용 최적화 도구 인 Grumatic은 매시간 클라우드 지출을 모니터링 한 다음 사용량 데이터를 사용하여 AI를 사용하여 클라우드 지출을 예측할 수 있습니다. 실시간 모니터링 및 경고를 통해 Grumatic은 이상 징후가 있을 경우 경고도 제공합니다.

 



 


### 결론
주요시사점은 클라우드 컴퓨팅에는 자동화 도구 또는 수동 프로세스가 필요한 비용 최적화를 위해 서비스를 조정하기에는 변수가 너무 많습니다. 그래서, 기업이 이런 한 인간의 한계를 넘는 클라우드 비용 최적화의 미세 조정에 있어서 인공 지능의 잠재력을 활용해야 한다는 것입니다.

앞서 언급했듯이 자동화된 도구가 존재하고 APM (애플리케이션 성능 관리) 도구도 존재하지만 클라우드 비용 절감 도구로 사용하기 어렵습니다. 앞으로 인공 지능은 AI 기반 클라우드 비용 최적화 도구는 앞에서 살펴본 것처럼 긍정적인 방식으로 클라우드 운영 및 인프라 관리에 지속적인 혁신을 가져 올 것입니다.

클라우드 관련 인사이트를 담은 글을 발행합니다.