Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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

3,300 views

Published on

5월 17일 서울COEX에서 열린 AWS Summit Seoul 2016에서 박선용 솔루션즈 아키텍트 님이 발표하신 "AWS상에서 게임서비스 최적화 방안" 발표자료입니다.

Published in: Technology

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

  1. 1. © 2016, Amazon Web Services, Inc. or its Affiliates. All rights reserved. 박선용 솔루션즈 아키텍트 2016/05/17 AWS 상에서 게임서비스 최적화 방안
  2. 2. 오늘의 내용 1. 성능(Performance) 개론 2. 단일 리전 글로벌 게임 서비스 3. AWS상에서 시스템 최적화 4. 정리
  3. 3. 1. 성능(Performance) 개론
  4. 4. • 좋은 성능의 시스템을 설계하려면? • 2개의 중요 문제가 존재 성능의 문제 1. 성능에 대한 정의 2. 바른 성능 측정
  5. 5. • 당신의 관점에 따라 성능이 무엇을 의미하는지가 달라진다: – 응답시간(Response time) – 출력량(Throughput) – 일관성(Consistency) 성능(Performance) 정의: 관점의 문제 Application System libraries System calls Kernel Devices Workload
  6. 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. 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. 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. 9. 성능 측정 1. 관점의 선정 : 측정 단위(Metric)선정 - IOPS, 지연시간(ms), 출력량(MB/s), 활용도(%) 2. 대상의 선정 : 측정할 시스템의 올바른 준비 - 특정 병목(100% utilization) 으로 인한 왜곡이 없는 설정 3. 주체의 선정 : 적합한 워크로드의 선정 - 정확한 로드를 줄 수 있는 적합한 로드 제너레이터의 선정 - 충분한 로드가 가해질 수 있는 로드의 설계
  10. 10. 측정의 일반적인 실수와 해결책 현명한 사람은 다른 사람의 실수로부터 배우고 어리석은 사람은 자신의 것으로부터 배운다 – H.G Well 1. 목표의 부재 or 편향된 목표 2. 비체계적인 접근 3. 부정확한 메트릭 4. 대표성 없는 워크로드 5. 잘못된 계산 기법 6. 부적합한 대상(시스템) 설정 7. 워크로드 생성기의 부적절한 선택
  11. 11. 당부의 말씀 여기 나오는 모든 수치는 예시적인 것입니다. 퍼포먼스 측정은 모두 여러분이 직접 수행해야만 가치가 있습니다.
  12. 12. 2. 단일 리전 글로벌 게임 서비스
  13. 13. FAQ 1. 한 지역에서 게임서버를 두고 전 세계 서비스를 할 수 있는가? 2. 대전(對戰) 게임을 여러 대륙간의 사용자끼리 하게 할 수 있는가? 3. 지역간 DB 상호 복제가 가능한가? Global network 성능 관련 문제
  14. 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. 15. 추천 모범 사례 : 전 세계적인 매시형 구조로 서비스 하지 말고 지역별로 게임서버를 둘 것 ###+ms ###+ms ##+ms ###+ms
  16. 16. 질문 : 하나의 지역에서 글로벌 서비스는 불가?
  17. 17. 네트워크 성능 주요 성능 관점 응답시간(Response time) 일관성(Consistency) 고려 사항 라우팅 패스 패킷 손실률 = 패킷 재전송 측정도구 ping traceroute mtr iperf scp
  18. 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. 19. 성능 테스트 § 비교 테스트 • 서울 (A 망사업자) à AWS China (베이징 리전의 EC2 인스턴스) • AWS 서울 à AWS China (베이징 리전의 EC2 인스턴스) § 테스트 종류 1.Traceroute : 라우팅 경로 확인 2. MTR : 라우팅 경로의 일관성 확인 3. Ping : 지연과 지연의 범위 확인 4. 데이터 전송 : 전송속도, 패킷 로스로 인한 패킷 재전송 횟수 측정. 워크로드에 필요한 전송크기. 여기서는 100KB § 중국과의 통신 (일반) 중국내 경로에 따른 인터넷 안정성 및 Great Firewall의 간섭으로 불특정하게 트래픽이 영향을 받은 것으로 알려져 있음
  20. 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. 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. 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. 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. 24. Region Edge Location 12 Regions 33 Availability Zones 54 Edge Locations AWS optimized network Internet 다른 점
  25. 25. Amazon S3 전송 가속 Embedded WAN acceleration S3 Bucket AWS Edge Location Uploader Optimized Throughput! 지리적으로 멀리 떨어진 곳으로의 이동 최대 300% (6x) 빠름 No firewall mods, no client software 54 글로벌 엣지 로케이션 엔드포인트를 바꾸면 되고, 코드를 바꿀 필요가 없다 New~
  26. 26. S3 전송 가속
  27. 27. Region Edge Location 12 Regions 32 Availability Zones 54 Edge Locations Need to update We’re here J CloudFront 동적 컨텐츠 글로벌 인프라
  28. 28. Elastic Load Balancing Dynamic content Amazon EC2 Static content Amazon S3 * (default) /error/* /assets/* Amazon CloudFront example.com CloudFront 동적 컨텐츠 여러 오리진에 대한 설정
  29. 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. 30. DEMO!
  31. 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. 32. AWS Edge Location Client Optimized Path HTTP(s) 게임 Game Server US region HTTP(s)형 게임은 CloudFront 다이나믹 컨텐츠 지원 기능을 이용한다. 각 글로벌 엣지로부터 최적화된 네트워크 경로를 통해서 게임 서비스 리전으로 연결된다.
  33. 33. AWS Region Client Optimized Path TCP 게임 US region TCP 형 게임은 클라이언트가 있는 곳의 AWS리전에 Proxy서버를 구축한다. 각 Proxy서버로부터 최적화된 네트워크 경로를 통해서 게임 서비스 리전으로 연결된다. Proxy
  34. 34. 글로벌 one region 게임 서비스? § 성능관련 검증 내용 • 라우팅 경로 확인 • 지연시간 확인 • 지연시간의 편차 확인 • 일정 크기 파일 전송 확인 à 패킷 로스 및 재전송 확인 § 성능 검증 결론 • 최적화 된 인터넷 경로 • Keep-Alive § AWS 서비스 • HTTP(s) : AWS CloudFront 동적 컨텐츠 지원 • TCP : 지역별로 구현된 Proxy 서버 Spot과 AWS 각 리전 연결
  35. 35. 글로벌 단일 리전 게임 설계시 다음을 고려하라 § 지연을 인정하라 • 전 세계 어느 지역에서든 500ms ~ 1s의 지연 허용 • 게임 종류에 따른 설계 반영 : 비동기, 버퍼링, eventually consistency (UDP) § 지원 가능한 인프라를 선택하라 • AWS : 각 리전, CloudFront, 리전 별 Proxy 구축 § 서비스 대상 범위를 지정하고 검증하라 • 지역의 선정 : 아시아, 유럽, 전 세계? • 각 로컬 네트워크 망의 사정 고려 및 테스트 • 지연이 심한 경우의 과감한 취사 선택 § 서버 아키텍처를 과감히 변경하라 • 서버 프로세싱을 최소화 : 네트워크가 지연시간의 대다수가 되도록 • 캐시, 메모리 DB, NoSQL 등으로 과감한 설계 구조 변경 • 게임 서버내의 성능 병목지점 제거
  36. 36. 3. AWS상에서 시스템 최적화
  37. 37. • 인스턴스 유형을 선택하는 것이 리소스 성능 튜닝과 같은 효과를 가져옴 • 워크로드에 맞는 이상적인 인스턴스 유형을 찾는 것이 관건 AWS에서 컴퓨팅 퍼포먼스란? 인스턴스 선택 = 성능 튜닝
  38. 38. 예: HTTP game application 시스템 콜
  39. 39. 방안 1 : 게임 서버 설계시 시스템 call을 최소화하라 § 단일 쓰레드 vs 다중 쓰레드 • 같은 리소스에 경쟁적으로 접근 예) 파일, 소켓, 특정 메모리 등 § O/S Lock의 최소화 • 상호 경쟁적 접근 요청이 많을 수록 lock은 극단적으로 비싸짐. § 큐 활용의 제한 • 처리 로직 사이 이벤트 큐의 입출력이 전체 비용의 대다수를 차지 예) 비거나 차거나 à 경쟁관계나 cache coherence발생으로 높은 비용 요구 • O/S 락을 요구하지 않는 원형버퍼 등의 활용 § 기본 규칙 • 처리량을 위해서는 async call을, 지연 시간 절감을 위해서는 캐시, 메모리, NoSQL을
  40. 40. X86 CPU 가상화: Prior to Intel VT-x • 특권 명령어에 대한 이진 변환 (Binary translation for privileged instructions) • 반가상화 (Para-virtualization) • PV는 VMM을 통과해야 하므로, 지연이 증가 • 시스템 콜을 해야하는 어플리케이션의 경우 더욱 영향을 받음 VMM Application Kernel PV
  41. 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. 42. 방안 2 : EBS와 함께 PV-HVM AMIs 를 사용하라
  43. 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. 44. 방안 3 : 고급 벡터확장(AVX2)을 위한 P-state control 을 고려하라 • 만약 어플리케이션이 모든 코어에서 AVX2 오퍼레이션을 과도하게 요구하게 되면, 프로세서는 가진것 이상의 파워를 이끌어내려고 시도한다. • 프로세서는 투명하게 프리퀀시를 줄임 • CPU 프리퀀시의 변화는 어플리케이션을 느리게 할수 있다 • Visual Studio 2012에 AVX2 서포트 시작. /arch:AVX2 스위치 옵션이 VS 2012 Update 2부터 지원.
  45. 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. 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. 47. 방안 4 : 3.8+ 커널 사용하라 • Amazon Linux 13.09 or later • Ubuntu 14.04 or later • RHEL7 or later • Etc.
  48. 48. 디바이스 요청 : Enhanced Networking • SR-IOV 드라이버 도메인 단계를 제거 • 물리적인 네트워크 디바이스가 가상 함수를 인스턴스에 노출 • 특별한 드라이버 필요 : • 인스턴스의 OS 가 인식하고 있어야 함 • EC2가 인스턴스에 사용할 수 있음을 알려주어야 함
  49. 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. 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. 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. 52. 방안 5 : Enhanced Networking 사용하라 • 아주 높은 packets/second • 지연에 대한 편차가 매우 낮음 • 인스턴스의 OS가 지원해야 함 • 인스턴스나 이미지의 SR-IOV 프로퍼티 확인
  53. 53. 5. EBS
  54. 54. EBS란 무엇인가? • 서비스형 네트워크 블락 스토리지 • EBS 볼륨은 같은 가용존에 있는 어떠한 EC2 인스턴스에도 연결될 수 있음 • 99.999% (five nines) 가용성으로 설계 • 매일 2 백만 볼륨이 생성
  55. 55. EBS volume types Magnetic General purpose (SSD) Provisioned IOPS (SSD) st1, sc1 gp2 io1
  56. 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. 57. 성능 개선을 위한 핵심 컴포넌트 : 4개 EC2 instance I/O EBS Network link
  58. 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. 59. 예제 워크로드 트랜젝션 (OLTP) 예 : 스토어 website, 아이템 거래, 게임 메타 데이터 저장 벤치마크 : MySQL + sysbench 성능 개선을 위한 부분(컴포넌트) 및 병목지점 확인
  60. 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. 61. 병렬처리 확장성 테스트 - 쓰레드 수를 늘림 MySQL threads Transactions(n) Baseline 2 n
  62. 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. 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. 64. 25% EBS 최적화 & 최신 세대 인스턴스 MySQL threads Transactions(n) Baseline r3.2xlarge 2 n
  65. 65. 볼륨 타입 선택 EBS magnetic 지연 : Read: 10-40ms Write: 2-10ms SSD backed 지연 : Read/Write: Single-digit ms
  66. 66. Pre-warming
  67. 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. 68. Optimization: Volume selection Transactions(n) 19% 50% MySQL threads Baseline r3.2xlarge r3.2xlarge gp2 2 n
  69. 69. 방안 6 : EBS 성능 개선을 위해 최신 인스턴스와 옵션을 사용하라 워크로드 최적의 인스턴스를 선택하라 가급적 최신 세대 인스턴스를 사용하라 볼륨 퍼포먼스가 문제되면 SSD 볼륨 타입을 선정하라 작은 볼륨 사이즈에 높은 IOPS가 필요하면 io1 타입을 선택하라
  70. 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. 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. 72. EBS-optimized instance 4개 핵심 컴포넌트 : 균형(Balanced) = 고른 utilization EC2 A “boatload” of I/O Right-sized EBS
  73. 73. 1. 게임 서버 설계시 시스템 call을 최소화하라 2. PV-HVM AMIs 를 사용하라 3. 고급 벡터확장(AVX2)을 위한 P-state control 을 고려하라 4. 3.8+ 커널 사용하라 5. Enhanced Networking 사용하라 6. EBS 성능 개선을 위해 최신의 인스턴스와 옵션을 사용하라 최적화 방안 정리

×