더 높은 초당 패킷 처리 수와 더 낮은 지연 시간을 달성하기 위한 AWS 네트워킹 옵션 (이정훈 솔루션즈 아키텍트, AWS) :: Gami...Amazon Web Services Korea
더 높은 초당 패킷 처리 수와 더 낮은 지연 시간을 달성하기 위한 AWS 네트워킹 옵션
게임 서비스에서 네트워크 안정성과 성능은 게이머들의 경험에 핵심적인 역할을 합니다. 이 세션에서는 AWS에서 게임 서비스의 높은 PPS 요구 사항, 낮은 지연 속도, 안정된 연결 지속성을 달성할 수 있는 EC2, VPC, Direct Connect, Cloudfront등의 다양한 기능을 소개하고 데모를 통해 그 효과를 직접 보여 드리고자 합니다.
본 세션에서는 Amazon의 관리형 데이터베이스 서비스(RDS) 중 기존 상용데이터베이스의 5배 성능 및 1/10 가격으로도 확장성을 보장하는 Aurora에 대한 소개 및 사용법 그리고 기존의 DB에서의 마이그레이션 방법에 대해 소개해드립니다. 10월 리인벤트를 통해 동경 리전에 Aurora를 사용가능하게 되었습니다.
더 높은 초당 패킷 처리 수와 더 낮은 지연 시간을 달성하기 위한 AWS 네트워킹 옵션 (이정훈 솔루션즈 아키텍트, AWS) :: Gami...Amazon Web Services Korea
더 높은 초당 패킷 처리 수와 더 낮은 지연 시간을 달성하기 위한 AWS 네트워킹 옵션
게임 서비스에서 네트워크 안정성과 성능은 게이머들의 경험에 핵심적인 역할을 합니다. 이 세션에서는 AWS에서 게임 서비스의 높은 PPS 요구 사항, 낮은 지연 속도, 안정된 연결 지속성을 달성할 수 있는 EC2, VPC, Direct Connect, Cloudfront등의 다양한 기능을 소개하고 데모를 통해 그 효과를 직접 보여 드리고자 합니다.
본 세션에서는 Amazon의 관리형 데이터베이스 서비스(RDS) 중 기존 상용데이터베이스의 5배 성능 및 1/10 가격으로도 확장성을 보장하는 Aurora에 대한 소개 및 사용법 그리고 기존의 DB에서의 마이그레이션 방법에 대해 소개해드립니다. 10월 리인벤트를 통해 동경 리전에 Aurora를 사용가능하게 되었습니다.
게임 서비스를 위한 AWS상의 고성능 SQL 데이터베이스 구성 (이정훈 솔루션즈 아키텍트, AWS) :: Gaming on AWS 2018Amazon Web Services Korea
게임 서비스를 위한 AWS상의 고성능 SQL 데이터베이스 구성
게임 서비스 아키텍처에서 관계형 데이터베이스는 핵심 컴포넌트이며 또한 전체 서비스의 성능 병목 지점이 되곤 합니다. 이 세션에서는 AWS 상에서 게임 서비스를 구현할 때, 기존 물리환경에서의 DB 성능과 동일하거나 더 높은 성능을 얻을 수 있는 구성을 설명 드리며, MS SQL 구성의 성능 데모를 시연하고자 합니다.
게임 서비스를 위한 AWS상의 고성능 SQL 데이터베이스 구성 (이정훈 솔루션즈 아키텍트, AWS) :: Gaming on AWS 2018Amazon Web Services Korea
게임 서비스를 위한 AWS상의 고성능 SQL 데이터베이스 구성
게임 서비스 아키텍처에서 관계형 데이터베이스는 핵심 컴포넌트이며 또한 전체 서비스의 성능 병목 지점이 되곤 합니다. 이 세션에서는 AWS 상에서 게임 서비스를 구현할 때, 기존 물리환경에서의 DB 성능과 동일하거나 더 높은 성능을 얻을 수 있는 구성을 설명 드리며, MS SQL 구성의 성능 데모를 시연하고자 합니다.
Vectorized Processing in a Nutshell. (in Korean)
Presented by Hyoungjun Kim, Gruter CTO and Apache Tajo committer, at DeView 2014, Sep. 30 Seoul Korea.
NEOS는 높은 신뢰성이 요구되는 분야에 최적화된 국내 최초의 실시간 운영체제(RTOS) 소프트웨어입니다.
항공, 유도, 기동 등의 무기체계 뿐만 아니라 자동차, 의료기기, 철도, 전력 등 민수 분야의 다양한 기기에도 전용되어 신뢰성 및 안정성을 입증한 사례를 보유하고 있습니다.
1. 국내 기술로 개발된 최초의 국산 RTOS
2. 신뢰성( DO-178 Level A, GS인증, 제품 양산 1,000만+)
3. 시스템 특성에 최적화된 RTOS(빠른 부팅 및 포팅 가능)
- 문의: 한컴MDS IIoT개발실 neos@hancommds.com
Similar to AWS 상에서 게임 서비스 최적화 방안 :: 박선용 :: AWS Summit Seoul 2016 (20)
사례로 알아보는 Database Migration Service : 데이터베이스 및 데이터 이관, 통합, 분리, 분석의 도구 - 발표자: ...Amazon Web Services Korea
Database Migration Service(DMS)는 RDBMS 이외에도 다양한 데이터베이스 이관을 지원합니다. 실제 고객사 사례를 통해 DMS가 데이터베이스 이관, 통합, 분리를 수행하는 데 어떻게 활용되는지 알아보고, 동시에 데이터 분석을 위한 데이터 수집(Data Ingest)에도 어떤 역할을 하는지 살펴보겠습니다.
Amazon Elasticache - Fully managed, Redis & Memcached Compatible Service (Lev...Amazon Web Services Korea
Amazon ElastiCache는 Redis 및 MemCached와 호환되는 완전관리형 서비스로서 현대적 애플리케이션의 성능을 최적의 비용으로 실시간으로 개선해 줍니다. ElastiCache의 Best Practice를 통해 최적의 성능과 서비스 최적화 방법에 대해 알아봅니다.
Internal Architecture of Amazon Aurora (Level 400) - 발표자: 정달영, APAC RDS Speci...Amazon Web Services Korea
ccAmazon Aurora 데이터베이스는 클라우드용으로 구축된 관계형 데이터베이스입니다. Aurora는 상용 데이터베이스의 성능과 가용성, 그리고 오픈소스 데이터베이스의 단순성과 비용 효율성을 모두 제공합니다. 이 세션은 Aurora의 고급 사용자들을 위한 세션으로써 Aurora의 내부 구조와 성능 최적화에 대해 알아봅니다.
[Keynote] 슬기로운 AWS 데이터베이스 선택하기 - 발표자: 강민석, Korea Database SA Manager, WWSO, A...Amazon Web Services Korea
오랫동안 관계형 데이터베이스가 가장 많이 사용되었으며 거의 모든 애플리케이션에서 널리 사용되었습니다. 따라서 애플리케이션 아키텍처에서 데이터베이스를 선택하기가 더 쉬웠지만, 구축할 수 있는 애플리케이션의 유형이 제한적이었습니다. 관계형 데이터베이스는 스위스 군용 칼과 같아서 많은 일을 할 수 있지만 특정 업무에는 완벽하게 적합하지는 않습니다. 클라우드 컴퓨팅의 등장으로 경제적인 방식으로 더욱 탄력적이고 확장 가능한 애플리케이션을 구축할 수 있게 되면서 기술적으로 가능한 일이 달라졌습니다. 이러한 변화는 전용 데이터베이스의 부상으로 이어졌습니다. 개발자는 더 이상 기본 관계형 데이터베이스를 사용할 필요가 없습니다. 개발자는 애플리케이션의 요구 사항을 신중하게 고려하고 이러한 요구 사항에 맞는 데이터베이스를 선택할 수 있습니다.
Demystify Streaming on AWS - 발표자: 이종혁, Sr Analytics Specialist, WWSO, AWS :::...Amazon Web Services Korea
실시간 분석은 AWS 고객의 사용 사례가 점점 늘어나고 있습니다. 이 세션에 참여하여 스트리밍 데이터 기술이 어떻게 데이터를 즉시 분석하고, 시스템 간에 데이터를 실시간으로 이동하고, 실행 가능한 통찰력을 더 빠르게 얻을 수 있는지 알아보십시오. 일반적인 스트리밍 데이터 사용 사례, 비즈니스에서 실시간 분석을 쉽게 활성화하는 단계, AWS가 Amazon Kinesis와 같은 AWS 스트리밍 데이터 서비스를 사용하도록 지원하는 방법을 다룹니다.
Amazon EMR - Enhancements on Cost/Performance, Serverless - 발표자: 김기영, Sr Anal...Amazon Web Services Korea
Amazon EMR은 Apache Spark, Hive, Presto, Trino, HBase 및 Flink와 같은 오픈 소스 프레임워크를 사용하여 분석 애플리케이션을 쉽게 실행할 수 있는 관리형 서비스를 제공합니다. Spark 및 Presto용 Amazon EMR 런타임에는 오픈 소스 Apache Spark 및 Presto에 비해 두 배 이상의 성능 향상을 제공하는 최적화 기능이 포함되어 있습니다. Amazon EMR Serverless는 Amazon EMR의 새로운 배포 옵션이지만 데이터 엔지니어와 분석가는 클라우드에서 페타바이트 규모의 데이터 분석을 쉽고 비용 효율적으로 실행할 수 있습니다. 이 세션에 참여하여 개념, 설계 패턴, 라이브 데모를 사용하여 Amazon EMR/EMR 서버리스를 살펴보고 Spark 및 Hive 워크로드, Amazon EMR 스튜디오 및 Amazon SageMaker Studio와의 Amazon EMR 통합을 실행하는 것이 얼마나 쉬운지 알아보십시오.
Amazon OpenSearch - Use Cases, Security/Observability, Serverless and Enhance...Amazon Web Services Korea
로그 및 지표 데이터를 쉽게 가져오고, OpenSearch 검색 API를 사용하고, OpenSearch 대시보드를 사용하여 시각화를 구축하는 등 Amazon OpenSearch의 새로운 기능과 기능에 대해 자세히 알아보십시오. 애플리케이션 문제를 디버깅할 수 있는 OpenSearch의 Observability 기능에 대해 알아보세요. Amazon OpenSearch Service를 통해 인프라 관리에 대해 걱정하지 않고 검색 또는 모니터링 문제에 집중할 수 있는 방법을 알아보십시오.
Enabling Agility with Data Governance - 발표자: 김성연, Analytics Specialist, WWSO,...Amazon Web Services Korea
데이터 거버넌스는 전체 프로세스에서 데이터를 관리하여 데이터의 정확성과 완전성을 보장하고 필요한 사람들이 데이터에 액세스할 수 있도록 하는 프로세스입니다. 이 세션에 참여하여 AWS가 어떻게 분석 서비스 전반에서 데이터 준비 및 통합부터 데이터 액세스, 데이터 품질 및 메타데이터 관리에 이르기까지 포괄적인 데이터 거버넌스를 제공하는지 알아보십시오. AWS에서의 스트리밍에 대해 자세히 알아보십시오.
Amazon Redshift Deep Dive - Serverless, Streaming, ML, Auto Copy (New feature...Amazon Web Services Korea
이 세션에 참여하여 Amazon Redshift의 새로운 기능을 자세히 살펴보십시오. Amazon Data Sharing, Amazon Redshift Serverless, Redshift Streaming, Redshift ML 및 자동 복사 등에 대한 자세한 내용과 데모를 통해 Amazon Redshift의 새로운 기능을 알고 싶은 사용자에게 적합합니다.
From Insights to Action, How to build and maintain a Data Driven Organization...Amazon Web Services Korea
데이터는 혁신과 변혁의 토대입니다. 비즈니스 혁신을 이끄는 혁신은 특정 시점의 전략이나 솔루션이 아니라 성장을 위한 반복적이고 집단적인 계획입니다. 혁신에 이러한 접근 방식을 채택하는 기업은 전략과 비즈니스 문화에서 데이터를 기반으로 하는 경우가 많습니다. 이러한 접근 방식을 개발하려면 리더가 데이터를 조직의 자산처럼 취급하고 조직이 더 나은 비즈니스 성과를 위해 데이터를 활용할 수 있도록 권한을 부여해야 합니다. AWS와 Amazon이 어떻게 데이터와 분석을 활용하여 확장 가능한 비즈니스 효율성을 창출하고 고객의 가장 복잡한 문제를 해결하는 메커니즘을 개발했는지 알아보십시오.
[Keynote] Accelerating Business Outcomes with AWS Data - 발표자: Saeed Gharadagh...Amazon Web Services Korea
데이터는 최종 소비자의 성공에 초점을 맞춘 디지털 혁신에서 중추적인 역할을 하고 있습니다. 모든 기업들은 데이터를 자산으로 사용하여 사례 제공을 추진하고 까다로운 결과를 해결하고 있습니다. AWS 클라우드 기술과 분석 솔루션의 강력한 성능을 통해 고객은 혁신 여정을 가속화할 수 있습니다. 이 세션에서는 기업 고객들이 클라우드에서 데이터의 힘을 활용하여 혁신 목표를 달성하고 필요한 결과를 제공하는 방법에 대해 다룹니다.
LG전자 - Amazon Aurora 및 RDS 블루/그린 배포를 이용한 데이터베이스 업그레이드 안정성 확보 - 발표자: 이은경 책임, L...Amazon Web Services Korea
LG ThinQ는 LG전자의 가전제품과 서비스를 아우르는 플랫폼 브랜드로서 앱 하나로 간편한 컨트롤, 똑똑한 케어, 스마트한 쇼핑까지 한번에 가능한 플랫폼입니다. ThinQ 플랫폼은 글로벌 서비스로 제공되고 있어, 작업 시간을 최소화하고, 서비스의 영향을 최소화 할 필요가 있었습니다. 따라서 DB 버전 업그레이드 작업 시 애플리케이션 배포가 필요없는 Blue/Green Deployment 방식은 최선의 선택이 되었습니다.
KB국민카드 - 클라우드 기반 분석 플랫폼 혁신 여정 - 발표자: 박창용 과장, 데이터전략본부, AI혁신부, KB카드│강병억, Soluti...Amazon Web Services Korea
온프레미스 분석 플랫폼에는 자원 증설 비용, 자원 관리 비용, 신규 자원 도입 및 환경 설정의 리드타임 등 다양한 측면에서의 한계가 존재합니다. 이에 KB국민카드에서는 기존 분석 플랫폼의 한계를 극복함과 동시에 시너지를 낼 수 있는 클라우드 기반 분석 플랫폼을 설계 및 도입하였습니다. 본 사례 소개는 KB국민카드의 데이터 혁신 여정과 노하우를 소개합니다.
SK Telecom - 망관리 프로젝트 TANGO의 오픈소스 데이터베이스 전환 여정 - 발표자 : 박승전, Project Manager, ...Amazon Web Services Korea
SK Telecom의 망관리 프로젝트인 TANGO에서는 오라클을 기반으로 시스템을 구축하여 운영해 왔습니다. 하지만 늘어나는 사용자와 데이터로 인해 유연하고 비용 효율적인 인프라가 필요하게 되었고, 이에 클라우드 도입을 검토 및 실행에 옮기게 되었습니다. TANGO 프로젝트의 클라우드 도입을 위한 검토부터 준비, 실행 및 이를 통해 얻게 된 교훈과 향후 계획에 대해 소개합니다.
코리안리 - 데이터 분석 플랫폼 구축 여정, 그 시작과 과제 - 발표자: 김석기 그룹장, 데이터비즈니스센터, 메가존클라우드 ::: AWS ...Amazon Web Services Korea
2022년 코리안리는 핵심업무시스템(기간계/정보계 시스템)을 AWS 클라우드로 전환하는 사업과 AWS 클라우드 기반에서 손익분석을 위한 어플리케이션 구축 사업을 동시에 진행하고 있었습니다. 이에 따라 클라우드 전환 이후 시스템 간 상호운용성과 호환성을갖춘 데이터 분석 플랫폼 또한 필요하게 되었습니다. 코리안리 IT 환경에 적합한 플랫폼 선정을 위하여 AWS Native Analytics Platform, 3rd Party Analytics Platform (클라우데라, 데이터브릭스)과의 PoC를 진행하고, 최종적으로 AWS Native Analytics Platform 으로 확정하였습니다. 코리안리는 메가존클라우드와 함께 2022년 10월부터 4개월(구축 3개월, 안정화 및 교육 1개월) 동안 AWS 기반 데이터 분석 플랫폼을 구축하고 활용 범위를 지속적으로 확대하고 있습니다.
LG 이노텍 - Amazon Redshift Serverless를 활용한 데이터 분석 플랫폼 혁신 과정 - 발표자: 유재상 선임, LG이노...Amazon Web Services Korea
LG 이노텍은 세계 시장을 선도하는 글로벌 소재·부품기업으로, Amazon Redshift 을 데이터 분석 플랫폼의 핵심 서비스로 활용하고 있습니다.지속적인 데이터 증가와 업무 확대에 따른 유연한 아키텍처 개선의 필요성에 대처하기 위해, 2022년에 AWS 에서 발표된 Redshift Serverless 를 활용한, 비용 최적화된 아키텍처 개선 과정의 실사례를 엿볼수 있는 기회가 됩니다.
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 성능 개선을 위해 최신의 인스턴스와 옵션을 사용하라
최적화 방안 정리