[Games on AWS 2019] AWS 사용자를 위한 만랩 달성 트랙 | AWS 최적화 사용을 위해 운영자가 아닌 개발자들이 해야 할 일 - 이정훈 AWS 솔루션즈 아키텍트

© 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.
AWS 최적화 사용을 위해
운영자가 아닌 개발자들이 해야 할 일
이정훈 솔루션즈 아키텍트, AWS

오늘 세션에서는 …
AWS에서 잘 구성된 아키텍처란 (AWS Well-Architected)
개발자가 도와주어야 완성되는 AWS 상의 Well-Architected
• 운영 우수성
• 보안
• 신뢰성
• 성능 효율성
• 비용 최적화

AWS에서 잘 구성된 아키텍처란
(AWS Well-Architected)

새로운(?) 도구 출시 (2018년 11월)

AWS 콘솔에서 접근 가능
서비스 가능 [지역]을 선택하고 서비스에서 [AWS Well-Architected Tool] 을 선택 합니다.
AWS Well-Architected Tool은 현재 미국 동부(버지니아 북부), 미국 동부(오하이오), 미국 서부(오레곤), EU(아일랜드), AP(시드니), EU(런던), AP(도쿄) 지역에서 사용 가능 합니다.

AWS Well-Architected Tool
• 새로운 도구 출시
모든 AWS 고객이 Well-Architected 검토를 이용 할 수 있도록 새로운 서비스가 발표 되었습니다.
• 셀프-서비스 및 학습 도구
아키텍트와 담당 관리자가 AWS 솔루션스 아키텍트의 도움 없이 언제든지 AWS 워크로드를 검토 할 수
있도록 설계된 셀프 서비스 도구 입니다.
• Pillar(요소) 별 모범 사례 비교
검토하려는 워크로드에 대해 5개의 Well-Architected 요소별로 모범 사례와 비교하고 질문을 통한
워크로드를 검토 할 수 있습니다.
• 계획 수립
AWS를 더 잘 사용하기 위한 계획 수립이 가능 하며, 검토 프로세스에는 최신 AWS 모범 사례를 중심으로 한
다양한 콘텐츠가 포함되어 있습니다.

왜 갑자기 Well-Architected
• AWS는 On-premises의 경험에 기반하여 사용하기 쉬워 AWS의
장점을 최대한 살린 아키텍처 구현이 안 되는 경우가 많음
• 다년간 다양한 고객과 수천가지의 아키텍처를 도운 AWS
솔루션즈 아키텍트의 경험을 활용할 수 있도록 프레임워크를
만듦
• 고객들이 AWS 상에서 어플리케이션의 아키텍트 구성과 운영
시, AWS의 모범 사례와 전략을 제공함
• 고객들이 On-premises와 다른 AWS의 차이점을 이해하고 이에
따른 아키텍처 구성을 결정할 수 있도록 지원하고자 함

AWS
Well-Architected
프레임워크를
사용하여…
AWS 모범 사례 학습
더 빠른 빌드와 배포
위험을 감소하거나
최소화
정보에 근거한 선택과 결정

On-premises와 다른 AWS의 특성
• 필요 서버 자원에 대한 추측과 계획을 할 필요가 없는 운영비용 관점
• 실제 사용자 규모 또는 그 이상의 규모에 대한 테스트 가능
• 모든 것을 자동화 할 수 있음 (테스트 비용 감소, 더 많은 실험)
• 지속적인 아키텍처 개선을 할 수 있음
- 계속되는 기능 업데이트
- 데이터 기반
- 다양한 이벤트를 실제 발생 시키는 Gameday
• 다양한 관리형 서비스, 서버리스 서비스 선택 가능
새로운 플랫폼, 커다란 클라우드 운영 체제 (Research, Research!!!!!)

AWS에서 Well-Architected란
보안 신뢰성 성능 효율성 비용 최적화운영 우수성
앞서 언급된 On-premises와 다른 AWS의 특성을 고려하여
아래 5가지 목적을 달성 하는 것

Well-Architected는 인프라팀에서만?
• 다년간 게임 고객의 인프라팀과 협업으로 AWS의 장점을 살릴
수 있도록 지원해 왔으나 인프라팀의 노력만으로는 AWS의
장점을 모두 다 누릴 수 없음을 인식
• AWS에서 최고 수준의 Well-architected가 되기 위해 개발자의
도움이 필요한 부분이 있음
-개발자들이 알아야 할 것
-개발자들이 주의해야 할 것
-개발자들이 사용해야 할 서비스
-개발자들이 바꾸어 주어야 할 것

개발자가 도와주어야 완성되는
- 운영 우수성

개발자들이 도와주는 운영 우수성
1. 모든 것은 코드로
 CloudFormation 또는 CDK
2. 클라우드 기반의 어플리케이션 로깅
 CloudWatch Logs & Kinesis
3. 쉽고 빠른 게임 성능 모니터링
 AWS X-Ray

1. 모든 것은 코드로…
• 시간이 소모되는 반복적인 작업 자동화
-다양한 개발/테스트 환경 구축
• 게임 바이너리의 버전 관리 뿐만 아니라 인프라 자체도 코드
버전으로 관리 가능
• DevOps를 가속화하는 프랙티스
• 더 자세한 내용은 아래 세션 참조
-AWS 사용자를 위한 만랩 달성 트랙
-16:10 - 17:00 코드 기반으로 인프라 운영하기
-발표자 : 박성훈 팀장, 네오위즈 | 김필중 솔루션즈 아키텍트, AWS

2. 클라우드 기반 어플리케이션 로깅
• 서버(인스턴스)는 더 이상 여러분의 게임과 수명을 같이 하지 않습니다.
로그는 별도의 저장소에 관리해야 합니다.
• CloudWatch Logs
- AWS SDK를 사용하여 로컬파일에 로그를 남기듯이 CloudWatch에 로그를 남길 수
있습니다.
- 로그를 지표화하여 알람을 받을 수 있습니다.
- CloudWatch Logs Insights를 이용하면 대용량의 어플리케이션 로그 분석이 쉽습니다.
• Kinesis
- 어플리케이션 동작 상태가 아닌 게임 내의 대규로 로그는 비용 효율적인 Kinesis
서비스를 사용합니다.
- Kinesis Firehose는 S3에 바로 여러분의 게임 로그를 적재하고 EMR과 Athena로 즉시
게임 로그 분석을 수행할 수 있습니다.

3. 쉽고 빠른 게임 성능 모니터링
• 사례: 개별 기능 테스트에서 문제가 없지만, 대규모 성능 테스트
또는 실제 프로덕션에서 극히 일부 요청에서 에러 발생하는
경우, 원인 분석에 인프라팀 및 개발팀이 많은 시간을 소비함
• 게임의 상태 모니터링은 인프라팀에서 수행이 가능하나 게임
응답 지연 등의 성능 모니터링은 개발팀이 지원해 주어야
합니다.
• AWS X-Ray 서비스
- 어플리케이션 변경 없이 X-Ray SDK 포함만으로 AWS 서비스 호출, HTTP(S) 외부
호출, DB 호출의 지연 시간을 트랜잭션 단위로 End-to-end 모니터링 가능
- 추가로 주석(Annotation) 코드 삽입 시, 더 정교한 어플리케이션 성능 모니터링 가능

AWS X-Ray를 통해 게임 내의 서비스 응답 상태 및 응답 성능 모니터링

AWS X-Ray를 통해 서버와 DB통신 지연 원인 확인

위와 같은 방식으로 사용자별/게임별/요청별 등의 다양한 성능 분석이 가능
AWS X-Ray 주석 추가로 더 많은 성능 정보 획득
기능별
주석 코드
삽입
모듈별
지연 시간
개발자가 아래의 주석 코드를 기존 코드에 삽입 필요
AWSXRayRecorder.Instance.SafeAddAnnotation(“EntityType”, serviceName);
모듈별
사용 비율
오류 비율

- 보안

개발자들이 도와주는 보안
1. 안전한 서비스 접근 및 자격증명 외부 노출 방지
 AWS IAM 역할 및 AWS SDK
2. 안전한 데이터 암호화
 AWS Key Management Service (KMS)

• AWS IAM(Identity & Access Management) 사용
-서비스 용도의 사용자를 별도 생성
-생성된 서비스용도 사용자의 액세스키(Access Key ID + Secret Access
Key) 생성
-해당 액세스키로 게임 서비스가 AWS 서비스에 접근
• IAM 사용자 vs. IAM 역할
-공통 사항 – 권한정책을 가질 수 있음
-차이점 – 패스워드/액세스키와 같은 자격 증명이 없음
• AWS SDK에서 액세스키 사용 우선 순위 (간략 버전)
-직접 코드에서 사용  환경 변수  설정 파일  인스턴스 프로파일

• 자격 증명 정보를 소스 코드에
포함하지 말 것
• IAM 역할을 사용하여 Amazon EC2,
Amazon EC2 Containers, 및 AWS
Lambda 함수에 권한 제공
• 다른 AWS 자원 접근 권한을
상세하게 정의

2. 안전한 데이터 암호화
• 암호화의 핵심은 키관리
• AWS KMS(Key Management
Service)를 이용하여 대부분의
인프라 수준 암호화 지원
• 게임서버나 플랫폼에서
어플리케이션 수준에서 암호하고자
할 때, AWS KMS의 CMK(Customer
Master Key)를 사용하여 봉투
암호화 방법을 사용
-GenerateDataKey 및 Decrypt API 사용

- 신뢰성

개발자들이 도와주는 신뢰성
1. 다양한 이벤트에 대한 준비
 Retry, Retry, & Retry
2. 메세징 서비스의 활용 (Loose coupling)
 Amazon Simple Queue Service (SQS)
3. CI/CD를 이용한 자동화 배포
 AWS Code*

© 2017, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
“Everything fails, all the time.”
-- Werner Vogels, CTO Amazon.com

Failure management
• Netflix OSS Simian Army는 결함 감내(fault tolerance) 시스템 테스트
도구의 예입니다.
- Chaos Monkey - 인스턴스 또는 컨테이너에 인위적 실패 발생
- Chaos Kong - AWS 리전의 실패를 시뮬레이션
• 테스트, 테스트, 그리고 테스트 …
“구성 요소에 문제 발생하면 어떻하지가
아니라 문제 발생 시에 어떻게 되느냐로”
(Not what happens IF it fails, but what happens WHEN it fails.)
—Nora Jones, Author, and Sr. Chaos Engineer at Netflix

실패를 예상한 설계는 실패를 없앨 수 있다
(Design for failure and nothing fails)
• 모든 단위 요소는 실패할
수 있습니다. (Compute,
Storage, Network 등)
• 클라우드와 확율
• 인프라의 자동 복구에
맞추어 어플리케이션도
자동 복구를 지원해야
합니다.
• 서비스 완전 중단 보다는
저하된 상태의 운영 고려

ELB
IP 1
Amazon
Route 53
ELB
IP 2
연결 요청 실패
재시도(Retry)의 모범 사례

ELB
IP 1
Amazon
Route 53
ELB
IP 2

ELB
IP 1
Amazon
Route 53
ELB
IP 2응답
재요청

“만약 클라우드 네이티브 또는 대규모,
분산 어플리케이션에 메세징 요소가
없다면 그건 아마 버그일 것이다.”
(If your application is cloud-native, or large-scale, or distributed, and
doesn’t include a messaging component, that’s probably a bug)
- Tim Bray

2017 Gaming on AWS – Building PUBG with Microservice
https://m.blog.naver.com/PostView.nhn?blogId=njh0602&logNo=221125203416&proxyReferer=https%3A%2F%2Fwww.google.com%2F

• WHY - 특정 기간 변경 불가 (Christmas Change
Freeze)???
• 어쨌든 사람에 의한 오류는 줄여 보자
-자동화는 효과가 있으며
-자동화는 신뢰가 더하며
-자동화는 더 많은 업무를 가능하게 합니다

Source Build Test Deploy Monitor
AWS CodeBuild +
Third Party
AWS Code Services
AWS CodeCommit AWS CodeBuild AWS CodeDeploy
AWS CodePipeline
AWS
CodeStar
AWS X-Ray
Amazon
CloudWatch

- 성능 효율성

개발자들이 도와주는 성능 효율성
1. Scale up, down에서 Scale in, out 아키텍처로
 Autoscaling
2. 목적에 맞는 관리형 또는 서버리스 서비스 사용
 AWS 데이터베이스 선택 사항
 AWS 스토리지 선택 사항
 AWS 서버리스 선택 사항

1. Scale up, down에서 Scale in, out 아키텍처로
• 비용적인 측면
-하나의 서버를 100시간 동안 실행하는 비용과 100개의 서버를
한시간동안 실행하는 비용은 동일하다
• 유연한 스케일링 가능 (1.1배 만큼 더 리소스가 필요할 때?)
• 인스턴스 이벤트 발생 시에 서비스 영향도가 작아진다.
• 하드웨어의 한계도 있지만, 결국 소프트웨어도 한계가 있다

2-1. 목적에 맞는 데이터베이스 서비스 사용
Relational Key-value Document In-memory Graph Time-series Ledger
DynamoDB NeptuneAmazon RDS
Aurora CommercialCommunity
Timestream QLDBElastiCache
Redis Memcached
DocumentDB

Amazon FSx
for Lustre
2-2. 목적에 맞는 스토리지 서비스 사용
오브젝트 기반
스토리지 옵션
S3 Standard
S3 Glacier Deep Archive
S3 Glacier
S3 Intelligent-Tiering
S3 One Zone-IA
S3 Standard-IA
다양한 블록 기반
스토리지 옵션
Provisioned IOPS SSD
Cold HDD
Throughput-Optimized HDD
파일 기반 스토리지
EFS Standard
EFS Infrequent Access
Amazon
EFS
AWS Storage
Gateway Family
Amazon S3
Amazon FSx
for Windows
File ServerAmazon EBS
Amazon EC2
Backup
AWS Backup

2-3. 목적에 맞는 서버리스 서비스 사용
인프라 배포 및
관리 불필요 자동 스케일링
사용한만큼 지불 고가용성 및 보안
서버리스 서비스의 장점

카카오 개발자 컨퍼런스 – if (kakao) dev 2019
클라우드 환경에서의 Serverless service 개발
https://if.kakao.com/2019/program

On-Premises Cloud
Less More
Compute Virtual Machine
EC2 Elastic Beanstalk AWS LambdaFargate
Databases MySQL MySQL on EC2
RDS MySQL RDS Aurora Aurora Serverless DynamoDB
Storage Storage
S3
Messaging ESBs
Amazon MQ Kinesis SQS / SNS
Analytics
Hadoop Hadoop on EC2 EMR Elasticsearch Service Athena

- 비용 최적화

개발자들이 도와주는 비용 최적화
1. 사용자 임팩트 없이 자유자재로 Autoscaling을…
 Stateful에서 Stateless로
2. 요청 개수 기반의 서비스 비용 절감을 위해
 Chatty에서 Bulky 요청으로
3. 요청 데이터 크기 기반의 서비스 비용 절감을 위해
 비용을 고려한 데이터 스키마 구현

비용의 공유 책임(Shared Responsibility)
• 고객의 노력
-적절한 서비스 크기 사용 (Right sizing)
-사용하지 않는 시간대에 서비스 중지 (Scheduling)
-RI 또는 Spot의 활용
-최적의 아키텍처 (Right architecting)
• AWS의 노력
-클라우드 인프라 최적화로 서비스 비용 단가 절감
-50회 이상의 자발적인 서비스 단가 인하

1. 사용자 임팩트 없이 자유자재로 Autoscaling을…
• Stateless 아키텍처
-Auto Scaling이 자유롭기 위해서 Compute과 Storage를 분리
-Scale in/out 이벤트에도 사용자/서비스 임팩트 제거
-State는 외부 저장소 사용 (DynamoDB, ElastiCache, RDBMS,
DocumentDB, S3 등)
• Stateful인 경우, Draining 설정 및 Life-hook 기능 사용
• 필요한 경우, Application에서 Scale 판단에 필요한 지표 생성
• Ex. Game server가 1,000명만 받아들이는 경우, Game server에서 현재
접속된 Game 사용자 수를 지표로 남기기
• ELB를 사용하지 않는 워크로드도 사용 가능

© 2017, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
Cost saving simulation by better architected
100대의 c5.xlarge
Linux 사용 (OD: $0.192/hr, Spot: $0.0599/hr)
Stateless 아키텍처 구현 시, Auto Scaling으로
게임 사용자 영향 없이 약 79% 비용 절감 예상
(일년 기준 약 $133,356)
0
10
20
30
40
50
60
70
80
90
100
00:00
01:00
02:00
03:00
04:00
05:00
06:00
07:00
08:00
09:00
10:00
11:00
12:00
13:00
14:00
15:00
16:00
17:00
18:00
19:00
20:00
21:00
22:00
23:00
하루의 부하 분포
Instance 기준 개수 실제 부하에 의한 필요 개수
0
2
4
6
8
10
12
14
16
18
20
00:00
01:00
02:00
03:00
04:00
05:00
06:00
07:00
08:00
09:00
10:00
11:00
12:00
13:00
14:00
15:00
16:00
17:00
18:00
19:00
20:00
21:00
22:00
23:00
시간당 인스턴스 비용 비교(c5.xlarge기준)
No autoscaling Autoscaling(stateful) Autoscaling(stateless)
0
10
20
30
40
50
60
70
80
90
100
00:00
01:00
02:00
03:00
04:00
05:00
06:00
07:00
08:00
09:00
10:00
11:00
12:00
13:00
14:00
15:00
16:00
17:00
18:00
19:00
20:00
21:00
22:00
23:00
하루의 부하 분포
Instance 기준 개수 실제 부하에 의한 필요 개수
0
2
4
6
8
10
12
14
16
18
20
00:00
01:00
02:00
03:00
04:00
05:00
06:00
07:00
08:00
09:00
10:00
11:00
12:00
13:00
14:00
15:00
16:00
17:00
18:00
19:00
20:00
21:00
22:00
23:00
시간당 인스턴스 비용 비교(c5.xlarge기준)
No autoscaling Autoscaling(stateful) Autoscaling(stateless)

Recipient Date Sender Subject MsgId
David 2014-10-02 Bob Hi!… afed
David 2014-10-03 Alice RE: The… 3kf8
Alice 2014-09-28 Bob FW: Ok… 9d2b
Alice 2014-10-01 Carol Hi!... ct7r
Cost saving by mechanical sympathy
Inbox table Messages table
MsgId Body
9d2b …
3kf8 …
ct7r …
afed …
David
1. 분리형 테이블 구조 디자인: 1 RCU
2. 혼합형 테이블 구조 디자인: 1600 RCU
(50 items at 256 KB)
(50 items at 128 bytes)
DynamoDB에서 읽기는 4KB 당 0.5개의 읽기 용량을 사용합니다.
크기가 큰 속성(attribute)값은 다른 테이블로 분리하고 해당 테이블을 인덱스로
처리하면 읽기 성능과 읽기 비용을 절감할 수 있습니다.

정리하며…
• Blah blah blah
• 개발자들이여 새로운 세상에 적응하기 위해 공부를…

여러분의 피드백을 기다립니다!
Games on AWS 2019 QR코드를 통해
강연평가 및 설문조사에 참여해 주시면 최신
랩탑 배낭을 드립니다!
여러분의 소중한 의견 부탁 드립니다.
#GamesOnAWS 해시태그와 함께
소셜미디어에 여러분의 행사 소감을 올려주세요.

[Games on AWS 2019] AWS 사용자를 위한 만랩 달성 트랙 | AWS 최적화 사용을 위해 운영자가 아닌 개발자들이 해야 할 일 - 이정훈 AWS 솔루션즈 아키텍트

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to [Games on AWS 2019] AWS 사용자를 위한 만랩 달성 트랙 | AWS 최적화 사용을 위해 운영자가 아닌 개발자들이 해야 할 일 - 이정훈 AWS 솔루션즈 아키텍트

Similar to [Games on AWS 2019] AWS 사용자를 위한 만랩 달성 트랙 | AWS 최적화 사용을 위해 운영자가 아닌 개발자들이 해야 할 일 - 이정훈 AWS 솔루션즈 아키텍트 (20)

More from Amazon Web Services Korea

More from Amazon Web Services Korea (20)

Recently uploaded

Recently uploaded (6)

[Games on AWS 2019] AWS 사용자를 위한 만랩 달성 트랙 | AWS 최적화 사용을 위해 운영자가 아닌 개발자들이 해야 할 일 - 이정훈 AWS 솔루션즈 아키텍트