Google Cloud로 마이그레이션: 마이그레이션 계획 검증을 위한 권장사항

Last reviewed 2024-11-08 UTC

이 문서에서는 워크로드를 Google Cloud로 마이그레이션하는 계획의 유효성을 검사하기 위한 권장사항을 설명합니다. 이 문서는 마이그레이션 계획의 유효성 검사할 수 있는 가능한 모든 권장사항을 나열하지 않으며 성공을 보장하지 않습니다. 대신 잠재적 변경사항과 마이그레이션 계획 개선 사항에 대한 토론을 촉진하는 데 도움이 됩니다.

이 문서는 온프레미스 환경, 비공개 호스팅 환경 또는 다른 클라우드 제공업체에서 Google Cloud로 마이그레이션하려는 경우에 유용합니다. 이 문서는 마이그레이션 기회를 살펴보고 마이그레이션 과정을 미리 알아보고자 할 때 유용합니다.

이 문서는 Google Cloud로 마이그레이션에 대해 여러 편으로 구성된 다음 시리즈 중 일부입니다.

평가

워크로드 및 환경을 완벽하게 평가하면 워크로드와 환경을 심층적으로 이해하는 데 도움이 됩니다. 이러한 이해를 통해 Google Cloud로 마이그레이션하는 도중과 이후에 발생하는 문제의 위험을 최소화할 수 있습니다.

전체 평가

평가 단계를 따르는 단계로 진행하기 전에 워크로드와 환경 평가를 완료합니다. 전체 평가를 수행하려면 자주 간과되는 다음 항목을 고려하세요.

  • 인벤토리: 마이그레이션할 워크로드의 인벤토리가 최신 상태이고 평가를 완료했는지 확인합니다. 예를 들어 평가에 사용할 소스 데이터의 최신 상태와 안정성, 그리고 데이터 격차를 고려합니다.

  • 다운타임: 다운타임을 감당할 수 있는 워크로드와 다운타임이 발생할 수 있는 최대 시간을 평가합니다. 다운타임이 거의 또는 전혀 없는 상태에서 워크로드를 마이그레이션하는 것은 다운타임을 감당할 수 있는 워크로드를 마이그레이션하는 것보다 어렵습니다. 다운타임이 없는 마이그레이션을 완료하려면 마이그레이션할 각 워크로드에 중복을 설계하고 구현해야 합니다. 이러한 중복 인스턴스도 조정해야 합니다.

    워크로드가 감당할 수 있는 다운타임을 평가할 때 제로 다운타임 마이그레이션의 비즈니스 이점이 추가된 마이그레이션 복잡성보다 큰지 평가합니다. 가능하면 워크로드에 제로 다운타임 요구사항을 만들지 마세요.

  • 클러스터링 및 중복화: 클러스터링과 중복을 지원하는 워크로드를 평가합니다. 워크로드에서 클러스터링과 중복을 지원하는 경우 원본 환경 및 대상 환경과 같은 다양한 환경에서도 워크로드 인스턴스를 여러 개 배포할 수 있습니다. 클러스터링 및 중복 배포는 제한된 개입으로 워크로드가 서로 조정되므로 마이그레이션을 간소화할 수 있습니다.

  • 구성 업데이트: 워크로드 구성을 업데이트하는 방법을 평가합니다. 예를 들어 마이그레이션하려는 각 워크로드의 구성에 업데이트를 제공하는 방법을 고려합니다. 워크로드를 대상 환경으로 마이그레이션하는 동안 워크로드 구성을 업데이트해야 할 수 있으므로 이러한 고려 사항은 마이그레이션의 성공에 중요합니다.

  • 여러 평가 보고서 생성: 평가 단계 중에는 여러 시나리오를 고려할 수 있도록 평가 보고서를 여러 개 생성하는 것이 유용할 수 있습니다. 예를 들어 최대 사용 기간 및 이후 기간과 같이 워크로드의 여러 다른 부하 프로필을 고려하기 위해 보고서를 생성할 수 있습니다.

워크로드에서 지원하는 장애 모드 평가

예외적인 상황에서 워크로드 동작 방식을 알면 워크로드가 복구할 수 없는 조건에 노출되지 않도록 할 수 있습니다. 평가의 일환으로 워크로드가 지원하고 자동으로 복구할 수 있는 장애 모드와 그 영향과 개입해야 하는 장애 모드에 대한 정보를 수집합니다. 예를 들어 다음과 같은 가능한 장애 모드에 대한 질문을 고려할 수 있습니다.

  • 워크로드가 네트워크와의 연결이 끊어지면 어떻게 되나요?
  • 워크로드가 중지된 시점부터 작업을 재개할 수 있나요?
  • 워크로드 또는 종속 항목의 성능이 충분하지 않으면 어떻게 되나요?
  • 아키텍처에 동일한 식별자가 있는 워크로드가 2개 있으면 어떻게 되나요?
  • 예약된 작업이 실행되지 않으면 어떻게 되나요?
  • 두 워크로드에서 동일한 요청을 처리하면 어떻게 되나요?

지원되지 않는 장애 모드의 또 다른 소스는 마이그레이션 계획 자체일 수 있습니다. 마이그레이션 계획에 특정 조건의 성공에 의존하는 단계와 조건이 충족되지 않은 경우의 대응책이 포함되어 있는지 여부를 확인합니다. 이러한 유형의 조건이 포함된 계획은 계획 자체가 실패하거나 마이그레이션 중에 개별 구성요소가 실패할 수 있음을 나타낼 수 있습니다.

이러한 장애 모드와 그 영향을 평가한 후에는 실패를 시뮬레이션하고 이러한 장애 모드를 에뮬레이션하는 오류를 삽입하여 중요하지 않은 환경에서 발견 항목의 유효성을 검사합니다. 예를 들어 워크로드가 네트워크 연결 손실 후 자동으로 복구되도록 설계된 경우 연결을 강제로 중단하고 나중에 복원하여 자동 복구의 유효성을 검사합니다.

데이터 처리 파이프라인 평가

워크로드 평가는 다음 질문에 답할 수 있어야 합니다.

  • 리소스 크기가 마이그레이션에 맞게 올바르게 지정되었나요?
  • 워크로드에 필요한 데이터를 마이그레이션하는 데 얼마나 많은 시간이 필요하나요?
  • 대상 환경에서 전체 데이터 볼륨을 수용할 수 있나요?
  • 워크로드가 수요 급증 또는 특정 기간 동안 생성된 데이터 양의 급증을 수용해야 할 때 어떻게 동작하나요?
  • 수요가 급증하거나 워크로드에서 생성되는 데이터 양이 급증하는 경우 지연 시간 증가 또는 응답 지연과 같은 부작용이 있나요?
  • 워크로드가 시작된 후 예상된 성능 수준에 도달하는 데 시간이 필요한가요?

이 평가 결과는 워크로드가 충족하는 수요 모델과 워크로드가 지정된 기간에 생성하는 데이터인 경우가 많습니다. 이러한 모델을 생성하기 위해 데이터 포인트를 수집할 때 피크 및 비피크 시간 사이에 이러한 데이터 포인트가 크게 다를 수 있음을 고려합니다. 모니터링 방법과 대상에 대한 자세한 내용은 사이트 안정성 엔지니어링 교재의 서비스 수준 목표를 참조하세요.

마이그레이션할 각 워크로드를 업데이트하고 배포할 수 있는지 확인

마이그레이션하는 동안 마이그레이션하는 워크로드의 일부를 업데이트해야 할 수 있습니다. 예를 들어 문제의 수정사항을 배포하거나 문제의 원인이 되는 최근 변경사항을 롤백해야 할 수 있습니다. 마이그레이션하는 워크로드마다 변경사항을 적용하고 배포할 수 있는지 확인합니다. 예를 들어 소스 코드가 있는 워크로드를 마이그레이션하는 경우 소스 코드에 액세스할 수 있는지, 소스 코드를 필요한 만큼 빌드, 패키징, 배포할 수 있는지 확인합니다.

마이그레이션에 변경사항을 적용하거나 배포할 수 없는 워크로 (예: 독점 소프트웨어)가 있을 수 있습니다. 이 시나리오에서는 마이그레이션 계획을 리팩터링하여 이러한 워크로드를 마이그레이션한 후에 발생할 수 있는 문제를 완화합니다.

네트워크 인프라 평가

작동하는 네트워크 인프라는 마이그레이션의 기본 요소입니다. 네트워크 인프라를 마이그레이션 도구의 일부로 사용할 수 있습니다. 예를 들어 부하 분산기와 DNS 서버를 사용하여 마이그레이션 계획에 따라 트래픽을 전달할 수 있습니다.

마이그레이션 중 문제를 방지하려면 네트워크 인프라를 평가하고 마이그레이션을 지원할 수 있는 범위를 평가하는 것이 중요합니다. 예를 들어 다음과 같은 부하 분산 인프라에 대한 질문을 고려할 수 있습니다.

  • 부하 분산기를 다시 구성하면 어떻게 되나요?
  • 업데이트된 구성이 적용되는 데 얼마나 걸리나요?
  • 다운타임 없이 마이그레이션할 때 업데이트된 구성이 적용되기 전에 트래픽이 급증하면 어떻게 되나요?

부하 분산 인프라에 대한 질문을 검토한 후 다음과 같이 DNS 인프라에 대한 질문을 고려합니다.

  • 대상 환경을 가리키도록 어떤 DNS 레코드를 언제 업데이트해야 하나요?
  • 어떤 클라이언트에서 이러한 DNS 레코드를 사용하나요?
  • DNS 레코드가 업데이트되도록 TTL(수명)을 어떻게 구성하나요?
  • 마이그레이션 중에 DNS 레코드 TTL을 최소로 설정할 수 있나요?
  • DNS 클라이언트가 업데이트할 DNS 레코드의 TTL을 준수하나요? 예를 들어 마이그레이션에 구성한 TTL을 무시하는 클라이언트 측 DNS 캐싱이 애플리케이션에 있나요?
  • 이전을 완료한 후에도 원본 환경으로 향하는 트래픽이 감지되나요?

마이그레이션 계획

마이그레이션을 철저하게 계획하면 마이그레이션 도중과 후에 발생하는 문제를 방지하는 데 도움이 됩니다. 계획은 예기치 않은 태스크를 처리하는 수고를 줄이는 데에도 도움이 됩니다.

마이그레이션 계획의 각 단계에 대한 롤백 전략 개발

마이그레이션하는 동안 실행하는 마이그레이션 계획의 단계에서 예기치 않은 문제가 발생할 수 있습니다. 이러한 문제를 복구할 수 있도록 마이그레이션 계획의 단계마다 롤백 전략을 준비합니다. 서비스 중단 중에 시간이 손실되지 않도록 다음을 수행합니다.

  • 각 롤백 전략을 주기적으로 검토하고 테스트하여 롤백 전략이 작동하는지 확인합니다.
  • 마이그레이션 단계마다 최대 허용 실행 시간을 설정합니다. 이 허용 실행 시간이 만료되면 팀은 마이그레이션 단계를 롤백하기 시작합니다.

마이그레이션 계획 단계마다 롤백 전략이 있더라도 일부 단계에서 여전히 중단이 발생할 수 있습니다. 중단이 발생할 수 있는 단계에서는 롤백을 수행하더라도 데이터 손실과 같이 일종의 손실이 발생할 수 있습니다. 마이그레이션 계획의 어떤 단계가 중단될 수 있는지 평가합니다.

마이그레이션 계획 단계를 자동화한 경우 자동화가 실패하면 자동 단계마다 사전 계획된 절차가 있는지 확인합니다. 롤백 전략과 마찬가지로 미리 계획된 각 절차를 주기적으로 검토하고 테스트합니다.

마이그레이션의 일부로 통신 채널을 설정한다면 환경에 액세스하지 못하는 경우가 없도록 장애로부터 복구하는 데 사용할 수 있는 백업 채널을 프로비저닝합니다. 예를 들어 Partner Interconnect를 설정할 때, 마이그레이션 중에 프로비저닝 및 구성 중에 문제가 발생할 경우 공개 인터넷을 통해 백업 액세스를 설정할 수도 있습니다.

점진적 출시 및 배포 계획

마이그레이션 중에 발생할 수 있는 문제 범위를 줄이려면 대규모 변경사항을 방지하고 변경사항을 점진적으로 배포하도록 마이그레이션 계획을 설계합니다. 예를 들어 점진적 배포와 구성 변경사항을 계획합니다.

점진적 출시를 계획하는 경우 변경사항 적용으로 인한 예기치 않은 문제가 발생할 위험을 낮추려면 이러한 변경사항의 수와 크기를 최소화합니다. 첫 번째 소규모 출시 문제를 파악하고 해결한 후 커진 규모로 유사한 변경사항에 따라 후속 출시를 수행할 수 있습니다.

개발팀 및 운영팀에 알림

마이그레이션 중에 발생할 수 있는 문제의 영향을 줄이려면 마이그레이션할 워크로드를 담당하는 팀에 알림을 보냅니다. 또한 원본 환경과 대상 환경 모두의 인프라를 담당하는 팀에게 알림을 보냅니다.

팀이 근무하는 시간대가 서로 다른 경우 다음 사항을 확인하세요.

  • 팀은 해당 시간대를 적절하게 담당하고 단일 교대 근무 시간 동안 문제를 해결할 수 없을 수 있으므로 여러 연속 교대 근무를 담당합니다.
  • 팀은 발생할 수 있는 문제에 대한 자세한 정보를 수집할 준비가 되어 있습니다. 이 컬렉션은 다음 교대 엔지니어가 이전 교대 근무 업무와 그 이유를 완벽하게 이해할 수 있도록 해줍니다.
  • 특정 교대 근무에 대한 책임은 팀의 특정 사람들에게 있습니다.

대상 프로덕션 환경에서 개념 증명 리소스 삭제

평가의 일환으로 대상 환경을 사용하여 실험 및 개념 증명을 호스팅했을 수 있습니다. 마이그레이션하기 전에 이러한 실험 중에 만든 리소스를 삭제하고 대상 환경의 프로덕션 영역에서 개념 증명을 진행합니다.

마이그레이션이 진행되는 동안 대상 환경의 비프로덕션 영역에 리소스를 유지할 수 있습니다. 이렇게 하면 마이그레이션 중에 발생할 수 있는 문제에 대한 정보를 수집하는 데 도움이 될 수 있기 때문입니다. 예를 들어 마이그레이션 후에 프로덕션 워크로드에 영향을 미치는 문제를 진단하려면 프로덕션 워크로드의 구성 및 데이터 로그를 개념 증명과 실험의 증명 및 데이터 로그와 비교하면 됩니다.

마이그레이션을 완료하고 대상 환경이 예상대로 작동하는지 검증한 후에 대상 환경의 비프로덕션 영역에서 리소스를 삭제할 수 있습니다.

원본 환경을 안전하게 중단하기 위한 기준 정의

두 환경을 무기한 실행하는 비용을 피하려면 다음과 같이 원본 환경을 안전하게 중단하기 위해 충족해야 하는 조건을 정의하세요.

  • 백업, 고가용성, 재해 복구 메커니즘을 포함한 모든 워크로드가 대상 환경으로 성공적으로 마이그레이션됩니다.
  • 대상 환경으로 이전된 데이터는 일관되고 액세스 가능하며 사용할 수 있습니다.
  • 이전된 데이터의 정확성과 완전성이 정의된 표준을 충족합니다.
  • 원본 환경에 남아 있는 리소스는 마이그레이션 범위를 벗어난 워크로드의 종속 항목이 아닙니다.
  • 대상 환경에서 워크로드의 성능이 SLA 타겟을 충족합니다.
  • 모니터링 시스템에서 대상 환경으로 전달해야 하는 네트워크 트래픽이 원본 환경에 없다고 보고합니다.
  • 대상 환경에서 정의한 기간 동안 워크로드가 문제 없이 실행되면 더 이상 원본 환경으로 대체할 필요가 없습니다.

운영

마이그레이션 중에 원본 환경과 대상 환경을 효율적으로 관리하려면 운영 프로세스도 설계해야 합니다.

환경 모니터링

원본 환경과 대상 환경의 동작을 관찰하고 문제가 발생했을 때 이를 진단할 수 있도록 다음을 설정합니다.

  • 시나리오에 유용한 측정항목을 수집하는 모니터링 시스템
  • 워크로드 및 환경의 기타 구성요소에서 수행하는 작업의 흐름을 관찰하는 로깅 시스템
  • 문제가 있는 이벤트가 발생하기 전에 경고하는 알림 시스템

Google Cloud Observability는 통합 모니터링, 로깅 및 Google Cloud 환경에 대한 알림을 지원합니다.

워크로드와 종속 항목은 여러 환경에 걸쳐 있으므로 여러 환경에 모니터링 및 알림 도구를 여러 개 사용해야 할 수 있습니다. 워크로드를 지원하는 모니터링 및 알림 정책을 마이그레이션하는 시점을 고려합니다. 예를 들어 원본 환경이 특정 서버가 다운될 때 알리도록 구성된 경우 서버를 의도적으로 다운하면 알림이 트리거됩니다. 알림 트리거가 예상되지만 이는 도움이 되지 않습니다. 마이그레이션의 일환으로 원본 환경에 대한 알림을 지속적으로 조정하고 대상 환경에 맞게 다시 구성해야 합니다.

마이그레이션 관리

마이그레이션을 관리하려면 마이그레이션 성능을 검토하여 마이그레이션이 완료된 후 소급해서 사용할 수 있는 정보를 수집합니다. 정보를 수집한 후에는 이 정보를 사용하여 마이그레이션 성능을 분석하고 환경의 잠재적 개선 사항에 대한 데이터 포인트를 준비합니다.

예를 들어 마이그레이션 관리 계획을 시작하려면 다음 질문을 고려합니다.

  • 마이그레이션 계획의 각 단계가 얼마나 걸렸나요?
  • 예상보다 더 많은 시간이 소요된 마이그레이션 계획 단계가 있나요?
  • 누락된 단계나 점검사항이 있나요?
  • 마이그레이션 중에 부정적인 이벤트가 발생했나요?

다음 단계

참여자

작성자: 마르코 페라리 | 클라우드 솔루션 설계자