데이터베이스를 이전하고 끝내는 게 아니라, 운영까지 담당합니다

온프레미스에서 AWS·Azure로의 이전

같은 제품 이름이라도 온프레미스에서 클라우드로의 이전에서는 운영의 전제가 달라집니다. 관리형 서비스는 OS 레이어에 접근할 수 없으므로, 상주 에이전트, 로컬 파일 연동, OS 스케줄러에 의존하는 처리는 그대로 가져올 수 있는지 먼저 분기해야 합니다.

GIIP는 온프레미스 SQL Server의 AWS RDS 이전, 온프레미스 Oracle의 AWS 이전을 실제로 경험했습니다. AWS와 Azure 양쪽에서 데이터베이스를 운영하므로, 한쪽 클라우드의 전제를 다른쪽에 가져오지 않는 형태로 설계할 수 있습니다.

스키마·호환성·쿼리 검증

"실행되는지"가 아니라 "같은 결과가 나오는지"를 확인하는 공정입니다.

• 기본 키, 인덱스, 제약 조건, 파티션의 스키마 정의 차이를 찾아냅니다.
• 데이터 타입·문자 코드·정렬 순서의 차이가 값 자체에 영향을 미치지 않는지 확인합니다.
• 기존 SQL이 이전 대상에서 같은 실행 계획을 낸다는 보장은 없습니다. 사전에 무거워질 쿼리를 특정합니다.
• 스토어드 프로시저, 트리거, 잡, 배치 처리 종속성을 열거하여 이전 대상에서 누락되지 않도록 합니다.
• 이전 전후의 건수·정의를 기계적으로 대조할 수 있는 형태로 만듭니다.

전환 계획과 롤백 계획

이전의 성패를 나누는 것은 많은 경우 "잘 되었을 때"가 아니라 "잘 안 되었을 때"의 설계입니다. 롤백할 수 없는 전환은 업무상 판단으로서 위험이 너무 높습니다.

• 전환 시 기준이 될 노드·시점을 사전에 확정합니다.
• 허용 가능한 중단 시간을 업무 측과 합의하고, 그 범위 안에 들어오는 방식을 선택합니다.
• 롤백 판단 기준(무슨 일이 일어나면 돌아갈지)과 그 소요 절차를 적어 둡니다.
• 전환 후 확인할 항목과 그 확인을 누가 수행할지 정합니다.

중단 시간의 기준은 환경에 따라 다릅니다. 실측에 기반하지 않은 일반 수치는 전달하지 않습니다.

이전 후 성능 모니터링

이전 직후는 이전에 문제 되지 않았던 쿼리가 드러나기 쉬운 시기입니다. 실행 계획의 변화, 연결 수의 변화, 배치 처리 부하 특성의 변화가 동시에 발생하기 때문입니다.

GIIP는 이전하고 끝내지 않고, 이전 후 모니터링·성능 분석·운영까지 같은 팀이 계속합니다. 현재도 AWS와 Azure 위의 클라우드 데이터베이스를 지속적으로 모니터링하고 있습니다.

AWS DMS 등의 도구 사용에 대하여

GIIP는 특정 이전 도구의 채용을 전제하지 않습니다. AWS Database Migration Service(DMS)와 같은 관리형 도구가 적합한 상황이 있는 반면, 논리 덤프나 복제가 더 확실한 상황이 있습니다.

도구는 이전 원본·대상 조합, 데이터 양, 허용 가능한 중단 시간, 검증에 투입할 수 있는 기간에서 선택합니다. 이 페이지에서는 실제 건에서 어떤 도구를 사용했는지는 공개하지 않습니다.

1. 1

   현행 구성 확인

   데이터베이스 종류, 버전, 온프레미스인지 클라우드인지, 인스턴스 구성을 확인합니다.

2. 2

   규모 파악

   데이터 용량과 대략적인 테이블 수를 확인합니다. 둘 중 어느 것이 실제 난관인지가 여기서 정해집니다.

3. 3

   종속 관계 정리

   잡, 배치, 외부 인터페이스, 다른 시스템과의 연계를 열거합니다.

4. 4

   중단 허용 범위 확인

   무중단이 필요한지, 몇 시간까지 중단할 수 있는지 업무 측 조건으로 확인합니다.

5. 5

   이전 방식과 검증 계획 제시

   전제를 명시한 뒤에, 방식의 선택지·검증 항목·롤백 방침을 정리하여 제시합니다.

6. 6

   이전 후 운영 범위 결정

   모니터링·운영을 GIIP가 담당할지, 인계할지 정합니다.