마이그레이션 그 이상: 디스크 축소를 위한 Database Migration Service 사용

*이 콘텐츠는 AI 번역 도구를 사용하여 번역되었습니다. 정확성을 기하기 위해 노력하고 있으나, 자동 번역에는 오류나 누락이 포함될 수 있습니다. 정확한 정보는 영문 원본을 참고해 주시기 바랍니다.

데이터베이스 엔지니어는 '데이터베이스 마이그레이션'이라는 말을 들으면 일반적으로 일회성 온보딩 경로, 즉 데이터베이스를 온프레미스 환경에서 클라우드로 또는 서로 다른 클라우드 제공업체 간에 이동하는 것을 떠올립니다.

하지만 Google Cloud의 Database Migration Service(DMS)는 SQL Server용 Cloud SQL을 소스로 지원합니다. 이를 통해 Google Cloud 내 SQL Server 고객은 기존과는 다른 강력한 운영 패턴을 활용할 수 있습니다. DMS는 동일한 프로젝트, 여러 프로젝트 또는 여러 리전에서 Cloud SQL 인스턴스 간에 지속적이고 다운타임이 짧은 데이터베이스 복제를 지원하므로 스토리지 관리와 같은 2일 차 운영을 위한 일상적인 유틸리티로 사용할 수 있습니다.

이 게시물에서는 SQL Server용 Cloud SQL과 함께 DMS를 활용하는 운영상의 강력한 사용 사례인 최소한의 애플리케이션 다운타임으로 디스크 축소를 실행하는 방법을 살펴봅니다.

디스크를 축소해야 하는 이유는 무엇인가요?

많은 프로덕션 환경에서 데이터베이스 스토리지는 한 방향, 즉 위로만 이동합니다. Cloud SQL 자동 스토리지 증가와 같은 기능은 예기치 않은 트래픽 급증, 대규모의 일괄 가져오기, 색인 유지보수 또는 임시 스테이징 로드 중에 공간 부족으로 인해 서비스가 중단되는 것을 방지하는 데 필수적입니다. 마찬가지로 애플리케이션의 수명 주기 동안 이전 레코드를 보관처리하거나, 오래된 데이터를 영구 삭제하거나, 사용하지 않는 색인을 삭제할 수 있습니다.

데이터가 삭제되면 SQL Server는 데이터 파일(.mdf, .ndf) 내의 여유 공간을 향후 쓰기 작업에 재사용할 수 있는 것으로 표시합니다. 마찬가지로 로그 자르기는 트랜잭션 로그 파일(.ldf) 내의 공간을 확보합니다. 그러나 데이터베이스 파일 자체는 AUTO_SHRINK가 구성되지 않는 한 최대 사용 공간을 계속 유지합니다. 이 설정은 일반적으로 심각한 색인 단편화 및 성능 오버헤드로 인해 프로덕션에는 권장하지 않습니다.

DBCC SHRINKFILE을 사용하여 데이터베이스 파일에 대한 수동 축소 작업을 수행하면 SQL Server 파일에서 사용하지 않는 공간을 기본 디스크로 다시 해제할 수 있습니다. 데이터베이스 파일을 축소한 후에도 Cloud SQL 영구 디스크는 할당된 최대 용량을 유지합니다. 조만간 데이터베이스가 할당된 디스크 공간으로 다시 확장될 가능성이 낮다면 디스크 자체를 축소하여 지속적인 스토리지 비용을 줄이는 것이 좋습니다. 특히 다음과 같은 시나리오에서는 더욱 그렇습니다.

주요 데이터 보관처리 또는 영구 삭제 후: 이전 데이터를 콜드 스토리지 또는 BigQuery로 영구적으로 이동했으며 이제 활성 데이터 세트가 최대 크기의 일부에 불과합니다.

일회성 스토리지 급증 복구: 통제 불가한 트랜잭션, 대규모 데이터 마이그레이션 또는 임시 스테이징 로드로 인해 스토리지 자동 증가가 트리거되었고 이로 인해 더 이상 필요하지 않은 프로비저닝된 디스크 용량에 대해 테라바이트 단위로 비용을 지불합니다.

리팩터링 또는 스키마 최적화 후: 모놀리식 데이터베이스에서 테이블을 별도의 서비스로 분할하거나, 사용하지 않는 대규모 색인을 삭제하거나, 데이터 압축을 적용했습니다.

아래 쿼리를 사용하면 데이터베이스의 각 데이터베이스 파일에 할당된 용량과 사용 가능한 여유 공간을 모두 검사할 수 있습니다.

Cloud Monitoring에서 다음과 같은 주요 Cloud SQL 측정항목을 모니터링하여 프로비저닝된 디스크 할당량이 실제 디스크 사용량을 크게 초과하는지 확인하면 디스크 축소 기회를 파악할 수 있습니다.

• database/disk/bytes_used: 데이터베이스 파일과 로그가 현재 사용 중인 실제 디스크 공간의 양을 추적합니다.

• database/disk/quota: 인스턴스에 할당된 총 디스크 프로비저닝 용량을 나타냅니다.

Cloud SQL은 할당되지 않은 디스크 공간을 회수할 수 있는 스토리지 축소 기능을 기본으로 제공하며, 이 기능은 워크로드가 계획된 유지보수 기간을 허용할 수 있는 경우에 잘 작동합니다. 그러나 기본 디스크 축소에는 할당된 총 디스크 크기에 비례하는 인스턴스 다운타임이 필요합니다. 즉, 멀티 테라바이트 드라이브의 경우 몇 시간 동안 오프라인 유지보수가 필요할 수 있습니다.

프로덕션 SLA가 연장된 다운타임을 수용할 수 없는 경우 Database Migration Service(DMS)는 다운타임을 최소화할 수 있는 대안을 제공합니다. 데이터베이스를 더 작고 적절한 크기의 디스크가 있는 새로 프로비저닝된 Cloud SQL 인스턴스에 지속적으로 복제하면 애플리케이션이 온라인 상태를 유지하는 동안 사용하지 않는 스토리지를 회수할 수 있으며, 짧은 컷오버 기간만 필요합니다. 이 접근 방식으로 컷오버 기간을 짧게 유지할 수 있는 이유를 이해하기 위해 먼저 DMS가 어떻게 내부적으로 SQL Server용 Cloud SQL 인스턴스 간에 데이터를 복제하는지 살펴보겠습니다.

DMS의 내부 작동 방식: SQL Server용 Cloud SQL 인스턴스 간 복제

DMS를 효과적으로 활용하려면 기본 복제 메커니즘을 이해하는 것이 좋습니다. SQL Server용 Cloud SQL 인스턴스 간에 마이그레이션할 때 DMS는 네이티브 SQL Server 로그 전달과 유사한 동기화 프로세스를 조정합니다.

1. 초기 전체 백업: 선택한 사용자 데이터베이스의 초기 전체 백업(.bak)을 캡처하고 대상 인스턴스에 복원합니다.

2. 지속적인 로그 백업: 트랜잭션 로그 백업(.trn)을 지속적으로 캡처하고 적용하여 대상 인스턴스를 거의 실시간으로 동기화합니다.

동기화는 사용자 데이터베이스 수준에서 이루어지므로 로그인, 연결된 서버, SQL Server 에이전트 작업과 같이 데이터베이스 외부에 있는 객체는 대기 인스턴스에 자동으로 복제되지 않습니다. 따라서 서버 수준 객체는 수동으로 마이그레이션해야 합니다.

다운타임을 최소화하는 디스크 축소

이 지속적 복제 파이프라인을 사용하면 긴 유지보수 기간을 거치지 않고도 할당되지 않은 스토리지를 회수할 수 있습니다. 인스턴스가 오프라인 상태인 동안 기존 디스크를 축소하는 대신, 프로덕션 애플리케이션이 온라인 상태를 유지하는 동안 워크로드를 적절한 크기의 디스크가 있는 새로 프로비저닝된 Cloud SQL 인스턴스로 마이그레이션합니다.

DMS 디스크 축소 워크플로

1. 적절한 크기의 더 작은 디스크로 새 대상 인스턴스를 프로비저닝합니다(트랜잭션 로그와 향후 데이터 증가를 위해 충분한 여유 공간을 남겨둠).

2. 기존 Cloud SQL 인스턴스를 소스로 사용하여 연속 DMS 작업을 시작합니다.

3. 프로덕션 애플리케이션이 중단 없이 실행되는 동안 복제가 따라잡을 수 있도록 합니다.

4. 간단한 컷오버 수행: 애플리케이션 트래픽을 중지하고, 최종 트랜잭션 로그를 적용하고, DMS에서 대상 인스턴스를 승격하고, 애플리케이션을 다시 가리킵니다.

비교: 기본 축소와 DMS 마이그레이션

위의 비교에서 볼 수 있듯이 DMS는 사용자 데이터베이스 수준에서 워크로드를 새 인스턴스로 마이그레이션하므로 원활한 컷오버를 위해서는 데이터와 함께 서버 수준 객체 및 사용자 매핑을 마이그레이션해야 합니다. 런북에 포함해야 할 필수 컷오버 전후 단계를 살펴보겠습니다.

컷오버 전후 필수사항: 데이터베이스 복제 그 이상 

컷오버 전 준비: 서버 수준 객체 마이그레이션

DMS는 사용자 데이터베이스 수준에서 작동하므로 서버 수준 객체는 자동으로 복제되지 않습니다. 컷오버 전에 대상 인스턴스에서 수동으로 만들어야 합니다.

• sp_help_revlogin을 사용하여 소스에서 로그인을 스크립팅하고 대상 인스턴스에서 다시 만듭니다.

• SQL Server 에이전트 작업 및 서버 수준 객체: DMS는 서버 인스턴스 상태가 아닌 데이터베이스를 복제하므로 사용자 데이터베이스 외부의 객체는 소스에서 스크립팅하여 대상 Cloud SQL 인스턴스에 배포해야 합니다. SQL Server Management Studio(SSMS)에서 소스 인스턴스에 연결하고 객체 탐색기에서 객체로 이동한 후 마우스 오른쪽 버튼을 클릭하고 Script [Object] as > CREATE To > New Query Window / File을 선택합니다.

  • SQL Server 에이전트 작업(SQL Server Agent > Jobs): 생성된 스크립트를 검사하여 작업 단계가 온프레미스 파일 경로 또는 지원되지 않는 OS 종속 항목을 참조하지 않는지 확인합니다.

  • 연결된 서버(Server Objects > Linked Servers): 정확히 동일한 스크립팅 접근 방식을 따릅니다. 배포하기 전에 Cloud SQL 인스턴스에서 cloudsql.linked_servers 데이터베이스 플래그를 사용 설정해야 합니다.

  • 확장 이벤트(Management > Extended Events > Sessions): 동일한 스크립팅 접근 방식을 따릅니다.

• TDE가 사용 설정된 인스턴스의 경우 미리 소스에서 TDE 인증서를 내보내고 대상에서 TDE 인증서를 가져와야 합니다. 

• 인스턴스 구성(예: 데이터베이스 플래그, Active Directory, Entra ID 구성 등): 소스 설정과 정확히 일치하도록 대상 인스턴스에서 수동으로 구성해야 합니다.

• Polybase를 사용하는 경우 데이터베이스 범위 사용자 인증 정보가 올바르게 작동하려면 DMK를 다시 암호화해야 합니다.

컷오버 후 해결: 분리된 데이터베이스 사용자 해결

서버 인스턴스에 없거나 잘못 구성된 SQL Server 로그인에 매핑된 데이터베이스 사용자는 인증할 수 없습니다. 이를 분리된 사용자라고 합니다. 대상 인스턴스에서 생성된 로그인은 마이그레이션된 데이터베이스에 보존된 소스 SID와 일치하지 않는 고유한 보안 식별자(SID)를 갖게 되므로 기본적으로 사용자는 분리됩니다. 이 문제는 컷오버 후 대상 데이터베이스가 온라인 상태가 될 때 수동으로 다시 매핑하여 해결할 수 있습니다.

• 분리된 사용자 감지 및 재매핑: sp_help_revlogin을 사용하면 로그인 마이그레이션 중에 SID가 보존되지만, 다른 방법을 통해 대상 인스턴스에 로그인을 만들면 새로운 서버 수준의 SID가 생성됩니다. 이러한 SID는 DMS로 복원된 사용자 데이터베이스에 보관된 소스 SID와 다르기 때문에 데이터베이스 사용자는 컷오버 후 분리 상태가 되며 다시 매핑해야 합니다.

1. 분리된 사용자 감지: 각 대상 사용자 데이터베이스에 연결하고 Microsoft의 공식 분리된 사용자 문제 해결 가이드에서 진단 쿼리를 실행합니다.

2. 분리된 사용자 수정(ALTER USER): 쿼리에서 반환된 각 데이터베이스 연결 해제 사용자에 대해 해당 데이터베이스의 컨텍스트 내에서 다음 문을 실행하여 주 구성원과 해당 권한을 새 Cloud SQL 서버 로그인에 깔끔하게 다시 매핑합니다.

요약 및 다음 단계

DMS는 온프레미스 환경에서 Google Cloud로의 일회성 브리지 그 이상입니다. Cloud SQL 엔지니어의 툴킷에서 2일 차 운영을 위한 다목적 도구입니다. 엄격한 프로덕션 SLA로 인해 기본 디스크 축소를 위한 긴 유지보수 기간을 확보할 수 없는 경우, DMS는 안정적인 관리형 복제 파이프라인을 제공하여 최소한의 다운타임으로 스토리지 사용 공간을 적절한 크기로 조정하고 인프라 비용을 절감할 수 있도록 지원합니다.

SQL Server용 Cloud SQL을 DMS 소스로 구성하려면 공식 문서를 살펴보세요. Google Cloud에서 SQL Server를 처음 실행하는 경우 SQL Server용 Cloud SQL 소개를 확인해 보세요.