원해서가 아니라 어쩔 수 없이 마이그레이션해야 하는 경우도 있습니다. 기존 시스템은 결국 현대 비즈니스의 요구사항을 더 이상 충족할 수 없는 지점에 도달할 수 있으며, 이를 유지하는 것은 자산이 되기보다는 오히려 위험이 될 수 있습니다.

데이터베이스 마이그레이션이 필요한 몇 가지 주요 이유는 다음과 같습니다.

• 수명이 다한 하드웨어: 물리적 서버가 노후화되고 제조업체에서 더 이상 하드웨어 또는 운영체제를 지원하지 않습니다.
• 성능 병목 현상: 현재 데이터베이스 아키텍처가 데이터 볼륨이나 트래픽 급증을 처리할 수 없어 사용자에게 느린 경험을 제공합니다.
• 보안 및 규정 준수: 기존 시스템에는 오늘날의 규제 표준을 충족하는 데 필요한 최신 보안 기능, 패치 또는 감사 기능이 부족할 수 있습니다.
• 공급업체 종속: 독점적이고 비싸며 유연하지 않은 라이선스에 묶여 혁신을 이루거나 특정 요구사항에 가장 적합한 도구를 선택하는 데 제약이 있습니다.
• 데이터 사일로: 데이터가 격리된 온프레미스 시스템에 갇혀 있어 팀이 경쟁력을 유지하는 데 필요한 최신 분석 또는 AI 모델에 데이터를 제공하기가 어렵습니다.

기존 아키텍처가 더 이상 운영 요구사항을 지원할 수 없는 경우 비즈니스를 안전하고 효율적으로 운영하기 위한 다음 단계는 마이그레이션입니다.

데이터베이스를 이전할 때 동종 및 이기종이라는 용어를 자주 듣게 됩니다. 차이점을 이해하면 기술팀이 수행해야 하는 작업량을 계획하는 데 도움이 됩니다.

데이터를 마이그레이션하는 데는 4가지 일반적인 전략이 있습니다. 클라우드 마이그레이션 전략을 방문하여 심층 분석 및 권장 전략을 확인하세요.

• 재호스팅: 리프트 앤 시프트 데이터를 마이그레이션하는 가장 간단한 방법으로, 일반적으로 나머지 애플리케이션 스택과 함께 기존 데이터베이스를 다른 환경으로 복사합니다. [동종]
• 리플랫폼: 리프트 및 최적화 이 전략은 데이터베이스, 애플리케이션, 가상 머신을 복사한 다음 새로운 클라우드 환경에 맞게 최적화합니다. 상용 데이터베이스에서 AlloyDB와 같은 PostgreSQL 호환 데이터베이스로 마이그레이션하는 경우와 같이 이기종 마이그레이션이 가능합니다. [동종/이기종]
• 리팩터링: 이동 및 개선 리팩터링 클라우드 마이그레이션 전략은 클라우드 네이티브 원칙에 맞게 애플리케이션을 재설계하는 것으로, 애플리케이션 코드 자체를 변경해야 합니다. [일반적으로 이기종]
• 재빌드. 재빌드 클라우드 마이그레이션 전략은 아키텍처와 애플리케이션을 클라우드용으로 완전히 다시 작성합니다. 애플리케이션에 따라 리팩터링보다 비용이 저렴할 수 있습니다. [일반적으로 이기종]

사실상 어느 두 위치 간에도 데이터베이스를 마이그레이션할 수 있지만 대부분의 마이그레이션은 온프레미스에서 클라우드로 또는 한 클라우드에서 다른 클라우드로 이루어 집니다.

기업이 클라우드(또는 다른 클라우드 제공업체)로 마이그레이션하는 이유는 다양합니다.

• 더 빠른 애플리케이션 개발
• 향상된 성능 및 확장성 
• 비용 절감
• 보안
• 더 광범위한 기능, 특히 AI 관련 기능
• 기존 라이선스 데이터베이스에서 흔히 볼 수 있는 온프레미스 자본적 지출(CapEx)에서 클라우드 서비스에서 흔히 볼 수 있는 운영 지출(OpEx)로 전환

클라우드로 마이그레이션할 때의 이점을 자세히 알아보세요.

많은 조직이 위에서 설명한 이유로 온프레미스 워크로드를 클라우드로 이전하고 있습니다. 온프레미스에서 마이그레이션하는 경우 클라우드 간 마이그레이션에 비해 추가적인 고려사항이 필요합니다.

온프레미스 워크로드를 마이그레이션하는 일반적인 전략은 전체 워크로드를 클라우드로 복사하는 재호스팅입니다. 이렇게 하면 클라우드 마이그레이션과 관련된 보안, 안정성, 일부 비용 혜택을 누릴 수 있습니다. 

하지만 이 전략은 기존의 비효율성을 온프레미스 아키텍처에서 클라우드 인프라로 그대로 이전하는 효과도 있습니다. 따라서 클라우드 네이티브 아키텍처와 관련된 더 큰 비용 절감 효과와 효율성을 놓치게 될 수 있습니다. 재해 복구, 분석 통합, AI/ML 서비스, 파트너 서비스 마켓플레이스 등의 영역에서 클라우드의 풍부한 기능을 놓칠 수도 있습니다.

마이그레이션 중, 특히 다양한 유형의 환경 간에 데이터 보안을 유지해야 합니다. 최고의 보안을 보장하는 한 가지 방법은 신뢰할 수 있는 데이터베이스 마이그레이션 서비스를 사용하는 것입니다.

데이터 및 데이터베이스 마이그레이션은 복잡할 수 있습니다. 기업의 데이터는 물론 조직과 직무가 새로운 아키텍처로 원활하게 이전되도록 하는 것이 중요합니다. 잘못 수행할 경우 데이터 손실, 워크로드가 제대로 실행되지 않음, 보안 문제가 발생할 수 있습니다.

권장사항

• 데이터를 이해하세요. 특정 비즈니스 사례와 애플리케이션에 필요한 것이 무엇인지 파악하는 것이 중요합니다.
• 비즈니스의 방향을 평가하세요. 확장성을 고려하는 것은 적절한 아키텍처와 제공업체를 선택하는 데 핵심입니다. 
• 기능 플래그로 테스트하세요. 기능 플래그를 사용하여 먼저 소규모 사용자 그룹에 새 데이터베이스를 출시합니다. 이를 통해 정식 출시 전에 시스템을 안전하게 테스트할 수 있습니다.
• 상황에 맞는 적절한 데이터 마이그레이션 전략을 선택하세요.
• 최적의 성능을 보장하기 위해 데이터 마이그레이션 계획을 신중하게 따르세요.

프로세스를 자세히 알아보려면 데이터 마이그레이션의 개념 및 원칙과 데이터 마이그레이션 프로세스 설정 및 실행을 읽어보세요.

세부정보는 구체적인 비즈니스 사례에 따라 다르지만 성공적인 마이그레이션의 기본 단계는 다음과 같습니다.

1. 현재 모든 데이터가 어디에 있는지, 어떤 형식인지, 마이그레이션 후에는 어디에 있어야 하는지 파악합니다. 모든 데이터를 마이그레이션할 필요가 없다고 판단하고 기존 데이터를 보관처리하거나 삭제할 수 있습니다. 이 단계는 마이그레이션의 잠재적 위험을 파악하는 중요한 시기이기도 합니다.
2. 마이그레이션 전략을 계획합니다. 가장 적합한 마이그레이션 전략을 결정하고, 업무 시간 중에 다운타임이 발생할 수 있는지 여부를 확인하고, 예산을 책정합니다. 
3. 마이그레이션을 실행합니다. 구현을 위해 마이그레이션 서비스를 사용하는 것이 좋습니다.
4. 컷오버 전에 새 시스템을 테스트하세요. 이를 통해 적절하게 작동하지 않는 워크로드를 식별하고 문제를 해결할 수 있습니다. 두 데이터베이스를 동시에 실행해야 할 수 있으며, 이 경우 한 시스템에서 다른 시스템으로 데이터를 복제해야 합니다. 모든 워크로드가 새 데이터베이스에서 예상대로 작동하는지 확인한 후에만 기존 시스템을 종료할 수 있습니다.

마이그레이션 단계의 수는 조직의 기존 설정과 일정에 따라 다릅니다. 예를 들어 자체 관리형 온프레미스 배포에서 관리형 클라우드 서비스로의 마이그레이션은 한 단계로 완료할 수 있습니다. 또는 시간적 여유가 없다면 먼저 클라우드의 자체 관리형 데이터베이스로 마이그레이션한 다음 완전 관리형 솔루션으로 전환할 수 있습니다.

기업에서 데이터베이스 마이그레이션을 자주 수행하지 않는 것이 좋습니다. 마이그레이션을 최대한 활용하려면 다음과 같은 몇 가지 주요 질문을 고려해야 합니다.