데이터 이동은 클라우드 마이그레이션에서 가장 까다로운 부분 중 하나입니다. 마이그레이션 중에는 데이터의 위치가 애플리케이션의 성능에 중대한 영향을 미칠 수 있습니다. 데이터를 마이그레이션하면서 그 데이터를 사용하는 서비스를 동시에 마이그레이션하지 않으면, 온프레미스와 클라우드 데이터센터 간에 거리를 두고 데이터에 액세스를 해야 하기 때문에 지연 시간과 처리량 문제가 발생할 위험이 있습니다.
또한 데이터 전송 중에 데이터가 변경되지 않고, 동기화 및 자체 일관성을 유지하려면, 밀접한 상관관계를 수립해둘 필요가 있습니다. 그렇지 않으면 애플리케이션의 다운타임이 발생할 수 있습니다. 전자의 경우, 마이그레이션을 수행하는 팀의 입장에서 기술적인 어려움이 있을 수 있는 문제이지만, 후자인 다운타임은 비즈니스 전체에서 결코 허용될 수 없는 문제입니다.
애플리케이션이 허용 가능한 수준의 성능을 지속적으로 유지하려면, 데이터와 데이터를 사용하는 애플리케이션을 반드시 동시에 이동해야 합니다. 그러나 서비스와 관련된 데이터를 언제, 어떻게 마이그레이션할지 결정하는 일은 그렇게 간단한 문제가 아닙니다. 기업들은 종종 클라우드 마이그레이션의 성공에 도움을 주는 마이그레이션 아키텍트의 전문지식에 의존합니다.
필수 확인: 뉴렐릭의 클라우드 도입 전략 계획 가이드
자체적으로 클라우드 아키텍트가 있는지와는 상관없이, 애플리케이션 데이터를 클라우드로 마이그레이션하려면 다음의 3가지 기본 전략이 필요합니다.
- 오프라인 복사 마이그레이션
- 마스터/읽기 복제본 전환 마이그레이션
- 마스터/마스터 마이그레이션
SQL 데이터베이스, noSQL 데이터베이스, 원시 데이터 파일 등 마이그레이션의 대상에 상관없이, 각 마이그레이션 방식마다 필요한 노력의 양이 다르고, 애플리케이션의 가용성에 미치는 영향도 다르며, 비즈니스에 대한 위험 요소들도 다릅니다. 기본적으로는 3가지 전략이 상당히 비슷하지만, 세부적으로는 보면 차이가 있습니다.
전략 1: 오프라인 복사 마이그레이션
오프라인 복사 마이그레이션은 가장 간단한 방법입니다. 온프레미스 애플리케이션의 작동을 중지하고, 온프레미스 데이터베이스의 데이터를 새 클라우드 데이터베이스로 복사한 다음 클라우드에서 애플리케이션을 다시 가동을 하는 것입니다.
오프라인 복사 마이그레이션은 간단하고, 쉽고, 안전하지만, 실행하기 위해서는 애플리케이션을 오프라인 상태로 전환해야 합니다. 규모가 큰 데이터세트의 경우 애플리케이션이 상당히 오랜 시간 동안 오프라인 상태가 되어야 하기 때문에, 고객과 비즈니스에 지장을 줍니다.
대부분의 애플리케이션의 경우, 오프라인 복사 마이그레이션에 필요한 다운타임이 허용되지 않습니다. 하지만 비즈니스에서 어느 정도의 다운타임을 허용할 수 있고, 데이터세트의 규모가 작은 경우라면 이 방법을 고려해볼 수 있습니다. 데이터를 클라우드로 마이그레이션하는 쉽고, 비용과 위험 부담이 가장 적은 방법이기 때문입니다.
전략 2: 마스터/읽기 복제본 전환 마이그레이션
마스터/읽기 복제본 전환 마이그레이션의 목표는 데이터 마이그레이션을 복잡하게 만들지 않으면서 애플리케이션의 다운타임을 줄이는 것입니다.
이러한 유형의 마이그레이션은 먼저 온프레미스 데이터센터에서 실행되는 데이터베이스의 마스터 버전으로 시작합니다. 그런 다음 클라우드에 데이터베이스의 읽기 복제본을 설정하고, 온프레미스 마스터에서 읽기 복제본으로 단방향 데이터 동기화를 수행합니다. 이 시점에서도 온프레미스의 마스터에는 모든 데이터 업데이트 및 변경 작업은 계속 수행을 합니다. 그러면 마스터가 변경된 내용을 클라우드 기반의 읽기 복제본과 동기화합니다. 마스터-복제본 모델은 대부분의 데이터베이스 시스템에서 보편적으로 사용됩니다.
애플리케이션을 클라우드에 마이그레이션하여 운영을 시작한 후에도 온프레미스 마스터에 계속에서 데이터 쓰기 작업을 수행합니다. 그러다가 미리 정해 놓은 시점에서 “전환”하여 마스터와 읽기 복제본의 역할을 바꿉니다. 클라우드 데이터베이스가 마스터가 되고 온프레미스 데이터베이스가 읽기 복제본이 되는 것입니다. 동시에 온프레미스 데이터베이스의 모든 쓰기 액세스 권한을 클라우드 데이터베이스로 이동합니다.
전환 중에 짧은 시간 동안 다운타임이 필요하지만, 오프라인 복사 방법을 사용할 때보다 다운타임이 현저히 짧습니다.
그러나, 짧은 시간이긴 하더라도 다운타임은 다운타임이기 때문에, 비즈니스에서 이러한 다운타임이 허용될 수 있는지 정확히 평가를 해야 합니다.
전략 3: 마스터/마스터 마이그레이션
3가지 데이터 마이그레이션 전략 중 가장 복잡하고 위험 부담도 가장 높습니다. 하지만 올바르게 구현할 경우 애플리케이션의 다운타임 없이 데이터를 마이그레이션할 수 있습니다.
이 방법은, 클라우드에 온프레미스 데이터의 복제본을 만들고 두 마스터 간의 양방향 동기화를 수행하여 온프레미스에서 클라우드로, 그리고 클라우드에서 온프레미스로 모든 데이터를 동기화합니다. 기본적으로 전형적인 멀티마스터 데이터베이스를 구성하는 것입니다.
양쪽 데이터베이스를 설정한 후에는 온프레미스 데이터베이스나 클라우드 데이터베이스 모두에서 데이터를 읽고 쓸 수 있으며, 둘 다 동기화 상태가 유지됩니다. 때문에, 데이터에 대해 걱정하지 않고 원하는 일정에 애플리케이션과 서비스를 개별적으로 이동할 수 있습니다.
실제로, 마이그레이션을 보다 효과적으로 제어하려면, 온프레미스와 클라우드 모두에서 애플리케이션의 인스턴스를 실행하고, 다운타임 없이 클라우드로 애플리케이션의 트래픽을 이동할 수 있습니다. 문제가 발생하면, 마이그레이션을 롤백하고 문제를 해결하는 동안 트래픽을 데이터베이스의 온프레미스 버전으로 리디렉션할 수 있습니다.
마이그레이션이 완료되면, 온프레미스 마스터의 사용을 중지하고 클라우드 마스터를 데이터베이스로 사용하면 됩니다.
결코 간단한 방법은 아닙니다. 멀티마스터 데이터베이스를 구성하는 일은 대단히 복잡하고, 데이터가 왜곡되거나 부적절한 결과가 발생할 위험도 있습니다. 예를 들어, 양쪽 마스터에서 동시에 동일한 데이터를 업데이트하려는 시도를 하면 어떻게 될까요? 또는 한 마스터에서 수행된 업데이트가 데이터를 동기화하기 전에 다른 마스터에서 데이터를 읽으려고 시도하면 어떻게 될까요?
그렇기 때문에, 이 모델은 애플리케이션의 데이터 액세스 패턴과 데이터 관리 전략이 이러한 방법을 지원할 수 있는 경우에만 사용해야 합니다. 또한 애플리케이션별 동기화와 동기화와 관련된 문제를 해결할 수 있는 동기화 해결 절차를 수립할 필요가 있습니다.
그러나 애플리케이션, 데이터 및 비즈니스가 이 마이그레이션 방법을 사용할 수 있는 역량이 있다면, 주저하지 말고 활용해야 합니다. 3가지 전략 중 가장 명확하고 쉬운 방법이기 때문입니다.
마이그레이션의 위험 경감
모든 데이터 마이그레이션에는 어느 정도의 위험, 특히 데이터 손상의 위험이 따릅니다. 마이그레이션이 진행 중인 동안에 데이터가 특히 더 위험합니다. 따라서 신속하고 단호하게 마이그레이션을 실행하는 것이 중요합니다. 과정이 완료되거나 완전히 롤백이 될 때까지 마이그레이션을 중지하면 안됩니다. 그리고 절대로 마이그레이션을 중간에 중단하면 안 됩니다. 절반만 마이그레이션된 데이터는 아무런 쓸모가 없기 때문입니다.
규모가 큰 데이터세트를 마이그레이션할 때는 특히 데이터가 손상될 위험이 큽니다. AWS Snowball과 같은 오프라인 데이터 복사 및 전송 도구는 대용량 데이터의 마이그레이션을 관리하는데 도움을 주지만, 마이그레이션하는 동안 애플리케이션의 데이터 사용 패턴에는 아무런 도움도 되지 않습니다. Snowball과 같은 전송 장치를 사용하더라도 앞서 설명한 마이그레이션 전략 중 하나를 사용해야 합니다.
모든 마이그레이션이 그렇지만, 마이그레이션의 전과 도중, 그리고 후에 애플리케이션이 어떤 식으로 작동할지 알 수 없으면, 문제가 발생해도 대처할 수 있는 방법이 없습니다. 마이그레이션 과정의 다양한 단계에서 애플리케이션이 어떻게 응답하는지 이해를 해야만 애플리케이션의 가용성을 유지하고 데이터를 안전하게 유지할 수 있습니다.
뉴렐릭 APM 및 뉴렐릭 인프라가 포함된 뉴렐릭 플랫폼으로 마이그레이션의 모든 측면에서 애플리케이션을 모니터링하면, 데이터를 훼손하지 않고 애플리케이션을 안전하게 유지할 수 있습니다. 이는 데이터 마이그레이션뿐만 아니라 마이그레이션의 모든 측면에서 아주 중요합니다.
이 블로그에 표현된 견해는 저자의 견해이며 반드시 New Relic의 견해를 반영하는 것은 아닙니다. 저자가 제공하는 모든 솔루션은 환경에 따라 다르며 New Relic에서 제공하는 상용 솔루션이나 지원의 일부가 아닙니다. 이 블로그 게시물과 관련된 질문 및 지원이 필요한 경우 Explorers Hub(discuss.newrelic.com)에서만 참여하십시오. 이 블로그에는 타사 사이트의 콘텐츠에 대한 링크가 포함될 수 있습니다. 이러한 링크를 제공함으로써 New Relic은 해당 사이트에서 사용할 수 있는 정보, 보기 또는 제품을 채택, 보증, 승인 또는 보증하지 않습니다.
