SlideShare une entreprise Scribd logo
1  sur  74
Télécharger pour lire hors ligne
© 2016, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
박선용 솔루션즈 아키텍트
2016/05/17
AWS 상에서 게임서비스 최적화 방안
오늘의 내용
1. 성능(Performance) 개론
2. 단일 리전 글로벌 게임 서비스
3. AWS상에서 시스템 최적화
4. 정리
1. 성능(Performance) 개론
• 좋은 성능의 시스템을 설계하려면?
• 2개의 중요 문제가 존재
성능의 문제
1. 성능에 대한 정의
2. 바른 성능 측정
• 당신의 관점에 따라 성능이
무엇을 의미하는지가
달라진다:
– 응답시간(Response time)
– 출력량(Throughput)
– 일관성(Consistency)
성능(Performance) 정의: 관점의 문제
Application
System libraries
System calls
Kernel
Devices
Workload
성능 요소(Performance Factors)
리소스 성능 요소 주요 지표
CPU 소켓(Sockets), 코어 갯수(number of
cores), clock frequency, bursting
capability
CPU utilization, run queue length
메모리Memory 메모리 용량(Memory capacity) Free memory, anonymous paging,
thread swapping
네트워크
인터페이스
Max bandwidth, packet rate Receive throughput, transmit throughput
over max bandwidth
디스크 IOPS(Input / output operations per
second), 출력량(throughput)
Wait queue length, device utilization,
device errors
리소스 활용률(Utilization)
• For given performance, how efficiently are resources being used
• Something at 100% utilization can’t accept any more work
• Low utilization can indicate more resource is being purchased
than needed
• 병목 == 시스템에서 최대 활용률을 나타내는 컴포넌트
성능 게임
성능 게임 : 같은 수치를 가지고 더 나은 성능치로 보이기 위한 기술적인 트릭
수십가지의 대표적인 기법들이 있다
Ratio 게임
시스템 워크로드 1 워크로드 2
A 10 20
B 20 10
측정값
시스템 워크로드 1 워크로드 2 평균값
A 10 20 15
B 20 10 15
평균값 비교
시스템 워크로드 1 워크로드 2 평균값
A 0.5 2 1.25
B 1 1 1
B 기준 처리량 비교
시스템 워크로드 1 워크로드 2 평균값
A 1 1 1
B 0.5 2 1.25
A 기준 처리량 비교
성능 측정
1. 관점의 선정 : 측정 단위(Metric)선정
- IOPS, 지연시간(ms), 출력량(MB/s), 활용도(%)
2. 대상의 선정 : 측정할 시스템의 올바른 준비
- 특정 병목(100% utilization) 으로 인한 왜곡이 없는 설정
3. 주체의 선정 : 적합한 워크로드의 선정
- 정확한 로드를 줄 수 있는 적합한 로드 제너레이터의 선정
- 충분한 로드가 가해질 수 있는 로드의 설계
측정의 일반적인 실수와 해결책
현명한 사람은 다른 사람의 실수로부터 배우고 어리석은 사람은 자신의 것으로부터 배운다 – H.G Well
1. 목표의 부재 or 편향된 목표
2. 비체계적인 접근
3. 부정확한 메트릭
4. 대표성 없는 워크로드
5. 잘못된 계산 기법
6. 부적합한 대상(시스템) 설정
7. 워크로드 생성기의 부적절한 선택
당부의 말씀
여기 나오는 모든 수치는 예시적인 것입니다.
퍼포먼스 측정은 모두 여러분이 직접 수행해야만 가치가 있습니다.
2. 단일 리전 글로벌 게임 서비스
FAQ
1. 한 지역에서 게임서버를 두고 전 세계 서비스를 할 수
있는가?
2. 대전(對戰) 게임을 여러 대륙간의 사용자끼리 하게 할 수
있는가?
3. 지역간 DB 상호 복제가 가능한가?
Global network 성능 관련 문제
지역별 평균 네트워크 지연
http://bit.ly/superdata-latency, See http://bit.ly/verizon-latency
N.America
41.7ms
Europe toAsia
137.9ms
Asia Pacific
97.9ms
Trans-Pacfic
103.8ms
Trans-Atlantic
79.6ms
LatinAmerica
133.2ms
Europe
11.6ms
Japan
16.8ms
추천 모범 사례 : 전 세계적인 매시형 구조로 서비스
하지 말고 지역별로 게임서버를 둘 것
###+ms
###+ms
##+ms
###+ms
질문 : 하나의 지역에서 글로벌 서비스는 불가?
네트워크 성능
주요 성능 관점
응답시간(Response time)
일관성(Consistency)
고려 사항
라우팅 패스
패킷 손실률 = 패킷 재전송
측정도구
ping
traceroute
mtr
iperf
scp
Latency의 중요성 - TCP 연결
Keep-Alive를 사용해야
SYN
SYN-ACK
ACK
GET /index.jsp
ACK
SYN-ACK
GET /index.jsp
2nd 요청
Region
SYN
360ms
360ms
90ms
성능 테스트
§ 비교 테스트
• 서울 (A 망사업자) à AWS China (베이징 리전의 EC2 인스턴스)
• AWS 서울 à AWS China (베이징 리전의 EC2 인스턴스)
§ 테스트 종류
1.Traceroute : 라우팅 경로 확인
2. MTR : 라우팅 경로의 일관성 확인
3. Ping : 지연과 지연의 범위 확인
4. 데이터 전송 : 전송속도, 패킷 로스로 인한 패킷 재전송 횟수 측정. 워크로드에
필요한 전송크기. 여기서는 100KB
§ 중국과의 통신 (일반)
중국내 경로에 따른 인터넷 안정성 및 Great Firewall의 간섭으로 불특정하게
트래픽이 영향을 받은 것으로 알려져 있음
Tracerout 비교
traceroute to 54.222.13x.xx (54.222.13x.xx), 128 hops max, 52 byte
packets
1 [AS56220] 192.168.0.1 (192.168.0.1) 5.307 ms 1.238 ms 0.968
ms
6 [AS3786] 1.213.28.145 (1.213.28.145) 2.242 ms
[AS3786] 1.213.28.49 (1.213.28.49) 2.174 ms 2.081 ms
7 [AS3786] 1.208.150.37 (1.208.150.37) 2.700 ms
[AS3786] 210.120.248.237 (210.120.248.237) 3.014 ms
[AS3786] 1.208.150.229 (1.208.150.229) 3.113 ms
8 [AS3786] 1.213.150.165 (1.213.150.165) 14.654 ms
[AS55831] 1.208.104.149 (1.208.104.149) 6.444 ms
[AS3786] 1.213.150.165 (1.213.150.165) 4.945 ms
10 [AS3786] 1.213.106.9 (1.213.106.9) 4.124 ms
[AS3786] 1.208.148.105 (1.208.148.105) 3.917 ms
[AS3786] 1.213.148.57 (1.213.148.57) 3.955 ms
13 [AS4134] 202.97.58.106 (202.97.58.106) 52.624 ms 51.554 ms
LG DACOM [AS3786] 211.40.6.110 (211.40.6.110) 50.114 ms
14 [AS4134] 202.97.58.117 (202.97.58.117) 50.871 ms 54.061 ms
51.665 ms
15 [AS4134] 202.97.53.93 (202.97.53.93) 53.085 ms
[AS4134] 202.97.58.117 (202.97.58.117) 52.425 ms
[AS4134] 202.97.53.93 (202.97.53.93) 56.021 ms
16 China Telecom Backbone [AS4134] 202.97.53.93 (202.97.53.93)
54.102 ms 51.934 ms *
17 China Networks Inter-Exchange [AS4847] bj141-130-
93.bjtelecom.net (219.141.130.93) 52.357 ms * *
A 망 à AWS China (예) traceroute to 54.222.13x.xx (54.222.13x.xx), 30 hops max, 60
byte packets
1 ec2-52-79-0-0.ap-northeast-2.compute.amazonaws.com
(52.79.0.0) [AS16509] 20.145 ms 20.289 ms 20.346 ms
2 Cox Communication Inc. 100.64.1.8 (100.64.1.8) [AS22773]
16.820 ms 100.64.2.8 (100.64.2.8) [AS22773] 20.275 ms
100.64.2.136 (100.64.2.136) [AS22773] 13.769 ms
3 100.64.3.135 (100.64.3.135) [AS22773] 13.877 ms
100.64.2.195 (100.64.2.195) [AS22773] 15.923 ms 100.64.3.3
(100.64.3.3) [AS22773] 15.944 ms14 otejbb205.int-
gw.kddi.ne.jp (203.181.99.69) [AS2516] 38.586 ms
otejbb206.int-gw.kddi.ne.jp (59.128.4.249) [AS2516] 38.112 ms
otejbb205.int-gw.kddi.ne.jp (59.128.4.101) [AS2516] 45.558 ms
15 tr-ote124.int-gw.kddi.ne.jp (106.187.6.198) [AS2516] 39.897
ms tr-ote124.int-gw.kddi.ne.jp (106.187.6.190) [AS2516] 39.156
ms tr-ote124.int-gw.kddi.ne.jp (106.187.6.194) [AS2516] 40.067
ms
16 203.181.102.42 (203.181.102.42) [AS2516] 151.869 ms *
152.305 ms
17 202.97.33.49 (202.97.33.49) [AS4134] 153.793 ms
202.97.35.237 (202.97.35.237) [AS4134] 152.355 ms 151.471
ms
18 * 202.97.33.125 (202.97.33.125) [AS4134] 153.458 ms
19 202.97.50.229 (202.97.50.229) [AS4134] 157.713 ms
202.97.35.153 (202.97.35.153) [AS4134] 209.974 ms
202.97.39.230 (202.97.39.230) [AS4134] 241.158 ms
20 202.97.34.189 (202.97.34.189) [AS4134] 184.304 ms *
202.97.34.133 (202.97.34.133) [AS4134] 227.440 ms
AWS 서울 à AWS China (예)
Mtr 비교
mtr --tcp -P 22 54.222.13x.xx--report -c 100
Start: Mon May 2 00:06:25 2016
HOST: 80e627e.ant Loss% Snt Last Avg Best Wrst StDev
1.|-- 172.20.nate.com 0.0% 100 1.8 3.0 1.7 27.3 2.7
2.|-- ??? 100.0 100 0.0 0.0 0.0 0.0 0.0
3.|-- 172.28.nate.com 0.0% 100 65.6 48.3 24.7 522.9
54.7
4.|-- ??? 100.0 100 0.0 0.0 0.0 0.0 0.0
5.|-- ??? 100.0 100 0.0 0.0 0.0 0.0 0.0
6.|-- 113.217.252.149 76.0% 100 30.4 57.1 29.0 354.1
68.2
7.|-- ??? 100.0 100 0.0 0.0 0.0 0.0 0.0
8.|-- 1.255.25.129 0.0% 100 48.4 51.7 27.9 374.7
44.8
9.|-- 39.115.132.141 0.0% 100 52.2 49.9 28.3 236.6
29.8
10.|-- 58.229.15.206 23.0% 100 71.3 84.1 62.2 262.1
28.5
11.|-- 202.97.121.169 0.0% 100 80.2 84.1 63.8 221.6
20.6
67.9
15.|-- ??? 100.0 99 0.0 0.0 0.0 0.0 0.0
16.|-- 98.31.110.36.static.bjtel 11.2% 98 146.0 147.5 123.6
571.6 48.6
17.|-- 54.222.1.11 2.1% 97 110.9 123.2 105.2 252.5
16.2
18.|-- 54.222.1.35 3.1% 97 116.7 120.5 101.8 198.0
12.9
A 망 à AWS China
Loss 율이 변화하지 않는 것이 중요
mtr --tcp -P 22 54.222.137.37 --report -c 100
ST: ip-172-31-10-43 Loss% Snt Last Avg Best Wrst
StDev
1.|-- ??? 100.0 100 0.0 0.0 0.0 0.0 0.0
4.|-- 100.64.17.225 0.0% 100 0.4 6.6 0.3 616.2 61.6
5.|-- 54.239.122.7 0.0% 100 1.1 6.7 0.7 577.6
57.7
10.|-- 54.239.53.11 0.0% 100 38.5 45.9 37.2 429.8
39.2
12.|-- 106.187.29.153 0.0% 100 39.8 44.2 37.8 342.3
31.2
13.|-- o205.int-gw.kddi.ne. 0.0% 100 42.8 48.4 37.3 458.9
49.9
14.|-- otejb.int-gw.kddi.ne. 0.0% 100 46.9 46.6 37.1 420.4
44.2
15.|-- 203.181.102.42 0.0% 100 41.2 58.0 37.0 381.8
52.1
16.|-- 203.181.102.42 24.0% 100 151.4 162.0 148.8
495.3 43.8
18.|-- 202.97.33.161 35.0% 100 161.5 210.6 149.8 3159.
373.3
19.|-- 202.97.33.25 3.0% 100 154.7 212.1 151.1 1222.
146.6
AWS 서울 à AWS China
Ping & Scp 비교
ping -c 20 54.222.13x.xx
PING 54.222.137.37 (54.222.137.37): 56 data bytes
Request timeout for icmp_seq 0
64 bytes from 54.222.137.37: icmp_seq=1 ttl=46 time=151.090 ms
Request timeout for icmp_seq 2
64 bytes from 54.222.137.37: icmp_seq=3 ttl=46 time=152.218 ms
64 bytes from 54.222.137.37: icmp_seq=4 ttl=46 time=151.107 ms
64 bytes from 54.222.137.37: icmp_seq=5 ttl=46 time=150.753 ms
64 bytes from 54.222.137.37: icmp_seq=6 ttl=46 time=152.004 ms
Request timeout for icmp_seq 7
64 bytes from 54.222.137.37: icmp_seq=8 ttl=46 time=154.614 ms
64 bytes from 54.222.137.37: icmp_seq=9 ttl=46 time=154.078 ms
Request timeout for icmp_seq 10
Request timeout for icmp_seq 11
A 망 à AWS China (ping)
Transferred: sent 105672, received 2232 bytes, in 1.4 seconds
Bytes per second: sent 76756.9, received 1621.3
tcp.analysis.retransmission : 1
AWS 서울 à AWS China (100KB, tcpdump)
Transferred: sent 105672, received 2232 bytes, in 7.0 seconds
Bytes per second: sent 15009.0, received 317.0
tcp.analysis.retransmission : 24
A 망 à AWS China (100KB, tcpdump)
비교 성능 결과
§ Traceroute 결과
• 서울리전과 베이징 리전간 라우팅 경로가 훨씬 일관성이 있음
§ Ping 수행 결과
• A망 à AWS China : 53 ~ 173 ms (라우팅 경로에 따라 ping 응답이 차이가 큼)
• 서울리전 à AWS China : 107 ~ 108 ms (편차가 적음)
§ 데이터 전송(100KB) 결과
• A망 à AWS China : 7.0 초 / TCP 재전송 24회
• 서울리전 à AWS China : 1.4초 / TCP 재전송 1회
Region
Edge Location
12 Regions
33 Availability Zones
54 Edge Locations
AWS optimized network
Internet
다른 점
Amazon S3 전송 가속
Embedded WAN acceleration
S3 Bucket
AWS Edge
Location
Uploader
Optimized
Throughput!
지리적으로 멀리 떨어진 곳으로의
이동
최대 300% (6x) 빠름
No firewall mods, no client software
54 글로벌 엣지 로케이션
엔드포인트를 바꾸면 되고, 코드를
바꿀 필요가 없다
New~
S3 전송 가속
Region
Edge Location
12 Regions
32 Availability Zones
54 Edge Locations
Need to update
We’re here J
CloudFront 동적 컨텐츠
글로벌 인프라
Elastic Load
Balancing
Dynamic content
Amazon EC2
Static content
Amazon S3
* (default)
/error/*
/assets/*
Amazon CloudFront
example.com
CloudFront 동적 컨텐츠
여러 오리진에 대한 설정
CloudFront
Customer	Location
www.mysite.com
Path Pattern Matching
/*.jpg; /*.php etc.
GET http://mysite.com/images/1.jpg to ORIGIN A
GET http://mysite.com/index.php to ORIGIN B
GET http://mysite.com/web/home.css to ORIGIN C
GET http://mysite.com/* (DEFAULT) to ORIGIN D
Origin A: S3 bucket
Origin B:
www.mysite.com
Origin C: S3 Bucket
Origin D:
www.mysite.com
Path Pattern Matching
/*.php
/images/*.jpg
/web/*.css
/*.* (DEFAULT)
CloudFront 동적 컨텐츠
CloudFront 동작
DEMO!
버지니아 리전의 웹서버 성능 비교
웹서버 직접 호출 CF를 통한 호출
min mean median min mean median
1k 529 949 926 468 693 645
2k 588 1090 1173 481 701 699
4k 879 1158 1129 492 809 750
B망 à Us-east-1b : c4.large 단위 : ms
상대적인 값만 볼것. 이것은 패킷의 전달 속도만을 측정하는 것임.
측정하는 망이나 위치에 따라 값은 달라짐
AWS Edge
Location
Client
Optimized
Path
HTTP(s) 게임
Game Server
US region
HTTP(s)형 게임은
CloudFront 다이나믹
컨텐츠 지원 기능을
이용한다.
각 글로벌 엣지로부터
최적화된 네트워크
경로를 통해서 게임
서비스 리전으로
연결된다.
AWS Region
Client
Optimized
Path
TCP 게임
US region
TCP 형 게임은
클라이언트가 있는
곳의 AWS리전에
Proxy서버를
구축한다.
각 Proxy서버로부터
최적화된 네트워크
경로를 통해서 게임
서비스 리전으로
연결된다.
Proxy
글로벌 one region 게임 서비스?
§ 성능관련 검증 내용
• 라우팅 경로 확인
• 지연시간 확인
• 지연시간의 편차 확인
• 일정 크기 파일 전송 확인 à 패킷 로스 및 재전송 확인
§ 성능 검증 결론
• 최적화 된 인터넷 경로
• Keep-Alive
§ AWS 서비스
• HTTP(s) : AWS CloudFront 동적 컨텐츠 지원
• TCP : 지역별로 구현된 Proxy 서버 Spot과 AWS 각 리전 연결
글로벌 단일 리전 게임 설계시 다음을 고려하라
§ 지연을 인정하라
• 전 세계 어느 지역에서든 500ms ~ 1s의 지연 허용
• 게임 종류에 따른 설계 반영 : 비동기, 버퍼링, eventually consistency (UDP)
§ 지원 가능한 인프라를 선택하라
• AWS : 각 리전, CloudFront, 리전 별 Proxy 구축
§ 서비스 대상 범위를 지정하고 검증하라
• 지역의 선정 : 아시아, 유럽, 전 세계?
• 각 로컬 네트워크 망의 사정 고려 및 테스트
• 지연이 심한 경우의 과감한 취사 선택
§ 서버 아키텍처를 과감히 변경하라
• 서버 프로세싱을 최소화 : 네트워크가 지연시간의 대다수가 되도록
• 캐시, 메모리 DB, NoSQL 등으로 과감한 설계 구조 변경
• 게임 서버내의 성능 병목지점 제거
3. AWS상에서 시스템 최적화
• 인스턴스 유형을 선택하는 것이 리소스 성능 튜닝과 같은 효과를
가져옴
• 워크로드에 맞는 이상적인 인스턴스 유형을 찾는 것이 관건
AWS에서 컴퓨팅 퍼포먼스란?
인스턴스 선택 = 성능 튜닝
예: HTTP game application 시스템 콜
방안 1 : 게임 서버 설계시 시스템 call을 최소화하라
§ 단일 쓰레드 vs 다중 쓰레드
• 같은 리소스에 경쟁적으로 접근 예) 파일, 소켓, 특정 메모리 등
§ O/S Lock의 최소화
• 상호 경쟁적 접근 요청이 많을 수록 lock은 극단적으로 비싸짐.
§ 큐 활용의 제한
• 처리 로직 사이 이벤트 큐의 입출력이 전체 비용의 대다수를 차지 예) 비거나
차거나 à 경쟁관계나 cache coherence발생으로 높은 비용 요구
• O/S 락을 요구하지 않는 원형버퍼 등의 활용
§ 기본 규칙
• 처리량을 위해서는 async call을, 지연 시간 절감을 위해서는 캐시,
메모리, NoSQL을
X86 CPU 가상화: Prior to Intel VT-x
• 특권 명령어에 대한 이진 변환 (Binary translation for privileged
instructions)
• 반가상화 (Para-virtualization)
• PV는 VMM을 통과해야 하므로, 지연이 증가
• 시스템 콜을 해야하는 어플리케이션의 경우 더욱 영향을 받음
VMM
Application
Kernel
PV
X86 CPU Virtualization: After Intel VT-x
• x86 프로세서는 포펙과 골드버그 가상화 요구를 만족하지 않았음 à
일반 가상머신을 추가하는 것이 어려웠음.
• Hardware assisted virtualization (HVM)
• PV-HVM 은 명령어가 느리게 에뮬레이트 되는 경우 선택적으로 PV
들이버를 사용한다:
• e.g. network and block I/O
Kernel
Application
VMM
PV-HVM
방안 2 : EBS와 함께 PV-HVM AMIs 를 사용하라
Review: C4 Instances
Custom Intel E5-2666 v3 at 2.9 GHz
P-state and C-state controls
Model vCPU Memory (GiB) EBS (Mbps)
c4.large 2 3.75 500
c4.xlarge 4 7.5 750
c4.2xlarge 8 15 1,000
c4.4xlarge 16 30 2,000
c4.8xlarge 36 60 4,000
방안 3 : 고급 벡터확장(AVX2)을 위한 P-state
control 을 고려하라
• 만약 어플리케이션이 모든 코어에서 AVX2 오퍼레이션을
과도하게 요구하게 되면, 프로세서는 가진것 이상의 파워를
이끌어내려고 시도한다.
• 프로세서는 투명하게 프리퀀시를 줄임
• CPU 프리퀀시의 변화는 어플리케이션을 느리게 할수 있다
• Visual Studio 2012에 AVX2 서포트 시작. /arch:AVX2 스위치 옵션이
VS 2012 Update 2부터 지원.
I/O : Granting in pre-3.8.0 Kernels
• Requires “grant mapping” prior to 3.8.0
• Grant mappings are expensive operations due to TLB flushes
read(fd, buffer,…)
I/O : Granting in 3.8.0+ Kernels, Persistent and
Indirect
• Grant mappings are setup in a pool once
• Data is copied in and out of the grant pool
read(fd, buffer…)
Copy to
and from
grant pool
방안 4 : 3.8+ 커널 사용하라
• Amazon Linux 13.09 or later
• Ubuntu 14.04 or later
• RHEL7 or later
• Etc.
디바이스 요청 : Enhanced Networking
• SR-IOV 드라이버 도메인 단계를 제거
• 물리적인 네트워크 디바이스가 가상 함수를 인스턴스에
노출
• 특별한 드라이버 필요 :
• 인스턴스의 OS 가 인식하고 있어야 함
• EC2가 인스턴스에 사용할 수 있음을 알려주어야 함
Hardware
After Enhanced Networking
Driver Domain Guest Domain Guest Domain
VMM
Frontend
driver
NIC
Driver
Backend
driver
Device
Driver
Physical
CPU
Physical
Memory
SR-IOV Network
Device
Virtual CPU
Virtual
Memory
CPU
Scheduling
Sockets
Application
Hardware
After Enhanced Networking
Driver Domain Guest Domain Guest Domain
VMM
Frontend
driver
NIC
Driver
Backend
driver
Device
Driver
Physical
CPU
Physical
Memory
SR-IOV Network
Device
Virtual CPU
Virtual
Memory
CPU
Scheduling
Sockets
Application
Hardware
After Enhanced Networking
Driver Domain Guest Domain Guest Domain
VMM
Frontend
driver
NIC
Driver
Backend
driver
Device
Driver
Physical
CPU
Physical
Memory
SR-IOV Network
Device
Virtual CPU
Virtual
Memory
CPU
Scheduling
Sockets
Application
방안 5 : Enhanced Networking 사용하라
• 아주 높은 packets/second
• 지연에 대한 편차가 매우 낮음
• 인스턴스의 OS가 지원해야 함
• 인스턴스나 이미지의 SR-IOV 프로퍼티 확인
5. EBS
EBS란 무엇인가?
• 서비스형 네트워크 블락 스토리지
• EBS 볼륨은 같은 가용존에 있는 어떠한 EC2
인스턴스에도 연결될 수 있음
• 99.999% (five nines) 가용성으로 설계
• 매일 2 백만 볼륨이 생성
EBS volume types
Magnetic General purpose (SSD) Provisioned IOPS
(SSD)
st1, sc1 gp2 io1
EBS volume types
Solid-State Drives (SSD) Hard disk Drives (HDD)
볼륨타입 General Purpose
SSD (gp2)
Provisioned
IOPS SSD (io1)
Throughput
Optimized HDD
(st1)
Cold HDD (sc1)
볼륨 사이즈 1 GiB - 16 TiB 4 GiB - 16 TiB 500 GiB - 16 TiB 500 GiB - 16 TiB
최대 IOPS/볼륨 10,000 20,000 500 250
최대
Throughput/볼륨
160 MiB/s 320 MiB/s 500 MiB/s 250 MiB/s
성능 개선을 위한 핵심 컴포넌트 : 4개
EC2 instance
I/O
EBS
Network link
Workload/
software
Typical block
size
Random/
Seq?
Max EBS @ 500
MB/s instances
Max EBS @
1 GB/s instances
Max EBS @ 10 GB/s
instances
Oracle DB Configurable:2 KB
–16 KB
Default 8 KB
random ~7,800 IOPS ~15,600 IOPS ~48,000 IOPS
Microsoft SQL
Server
8 KB w/ 64 KB
extents
random ~7,800 IOPS ~15,600 IOPS ~48,000 IOPS
MySQL 16 KB random ~4,000 IOPS ~7,800 IOPS ~48,000 IOPS
PostgreSQL 8 KB random ~7,800 IOPS ~15,600 IOPS ~48,000 IOPS
MongoDB 4 KB sequential ~15,600 IOPS ~31,000 IOPS ~48,000 IOPS
Apache
Cassandra
4 KB random ~15,600 IOPS ~31,000 IOPS ~48,000 IOPS
GlusterFS 128 KB sequential ~500 IOPS ~1,000 IOPS ~6,000 IOPS
참조 테이블 : AWS 상에서 예제 워크로드 표
예제 워크로드
트랜젝션 (OLTP)
예 : 스토어 website, 아이템 거래, 게임 메타 데이터 저장
벤치마크 : MySQL + sysbench
성능 개선을 위한 부분(컴포넌트) 및 병목지점 확인
최초 테스트 사양
가용존 : US West (Oregon)
인스턴스 타입 : m2.4xlarge
vCPU: 8
Memory: 68.4GiB
EBS-optimized
데이터 볼륨 : 500GiB EBS magnetic
OS: Amazon Linux 2015.03.1
CPU: Intel Xeon
병렬처리 확장성 테스트 - 쓰레드 수를 늘림
MySQL threads
Transactions(n)
Baseline
2 n
EBS 최적화 인스턴스
• 대부분의 인스턴스 패밀리가 EBS-optimized 플래그를 지원
• EBS-optimized instances now support up to 4 Gb/s
• Drive 32,000 16K IOPS or 500 MB/s
• Available by default on newer instance types
• EC2 *.8xlarge 는 10 Gb/s 네트워크 지원
• 노드 당 지원되는 최대 IOPS 는 ~48,000 IOPS @ 16K I/O
인스턴스 변경
가용 존: US West (Oregon)
인스턴스 타입: r3.2xlarge
vCPU: 8
Memory: 61 GiB
EBS-optimized
EBS volume: 500GiB magnetic
OS: Amazon Linux 2015.03.1
CPU: Intel Xeon E5-2670 v2
25%
EBS 최적화 & 최신 세대 인스턴스
MySQL threads
Transactions(n)
Baseline
r3.2xlarge
2 n
볼륨 타입 선택
EBS magnetic
지연 :
Read: 10-40ms
Write: 2-10ms
SSD backed
지연 :
Read/Write: Single-digit ms
Pre-warming
인스턴스 변경: EBS volumes
Availability Zone: US West (Oregon)
Instance type: r3.2xlarge
vCPU: 8
Memory: 61 GiB
EBS-optimized
Boot volume: 8 GiB – EBS general purpose
Data volume: 500 GiB – EBS general purpose
OS: Amazon Linux 2015.03.1
Optimization: Volume selection
Transactions(n)
19% 50%
MySQL threads
Baseline
r3.2xlarge
r3.2xlarge gp2
2 n
방안 6 : EBS 성능 개선을 위해 최신 인스턴스와
옵션을 사용하라
워크로드 최적의 인스턴스를 선택하라
가급적 최신 세대 인스턴스를 사용하라
볼륨 퍼포먼스가 문제되면 SSD 볼륨 타입을
선정하라
작은 볼륨 사이즈에 높은 IOPS가 필요하면 io1
타입을 선택하라
EBS IOPS vs. Throughput
20,000 IOPS
PIOPS volume
20,000 IOPS
320 MB/s
throughput
You can achieve 20,000 IOPS when
driving smaller I/O operations
You can achieve up to 320 MB/s
when driving larger I/O operations
스트라이핑 (Striping)
Increases performance, or capacity, or both
Don’t mix volume types
Typically RAID 0 or LVM stripe
Avoid RAID for redundancy
EBS
EC2
EBS-optimized instance
4개 핵심 컴포넌트 : 균형(Balanced) = 고른 utilization
EC2
A “boatload” of I/O
Right-sized EBS
1. 게임 서버 설계시 시스템 call을 최소화하라
2. PV-HVM AMIs 를 사용하라
3. 고급 벡터확장(AVX2)을 위한 P-state control 을 고려하라
4. 3.8+ 커널 사용하라
5. Enhanced Networking 사용하라
6. EBS 성능 개선을 위해 최신의 인스턴스와 옵션을 사용하라
최적화 방안 정리
AWS 상에서 게임 서비스 최적화 방안 :: 박선용 :: AWS Summit Seoul 2016

Contenu connexe

Tendances

AWS를 활용한 미디어 고객사 서비스 혁신 사례 - 양승도 :: AWS 미디어 커스토머 데이
AWS를 활용한 미디어 고객사 서비스 혁신 사례 - 양승도 :: AWS 미디어 커스토머 데이AWS를 활용한 미디어 고객사 서비스 혁신 사례 - 양승도 :: AWS 미디어 커스토머 데이
AWS를 활용한 미디어 고객사 서비스 혁신 사례 - 양승도 :: AWS 미디어 커스토머 데이Amazon Web Services Korea
 
Aws summit 2017_이상오_fn
Aws summit 2017_이상오_fnAws summit 2017_이상오_fn
Aws summit 2017_이상오_fnLEE Kevin
 
AWS CLOUD 2018- Amazon Aurora  신규 서비스 알아보기 (최유정 솔루션즈 아키텍트)
AWS CLOUD 2018- Amazon Aurora  신규 서비스 알아보기 (최유정 솔루션즈 아키텍트)AWS CLOUD 2018- Amazon Aurora  신규 서비스 알아보기 (최유정 솔루션즈 아키텍트)
AWS CLOUD 2018- Amazon Aurora  신규 서비스 알아보기 (최유정 솔루션즈 아키텍트)Amazon Web Services Korea
 
마이크로서비스를 위한 AWS 아키텍처 패턴 및 모범 사례 - AWS Summit Seoul 2017
마이크로서비스를 위한 AWS 아키텍처 패턴 및 모범 사례 - AWS Summit Seoul 2017마이크로서비스를 위한 AWS 아키텍처 패턴 및 모범 사례 - AWS Summit Seoul 2017
마이크로서비스를 위한 AWS 아키텍처 패턴 및 모범 사례 - AWS Summit Seoul 2017Amazon Web Services Korea
 
Amazon kinesis와 elasticsearch service로 만드는 실시간 데이터 분석 플랫폼 :: 박철수 :: AWS Summi...
Amazon kinesis와 elasticsearch service로 만드는 실시간 데이터 분석 플랫폼 :: 박철수 :: AWS Summi...Amazon kinesis와 elasticsearch service로 만드는 실시간 데이터 분석 플랫폼 :: 박철수 :: AWS Summi...
Amazon kinesis와 elasticsearch service로 만드는 실시간 데이터 분석 플랫폼 :: 박철수 :: AWS Summi...Amazon Web Services Korea
 
CloudWatch 성능 모니터링과 신속한 대응을 위한 노하우 - 박선용 솔루션즈 아키텍트:: AWS Cloud Track 3 Gaming
CloudWatch 성능 모니터링과 신속한 대응을 위한 노하우 - 박선용 솔루션즈 아키텍트:: AWS Cloud Track 3 GamingCloudWatch 성능 모니터링과 신속한 대응을 위한 노하우 - 박선용 솔루션즈 아키텍트:: AWS Cloud Track 3 Gaming
CloudWatch 성능 모니터링과 신속한 대응을 위한 노하우 - 박선용 솔루션즈 아키텍트:: AWS Cloud Track 3 GamingAmazon Web Services Korea
 
AWS 환경에서 MySQL Infra 설계하기-2부.본론
AWS 환경에서 MySQL Infra 설계하기-2부.본론AWS 환경에서 MySQL Infra 설계하기-2부.본론
AWS 환경에서 MySQL Infra 설계하기-2부.본론I Goo Lee
 
가상 데이터 센터 만들기 VPC 기본 및 연결 옵션- AWS Summit Seoul 2017
가상 데이터 센터 만들기 VPC 기본 및 연결 옵션- AWS Summit Seoul 2017가상 데이터 센터 만들기 VPC 기본 및 연결 옵션- AWS Summit Seoul 2017
가상 데이터 센터 만들기 VPC 기본 및 연결 옵션- AWS Summit Seoul 2017Amazon Web Services Korea
 
[Azure study group] azure의 부하분산
[Azure study group] azure의 부하분산[Azure study group] azure의 부하분산
[Azure study group] azure의 부하분산세준 김
 
쉽게 알아보는 AWS 클라우드 보안 :: 임기성 & 신용녀 :: AWS Summit Seoul 2016
쉽게 알아보는 AWS 클라우드 보안 :: 임기성 & 신용녀 :: AWS Summit Seoul 2016쉽게 알아보는 AWS 클라우드 보안 :: 임기성 & 신용녀 :: AWS Summit Seoul 2016
쉽게 알아보는 AWS 클라우드 보안 :: 임기성 & 신용녀 :: AWS Summit Seoul 2016Amazon Web Services Korea
 
AWS 기반의 마이크로 서비스 아키텍쳐 구현 방안 :: 김필중 :: AWS Summit Seoul 20
AWS 기반의 마이크로 서비스 아키텍쳐 구현 방안 :: 김필중 :: AWS Summit Seoul 20AWS 기반의 마이크로 서비스 아키텍쳐 구현 방안 :: 김필중 :: AWS Summit Seoul 20
AWS 기반의 마이크로 서비스 아키텍쳐 구현 방안 :: 김필중 :: AWS Summit Seoul 20Amazon Web Services Korea
 
[Gaming on AWS] AWS와 함께 한 쿠키런 서버 Re-architecting 사례 - 데브시스터즈
[Gaming on AWS] AWS와 함께 한 쿠키런 서버 Re-architecting 사례 - 데브시스터즈[Gaming on AWS] AWS와 함께 한 쿠키런 서버 Re-architecting 사례 - 데브시스터즈
[Gaming on AWS] AWS와 함께 한 쿠키런 서버 Re-architecting 사례 - 데브시스터즈Amazon Web Services Korea
 
Cloudera Impala 1.0
Cloudera Impala 1.0Cloudera Impala 1.0
Cloudera Impala 1.0Minwoo Kim
 
[115]쿠팡 서비스 클라우드 마이그레이션 통해 배운것들
[115]쿠팡 서비스 클라우드 마이그레이션 통해 배운것들[115]쿠팡 서비스 클라우드 마이그레이션 통해 배운것들
[115]쿠팡 서비스 클라우드 마이그레이션 통해 배운것들NAVER D2
 
AWS 클라우드 기반 게임 아키텍처 사례 - AWS Summit Seoul 2017
AWS 클라우드 기반 게임 아키텍처 사례 - AWS Summit Seoul 2017AWS 클라우드 기반 게임 아키텍처 사례 - AWS Summit Seoul 2017
AWS 클라우드 기반 게임 아키텍처 사례 - AWS Summit Seoul 2017Amazon Web Services Korea
 
Zadara Storage As-a-Service, 스토리지 전문 서비스 활용 전략 - AWS Summit Seoul 2017
Zadara Storage As-a-Service, 스토리지 전문 서비스 활용 전략 - AWS Summit Seoul 2017Zadara Storage As-a-Service, 스토리지 전문 서비스 활용 전략 - AWS Summit Seoul 2017
Zadara Storage As-a-Service, 스토리지 전문 서비스 활용 전략 - AWS Summit Seoul 2017Amazon Web Services Korea
 
AWS 를 이용한 Serverless Infra 구축해보기 (Lambda, DynamoDB)
AWS 를 이용한 Serverless Infra 구축해보기 (Lambda, DynamoDB)AWS 를 이용한 Serverless Infra 구축해보기 (Lambda, DynamoDB)
AWS 를 이용한 Serverless Infra 구축해보기 (Lambda, DynamoDB)I Goo Lee
 
게임 서비스를 위한 AWS상의 고성능 SQL 데이터베이스 구성 (이정훈 솔루션즈 아키텍트, AWS) :: Gaming on AWS 2018
게임 서비스를 위한 AWS상의 고성능 SQL 데이터베이스 구성 (이정훈 솔루션즈 아키텍트, AWS) :: Gaming on AWS 2018게임 서비스를 위한 AWS상의 고성능 SQL 데이터베이스 구성 (이정훈 솔루션즈 아키텍트, AWS) :: Gaming on AWS 2018
게임 서비스를 위한 AWS상의 고성능 SQL 데이터베이스 구성 (이정훈 솔루션즈 아키텍트, AWS) :: Gaming on AWS 2018Amazon Web Services Korea
 
Photon게임서버 네트워크엔진과 GBaaS를 통한 AWS DB 서비스 구성 방법 소개 - AWS Summit Seoul 2017
Photon게임서버 네트워크엔진과 GBaaS를 통한 AWS DB 서비스 구성 방법 소개 - AWS Summit Seoul 2017Photon게임서버 네트워크엔진과 GBaaS를 통한 AWS DB 서비스 구성 방법 소개 - AWS Summit Seoul 2017
Photon게임서버 네트워크엔진과 GBaaS를 통한 AWS DB 서비스 구성 방법 소개 - AWS Summit Seoul 2017Amazon Web Services Korea
 
ELB와 EBS의 아키텍터로 생각해보는 사용상 주의할 점들
ELB와 EBS의 아키텍터로 생각해보는 사용상 주의할 점들ELB와 EBS의 아키텍터로 생각해보는 사용상 주의할 점들
ELB와 EBS의 아키텍터로 생각해보는 사용상 주의할 점들AWSKRUG - AWS한국사용자모임
 

Tendances (20)

AWS를 활용한 미디어 고객사 서비스 혁신 사례 - 양승도 :: AWS 미디어 커스토머 데이
AWS를 활용한 미디어 고객사 서비스 혁신 사례 - 양승도 :: AWS 미디어 커스토머 데이AWS를 활용한 미디어 고객사 서비스 혁신 사례 - 양승도 :: AWS 미디어 커스토머 데이
AWS를 활용한 미디어 고객사 서비스 혁신 사례 - 양승도 :: AWS 미디어 커스토머 데이
 
Aws summit 2017_이상오_fn
Aws summit 2017_이상오_fnAws summit 2017_이상오_fn
Aws summit 2017_이상오_fn
 
AWS CLOUD 2018- Amazon Aurora  신규 서비스 알아보기 (최유정 솔루션즈 아키텍트)
AWS CLOUD 2018- Amazon Aurora  신규 서비스 알아보기 (최유정 솔루션즈 아키텍트)AWS CLOUD 2018- Amazon Aurora  신규 서비스 알아보기 (최유정 솔루션즈 아키텍트)
AWS CLOUD 2018- Amazon Aurora  신규 서비스 알아보기 (최유정 솔루션즈 아키텍트)
 
마이크로서비스를 위한 AWS 아키텍처 패턴 및 모범 사례 - AWS Summit Seoul 2017
마이크로서비스를 위한 AWS 아키텍처 패턴 및 모범 사례 - AWS Summit Seoul 2017마이크로서비스를 위한 AWS 아키텍처 패턴 및 모범 사례 - AWS Summit Seoul 2017
마이크로서비스를 위한 AWS 아키텍처 패턴 및 모범 사례 - AWS Summit Seoul 2017
 
Amazon kinesis와 elasticsearch service로 만드는 실시간 데이터 분석 플랫폼 :: 박철수 :: AWS Summi...
Amazon kinesis와 elasticsearch service로 만드는 실시간 데이터 분석 플랫폼 :: 박철수 :: AWS Summi...Amazon kinesis와 elasticsearch service로 만드는 실시간 데이터 분석 플랫폼 :: 박철수 :: AWS Summi...
Amazon kinesis와 elasticsearch service로 만드는 실시간 데이터 분석 플랫폼 :: 박철수 :: AWS Summi...
 
CloudWatch 성능 모니터링과 신속한 대응을 위한 노하우 - 박선용 솔루션즈 아키텍트:: AWS Cloud Track 3 Gaming
CloudWatch 성능 모니터링과 신속한 대응을 위한 노하우 - 박선용 솔루션즈 아키텍트:: AWS Cloud Track 3 GamingCloudWatch 성능 모니터링과 신속한 대응을 위한 노하우 - 박선용 솔루션즈 아키텍트:: AWS Cloud Track 3 Gaming
CloudWatch 성능 모니터링과 신속한 대응을 위한 노하우 - 박선용 솔루션즈 아키텍트:: AWS Cloud Track 3 Gaming
 
AWS 환경에서 MySQL Infra 설계하기-2부.본론
AWS 환경에서 MySQL Infra 설계하기-2부.본론AWS 환경에서 MySQL Infra 설계하기-2부.본론
AWS 환경에서 MySQL Infra 설계하기-2부.본론
 
가상 데이터 센터 만들기 VPC 기본 및 연결 옵션- AWS Summit Seoul 2017
가상 데이터 센터 만들기 VPC 기본 및 연결 옵션- AWS Summit Seoul 2017가상 데이터 센터 만들기 VPC 기본 및 연결 옵션- AWS Summit Seoul 2017
가상 데이터 센터 만들기 VPC 기본 및 연결 옵션- AWS Summit Seoul 2017
 
[Azure study group] azure의 부하분산
[Azure study group] azure의 부하분산[Azure study group] azure의 부하분산
[Azure study group] azure의 부하분산
 
쉽게 알아보는 AWS 클라우드 보안 :: 임기성 & 신용녀 :: AWS Summit Seoul 2016
쉽게 알아보는 AWS 클라우드 보안 :: 임기성 & 신용녀 :: AWS Summit Seoul 2016쉽게 알아보는 AWS 클라우드 보안 :: 임기성 & 신용녀 :: AWS Summit Seoul 2016
쉽게 알아보는 AWS 클라우드 보안 :: 임기성 & 신용녀 :: AWS Summit Seoul 2016
 
AWS 기반의 마이크로 서비스 아키텍쳐 구현 방안 :: 김필중 :: AWS Summit Seoul 20
AWS 기반의 마이크로 서비스 아키텍쳐 구현 방안 :: 김필중 :: AWS Summit Seoul 20AWS 기반의 마이크로 서비스 아키텍쳐 구현 방안 :: 김필중 :: AWS Summit Seoul 20
AWS 기반의 마이크로 서비스 아키텍쳐 구현 방안 :: 김필중 :: AWS Summit Seoul 20
 
[Gaming on AWS] AWS와 함께 한 쿠키런 서버 Re-architecting 사례 - 데브시스터즈
[Gaming on AWS] AWS와 함께 한 쿠키런 서버 Re-architecting 사례 - 데브시스터즈[Gaming on AWS] AWS와 함께 한 쿠키런 서버 Re-architecting 사례 - 데브시스터즈
[Gaming on AWS] AWS와 함께 한 쿠키런 서버 Re-architecting 사례 - 데브시스터즈
 
Cloudera Impala 1.0
Cloudera Impala 1.0Cloudera Impala 1.0
Cloudera Impala 1.0
 
[115]쿠팡 서비스 클라우드 마이그레이션 통해 배운것들
[115]쿠팡 서비스 클라우드 마이그레이션 통해 배운것들[115]쿠팡 서비스 클라우드 마이그레이션 통해 배운것들
[115]쿠팡 서비스 클라우드 마이그레이션 통해 배운것들
 
AWS 클라우드 기반 게임 아키텍처 사례 - AWS Summit Seoul 2017
AWS 클라우드 기반 게임 아키텍처 사례 - AWS Summit Seoul 2017AWS 클라우드 기반 게임 아키텍처 사례 - AWS Summit Seoul 2017
AWS 클라우드 기반 게임 아키텍처 사례 - AWS Summit Seoul 2017
 
Zadara Storage As-a-Service, 스토리지 전문 서비스 활용 전략 - AWS Summit Seoul 2017
Zadara Storage As-a-Service, 스토리지 전문 서비스 활용 전략 - AWS Summit Seoul 2017Zadara Storage As-a-Service, 스토리지 전문 서비스 활용 전략 - AWS Summit Seoul 2017
Zadara Storage As-a-Service, 스토리지 전문 서비스 활용 전략 - AWS Summit Seoul 2017
 
AWS 를 이용한 Serverless Infra 구축해보기 (Lambda, DynamoDB)
AWS 를 이용한 Serverless Infra 구축해보기 (Lambda, DynamoDB)AWS 를 이용한 Serverless Infra 구축해보기 (Lambda, DynamoDB)
AWS 를 이용한 Serverless Infra 구축해보기 (Lambda, DynamoDB)
 
게임 서비스를 위한 AWS상의 고성능 SQL 데이터베이스 구성 (이정훈 솔루션즈 아키텍트, AWS) :: Gaming on AWS 2018
게임 서비스를 위한 AWS상의 고성능 SQL 데이터베이스 구성 (이정훈 솔루션즈 아키텍트, AWS) :: Gaming on AWS 2018게임 서비스를 위한 AWS상의 고성능 SQL 데이터베이스 구성 (이정훈 솔루션즈 아키텍트, AWS) :: Gaming on AWS 2018
게임 서비스를 위한 AWS상의 고성능 SQL 데이터베이스 구성 (이정훈 솔루션즈 아키텍트, AWS) :: Gaming on AWS 2018
 
Photon게임서버 네트워크엔진과 GBaaS를 통한 AWS DB 서비스 구성 방법 소개 - AWS Summit Seoul 2017
Photon게임서버 네트워크엔진과 GBaaS를 통한 AWS DB 서비스 구성 방법 소개 - AWS Summit Seoul 2017Photon게임서버 네트워크엔진과 GBaaS를 통한 AWS DB 서비스 구성 방법 소개 - AWS Summit Seoul 2017
Photon게임서버 네트워크엔진과 GBaaS를 통한 AWS DB 서비스 구성 방법 소개 - AWS Summit Seoul 2017
 
ELB와 EBS의 아키텍터로 생각해보는 사용상 주의할 점들
ELB와 EBS의 아키텍터로 생각해보는 사용상 주의할 점들ELB와 EBS의 아키텍터로 생각해보는 사용상 주의할 점들
ELB와 EBS의 아키텍터로 생각해보는 사용상 주의할 점들
 

Similaire à AWS 상에서 게임 서비스 최적화 방안 :: 박선용 :: AWS Summit Seoul 2016

AWS 환경에서 MySQL BMT
AWS 환경에서 MySQL BMTAWS 환경에서 MySQL BMT
AWS 환경에서 MySQL BMTI Goo Lee
 
Development of microgrid integrated multi platform using dds and verification...
Development of microgrid integrated multi platform using dds and verification...Development of microgrid integrated multi platform using dds and verification...
Development of microgrid integrated multi platform using dds and verification...Dong-Jin Lee
 
광안 1반 2팀 엠퀴즈 최종 발표 자료.pptx
광안 1반 2팀 엠퀴즈 최종 발표 자료.pptx광안 1반 2팀 엠퀴즈 최종 발표 자료.pptx
광안 1반 2팀 엠퀴즈 최종 발표 자료.pptxYeongKiKim1
 
[오픈소스컨설팅]Java Performance Tuning
[오픈소스컨설팅]Java Performance Tuning[오픈소스컨설팅]Java Performance Tuning
[오픈소스컨설팅]Java Performance TuningJi-Woong Choi
 
윤석준 2015 cuda_contest
윤석준 2015 cuda_contest윤석준 2015 cuda_contest
윤석준 2015 cuda_contestSeok-joon Yun
 
초초초 (초고속 초저지연 초연결) 5G IoT 플랫폼 개발 이야기
초초초 (초고속 초저지연 초연결) 5G IoT 플랫폼 개발 이야기초초초 (초고속 초저지연 초연결) 5G IoT 플랫폼 개발 이야기
초초초 (초고속 초저지연 초연결) 5G IoT 플랫폼 개발 이야기ksdc2019
 
11_빠른 개발 가능한 레벨 편집 시스템
11_빠른 개발 가능한 레벨 편집 시스템11_빠른 개발 가능한 레벨 편집 시스템
11_빠른 개발 가능한 레벨 편집 시스템noerror
 
[OpenStack Days Korea 2016] Track3 - 방송제작용 UHD 스트로지 구성 및 테스트
[OpenStack Days Korea 2016] Track3 - 방송제작용 UHD 스트로지 구성 및 테스트[OpenStack Days Korea 2016] Track3 - 방송제작용 UHD 스트로지 구성 및 테스트
[OpenStack Days Korea 2016] Track3 - 방송제작용 UHD 스트로지 구성 및 테스트OpenStack Korea Community
 
클라우드 환경에서 알아야할 성능 이야기
클라우드 환경에서 알아야할 성능 이야기클라우드 환경에서 알아야할 성능 이야기
클라우드 환경에서 알아야할 성능 이야기YoungSu Son
 
[오픈소스컨설팅]Performance Tuning How To
[오픈소스컨설팅]Performance Tuning How To[오픈소스컨설팅]Performance Tuning How To
[오픈소스컨설팅]Performance Tuning How ToJi-Woong Choi
 
Opensource APM SCOUTER in practice
Opensource APM SCOUTER in practiceOpensource APM SCOUTER in practice
Opensource APM SCOUTER in practiceGunHee Lee
 
KGC 2014: 분산 게임 서버 구조론
KGC 2014: 분산 게임 서버 구조론KGC 2014: 분산 게임 서버 구조론
KGC 2014: 분산 게임 서버 구조론Hyunjik Bae
 
3.[d2 오픈세미나]분산시스템 개발 및 교훈 n base arc
3.[d2 오픈세미나]분산시스템 개발 및 교훈 n base arc3.[d2 오픈세미나]분산시스템 개발 및 교훈 n base arc
3.[d2 오픈세미나]분산시스템 개발 및 교훈 n base arcNAVER D2
 
mongodb와 mysql의 CRUD 연산의 성능 비교
mongodb와 mysql의 CRUD 연산의 성능 비교mongodb와 mysql의 CRUD 연산의 성능 비교
mongodb와 mysql의 CRUD 연산의 성능 비교Woo Yeong Choi
 
[박민근] 3 d렌더링 옵티마이징_nv_perfhud
[박민근] 3 d렌더링 옵티마이징_nv_perfhud[박민근] 3 d렌더링 옵티마이징_nv_perfhud
[박민근] 3 d렌더링 옵티마이징_nv_perfhudMinGeun Park
 
Alluxio: Data Orchestration on Multi-Cloud
Alluxio: Data Orchestration on Multi-CloudAlluxio: Data Orchestration on Multi-Cloud
Alluxio: Data Orchestration on Multi-CloudJinwook Chung
 
클라우드 & 모바일 환경에서 알아야 할 성능 품질 이야기
클라우드 & 모바일 환경에서 알아야 할 성능 품질 이야기클라우드 & 모바일 환경에서 알아야 할 성능 품질 이야기
클라우드 & 모바일 환경에서 알아야 할 성능 품질 이야기YoungSu Son
 
네트웍 설정 오류로 인한 RAC 시스템 성능 저하_Maxgauge case study
네트웍 설정 오류로 인한 RAC 시스템 성능 저하_Maxgauge case study네트웍 설정 오류로 인한 RAC 시스템 성능 저하_Maxgauge case study
네트웍 설정 오류로 인한 RAC 시스템 성능 저하_Maxgauge case study엑셈
 
Vectorized processing in_a_nutshell_DeView2014
Vectorized processing in_a_nutshell_DeView2014Vectorized processing in_a_nutshell_DeView2014
Vectorized processing in_a_nutshell_DeView2014Gruter
 
한컴MDS_국산 RTOS NEOS 제품 및 적용 사례
한컴MDS_국산 RTOS NEOS 제품 및 적용 사례한컴MDS_국산 RTOS NEOS 제품 및 적용 사례
한컴MDS_국산 RTOS NEOS 제품 및 적용 사례HANCOM MDS
 

Similaire à AWS 상에서 게임 서비스 최적화 방안 :: 박선용 :: AWS Summit Seoul 2016 (20)

AWS 환경에서 MySQL BMT
AWS 환경에서 MySQL BMTAWS 환경에서 MySQL BMT
AWS 환경에서 MySQL BMT
 
Development of microgrid integrated multi platform using dds and verification...
Development of microgrid integrated multi platform using dds and verification...Development of microgrid integrated multi platform using dds and verification...
Development of microgrid integrated multi platform using dds and verification...
 
광안 1반 2팀 엠퀴즈 최종 발표 자료.pptx
광안 1반 2팀 엠퀴즈 최종 발표 자료.pptx광안 1반 2팀 엠퀴즈 최종 발표 자료.pptx
광안 1반 2팀 엠퀴즈 최종 발표 자료.pptx
 
[오픈소스컨설팅]Java Performance Tuning
[오픈소스컨설팅]Java Performance Tuning[오픈소스컨설팅]Java Performance Tuning
[오픈소스컨설팅]Java Performance Tuning
 
윤석준 2015 cuda_contest
윤석준 2015 cuda_contest윤석준 2015 cuda_contest
윤석준 2015 cuda_contest
 
초초초 (초고속 초저지연 초연결) 5G IoT 플랫폼 개발 이야기
초초초 (초고속 초저지연 초연결) 5G IoT 플랫폼 개발 이야기초초초 (초고속 초저지연 초연결) 5G IoT 플랫폼 개발 이야기
초초초 (초고속 초저지연 초연결) 5G IoT 플랫폼 개발 이야기
 
11_빠른 개발 가능한 레벨 편집 시스템
11_빠른 개발 가능한 레벨 편집 시스템11_빠른 개발 가능한 레벨 편집 시스템
11_빠른 개발 가능한 레벨 편집 시스템
 
[OpenStack Days Korea 2016] Track3 - 방송제작용 UHD 스트로지 구성 및 테스트
[OpenStack Days Korea 2016] Track3 - 방송제작용 UHD 스트로지 구성 및 테스트[OpenStack Days Korea 2016] Track3 - 방송제작용 UHD 스트로지 구성 및 테스트
[OpenStack Days Korea 2016] Track3 - 방송제작용 UHD 스트로지 구성 및 테스트
 
클라우드 환경에서 알아야할 성능 이야기
클라우드 환경에서 알아야할 성능 이야기클라우드 환경에서 알아야할 성능 이야기
클라우드 환경에서 알아야할 성능 이야기
 
[오픈소스컨설팅]Performance Tuning How To
[오픈소스컨설팅]Performance Tuning How To[오픈소스컨설팅]Performance Tuning How To
[오픈소스컨설팅]Performance Tuning How To
 
Opensource APM SCOUTER in practice
Opensource APM SCOUTER in practiceOpensource APM SCOUTER in practice
Opensource APM SCOUTER in practice
 
KGC 2014: 분산 게임 서버 구조론
KGC 2014: 분산 게임 서버 구조론KGC 2014: 분산 게임 서버 구조론
KGC 2014: 분산 게임 서버 구조론
 
3.[d2 오픈세미나]분산시스템 개발 및 교훈 n base arc
3.[d2 오픈세미나]분산시스템 개발 및 교훈 n base arc3.[d2 오픈세미나]분산시스템 개발 및 교훈 n base arc
3.[d2 오픈세미나]분산시스템 개발 및 교훈 n base arc
 
mongodb와 mysql의 CRUD 연산의 성능 비교
mongodb와 mysql의 CRUD 연산의 성능 비교mongodb와 mysql의 CRUD 연산의 성능 비교
mongodb와 mysql의 CRUD 연산의 성능 비교
 
[박민근] 3 d렌더링 옵티마이징_nv_perfhud
[박민근] 3 d렌더링 옵티마이징_nv_perfhud[박민근] 3 d렌더링 옵티마이징_nv_perfhud
[박민근] 3 d렌더링 옵티마이징_nv_perfhud
 
Alluxio: Data Orchestration on Multi-Cloud
Alluxio: Data Orchestration on Multi-CloudAlluxio: Data Orchestration on Multi-Cloud
Alluxio: Data Orchestration on Multi-Cloud
 
클라우드 & 모바일 환경에서 알아야 할 성능 품질 이야기
클라우드 & 모바일 환경에서 알아야 할 성능 품질 이야기클라우드 & 모바일 환경에서 알아야 할 성능 품질 이야기
클라우드 & 모바일 환경에서 알아야 할 성능 품질 이야기
 
네트웍 설정 오류로 인한 RAC 시스템 성능 저하_Maxgauge case study
네트웍 설정 오류로 인한 RAC 시스템 성능 저하_Maxgauge case study네트웍 설정 오류로 인한 RAC 시스템 성능 저하_Maxgauge case study
네트웍 설정 오류로 인한 RAC 시스템 성능 저하_Maxgauge case study
 
Vectorized processing in_a_nutshell_DeView2014
Vectorized processing in_a_nutshell_DeView2014Vectorized processing in_a_nutshell_DeView2014
Vectorized processing in_a_nutshell_DeView2014
 
한컴MDS_국산 RTOS NEOS 제품 및 적용 사례
한컴MDS_국산 RTOS NEOS 제품 및 적용 사례한컴MDS_국산 RTOS NEOS 제품 및 적용 사례
한컴MDS_국산 RTOS NEOS 제품 및 적용 사례
 

Plus de Amazon Web Services Korea

AWS Modern Infra with Storage Roadshow 2023 - Day 2
AWS Modern Infra with Storage Roadshow 2023 - Day 2AWS Modern Infra with Storage Roadshow 2023 - Day 2
AWS Modern Infra with Storage Roadshow 2023 - Day 2Amazon Web Services Korea
 
AWS Modern Infra with Storage Roadshow 2023 - Day 1
AWS Modern Infra with Storage Roadshow 2023 - Day 1AWS Modern Infra with Storage Roadshow 2023 - Day 1
AWS Modern Infra with Storage Roadshow 2023 - Day 1Amazon Web Services Korea
 
사례로 알아보는 Database Migration Service : 데이터베이스 및 데이터 이관, 통합, 분리, 분석의 도구 - 발표자: ...
사례로 알아보는 Database Migration Service : 데이터베이스 및 데이터 이관, 통합, 분리, 분석의 도구 - 발표자: ...사례로 알아보는 Database Migration Service : 데이터베이스 및 데이터 이관, 통합, 분리, 분석의 도구 - 발표자: ...
사례로 알아보는 Database Migration Service : 데이터베이스 및 데이터 이관, 통합, 분리, 분석의 도구 - 발표자: ...Amazon Web Services Korea
 
Amazon DocumentDB - Architecture 및 Best Practice (Level 200) - 발표자: 장동훈, Sr. ...
Amazon DocumentDB - Architecture 및 Best Practice (Level 200) - 발표자: 장동훈, Sr. ...Amazon DocumentDB - Architecture 및 Best Practice (Level 200) - 발표자: 장동훈, Sr. ...
Amazon DocumentDB - Architecture 및 Best Practice (Level 200) - 발표자: 장동훈, Sr. ...Amazon Web Services Korea
 
Amazon Elasticache - Fully managed, Redis & Memcached Compatible Service (Lev...
Amazon Elasticache - Fully managed, Redis & Memcached Compatible Service (Lev...Amazon Elasticache - Fully managed, Redis & Memcached Compatible Service (Lev...
Amazon Elasticache - Fully managed, Redis & Memcached Compatible Service (Lev...Amazon Web Services Korea
 
Internal Architecture of Amazon Aurora (Level 400) - 발표자: 정달영, APAC RDS Speci...
Internal Architecture of Amazon Aurora (Level 400) - 발표자: 정달영, APAC RDS Speci...Internal Architecture of Amazon Aurora (Level 400) - 발표자: 정달영, APAC RDS Speci...
Internal Architecture of Amazon Aurora (Level 400) - 발표자: 정달영, APAC RDS Speci...Amazon Web Services Korea
 
[Keynote] 슬기로운 AWS 데이터베이스 선택하기 - 발표자: 강민석, Korea Database SA Manager, WWSO, A...
[Keynote] 슬기로운 AWS 데이터베이스 선택하기 - 발표자: 강민석, Korea Database SA Manager, WWSO, A...[Keynote] 슬기로운 AWS 데이터베이스 선택하기 - 발표자: 강민석, Korea Database SA Manager, WWSO, A...
[Keynote] 슬기로운 AWS 데이터베이스 선택하기 - 발표자: 강민석, Korea Database SA Manager, WWSO, A...Amazon Web Services Korea
 
Demystify Streaming on AWS - 발표자: 이종혁, Sr Analytics Specialist, WWSO, AWS :::...
Demystify Streaming on AWS - 발표자: 이종혁, Sr Analytics Specialist, WWSO, AWS :::...Demystify Streaming on AWS - 발표자: 이종혁, Sr Analytics Specialist, WWSO, AWS :::...
Demystify Streaming on AWS - 발표자: 이종혁, Sr Analytics Specialist, WWSO, AWS :::...Amazon Web Services Korea
 
Amazon EMR - Enhancements on Cost/Performance, Serverless - 발표자: 김기영, Sr Anal...
Amazon EMR - Enhancements on Cost/Performance, Serverless - 발표자: 김기영, Sr Anal...Amazon EMR - Enhancements on Cost/Performance, Serverless - 발표자: 김기영, Sr Anal...
Amazon EMR - Enhancements on Cost/Performance, Serverless - 발표자: 김기영, Sr Anal...Amazon Web Services Korea
 
Amazon OpenSearch - Use Cases, Security/Observability, Serverless and Enhance...
Amazon OpenSearch - Use Cases, Security/Observability, Serverless and Enhance...Amazon OpenSearch - Use Cases, Security/Observability, Serverless and Enhance...
Amazon OpenSearch - Use Cases, Security/Observability, Serverless and Enhance...Amazon Web Services Korea
 
Enabling Agility with Data Governance - 발표자: 김성연, Analytics Specialist, WWSO,...
Enabling Agility with Data Governance - 발표자: 김성연, Analytics Specialist, WWSO,...Enabling Agility with Data Governance - 발표자: 김성연, Analytics Specialist, WWSO,...
Enabling Agility with Data Governance - 발표자: 김성연, Analytics Specialist, WWSO,...Amazon Web Services Korea
 
Amazon Redshift Deep Dive - Serverless, Streaming, ML, Auto Copy (New feature...
Amazon Redshift Deep Dive - Serverless, Streaming, ML, Auto Copy (New feature...Amazon Redshift Deep Dive - Serverless, Streaming, ML, Auto Copy (New feature...
Amazon Redshift Deep Dive - Serverless, Streaming, ML, Auto Copy (New feature...Amazon Web Services Korea
 
From Insights to Action, How to build and maintain a Data Driven Organization...
From Insights to Action, How to build and maintain a Data Driven Organization...From Insights to Action, How to build and maintain a Data Driven Organization...
From Insights to Action, How to build and maintain a Data Driven Organization...Amazon Web Services Korea
 
Amazon DynamoDB - Use Cases and Cost Optimization - 발표자: 이혁, DynamoDB Special...
Amazon DynamoDB - Use Cases and Cost Optimization - 발표자: 이혁, DynamoDB Special...Amazon DynamoDB - Use Cases and Cost Optimization - 발표자: 이혁, DynamoDB Special...
Amazon DynamoDB - Use Cases and Cost Optimization - 발표자: 이혁, DynamoDB Special...Amazon Web Services Korea
 
LG전자 - Amazon Aurora 및 RDS 블루/그린 배포를 이용한 데이터베이스 업그레이드 안정성 확보 - 발표자: 이은경 책임, L...
LG전자 - Amazon Aurora 및 RDS 블루/그린 배포를 이용한 데이터베이스 업그레이드 안정성 확보 - 발표자: 이은경 책임, L...LG전자 - Amazon Aurora 및 RDS 블루/그린 배포를 이용한 데이터베이스 업그레이드 안정성 확보 - 발표자: 이은경 책임, L...
LG전자 - Amazon Aurora 및 RDS 블루/그린 배포를 이용한 데이터베이스 업그레이드 안정성 확보 - 발표자: 이은경 책임, L...Amazon Web Services Korea
 
KB국민카드 - 클라우드 기반 분석 플랫폼 혁신 여정 - 발표자: 박창용 과장, 데이터전략본부, AI혁신부, KB카드│강병억, Soluti...
KB국민카드 - 클라우드 기반 분석 플랫폼 혁신 여정 - 발표자: 박창용 과장, 데이터전략본부, AI혁신부, KB카드│강병억, Soluti...KB국민카드 - 클라우드 기반 분석 플랫폼 혁신 여정 - 발표자: 박창용 과장, 데이터전략본부, AI혁신부, KB카드│강병억, Soluti...
KB국민카드 - 클라우드 기반 분석 플랫폼 혁신 여정 - 발표자: 박창용 과장, 데이터전략본부, AI혁신부, KB카드│강병억, Soluti...Amazon Web Services Korea
 
SK Telecom - 망관리 프로젝트 TANGO의 오픈소스 데이터베이스 전환 여정 - 발표자 : 박승전, Project Manager, ...
SK Telecom - 망관리 프로젝트 TANGO의 오픈소스 데이터베이스 전환 여정 - 발표자 : 박승전, Project Manager, ...SK Telecom - 망관리 프로젝트 TANGO의 오픈소스 데이터베이스 전환 여정 - 발표자 : 박승전, Project Manager, ...
SK Telecom - 망관리 프로젝트 TANGO의 오픈소스 데이터베이스 전환 여정 - 발표자 : 박승전, Project Manager, ...Amazon Web Services Korea
 
코리안리 - 데이터 분석 플랫폼 구축 여정, 그 시작과 과제 - 발표자: 김석기 그룹장, 데이터비즈니스센터, 메가존클라우드 ::: AWS ...
코리안리 - 데이터 분석 플랫폼 구축 여정, 그 시작과 과제 - 발표자: 김석기 그룹장, 데이터비즈니스센터, 메가존클라우드 ::: AWS ...코리안리 - 데이터 분석 플랫폼 구축 여정, 그 시작과 과제 - 발표자: 김석기 그룹장, 데이터비즈니스센터, 메가존클라우드 ::: AWS ...
코리안리 - 데이터 분석 플랫폼 구축 여정, 그 시작과 과제 - 발표자: 김석기 그룹장, 데이터비즈니스센터, 메가존클라우드 ::: AWS ...Amazon Web Services Korea
 
LG 이노텍 - Amazon Redshift Serverless를 활용한 데이터 분석 플랫폼 혁신 과정 - 발표자: 유재상 선임, LG이노...
LG 이노텍 - Amazon Redshift Serverless를 활용한 데이터 분석 플랫폼 혁신 과정 - 발표자: 유재상 선임, LG이노...LG 이노텍 - Amazon Redshift Serverless를 활용한 데이터 분석 플랫폼 혁신 과정 - 발표자: 유재상 선임, LG이노...
LG 이노텍 - Amazon Redshift Serverless를 활용한 데이터 분석 플랫폼 혁신 과정 - 발표자: 유재상 선임, LG이노...Amazon Web Services Korea
 
AWS Summit Seoul 2023 | Amazon Neptune 및 Elastic을 이용한 추천 서비스 및 검색 플랫폼 구축하기
AWS Summit Seoul 2023 | Amazon Neptune 및 Elastic을 이용한 추천 서비스 및 검색 플랫폼 구축하기AWS Summit Seoul 2023 | Amazon Neptune 및 Elastic을 이용한 추천 서비스 및 검색 플랫폼 구축하기
AWS Summit Seoul 2023 | Amazon Neptune 및 Elastic을 이용한 추천 서비스 및 검색 플랫폼 구축하기Amazon Web Services Korea
 

Plus de Amazon Web Services Korea (20)

AWS Modern Infra with Storage Roadshow 2023 - Day 2
AWS Modern Infra with Storage Roadshow 2023 - Day 2AWS Modern Infra with Storage Roadshow 2023 - Day 2
AWS Modern Infra with Storage Roadshow 2023 - Day 2
 
AWS Modern Infra with Storage Roadshow 2023 - Day 1
AWS Modern Infra with Storage Roadshow 2023 - Day 1AWS Modern Infra with Storage Roadshow 2023 - Day 1
AWS Modern Infra with Storage Roadshow 2023 - Day 1
 
사례로 알아보는 Database Migration Service : 데이터베이스 및 데이터 이관, 통합, 분리, 분석의 도구 - 발표자: ...
사례로 알아보는 Database Migration Service : 데이터베이스 및 데이터 이관, 통합, 분리, 분석의 도구 - 발표자: ...사례로 알아보는 Database Migration Service : 데이터베이스 및 데이터 이관, 통합, 분리, 분석의 도구 - 발표자: ...
사례로 알아보는 Database Migration Service : 데이터베이스 및 데이터 이관, 통합, 분리, 분석의 도구 - 발표자: ...
 
Amazon DocumentDB - Architecture 및 Best Practice (Level 200) - 발표자: 장동훈, Sr. ...
Amazon DocumentDB - Architecture 및 Best Practice (Level 200) - 발표자: 장동훈, Sr. ...Amazon DocumentDB - Architecture 및 Best Practice (Level 200) - 발표자: 장동훈, Sr. ...
Amazon DocumentDB - Architecture 및 Best Practice (Level 200) - 발표자: 장동훈, Sr. ...
 
Amazon Elasticache - Fully managed, Redis & Memcached Compatible Service (Lev...
Amazon Elasticache - Fully managed, Redis & Memcached Compatible Service (Lev...Amazon Elasticache - Fully managed, Redis & Memcached Compatible Service (Lev...
Amazon Elasticache - Fully managed, Redis & Memcached Compatible Service (Lev...
 
Internal Architecture of Amazon Aurora (Level 400) - 발표자: 정달영, APAC RDS Speci...
Internal Architecture of Amazon Aurora (Level 400) - 발표자: 정달영, APAC RDS Speci...Internal Architecture of Amazon Aurora (Level 400) - 발표자: 정달영, APAC RDS Speci...
Internal Architecture of Amazon Aurora (Level 400) - 발표자: 정달영, APAC RDS Speci...
 
[Keynote] 슬기로운 AWS 데이터베이스 선택하기 - 발표자: 강민석, Korea Database SA Manager, WWSO, A...
[Keynote] 슬기로운 AWS 데이터베이스 선택하기 - 발표자: 강민석, Korea Database SA Manager, WWSO, A...[Keynote] 슬기로운 AWS 데이터베이스 선택하기 - 발표자: 강민석, Korea Database SA Manager, WWSO, A...
[Keynote] 슬기로운 AWS 데이터베이스 선택하기 - 발표자: 강민석, Korea Database SA Manager, WWSO, A...
 
Demystify Streaming on AWS - 발표자: 이종혁, Sr Analytics Specialist, WWSO, AWS :::...
Demystify Streaming on AWS - 발표자: 이종혁, Sr Analytics Specialist, WWSO, AWS :::...Demystify Streaming on AWS - 발표자: 이종혁, Sr Analytics Specialist, WWSO, AWS :::...
Demystify Streaming on AWS - 발표자: 이종혁, Sr Analytics Specialist, WWSO, AWS :::...
 
Amazon EMR - Enhancements on Cost/Performance, Serverless - 발표자: 김기영, Sr Anal...
Amazon EMR - Enhancements on Cost/Performance, Serverless - 발표자: 김기영, Sr Anal...Amazon EMR - Enhancements on Cost/Performance, Serverless - 발표자: 김기영, Sr Anal...
Amazon EMR - Enhancements on Cost/Performance, Serverless - 발표자: 김기영, Sr Anal...
 
Amazon OpenSearch - Use Cases, Security/Observability, Serverless and Enhance...
Amazon OpenSearch - Use Cases, Security/Observability, Serverless and Enhance...Amazon OpenSearch - Use Cases, Security/Observability, Serverless and Enhance...
Amazon OpenSearch - Use Cases, Security/Observability, Serverless and Enhance...
 
Enabling Agility with Data Governance - 발표자: 김성연, Analytics Specialist, WWSO,...
Enabling Agility with Data Governance - 발표자: 김성연, Analytics Specialist, WWSO,...Enabling Agility with Data Governance - 발표자: 김성연, Analytics Specialist, WWSO,...
Enabling Agility with Data Governance - 발표자: 김성연, Analytics Specialist, WWSO,...
 
Amazon Redshift Deep Dive - Serverless, Streaming, ML, Auto Copy (New feature...
Amazon Redshift Deep Dive - Serverless, Streaming, ML, Auto Copy (New feature...Amazon Redshift Deep Dive - Serverless, Streaming, ML, Auto Copy (New feature...
Amazon Redshift Deep Dive - Serverless, Streaming, ML, Auto Copy (New feature...
 
From Insights to Action, How to build and maintain a Data Driven Organization...
From Insights to Action, How to build and maintain a Data Driven Organization...From Insights to Action, How to build and maintain a Data Driven Organization...
From Insights to Action, How to build and maintain a Data Driven Organization...
 
Amazon DynamoDB - Use Cases and Cost Optimization - 발표자: 이혁, DynamoDB Special...
Amazon DynamoDB - Use Cases and Cost Optimization - 발표자: 이혁, DynamoDB Special...Amazon DynamoDB - Use Cases and Cost Optimization - 발표자: 이혁, DynamoDB Special...
Amazon DynamoDB - Use Cases and Cost Optimization - 발표자: 이혁, DynamoDB Special...
 
LG전자 - Amazon Aurora 및 RDS 블루/그린 배포를 이용한 데이터베이스 업그레이드 안정성 확보 - 발표자: 이은경 책임, L...
LG전자 - Amazon Aurora 및 RDS 블루/그린 배포를 이용한 데이터베이스 업그레이드 안정성 확보 - 발표자: 이은경 책임, L...LG전자 - Amazon Aurora 및 RDS 블루/그린 배포를 이용한 데이터베이스 업그레이드 안정성 확보 - 발표자: 이은경 책임, L...
LG전자 - Amazon Aurora 및 RDS 블루/그린 배포를 이용한 데이터베이스 업그레이드 안정성 확보 - 발표자: 이은경 책임, L...
 
KB국민카드 - 클라우드 기반 분석 플랫폼 혁신 여정 - 발표자: 박창용 과장, 데이터전략본부, AI혁신부, KB카드│강병억, Soluti...
KB국민카드 - 클라우드 기반 분석 플랫폼 혁신 여정 - 발표자: 박창용 과장, 데이터전략본부, AI혁신부, KB카드│강병억, Soluti...KB국민카드 - 클라우드 기반 분석 플랫폼 혁신 여정 - 발표자: 박창용 과장, 데이터전략본부, AI혁신부, KB카드│강병억, Soluti...
KB국민카드 - 클라우드 기반 분석 플랫폼 혁신 여정 - 발표자: 박창용 과장, 데이터전략본부, AI혁신부, KB카드│강병억, Soluti...
 
SK Telecom - 망관리 프로젝트 TANGO의 오픈소스 데이터베이스 전환 여정 - 발표자 : 박승전, Project Manager, ...
SK Telecom - 망관리 프로젝트 TANGO의 오픈소스 데이터베이스 전환 여정 - 발표자 : 박승전, Project Manager, ...SK Telecom - 망관리 프로젝트 TANGO의 오픈소스 데이터베이스 전환 여정 - 발표자 : 박승전, Project Manager, ...
SK Telecom - 망관리 프로젝트 TANGO의 오픈소스 데이터베이스 전환 여정 - 발표자 : 박승전, Project Manager, ...
 
코리안리 - 데이터 분석 플랫폼 구축 여정, 그 시작과 과제 - 발표자: 김석기 그룹장, 데이터비즈니스센터, 메가존클라우드 ::: AWS ...
코리안리 - 데이터 분석 플랫폼 구축 여정, 그 시작과 과제 - 발표자: 김석기 그룹장, 데이터비즈니스센터, 메가존클라우드 ::: AWS ...코리안리 - 데이터 분석 플랫폼 구축 여정, 그 시작과 과제 - 발표자: 김석기 그룹장, 데이터비즈니스센터, 메가존클라우드 ::: AWS ...
코리안리 - 데이터 분석 플랫폼 구축 여정, 그 시작과 과제 - 발표자: 김석기 그룹장, 데이터비즈니스센터, 메가존클라우드 ::: AWS ...
 
LG 이노텍 - Amazon Redshift Serverless를 활용한 데이터 분석 플랫폼 혁신 과정 - 발표자: 유재상 선임, LG이노...
LG 이노텍 - Amazon Redshift Serverless를 활용한 데이터 분석 플랫폼 혁신 과정 - 발표자: 유재상 선임, LG이노...LG 이노텍 - Amazon Redshift Serverless를 활용한 데이터 분석 플랫폼 혁신 과정 - 발표자: 유재상 선임, LG이노...
LG 이노텍 - Amazon Redshift Serverless를 활용한 데이터 분석 플랫폼 혁신 과정 - 발표자: 유재상 선임, LG이노...
 
AWS Summit Seoul 2023 | Amazon Neptune 및 Elastic을 이용한 추천 서비스 및 검색 플랫폼 구축하기
AWS Summit Seoul 2023 | Amazon Neptune 및 Elastic을 이용한 추천 서비스 및 검색 플랫폼 구축하기AWS Summit Seoul 2023 | Amazon Neptune 및 Elastic을 이용한 추천 서비스 및 검색 플랫폼 구축하기
AWS Summit Seoul 2023 | Amazon Neptune 및 Elastic을 이용한 추천 서비스 및 검색 플랫폼 구축하기
 

AWS 상에서 게임 서비스 최적화 방안 :: 박선용 :: AWS Summit Seoul 2016

  • 1. © 2016, Amazon Web Services, Inc. or its Affiliates. All rights reserved. 박선용 솔루션즈 아키텍트 2016/05/17 AWS 상에서 게임서비스 최적화 방안
  • 2. 오늘의 내용 1. 성능(Performance) 개론 2. 단일 리전 글로벌 게임 서비스 3. AWS상에서 시스템 최적화 4. 정리
  • 4. • 좋은 성능의 시스템을 설계하려면? • 2개의 중요 문제가 존재 성능의 문제 1. 성능에 대한 정의 2. 바른 성능 측정
  • 5. • 당신의 관점에 따라 성능이 무엇을 의미하는지가 달라진다: – 응답시간(Response time) – 출력량(Throughput) – 일관성(Consistency) 성능(Performance) 정의: 관점의 문제 Application System libraries System calls Kernel Devices Workload
  • 6. 성능 요소(Performance Factors) 리소스 성능 요소 주요 지표 CPU 소켓(Sockets), 코어 갯수(number of cores), clock frequency, bursting capability CPU utilization, run queue length 메모리Memory 메모리 용량(Memory capacity) Free memory, anonymous paging, thread swapping 네트워크 인터페이스 Max bandwidth, packet rate Receive throughput, transmit throughput over max bandwidth 디스크 IOPS(Input / output operations per second), 출력량(throughput) Wait queue length, device utilization, device errors
  • 7. 리소스 활용률(Utilization) • For given performance, how efficiently are resources being used • Something at 100% utilization can’t accept any more work • Low utilization can indicate more resource is being purchased than needed • 병목 == 시스템에서 최대 활용률을 나타내는 컴포넌트
  • 8. 성능 게임 성능 게임 : 같은 수치를 가지고 더 나은 성능치로 보이기 위한 기술적인 트릭 수십가지의 대표적인 기법들이 있다 Ratio 게임 시스템 워크로드 1 워크로드 2 A 10 20 B 20 10 측정값 시스템 워크로드 1 워크로드 2 평균값 A 10 20 15 B 20 10 15 평균값 비교 시스템 워크로드 1 워크로드 2 평균값 A 0.5 2 1.25 B 1 1 1 B 기준 처리량 비교 시스템 워크로드 1 워크로드 2 평균값 A 1 1 1 B 0.5 2 1.25 A 기준 처리량 비교
  • 9. 성능 측정 1. 관점의 선정 : 측정 단위(Metric)선정 - IOPS, 지연시간(ms), 출력량(MB/s), 활용도(%) 2. 대상의 선정 : 측정할 시스템의 올바른 준비 - 특정 병목(100% utilization) 으로 인한 왜곡이 없는 설정 3. 주체의 선정 : 적합한 워크로드의 선정 - 정확한 로드를 줄 수 있는 적합한 로드 제너레이터의 선정 - 충분한 로드가 가해질 수 있는 로드의 설계
  • 10. 측정의 일반적인 실수와 해결책 현명한 사람은 다른 사람의 실수로부터 배우고 어리석은 사람은 자신의 것으로부터 배운다 – H.G Well 1. 목표의 부재 or 편향된 목표 2. 비체계적인 접근 3. 부정확한 메트릭 4. 대표성 없는 워크로드 5. 잘못된 계산 기법 6. 부적합한 대상(시스템) 설정 7. 워크로드 생성기의 부적절한 선택
  • 11. 당부의 말씀 여기 나오는 모든 수치는 예시적인 것입니다. 퍼포먼스 측정은 모두 여러분이 직접 수행해야만 가치가 있습니다.
  • 12. 2. 단일 리전 글로벌 게임 서비스
  • 13. FAQ 1. 한 지역에서 게임서버를 두고 전 세계 서비스를 할 수 있는가? 2. 대전(對戰) 게임을 여러 대륙간의 사용자끼리 하게 할 수 있는가? 3. 지역간 DB 상호 복제가 가능한가? Global network 성능 관련 문제
  • 14. 지역별 평균 네트워크 지연 http://bit.ly/superdata-latency, See http://bit.ly/verizon-latency N.America 41.7ms Europe toAsia 137.9ms Asia Pacific 97.9ms Trans-Pacfic 103.8ms Trans-Atlantic 79.6ms LatinAmerica 133.2ms Europe 11.6ms Japan 16.8ms
  • 15. 추천 모범 사례 : 전 세계적인 매시형 구조로 서비스 하지 말고 지역별로 게임서버를 둘 것 ###+ms ###+ms ##+ms ###+ms
  • 16. 질문 : 하나의 지역에서 글로벌 서비스는 불가?
  • 17. 네트워크 성능 주요 성능 관점 응답시간(Response time) 일관성(Consistency) 고려 사항 라우팅 패스 패킷 손실률 = 패킷 재전송 측정도구 ping traceroute mtr iperf scp
  • 18. Latency의 중요성 - TCP 연결 Keep-Alive를 사용해야 SYN SYN-ACK ACK GET /index.jsp ACK SYN-ACK GET /index.jsp 2nd 요청 Region SYN 360ms 360ms 90ms
  • 19. 성능 테스트 § 비교 테스트 • 서울 (A 망사업자) à AWS China (베이징 리전의 EC2 인스턴스) • AWS 서울 à AWS China (베이징 리전의 EC2 인스턴스) § 테스트 종류 1.Traceroute : 라우팅 경로 확인 2. MTR : 라우팅 경로의 일관성 확인 3. Ping : 지연과 지연의 범위 확인 4. 데이터 전송 : 전송속도, 패킷 로스로 인한 패킷 재전송 횟수 측정. 워크로드에 필요한 전송크기. 여기서는 100KB § 중국과의 통신 (일반) 중국내 경로에 따른 인터넷 안정성 및 Great Firewall의 간섭으로 불특정하게 트래픽이 영향을 받은 것으로 알려져 있음
  • 20. Tracerout 비교 traceroute to 54.222.13x.xx (54.222.13x.xx), 128 hops max, 52 byte packets 1 [AS56220] 192.168.0.1 (192.168.0.1) 5.307 ms 1.238 ms 0.968 ms 6 [AS3786] 1.213.28.145 (1.213.28.145) 2.242 ms [AS3786] 1.213.28.49 (1.213.28.49) 2.174 ms 2.081 ms 7 [AS3786] 1.208.150.37 (1.208.150.37) 2.700 ms [AS3786] 210.120.248.237 (210.120.248.237) 3.014 ms [AS3786] 1.208.150.229 (1.208.150.229) 3.113 ms 8 [AS3786] 1.213.150.165 (1.213.150.165) 14.654 ms [AS55831] 1.208.104.149 (1.208.104.149) 6.444 ms [AS3786] 1.213.150.165 (1.213.150.165) 4.945 ms 10 [AS3786] 1.213.106.9 (1.213.106.9) 4.124 ms [AS3786] 1.208.148.105 (1.208.148.105) 3.917 ms [AS3786] 1.213.148.57 (1.213.148.57) 3.955 ms 13 [AS4134] 202.97.58.106 (202.97.58.106) 52.624 ms 51.554 ms LG DACOM [AS3786] 211.40.6.110 (211.40.6.110) 50.114 ms 14 [AS4134] 202.97.58.117 (202.97.58.117) 50.871 ms 54.061 ms 51.665 ms 15 [AS4134] 202.97.53.93 (202.97.53.93) 53.085 ms [AS4134] 202.97.58.117 (202.97.58.117) 52.425 ms [AS4134] 202.97.53.93 (202.97.53.93) 56.021 ms 16 China Telecom Backbone [AS4134] 202.97.53.93 (202.97.53.93) 54.102 ms 51.934 ms * 17 China Networks Inter-Exchange [AS4847] bj141-130- 93.bjtelecom.net (219.141.130.93) 52.357 ms * * A 망 à AWS China (예) traceroute to 54.222.13x.xx (54.222.13x.xx), 30 hops max, 60 byte packets 1 ec2-52-79-0-0.ap-northeast-2.compute.amazonaws.com (52.79.0.0) [AS16509] 20.145 ms 20.289 ms 20.346 ms 2 Cox Communication Inc. 100.64.1.8 (100.64.1.8) [AS22773] 16.820 ms 100.64.2.8 (100.64.2.8) [AS22773] 20.275 ms 100.64.2.136 (100.64.2.136) [AS22773] 13.769 ms 3 100.64.3.135 (100.64.3.135) [AS22773] 13.877 ms 100.64.2.195 (100.64.2.195) [AS22773] 15.923 ms 100.64.3.3 (100.64.3.3) [AS22773] 15.944 ms14 otejbb205.int- gw.kddi.ne.jp (203.181.99.69) [AS2516] 38.586 ms otejbb206.int-gw.kddi.ne.jp (59.128.4.249) [AS2516] 38.112 ms otejbb205.int-gw.kddi.ne.jp (59.128.4.101) [AS2516] 45.558 ms 15 tr-ote124.int-gw.kddi.ne.jp (106.187.6.198) [AS2516] 39.897 ms tr-ote124.int-gw.kddi.ne.jp (106.187.6.190) [AS2516] 39.156 ms tr-ote124.int-gw.kddi.ne.jp (106.187.6.194) [AS2516] 40.067 ms 16 203.181.102.42 (203.181.102.42) [AS2516] 151.869 ms * 152.305 ms 17 202.97.33.49 (202.97.33.49) [AS4134] 153.793 ms 202.97.35.237 (202.97.35.237) [AS4134] 152.355 ms 151.471 ms 18 * 202.97.33.125 (202.97.33.125) [AS4134] 153.458 ms 19 202.97.50.229 (202.97.50.229) [AS4134] 157.713 ms 202.97.35.153 (202.97.35.153) [AS4134] 209.974 ms 202.97.39.230 (202.97.39.230) [AS4134] 241.158 ms 20 202.97.34.189 (202.97.34.189) [AS4134] 184.304 ms * 202.97.34.133 (202.97.34.133) [AS4134] 227.440 ms AWS 서울 à AWS China (예)
  • 21. Mtr 비교 mtr --tcp -P 22 54.222.13x.xx--report -c 100 Start: Mon May 2 00:06:25 2016 HOST: 80e627e.ant Loss% Snt Last Avg Best Wrst StDev 1.|-- 172.20.nate.com 0.0% 100 1.8 3.0 1.7 27.3 2.7 2.|-- ??? 100.0 100 0.0 0.0 0.0 0.0 0.0 3.|-- 172.28.nate.com 0.0% 100 65.6 48.3 24.7 522.9 54.7 4.|-- ??? 100.0 100 0.0 0.0 0.0 0.0 0.0 5.|-- ??? 100.0 100 0.0 0.0 0.0 0.0 0.0 6.|-- 113.217.252.149 76.0% 100 30.4 57.1 29.0 354.1 68.2 7.|-- ??? 100.0 100 0.0 0.0 0.0 0.0 0.0 8.|-- 1.255.25.129 0.0% 100 48.4 51.7 27.9 374.7 44.8 9.|-- 39.115.132.141 0.0% 100 52.2 49.9 28.3 236.6 29.8 10.|-- 58.229.15.206 23.0% 100 71.3 84.1 62.2 262.1 28.5 11.|-- 202.97.121.169 0.0% 100 80.2 84.1 63.8 221.6 20.6 67.9 15.|-- ??? 100.0 99 0.0 0.0 0.0 0.0 0.0 16.|-- 98.31.110.36.static.bjtel 11.2% 98 146.0 147.5 123.6 571.6 48.6 17.|-- 54.222.1.11 2.1% 97 110.9 123.2 105.2 252.5 16.2 18.|-- 54.222.1.35 3.1% 97 116.7 120.5 101.8 198.0 12.9 A 망 à AWS China Loss 율이 변화하지 않는 것이 중요 mtr --tcp -P 22 54.222.137.37 --report -c 100 ST: ip-172-31-10-43 Loss% Snt Last Avg Best Wrst StDev 1.|-- ??? 100.0 100 0.0 0.0 0.0 0.0 0.0 4.|-- 100.64.17.225 0.0% 100 0.4 6.6 0.3 616.2 61.6 5.|-- 54.239.122.7 0.0% 100 1.1 6.7 0.7 577.6 57.7 10.|-- 54.239.53.11 0.0% 100 38.5 45.9 37.2 429.8 39.2 12.|-- 106.187.29.153 0.0% 100 39.8 44.2 37.8 342.3 31.2 13.|-- o205.int-gw.kddi.ne. 0.0% 100 42.8 48.4 37.3 458.9 49.9 14.|-- otejb.int-gw.kddi.ne. 0.0% 100 46.9 46.6 37.1 420.4 44.2 15.|-- 203.181.102.42 0.0% 100 41.2 58.0 37.0 381.8 52.1 16.|-- 203.181.102.42 24.0% 100 151.4 162.0 148.8 495.3 43.8 18.|-- 202.97.33.161 35.0% 100 161.5 210.6 149.8 3159. 373.3 19.|-- 202.97.33.25 3.0% 100 154.7 212.1 151.1 1222. 146.6 AWS 서울 à AWS China
  • 22. Ping & Scp 비교 ping -c 20 54.222.13x.xx PING 54.222.137.37 (54.222.137.37): 56 data bytes Request timeout for icmp_seq 0 64 bytes from 54.222.137.37: icmp_seq=1 ttl=46 time=151.090 ms Request timeout for icmp_seq 2 64 bytes from 54.222.137.37: icmp_seq=3 ttl=46 time=152.218 ms 64 bytes from 54.222.137.37: icmp_seq=4 ttl=46 time=151.107 ms 64 bytes from 54.222.137.37: icmp_seq=5 ttl=46 time=150.753 ms 64 bytes from 54.222.137.37: icmp_seq=6 ttl=46 time=152.004 ms Request timeout for icmp_seq 7 64 bytes from 54.222.137.37: icmp_seq=8 ttl=46 time=154.614 ms 64 bytes from 54.222.137.37: icmp_seq=9 ttl=46 time=154.078 ms Request timeout for icmp_seq 10 Request timeout for icmp_seq 11 A 망 à AWS China (ping) Transferred: sent 105672, received 2232 bytes, in 1.4 seconds Bytes per second: sent 76756.9, received 1621.3 tcp.analysis.retransmission : 1 AWS 서울 à AWS China (100KB, tcpdump) Transferred: sent 105672, received 2232 bytes, in 7.0 seconds Bytes per second: sent 15009.0, received 317.0 tcp.analysis.retransmission : 24 A 망 à AWS China (100KB, tcpdump)
  • 23. 비교 성능 결과 § Traceroute 결과 • 서울리전과 베이징 리전간 라우팅 경로가 훨씬 일관성이 있음 § Ping 수행 결과 • A망 à AWS China : 53 ~ 173 ms (라우팅 경로에 따라 ping 응답이 차이가 큼) • 서울리전 à AWS China : 107 ~ 108 ms (편차가 적음) § 데이터 전송(100KB) 결과 • A망 à AWS China : 7.0 초 / TCP 재전송 24회 • 서울리전 à AWS China : 1.4초 / TCP 재전송 1회
  • 24. Region Edge Location 12 Regions 33 Availability Zones 54 Edge Locations AWS optimized network Internet 다른 점
  • 25. Amazon S3 전송 가속 Embedded WAN acceleration S3 Bucket AWS Edge Location Uploader Optimized Throughput! 지리적으로 멀리 떨어진 곳으로의 이동 최대 300% (6x) 빠름 No firewall mods, no client software 54 글로벌 엣지 로케이션 엔드포인트를 바꾸면 되고, 코드를 바꿀 필요가 없다 New~
  • 27. Region Edge Location 12 Regions 32 Availability Zones 54 Edge Locations Need to update We’re here J CloudFront 동적 컨텐츠 글로벌 인프라
  • 28. Elastic Load Balancing Dynamic content Amazon EC2 Static content Amazon S3 * (default) /error/* /assets/* Amazon CloudFront example.com CloudFront 동적 컨텐츠 여러 오리진에 대한 설정
  • 29. CloudFront Customer Location www.mysite.com Path Pattern Matching /*.jpg; /*.php etc. GET http://mysite.com/images/1.jpg to ORIGIN A GET http://mysite.com/index.php to ORIGIN B GET http://mysite.com/web/home.css to ORIGIN C GET http://mysite.com/* (DEFAULT) to ORIGIN D Origin A: S3 bucket Origin B: www.mysite.com Origin C: S3 Bucket Origin D: www.mysite.com Path Pattern Matching /*.php /images/*.jpg /web/*.css /*.* (DEFAULT) CloudFront 동적 컨텐츠 CloudFront 동작
  • 30. DEMO!
  • 31. 버지니아 리전의 웹서버 성능 비교 웹서버 직접 호출 CF를 통한 호출 min mean median min mean median 1k 529 949 926 468 693 645 2k 588 1090 1173 481 701 699 4k 879 1158 1129 492 809 750 B망 à Us-east-1b : c4.large 단위 : ms 상대적인 값만 볼것. 이것은 패킷의 전달 속도만을 측정하는 것임. 측정하는 망이나 위치에 따라 값은 달라짐
  • 32. AWS Edge Location Client Optimized Path HTTP(s) 게임 Game Server US region HTTP(s)형 게임은 CloudFront 다이나믹 컨텐츠 지원 기능을 이용한다. 각 글로벌 엣지로부터 최적화된 네트워크 경로를 통해서 게임 서비스 리전으로 연결된다.
  • 33. AWS Region Client Optimized Path TCP 게임 US region TCP 형 게임은 클라이언트가 있는 곳의 AWS리전에 Proxy서버를 구축한다. 각 Proxy서버로부터 최적화된 네트워크 경로를 통해서 게임 서비스 리전으로 연결된다. Proxy
  • 34. 글로벌 one region 게임 서비스? § 성능관련 검증 내용 • 라우팅 경로 확인 • 지연시간 확인 • 지연시간의 편차 확인 • 일정 크기 파일 전송 확인 à 패킷 로스 및 재전송 확인 § 성능 검증 결론 • 최적화 된 인터넷 경로 • Keep-Alive § AWS 서비스 • HTTP(s) : AWS CloudFront 동적 컨텐츠 지원 • TCP : 지역별로 구현된 Proxy 서버 Spot과 AWS 각 리전 연결
  • 35. 글로벌 단일 리전 게임 설계시 다음을 고려하라 § 지연을 인정하라 • 전 세계 어느 지역에서든 500ms ~ 1s의 지연 허용 • 게임 종류에 따른 설계 반영 : 비동기, 버퍼링, eventually consistency (UDP) § 지원 가능한 인프라를 선택하라 • AWS : 각 리전, CloudFront, 리전 별 Proxy 구축 § 서비스 대상 범위를 지정하고 검증하라 • 지역의 선정 : 아시아, 유럽, 전 세계? • 각 로컬 네트워크 망의 사정 고려 및 테스트 • 지연이 심한 경우의 과감한 취사 선택 § 서버 아키텍처를 과감히 변경하라 • 서버 프로세싱을 최소화 : 네트워크가 지연시간의 대다수가 되도록 • 캐시, 메모리 DB, NoSQL 등으로 과감한 설계 구조 변경 • 게임 서버내의 성능 병목지점 제거
  • 37. • 인스턴스 유형을 선택하는 것이 리소스 성능 튜닝과 같은 효과를 가져옴 • 워크로드에 맞는 이상적인 인스턴스 유형을 찾는 것이 관건 AWS에서 컴퓨팅 퍼포먼스란? 인스턴스 선택 = 성능 튜닝
  • 38. 예: HTTP game application 시스템 콜
  • 39. 방안 1 : 게임 서버 설계시 시스템 call을 최소화하라 § 단일 쓰레드 vs 다중 쓰레드 • 같은 리소스에 경쟁적으로 접근 예) 파일, 소켓, 특정 메모리 등 § O/S Lock의 최소화 • 상호 경쟁적 접근 요청이 많을 수록 lock은 극단적으로 비싸짐. § 큐 활용의 제한 • 처리 로직 사이 이벤트 큐의 입출력이 전체 비용의 대다수를 차지 예) 비거나 차거나 à 경쟁관계나 cache coherence발생으로 높은 비용 요구 • O/S 락을 요구하지 않는 원형버퍼 등의 활용 § 기본 규칙 • 처리량을 위해서는 async call을, 지연 시간 절감을 위해서는 캐시, 메모리, NoSQL을
  • 40. X86 CPU 가상화: Prior to Intel VT-x • 특권 명령어에 대한 이진 변환 (Binary translation for privileged instructions) • 반가상화 (Para-virtualization) • PV는 VMM을 통과해야 하므로, 지연이 증가 • 시스템 콜을 해야하는 어플리케이션의 경우 더욱 영향을 받음 VMM Application Kernel PV
  • 41. X86 CPU Virtualization: After Intel VT-x • x86 프로세서는 포펙과 골드버그 가상화 요구를 만족하지 않았음 à 일반 가상머신을 추가하는 것이 어려웠음. • Hardware assisted virtualization (HVM) • PV-HVM 은 명령어가 느리게 에뮬레이트 되는 경우 선택적으로 PV 들이버를 사용한다: • e.g. network and block I/O Kernel Application VMM PV-HVM
  • 42. 방안 2 : EBS와 함께 PV-HVM AMIs 를 사용하라
  • 43. Review: C4 Instances Custom Intel E5-2666 v3 at 2.9 GHz P-state and C-state controls Model vCPU Memory (GiB) EBS (Mbps) c4.large 2 3.75 500 c4.xlarge 4 7.5 750 c4.2xlarge 8 15 1,000 c4.4xlarge 16 30 2,000 c4.8xlarge 36 60 4,000
  • 44. 방안 3 : 고급 벡터확장(AVX2)을 위한 P-state control 을 고려하라 • 만약 어플리케이션이 모든 코어에서 AVX2 오퍼레이션을 과도하게 요구하게 되면, 프로세서는 가진것 이상의 파워를 이끌어내려고 시도한다. • 프로세서는 투명하게 프리퀀시를 줄임 • CPU 프리퀀시의 변화는 어플리케이션을 느리게 할수 있다 • Visual Studio 2012에 AVX2 서포트 시작. /arch:AVX2 스위치 옵션이 VS 2012 Update 2부터 지원.
  • 45. I/O : Granting in pre-3.8.0 Kernels • Requires “grant mapping” prior to 3.8.0 • Grant mappings are expensive operations due to TLB flushes read(fd, buffer,…)
  • 46. I/O : Granting in 3.8.0+ Kernels, Persistent and Indirect • Grant mappings are setup in a pool once • Data is copied in and out of the grant pool read(fd, buffer…) Copy to and from grant pool
  • 47. 방안 4 : 3.8+ 커널 사용하라 • Amazon Linux 13.09 or later • Ubuntu 14.04 or later • RHEL7 or later • Etc.
  • 48. 디바이스 요청 : Enhanced Networking • SR-IOV 드라이버 도메인 단계를 제거 • 물리적인 네트워크 디바이스가 가상 함수를 인스턴스에 노출 • 특별한 드라이버 필요 : • 인스턴스의 OS 가 인식하고 있어야 함 • EC2가 인스턴스에 사용할 수 있음을 알려주어야 함
  • 49. Hardware After Enhanced Networking Driver Domain Guest Domain Guest Domain VMM Frontend driver NIC Driver Backend driver Device Driver Physical CPU Physical Memory SR-IOV Network Device Virtual CPU Virtual Memory CPU Scheduling Sockets Application
  • 50. Hardware After Enhanced Networking Driver Domain Guest Domain Guest Domain VMM Frontend driver NIC Driver Backend driver Device Driver Physical CPU Physical Memory SR-IOV Network Device Virtual CPU Virtual Memory CPU Scheduling Sockets Application
  • 51. Hardware After Enhanced Networking Driver Domain Guest Domain Guest Domain VMM Frontend driver NIC Driver Backend driver Device Driver Physical CPU Physical Memory SR-IOV Network Device Virtual CPU Virtual Memory CPU Scheduling Sockets Application
  • 52. 방안 5 : Enhanced Networking 사용하라 • 아주 높은 packets/second • 지연에 대한 편차가 매우 낮음 • 인스턴스의 OS가 지원해야 함 • 인스턴스나 이미지의 SR-IOV 프로퍼티 확인
  • 54. EBS란 무엇인가? • 서비스형 네트워크 블락 스토리지 • EBS 볼륨은 같은 가용존에 있는 어떠한 EC2 인스턴스에도 연결될 수 있음 • 99.999% (five nines) 가용성으로 설계 • 매일 2 백만 볼륨이 생성
  • 55. EBS volume types Magnetic General purpose (SSD) Provisioned IOPS (SSD) st1, sc1 gp2 io1
  • 56. EBS volume types Solid-State Drives (SSD) Hard disk Drives (HDD) 볼륨타입 General Purpose SSD (gp2) Provisioned IOPS SSD (io1) Throughput Optimized HDD (st1) Cold HDD (sc1) 볼륨 사이즈 1 GiB - 16 TiB 4 GiB - 16 TiB 500 GiB - 16 TiB 500 GiB - 16 TiB 최대 IOPS/볼륨 10,000 20,000 500 250 최대 Throughput/볼륨 160 MiB/s 320 MiB/s 500 MiB/s 250 MiB/s
  • 57. 성능 개선을 위한 핵심 컴포넌트 : 4개 EC2 instance I/O EBS Network link
  • 58. Workload/ software Typical block size Random/ Seq? Max EBS @ 500 MB/s instances Max EBS @ 1 GB/s instances Max EBS @ 10 GB/s instances Oracle DB Configurable:2 KB –16 KB Default 8 KB random ~7,800 IOPS ~15,600 IOPS ~48,000 IOPS Microsoft SQL Server 8 KB w/ 64 KB extents random ~7,800 IOPS ~15,600 IOPS ~48,000 IOPS MySQL 16 KB random ~4,000 IOPS ~7,800 IOPS ~48,000 IOPS PostgreSQL 8 KB random ~7,800 IOPS ~15,600 IOPS ~48,000 IOPS MongoDB 4 KB sequential ~15,600 IOPS ~31,000 IOPS ~48,000 IOPS Apache Cassandra 4 KB random ~15,600 IOPS ~31,000 IOPS ~48,000 IOPS GlusterFS 128 KB sequential ~500 IOPS ~1,000 IOPS ~6,000 IOPS 참조 테이블 : AWS 상에서 예제 워크로드 표
  • 59. 예제 워크로드 트랜젝션 (OLTP) 예 : 스토어 website, 아이템 거래, 게임 메타 데이터 저장 벤치마크 : MySQL + sysbench 성능 개선을 위한 부분(컴포넌트) 및 병목지점 확인
  • 60. 최초 테스트 사양 가용존 : US West (Oregon) 인스턴스 타입 : m2.4xlarge vCPU: 8 Memory: 68.4GiB EBS-optimized 데이터 볼륨 : 500GiB EBS magnetic OS: Amazon Linux 2015.03.1 CPU: Intel Xeon
  • 61. 병렬처리 확장성 테스트 - 쓰레드 수를 늘림 MySQL threads Transactions(n) Baseline 2 n
  • 62. EBS 최적화 인스턴스 • 대부분의 인스턴스 패밀리가 EBS-optimized 플래그를 지원 • EBS-optimized instances now support up to 4 Gb/s • Drive 32,000 16K IOPS or 500 MB/s • Available by default on newer instance types • EC2 *.8xlarge 는 10 Gb/s 네트워크 지원 • 노드 당 지원되는 최대 IOPS 는 ~48,000 IOPS @ 16K I/O
  • 63. 인스턴스 변경 가용 존: US West (Oregon) 인스턴스 타입: r3.2xlarge vCPU: 8 Memory: 61 GiB EBS-optimized EBS volume: 500GiB magnetic OS: Amazon Linux 2015.03.1 CPU: Intel Xeon E5-2670 v2
  • 64. 25% EBS 최적화 & 최신 세대 인스턴스 MySQL threads Transactions(n) Baseline r3.2xlarge 2 n
  • 65. 볼륨 타입 선택 EBS magnetic 지연 : Read: 10-40ms Write: 2-10ms SSD backed 지연 : Read/Write: Single-digit ms
  • 67. 인스턴스 변경: EBS volumes Availability Zone: US West (Oregon) Instance type: r3.2xlarge vCPU: 8 Memory: 61 GiB EBS-optimized Boot volume: 8 GiB – EBS general purpose Data volume: 500 GiB – EBS general purpose OS: Amazon Linux 2015.03.1
  • 68. Optimization: Volume selection Transactions(n) 19% 50% MySQL threads Baseline r3.2xlarge r3.2xlarge gp2 2 n
  • 69. 방안 6 : EBS 성능 개선을 위해 최신 인스턴스와 옵션을 사용하라 워크로드 최적의 인스턴스를 선택하라 가급적 최신 세대 인스턴스를 사용하라 볼륨 퍼포먼스가 문제되면 SSD 볼륨 타입을 선정하라 작은 볼륨 사이즈에 높은 IOPS가 필요하면 io1 타입을 선택하라
  • 70. EBS IOPS vs. Throughput 20,000 IOPS PIOPS volume 20,000 IOPS 320 MB/s throughput You can achieve 20,000 IOPS when driving smaller I/O operations You can achieve up to 320 MB/s when driving larger I/O operations
  • 71. 스트라이핑 (Striping) Increases performance, or capacity, or both Don’t mix volume types Typically RAID 0 or LVM stripe Avoid RAID for redundancy EBS EC2
  • 72. EBS-optimized instance 4개 핵심 컴포넌트 : 균형(Balanced) = 고른 utilization EC2 A “boatload” of I/O Right-sized EBS
  • 73. 1. 게임 서버 설계시 시스템 call을 최소화하라 2. PV-HVM AMIs 를 사용하라 3. 고급 벡터확장(AVX2)을 위한 P-state control 을 고려하라 4. 3.8+ 커널 사용하라 5. Enhanced Networking 사용하라 6. EBS 성능 개선을 위해 최신의 인스턴스와 옵션을 사용하라 최적화 방안 정리