비용 관점에서 AWS 클라우드 아키텍처 디자인하기::류한진::AWS Summit Seoul 2018

© 2018, Amazon Web Services, Inc. or Its Affiliates. All rights reserved.
Ryu Hanjin
Eland
비용 관점에서 AWS 클라우드
아키텍처 디자인하기

자기 소개
▪ 류한진
Cloud Architect, Eland
대표 서비스: Elandmall, MyNB 등
▪ 한국AWS사용자그룹
데이터사이언스모임 리더
아키텍처, 서버리스, 컨테이너, 구로/신촌 모임
▪ 좋아하는 AWS 서비스
Eland : http://eland.co.kr/
AWSKRUG : https://www.facebook.com/groups/awskrug/
Elastic Load
Balancing
Amazon
Athena
Amazon
S3
Amazon
CloudFront
Amazon
RDS

Agenda & 유의점
▪ 어떻게 하면 비용 효율적으로 서비스를 만들 수 있는가?
• 주요 AWS서비스의 비용구조
• 비용 효율적으로 사용하는 아키텍처와 팁
▪ 단, 적용할 수 있는 부분부터 적용하자!
• 가장 중요한 건 제한된 시간 내에 비즈니스 목표를 달성하는 서비스를 만드는 것
• 익숙한 기술 스택 하에 가능한 영역부터 점진적으로 개선이 중요
Creating a Culture of Cost Transparency and Accountability

시작하기에 앞서

처음 AWS를 접한다면? – 개인 사용자
▪ Free tier 맛보기 서비스
가입 후 12개월 무료 서비스 : t2.micro(1 vCPU, 1GB RAM)급 EC2, RDS(DB) 1대
무기한 무료 서비스 : DynamoDB 25GB, CloudWatch 등
▪ AWS 세미나에 적극 참여
무료로 교육을 듣는 건 기본
실습용 Credit 획득
▪ Free tier + Credit 으로 만들어 보자
무료로 제공하는 범위 내에서 서비스 테스트
워드프레스 같은 간단한 개인용도 서비스는 무료로 사용 가능

Cost Optimization Pillar AWS Well-Architected Framework
▪비용 효율적인 자원 사용
• Appropriate provisioning
• Right sizing
• Purchasing options
• Geographic selection
• Managed services
▪ 지출 인지
• Stakeholders
• Visibility and controls
• Cost attribution
• Tagging
• Entity lifecycle tracking
▪공급과 수요 맞추기
• Demand-based
• Buffer-based
• Time-based
▪지속적인 최적화
• Measure, monitor, and improve
• Staying ever green
AWS Cost Optimization Pillar : https://d1.awsstatic.com/whitepapers/architecture/AWS-Cost-Optimization-Pillar.pdf

AWS의 비용구조

AWS의 비용구조
Allocating Size Traffic
Amazon
EC2
AWS
Lambda
Amazon
S3
Amazon
RDS
Amazon
DynamoDB
Amazon
ElastiCache
Free
Amazon ECS
Amazon EBS
Amazon
Redshift
Amazon
EMR
Amazon
SNS
Amazon
SQS
Amazon
MQ
Amazon
CloudFront
그리고 AWS 밖으로 나가는 데이터 용량
Amazon
CloudWatch
Systems Manager
AWS
CloudFormation
IAM
Amazon
Athena
Amazon
Route 53
Amazon
Kinesis
Amazon API
Gateway
AWS IoT Amazon
Lex

AWS의 비용최적화
▪ 비즈니스/성능 목표 달성하의 최소화
• Allocating Size
• Traffic 과 AWS 밖으로 나가는 데이터 용량
▪ 그 결과, 추구하는 비용 최적화 아키텍처
• 확장, 축소가 유연한 아키텍처
• Caching을 최대한 활용하는 아키텍처

비용이 주로 발생하는 주요 서비스
AWS
Lambda
Amazon
S3
Amazon
DynamoDB
Amazon
ElastiCache
Amazon ECS
Amazon EBS
Amazon
Redshift
Amazon
EMR
Amazon
SNS
Amazon
SQS
Amazon
MQ
Amazon
CloudWatch
Systems Manager
AWS
CloudFormation
IAM
Amazon
Athena
Amazon
Route 53
Amazon
Kinesis
Amazon API
Gateway
AWS IoT Amazon
Lex
Amazon
EC2
Amazon
RDS
Amazon
CloudFront
Allocating Size Traffic Free
그리고 AWS 밖으로 나가는 데이터 용량

예시 - 웹서비스 아키텍처

EC2 비용 최적화

EC2 비용 최적화
▪ Service statelessness
▪ 서비스 사용량에 필요한 만큼
적절한 프로비저닝
▪ 효율을 고려하여
맞는 서비스별 인스턴스 선택
▪ 구입옵션을 반드시 고려

▪ 실제 서비스 사용량에 맞추어 적정한 서비스 용량을 제공
▪ Service Statelessness가 달성된 서비스는
ELB와 Auto Scaling를 이용하여 EC2의 확장/축소가 가능
적절한 프로비저닝
▪ 예측가능한 사용량 변화에
대한 프로비저닝
▪ 마케팅 이벤트에 따른 사용량 변화 예상
: 수동으로 프로비저닝
▪ 시간대에 따른 사용량 변화 예상
: AutoScaling Scheduled Action

예측불가능한 사용량 변화에 대한 프로비저닝
▪ Auto Scaling이 트리거될
지표의 선택이 중요
▪ CloudWatch alarm으로
만들면 Auto Scaling 트리거로
사용가능
▪ 간헐적인 대량 트래픽이라면
Serverless를 검토
instances
CloudWatch
alarm
Auto Scaling
2. Trigger
1.Metric (1min)
New
instance
3. Scale out (3min)4. health check (1min)
5. inservice

Auto Scaling Lifecycle hook
▪ 인스턴스 생성 후 인서비스 전,
혹은 인스턴스 제거 전에 사용자
지정작업 가능
▪ User Data 등과 다르게
모든 작업이 완료된 걸 확인 후
인서비스 가능
https://docs.aws.amazon.com/ko_kr/autoscaling/ec2/userguide/AutoScalingGroupLifecycle.html

맞는 서비스별 인스턴스 선택
• EC2 유형별 최적화 인스턴스 타입
범용 T2, M5, 컴퓨팅 C5, 메모리 R4, 스토리지 I3, D2
• Load Test를 통해 인스턴스 타입/사이즈별 TPS를 측정, 검토
• 자원 사용량을 바탕으로 주기적 용량 조정
• 같은 인스턴스 타입, Linux 권장

Open Source를 적극 이용 (EC2)
▪ Open Source OS는 EC2의 비용 유연화를 제공
초 당 과금은 라이선스 비용이 없는 OS(AMI)를 사용한 인스턴스만 제공
Reserved Instance의 Flexibility 도 마찬가지
▪ 참고로 Windows서버는 Linux서버의 1.8 ~ 2.5배 가격
구매 옵션 Instance Type
Linux 인스턴스 대비
Windows 인스턴스 비용
On-Demand
m5.large 178%
c5.xlarge 196%
Reserved
(1year, Standard, all upfront)
m5.large 213%
c5.xlarge 251%

Amazon Linux 2
▪ 최근 LTS Candidate2 버전 공개.
공식 LTS 빌드 발표 후 5년간 장기 지원 제공 예정
▪ RHEL 7 / CentOS 7과 유사
▪ On-Premise 환경에서 사용 가능
Docker container image와 VMware, Hyper-V, VirtualBox의 virtual machine images 제공.
▪ AWS Integration
* Amazon Linux는 2017.09 가 마지막 릴리즈. 2년간 보안 업데이트 제공
* 현재 Amazon Linux 2로의 마이그레이션을 AWS는 권장 중

구매옵션을 반드시 고려하여
Reserved, Spot 인스턴스 적극 사용

Reserved Instance
▪ 상시 사용되는 자원은 Reserved Instance 구매
Linux/Unix의 같은 인스턴스 타입으로 되도록 통일 (범용 t2, m5 계열)
하지만 워크로드에 맞게 선택하는게 가장 중요 (메모리 r4, 컴퓨팅 c5 등)
하루 중 사용시간에 따라 RI구매와
인스턴스 스케쥴링 중 어느 쪽이 더
비용 효율적인지 고려하여 적용

Spot Instance
▪ 중단 가능한 작업은 Spot Instance 사용
배치 작업, 테스트에 적극 이용
Spot Fleet(분산입찰), Spot block (6시간까지 확정 이용)

Spot Instance – 웹서비스 아키텍처
▪ Auto Scaling Group을
이중으로 사용
▪ 온디맨드 인스턴스와
스팟 인스턴스로
서비스 용량을 유지
https://aws.amazon.com/ko/blogs/compute/an-ec2-spot-architecture-for-web-applications/
온디맨드 AutoScaling Group의 Scale-out 민감도 < 스팟 AutoScaling Group의 Scale-out 민감도

Spot Instance - 자동화
CloudWatch events 와 인스턴스 메타데이터에서 Spot Instance의 Interruption 확인가능
이벤트 트리거로 사용하여 자동화 가능

Spot Instance - 절전기능
▪ 중단된 Spot Instance를 최대 절전 모드로 전환 가능
다시 시작하면 EBS 루트 디바이스는 RAM 내용을 포함하여 이전 상태에서 복원
▪ 지원 인스턴스
메모리 용량이 100GB 미만인 C3, C4, C5, M4, M5, R3, R4 인스턴스
Amazon Linux, Ubuntu, Windows Server
▪ EC2 Hibernation Agent 이용

RDS 비용 최적화

RDS 비용 최적화
▪ EC2는 Auto Scaling을 이용하여
쉽게 프로비저닝 가능
▪ 하지만 Relational Database는
Online Master노드 변경이 불가능
▪ 서비스 사용량의 성장에 따라
RDS는 점점 크기가 커지고 유연화
하기 어려움

Open Source를 적극 이용 (RDS)
▪ 유연화 되지않은 거대한 상용라이센스 DB는 큰 부담
▪ AWS의 RDS에서는 상용라이센스 DB의 기능 제약 존재
Oracle DB는 RAC 기능을 제공하지 않음
SQL Server는 Always on 기능을 제공하지 않음 (EC2 구성 시 가능)
구매 옵션 Instance Type
BYOL RDS 대비
Oracle RDS 비용
On-Demand
db.m4.large 210%
db.r4.4xlarge 198%
Reserved
(1year, Standard, all upfront)
db.m4.large 234%
db.r4.4xlarge 192%

Amazon Aurora RDS
▪ MySQL 및 PostgreSQL 호환 관계형 데이터베이스
• MySQL 5.7.12 호환 버전
• PostgreSQL 9.6.6 호환 버젼 (서울리전 미출시)
▪ 스토리지 계층과 DB엔진간 성능 개선으로 기존 RDS 대비 2~5배 성능 증가
▪ read replica를 이용하여
read 처리량 증대 가능
https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/Aurora.Overview.html

Amazon Aurora RDS (Preview)
▪ Amazon Aurora Multi-master (Preview)
: 다수의 Master-node로 read/write 가능
▪ Amazon Aurora Serverless (Preview)
: 드물게 사용하는 어플리케이션, 예측할 수 없는 워크로드 처리, 개발 테스트 DB 등
https://aws.amazon.com/ko/blogs/korea/in-the-works-amazon-aurora-serverless

캐싱 적용
▪ Caching을 이용하여 유연하기
어려운 DB에게 부담 감소
• DB cache
• Web Cache
• CDN Cache
• API Cache
https://aws.amazon.com/ko/caching/
AWS re:Invent 2017: Cache Me If You Can

캐싱을 위한 AWS 서비스
▪ Amazon ElastiCache
Managed Redis, Memcached 서비스
인메모리 기반 캐싱 티어로 사용
▪ Amazon DAX (도쿄리전 출시)
DynamoDB in-memory cache
▪ Amazon CloudFront
정적 컨텐츠 캐싱
필요할 경우 캐싱 티어로 다양하게 활용 가능
▪ Amazon API Gateway
API Caching 가능
Amazon DynamoDB
Accelerator
Amazon
ElastiCache
Amazon
CloudFront
Amazon API
Gateway
https://docs.aws.amazon.com/ko_kr/AmazonCloudFront/latest/DeveloperGuide/Expiration.html

Serverless로
확장성의 한계를 극복?

Serverless 도입
▪ 예측 불가능한 사용량 급증은
EC2로 대응하기 어려움
EC2로는 인서비스까지 5분 이상 소요
▪ Serverless는 빠르게 대응 가능
API Gateway와 Lambda를 활용하여
스파이크성 트래픽에 대응
미리 프로비저닝 할 필요 없음

Serverless 검토
* EC2의 어플리케이션은
Lambda로 바꾸기 어렵지만,
Lambda로 만든 어플리케이션은
EC2에서 실행하기 쉽다
https://d1.awsstatic.com/whitepapers/serverless-architectures-with-aws-lambda.pdf
▪ AWS Lambda 고려사항
• Cold Start, Concurrency, Reuse
• Function Memory 크기 (CPU Power) 선택
• 실행시간 제약으로 작업 분리 필요

Summery - AWS의 비용최적화
▪ 비용 최적화 아키텍처
• 확장, 축소가 유연한 아키텍처
• Caching을 최대한 활용하는 아키텍처
▪ 비용 최적화
• EC2, RDS 최적화
• Caching, Serverless 검토

비용 관점에서 AWS 클라우드 아키텍처 디자인하기::류한진::AWS Summit Seoul 2018

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a 비용 관점에서 AWS 클라우드 아키텍처 디자인하기::류한진::AWS Summit Seoul 2018

Semelhante a 비용 관점에서 AWS 클라우드 아키텍처 디자인하기::류한진::AWS Summit Seoul 2018 (20)

Mais de Amazon Web Services Korea

Mais de Amazon Web Services Korea (20)

Último

Último (7)

비용 관점에서 AWS 클라우드 아키텍처 디자인하기::류한진::AWS Summit Seoul 2018