게임 서비스를 위한 AWS상의 고성능 SQL 데이터베이스 구성
게임 서비스 아키텍처에서 관계형 데이터베이스는 핵심 컴포넌트이며 또한 전체 서비스의 성능 병목 지점이 되곤 합니다. 이 세션에서는 AWS 상에서 게임 서비스를 구현할 때, 기존 물리환경에서의 DB 성능과 동일하거나 더 높은 성능을 얻을 수 있는 구성을 설명 드리며, MS SQL 구성의 성능 데모를 시연하고자 합니다.
[Keynote] Data Driven Organizations with AWS Data - 발표자: Agnes Panosian, Head...
게임 서비스를 위한 AWS상의 고성능 SQL 데이터베이스 구성 (이정훈 솔루션즈 아키텍트, AWS) :: Gaming on AWS 2018
1.
2. 게임 서비스를 위한 AWS상의
고성능 SQL 서버 구성
이정훈, Solutions Architect
3. 높은 초당 트랜잭션 처리 및 빠른 응답의 DBMS
무제한의 용량 및 성능을 제공하는 Amazon DynamoDB
- 초당 수 백 만개 요청 처리
- 수 백TB 용량 자동 확장
- 10ms 미만의 지연시간 보장
- DAX로 마이크로 초 단위로 감소
- 알렉사, Amazon.com 사이트, 아마존 주문처리센터(fulfillment center) 로 부터의 초당 최대
천이백구십만 요청을 처리하고 있습니다.
최고 수준의 가용성을 제공하는 관리형 DBMS – 99.999% SLA (Global Table 적용)
Global Table 기능으로 여러 리전 데이터의 자동 동기화
PITR (Point-in-time recovery) 가능한 온디맨드 및 지속적 백업 제공
4. 그러나, RDBMS가 필요한 경우가 있을 수 있습니다
새로운 것을 배우고 적용하기에는 시간이 부족하다 생각되는
경우
게임 개발을 급하게 진행하여 어떤 종류의 쿼리(특히
Aggregation 종류의 쿼리)가 추후 새롭게 요구될지 모르는
경우
강력한 트랜잭션 기반의 쿼리가 필요한 경우
5. AWS에서 RDBMS 고려 사항
구성 및 운영 관리
- 어떤 아키텍처로 구성할 것인가?
- 업데이트 및 모니터링은 어떤 방법으로?
- 직접 구현 할 것인가, 관리형 서비스를 사용할 것인가?
- 백업 및 스냅샷 관리
가용성 수준 관리
- 자동 또는 수동 페일 오버 (Failover)
- Availability Zone 사용여부
성능 관리
- 어떤 인스턴스 타입과 크기를 사용할 것인가?
- 어떤 스토리지 옵션을 선택할 것인가?
6. 최선의 답은 Amazon Aurora
하이엔드 상용 데이터베이스의
성능 과 가용성
오픈소스 데이터베이스의
비용효율성 과 간단함
MySQL, PostgreSQL와의 호환성
• OS 및 DB 엔진 보안 관리
• 암호화
• 고가용성 구성
• 백업 정책에 따른 백업 관리
• DBMS 배포
• OS 및 DB 엔진 업데이트
• 관리자 요청에 따른 스케일 업/다운
• 스토리지 볼륨 자동 확장
7. 하지만, Microsoft SQL Server 를 쓰고 있어요 …
다양한 이유로 …
- 오랜 동안 게임을 SQL Server 기반으로 개발해 와서 익숙한 플랫폼을
변경하고 싶지 않아요
- 우리 게임은 이미 SQL Server 기반으로 개발 완료 단계 또는 이미 운영
중인데요
Amazon RDS for SQL Server
- Amazon RDS 관리형 서비스의 장점을 SQL Server에서 그대로 사용
- 그러나, 아래의 추가 요건이 있는 경우, 다른 선택이 필요
o 더 다양한 사양의 인스턴스 타입과 크기, 스토리지 성능이 필요한 경우
o 우리 게임을 지원하기 위한 SQL Server의 추가 기능이 필요한 경우
o DBA가 모든 권한을 가지길 원하는 경우
8. EC2로 SQL Server 직접 구성 및 운영
구성 및 운영 관리
- 직접 구성하여야 하나 CloudFormation이나 AWS CLI, SDK로 자동화 배포
- 관리형 서비스인 RDS에 비해 인스턴스 운영 업무, DB 관리 업무 추가 수행 필요
가용성 수준 관리
- SQL Server가 지원하는 고가용성 기능 구현 (미러링, Always-on Availability Group)
- AWS의 특성 고려 (Availability Zone)
성능 관리
- 원하는 모든 인스턴스 타입/크기 선택 가능
- 읽기 복제본 등의 추가 확장 기능 사용 가능
- 원하는 성능의 스토리지 옵션 선택 가능
9. RDBMS의 병목: 스토리지 성능 극복 방안
Amazon EC2 인스턴스 스토어
- 인스턴스가 위치한 호스트에 물리적으로 연결된 블록 스토리지
- 인스턴스가 중지/종료, 또는 호스트 하드웨어 이슈로 호스트가 이동되는 경우, 데이터 보존
안됨 (재부팅 시에는 데이터 유지)
- 최신 세대는 NVMe (Non-Volatile Memory express) 타입의 SSD를 장착하여 낮은
지연속도와 높은 IOPS를 제공
인스턴스 타입 vCPU (CPU clock) Mem(GiB) 인스턴스 스토어
크기
c5d 2 ~ 72 (3.0 ~ 3.5 GHz) 4 ~ 144 50 ~ 900 GiB
m5d 2 ~ 96 (2.5 GHz) 8 ~ 384 75 GiB ~ 3.6 TiB
r5d 2 ~ 96 (~3.1 GHz) 16 ~ 768 75 GiB ~ 3.6 TiB
z1d 2 ~ 48 (~4.0 GHz) 16 ~ 384 75 GiB ~ 1.8 TiB
i3 2 ~ 72 (2.3 GHz) 15.25 ~ 512 475 GiB ~ 15.2 TiB
10. Demo: EBS vs. 인스턴스 스토어 성능 비교
N. Virginia 기준 비용 비교 (월간)
옵션 1. r5.12xlarge + io1(640GB, 32000 IOPS) 합계 $3550.65
• STD RI, 1yr, no upfront, monthly = $1,390.65
• 640GB x $0.125 = $80
• 32000 IOPS x $0.065 = $2,080
옵션 2. r5d.12xlarge 합계 $1,592.13
• STD RI, 1yr, no upfront, monthly = $1,592.13
11. 인스턴스 스토어를 사용한 SQL Server 고려 사항
Durability
- 최고 우선 고려 사항으로 SQL Server의 복제 기능 사용
- 미러링: 두벌 복제 (현재 유지 관리 모드 기능, 향후 SQL 서버에서 지원되지 안을 수 있음)
- Always-on Availability Group: 두벌 이상 최대 8벌 복제, Sync 또는 Async 조합 가능
가용성
- Durability와는 별도의 고려 사항으로 매뉴얼 또는 자동 선택
인스턴스 장애 복구
- 인스턴스의 호스트 이동 상황 발생 시, 데이터 새로 복제 및 복제 구성 신규 적용 필요
백업
- 데이터 복구 최후의 보루로 전체 백업 및 로그 백업 주기 / 위치
성능 병목
- vCPU, 메모리, 네트워크, 디스크, 페이지 경합, SQL 엔진
12. 추가 상세 고려 사항
선택 항목 안정성 위주 혼합형 고성능 위주 비고
볼륨 선택 모두 EBS 볼륨 데이터는 EBS, 로그는
인스턴스 스토어
모두 인스턴스 스토어
Placement Group Spread n/a Cluster 동일 리전에 인스턴스
배치 시
Availability zone 구성 복수 AZ 사용 3개 이상의 인스턴스를
단일/복수 AZ에 배포
단일 AZ 사용
SQL 인스턴스 개수 3개 이상 n/a 2개 SQL 서버 라이선스
사양 고려
복제 방식 Synchronous 단일AZ Synchronous/
복수AZ Asynchronous
Asynchronous
13. Architecture Sample – 비용 효율성 위주
SQL 서버의 스탠다드 라이선스
사용
• 2대 인스턴스 구성
• 복수 AZ 구성 권고
• 인스턴스간 Synchronous 복제
(EBS의 간헐적인 Latency Spike
영향 최소화) 또는
Asynchronous 복제 (더 높은
SQL 트랜잭션 처리)
• 인스턴스 스토어에 데이터 파일
및 로그 파일 구성
VPC
Availability zone 1 Availability zone 2
Private subnet Private subnet
EC2 ReplicaEC2 Active
Public subnet Public subnet
게임 서버
Synchronous
/ Asynchronous
14. Architecture Sample – 고성능 위주
SQL 서버 엔터프라이즈 라이선스
사용
• 3대 인스턴스 사용
• 동일 AZ에 Cluster Placement
Group으로 2대 인스턴스 배치
• 동일 AZ 인스턴스간 Synchronous
복제
• 다른 AZ에 추가 1대 인스턴스 배치
• 다른 AZ 인스턴스간
Asynchronous 복제
• 복제 인스턴스에서 데이터 및 로그
백업
VPC
Availability zone 1 Availability zone 2
Private subnet Private subnet
EC2 ReplicaEC2 Active
Public subnet Public subnet
게임 서버
Sync
EC2 Replica
Async
Cluster Placement Group
15. Architecture Sample – 데이터 안정성 위주
SQL 서버 엔터프라이즈
라이선스 사용
• 3대 이상 인스턴스 사용
• 데이터는 EBS 볼륨, 로그는
인스턴스 스토어에 배치
• 다수의 AZ에 인스턴스 배치
• 모든 인스턴스간
Synchronous 복제
• 복제 인스턴스에서 데이터
및 로그 백업
• 동일 AZ에 인스턴스 배치할
경우, Spread Placement
Group 사용
VPC
Availability zone1 Availability zone2
Private
subnet
Private
subnet
EC2 ReplicaEC2 Active
Public
subnet
Public subnet
게임 서버
Sync
Availability zone3
Private
subnet
EC2 Replica
Public subnet
syncEBS EBS EBS
17. Lessons Learned & Recommendations
SQL Server 버전 별 라이선스에 따른 제약 확인
- Always-on AG는 STD에서 Basic 기능으로만 제공하여 1개 DB의 2개 노드 복제만 제공
실수 방지 최소화 (최소화 권한: IAM Policy로 인스턴스 중지/제거 금지)
병목은 어디에서 발생 할 수 있는가?
- vCPU / 메모리 / 네트워크 / 스토리지 / 쿼리 / SQL Server 내부 엔진
- 네트워크 / 스토리지의 인프라 수준 병목 현상은 거의 발생하지 않음
- 하나의 로지컬 코어의 사용율이 유독 높을 경우, RSS 설정 변경 필요
- 복수 AZ 간의 Synchronous 복제
요구 사항에 따른 다양한 아키텍처 선택 가능
- 멀티 AZ 사용 권고
- Active Directory, AWS Managed Active Directory, 또는 AD 없는 구성
- 미러링 또는 Always-on AG / Log shipping 혼용
18. 인스턴스 장애 복구
다음의 두 가지 경우에 인스턴스는 호스트에서 제거되어 인스턴스 스토어
데이터 유지되지 않음
- 사용자의 인스턴스 중단/시작 (리부팅의 경우는 호스트 이동하지 않음)
- 호스트 내부의 디스크 손실 또는 호스트의 하드웨어 장애
인스턴스가 재 시작 될 경우, 데이터 복제 구성 및 데이터 복제 수행 되어야 함
인스턴스 복제 상태가 비정상인 경우, 데이터 내구성 수준이 약화되므로
신속한 복구가 필요하며 복구 자동화를 권고
- 인스턴스 이벤트 모니터링 (SYSTEM FAILURE)
- 이벤트 발생 시, AWS Systems Manager로 자동화 복구 수행
- 자동화 스크립트 내에서 데이터 복제 구성 및 데이터 복제 수행 완료 (데이터 크기에 따라
수 분에서 수십 분 소요)
19. Demo: 인스턴스 스토어 SQL Server
자동 장애 복구
SQL
AlwaysOn
AG
CloudWatch
Logs &
Alarm
AWS
System
Manager
Run
command
Lambda
FunctionAmazon
SNS Topic
20. 시작하기
AWS 클라우드의 SQL Server: Quick Start 레퍼런스 배포
Windows Server Failover Clustering(WSFC) 및 SQL Server Always
On 가용성 그룹 사용
https://docs.aws.amazon.com/ko_kr/quickstart/latest/sql/welcome.html
21. 세션 요약
성능이 필수 요구 사항인 경우, NoSQL 기반의 DynamoDB가 최적의 선택
RDBMS가 필요한 경우, Amazon Aurora가 AWS상에서 최적의 선택
Microsoft SQL Server가 필요한 경우, 관리형 서비스인 Amazon RDS for
SQL server를 사용
추가 성능 및 기능 요구 사항이 있는 경우, EC2 상에 SQL Server 구성
사용할 수 있음
추가 스토리지 성능 요구 사항 만족을 위해 인스턴스 스토어의 특성을
이해하고 프로덕션에 사용할 수 있음