AWS Aurora 운영사례 (by 배은미)

AWS Aurora 운영 경험담
2016.04.22
배은미
1

2
1. Configuration
2. Grant
3. Backup / Restore
4. Failover
5. Maintenance
6. Monitoring
7. Appendix
Agenda

3
• DB 리소스 변경 간편.
• Auto Backup 제공.
• 손쉬운 Restore 작업.
• Disk 자동 Scale Out.
• Aurora Version Upgrade 간편.
• Auto Failover.
• Read 분산 용이.
GOOD

• 수정 불가능한 Configuration 존재.
• 백업 받은 시점으로 Restore 시 시간 소요.
• Super 권한 부재.
• Failover에 대한 원인불명.
• 모니터링 데이터 보관주기.
• 비용.
BAD

• Aurora Parameter Groups = my.cnf
• Aurora는 'DB Cluster Parameter' 와 'DB Instance Parameter' 로 분리.
– DB cluster parameter : cluster 에 포함된 모든 Instance에 적용
– DB Instance parameter : 개별 Instance에 적용.
Configuration
Cluster
(cluster-parameter 적용)
Instance 01 (writer)
(Instance-parameter01 적용)
Instance 02 (reader)
Instance 03 (reader)

7
• Parameter Groups 생성 및 확인.
• Instance의 적용된 Parameter 확인.
Parameter Groups

8
• 사용자가 수정할 수 없는 항목
• 사내 표준에 맞게 수정한 항목
Cluster Parameter

9
• 사용자가 수정할 수 없는 항목
• Aurora에서 수정이 불가능한 항목을 확인하고, Service 성격과 사내 표준에 맞게 Parameter Group을 설정.
Instance Parameter

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
• 이슈 : Instance 에 접속하여 set global <variable_name> 명령 사용 불가.
• 대안 : Instance에 적용되어있는 Cluster/Instance Parameter의 값 수정.
– Save Changes 버튼 클릭시, dynamic 변수는 즉시 적용.
– 여러 Instance에 동일한 parameter group이 적용 되어 있는 경우, 특정 server만 값 변경 불가.
Global Variables 수정

13
• 이슈 : kill 명령으로 다른 계정에 속한 thread 강제종료 불가능.
• 대안 : CALL mysql.rds_kill(thread_id) 사용.
Other Connection Kill

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
• 자동 백업(Automated Backup)
• Amazon RDS에서 백업을 자동으로 생성.
• Aurora 생성 시 기본 1일 보관.
– 1~35일까지 가능
• 연속 및 증분 백업.
– 백업 보존 기간 안에서 시점 복원 가능.
• 백업 중에 성능 영향이 없음.
• 백업 파일 보관기간 2일로 운영 중.
Backup - Automated Backup

• 수동 스냅샷 (Snapshots)
• 사용자가 수동으로 생성.
• 백업 보관기간을 별도 지정하지 않음.
– Amazone RDS 표준 스토리지 비용 발생.
• 리전당 50개의 스냅샷 한도
– 자동 백업에 미포함
• Aurora cluster version Upgrade 또는 대규모 정기점검 작업 전, 수동 스냅샷 생성.
Backup - Snapshots

• 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
• 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

• 배경 : 타게임에서 관리자의 실수로 전설 아이템 대량 지급 발생. 아이템 지급 이전으로 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

21
• Aurora의 binary Log 활성화.
Aurora Setting

22
• Aurora binary log 보관 주기 설정.
– Auto Backup의 보관주기와 동일하게 2일로 설정.
Aurora Setting

23
• Aurora 로 접근 가능한 Gateway Server 에 mysql을 설치.
• Aurora Instance 에 replication 계정 생성.
Find Query (1)

• 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

• 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
• 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
• 사용자가 수동으로 Failover 발생.
• Failover 시 priority 에 따라 Master(=Writer)가 결정됨.
• Instance에서 Failover 메뉴를 선택하여 진행.
Manual Failover

• 주기적으로 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

• 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.

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 적용.

34
Aurora Monitoring
AWS
CloudWatch
Metrics
Logs
Events
RDS monitoring Enhanced monitoring
(최근 1 개월)(최근 2주)
Logs
RDS Dashboard
(최근 2 개월)

35
• Aurora에서 기본 제공하는 Monitoring.
• 운영체제(OS) 및 SQL 모니터링 데이터 제공.
• RDS는 Monitoring의 데이터를 1분 마다 CloudWatch에 자동 전송. ( CloudWatch의 Metrics 확인 )
RDS Monitoring

36
• 운영체제(OS)에 대한 모니터링 제공.
– 프리 티어 초과하는 별도 비용 청구됨.
– 최근 한달까지의 데이터 제공.
• RDS Monitoring에서 제공하는 OS정보보다 더 상세한 정보를 제공.
Enhanced Monitoring

• 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
• Enhanced Monitoring에서는 RDS monitoring에서 제공하는 OS 정보보다 더 세분화된 데이터를 제공.
– CPU, 메모리, 파일시스템 및 디스크 I/O 등
RDS Monitoring과 Enhanced Monitoring
 RDS 의 CPU 지표  Enhanced의 CPU 지표

39
• 오래된 데이터는 monitoring 불가능.
Aurora Monitoring
AWS
CloudWatch
Metrics
Logs
Events
RDS monitoring Enhanced monitoring
최근 1 달의 데이터 monitoring최근 2주의 데이터 monitoring
Logs
RDS Dashboard

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
Aurora Alert
AWS
Metrics Logs Alarms
Event
Subscriptions
Event 발생시 Email로 Alert 발송
RDS Dashboard CloudWatch
지정한 임계 값에 도달할 경우 Alert 발송.

42
• Event Subscriptions를 생성하여 Event 발생 시 Alert 발송.
– 구독할 Source Type과 Event Categories를 선택.
– Send notifications to에서 Email(기본 제공)로 Alert을 수신.
Event Subscriptions

• Cloudwatch의 Metrics 데이터를 모니터링하여 Alarm 설정.
– 지정한 임계 값에 도달하고, 지정한 기간 동안 유지가 된다면 알람 발송.
CloudWatch의 Alarms

44
• 기본 Email 이외에 다른 platform으로 Alter을 받으려면 별도의 연동 필요.
• CloudWatch Alarms의 경우, UI 및 관리가 불편하여 사용하고 있지 않음.
Aurora Alert
AWS
Metrics Logs Alarms
Event
Subscriptions
Event 발생시 Email로 Alert 발송
UI 및 관리가 불편하여 사용하지 않음

45
• Python용 AWS SDK인 boto3를 이용하여 별도 Alert 사용.
Aurora Alert
IDC
server
Alert cron job
임계 값 초과 시 telegram으로 Alter 발송
AWS
Metrics Logs Alarms
Event
Subscriptions

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
• 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
• 배경 : 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% 증가 !!!
단, 인스턴스 타입에 상이함

• 배경 : 비용 최소화 측면에서 상이한 스펙으로 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 [숫자]

AWS Aurora 운영사례 (by 배은미)

AWS Aurora 운영사례 (by 배은미)

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados(20)

Similar a AWS Aurora 운영사례 (by 배은미)

Similar a AWS Aurora 운영사례 (by 배은미)(20)

Último

Último(6)

AWS Aurora 운영사례 (by 배은미)