LFCA: 클라우드 비용 및 예산 책정 학습 – 16부


조직이 비즈니스를 간소화하기 위해 클라우드가 제공하는 수많은 이점을 활용하려고 함에 따라 수년에 걸쳐 클라우드 서비스가 기하급수적으로 채택되었습니다. 대부분의 기업은 온프레미스 인프라를 클라우드와 통합하거나 핵심 서비스를 클라우드로 완전히 이전했습니다.

클라우드는 사용한 만큼만 지불하는 종량제 모델을 제공하지만 클라우드 공급업체의 목표는 항상 제공된 서비스에서 수익을 극대화하는 것입니다.

클라우드 공급업체는 다양한 지역에 대규모 데이터 센터를 구축하는 데 수십억 달러를 투자하고 있으며 이를 저렴하게 제공할 생각은 없습니다. 이것이 고객과 기업에 명백하지 않다는 것은 놀라운 일입니다.

고객으로서 귀하의 목표는 가능한 최소 비용으로 뛰어난 클라우드 서비스를 얻는 것입니다.

가격 책정에 대한 명확성 부족

온프레미스 환경에서 전체 인프라를 설정하고 애플리케이션을 배포하는 비용은 이미 관리 팀에서 알고 있습니다. 운영 및 개발 팀은 일반적으로 예산을 공식화하고 승인을 위해 CFO에게 제출합니다. 간단히 말해서 인프라에 지출할 금액을 정확히 알고 있습니다.

클라우드 가격 책정 비용은 특히 각 클라우드 서비스가 끌어들이는 비용을 이해하는 데 상당한 시간을 소비하지 않은 사용자에게 상당히 모호할 수 있습니다.

AWS 및 Microsoft Azure와 같은 주요 클라우드 제공업체의 가격 모델은 온프레미스 비용에 비해 간단하지 않습니다. 인프라에 대해 지불할 비용에 대한 명확한 매핑을 얻을 수 없습니다.

AWS Lambda를 사용하여 서버리스 웹 사이트를 배포하는 예를 들어 보겠습니다.

웹사이트의 프런트 엔드(HTML, CSS 및 JS 파일)는 S3 버킷에서 호스팅되는 동시에 Cloudfront 캐싱을 활용하여 콘텐츠 제공을 가속화합니다. 프런트엔드는 API 게이트웨이 HTTPS 엔드포인트를 통해 Lambda 함수에 요청을 보냅니다.

그런 다음 Lambda 함수는 애플리케이션 로직을 처리하고 데이터를 RDS(분산 관계형 데이터베이스 시스템) 또는 DynamoDB(비관계형 데이터베이스)와 같은 관리형 데이터베이스 서비스에 저장합니다.

웹 사이트 설정이 간단해 보이지만 4개의 \u200b\u200bAWS 서비스를 사용하게 됩니다. 웹사이트의 정적 파일을 저장하기 위한 S3 버킷, 웹사이트의 콘텐츠 전송을 가속화하기 위한 CloudFront CDN, HTTPS 요청 라우팅을 위한 API 게이트웨이, 마지막으로 데이터 저장을 위한 RDS 또는 DynamoDB가 있습니다. 이러한 각 서비스에는 고유한 가격 모델이 있습니다.

S3 버킷에 객체를 저장하는 데 발생하는 요금은 객체의 크기, 저장 기간, S3 버킷의 스토리지 클래스에 따라 다릅니다. S3 버킷과 연결된 6개의 스토리지 클래스가 있으며 각각 고유한 가격 모델이 있습니다. 다음은 다양한 S3 스토리지 클래스의 가격 모델에 대한 전체 분석입니다.

CloudFront CDN은 처음 1년 동안 50GB의 무료 아웃바운드 데이터 전송을 제공하고 1년 동안 매월 2,000,000개의 HTTP 또는 HTTPS 요청을 무료로 제공합니다. 그 이후에는 지역, 계층 및 프로토콜별로 비용이 다릅니다(HTTPS는 HTTP보다 더 많은 요금을 부과합니다).

API 게이트웨이로 진행할 수 있지만 요점은 알 것입니다. 다양한 서비스에 대한 가격 책정 모델은 여러 요인에 따라 복잡해질 수 있습니다. 따라서 클라우드에 리소스를 배포하기 전에 다양한 클라우드 서비스 비용에 대해 실사를 수행하는 것이 현명합니다.

안타깝게도 일부 조직의 경우 개발 팀이 다양한 서비스에 대한 가격 책정 모델에 주의를 기울이지 않고 프로젝트에 착수하여 그에 따라 예산을 책정할 수 있습니다. 시급한 요구 사항은 일반적으로 정해진 기한까지 애플리케이션을 배포하고 가동하는 것입니다.

클라우드 서비스에 대한 예산 책정은 일반적으로 잘 고려되지 않으며, 그 결과 회사를 폐업시키겠다고 위협할 수 있는 막대한 클라우드 비용이 발생합니다. 다양한 클라우드 서비스 계획 및 비용에 대한 명확한 이해 없이는 예산이 통제 불능 상태에 빠질 수 있습니다.

과거에 자이언트 기업은 끔찍한 구름 청구서로 인해 혼탁한 상황에 직면했습니다.

2018년 가을, Adobe는 개발 팀이 Microsoft의 클라우드 컴퓨팅 플랫폼인 Azure에서 실행 중인 프로젝트에 대해 예상치 못한 클라우드 요금으로 하루에 무려 8만 달러를 벌어들였습니다.

1주일이 지나서야 간과한 사실이 적발되었고, 그 당시 청구서는 눈덩이처럼 불어 500,000달러가 훨씬 넘었습니다. 같은 해 Pinterest의 클라우드 청구액은 1억 9000만 달러까지 올라갔고, 이는 당초 예상보다 2000만 달러 더 많은 금액이었습니다.

따라서 클라우드 서비스 비용에 대한 명확한 이해는 비즈니스를 쉽게 중단시킬 수 있는 누적 클라우드 비용을 방지하는 데 필수적입니다. 이러한 이유로 클라우드 청구 및 예산 책정은 리소스 프로비저닝을 시작하기 전에 최우선 순위가 되어야 합니다. 결국 고객의 목표는 클라우드가 제공하는 서비스를 즐기면서 최대한 적은 비용으로 지출하는 것임을 기억하십시오.

클라우드 비용 최적화 – 비용 관리 모범 사례

클라우드 컴퓨팅은 운영 비용 절감과 함께 필요한 확장성을 제공하지만 사실은 AWS 및 Microsoft Azure와 같은 대부분의 공급업체는 사용 여부에 관계없이 주문한 리소스에 대해 비용을 청구한다는 것입니다. 이는 유휴 리소스가 여전히 원치 않는 청구서를 발생시켜 귀하의 예산을 크게 증가시킬 것임을 의미합니다.

클라우드 최적화는 유휴 리소스를 식별 및 제거하고 리소스 낭비를 방지하기 위해 필요한 것을 정확히 주문하도록 하여 전체 클라우드 지출을 낮추는 것입니다.

다음은 클라우드 비용을 관리하고 예산 내에서 작업하는 데 도움이 되는 몇 가지 모범 사례입니다.

눈덩이처럼 불어나는 클라우드 비용을 완화하는 가장 쉬운 방법 중 하나는 사용하지 않는 리소스를 찾아 끄거나 종료하는 것입니다. 사용하지 않는 리소스는 개발자나 시스템 관리자가 데모 목적으로 가상 서버를 배포하고 끄는 것을 잊었을 때 종종 발생합니다.

또한 관리자는 종료 후 EC2 인스턴스에서 EBS 볼륨과 같은 연결된 블록 스토리지를 제거하지 못할 수 있습니다. 최종 결과는 조직이 사용하지 않는 리소스에 대해 막대한 Cloud 청구서를 작성하게 된다는 것입니다. 이 문제에 대한 해결 방법은 인프라를 매핑하고 사용하지 않는 모든 클라우드 인스턴스를 종료하는 것입니다.

클라우드 요금을 높이는 또 다른 요인은 리소스를 과도하게 프로비저닝하여 결국 유휴 리소스가 되는 것입니다. 4GB의 RAM과 2개의 vCPU만 필요한 애플리케이션을 호스팅하기 위해 가상 서버를 배포하는 시나리오를 가정합니다. 대신 32GB의 RAM과 4개의 CPU가 있는 서버를 선택합니다. 이는 결국 많은 유휴 및 사용되지 않은 리소스에 대해 비용이 청구됨을 의미합니다.

클라우드는 확장 또는 축소할 수 있는 기능을 제공하므로 가장 좋은 전략은 필요한 만큼만 프로비저닝하고 나중에 리소스 수요 변화에 따라 확장하는 것입니다. 쉽게 확장할 수 있을 때 리소스를 과도하게 구매하지 마세요 :-)

Google Cloud, AWS 및 Azure와 같은 주류 제공업체는 월별 클라우드 청구서의 대략적인 추정치를 제공하는 직관적인 계산기를 제공합니다. AWS는 더욱 우아하고 직관적인 하늘색 계산기를 제공합니다.

AWS 및 Azure와 같은 주요 클라우드 공급업체는 클라우드 지출을 추적하는 데 도움이 되는 청구 및 비용 관리 대시보드를 제공합니다. 지출이 미리 정의된 예산에 가까워지면 청구 알림을 활성화하여 청구서를 최적화하는 데 필요한 조정을 할 수 있습니다.

또한 비용 절감을 위해 클라우드 리소스를 축소하는 데 도움이 되는 활용도가 낮은 징후를 조사하기 위해 제공되는 기본 제공 모니터링 대시보드를 사용하여 리소스 사용량을 검토하는 것이 좋습니다.

클라우드는 비즈니스를 한 단계 끌어올릴 수 있는 엄청난 잠재력을 제공합니다. 그러나 유휴 상태이거나 사용되지 않는 클라우드 리소스에 대한 지출은 비즈니스에 큰 차질을 초래할 수 있습니다.

이러한 이유로 운영 팀은 배포하려는 리소스의 가격 모델을 주의 깊게 연구하고 클라우드 지출을 억제하기 위해 요약한 최적화 조치를 적용하는 것이 좋습니다.