AWS CLOUD 2017 - AWS 클라우드 비용 최적화 전략 (오길재 테크니컬 어카운트 매니저 & 이범석 테크니컬 어카운트 매니저)
3 likes•4,167 views
AWS CLOUD 2017 - AWS 클라우드 비용 최적화 전략 (오길재 테크니컬 어카운트 매니저 & 이범석 테크니컬 어카운트 매니저)
- 1. AWS 클라우드 비용 최적화 전략
- 2. 여기 계신분들에 대한 몇 가지 가정… 1. 현재 AWS를 사용하고 있다. 2. AWS를 지속 사용할 예정이다. 3. 계획에 맞는 비용 지출과 현황을 알고 싶다. 4. 비용을 최적화하고 싶다.
- 3. AWS 가격 철학 More AWS Usage More Infrastructure Economies of Scale Lower Infrastructure Costs Reduced Prices More Customers 에코시스템 글로벌 커버리지 새로운 기능과 새로운 서비스 인프라 혁신 “CJ 오쇼핑은 글로벌 홈쇼핑 사업 해외 진출시 AWS클라우드를 활용하여, 기존 IT투자 비용을 90% 이상 절감할 수 있었습니다.” 류형석 책임, CJ 오쇼핑 글로벌 사업팀 59
- 4. 비용 효율화는… Going From: • 사용한 만큼 비용을 지불 To: • 필요한 만큼 비용을 지불
- 5. 오늘의 주제 Frameworks Tools Best Practices
- 6. 정책과 프로세스
- 7. 자원 생성 권한 및 Tag 관리 ü 자원 생성 권한 설정 ü 필요한 정보는 모두 태그 ü 용도에 맞게 태그 사용 1. 자원 태그 2. 비용 할당 태그
- 8. 필요한 정보 태그 및 비용 할당 태그
- 9. 지속적인 비용 관찰 ü 결제 보고서 (Detailed Billing Report) ü 예산 (Budgets)을 통한 비용 감시 ü Cost Explorer는 비용의 나침반
- 10. 결제 보고서 (Detailed Billing Report) 설정 dbr-bucket-name dbr-bucket-name
- 11. 예산 (Budgets)을 통한 비용 감시 고유한 AWS 예산 만들기 1. 예산의 이름을 입력하고, 예산 금액을 지정하고, 예산이 적용되는 기간을 설정합니다. 예) 월간 예산, 월별 (2017.01.01 - 2017.12.31), 예산 금액 $1,000 2. 선택 옵션 필터로 예산 기준을 구체화합니다. 예) EC2-Instances 3. 예산 임계값에 도달할 경우 이메일 및 SNS 주제로 알림을 전송합니다. 예) 실제 비용이 80% 이상일 경우 경고 발송
- 12. Cost Explorer는 비용의 나침반
- 13. Best Practice: 자원 생성 및 감시 • 특정 그룹 또는 팀에만 특정 AWS 자원 생성 권한 부여 • 각 환경별 (예. Dev/Test vs. Production) 다른 정책 생성 • 자원을 설명할 수 있는 태그 추가 • 잘못된 태그를 사용하는 인스턴스 감시, 경고 발송 또는 정지 • 예산을 설정하여 임계치에 도달하면 경고 발송 • AWS 또는 Partner 툴을 통해서 비용 분석
- 14. 사례: Cost Optimization Monitoring Cost Optimization Monitor 구축 - AWS CloudFormation를 통한 구축 - 상세 billing report data를 Amazon Elasticsearch로 전달 - 사용하기 쉽고 편집 가능한 대시보드를 통해 분석 가능 Dashboards에 대한 접속 제한 - Nginx proxy를 통한 간편한 인증 방법으로 Amazon Elasticsearch로 접근 - 유저 인증을 통한 추가 보안 제공. 단순하고 간편하게 분석 내용 시각화 가능 - Kibana 4를 통한 기본 대시보드 제공 - 손쉽게 유저가 대시보드 설계
- 15. 사례: Cost Optimization Monitoring
- 16. 아키텍처와 디자인
- 17. ü Auto Scaling 사용 ü 최적 조합에 대한 검토 Peak 기반 설계에서 탄력적 설계
- 18. Auto Scaling 사용 사용량에 따른 Compute Cluster 사이즈 자동 조정 Auto Scaling 정책 발동 기능 상세설명 제어 인스턴스 최소/최대 개수 및 스케이링/쿨다운 정책 정의 CloudWatch 연동 스케일링을 위해서 CloudWatch에 수집된 Metric을 사용 인스턴스 타입 온디맨드 인스턴스와 스팟 인스턴스를 위한 Auto Scaling 운영 aws autoscaling create-auto-scaling-group --auto-scaling-group-name MyGroup --launch-configuration-name MyConfig --min-size 4 --max-size 200 --availability-zones ap-northeast-2a
- 19. 최적 조합에 대한 검토 용량이 큰 인스턴스로 적게 vs. 용량이 작은 인스턴스로 많이 35 m4.xlarge @ $0.265/hr $6,678 / mo* 59 m4.large @ $0.132/hr $5,608 / mo* * 서울 지역에서 Amazon Linux 인스턴스를 한 달에 720시간 사용한다는 가정
- 20. 유휴 자원 및 사용하지 않는 자원 확인 ü Trusted Advisor 사용 ü CloudWatch를 이용한 감시, 수집
- 21. Trusted Advisor, CloudWatch 사용
- 22. 비용을 고려한 설계 ü 온디맨드, 예약, 스팟 인스턴스 ü 스토리지 클래스와 수명 주기 ü AWS Managed/Application 서비스
- 23. 온디맨드, 예약, 스팟 인스턴스 예약 인스턴스 1년 또는 3년 사용 예약을 통한 대폭 할인된 요금을 제공 선결제 금액에 따른 할인율 적용 일정한 워크로드에 적합 온디맨드 인스턴스 사용한 시간 만큼 비용을 지불하는 일반적인 형태의 인스턴스 제약없는 일반적인 사용에 적합 스팟 인스턴스 가격 경쟁을 통한 구입 스팟 인스턴스의 공급과 수요에 따라 시간당 가격 변동 데이터 분석, 배치 작업, 백그라운드 프로세싱 및 선택적 작업에 적합
- 24. 온디맨드, 예약, 스팟 인스턴스 1. 일정한 워크로드를 위한 예약 인스턴스 사용 2. 다수의 Auto Scaling 그룹 3. Auto Scaling 시 스팟 인스턴스 부터 사용 4. 스팟 인스턴스의 가격이 너무 높거나 사용이 불가할 경우 온디맨드 인스턴스 사용 0 2 4 6 8 10 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 /Spot온디맨드 인스턴스 스팟 인스턴스 예약 인스턴스
- 25. 적당한 스토리지 클래스와 수명 주기 • Amazon S3 Standard - Infrequent Access Ø 동일한 내구성, 동일한 성능 Ø 조금 낮은 가용성: 99.9% Ø 일반 S3보다 약 58% 비용 절감 • Amazon Glacier Ø S3와 동일한 내구성 Ø 복구하는데 3-5시간 소요 Ø 아카이브, 장기 백업, 오래된 데이터 Ø 최대 65% 비용 절감 • Amazon S3 Reduced Redundancy Ø 99.99% 내구성 vs 99.999999999% Ø 재생산이 쉬운 경우 Ø 최대 20% 비용 절감 AWS Storage Amazon EBS Amazon EFS Amazon S3 Amazon Glacier
- 26. AWS Managed/Application 서비스 Amazon Relational Database Service (RDS) Amazon DynamoDB Elastic Load Balancing (ELB) Amazon Simple Queue Service (SQS) Amazon Simple Email Service (SNS) Amazon Kinesis Amazon ElastiCache Amazon Redshift Amazon Route 53 Amazon Simple Notification Service (SNS) AWS Lambda Amazon Elastic MapReduce (EMR)
- 27. Best Practice: 사용 용도와 용량에 맞게 시작 요구사항에 가장 부합하는 인스턴스 고르기 최적화 CloudWatch와 Trusted Advisor를 사용한 평가 확장 다수의 인스턴스들을 다수의 가용 영역에서 운영 메모리부터 시작해서 가장 적합한 가상 Core 고르기 Peak IOPS 처리 가능한 스토리지 찾기 사용량 모니터링을 통한 인스턴스 사이즈 조절 (Up/Down) Auto Scaling을 사용하여서 사용량에 따라서 필요한 만큼 Scale In/Out
- 28. 사례: EC2 Right Sizing EC2 Right Sizing solution 구축 - AWS CloudFormation을 통해 구축 및 단기간 사용 - Right-sizing 권고 결과를 S3 bucket 에 저장 Scale-down 추천 Instance 및 절감액 제시 - 인스턴스 변경 추천 대상 제시 - 변경시 예상되는 월 절감 비용 산출
- 29. 사례: EC2 Right Sizing region InstanceId Old Instance Type Old vCPU Old Memory Old Storage Old Network Performance Old Rate New Instance Type New vCPU New Memory New Storage New Network Performance New Rate Cost Saved Per Month APN1 i-066b5ca3... m4.large 2 8 GiB EBS only Moderate 0.139 t2.large 2 8.0 GiB EBS only Low to Moderate 0.128 7.92 APN1 i-0d7113dc… m4.xlarge 4 16 GiB EBS only High 0.278 t2.xlarge 4 16.0 GiB EBS only Moderate 0.256 15.84 APN2 i-0b2070be… c4.large 2 3.75 GiB EBS only Moderate 0.114 m3.medium 1 3.75 GiB 1x4 SSD Moderate 0.091 16.56 APN2 i-089212c5... c4.large 2 3.75 GiB EBS only Moderate 0.114 m3.medium 1 3.75 GiB 1x4 SSD Moderate 0.091 16.56 APN2 i-0519186f… c4.xlarge 4 7.5 GiB EBS only High 0.227 t2.large 2 8.0 GiB EBS only Low to Moderate 0.128 71.28 APN2 i-0a36da54… c4.xlarge 4 7.5 GiB EBS only High 0.227 t2.large 2 8.0 GiB EBS only Low to Moderate 0.128 71.28 Total 199.44 i-066b5ca3e2264fb27 m4.large => t2.large Max CPU 46.58% Max IOPS 0 Max Network 3.33Mbps i-0d7113dc6d970a524 m4.xlarge => t2.xlarge Max CPU 23.46% Max IOPS 0 Max Network 4.39Mbps i-0519186f2db68858a c4.xlarge => t2.large Max CPU 30.17% Max IOPS 0 Max Network 4.36Mbps
- 31. 최신 서비스/RI 구매
- 32. ü 새로운 인스턴스 타입, 서비스 ü 통합 결제 기술 업데이트 확인
- 33. • 새로운 인스턴스 타입/ 패밀리 (예. C5, R4 등) • 새로운 기술 서비스 (예. Amazon Athena, Amazon Batch 등) 새로운 인스턴스 타입, 서비스 New Prices 0 0.005 0.01 0.015 0.02 0.025 0.03 ECU$/Hour 60 %
- 34. • 모든 연결 계정에서 발생한 비용을 하나의 청구서로 수령 ü 예약 인스턴스 할인 공유 ü Tiering 요금 혜택/대량 사용 할인 • 연결 계정 확인 및 관리 통합 결제 (Consolidated Billing) 사용
- 35. • 새로운 서비스나 기술이 출시될 경우 설계를 재점검 • 통합 결제를 통한 Tiering 가격 이점 활용 Best Practice: 설계시 모든 수단 활용
- 36. 예약 인스턴스 구매 전략 ü 80%만 사용해도 이득 ü 활용률보다 절감 효과 우선 ü 시간 단위로 최적 수량 산출 ü 월단위의 반복적인 구매 ü Cost Explorer를 통한 낭비 최소화
- 37. 80%만 사용해도 이득 Seoul, Linux, Shared Tenancy $ per hour On-Demand 1Y Partial Upfront RI Savings m4.large $0.132 $0.088 33.33% c4.large $0.144 $0.085 40.97% i2.xlarge $1.001 $0.623 37.76% c4.large 인스턴스를 1개월 다음과 같이 사용하였다고 가정할 경우 Hours On-Demand Partial Upfront RI Savings 100% of the month 744 $107.136 $63.24 41% 80% of the month 595 $85.68 $63.24 26% 59.13% of the month 440 $63.36 $63.24 0% 40% of the month 298 $42.912 $63.24 -47% 온디맨드 인스턴스 대비 26% 비용 감소
- 38. 4.10% 24.50% 0.00% 8.22% 24.77% 0.00% 10.00% 20.00% 30.00% 94 400 410 420 430 440 450 460 470 480 490 500 510 520 530 540 550 560 570 580 590 600 610 620 630 755 Saving RI Wasting 활용률보다 절감 효과 우선 0 200 400 600 800 1000 1200 Usage Hours Current RI Best RI 0% 94 570
- 39. 시간 단위로 최적 수량 산출 HOURS OF MONTH RUNNING INSTANCES 1 4 2 6 3 0 4 5 5 7 6 8 7 5 8 3 9 12 10 3 RUNNING INSTANCE COUNT FREQUENCY OF OCCURRENCE FREQUENCEY % 0 1 10.00% 1 9 90.00% 2 9 90.00% 3 9 90.00% 4 7 70.00% 5 6 60.00% 6 5 50.00% 7 4 40.00% 8 2 20.00% 9 1 10.00% 10 1 10.00% 11 1 10.00% 12 1 10.00%
- 40. 월단위의 반복적인 구매 ON-DEMAND ANNUALLY QUARTERLY MONTHLY Total Cost $309,053 $205,209 $134,900 $95,854 Discounted Hours 0% 48% 92% 100% Savings 0% 34% 63% 69% Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec Usage Annually Quarterly Monthly
- 41. Cost Explorer를 통한 낭비 최소화
- 42. 사례: RI 구매 현재 RI 현재 On demand 추가 RI
- 43. 지금까지 요약하면
- 44. Frameworks ü 자원 생성 권한 및 Tag 관리 ü 지속적인 비용 관찰 ü Peak 기반 설계에서 탄력적 설계 ü 유휴 자원 및 사용하지 않는 자원 확인 ü 비용을 고려한 설계 ü 기술 업데이트를 확인 ü RI 구매
- 45. 감사합니다