[ 고지 사항 (Disclaimer) ]
본 컨텐츠는 고객의 편의를 위하여 AWS 서비스 설명을 위해 제작, 제공된 것입니다. 만약 AWS 사이트와 컨텐츠 상에서 차이나 불일치가 있을 경우 AWS 사이트 (AWS.amazon.com)가 우선합니다. 또한 AWS 사이트 상에서 한글 번역문과 영어 원문에 차이나 불일치가 있을 경우(번역의 지체로 인한 경우 등 포함), 영어 원문이 우선합니다.
본 문서는 Cost Optimization with AWS Architecture, Tools, and Best Practices(2016, 영문) 내용에 기반하여 작성 되었습니다.
이 문서는 정보 제공의 목적으로만 제공됩니다. 본 문서의 발행일 당시 AWS의 현재 제품 오퍼링 및 실행방법 등을 설명하며, 예고 없이 변경될 수 있습니다. 고객은 본 문서에 포함된 정보나 AWS 제품 또는 서비스의 사용을 독립적으로 평가할 책임이 있으며, 각 정보 및 제품은 명시적이든 묵시적이든 어떠한 종류의 보증 없이 “있는 그대로” 제공됩니다. 본 문서는 AWS, 그 자회사, 공급업체 또는 라이선스 제공자로부터 어떠한 보증, 표현, 계약 약속, 조건 또는 보장을 구성하지 않습니다. 고객에 대한 AWS의 책임 및 의무는 AWS 계약에 의해 관리되며 본 문서는 AWS와 고객 사이의 어떠한 계약에도 속하지 않으며 계약을 변경하지도 않습니다.
© 2020, Amazon Web Services, Inc. or its affiliates. All rights reserved.
본 문서는 총 2부로 구성되어 있으며 이 글은 1부입니다.
요약
이 백서의 초점은 Well-Architected Framework의 비용 최적화 기반입니다. 고객이 AWS 환경의 설계, 제공 및 유지 관리에 모범 사례를 적용 할 수 있도록 지침을 제공합니다.
소개
AWS는 클라우드에서 안정적이고 안전하며 효율적이며 비용 효율적인 시스템을 설계하기위한 아키텍처 모범 사례에 대해 고객을 교육하는 것의 가치를 이해합니다. 이러한 노력의 일환으로 AWS에서 시스템을 구축 할 때 내린 결정의 장단점을 이해하는 데 도움이 되는 AWS Well-Architected Framework를 개발했습니다. 잘 설계된 시스템은 비즈니스 성공 가능성을 크게 높여줍니다.
이 프레임워크는 네 개의 기반을 기반으로 합니다.
· 보안
· 신뢰성
· 성능 효율성
· 비용 최적화
비용 최적화 요소는 불필요한 비용이나 최적의 리소스를 방지하거나 제거하고 비즈니스에 대한 차별화된 혜택에 대한 절감 효과를 활용할 수 있도록 도와줍니다. 비용 최적화된 시스템을 사용하면 비즈니스 목표를 달성하고 프레임워크의 다른 요소에 대한 요구사항을 충족하거나 초과 달성하면서 가능한 최고의 가격을 지불할 수 있습니다. 본 백서는 적절한 아키텍처를 선택하고 AWS 리소스를 최대한 효율적으로 활용하기 위한 심층적이고 모범 사례 지침을 제공합니다.
비용 최적화
비즈니스 문제는 본질적으로 운영 (지원 팀에 대기), 낭비 (과잉 프로비저닝 하드웨어 리소스), 장애에 취약 (조밀하게 결합 된 배포) 및 고가 (데이터 센터 실행, 보안 직원 채용 등)가 될 수 있습니다. AWS는 이러한 문제에 대한 솔루션을 제공하지만 비용 최적화를 염두에 두고 서비스를 이해하고 구현하는 것이 중요합니다.
AWS에서는 비용 최적화의 네 가지 영역에 대해 생각합니다.
· 공급과 수요를 일치
· 비용 효율적인 리소스
· 지출의 인식
· 시간이 지남에 따라 최적화
향상된 보안 또는 시장 출시 속도와 함께 비용 및 투자 수익 (ROI)은 종종 구매 결정의 요소를 결정합니다. AWS에는 AWS Trusted Advisor, 상세 청구 보고서 및 총 소유 비용 계산기 (TCO)와 같은 몇 가지 도구가 있어 청구서를 이해하고 소유 비용을 계산하며 개선 영역을 식별 할 수 있습니다. 의사 결정 프로세스에 도움이 되는 정량적 지원을 제공 할 수 있는 AWS 사례 연구 및 참조 자료도 있습니다.
설계 원칙
Keep these design principles in mind as we discuss best practices in the four areas of cost optimization:
• 예측 조달 모델에서 소비 모델로 전환합니다. 과거 데이터나 프로 형식 예측에 기반한 데이터 센터 및 서버에 많은 투자를 하는 대신, 소비하는 컴퓨팅 리소스에 대해서만 비용을 지불하고 필요에 따라 사용량을 늘리거나 줄입니다. 예를 들어 개발 및 테스트 환경은 일반적으로 근무 주간에 하루 8시간 동안만 사용됩니다. 이러한 리소스는 사용하지 않을 때 75%(40시간에서 168시간)의 잠재적인 비용 절감을 위해 중지할 수 있습니다.
• 규모의 경제를 통해 얻을 수 있는 이점은 다음과 같습니다. 수십만 명의 고객이 AWS 클라우드에 통합되어 있어 종량제(Pay-as-you-Go) 가격을 낮출 수 있습니다.
• 데이터 센터 운영에 대한 비용 지출을 중단합니다. 클라우드 컴퓨팅 벤더는 서버 랙 설치, 스택 쌓기 및 전원 공급 작업을 많이 수행하므로 IT 인프라보다는 고객과 핵심 비즈니스에 집중할 수 있습니다.
• 지출의 속성을 투명하게 지정합니다. 클라우드를 통해 시스템 비용을 보다 쉽게 파악하고 IT 비용을 개별 비즈니스 소유자에게 귀속시킬 수 있습니다. 이를 통해 ROI를 측정하고 소유자에게 리소스를 최적화하고 비용을 절감할 수 있는 인센티브를 제공합니다.
• 관리형 서비스를 사용하여 소유 비용을 절감할 수 있습니다. 클라우드에서 관리 서비스는 이메일 전송 또는 데이터베이스 관리와 같은 작업에 대해 서버를 유지 관리하는 데 따른 운영 부담을 덜어줍니다. 또한 관리 서비스는 클라우드 규모로 운영되기 때문에 트랜잭션 또는 서비스당 비용을 절감할 수 있습니다.
• 설계 선택 사항을 지속적으로 재평가합니다. 하드웨어 및 소프트웨어에 대규모 자본을 투자해야 하는 기존 IT 인프라 방식과 달리 AWS는 대부분의 서비스에 대해 종량제 가격을 제공합니다. 즉, 프로젝트의 라이프사이클이 시작될 때 설계 수준에서 내린 결정에 구속되지 않습니다. 따라서 초과 프로비저닝 또는 예상치 못한 수요에 대한 충족이 불가능할 위험이 줄어듭니다. 설계 결정을 지속적으로 재평가할 수 있습니다. 또한 새로운 AWS 제품의 사용을 검토하여 효율성이 더욱 향상되는지 확인할 수 있습니다.
수요와 공급
기존 IT 인프라 모델과 달리 AWS는 본질적으로 탄력적이고 온디맨드입니다. AWS는 필요에 따라 프로그래밍 방식으로 스케일업 및 스케일다운하거나 스토리지 개체를 자동으로 아카이브하거나 만료하는 라이프사이클 규칙을 구현하는 메커니즘을 제공합니다. 이러한 기능과 서비스를 통해 비용 최적화된 아키텍처를 구현할 수 있습니다.
컴퓨팅
AWS 에코시스템에서 컴퓨팅은 Amazon Elastic Compute Cloud(Amazon EC2)에서 시작됩니다. 가장 기본적인 수준에서 EC2는 클라우드의 가상 시스템입니다.
Amazon EC2는 2006년부터 발전해 왔으며, 다음 다이어그램과 같이 Auto Scaling 및 Amazon EC2 Container Service(효율성을 높이기 위해), Elastic Load Balancing(복원성을 위해), AWS Lambda(서버 없는 컴퓨팅용)와 같은 다른 서비스로 이어졌습니다.
Amazon EC2
비용 최적화는 애플리케이션 또는 워크로드의 요구 사항을 가장 적절한 인스턴스 유형과 일치시킬 수 있는 경우에만 성공할 수 있습니다. Amazon EC2 인스턴스 유형 및 크기는 CPU, 메모리, 스토리지 및 네트워크 용량을 다양하게 조합하여 애플리케이션에 적합한 리소스 조합을 선택할 수 있는 유연성을 제공합니다. 예를 들어 C4 인스턴스는 컴퓨팅 리소스가 많이 필요한 워크로드에 적합합니다. M4 인스턴스는 다중 역할 인스턴스 유형입니다. G2 인스턴스는 전용 그래픽 프로세서가 필요한 워크로드를 대상으로 합니다. 올바른 인스턴스 유형을 선택하면 비용 효율적인 방식으로 성능을 최적화할 수 있습니다.
작업 부하 요구 사항을 이해한 후에는 EC2 지출에서 각각 30% 또는 최대 90%까지 감소할 수 있는 예약된 인스턴스와 스폿 인스턴스를 활용하는 것이 좋습니다.
벤치마킹
AWS에서는 워크로드와 가장 일치하는 인스턴스(instance) 유형을 선택한 다음 벤치마킹 기간을 시작하는 것이 좋습니다. 인스턴스 유형을 변경할 수 있으므로 각 유형에 대해 벤치마킹을 수행할 수 있습니다. AWS가 새 인스턴스 유형을 릴리스하는 경우에도 이 작업을 수행할 수 있습니다.
예약 인스턴스
인스턴스 유형을 결정한 후에는 예약된 인스턴스를 구입할 수 있습니다. 이는 특정 AWS 지역의 용량을 구매하기 위한 초기 약속으로, 운영 비용을 크게 절감할 수 있습니다.
예약된 인스턴스는 대금 청구 구성입니다. 이 인스턴스는 해당 인스턴스 유형에 대해 선택하고 구입한 가용성 영역(AZ)에서 사용 가능한 용량을 보장하며 시간당 비율을 크게 낮춥니다. 예약된 인스턴스를 24x7 리소스로 처리하는 것 외에 워크로드가 시간에 따라 달라지는 경우에도 예약된 인스턴스를 결합할 수 있습니다.
예를 들어, m4.large와 같은 다목적 인스턴스 유형의 예약 인스턴스가 있다고 가정 해 봅시다. 근무 시간 동안 총 9 시간 (오전 8시-오후 5시) 동안 만이 인스턴스를 실행하면 됩니다. 그러나 동일한 가용 영역에 동일한 인스턴스 유형을 사용하고 근무 시간 (5:00 P.M.-8A.M.) 후에 실행할 수 있는 다른 워크로드가 있습니다. 주간 인스턴스가 종료 된 후 동일한 인스턴스 유형 (m4.large)을 선택하고 해당 인스턴스에서 저녁 워크로드를 시작할 수 있습니다.
첫 번째 인스턴스가 종료되면 예약된 인스턴스 시간당 비율이 애프터타임 인스턴스에 적용되므로 전반적인 비용 효율이 극대화됩니다.
워크로드 및 인스턴스 유형은 시간이 지남에 따라 변경되므로 인스턴스 선택을 지속적으로 재평가하는 것이 중요합니다. 예약된 인스턴스는 현재 1년 또는 3년 계약으로 제공되며, 예약된 인스턴스 약속이 만료되기 전에 요구 사항이 변경될 수 있습니다. 이 경우 EC2 컨테이너 서비스(Amazon ECS)를 사용하여 인스턴스 사용량을 늘리거나 AWS 예약 인스턴스 마켓플레이스에서 예약된 인스턴스를 판매할 수 있습니다.
오토 스케일링
Auto Scaling을 사용하면 정의한 조건에 따라 Amazon EC2 용량을 자동으로 늘리거나 줄일 수 있습니다. 예를 들어 기존 IT 배포에서는 최대 사용량을 기준으로 하드웨어 요구 사항을 결정해야합니다. 계산 리소스가 예측 가능한 최대 로드 기간에 의해 결정되고 축소 할 수 없는 경우 로드가 가장 낮을 때 컴퓨팅 리소스를 낭비하게 됩니다. Auto Scaling은 리소스에 대한 수요가 변화함에 따라 인스턴스 수를 늘리거나 줄여 효율성과 비용을 최적화합니다.
업무 시간 (오전 9시 ~ 오후 5시) 동안 워크로드가 실행되는 경우 지정된로드에 적합한 인스턴스를 시작하도록 Auto Scaling을 구성 할 수 있습니다. 업무 시간 후 Auto Scaling은 인스턴스 수를 줄여 시간당 운영 비용에 대한 지출을 최소화 할 수 있습니다.
스팟 인스턴스
스팟 인스턴스를 통해 고객은 여분의 Amazon EC2 컴퓨팅 용량에 입찰 할 수 있습니다. 스팟 인스턴스는 온 디맨드 요금에 비해 할인 된 가격으로 제공되는 경우가 많으므로 애플리케이션 실행 비용을 크게 줄이고 애플리케이션의 컴퓨팅 용량 및 처리량을 늘릴 수 있습니다.
스팟 시장을 활용하면 지속적인 상태가 필요없는 워크로드의 운영 비용을 줄일 수 있습니다. 이러한 유형의 모델에 적합한 작업에는 Amazon EMR (Amazon Elastic MapReduce) 클러스터가 포함됩니다. 스팟 인스턴스를 사용하면 추가 코어 노드로 온 디맨드 클러스터를 확장하고 Amazon EMR Hadoop 작업을 완료하는 데 필요한 시간을 줄일 수 있습니다.
입찰 가격이 최대 입찰을 초과하면 스팟 인스턴스로 실행중인 코어 노드가 종료 될 예정이라는 알림이 표시됩니다. 이 경우 Hadoop은 클러스터의 나머지 사용 가능한 인스턴스에서 실행중인 작업을 자동으로 다시 시작합니다.
스팟 인스턴스에 대한 비 지속적 사용 사례의 또 다른 예는 일괄 처리 작업입니다. 이러한 논리가 포함 된 경우 이러한 작업은 종종 중단으로 처리를 계속할 수 있습니다. 적절한 입찰 가격의 스팟 인스턴스를 사용할 수있을 때 야간 처리 작업을 시작할 수 있습니다. 해당 인스턴스가 종료되면 스팟 인스턴스를 다시 사용할 수있을 때 작업이 재개 될 수 있습니다.
Amazon ECS
Amazon EC2 Container Service (Amazon ECS)는 EC2 인스턴스가 Docker 컨테이너를 호스팅 할 수있는 플랫폼을 제공합니다. 이를 통해 워크로드의 세분성 수준과 EC2 인스턴스의 효율성이 향상됩니다. 이는 여러 EC2 인스턴스에서 애플리케이션 또는 인프라 구성 요소를 실행하는 대신 여러 컨테이너를 호스팅 할 수있는 대규모 인스턴스 유형이있는 경우 특히 유용합니다.
비용 최적화 관점에서 Amazon ECS는 활용률이 낮은 예약 인스턴스의 컨테이너와 함께 사용할 수도 있습니다.
m4.xlarge 예약 인스턴스를 사용하지만 CPU 리소스의 5 % 만 사용한다고 가정 해 봅시다. 인스턴스에 여러 컨테이너를 추가하고 사용률을보다 효율적인 수준으로 높일 수 있기 때문에 Amazon ECS의 좋은 사용 사례입니다.
Amazon ECS를 사용하여 일정에 따라 컨테이너를 인스턴스에 배치 할 수도 있습니다. 원래 인스턴스의 전원을 끄지 않고 예약 인스턴스 예를 확장하려면 오후 6 시부 터 컨테이너가 컨테이너에 배치되도록 예약 할 수 있습니다. 오전 8 시까 지 예약 인스턴스 시간당 요금으로 사용하십시오.
AWS Lambda
상시 실행 인스턴스를 실행하면 특히 서비스가 할 일을 기다리는 경우 낭비가 될 수 있습니다. 예를 들어 사진 처리 응용 프로그램을 만든 경우 일반적으로 리스너 또는 폴링 서비스에서 수신 작업을 찾은 다음 무언가가 업로드 될 때 처리 코드를 시작합니다. 여전히 서버 (인스턴스)를 실행하고 애플리케이션 코드에 대한 컴퓨팅 플랫폼을 제공하기 위해 많은 인스턴스를 결정한 후 유지 보수해야 합니다. Lambda를 사용하면 코드를 작성하고 시작하는 트리거 이벤트를 설정하기 만하면 됩니다.
Lambda는 서버리스 컴퓨팅입니다. Lambda 서비스는 코드에 컴퓨팅 플랫폼을 제공하고 사용자가 제공 한 매개 변수를 기반으로 이벤트를 트리거 합니다. 따라서 운영 체제에 대한 자체 실행 인스턴스 및 관리 정보가 필요하지 않습니다.
Lambda는 업로드 또는 느슨하게 분리 할 수 있는 서비스 요청과 같은 이벤트에 응답하는 워크로드에 적합한 선택입니다. Lambda는 100 밀리 초마다 측정되기 때문에 세분화 됩니다.
아키텍처 계획과 지속적인 개정 및 평가를 통해 비용 최적화를 달성 할 수 있습니다. 가상화 된 인스턴스에서 서버리스 컴퓨팅에 이르기까지 AWS 서비스를 사용한다는 것은 디자인 결정이 영구적 일 필요가 없음을 의미합니다. 또한 배포 된 제품을 지속적으로 최적화하기 위해 출시 된 신제품 및 서비스를 평가할 수 있습니다.
스토리지
스토리지 솔루션을 고려할 때 다음 요소가 특히 중요합니다.
· 내구성
· 유효성
· 규제 및 거버넌스 요구 사항
· 보안
· 기능 요구 사항
AWS 스토리지 솔루션은 다양한 기술 및 가격 요구 사항을 충족 할 수 있습니다. 비용 최적화 관점에서 가장 컴퓨팅 관련 비용이 저렴한 스토리지 옵션은 로컬로 연결된 임시 스토리지입니다. 이는 EC2 인스턴스의 실행 속도에 포함 된 스토리지입니다. 임시 스토리지의 로컬 처리 특성은 장기적이고 영구적 인 데이터 스토리지가 아닙니다. 보다 영구적 인 스토리지를 위해 Amazon Elastic Block Store (Amazon EBS)는 EC2 인스턴스가 다른 인스턴스로 마이그레이션 할 수 있는 블록 레벨 디바이스에 쓸 수 있도록 합니다. 또한 이러한 볼륨을 백업하고 마이그레이션하기위한 스냅 샷 기능을 제공합니다.
EC2 인스턴스에 사용할 수 있는 스토리지 유형은 로그 파일 및 중요하지 않은 데이터에 적합한 비 영구적 또는 임시 스토리지와 지속성이 필요한 애플리케이션 및 워크로드를 위한 영구 스토리지의 두 가지입니다.
각 옵션에는 성능과 비용 측면에서 장단점이 있습니다. 임시 스토리지는 EC2 인스턴스 시간당 요금에 포함됩니다. Amazon EBS는 추가 비용이 듭니다. 초기 평가 동안 그리고 다시 한 번 워크로드가 실행 된 후에 워크로드 당 이러한 장단점을 고려해야합니다. 이렇게 하면 할당 한 리소스를 사용하고 있는지 확인하고 필요한 경우 조정할 수 있습니다. 예를 들어, Amazon EBS 볼륨 유형 중에서 워크로드가 “파열”수준의 IOPS에서보다 효율적으로 실행되는 경우 프로비저닝 된 IOPS에서 GP2 인스턴스로 전환 할 수 있습니다. AWS는 Trusted Advisor를 통해 고객에게 볼륨 정보를 제공합니다. 이 정보는 연결되지 않은 Amazon EBS 볼륨 및 기타 중요한 배포 정보를 강조합니다. 이 경우 적절한 아카이브 전략을 통해 연결되지 않은 Amazon EBS 볼륨을 삭제하면 스토리지 비용이 최소화됩니다.
Amazon S3
인터넷 연결 및 99.999999999 %의 내구성을 제공하는 전세계 어디에서나 액세스 할 수있는 Amazon S3는 사용할 수있는 스토리지 양에 제한이 없으며 고객이 더 이상 필요하지 않은 데이터를 빠르게 삭제 또는 아카이브 (Amazon Glacier) 할 수있는 메커니즘을 제공합니다. 액세스 저장. Amazon S3 수명주기 정책을 사용하면 Amazon S3에서 Amazon Glacier로 데이터를 마이그레이션하거나 완전히 삭제할 수 있습니다. Amazon S3는 고객에게 다양한 수준의 내구성, 가용성 및 요금으로 스토리지 클래스를 제공합니다. 이러한 다른 클래스는 저장 메커니즘에 99.999999999 %의 내구성이 필요하지 않을 때 유용 할 수 있습니다.
Amazon Glacier
Amazon Glacier를 사용하여 아카이빙 요구 사항을 해결하고 비용 최적화를 개선 할 수 있습니다. Amazon Glacier는 설계 상 콜드 스토리지입니다. 보관해야하지만 자주 액세스 할 필요는없는 데이터에 사용해야합니다. S3-to-Amazon Glacier 마이그레이션은 원활 할 수 있지만 Amazon Glacier에서 소규모로 자주 검색하는 경우 비용이 많이 발생합니다. 따라서 검색 프로세스를 신중하게 고려해야합니다.
AWS는 IT 인프라 비용을 절감하고 기업의 핵심가치에 더욱 집중할 수 있도록 합니다.
AWS에 대한 자세한 문의사항은 여기를 눌러 주세요.
빌드업웍스는 AWS 컨설팅 파트너로 고객 비즈니스를 최우선으로 하며 고객의 클라우드의 성공적인 시작과 운영을 지원합니다.
