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. 당부의 말씀
여기 나오는 모든 수치는 예시적인 것입니다.
퍼포먼스 측정은 모두 여러분이 직접 수행해야만 가치가 있습니다.
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
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 (예)
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회
25. Amazon S3 전송 가속
Embedded WAN acceleration
S3 Bucket
AWS Edge
Location
Uploader
Optimized
Throughput!
지리적으로 멀리 떨어진 곳으로의
이동
최대 300% (6x) 빠름
No firewall mods, no client software
54 글로벌 엣지 로케이션
엔드포인트를 바꾸면 되고, 코드를
바꿀 필요가 없다
New~
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 동작
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
상대적인 값만 볼것. 이것은 패킷의 전달 속도만을 측정하는 것임.
측정하는 망이나 위치에 따라 값은 달라짐
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 등으로 과감한 설계 구조 변경
• 게임 서버내의 성능 병목지점 제거
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
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 프로퍼티 확인
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
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
73. 1. 게임 서버 설계시 시스템 call을 최소화하라
2. PV-HVM AMIs 를 사용하라
3. 고급 벡터확장(AVX2)을 위한 P-state control 을 고려하라
4. 3.8+ 커널 사용하라
5. Enhanced Networking 사용하라
6. EBS 성능 개선을 위해 최신의 인스턴스와 옵션을 사용하라
최적화 방안 정리