클라우드를 향한 여정: 데이터 센터 마이그레이션을 위한 다년 계획 수립

* 본 아티클의 원문은 2021년 2월 18일 Google Cloud 블로그(영문)에 게재되었습니다.  

클라우드로의 데이터 센터 마이그레이션은 기존 하드웨어와 소프트웨어, 네트워킹, 운영을 새로운 환경으로 전환해야 하는 만큼 대체로 결코 만만치 않은, 수년이 걸리는 비즈니스 이니셔티브입니다. Google Cloud의 Professional Services Organization은 고객과의 공동작업을 통해 데이터 센터를 Google Cloud로 마이그레이션할 수 있도록 설계하고 지원하는 팀입니다. 지난 몇 년간 다수의 마이그레이션 여정에 참여한 경험을 토대로 Professional Services Organization은 일반적인 접근법을 고안했으며 그 과정에서 수많은 난관을 겪으며 교훈을 얻기도 했습니다. 이 블로그 게시물에서는 Professional Services Organization에서 추천하는 데이터 센터 마이그레이션 절차를 개략적으로 소개합니다. 추후 블로그 게시물을 통해 마이그레이션 중에서도 엔지니어링 및 프로그램 관리 마이그레이션 분야를 자세하게 다룰 예정입니다. 

마이그레이션 여정

데이터 센터 마이그레이션 여정을 시작하는 데는 비용 절감이나 클라우드 기반 비즈니스를 추구하는 것과 같은 저마다의 계기가 있습니다. 이러한 계기로 '데이터 센터 n개를 이 날짜까지 마이그레이션하기'와 같은 비즈니스 목표가 수립됩니다. 어떤 동기에서 출발했든, 마이그레이션을 실현하면서 가장 흔히 직면하는 도전과제는 위험을 효율적으로 관리하면서 데이터 센터를 성공적으로 마이그레이션하는 것입니다. 

이를 지원하기 위해 Google Cloud에서는 4가지 단계로 구성된 반복 가능한 마이그레이션 접근법을 개발했습니다. 바로 탐색, 계획 수립, 실행, 최적화입니다. 대부분의 데이터 센터 마이그레이션에서 이 반복 가능한 프레임워크를 활용하면 애셋을 파악하고, 다단계 마이그레이션 접근법으로 위험을 최소화하며, 배포 및 구성을 실행하고, 최종 상태를 최적화할 수 있습니다.  

1단계: 탐색

마이그레이션 접근법의 첫 단계는 탐색입니다. 이 단계에서는 Google Cloud가 조직의 데이터 센터팀과 협력하여 전체 데이터 센터 범위를 파악하고 문서화합니다. 파악하는 대상에는 기존 하드웨어 매핑, 소프트웨어 애플리케이션, 스토리지 레이어(데이터베이스, 파일 공유), 운영체제, 네트워크 구성, 보안 요구사항, 운영 모델(릴리스 주기, 배포 방법, 에스컬레이션 관리, 시스템 유지보수, 패치, 가상화 등), 라이선스 및 규정 준수 요구사항, 기타 관련 애셋이 포함됩니다. 

이 단계의 목표는 현재 데이터 센터 범위에 속한 모든 관련 애셋과 리소스의 세부정보를 확보하는 것입니다. 다음 단계의 종속 항목 매핑 및 마이그레이션 웨이브 계획에서 활용될 리소스 그룹 분류 역시 이러한 리소스에 포함됩니다. 예를 들어 데이터 센터 인벤토리를 작성할 때 다양한 운영 환경(프로덕션 및 비프로덕션), 종속 항목(제3자 소프트웨어, 도메인 컨트롤러 등), 마이그레이션 범위에 속한 제3자 시스템을 비롯한 애플리케이션 전반의 비즈니스 영향을 모두 파악해야 합니다. 

탐색 단계의 핵심 과정은 다음으로 구성됩니다.

• 데이터 센터 범위에 대한 '공유형' 인벤토리 작성: 클라우드 마이그레이션에 참여하는 모든 팀에서 마이그레이션 대상 애셋 및 리소스를 파악하고 있어야 합니다.
• 초기 GCP 기초 설정 설계 완료: 폴더 구성, Identity and Access Management 모델, 네트워크 관리자 모델 등 GCP 조직의 중앙 집중식 개념을 파악하는 작업을 포함합니다.

또한 탐색 단계 중에는 IT, 재무, 프로그램 관리 등 다른 내부 사업부와 부서 간 소통하여 향후 클라우드 여정을 지원할 수 있도록 변화에 맞춰 업무를 조율하는 것이 좋습니다. 물리적 데이터 센터를 Google Cloud에 마이그레이션할 때는 데이터 센터 직원이 Google Cloud의 관리 시스템 및 인프라를 지원할 수 있도록 교육을 받았는지를 고려해야 합니다. 이와 더불어 Google Cloud에서 사용할 서비스에 대한 서비스 수준 계약(SLA)을 재평가하고 조정해야 할 수 있습니다. 

2단계: 계획 수립

두 번째 단계는 계획 수립입니다. 계획 수립 단계에서는 탐색 단계에서 수집한 애셋과 결과물을 활용하여 리소스의 논리적 그룹인 마이그레이션 웨이브를 만들고 프로덕션 및 비프로덕션 환경에 순차적으로 배포합니다. 

경험에 따르면, 마이그레이션할 웨이브 순서를 결정할 때는 비프로덕션 마이그레이션 웨이브를 우선 목표로 삼는 것이 좋습니다. 이때 다음을 고려하세요.

• 현재 서버 인벤토리를 Google Cloud 머신 유형에 매핑: 일반적으로 현재의 각 워크로드는 컴퓨팅 성능, 메모리, 디스크가 유사한 머신 유형에서 실행됩니다.
• 타임라인: 마이그레이션의 목적은 무엇이며 목표로 하는 일정은 어떻게 되나요?
• 각 그룹의 워크로드: 마이그레이션 웨이브를 그룹화하는 기준은 무엇인가요? 비프로덕션 애플리케이션인가요? 아니면 프로덕션 애플리케이션인가요? 기능 기준(데이터베이스, 파일 공유, 애플리케이션)인가요?
• 코드 릴리스 주기: 마이그레이션 시기를 앞당기거나 늦추는 데 영향을 미칠 수 있으므로 예정된 모든 코드 릴리스를 고려하세요.
• 인프라 배포 및 테스트 기간: Google Cloud로 완전히 전환하기 전에 인프라를 테스트할 시간을 적절하게 고려하세요.
• 애플리케이션 종속 항목 개수: 일반적으로 종속 항목이 가장 적은 애플리케이션이 우선적인 마이그레이션 대상입니다. 이와 반대로, 여러 데이터베이스에 종속적인 애플리케이션은 나중에 마이그레이션하는 편이 좋습니다.
• 마이그레이션의 복잡성 및 위험성: 일반적으로, 단순한 분야부터 시작할 때 마이그레이션이 보다 성공적인 결과로 이어집니다.

마이그레이션 웨이브의 경우 예측 가능하고 간단한 워크로드로 먼저 시작해 확신을 얻는 편이 좋습니다. 예를 들어 여기서는 제일 먼저 파일 공유를, 다음으로 데이터베이스와 도메인 컨트롤러를, 마지막으로 앱을 마이그레이션할 것을 권장합니다.

계획 수립 단계는 IT 조직의 미래 모습을 설계하고 기존 역할을 Google Cloud의 핵심 워크로드를 지원하도록 변환하는 방법을 논의하는 단계이기도 합니다. 고객들이 흔히 하는 질문으로 '마이그레이션 후에 기존 직원 모델을 Google Cloud를 지원할 수 있도록 매핑하는 가장 좋은 방법이 무엇인가요?'가 있습니다. 대부분의 경우에는 기존 직원을 교육하는 방법과 마이그레이션 이후 조직의 미래 모습에 기반해 조정이 필요할 수 있는 부분을 논의합니다. 조직을 조정할 가장 적절한 시기는 마이그레이션 웨이브를 배포하기 시작할 때입니다.  

계획 수립 단계 중에 고려해야 할 또 한 가지 사항은 DevOps 및 SRE 관행을 구현할지 여부입니다. 많은 고객이 클라우드 마이그레이션 시기가 코드형 인프라 관행을 구축하고, 코드 빌드 및 릴리스를 지속적 통합/지속적 배포(CI/CD) 파이프라인과 통합하고, 나아가 내부 서비스 수준 지표(SLI)를 정의할 적기라고 생각합니다. 또한 이 시기에 고객은 보통 사고 관리 및 애플리케이션 지원 프로세스를 업데이트하는데 문제 해결과 사고 대응에 도움이 되는 Google Cloud 지원과 관련된 프로세스도 여기에 포함됩니다. 

3단계: 실행

세 번째 단계인 실행에서는 앞서 수립한 계획을 실천에 옮겨 결과물을 얻습니다. 실행 단계에서는 일련의 정확한 단계를 거치고 구성을 개발하는 데 주의해야 합니다. 대개 비프로덕션 및 프로덕션 마이그레이션 웨이브에서 같은 과정을 반복하기 때문입니다. 

실행 단계에서는 IAM, 네트워킹, 방화벽 규칙, 서비스 계정 등 인프라 구성요소를 제자리에 배치하고 올바르게 구성했는지 확인합니다. 또한 인프라 구성에서 애플리케이션을 테스트하여 데이터베이스, 파일 공유, 웹 서버, 부하 분산기, Active Directory 서버 등에 액세스되는지 확인합니다. 로깅 및 모니터링으로 애플리케이션이 지속적으로 원하는 성능을 내며 작동하는지 확인하는 과정도 이 단계에 포함됩니다. 

실행 단계의 성공 여부는 민첩한 애플리케이션 디버깅 및 테스트에 의해 좌우되며 마이그레이션 도중에 맞닥뜨릴 수 있는 장애물에 대한 장단기 대책을 세워 두는 것이 좋습니다. 실행 단계는 반복적인 작업이 동반되며 목표는 이러한 반복을 통해 애플리케이션을 새 인프라에서 완전히 테스트하는 것입니다.

4단계: 최적화

대규모 데이터 센터 마이그레이션 프로젝트의 마지막 단계는 최적화입니다. 워크로드를 Google Cloud로 마이그레이션하고 나면 주기적으로 검토하고 최적화할 계획을 세우는 것이 좋습니다. 이 단계 중에는 최적화 활동의 범위를 고려할 수 있습니다. 

• 머신 유형 및 디스크 크기 조절(비용 절감을 위해서든 성능 향상을 위해서든, Active Assist에서 자동으로 실행할 수 있도록 지원)
• Terraform을 활용하여 보다 민첩하고 예측 가능한 배포 구현
• 자동화를 개선하여 운영 오버헤드 감소 
• 로깅, 모니터링, 알림 도구와의 통합 개선
• 관리형 서비스를 도입하여 운영 오버헤드 감소

기존 데이터 센터 환경에서 클라우드로 마이그레이션하면 리소스 소비와 비용을 가시적으로 확인할 수 있습니다. Compute Engine을 예로 들자면, Google Cloud에서 향상된 비용 관찰 기능을 제공하고 CPU 코어 및 RAM에 대한 전반적인 비용을 표시합니다. 따라서 비용을 지불할 컴퓨팅 리소스를 보다 손쉽게 파악할 수 있습니다. 

Recommender API를 사용해 더 이상 필요하지 않거나 필요한 성능에 맞게 크기를 조정할 수 있는 가상 머신을 파악할 수도 있습니다. 선점형 VM도 컴퓨팅 운영 비용을 절감할 수 있는 방법입니다.

또는 Cloud Storage를 사용하면 사용 사례를 기반으로 스토리지 클래스(예: 표준, nearline, coldline, archive)의 이점을 활용해 수명 주기 및 보관 정책을 적용할 수 있습니다.  

첫걸음 내딛기

데이터 센터 전체를 마이그레이션하는 작업은 쉬운 작업은 아니지만 힘든 만큼 충분히 가치가 있습니다. 이 마이그레이션 프레임워크를 사용해 마이그레이션 프로세스를 여러 단계로 나누면 마지막 데이터 센터까지 빠른 시간 안에 해제할 수 있습니다. 이제까지 살펴본 내용의 핵심 사항을 요약하는 것으로 마무리하겠습니다. 

• 민첩성을 갖추는 데 초점 맞추기: 데이터 센터 마이그레이션에는 변동 요소가 많습니다. 중요한 개별 요소에 차질이 발생하면 데이터 센터 마이그레이션 타임라인이 목표에서 벗어나게 됩니다. 
• 손쉬운 부분부터 먼저 공략: 잘못된 구성을 해결하거나 누락된 인프라를 파악하기 쉬운 간단한 애플리케이션부터 마이그레이션하면서 확신을 얻으세요. 복잡한 대규모 애플리케이션부터 마이그레이션하는 것은 바람직하지 않습니다. 
• 이해관계자에게 일찍 알리기: 대부분의 데이터 센터는 '외부 사용자'가 있습니다. 사내 다른 사용자도, 조직 외부의 사용자도 여기에 해당합니다. 이해관계자들에게 마이그레이션에 대해 일찍 알리고, 마이그레이션을 지연시킬 수 있는 규정 준수 문제가 발생할 가능성이 없는지 확인하세요.
• 팀원들이 Google Cloud를 익힐 수 있도록 지원: 여기에는 GCP 학습 프로세스를 구축하는 것부터 테스트를 위한 샌드박스 공간 프로비저닝, 교육 기회 제공이 포함됩니다.