[reinvent 2024] 대규모 Aurora 및 RDS환경에서 고아상태(DB와 연결이 끊어진) 의 스냅샷 관리하기

들어가며

AWS에서 고객의 서비스데이터를 저장하기 위한 RDBMS서비스는 AWS Aurora와 AWS RDS로 양분되어 있습니다. 기존의 On-premise환경에서 무겁고 진중하게만 관리되던 이 데이터베이스는 서비스는 클라우드에 와서야 한층 더 날개를 달게 되었습니다. 온라인에서의 데이터가 중요한만큼 이 데이터를 백업하는 것도 중요하기 때문에 On-premise환경에서의 전통적인 백업방식은 데이터베이스 엔진을 제공하는 회사의 DB브랜드만큼이나 서로 다르고 격리된 기술이었습니다.

AWS Aurora와 AWS RDS의 스냅샷은 단 몇번의 클릭만으로 완벽한 Hot백업을 수행하기 때문에 관리대상인 Aurora와 RDS의 수량만으로는 부담이 되지않을 정도입니다. 하지만, 스냅샷만큼은 데이터베이스당 적어도 10개 정도의 스냅샷을 유지하는 것이 일반적입니다. 그 이유는 복구해야할 시점을 최대한 유리하게 선택하기 위해 스냅샷 갯수를 유지하게 됩니다. 스냅샷이 10개있다면 데이터가 무너지더라도 10개의 타임머신 시간을 가진것이며, 100개의 스냅샷은 100개의 타임머신 시간을 제공받게 됩니다. 데이터가 오염된 상태를 인지한 이후 3개월 전의 깨끗한 데이터상태로 돌아가고 싶다면, 해당 시간대의 스냅샷을 복원하여 깨끗한 상태로 돌아갈 수 있습니다.

데이터베이스의 수량과 그 배수의 스냅샷이 존재한다면, 이들을 다루는건 여전히 쉽다고 할 수 있지만, 이들을 제대로 인지하고 필요한것과 불필요한것을 식별해 내는 것은 좀 다른 차원의 일이 됩니다.

Database의 스냅샷을 정리하는 구조(고아 상태의 스냅샷을 정리하는 과정)

연사께서 제공해주신 솔루션 개요입니다.

Aurora, RDS으로부터 저장된 수많은  스냅샷을 코드가 고아상태 여부를 식별하여 Step Function으로 과정을 가시화하여 고아상태인 스냅샷을 S3버킷으로 저장하고, 스냅샷을 삭제하는 솔루션입니다.

워크샵의 시작 및 초기 리소스 배포

워크샵의 시작입니다. 언젠가 공개가 되어 모두가 볼 수 있으면 좋겠네요.

1. 리소스현황 파악하기 (Aurora, RDS와 스냅샷)

CloudFormation배포가 끝나면, RDS서비스에서 운용 중인 Aurora, RDS의 상태와 스냅샷의 상태를 확인합니다.

대상 region은 모두 3개 이며, Ireland (eu-west-1), N.Virginia (us-east-1), Oregon(us-west-2) 입니다. Aurora, RDS는 Ireland에만 3개가 존재하며, 스냅샷은 3개 region에  스냅샷이 6개씩 존재합니다.

2. 환경변수 설정 및 배포 환경 파악하기

준비된 EC2의  Session Manager로 진입하여, 환경변수를 설정하는 커맨드를 실행합니다. 환경변수 중 SNS이메일을 수신할 이메일주소를 설정한 후, OS환경변수를 반영하고 확인하는 과정이 포함됩니다.

실행할 스크립트가 어떤 것인지 확인합니다.

• deploy-solution-regional.sh : CloudFormation을 통해 필요한 리소스를 배포합니다.
• execute-solution-regional.sh : 현재 Region의 데이터베이스와 스냅샷을 조회하고, 데이터베이스와 연결이 끊어져 필요없어진 스냅샷을 식별 후 스냅샷 삭제 메일을 발송, 스냅샷을 S3에 백업한 다음 스냅샷을 삭제합니다.

그리고, 2가지 파라미터를 확인합니다. 하기 파라미터로 실제로 스냅샷을 삭제할 지, 삭제 전에 백업할 지를 선택할 수 있습니다.

• ExportOrphanedSnapshotsToS3 = True : 고아상태 스냅샷을 S3로 별도 백업할지 결정합니다.
• DeleteOrphanedSnapshots = True : 고아상태 스냅샷을 삭제할지 결정합니다.

3. 솔루션 배포하기

솔루션을 배포하는 스크립트인 deploy-solution-regional.sh를 수행합니다.

내포된 CloudFormation에 따라 아래와 같은 리소스가 배포됩니다.

• KMSKey
  • AWS::KMS::Key: S3로 내보낸 스냅샷 데이터를 암호화/복호화하는 데 사용
  • KeyPolicy: Lambda 함수와 IAM 역할이 KMS 키를 사용할 수 있도록 권한 부여
    
    
• SNSTopic
  • AWS::SNS::Topic: 고아 스냅샷 알림을 전송하기 위한 SNS 주제
  • Subscription: 사용자 지정 이메일 주소(NotificationAddress)로 알림 전송
    
    
• IAM-Role (Solution)
  • AWS::IAM::Role: Lambda 함수, Step Functions, EventBridge 등이 사용할 IAM 역할
  • AssumeRolePolicyDocument: Lambda 함수, RDS Export 서비스, EventBridge 등이 이 역할을 맡을 수 있도록 허용
    
    
• IAM-Policy (Solution)
  • AWS::IAM::Policy: SolutionRole에 연결된 정책으로, 다음 작업을 허용:
    • RDS 관련 작업: 스냅샷 조회, 삭제, Export Task 시작 등
    • Lambda 작업: 다른 Lambda 함수 호출
    • CloudWatch 작업: 로그 생성 및 메트릭 기록
    • S3 작업: S3 버킷에 스냅샷 내보내기
    • SNS 작업: 알림 전송
    • KMS 작업: 데이터 암호화/복호화
      
      
• HelperLambdaFunction
  • AWS::Lambda::Function: 고아 스냅샷을 식별하고, S3로 내보내거나 삭제하는 핵심 로직을 수행
  • Environment Variables: Lambda 함수가 필요한 설정값(S3 버킷, KMS 키, SNS 주제 등)을 환경 변수로 전달
  • Handler: index.handler (Python 코드)
  • Timeout: 10초로 설정
  • Runtime: Python 3.12
    
    
• StateMachine
  • AWS::StepFunctions::StateMachine: 고아 스냅샷 관리 워크플로우를 정의
  • DefinitionS3Location: Step Functions 상태 머신 정의가 저장된 S3 JSON 파일 경로
  • RoleArn: StateMachine이 사용할 IAM 역할
    
    
• CloudWatch 대시보드 (SnapshotsDashboard)
  • AWS::CloudWatch::Dashboard: 고아 스냅샷 및 전체 스냅샷 상태를 모니터링할 수 있는 대시보드 생성
  • DashboardBody:
    • OrphanedSnapshots: 고아 스냅샷 개수를 시간별로 시각화
    • TotalSnapshots: 전체 스냅샷 개수를 단일 값으로 표시
    • Percent Orphaned: 고아 스냅샷의 비율을 게이지로 표시
      
      
• EventBridge 규칙
  • WorkflowRule:
    • ScheduleExpression: cron(0 6 ? * 2 *) (매월 두 번째 월요일 오전 6시에 실행)
    • Target: StateMachine을 트리거
  • RegularCheckRule:
    • ScheduleExpression: rate(1 minute) (1분마다 실행)
    • Target: HelperLambdaFunction을 트리거
    • Input: {“action”: “standalone”} (Standalone 모드로 실행)
      
      
• Lambda Permission
  • AWS::Lambda::Permission: EventBridge가 HelperLambdaFunction을 호출할 수 있도록 권한 부여

솔루션 배포가 완료되면, SNS가 발송한 이메일에 대해 수신 승인도 진행해 주세요.

4. 솔루션 수행하기

실제 작업을 수행하는 커맨드를 실행합니다. 동일 region의 스냅샷만 식별하여 처리하는 스크립트 입니다. 

스냅샷 식별도 하고, export to S3를 실행하기 때문에 20분정도는 소요됩니다. 실제 환경에선 보유하신 대상 스냅샷의 양과 사이즈에 따라 달라질 것입니다.

스냅샷 식별의 결과와 S3로의 백업, 스냅샷 삭제를 진행하겠다는 이메일이 수신되었습니다.

Step Function에서 진행되는 과정을 확인하십시오.

CloudWatch의 Metrics도 확인하셔서, 실제 운용시에 어떤 방식으로 모니터링될지 살펴보세요.

5. 솔루션 수행결과 확인하기

스냅샷 정리가 완료되었고, 고아상태의 스냅샷은 삭제되었습니다.

스냅샷 삭제 전에 Export to S3를 통해 S3로 저장되었습니다.

결론

이번 워크샵은 대량의 데이터베이스와 스냅샷을 보유하며 운용 하시는 고객의 경우 특히 유용할 것이라 생각합니다.

특별한 신기술이 사용되었다기 보다는 특정목적에 맞게 백업 뒷단에서 발생하는 가비지데이터를 정리하고, 이메일로 대상을 통지하며, 처리과정과 상태를 모니터링할 수 있게 해주는 파이프라인을 구현하는 방법을 소개해 준 워크샵이었다는 생각이 듭니다. 

워크샵에서는 RDS스냅샷을 대상으로 했지만, 가비지데이터를 확대하여 정리한다는 관점에서 보았을 때 사용하지않는 리소스를 스캔하여 정리하는 운용 파이프라인의 구성을 상상해 봅니다.

이번 워크샵이 공개되어 저도 마음껏 테스트해 볼 수 있으면 좋겠습니다.