클라우드 이전(cloud migration)에 대한 종전의 논의는 주로 온프레미스 워크로드를 아마존 웹 서비스(AWS)나 마이크로소프트 애저와 같은 퍼블릭 클라우드로 이동시키는 작업을 다뤘다. 많은 기업들이 온프레미스 인프라 관리에서 벗어나기 위해 퍼블릭 클라우드로 이동하는 것을 선호했기 때문이다. 결과적으로 온프레미스에서 퍼블릭 클라우드로의 마이그레이션을 돕는 가이드와 도구가 풍부했다.

그러나 어느덧 기업 중 약 절반이 퍼블릭 클라우드에 워크로드를 보유하고 있는 상황이다. 온프레미스 서버실이나 프라이빗 데이터센터에서 퍼블릭 클라우드 환경으로 애플리케이션과 데이터를 이동하는 작업이 관심사에서 밀려났다. 대신 기업들은 새로운 과제에 직면하고 있다: 한 퍼블릭 클라우드에서 다른 퍼블릭 클라우드로의 이전이다.

그러나 클라우드 간 이전은 비교적 새로운 유형이기에 이를 안내하는 자원이 드물다. 몇몇 클라우드 제공업체가 관련 도구(예: AWS 기반 서버 인스턴스를 애저로 이동할 수 있는 애저 마이그레이트(Azure Migrate), 반대 방향으로 이동할 수 있는 AWS 서버 마이그레이션 서비스(AWS Server Migration Service) 등)를 제공하고 있기는 하지만 한계가 있다. 복잡한 네트워크 구성 재구성이나 제한된 대역폭을 가진 네트워크 연결을 통해 수백 테라바이트 규모의 데이터를 이동해야 하는 문제 등은 해결하지 못한다.

또한 클라우드 마이그레이션에 대한 가이드 중 클라우드 간 마이그레이션을 수행하는 방법에 대한 베스트 프랙티스를 제공하는 사례는 거의 없다.

이 글을 작성하는 이유는 기업이 한 퍼블릭 클라우드에서 다른 퍼블릭 클라우드로 워크로드를 이동하는 작업을 효과적으로 수행하는 방법을 안내하기 위함이다. 여러 기업이 클라우드 간 마이그레이션 프로젝트를 계획하고 실행하는 데 도움을 준 경험을 바탕으로, 일반적으로 발생하는 과제와 이를 해결하는 방법을 정리했다.

퍼블릭 클라우드 간 이전 필요성의 대두

클라우드 간 마이그레이션 방법에 대한 팁으로 들어가기 전에, 먼저 앞서 물어야 할 질문이 있다. ‘왜 기업이 이 작업을 수행해야 할까?’

일반적인 시나리오 중 하나는 한 퍼블릭 클라우드를 사용하는 기업이 다른 클라우드를 사용하는 기업을 인수하거나 합병하는 경우다. 재편 후 IT 부서는 단일 클라우드 플랫폼으로 통합하기로 결정할 수 있다.

또한 특정 클라우드가 가격, 성능 또는 데이터 센터 위치 측면에서 더 이상 최적의 선택이 아니라는 판단이 있을 수 있다. 조직이 대체 퍼블릭 클라우드 플랫폼으로 이동하려는 경우다.

이 경우와 관련해 일부 워크로드를 한 퍼블릭 클라우드에 유지하며 다른 워크로드를 다른 클라우드에 배치하는 멀티클라우드 전략을 채택하면 되지 않느냐는 의문이 생길 수 있다. 이 전략에서는 모든 워크로드를 한 클라우드에서 다른 클라우드로 이동할 필요가 없기 때문이다. 멀티클라우드의 유연성이 단일 플랫폼에 묶이는 것보다 더 나은 선택이 아닐까?

답은 멀티클라우드가 분명한 장점(예: 비용과 성능의 균형을 최적화하기 위해 더 많은 클라우드 서비스 옵션 중에서 선택할 수 있는 유연성)을 가지고 있지만, 단점도 있다는 것이다. 가장 큰 단점은 복잡성 증가다: 더 많은 클라우드는 모니터링 및 관리해야 할 항목이 늘어나고, 관리해야 할 도구가 증가하며, 성능 및 보안 문제 발생 시 해결해야 할 사항도 늘어남을 의미한다.

멀티클라우드 환경은 일반적으로 각 클라우드 환경에 능통한 IT 인력이 필요로 한다. 한 가지 이상의 클라우드에 전문적인 지식을 갖춘 엔지니어를 찾기란 어렵다. 클라우드 간 이동을 시도하는 것보다 특정 퍼블릭 클라우드에서 완전히 벗어나기로 결정하는 것이 더 합리적일 수 있다.

클라우드 간 마이그레이션의 과제

한 퍼블릭 클라우드에서 다른 퍼블릭 클라우드로의 이동이 그리 어렵지 않아 보일 수 있다. 사실 모든 퍼블릭 클라우드는 동일한 핵심 서비스 유형을 제공하며, 동일한 개념을 기반으로 운영된다.

그러나 세부적으로 살펴보면, 퍼블릭 클라우드 플랫폼이 생각보다 일관되지 않은 현실을 이내 파악할 수 있다. 또한 마이그레이션을 복잡하게 만들거나 지연시킬 수 있는 추가적인 도전 과제들이 있다.

1. 서비스 기능 차이

퍼블릭 클라우드들의 기본 서비스 유형은 동일하지만, 그 구현 방식은 제각각이다. 즉, 워크로드를 한 클라우드에서 다른 클라우드로 단순히 이동시켜도 완벽하게 작동할 것이라고 기대하면 곤란하다. 구성 설정을 전면적으로 재구성해야 할 수도 있다.

예를 들어 코스모스DB와 다이나모DB를 살펴본다. 이 두 서비스는 각각 애저와 AWS에서 제공하는 관리형 NoSQL 데이터베이스다. 고수준에서는 동일한 기능을 제공하다. 하지만 내부적으로는 복제나 인덱싱과 같은 작업을 처리하는 방식이 서로 다르다. 또한 가격 구조도 다르며, 한 서비스에서 성능을 최적화한 구성 설정이 다른 서비스에서도 동일한 결과를 보장하지 않는다. 이 밖의 여러 요인으로 인해 코스모스에서 데이터를 추출해 다이나모DB에 그대로 옮길 수 없다. 데이터를 오프라인으로 전환하고 변환한 후 결과를 다이나모DB로 이동하는 복잡한 마이그레이션 프로세스를 수행해야 한다. 데이터베이스 구성과 데이터 구조에 대한 주요 변경이 필요할 수도 있다.

2. 지연 시간 문제

퍼블릭 클라우드 내에서 데이터를 이동하는 속도는 해당 워크로드나 서비스가 위치한 지역에 크게 달라진다. 예를 들어, 동일한 대륙 내 클라우드 지역 간 데이터 이동은 세계 다른 지역 간 데이터 전송보다 지연 시간이 짧을 수 있다.

각 클라우드 제공업체의 지역이 서로 다르기 때문에, 지역을 전략적으로 선택하지 않거나 구성하지 않으면 클라우드 마이그레이션 후 지연 문제가 발생할 수 있다. 원본 클라우드에서 사용한 지역과 동일한 지역에 위치한 지역을 선택하더라도, 각 클라우드 제공업체의 데이터센터 위치가 다르기 때문에 클라우드 내 지연 속도가 달라질 수 있다.

지연 문제는 다른 시나리오에서도 발생할 수 있다. SaaS 서비스나 온프레미스 애플리케이션을 사용하는데, 이러한 서비스나 애플리케이션이 조직의 퍼블릭 클라우드 환경에 호스팅된 리소스와 데이터를 전송하거나 수신해야 하는 경우다. 이 경우, SaaS 및 온프레미스 리소스가 호스팅되는 위치와 각 클라우드 제공업체의 데이터센터 간의 거리 차이는 전송 네트워크 속도와 지연에 영향을 미칠 수 있다. 따라서 조직의 전체 IT 인프라 전반에 걸친 클라우드 의존성과 상호 의존성을 이해하는 것이 필수적이다.

3. 자동화 재구축

클라우드 업체들은 워크로드를 통합하고 데이터를 이동하는 데 도움이 되는 자동화 도구를 제공한다. 불행히도 이러한 도구들은 일반적으로 해당 클라우드에서만 동작한다, 클라우드 서비스 고유의 구성 설정 및 언어에 의존하는 도구(AWS의 경우 AWS 컨피그, 클라우드포메이션 또는 SNS 등)에 제한적이다.

즉 거의 모든 경우 자동화 도구를 한 클라우드에서 다른 클라우드로 단순히 이동할 수 없다. 번역하거나 재구축해야 한다. 자동화 도구가 클라우드에 독립적인 제3자 솔루션인 경우만 예외다. 이 경우에도 구성 설정을 업데이트해야 할 수 있다. 왜냐하면 한 클라우드에서 작동하는 것이 다른 클라우드에서는 작동하지 않을 수 있기 때문이다.

4. 비용 변동

클라우드 간 서비스 유형이 유사하더라도 클라우드별 가격 세부 사항은 크게 다를 수 있다. 결과적으로 한 클라우드에서 비용 대비 성능 측면에서 최적화된 워크로드 구성은 다른 클라우드에서는 비효율적일 수 있다. 이는 마이그레이션 과정에서 새로운 클라우드의 가격 세부 사항을 평가하지 않고 구성 변경을 수행하지 않으면 비용 낭비가 발생할 수 있음을 의미한다.

5. 네트워크 대역폭 제한

클라우드 간 마이그레이션 시 데이터를 이동하는 가장 간단한 방법은 VPN 연결의 사용니다. 불행히도 VPN 연결은 클라우드 제공업체의 퍼블릭 인터넷을 사용하기 때문에 데이터 전송 성능이 제한된다. 또한 대량의 데이터를 이동할 경우 전용 연결보다 훨씬 더 비용이 많이 들 수 있다.

이러한 이유로 클라우드 간 마이그레이션에 테라바이트 규모의 데이터가 포함된다면 심각한 로지스틱스 및 비용 장벽에 직면할 수 있다.

퍼블릭 클라우드 간 마이그레이션 간소화하기

마법 같은 해결책이 있다면 좋겠지만, 그런 것은 없다. 현실적으로 한 퍼블릭 클라우드에서 다른 퍼블릭 클라우드로 이동하는 것은 복잡하며, 어떤 방법을 사용하더라도 많은 시간과 노력이 요구된다.

그러나 기술과 베스트 프랙티스를 활용하면 이 과정을 최대한 원활하게 만들 수 있습니다. 다음은 필자가 추천하는 방법이다.

계획, 계획, 그리고 계획

클라우드 간 마이그레이션을 신중하게 계획하는 것의 중요성을 강조해도 지나치지 않다. 철저한 계획을 수립하고, 가짜 워크로드를 사용한 모의 마이그레이션을 수행해 테스트한 후 예상과 달리 작동하지 않는 부분을 파악하고 계획을 재수립해야 한다. 계획에 투자하는 시간이 많을수록 마이그레이션 과정에서 예상치 못한 장애물에 부딪힐 위험이 줄어든다.

현실적인 일정 수립

일정 기대치를 현실적으로 설정하는 것도 중요하다. 종종 최고 경영진이 마이그레이션에 소요될 시간을 지시하지만, 이들은 마이그레이션 프로젝트의 복잡성을 완전히 이해하지 못할 수 있다.

고위층이 원하는 것보다 마이그레이션이 훨씬 더 오래 걸릴 수 있음을 투명하게 밝히는 것이, 일정을 계속 연기해야 하는 상황보다 나은 선택이다.

비핵심 워크로드를 먼저 마이그레이션

이전 작업을 시작할 때, 개발 및 테스트 단계에 있는 비핵심 워크로드부터 시작하는 것이 좋다. 계획상의 누락으로 인해 문제가 발생할 경우, 비핵심 워크로드에서 문제를 발견하는 편이 낫기 때문이다. 핵심 애플리케이션과 데이터는 이전 후반 단계로 미룬다.

새로운 배포를 일시 중단

클라우드 마이그레이션 시 중요하지만 자주 간과되는 고려 사항은 마이그레이션 기간 동안 애플리케이션의 새로운 배포, 플랫폼 수정 또는 구성 변경을 일시 중단하는 것이다.

개발자가 한 클라우드에 애플리케이션의 새 버전을 배포하는 상황과 이전 버전을 다른 클라우드로 이동 중인 상황이 겹치면 문제가 발생할 수 있다. 이 경우 마이그레이션을 다시 수행해야 한다. 마찬가지로 마이그레이션 중 한 클라우드 플랫폼에 적용된 변경 사항은 새로운 플랫폼에서도 재현해야 하며, 이는 불필요한 복잡성을 초래한다.

이 문제를 방지하려면 개발 팀이 마이그레이션 일정 및 상태에 포함되도록 한다.

인터커넥션 서비스 활용

퍼블릭 클라우드 간의 인터넷 연결 속도는 상대적으로 느리지만, 대역폭을 늘리고 마이그레이션 속도를 높이기 위해 클라우드 인터커넥션을 사용할 수 있다. 인터커넥션 솔루션(Megaport, NuSummit, Equinix Fabric 등)은 클라우드 간 전용 고대역폭 연결을 제공하여 데이터를 훨씬 빠르게 마이그레이션할 수 있도록 해준다.

인터커넥트의 비용이 저렴하지는 않지만, 마이그레이션이 완료되면 비활성화할 수 있으므로, 클라우드 간 마이그레이션을 가속화하는 단기적인 해결책으로 이 서비스를 활용하지 않을 이유가 없다.

클라우드 간 마이그레이션: 복잡하지만 필수적인 과정

현재의 애플리케이션과 데이터를 호스팅하는 클라우드 서비스가 조직에 영원히 최적화된 솔루션인 이상적인 상황은 기대할 수 없다. 현실에서는 현재 사용 중인 클라우드가 더 이상 최상의 선택이 아니게 되는 경우가 자주 발생하며, 이로 인해 새로운 퍼블릭 클라우드로 마이그레이션해야 할 필요가 생긴다. 이 과정은 본질적으로 복잡하지만, 적절한 전략과 충분한 계획 수립을 통해 위험과 장애물을 피할 수 있다.

Scott Wheeler는 아스페리타스(Asperitas)의 클라우드 프랙티스 리드다. 기업을 대상으로 복잡하고 까다로운 클라우드 솔루션의 구현, 하이브리드 및 멀티 클라우드의 활용, 엔터프라이즈급 보안의 제공 업무를 지원한다.
[email protected]