Google Cloud로 마이그레이션: 대규모 데이터 세트 전송

Last reviewed 2023-11-13 UTC

대다수의 고객은 Google Cloud 제품을 도입하는 첫 번째 단계로 데이터를 Google Cloud로 가져옵니다. 이 문서에서는 데이터 전송 계획부터 계획 구현 시 권장사항 사용에 이르기까지 전체 마이그레이션 과정을 살펴봅니다.

대규모 데이터 세트를 전송하려면 적절한 팀을 구성하고, 조기에 계획을 세우고, 실제 프로덕션 환경에 구현하기 전에 전송 계획을 테스트해야 합니다. 이러한 단계를 완료하는 데 전송 자체에 걸리는 시간만큼 소요될 수 있지만 준비 과정을 통해 전송 중 비즈니스 운영 중단을 최소화할 수 있습니다.

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

데이터 전송이란 무엇인가요?

이 문서에서 데이터 전송이란 데이터를 변환하지 않고 데이터를 이동하는 과정을 의미합니다. 즉, 파일을 객체로 이동하는 것입니다.

데이터 전송은 말처럼 간단하지 않습니다.

데이터 전송을 한 쪽에 파일을 놓고 다른 쪽에 파일이 나타날 때 까지 기다리는 하나의 거대한 FTP 세션이라고 생각하기 쉽습니다. 그러나 대부분의 엔터프라이즈 환경에서 전송 프로세스에는 다음과 같이 다양한 요소가 포함됩니다.

  • 전송 옵션을 결정하는 시점, 승인 얻기, 예기치 않은 문제 처리 등의 관리 시간을 고려한 전송 계획 수립
  • 전송 실행팀, 도구와 아키텍처의 승인 담당자, 데이터 이전을 통해 창출되는 가치, 데이터 이전으로 발생하는 중단에 대해 고민하는 비즈니스 이해관계자와 같은 조직 내 인력 조정
  • 리소스, 비용, 시간, 기타 프로젝트 고려사항을 기반으로 올바른 전송 도구 선택
  • '광신호 속도' 문제(충분하지 않은 대역폭) 등 데이터 전송 문제 극복, 실제 사용 중인 데이터 세트 이전, 이동 중인 데이터 보호 및 모니터링, 데이터가 성공적으로 전송되었는지 확인

이 문서의 목표는 성공적인 전송 이니셔티브를 시작하는 데 도움을 주는 것입니다.

다음 목록에는 이 문서에서 다루지 않는 다른 유형의 데이터 전송 프로젝트의 리소스가 나와 있습니다.

1단계: 팀 구성

일반적으로 전송을 계획하려면 다음 역할과 책임이 할당된 인력이 필요합니다.

  • 전송에 필요한 리소스 사용 설정: 스토리지, IT, 네트워크 관리자, 경영 후원자, 기타 전문가(예: Google 계정팀 또는 통합 파트너)
  • 전송 결정 승인: 데이터 소유자 또는 거버너(전송 대상 데이터 결정권자 관련 내부 정책), 법률 전문가(데이터 관련 규제), 보안 관리자(데이터 액세스 보호 방법 관련 내부 정책)
  • 전송 실행: 전송 실행팀 책임자, 프로젝트 관리자(프로젝트 실행 및 추적), 엔지니어링팀, 현장 수령 및 배송(어플라이언스 하드웨어 수령)

전송 프로젝트와 관련된 책임이 있는 담당자를 파악하고 필요에 따라 이들과 함께 계획 및 의사 결정 회의를 갖는 것이 중요합니다. 조직 수준의 계획 수립이 잘못되어 전송 이니셔티브 실행에 실패하는 경우가 많습니다.

이러한 이해관계자들의 프로젝트 요구사항과 의견을 수집하기가 어려울 수 있지만 계획을 수립하고 명확한 역할과 책임을 규정하면 성과로 나타납니다. 데이터의 모든 세부정보를 파악할 수는 없습니다. 팀을 구성하면 비즈니스의 요구사항을 보다 철저히 파악할 수 있습니다. 따라서 시간, 비용, 리소스를 투입하여 전송을 완료하기 전에 잠재적인 문제를 파악하는 것이 가장 좋습니다.

2단계: 요구사항 및 사용 가능한 리소스 수집

전송을 계획할 때는 먼저 데이터 전송 요구사항을 수집하고 전송 옵션을 설정하는 것이 좋습니다. 요구사항을 수집하려면 다음 절차를 따르세요.

  1. 이전할 데이터 세트를 파악합니다.
    • Data Catalog 같은 도구를 선택하여 함께 이전하고 사용할 논리 그룹으로 데이터를 분류합니다.
    • 조직 내 팀과 협력하여 이러한 그룹을 검증하고 업데이트합니다.
  2. 이전할 수 있는 데이터 세트를 파악합니다.
    • 규제, 보안 또는 기타 요인으로 인해 전송할 수 없는 데이터 세트가 있는지 여부를 고려합니다.
    • 데이터를 이전하기 전에 일부 데이터를 변환(예: 민감한 정보 제거 또는 데이터 재분류)해야 하면 Dataflow, Cloud Data Fusion 또는 Cloud Composer 같은 워크플로 조정 제품 사용을 고려합니다.
  3. 이전 가능한 데이터 세트의 경우 각 데이터 세트를 전송할 위치를 결정합니다.
    • 데이터를 저장하도록 선택한 스토리지 옵션을 기록합니다. 일반적으로 Google Cloud의 대상 스토리지 시스템은 Cloud Storage입니다. 애플리케이션을 준비하고 실행한 후 더 복잡한 솔루션이 필요한 경우에도 Cloud Storage는 확장성과 내구성이 가장 우수한 스토리지 옵션입니다.
    • 마이그레이션 후 어떤 데이터 액세스 정책을 유지관리해야 하는지 확인합니다.
    • 이 데이터를 특정 리전에 저장해야 하는지 여부를 결정합니다.
    • 대상 위치에서 이 데이터를 구조화하는 방법을 계획합니다. 예를 들어 소스와 동일하게 할지 아니면 다르게 할지 여부입니다.
    • 지속적으로 데이터를 전송해야 하는지 여부를 결정합니다.
  4. 이전 가능한 데이터 세트의 경우 어떤 리소스를 이전할 수 있는지 결정합니다.
    • 시간: 전송을 언제까지 완료해야 하나요?
    • 비용: 팀과 전송 비용으로 편성된 예산은 얼마인가요?
    • 인력: 누가 전송을 실행할 수 있나요?
    • 대역폭(온라인 전송): Google Cloud에서 사용 가능한 대역폭 중 전송에 할당할 수 있는 크기와 기간은 얼마인가요?

다음 계획 단계에서 전송 옵션을 평가하고 선택하기 전에 데이터 거버넌스, 조직, 보안 등 개선이 가능한 IT 모델 파트를 평가하는 것이 좋습니다.

보안 모델

데이터 전송 프로젝트의 일환으로 전송팀의 여러 구성원에게 Google Cloud 조직 내 새로운 역할이 부여될 수 있습니다. 데이터 전송 계획을 세울 때 Identity and Access Management(IAM) 권한과 IAM을 안전하게 사용하기 위한 권장사항을 검토하는 것이 좋습니다. 이러한 문제는 스토리지에 액세스 권한을 부여하는 방법에 영향을 미칠 수 있습니다. 예를 들어 규제상의 이유로 아카이브 처리된 데이터에 대한 쓰기 액세스에 엄격한 제한을 적용할 수 있지만 대다수의 사용자와 애플리케이션에서 테스트 환경에 데이터를 쓰도록 허용할 수 있습니다.

Google Cloud 조직

Google Cloud에서 데이터를 구조화하는 방법은 Google Cloud 사용을 어떻게 계획하는지에 따라 다릅니다. 애플리케이션을 실행하는 동일한 Google Cloud 프로젝트에 데이터를 저장하는 것도 가능하지만 관리 측면에서 최적의 방법은 아닙니다. 일부 개발자는 프로덕션 데이터를 볼 수 있는 권한이 없을 수 있습니다. 이 경우 개발자는 샘플 데이터에 대한 코드를 개발해야 하지만 권한을 가진 서비스 계정은 프로덕션 데이터에 액세스할 수 있습니다. 따라서 전체 프로덕션 데이터 세트를 별도의 Google Cloud 프로젝트에 보관한 다음 서비스 계정을 사용하여 각 애플리케이션 프로젝트의 데이터에 액세스하도록 허용할 수 있습니다.

Google Cloud는 프로젝트를 중심으로 구성됩니다. 프로젝트를 폴더로 그룹화하고, 폴더는 조직 아래에 그룹화할 수 있습니다. 역할은 프로젝트 수준에서 설정되고 액세스 권한은 Cloud Storage 버킷 수준에서 이러한 역할에 추가됩니다. 이 구조는 다른 객체 저장소 제공업체의 권한 구조와 일치합니다.

Google Cloud 조직 구성을 위한 권장사항은 Google Cloud 랜딩 영역의 리소스 계층 구조 결정을 참조하세요.

3단계: 전송 옵션 평가

데이터 전송 옵션을 평가하기 위해 전송팀은 다음과 같은 요소를 고려해야 합니다.

  • 비용
  • 전송 시간
  • 오프라인/온라인 전송 옵션
  • 전송 도구 및 기술
  • 보안

비용

데이터 전송과 관련된 대부분의 비용은 다음과 같은 항목에서 발생합니다.

  • 네트워킹 비용
    • Cloud Storage로의 인그레스는 무료입니다. 그러나 퍼블릭 클라우드 제공업체에서 데이터를 호스팅하는 경우 데이터 전송에 따른 이그레스 요금과 잠재적인 스토리지 요금(예: 읽기 작업)을 지불해야 할 수 있습니다. 이 요금은 Google 또는 다른 클라우드 제공업체로부터 수신하는 데이터에 적용됩니다.
    • 직접 운영하는 비공개 데이터 센터에서 데이터를 호스팅하는 경우 Google Cloud에 더 큰 대역폭을 설정하면 추가 비용이 발생할 수 있습니다.
  • 데이터 전송 중 및 전송 후 Cloud Storage의 저장 및 운영 비용
  • 제품 비용(예: Transfer Appliance)
  • 팀 구성 및 물류 지원을 위한 인적 비용

전송 시간

컴퓨팅 시 대량의 데이터를 전송할 때 네트워크의 하드웨어 제한을 강조하는 경우는 거의 없습니다. 이상적으로 1Gbps 네트워크에서는 1GB의 데이터를 8초 내에 전송할 수 있습니다. 이를 대규모 데이터 세트(예: 100 TB)로 확장하면 전송 시간은 12일이 됩니다. 대규모 데이터 세트를 전송할 때 인프라의 제한사항과 비즈니스에 영향을 미칠 수 있는 잠재적 문제를 테스트할 수 있습니다.

이전할 데이터 세트의 크기와 전송에 사용할 수 있는 대역폭을 고려하여 다음 계산기를 사용하여 전송에 걸리는 시간을 파악할 수 있습니다. 관리 시간의 특정 비율이 계산에 포함됩니다. 또한 효율적인 대역폭 효율성이 포함되어 있으므로 결과 수치가 보다 현실적입니다.

업무가 가장 바쁜 시간에는 회사 네트워크를 통해 대규모 데이터세트는 전송하지 않는 것이 좋습니다. 대규모 전송으로 인해 네트워크에 과부하가 걸리면 필요하거나 미션 크리티컬 업무를 아무도 완료하지 못하게 될 수 있기 때문입니다. 따라서 전송팀은 시간 요소를 고려해야 합니다.

Cloud Storage로 전송된 데이터를 수신하면 Dataflow 같은 다양한 기술을 사용하여 새로운 파일을 처리할 수 있습니다.

네트워크 대역폭 늘리기

네트워크 대역폭을 늘리는 방법은 Google Cloud에 연결하는 방법에 따라 다릅니다.

Google Cloud와 기타 클라우드 제공업체 간의 클라우드 간 전송에서는 Google이 클라우드 공급업체와 데이터 센터 간의 연결을 프로비저닝하므로 개발자가 직접 설정하지 않아도 됩니다.

비공개 데이터 센터와 Google Cloud 간에 데이터를 전송하려면 다음과 같은 몇 가지 접근 방식이 있습니다.

  • 공개 API를 사용하여 공개 인터넷 연결
  • 공개 API를 사용하여 다이렉트 피어링
  • 비공개 API를 사용하여 Cloud Interconnect

이러한 접근 방식을 평가할 때는 장기적인 연결 요구사항을 고려하는 것이 도움이 됩니다. 전송 목적으로만 대역폭을 확보하면 엄청난 비용이 발생할 수 있지만 조직 전체의 네트워크 요구에 따라 Google Cloud의 장기 사용을 고려하면 투자는 그만한 가치가 있습니다. 네트워크를 Google Cloud에 연결하는 방법은 네트워크 연결 제품 선택을 참조하세요.

공개 인터넷을 통해 데이터를 전송하는 방식을 선택한 경우 회사 정책에 따라 그러한 전송 방식이 금지되는지 여부를 보안 관리자에게 확인하는 것이 좋습니다. 또한 프로덕션 트래픽에 공개 인터넷 연결이 사용되는지 여부도 확인하세요. 마지막으로 대규모 데이터 전송은 프로덕션 네트워크 성능에 부정적인 영향을 줄 수 있습니다.

온라인과 오프라인 전송 비교

데이터 전송에 오프라인 프로세스를 사용할지 온라인 프로세스를 사용할지 결정하는 것은 중요합니다. 즉, 네트워크를 통한 전송(Cloud Interconnect 또는 공개 인터넷) 또는 스토리지 하드웨어를 통한 전송 중 하나를 선택해야 합니다.

이러한 결정을 돕기 위해 두 옵션 간의 시간 및 비용 차이를 추정할 수 있도록 전송 계산기를 제공합니다. 다음 차트는 다양한 데이터 세트 크기 및 대역폭의 전송 속도도 보여줍니다. 이러한 계산에는 일정량의 관리 오버헤드가 기본적으로 제공됩니다.

전송 크기와 전송 속도 간의 관계를 보여주는 차트

앞에서 설명했듯이 데이터 전송의 지연 시간을 낮추는 비용(예: 네트워크 대역폭 확보)이 해당 조직에 대한 투자 가치로 상쇄되는지 여부를 고려해야 합니다.

Google에서 제공하는 옵션

Google은 데이터 전송을 수행하는 데 도움이 되는 몇 가지 도구와 기술을 제공합니다.

Google의 전송 옵션 중에서 결정

전송 옵션 선택은 다음 표와 같이 사용 사례에 따라 다릅니다.

이전할 데이터의 원래 위치와 대상 위치 시나리오 추천 제품
다른 클라우드 제공업체(예: Amazon Web Services 또는 Microsoft Azure)와 Google Cloud 사이 : Storage Transfer Service
Cloud Storage와 Cloud Storage 사이(2개의 서로 다른 버킷) : Storage Transfer Service
비공개 데이터 센터와 Google Cloud 사이 프로젝트 기한을 맞추기에 충분한 대역폭 gcloud storage 명령어
비공개 데이터 센터와 Google Cloud 사이 프로젝트 기한을 맞추기에 충분한 대역폭 온프레미스 데이터용 Storage Transfer Service
비공개 데이터 센터와 Google Cloud 사이 프로젝트 기한을 맞추기에 충분하지 않은 대역폭 Transfer Appliance

소량의 온프레미스 데이터 전송을 위한 gcloud storage 명령어

gcloud storage 명령어는 일반적인 엔터프라이즈급 네트워크를 통해 비공개 데이터 센터 또는 다른 클라우드 제공업체에서 Google Cloud로의 중소 규모 전송을 위한 표준 도구입니다. gcloud storage는 최대 Cloud Storage 객체 크기까지 객체 업로드를 지원하지만 대규모 객체 전송은 단기적인 전송에 비해 장애가 발생할 가능성이 더 높습니다. Cloud Storage에 대규모 객체 전송에 대한 자세한 내용은 온프레미스 데이터의 대규모 전송용 Storage Transfer Service를 참조하세요.

gcloud storage 명령어는 특히 다음 시나리오에서 유용합니다.

  • 필요에 따라 또는 사용자의 명령줄 세션 중에 전송을 실행해야 합니다.
  • 몇 개의 파일이나 매우 큰 파일 또는 둘 다 전송해야 합니다.
  • 프로그램의 출력을 사용 중입니다(Cloud Storage로의 스트리밍 출력)
  • 파일 수가 많지 않은 디렉터리를 주시하고 지연 시간이 매우 짧은 업데이트가 있으면 동기화해야 합니다.

대규모 온프레미스 데이터 전송용 Storage Transfer Service

gcloud storage 명령어와 같이 온프레미스 데이터를 위한 Storage Transfer Service를 사용하면 네트워크 파일 시스템(NFS) 스토리지에서 Cloud Storage로 전송이 가능합니다. 온프레미스 데이터를 위한 Storage Transfer Service는 대규모 전송(페타바이트 규모의 데이터, 수십억 개의 파일)에 맞게 설계되었습니다. 전체 복사 또는 증분 복사를 지원하며 앞의 Google의 전송 옵션 중에서 선택에 나온 모든 전송 옵션을 사용할 수 있습니다. 또한 관리형 그래픽 사용자 인터페이스도 제공하므로 기술적으로 능숙하지 않은 사용자도 설정 후 데이터를 이전하는 데 사용할 수 있습니다.

온프레미스 데이터 전송용 Storage Transfer Service는 다음과 같은 상황에서 특히 유용합니다.

  • 데이터 볼륨을 이전하는 데 충분히 사용 가능한 대역폭이 있습니다(Google Cloud Data Transfer 계산기 참조).
  • 명령줄 도구를 사용하기 어려운 대규모의 내부 사용자층을 지원합니다.
  • 강력한 오류 보고 및 이동한 모든 파일 및 객체에 대한 레코드가 필요합니다.
  • 데이터 센터의 다른 워크로드에 미치는 전송의 영향을 제한해야 합니다. 이 제품에는 사용자가 지정한 대역폭 제한이 적용될 수 있습니다.
  • 일정에 따라 전송을 반복 실행합니다.

온프레미스 소프트웨어(에이전트라고 함)를 데이터 센터의 컴퓨터에 설치하여 온프레미스 데이터 전송을 위한 Storage Transfer Service를 설정합니다.

Storage Transfer Service를 설정한 후 소스 디렉터리, 대상 버킷, 시간 또는 일정을 제공하여 Google Cloud 콘솔에서 전송을 시작할 수 있습니다. Storage Transfer Service는 소스 디렉터리의 하위 디렉터리와 파일을 재귀적으로 크롤링하고 Cloud Storage에 해당 이름으로 객체를 만듭니다(/dir/foo/file.txt 객체가 /dir/foo/file.txt라는 대상 버킷의 객체가 됨). Storage Transfer Service는 일시적인 오류가 발생하면 자동으로 전송을 다시 시도합니다. 전송이 실행되는 동안 이동한 파일 수와 전반적인 전송 속도를 모니터링하고 오류 샘플을 확인할 수 있습니다.

Storage Transfer Service에서 전송이 완료되면 연결된 모든 파일과 수신된 모든 오류 메시지의 전체 기록이 포함된 탭 구분 파일(TSV)이 생성됩니다. 에이전트는 내결함성이 있으므로 특정 에이전트의 작동이 중지되면 나머지 에이전트에서 전송을 계속합니다. 또한 에이전트는 자체 업데이트 및 자가 복구를 하기 때문에 최신 버전 패치나 예기치 않은 문제로 인한 작동 중단 시 프로세스 재시작에 대해 걱정할 필요가 없습니다.

Storage Transfer Service를 사용할 때 고려해야 할 사항은 다음과 같습니다.

  • 모든 머신에서 동일한 에이전트 설정을 사용합니다. 모든 에이전트는 동일한 네트워크 파일 시스템(NFS)을 동일한 방식으로(동일한 상대 경로) 마운트해야 합니다. 제품이 올바르게 작동하려면 이 설정이 필요합니다.
  • 사용하는 에이전트 수에 비례하여 속도도 빨라집니다. 전송은 모든 에이전트에서 자동으로 동시 처리되므로 사용 가능한 대역폭을 사용하도록 여러 에이전트를 배포하는 것이 좋습니다.
  • 대역폭 제한으로 워크로드를 보호할 수 있습니다. 다른 워크로드에서 데이터 센터 대역폭을 사용하고 있을 수 있기 때문에 전송이 SLA에 영향을 미치지 않도록 대역폭 제한을 설정해야 합니다.
  • 오류 검토 시간을 계획합니다. 대규모 전송 시 검토가 필요한 오류가 발생할 수 있습니다. Storage Transfer Service를 사용하면 발생한 오류 샘플을 Google Cloud 콘솔에서 바로 볼 수 있습니다. 필요하다면 모든 전송 오류의 전체 레코드를 BigQuery에 로드하여 파일을 확인하거나 재시도 후에도 남아 있는 오류를 평가할 수 있습니다. 이러한 오류는 전송이 진행되는 동안 소스에 기록되는 앱을 실행할 때 발생할 수 있으며, 오류로 인해 문제 해결이 필요한 문제가 드러날 수 있습니다(예: 권한 오류).
  • 장기 실행 전송용 Cloud Monitoring을 설정합니다. Storage Transfer Service를 통해 Monitoring에서 에이전트 상태 및 처리량을 모니터링할 수 있으므로 에이전트 작동이 중지되거나 주의가 필요할 때 사용자에게 통지하도록 알림을 설정할 수 있습니다. 며칠 또는 몇 주가 소요되는 전송 시 프로젝트 기한을 지연시킬 수 있는 심각한 감속이나 중단을 피하려면 에이전트 오류에 대한 조치가 중요합니다.

대규모 전송용 Transfer Appliance

대규모 전송(특히 네트워크 대역폭이 제한된 전송) 수행 시 빠른 네트워크 연결을 사용할 수 없거나 대역폭을 추가로 확보하는 데 너무 많이 비용이 드는 경우 Transfer Appliance를 사용하는 것이 좋습니다.

Transfer Appliance는 다음과 같은 상황에서 특히 유용합니다.

  • 데이터 센터가 대역폭이 제한되었거나 대역폭에 액세스할 수 없는 원격 위치에 있습니다.
  • 대역폭이 사용 가능하지만 프로젝트 기한을 맞출 수 있는 시간 내에 확보할 수 없습니다.
  • 어플라이언스 수령 및 네트워크 연결을 수행할 수 있는 실행 리소스에 액세스할 수 있습니다.

이 옵션을 사용하는 경우 다음 사항을 고려하세요.

  • Transfer Appliance를 사용하려면 Google 소유 하드웨어를 수령한 후후 반송할 수 있어야 합니다.
  • 인터넷 연결에 따라 Google Cloud로 데이터를 전송할 때의 지연 시간은 일반적으로 온라인보다 Transfer Appliance에서 더 높습니다.
  • Transfer Appliance는 일부 국가에서만 사용할 수 있습니다.

Transfer Appliance 사용 시 고려해야 할 2가지 주요 기준은 비용과 속도입니다. 합리적 수준의 네트워크 연결(예: 1Gbps)을 사용할 경우 100TB의 데이터를 온라인으로 전송하는 데 10일이 걸립니다. 이 속도가 허용되는 경우 비즈니스 필요에 맞는 올바른 솔루션으로 온라인 솔루션을 사용하는 것이 좋습니다. 100Mbps 연결(원격 위치보다 훨씬 느린 속도)만 사용 가능하다면 동일한 규모의 데이터를 전송하는 데 100일이 걸립니다. 이때는 Transfer Appliance 같은 오프라인 전송 옵션 사용을 고려하는 것이 좋습니다.

Transfer Appliance를 입수하는 방법은 간단합니다. Google Cloud 콘솔에서 Transfer Appliance를 요청하고, 보유한 데이터 규모를 명시하면 Google에서 하나 이상의 어플라이언스를 요청한 위치로 배송합니다. 지정된 일수 동안 데이터를 어플라이언스로 전송('데이터 캡처')한 후 해당 어플라이언스를 Google로 반송합니다.

클라우드 간 전송용 Storage Transfer Service

Storage Transfer Service는 다른 퍼블릭 클라우드에서 Cloud Storage로의 전송을 자동화하는 확장성이 우수한 완전 관리형 서비스입니다. 예를 들어 Storage Transfer Service를 사용해서 Amazon S3에서 Cloud Storage로 데이터를 전송할 수 있습니다.

HTTP의 경우 Storage Transfer Service에 지정된 형식의 공개 URL 목록을 제공할 수 있습니다. 이 접근 방식을 사용하려면 Base64로 인코딩된 파일 콘텐츠의 MD5 해시와 함께 각 파일의 크기를 바이트 단위로 제공하는 스크립트를 작성해야 합니다. 파일 크기 및 해시는 소스 웹사이트에서 제공되는 경우도 있습니다. 그렇지 않으면 파일에 대한 로컬 액세스 권한이 필요하며, 이 경우 앞에서 설명한 대로 gcloud storage 명령어를 사용하는 것이 더 쉬울 수 있습니다.

전송이 필요한 경우 Storage Transfer Service를 사용하면 특히 다른 퍼블릭 클라우드에서 전송할 때 쉽게 데이터를 가져와 보관할 수 있습니다.

Storage Transfer Service에서 지원되지 않는 다른 클라우드에서 데이터를 이동하려면 클라우드에 호스팅된 가상 머신 인스턴스에서 gcloud storage 명령어를 사용할 수 있습니다.

보안

대다수의 Google Cloud 사용자는 보안에 가장 큰 초점을 두고 있으며 다양한 보안 수준을 사용할 수 있습니다. 고려해야 할 보안의 몇 가지 측면에는 저장 데이터 보호(소스 및 대상 스토리지 시스템에 대한 승인 및 액세스), 전송 중인 데이터 보호, 전송 제품에 대한 액세스 보호가 포함됩니다. 다음 표에서는 이러한 측면을 제품별로 설명합니다.

제품 저장 데이터 전송 중 데이터 전송 제품에 대한 액세스
Transfer Appliance 저장된 모든 데이터는 암호화됩니다. 데이터는 고객이 관리하는 키로 보호됩니다. 누구나 어플라이언스를 주문할 수 있지만 이를 사용하려면 데이터 소스에 대한 액세스 권한이 필요합니다.
gcloud storage 명령어 Cloud Storage에 액세스하는 데 필요한 액세스 키로, 저장 시 암호화됩니다. 데이터는 HTTPS를 통해 전송되고 전송 중 암호화됩니다. 누구나 Google Cloud CLI를 다운로드하고 실행할 수 있습니다. 데이터를 이전하려면 버킷 및 로컬 파일에 대한 권한이 있어야 합니다.
온프레미스 데이터용 Storage Transfer Service Cloud Storage에 액세스하는 데 필요한 액세스 키로, 저장 시 암호화됩니다. 에이전트 프로세스는 OS 권한이 허용하는 로컬 파일에 액세스할 수 있습니다. 데이터는 HTTPS를 통해 전송되고 전송 중 암호화됩니다. Cloud Storage 버킷에 액세스하려면 객체 편집자 권한이 있어야 합니다.
Storage Transfer Service Google Cloud 외부 리소스(예: Amazon S3)에 필요한 액세스 키입니다. Cloud Storage에 액세스하려면 액세스 키가 필요하며, 저장 상태에서 암호화됩니다. 데이터는 HTTPS를 통해 전송되고 전송 중 암호화됩니다. Cloud Storage 버킷의 소스와 객체 편집자 권한에 액세스하려면 서비스 계정에 대한 IAM 권한이 있어야 합니다.

기본적인 보안 개선 기능을 확보하기 위해 gcloud storage 명령어를 사용해서 Google Cloud로 온라인 전송을 수행하고, 전송 중에 데이터를 암호화하고, 기본적으로 Cloud Storage의 모든 데이터가 저장 중에 암호화됩니다. Transfer Appliance를 사용하면 제어권을 가진 보안 키로 데이터를 보호할 수 있습니다. 일반적으로 보안팀과 협력하여 전송 계획이 회사 및 규제 요구사항을 충족하는지 확인하는 것이 좋습니다.

타사 전송 제품

고급 네트워크 수준 최적화나 지속적인 데이터 전송 워크플로에는 고급 도구를 더 많이 사용하려는 경우가 있을 수 있습니다. 고급 도구에 대한 자세한 내용은 Google Cloud 파트너를 참조하세요.

4단계: 데이터 마이그레이션 방법 평가

데이터를 마이그레이션할 때 다음과 같은 일반적인 단계를 사용할 수 있습니다.

  1. 기존 사이트의 데이터를 새 사이트로 이전합니다.
  2. 데이터 통합 문제(예: 여러 소스의 동일한 데이터 동기화)가 발생하면 해결합니다.
  3. 데이터 마이그레이션의 유효성을 검사합니다.
  4. 새 사이트를 기본 복사본으로 승격합니다.
  5. 기존 사이트가 대체 옵션으로 더 이상 필요하지 않으면 기존 사이트를 중단합니다.

다음 질문에 따라 데이터 마이그레이션 방법을 수립해야 합니다.

  • 마이그레이션해야 하는 데이터의 양은 얼마인가요?
  • 데이터가 얼마나 자주 변경되나요?
  • 데이터를 이전할 때 단순 이전 기간 동안 발생하는 다운타임을 감당할 수 있나요?
  • 현재 데이터 일관성 모델은 무엇인가요?

최고의 방법은 없습니다. 사용 환경과 요구 사항에 따라 한 가지 방법을 선택하세요.

다음 섹션에는 네 가지 데이터 이전 방법이 나와 있습니다.

  • 예약된 유지보수
  • 지속적 복제
  • Y(쓰기 및 읽기)
  • 데이터 액세스 마이크로서비스

각 방법은 데이터 이전의 규모와 요구 사항에 따라 다른 문제를 해결합니다.

데이터 액세스 마이크로서비스 방법은 마이크로서비스 아키텍처에서 권장되는 옵션입니다. 하지만 다른 방법도 데이터 이전에 유용합니다. 데이터 액세스 마이크로서비스 방법을 사용하도록 인프라를 현대화하는 데 필요한 전환 기간에도 유용합니다.

다음 그래프에는 이러한 각 방법의 관련 단순 이전 기간, 리팩터링 작업, 유연성 특성이 간략히 나와 있습니다.

각 4개 방법의 유연성, 리팩터링 작업, 단순 이전 기간의 상대 값을 보여주는 막대 그래프

이러한 방법을 수행하기 전에 필요한 인프라를 새 환경에 구축했는지 확인하세요.

예약된 유지보수

워크로드가 단순 이전 기간을 감당할 수 있는 경우에는 예약된 유지보수 방법이 이상적입니다. 단순 이전 기간이 시작되는 시기를 계획할 수 있기 때문에 예약된 유지보수라고 합니다.

이 방법은 다음 단계를 따라 마이그레이션을 진행합니다.

  1. 기존 사이트에 있는 데이터를 새 사이트에 복사합니다. 이 초기 복사 과정은 단순 이전 기간을 최소화합니다. 초기 복사 후에는 단순 이전 기간 동안 변경된 데이터를 복사하기만 하면 됩니다.
  2. 기존 사이트의 데이터와 새 사이트의 복사된 데이터를 비교하는 데이터 유효성 검사 및 일관성 검사를 수행합니다.
  3. 더 이상 변경사항이 발생하지 않도록 복사된 데이터에 대한 쓰기 액세스 권한이 있는 작업 부하 및 서비스를 중지합니다.
  4. 초기 복사 후 변경된 내용을 동기화합니다.
  5. 새 사이트를 사용하도록 워크로드 및 서비스를 리팩토링합니다.
  6. 작업 부하 및 서비스를 시작합니다.
  7. 기존 사이트가 대체 옵션으로 더 이상 필요하지 않으면 기존 사이트를 사용 중지합니다.

예약된 유지보수 방법은 작업 부하 및 서비스를 최소한만 리팩토링하면 되므로 거의 운영 측면에만 부담을 줍니다.

지속적 복제

모든 작업 부하가 장기간의 단순 이전 과정을 감당할 수 있는 것은 아니므로 초기 복사 및 유효성 검사 단계 후 지속적 복제 메커니즘을 제공하여 예약된 유지보수 방법을 보강할 수 있습니다. 이와 같은 메커니즘을 설계할 때는 변경 사항이 데이터에 적용되는 속도도 고려해야 합니다. 두 시스템을 동기화하는 과정은 까다로울 수 있습니다.

지속적 복제 방법은 예약된 유지보수 방법보다 복잡합니다. 하지만 지속적 복제 방법을 사용하면 최소한의 데이터만 동기화하면 되므로 필수 단순 이전 기간이 최소화됩니다. 지속적 복제 이전 순서는 다음과 같습니다.

  1. 기존 사이트에 있는 데이터를 새 사이트에 복사합니다. 이 초기 복사 과정은 단순 이전 기간을 최소화합니다. 초기 복사 후에는 단순 이전 기간 동안 변경된 데이터를 복사하기만 하면 됩니다.
  2. 기존 사이트의 데이터와 새 사이트의 복사된 데이터를 비교하는 데이터 유효성 검사 및 일관성 검사를 수행합니다.
  3. 기존 사이트에서 새 사이트로의 지속적 복제 메커니즘을 설정합니다.
  4. 이전할 데이터(즉, 전 단계와 관련된 데이터)에 액세스할 수 있는 작업 부하 및 서비스를 중지합니다.
  5. 새 사이트를 사용하도록 워크로드 및 서비스를 리팩토링합니다.
  6. 복제 과정에서 새 사이트와 기존 사이트가 완전히 동기화될 때까지 기다립니다.
  7. 작업 부하 및 서비스를 시작합니다.
  8. 기존 사이트가 대체 옵션으로 더 이상 필요하지 않으면 기존 사이트를 사용 중지합니다.

지속적 복제 방법은 예약된 유지보수 방법과 마찬가지로 거의 운영 측면에만 부담을 줍니다.

Y(쓰기 및 읽기)

작업 부하의 고가용성 요구 사항이 까다롭고, 단순 이전 기간 동안 발생하는 다운타임을 감당할 수 없다면 다른 방법을 사용해야 합니다. 이 경우 동시 마이그레이션의 일종으로, 이 문서에서 Y(쓰기 및 읽기)라고 하는 방법을 사용할 수 있습니다. 이 방법을 사용하면 작업 부하가 이전 중에 기존 사이트와 새 사이트의 데이터를 쓰고 읽습니다. 여기서 Y라는 문자는 마이그레이션 기간 동안 데이터가 흐르는 모습을 형상화한 것입니다.

이 방법을 요약하면 다음과 같습니다.

  1. 기존 사이트와 새 사이트에 데이터를 쓰고 기존 사이트에서 데이터를 읽도록 작업 부하 및 서비스를 리팩토링합니다.
  2. 새 사이트에서 쓰기를 사용 설정하기 전에 기록된 데이터를 식별하고 기존 사이트에서 새 사이트로 복사합니다. 이렇게 하면 위의 리팩토링과 함께 데이터 저장소가 정렬되도록 보장합니다.
  3. 기존 사이트의 데이터와 새 사이트의 데이터를 비교하는 데이터 유효성 검사 및 일관성 검사를 수행합니다.
  4. 기존 사이트에서 새 사이트로 읽기 작업을 전환합니다.
  5. 기존 사이트의 데이터와 새 사이트의 데이터를 비교하는 데이터 유효성 검사 및 일관성 검사를 한 번 더 수행합니다.
  6. 기존 사이트에서 쓰기를 중지합니다.
  7. 기존 사이트가 대체 옵션으로 더 이상 필요하지 않으면 기존 사이트를 사용 중지합니다.

Y(쓰기 및 읽기) 방법은 예약된 유지보수 방법 및 지속적 복제 방법과 달리 리팩토링을 여러 번 거쳐야 하므로 운영 측면의 부담이 거의 대부분 개발 측면으로 넘어갑니다.

데이터 액세스 마이크로서비스

Y(쓰기 및 읽기) 방법을 수행하는 데 필요한 리팩토링 작업을 줄이고자 한다면 데이터 액세스 마이크로서비스를 사용하도록 작업 부하 및 서비스를 리팩토링하여 데이터 읽기 및 쓰기 작업을 중앙 집중화하면 됩니다. 이 확장 가능한 마이크로서비스는 데이터 스토리지 레이어의 유일한 진입점이 되며 해당 계층의 프록시 역할을 합니다. 아키텍처의 다른 구성요소에 영향을 주지 않고 단순 이전 기간을 거치지 않으면서 마이크로서비스를 리팩토링할 수 있기 때문에 여기에 설명된 이전 방법 중 유연성이 가장 뛰어납니다.

데이터 액세스 마이크로서비스를 사용하는 방법은 Y(쓰기 및 읽기) 방법과 상당히 유사합니다. 차이점은 데이터 스토리지 레이어에 액세스하는 모든 워크로드 및 서비스를 리팩토링할 필요 없이 데이터 액세스 마이크로서비스 자체만 리팩토링하면 된다는 것입니다. 이 방법을 요약하면 다음과 같습니다.

  1. 기존 사이트와 새 사이트에 데이터를 쓰도록 데이터 액세스 마이크로서비스를 리팩토링합니다. 기존 사이트에서 읽기가 수행됩니다.
  2. 새 사이트에서 쓰기를 사용 설정하기 전에 기록된 데이터를 식별하고 기존 사이트에서 새 사이트로 복사합니다. 이렇게 하면 위의 리팩토링과 함께 데이터 저장소가 정렬되도록 보장합니다.
  3. 기존 사이트의 데이터와 새 사이트의 데이터를 비교하는 데이터 유효성 검사 및 일관성 검사를 수행합니다.
  4. 새 사이트에서 데이터를 읽도록 데이터 액세스 마이크로서비스를 리팩토링합니다.
  5. 기존 사이트의 데이터와 새 사이트의 데이터를 비교하는 데이터 유효성 검사와 일관성 검사를 한 번 더 수행합니다.
  6. 새 사이트에서만 데이터를 작성하도록 데이터 액세스 마이크로서비스를 리팩토링합니다.
  7. 기존 사이트가 대체 옵션으로 더 이상 필요하지 않으면 기존 사이트를 사용 중지합니다.

데이터 액세스 마이크로서비스 방법은 Y(쓰기 및 읽기) 방법과 마찬가지로 거의 개발 측면에만 부담을 줍니다. 하지만 리팩터링 작업이 데이터 액세스 마이크로서비스에 집중되어 있기 때문에 Y(쓰기 및 읽기) 방법보다는 부담이 훨씬 덜합니다.

5단계: 전송 준비

대규모 전송 또는 종속 항목이 현저히 많은 전송의 경우 전송 제품의 작동 방법을 이해하는 것이 중요합니다. 일반적으로 고객은 다음 단계를 수행합니다.

  1. 가격 책정 및 ROI 추정. 이 단계에서는 의사 결정 과정을 지원하는 다양한 옵션을 제공합니다.

  2. 기능 테스트. 이 단계에서는 제품이 성공적으로 설정되고 네트워크 연결(해당되는 경우)이 올바르게 작동하는지 확인합니다. 또한 데이터의 대표 샘플(예: VM인스턴스 이동과 같이 동반되는 비전송 단계)을 대상 위치로 이동할 수 있는지 테스트합니다.

    이 단계는 대개 전송 머신이나 대역폭 같은 모든 리소스를 할당하기 전에 수행할 수 있습니다. 이 단계의 목표는 다음과 같습니다.

    • 전송을 설치하고 제대로 작동하는지 확인합니다.
    • 데이터 이동(예: 네트워크 경로)이나 작동(예: 비전송 단계에 필요한 교육)을 차단하는 잠재적인 프로젝트 중단 문제를 노출시킵니다.

  3. 성능 테스트. 이 단계에서는 프로덕션 리소스가 할당된 후 다음을 수행하여 대용량 샘플 데이터(일반적으로 3~5%)에 대한 전송을 실행합니다.

    • 할당된 모든 리소스를 사용하고 예상 속도에 도달할 수 있는지 확인합니다.
    • 병목 현상(예: 소스 스토리지 시스템의 속도 저하)을 표면화하고 해결합니다.

6단계: 전송의 무결성 확인

전송 중 데이터의 무결성을 확인하려면 다음과 같은 주의 사항을 따르는 것이 좋습니다.

  • 우발적 삭제로 인한 피해를 제한하기 위해 대상 위치에 버전 관리 및 백업을 사용 설정합니다.
  • 소스 데이터를 제거하기 전에 먼저 데이터를 검증합니다.

대규모 데이터 전송(페타바이트 규모의 데이터와 수십억 개의 파일 포함)의 경우 기본 소스 스토리지 시스템의 잠재 오류율 기준이 최저 0.0001%인 경우에도 수천 개의 파일과 기가바이트 규모의 데이터가 손실될 수 있습니다. 일반적으로 소스에서 실행되는 애플리케이션은 이미 이러한 오류를 허용하므로 별도의 검증이 필요하지 않습니다. 일부 예외적인 시나리오(예: 장기적인 아카이브 처리)에서는 추가적인 검증 절차를 통해 소스에서 데이터를 삭제해도 안전한지 확인해야 합니다.

애플리케이션의 요구사항에 따라 전송이 완료되면 일부 데이터에 대한 무결성 테스트를 실행하여 애플리케이션이 의도한 대로 계속 작동하는지 확인하는 것이 좋습니다. 대부분의 전송 제품에는 데이터 무결성 검사 기능이 기본 제공됩니다. 그러나 위험 프로필에 따라 소스에서 데이터를 삭제하기 전에 데이터와 해당 데이터를 읽는 앱에 대해 별도의 검사를 수행해야 할 수 있습니다. 예를 들어 독립적으로 기록하고 계산한 체크섬이 대상 위치에 작성된 데이터와 일치하는지 여부를 확인하거나 애플리케이션에서 사용한 데이터 세트가 성공적으로 전송되었는지 확인할 수 있습니다.

다음 단계