Introduction to Database Migration

데이터베이스 마이그레이션은 왜 필요한가?

많은 기업들이 오래된 데이터베이스 시스템으로 고민한다. 10년 전에 구축된 오라클 데이터베이스가 회사의 주요 업무를 담당하고 있지만, 라이선스 비용은 해마다 늘어나고 성능은 점점 느려지는 상황일 수 있다. 새로운 기능을 추가하려면 복잡한 절차를 거쳐야 하고, 서버 장애가 발생하면 몇 시간씩 서비스가 중단되기도 한다.
이런 상황에서 클라우드로의 데이터베이스 마이그레이션은 매력적인 해결책이 될 수 있다. 하지만 운영 중인 시스템을 옮기는 것은 매우 위험한 작업이다. 고객 정보, 주문 내역, 결제 데이터 등 중요한 정보들이 모두 안전하게 이전되어야 하고, 서비스가 중단되는 것도 최소화해야 한다.

AWS SCT

AWS Schema Conversion Tool(SCT)은 이런 복잡한 마이그레이션 과정에서 첫 번째 위험성을 해결해준다. 예를 들어, 오라클 데이터베이스를 PostgreSQL로 바꾼다고 생각해보자. 두 데이터베이스는 테이블을 만드는 문법부터 저장프로시저를 작성하는 방법까지 모든 것이 다르다. Oracle의 DECODE 함수는 Postgres에서 CASE WHEN으로 바꿔야 하고, 시퀀스는 SERIAL 타입으로 변환해야 한다.

SCT가 하는 일

자동 분석

SCT는 기존 데이터베이스를 스캔해서 무엇이 있는지 파악한다. 테이블이 몇 갠지, 저장프로시저는 얼마나 복잡한지, 인덱스는 어떻게 구성되어 있는지 모든 것을 분석한다.

복잡도 평가

각 객체를 변환하는 데 얼마나 어려울지 색깔로 표시해준다. 녹색은 자동으로 변환 가능, 노란색은 약간의 수정 필요, 빨간색은 상당한 작업이 필요함을 의미한다.

변환 작업

가능한 모든 것을 자동으로 변환해준다. 단순한 테이블 구조나 기본적인 SQL 문들은 몇 초만에 새로운 형태로 바뀐다.

결과 보고서 제공

ACT는 상세한 보고서도 제공해준다. 이 함수는 PostgreSQL에서 지원하지 않으니 이렇게 바꾸라는 식으로 구체적인 권장사항을 알려준다.

AWS DMS

스키마 변환이 끝나면 이제 실제 데이터를 옮겨야 한다. AWS Database Migration Service(DMS)의 역할이다.

운영 중 마이그레이션

DMS의 기능 중 하나는 운영 중에 데이터베이스를 중단하지 않고도 데이터를 옮길 수 있다는 것이다.

과정은 다음과 같다.

1단계: 전체 로드

먼저 기존 데이터를 모두 새로운 데이터베이스로 복사한다. 이 과정에서도 원본 데이터베이스는 계속 작동한다.

2단계: 지속적 복제(CDC)

전체 복사가 끝나면 이제 실시간으로 변경사항을 동기화한다. 원본에서 새로운 요청이 들어오면 즉시 대상 데이터베이스에도 반영된다. 이렇게 두 데이터베이스를 동기화 상태로 유지한다.

3단계: 전환

준비가 다 되면 애플리케이션을 새로운 데이터베이스로 전환한다. 이 시점에서만 잠시 서비스를 중단하면 된다.

12단계 마이그레이션 프로세스

데이터베이스 마이그레이션은 단순히 데이터를 복사하는 것이 아니다. 12단계의 체계적인 프로세스를 통해 안전하고 성공적인 마이그레이션을 보장한다.

1-5단계: 베이스 준비

1단계 - 구상 및 평가: 현재 상황을 파악한다. 데이터베이스가 얼마나 크고, 어떤 애플리케이션들이 연결되어 있으며, 어떤 위험요소들이 있는지 분석한다. 비즈니스 케이스도 만든다. "이 마이그레이션으로 연간 얼마를 절약할 수 있고, 어떤 이점을 얻을 수 있는가?"

2단계 - 스키마 변환: SCT를 사용해서 데이터베이스 구조를 변환한다. 이 단계에서 대부분의 기술적 이슈들이 발견된다.

3단계 - 애플리케이션 변환: 웹사이트나 모바일 앱에서 사용하는 SQL 문들도 새로운 데이터베이스에 맞게 수정해야 한다. SCT가 Java나 C# 코드에서 SQL을 찾아서 변환해준다.

4단계 - 스크립트 변환: 야간에 돌아가는 배치 작업이나 백업 스크립트들도 새로운 환경에 맞게 수정한다.

5단계 - 서드파티 통합: BI 도구나 모니터링 시스템 같은 외부 도구들이 새로운 데이터베이스와 잘 작동하는지 확인한다.

6단계: 실제 데이터 이전

DMS로 앞서 설명한 대로 운영을 중단하지 않고 데이터를 안전하게 옮긴다.

이 단계에서는 세심한 모니터링이 중요하다. 데이터가 얼마나 복사되었는지, 오류는 없는지, 성능에 문제는 없는지 실시간으로 확인한다. DMS 콘솔에서 진행상황을 그래프로 볼 수 있어 직관적이다.

7-9단계: 검증과 전환

7단계 - 기능 테스트: 새로운 시스템에서 모든 기능이 정상 작동하는지 확인한다. 고객이 주문을 할 수 있는지, 결제가 제대로 되는지, 재고가 정확히 차감되는지 등을 테스트한다.

8단계 - 성능 튜닝: 응답속도를 최적화한다. 때로는 새로운 데이터베이스에서 쿼리가 더 느려질 수 있는데, 인덱스를 조정하거나 쿼리를 개선해서 성능을 향상시킨다.

9단계 - 통합 및 배포: 드디어 실제 전환을 한다. 이때를 위해 롤백 계획도 미리 준비해둔다. 만약 문제가 생기면 즉시 원래 시스템으로 되돌릴 수 있어야 한다.

10-12단계

10단계 - 교육 및 지식전달: 팀원들이 새로운 시스템에 익숙해지도록 교육한다. Oracle에만 익숙했던 DBA가 PostgreSQL을 배우는 것은 쉽지 않은 일일 수 있다.

12단계 - 지속적 지원: 새로운 환경에서 안정적으로 운영하기 위한 모니터링과 지원 체계를 구축한다.

마이그레이션 유형별 접근법

동종 마이그레이션

같은 종류의 데이터베이스끼리 옮기는 것은 상대적으로 단순하다. 온프레미스 Oracle을 Amazon RDS for Oracle로 옮기는 경우를 예로 들면, 스키마 변환 없이 DMS만 사용하면 된다.

하지만 "단순하다"고 해서 쉽다는 뜻은 아니다. 네트워크 설정, 보안 구성, 성능 튜닝 등 여전히 신경 써야 할 부분들이 많다.

이종 마이그레이션

Oracle에서 PostgreSQL로, SQL Server에서 MySQL로 옮기는 것은 더 복잡하지만 그만큼 이익도 클 수 있다.

이 경우 SCT와 DMS를 모두 사용해야 한다. 먼저 SCT로 스키마를 변환하고, 그 다음에 DMS로 데이터를 옮긴다.

복제

데이터를 완전히 옮기는 것이 아니라 계속 동기화 상태로 유지하고 싶을 때가 있다. 재해복구용 백업 시스템을 만들거나, 읽기 전용 분석 시스템을 구축할 때 유용하다.

DMS의 CDC 기능을 사용하면 실시간으로 데이터를 동기화할 수 있다. 원본에 변경사항이 생기면 몇 초 내에 대상 시스템에도 반영된다.

마이그레이션의 실질적 이익

기술적 이익

가동중지 시간 최소화: 과거에는 데이터베이스를 옮기려면 며칠씩 서비스를 중단해야 했다. 이제는 몇 분이면 충분하다.

자동화: 수동 작업이 줄어들면서 인적 오류도 크게 감소한다. 사람이 직접 데이터를 복사하다가 실수할 위험이 없어진다.

안전성: DMS는 데이터를 옮긴 후 자동으로 검증한다. 원본과 대상의 데이터가 정확히 일치하는지 확인해준다.

비즈니스 이익

비용 절감: 비싼 상용 데이터베이스 라이선스에서 벗어나 오픈소스나 클라우드 서비스로 옮기면 상당한 비용을 절약할 수 있다.

확장성: 클라우드에서는 필요에 따라 자원을 늘리거나 줄일 수 있다.

현대화: 최신 데이터베이스 엔진은 더 나은 성능과 새로운 기능을 제공한다. 기계학습, 실시간 분석 같은 최신 기술을 쉽게 활용할 수 있다.

선택의 자유: 더 이상 하나의 벤더에 종속되지 않고 필요에 따라 다른 솔루션으로 전환할 수 있는 유연성을 가진다.

마치며

데이터베이스 마이그레이션은 분명 도전적인 프로젝트이지만, AWS SCT와 DMS 같은 도구들이 있고 체계적인 접근 방법을 따른다면 충분히 성공할 수 있다는 것을 알게 되었다. 무엇보다 이를 통해 얻는 이익이 투입한 노력보다 훨씬 크다면, 기업 입장에서 충분히 도전해볼 가치가 있을 것이다.