🚞 성공적인 AWS RDS 마이그레이션을 위한 여정과 필수 고려사항
1. Amazon DB Services 비교
Amazon RDS vs. Aurora
| 비교 항목 | RDS | Aurora |
|---|---|---|
| 지원 DBMS | MySQL, PostgreSQL, MariaDB, Microsoft SQL Server, Oracle | MySQL, PostgreSQL |
| 성능 | 상급 성능 | 최상급 성능 (유사 하드웨어에서 throughput이 Stock MySQL 대비 최대 5배) |
| 안정성 | 상급 안정성 | 최상급 안정성 (특화된 스토리지 아키텍처 디자인 + 지속적인 백업 아키텍처) |
| 스토리지 확장성 | 64 TiB (SQL Server 경우 16 TiB 까지 확장 가능) | 128 TiB 까지 확장 가능 |
| 가격 | 인스턴스 유형, 스토리지 볼륨 크기 | 인스턴스 유형, 스토리지 실사용 크기, IO 요청 |
Amazon RDS Custom for Oracle
- 2022년 말부터 서울 리전에서 시작된 DB 서비스
- 일반적으로 Amazon RDS로도 충분하지만 추가적인 OS와 Database의 커스텀 설정이 필요한 경우에 선택 가능한 옵션
- Oracle과 SQL-Server 중 선택 가능
| 기능 및 책임 | EC2 | RDS Custom | RDS |
|---|---|---|---|
| Application | Customer | Customer | AWS |
| Availability | Customer | Shared | AWS |
| DB Backup | Customer | Shared | AWS |
| DB SW | Customer | Shared | AWS |
| OS | Customer | Shared | AWS |
| Server | AWS | AWS | AWS |
- AWS에서 제공한 설정에 대한 책임은 AWS가 담당
- 고객 맞춤(Custom) 설정은 책임을 공동으로 가져가는 모델
2. DB Migration 단계
일반적인 DB Migration 단계
- Amazon RDS로의 마이그레이션은 아래와 같은 각 단계별 계획 수립 필요
- Assess
- 소스 DB 환경에 대한 분석
- 인프라 환경
- 데이터 용량/종류
- 연계 환경
- 요구 조건
- 영향, 리스크
- 타겟 AWS DB 환경 분석
- 소스 DB 환경에 대한 분석
- Plan
- 데이터 용량, 이관 기간, 다운 타임, 실행 난이도 등을 전체적으로 고려하여 계획 수립
- 이관 전략
- 이관 기술
- 테스트/검증 계획
- 이행 계획
- 롤백 계획
- 데이터 용량, 이관 기간, 다운 타임, 실행 난이도 등을 전체적으로 고려하여 계획 수립
- Test
- 실제 데이터로 이관 테스트 진행
- 검증
- 시간 측정
- 튜닝 요소 점검
- 2-3회 테스트 진행
- 실제 데이터로 이관 테스트 진행
- Excute
- 계획에 맞추어 DB 이관 진행
- 이관 진행
- 상황 모니터링
- 검증 진행
- 시스템 오픈
- 모니터링
- 운영 모드 진입
- 계획에 맞추어 DB 이관 진행
Access Inspection Lists
Access 단계에서는 특히 상세한 분석이 필요함
3. DB Migration 고려사항
Amazon RDS Custom for Oracle
- Amazon RDS로의 마이그레이션을 위한 준비사항
- 백업
- 최소 2개 이상 백업본 생성해두기
- 호환성 점검
- 이관방법 제약사항 숙지
- 라이선스 As-Is, To-Be 변화 준비
- 3rd파티 SW 이관 대체방안 마련
- 충분한 시간 확보
- 백업
4. DB Migration 도구
OS Command 사용
- OS, DB 버전이 동일하고 데이터 크기가 크지 않은 경우에 간단하고 쉽게 이관할 수 있는 방법
- 장점
- 간단한 OS 명령(scp, sftp 등)만을 사용한 이전 가능
- 쉬운 사용 방법
- 단점
- 파일 복사에 필요한 서비스 중단 시간은 파일 용량에 비례
- OS/플랫폼, Oracle DB 버전, 설정 등의 환경이 일치해야 함
- 파일 복사 시 중간에 끊길 수 잇는 경우에 대한 대비 필요
DBMS 제공 도구 사용
- DBMS 자체에서 제공해주는 도구를 사용하여 버전이 다른 환경으로의 이관 가능
- ex) Oracle Data Pump, MySQL Dump
- 장점
- 서로 다른 OS/플랫폼 환경에서의 이전 가능
- DB 버전이 달라도 이전 가능
- 다른 character set 환경에서의 이전 가능
- 특정 대상 테이블만 선별하여 이전 가능
- 단점
- 일반적으로 시간이 많이 소요되며 이에 따른 서비스 중단 필요
- 타 DB로의 이전 불가
- DB 버전 간 차이가 심한 경우 실패 확률 증가
Data 캡쳐 도구 변경
- CDC 도구는 동일 또는 이기종 DB간 실시간 복제 기능을 제공
- ex)
- AWS Database Migration Service (AWS DMS)
- 무료
- Shareplex Quest, Oracle Golden Gate 등
- 임시 라이선스 구입 필요
- AWS Database Migration Service (AWS DMS)
- 장점
- 서로 다른 OS/플랫폼 환경에서의 이전 가능
- 타 DB로의 이전 가능
- 대용량 이전 가능
- 제품에 따라 소스, 타깃 DB, 대상 테이블들을 여러 형태로 선별하여 이전 가능
- 실시간에 가까운 Ongoing 복제가 가능하며 다운타임을 최소화
- 단점
- 상용 제품일 경우 도입 비용 발생
- 제품별로 지원되지 않는 DB 존재
5. DB Migration 사례
Onpremise MS-SQL에서 Amazon RDS MySQL로의 이관
미디어사 A사의 Onpremise MS-SQL에서 Amazon RDS MySQL로의 이관 사례
- AWS 도구(SCT, DMS)를 사용하여 MS-SQL에서 MySQL로 이관한 사례
- AWS SCT로 스키마를 우선 생성한 후에 DMS로 데이터 이전을 진행
- 이기종 DB로의 전환이므로 쿼리에 대한 튜닝과 필요한 경우 로직을 수정해줌
- 주의사항
- AWS SCT, DMS 사용 시 이기종 DB로의 전환에서 기능 제약이 존재하므로 반드시 사전에 해당 DB 버전들에 대한 기능 지원/미지원에 대한 점검과 계획 필요
- 여러 인덱스, 외래키, 트리거 등
- MySQL의 경우 MS-SQL의 기본 스키마 이름의 일부인 dbo 스키마 이름 형식이 포함되어선 안됨 → 이름 수정에 반영
- 프로세저의 경우 메뉴얼 작업 준비 필요
- 쿼리 수정 및 로직 수정이 필요한 경우가 다수 존재할 수 있음
- AWS SCT, DMS 사용 시 이기종 DB로의 전환에서 기능 제약이 존재하므로 반드시 사전에 해당 DB 버전들에 대한 기능 지원/미지원에 대한 점검과 계획 필요
Onpremise Oracle DB에서 Amazon RDS Oracle로의 이관
온라인 샵 B사의 온프레미스 Oracle RAC DB에서 AWS RDS로의 이관 사례
- CDC 도구를 사용하여 업버전으로 이관한 사례
- 운영 DB의 영향을 줄이기 위해 백업데이터로 초기 데이터 적재 후 Sync를 진행
- 실행 전에 사전 테스트 진행
- AWS RDS는 RAC를 지원하지 않으므로 새로운 환경에 맞게 설정을 조정
- 서비스 오픈 전 Top 쿼리를 선별하여 튜닝을 진행하였으며, 오픈 후에는 모니터링을 통해 나머지 쿼리에 대한 추가 튜닝을 진행
- 주의사항
- AWS로 이관 시 RAC에 대한 대안 준비가 필요하며 HA 구성 시 Active 인스턴스는 기존 RAC 환경의 모든 처리를 할 수 있어야 하며 로직에서도 타깃 DB에 대한 수정이 필요
- 데이터 싱크 시 대역폭 사용량에 대한 준비 필요. 가급적 별도의 전용선 또는 VPN 사용 권장
- CDC 도구는 만등이 아니며 간혹 에러가 발생할 수 있기 때문에 수정 도구 또는 수작업으로 해결이 필요할 수 있음
- 버전 업그레이드 시 쿼리 튜닝에 대한 준비 필요
