11. 11
• Aurora의 Instance 생성 할 때, 기본 master 사용자를 설정하게 됨.
• 기본 master 사용자의 권한 확인.
• Aurora의 기본 master 사용자는 File, Create Tablespace, Proxy, Shutdown, Super 권한이 없음.
• Aurora에만 존재하는 “Load from s3” 권한 존재
Grant
데이터베이스 엔진 시스템 권한
Amazon Aurora CREATE, DROP, GRANT OPTION, REFERENCES, EVENT, ALTER, DELETE, INDEX, INSERT,
SELECT, UPDATE, CREATE TEMPORARY TABLES, LOCK TABLES, TRIGGER, CREATE VIEW,
SHOW VIEW, LOAD FROM S3, ALTER ROUTINE, CREATE ROUTINE, EXECUTE, CREATE
USER, PROCESS, SHOW DATABASES , RELOAD, REPLICATION CLIENT, REPLICATION
SLAVE
12. 12
• 이슈 : Instance 에 접속하여 set global <variable_name> 명령 사용 불가.
• 대안 : Instance에 적용되어있는 Cluster/Instance Parameter의 값 수정.
– Save Changes 버튼 클릭시, dynamic 변수는 즉시 적용.
– 여러 Instance에 동일한 parameter group이 적용 되어 있는 경우, 특정 server만 값 변경 불가.
Global Variables 수정
13. 13
• 이슈 : kill 명령으로 다른 계정에 속한 thread 강제종료 불가능.
• 대안 : CALL mysql.rds_kill(thread_id) 사용.
Other Connection Kill
14. 14
• 이슈 : max_connections 시스템 변수로 제어되는 연결 제한에 도달할 경우,
master 유저는 Super 권한이 없기 때문에 연결 불가능.
• 해결 : Instance Parameter Groups 에서 max_connections 의 값 수정 (online)
• max_connections 의 기본 설정 값.
Instnace class 에 따라 설정되며, 최대값은 16,000.
기본값 : log ( DBInstanceClassMemory / 8,187,281,408 ) * 1,000
Reference : http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/Aurora.Managing.html
예) db.r3.xlarge 인 경우 : log( (30.5 * 1,073,741,824) / 8,187,281,408 ) * 1,000 = 2,000
• Service 성격 및 Game Server Connection을 예측하여, 고정 값으로 지정하여 운영 중.
Maximum Connections
16. 16
• 자동 백업(Automated Backup)
• Amazon RDS에서 백업을 자동으로 생성.
• Aurora 생성 시 기본 1일 보관.
– 1~35일까지 가능
• 연속 및 증분 백업.
– 백업 보존 기간 안에서 시점 복원 가능.
• 백업 중에 성능 영향이 없음.
• 백업 파일 보관기간 2일로 운영 중.
Backup - Automated Backup
17. • 수동 스냅샷 (Snapshots)
• 사용자가 수동으로 생성.
• 백업 보관기간을 별도 지정하지 않음.
– Amazone RDS 표준 스토리지 비용 발생.
• 리전당 50개의 스냅샷 한도
– 자동 백업에 미포함
• Aurora cluster version Upgrade 또는 대규모 정기점검 작업 전, 수동 스냅샷 생성.
Backup - Snapshots
18. • 1) ‘Automated Backup’ 파일 또는 'Snapshot’ 파일로 DB Instance 복구.
• 2) 원본 Instance와 동일한 Parameter, Security Groups 로 수정.
• 3) 복구한 Instance를 Master로 투입할 경우, Route53 에서 복구한 Instance의 Endpoint 로 CNAME 변경.
– CNAME은 일종의 포워딩.
18
Restore
복구한 Instance의
Endpoint로 변경
원본 Instance의 Endpointgame server에서 바라보는 주소
19. 19
• 1) 복구할 Instance 에서 복구 가능 기간 확인.
– 현재 시간에서 5분 이내 ~ 자동 백업 보존기간 내에서 복구 가능.
예) 현재 2017-04-19 01:31 PM (UTC+9) 일 때,
• 2) 복구할 Instance의 Restore to Point in Time 메뉴를 선택 하고
원하는 시점으로 복구.
– 복구시점을 18시 9분 17초로 한다면, 18시 9분 16초까지 복구.
( 즉, < 개념으로 17초는 복구되지 않음 )
• 3) 복구한 Instance를 Master로 투입할 경우,
Route53 에서 복구한 Instance의 Endpoint 로 CNAME 변경.
Restore To Point In Time
20. • 배경 : 타게임에서 관리자의 실수로 전설 아이템 대량 지급 발생. 아이템 지급 이전으로 Rollback 필요.
• 이슈 : MySQL 의 경우 replication 을 위해 binary log 활성화 하여 운영 ⇒ 쿼리 발생 시점 확인 가능.
Aurora 의 경우 replication에 binary log를 사용하지 않기 때문에 binary log가 기본적으로 비활성화.
⇒ 쿼리 발생 시점 확인 불가능.
• 대안 : 논리 장애 발생시, 해당 쿼리를 찾을 수 있도록 Aurora 도 binary log 활성화 하여 운영 중
Restore To Point In Time의 Issue
Gateway Server
mysql empty database
binary
log
3) binary log를 가져와 drop
명령어가 실행된 시간 확인
gameDB (aurora)
gdb-01
(writer)
gdb-02
(reader)
gdb-03
(reader)
binary
log
1) binary log
활성화
2) 실수로 drop
명령어 실행
장애
발생
4) 시점 복원을 통해 drop 명령어
실행 이전 시간으로 rollback
22. 22
• Aurora binary log 보관 주기 설정.
– Auto Backup의 보관주기와 동일하게 2일로 설정.
Aurora Setting
23. 23
• Aurora 로 접근 가능한 Gateway Server 에 mysql을 설치.
• Aurora Instance 에 replication 계정 생성.
Find Query (1)
24. • Aurora에 있는 binary log 목록을 확인 후
• mysqlbinlog를 이용하여 aurora의 binary log 를 가져온다.
• 가져온 binary log에서 Error Query를 찾아, 실행된 시간을 확인한다.
Find Query (2-1).mysqlbinlog
service DB (Aurora) Gatewa Server
/usr1/mysql/5633/bin/mysqlbinlog -h
‘aurorahostname’ -u root -p --read-from-remote-
server --base64-output=decode-rows --verbose -
-verbose mysql-bin-changelog.027538 > mysql-
bin-changelog.027538.txt
25. • Aurora에 있는 binary log 목록을 확인 후
• Aurora 에 대해 slave 로 붙인 후 I/O thread 를 이용하여 binary log를 가져온다.
• 가져온 binary log에서 Error Query를 찾아, 실행된 시간을 확인한다.
Find Query (2-2).Replication
service DB (Aurora) Gatewa Server
27. 27
• Aurora에서 Failover 발생시 아래 중 하나로 장애조치.
1. 기존 Aurora Reader Replica 중 하나를 새 기본 Instance 로 승격 (둘 이상의 복제본 존재)
2. 새로운 기본 Instance를 생성.
• cluster의 가용성을 높이기 위해, 1개의 cluster에 3개 Instance 구성하여 운영 중.
• Active Master(writer)와 Standby Master(reader)를 각각 다른 zone에 생성.
• Instance failover 우선순위 설정.
– tier-[숫자]가 작을 수록 master로 승격될 우선순위가 높음.
Auto Failover
gdb-01
(writer)
priority : tier-0
gdb-02
(reader)
priority : tier-1
gdb-03
(reader)
priority : tier-2
zone : ap-northeast-1a zone : ap-northeast-1c
gamedb-cluster
28. 28
• 사용자가 수동으로 Failover 발생.
• Failover 시 priority 에 따라 Master(=Writer)가 결정됨.
• Instance에서 Failover 메뉴를 선택하여 진행.
Manual Failover
30. • 주기적으로 Amazon RDS는 Amazon RDS resources에 대한 유지 관리 작업을 수행.
• Maintenance는 대개 DB Instance 또는 DB Cluster의 운영체제(OS)에 대한 업그레이드를 포함.
– Required : 반드시 반영되어야 하는 Maintenance. 무기한으로 연기될 수 없으며,
연기할 경우 업데이트 수행되는 시간을 통보 받는다.
– Available : 그 이외의 업데이트. 무기한으로 연기할 수 있다.
• Maintenance 반영은 DB instance/DB Cluster에 짧은 시간 동안 offline을 요구함.
• Instance 설정에서 Auto Minor Version Upgrade “비활성화” 로 운영 중
RDS Maintenance
31. • RDS console 에서 Maintenance 확인
– ‘Required’ Maintenance의 경우 업데이트 날짜 확인 불가.
• AWS CLI 를 통해 Maintenance 확인
– ‘Required’ Maintenance의 경우, 업데이트 날짜가 픽스되면 아래와 같이 날짜가 확인가능.
RDS Maintenance 확인
$ aws --profile xxxxxx rds describe-pending-maintenance-actions --output text
PENDINGMAINTENANCEACTIONS
PENDINGMAINTENANCEACTIONDETAILS system-update 2016-11-24T01:00:00Z 2016-11-24T01:00:00Z Aurora 1.8.1 release.
PENDINGMAINTENANCEACTIONS
PENDINGMAINTENANCEACTIONDETAILS system-update 2016-11-24T01:00:00Z 2016-11-24T01:00:00Z Aurora 1.8.1 release.
PENDINGMAINTENANCEACTIONS
PENDINGMAINTENANCEACTIONDETAILS system-update 2016-11-24T01:00:00Z 2016-11-24T01:00:00Z Aurora 1.8.1 release.
PENDINGMAINTENANCEACTIONS
PENDINGMAINTENANCEACTIONDETAILS system-update 2016-11-24T01:00:00Z 2016-11-24T01:00:00Z Aurora 1.8.1 release.
32. 32
• 1) 점검 시작
• 2) 대상 instance 에 대한 snapshot 백업
• 3) Maintenance 를 적용 (약 10~15분 소요)
- Cluster 내 Instance 들이 하나씩 Upgrade 되며 Instance Restart 발생
• 4) 점검 종료
• 이슈1 : maintenance 작업이 “Required”의 경우,
적용일자에 강제 upgrade가 진행되기 때문에 운영 중 발생하지 않도록 일정 모니터링이 필요.
• 이슈2 : maintenance 작업임에도 불구하고 Instance Restart 에 따른 auto-failover 가 진행됨
상이한 Instance Type 으로 운영하는 환경에서는 maintenance 작업 후 용도별 Instance Type 이
맞게 설정되었는지 체크필요 (필요시 manual failover 진행해야 함)
Maintenance 적용.
35. 35
• Aurora에서 기본 제공하는 Monitoring.
• 운영체제(OS) 및 SQL 모니터링 데이터 제공.
• RDS는 Monitoring의 데이터를 1분 마다 CloudWatch에 자동 전송. ( CloudWatch의 Metrics 확인 )
RDS Monitoring
36. 36
• 운영체제(OS)에 대한 모니터링 제공.
– 프리 티어 초과하는 별도 비용 청구됨.
– 최근 한달까지의 데이터 제공.
• RDS Monitoring에서 제공하는 OS정보보다 더 상세한 정보를 제공.
Enhanced Monitoring
37. • Enhanced Monitoring은 데이터를 1분 마다 CloudWatch Logs에 자동 전송.
– Cloudwatch Log에서 JSON 형태로 데이터 제공.
– 사용자를 대신하여 RDS OS 정보를 CloudWatch Log에 전송 할 수 있는 IAM 역할 생성 필요.
IAM 역할에 AmazonRDSEnhancedMonitoringRole 정책 부여.
(Reference : http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/USER_Monitoring.OS.html )
• Enhanced Monitoring 활성화.
– Enable Enhanced Monitoring : Yes 로 선택
– Monitoring Role : 위에서 생성한 IAM 역할 선택.
Enhanced Monitoring
38. 38
• Enhanced Monitoring에서는 RDS monitoring에서 제공하는 OS 정보보다 더 세분화된 데이터를 제공.
– CPU, 메모리, 파일시스템 및 디스크 I/O 등
RDS Monitoring과 Enhanced Monitoring
RDS 의 CPU 지표 Enhanced의 CPU 지표
39. 39
• 오래된 데이터는 monitoring 불가능.
Aurora Monitoring
AWS
CloudWatch
Metrics
Logs
Events
RDS monitoring Enhanced monitoring
최근 1 달의 데이터 monitoring최근 2주의 데이터 monitoring
Logs
RDS Dashboard
40. 40
• Cacti 모니터링을 연동하여, monitoring 가능하도록 구축
(Reference : https://www.percona.com/doc/percona-monitoring-plugins/1.1/cacti/rds-templates.html )
Aurora Monitoring
AWS
CloudWatch
Metrics Logs Alarms
RDS
Event Subscriptions
RDS monitoring
Enhanced monitoring
IDC
server
Cacti
Collection Thread
Cacti Web server
2주/1달 이후의 데이터도
monitoring 가능
41. 41
Aurora Alert
AWS
Metrics Logs Alarms
Event
Subscriptions
Event 발생시 Email로 Alert 발송
RDS Dashboard CloudWatch
지정한 임계 값에 도달할 경우 Alert 발송.
43. • Cloudwatch의 Metrics 데이터를 모니터링하여 Alarm 설정.
– 지정한 임계 값에 도달하고, 지정한 기간 동안 유지가 된다면 알람 발송.
CloudWatch의 Alarms
44. 44
• 기본 Email 이외에 다른 platform으로 Alter을 받으려면 별도의 연동 필요.
• CloudWatch Alarms의 경우, UI 및 관리가 불편하여 사용하고 있지 않음.
Aurora Alert
AWS
Metrics Logs Alarms
Event
Subscriptions
Event 발생시 Email로 Alert 발송
RDS Dashboard CloudWatch
UI 및 관리가 불편하여 사용하지 않음
45. 45
• Python용 AWS SDK인 boto3를 이용하여 별도 Alert 사용.
Aurora Alert
IDC
server
Alert cron job
임계 값 초과 시 telegram으로 Alter 발송
AWS
Metrics Logs Alarms
Event
Subscriptions
RDS Dashboard CloudWatch
46. 46
• Python 용 AWS SDK인 Boto3을 사용하여 Alert 스크립트 작성.
( Reference : http://boto3.readthedocs.io/en/latest/index.html )
• Server의 crontab에서 수행, 임계값이 넘으면 telegram으로 Alert 발송.
• Instance 단위 Alert 항목
– Database connections
– CPU Utilization
– Deadlocks
• Region 단위 Alert 항목
– Maintenance : 하루에 한번 region에 maintenance가 있는지 확인하여 있다면 Alert 발송
– Events : region에 event가 발생할 경우 Alert 발송
Boto3를 사용한 Alert
47. 47
• Script 예제.
ex) Instance 단위 Alert 항목
– Database connections
– CPU Utilization
– Deadlocks
Boto3를 사용한 Alert
import boto3
from boto3.session import Session
...(생략)...
def get_metric(self, metric, role=None):
"""Get RDS metric from CloudWatch""“
session = boto3.Session(profile_name=self.profile)
cloudwatch = session.client('cloudwatch', region_name=self.region)
if not role:
dimension = [{u'Name':'DBInstanceIdentifier',u'Value':self.identifier} ]
else :
if role in ('aurora'):
dimension = [{u'Name':'EngineName',u'Value': role },{u'Name':'DbClusterIdentifier',u'Value':self.identifier } ]
else:
dimension = [{u'Name':'Role',u'Value': role },{u'Name':'DBClusterIdentifier',u'Value':self.identifier } ]
result = cloudwatch.get_metric_statistics(
Namespace='AWS/RDS',
Dimensions=dimension,
MetricName=metric,
StartTime=datetime.utcnow() - timedelta(seconds=300),
EndTime=datetime.utcnow(),
Period=300,
Statistics=['Average‘ ]
)
if result['Datapoints']:
if metric in ('ReadLatency', 'WriteLatency'):
# Transform into miliseconds
result = '%.2f' % float(result['Datapoints'][0][statistic] * 1000)
else:
result = '%.2f' % float(result['Datapoints'][0][statistic])
else:
print 'Unable to get RDS statistics' + metric
result = -1
return float(result)
...(생략)...
49. 49
• 배경 : AWS ⇒ IDC Server 로 마이그레이션 이슈 발생
. 구성도 : Aurora ⇒ AWS EC2 mysql replication ⇒ IDC mysql server
• 이슈 : Aurora 서버에 EC2 mysql replication 을 연결하면 Aurora CPU 증가 현상 발생.
– 아직 정확한 원인 확인되지 않음 (w/AWS)
• 대응 : Replication 을 연결하여 CPU 사용량을 분석하여, 여유있는 Aurora Instance 타입으로 운영 중…. (Cost… ㅠ.ㅠ)
Aurora에 Replication 연결시 CPU 증가 현상.
CPU Usage 가 30% 증가 !!!
단, 인스턴스 타입에 상이함
50. • 배경 : 비용 최소화 측면에서 상이한 스펙으로 Cluster 를 구성.
• 이슈 : 자동복구시 최소 스펙의 인스턴스가 master 가 될 수 있음.
• 대응 : Failover priority 관리하면서 운영
– AWS Web : Instance 별로 개별 확인만 가능 (Modify 메뉴)
– AWS-CLI 명령어 : 전체 Instance의 Failover priority 확인 가능.
– AWS-CLI 명령어 : Failover priority 수정.
( Reference : http://docs.aws.amazon.com/cli/latest/reference/rds/index.html#cli-aws-rds )
AWS-CLI command 활용.
$ aws --profile xxxx rds describe-db-instances --query 'DBInstances[*].[DBInstanceIdentifier, DBClusterIdentifier, AvailabilityZone,
DBInstanceClass, PromotionTier]' --output table
---------------------------------------------------------------------------------------------------------
| DescribeDBInstances |
+-------------------------+------------------------------------+------------------+----------------+----+
| test-commondb-db01-tok | test-commondb-db01-tok-cluster-1 | ap-northeast-1a | db.r3.4xlarge | 0 |
| test-commondb-db02-tok | test-commondb-db01-tok-cluster-1 | ap-northeast-1c | db.r3.2xlarge | 1 |
| test-commondb-db03-tok | test-commondb-db01-tok-cluster-1 | ap-northeast-1a | db.r3.xlarge | 2 |
| test-gamedb1-db01-tok | test-gamedb1-db01-tok-cluster-1 | ap-northeast-1a | db.r3.4xlarge | 0 |
| test-gamedb1-db02-tok | test-gamedb1-db01-tok-cluster-1 | ap-northeast-1c | db.r3.2xlarge | 1 |
| test-gamedb1-db03-tok | test-gamedb1-db01-tok-cluster-1 | ap-northeast-1a | db.r3.xlarge | 2 |
…
+-------------------------+------------------------------------+------------------+----------------+----+
$ aws --profile xxxxx rds modify-db-instance --db-instance-identifier [Instance 이름] --promotion-tier [숫자]