온프레미스에서 Google Cloud로 HDFS 데이터 마이그레이션

Last reviewed 2024-04-17 UTC

이 가이드에서는 온프레미스 Hadoop 분산 파일 시스템(HDFS)에서 Google Cloud(Google Cloud)로 데이터를 이동하는 프로세스를 설명합니다.

이 가이드는 온프레미스 Hadoop에서 이동하는 방법을 설명하는 네 가지 가이드 중 두 번째입니다.

데이터 이동 계획

다음 섹션에서는 온프레미스 HDFS에서 Google Cloud로 데이터 마이그레이션을 계획하는 데 관련된 권장사항을 설명합니다. 각 데이터를 이동한 후 작업을 마이그레이션하고, 실험하고, 테스트할 시간을 할애할 수 있도록 점진적으로 마이그레이션할 계획을 세우세요.

데이터 이동 방법 결정

HDFS 데이터를 클라우드로 전송하기 위해 고려할 수 있는 두 가지 이전 모델로 내보내기와 가져오기가 있습니다. 두 모델 모두 Hadoop DistCp를 사용하여 온프레미스 HDFS 클러스터에서 Cloud Storage로 데이터를 복사하지만 방식이 서로 다릅니다.

내보내기 모델은 가장 간단한 모델입니다. 소스 클러스터가 데이터 노드에서 distcp 작업을 실행하고 아래 다이어그램과 같이 파일을 직접 Cloud Storage로 내보냅니다.

내보내기 모델을 사용하여 HDFS 마이그레이션

가져오기 모델은 더 복잡하지만 몇 가지 장점이 있습니다. 임시 Dataproc 클러스터는 다음 다이어그램과 같이 데이터 노드에서 distcp 작업을 실행하고, 소스 클러스터에서 파일을 가져오고 Cloud Storage에 복사합니다.

가져오기 모델을 사용하여 HDFS 데이터 마이그레이션

내보내기 모델은 소스 클러스터에서 Cloud Storage로 직접 데이터를 내보낼 수 있고 복사하기 위해 별도의 컴퓨팅 리소스를 만들 필요가 없으므로 가장 간단한 모델입니다. 하지만 다른 정기적인 데이터 처리 작업을 위한 이전 작업 중에 계속해서 소스 클러스터를 사용하려면 복사 작업도 함께 수행할 수 있도록 소스 클러스터에서 CPU, RAM, 네트워크 대역폭과 같은 리소스를 충분히 사용할 수 있어야 합니다.

소스 클러스터가 이미 컴퓨팅 용량 수준에서 실행 중이고 소스 클러스터에서 복사를 수행하기 위한 리소스를 늘릴 수 없으면 대신 가져오기 모델을 사용하는 것이 좋습니다.

가져오기 모델은 내보내기 모델보다 복잡하지만 여러 가지 장점이 있습니다.

  • 소스 노드는 클러스터에서 블록을 제공하는 데만 사용되므로 소스 클러스터의 CPU와 RAM 리소스에 미치는 영향이 최소화됩니다. 또한 복사 작업을 처리하고 마이그레이션이 완료되었을 때 가져오기 클러스터를 세분화하도록 Google Cloud에서 가져오기 클러스터의 리소스 사양을 미세 조정할 수 있습니다.
  • 소스 클러스터의 네트워크 트래픽이 감소하여 아웃바운드 대역폭과 전송 속도를 높일 수 있습니다.
  • 이미 커넥터가 설치된 임시 Dataproc 클러스터가 데이터를 Cloud Storage로 전송하므로 소스 클러스터에 Cloud Storage 커넥터를 설치할 필요가 없습니다.

두 모델이 네트워크 사용량에 미치는 영향을 이해하려면 Hadoop이 HDFS에서 데이터 복제를 처리하는 방식을 고려합니다. Hadoop은 각 파일을 여러 블록으로 분할하며, 블록 크기는 일반적으로 128~256MB입니다. Hadoop은 데이터 노드 오류 또는 랙 오류 발생 시 데이터 손실을 방지하기 위해 여러 데이터 노드 및 여러 랙에 이러한 블록을 복제합니다. 표준 구성은 각 블록의 복제본을 3개씩 저장하는 것입니다.

또한 Hadoop은 '랙 인식'을 사용하는데 이 메커니즘은 지연 시간을 줄이기 위해 각 블록의 복사본 2개는 동일한 랙의 서로 다른 데이터 노드에 두고, 중복성 및 가용성을 높이기 위해 세 번째 복사본은 다른 랙에 둡니다. 이 복제 논리가 아래 다이어그램에 요약되어 있습니다.

랙 인식을 사용하여 HDFS 블록 복제

내보내기 모델을 사용하여 파일을 복사할 경우, 즉 distcp 맵 태스크가 소스 클러스터의 데이터 노드에서 실행되면 먼저 모든 파일 블록이 다양한 데이터 노드에서 수집됩니다. 그런 다음 파일 블록이 소스 클러스터에서 Cloud Storage로 내보내집니다. 다음 다이어그램과 같이 네트워크 트래픽 최대 크기는 파일 총 크기의 거의 두 배가 될 수 있습니다.

내보내기 모델을 사용하는 경우의 네트워크 사용량

가져오기 모델을 사용하여 파일을 복사하면(distcp 맵 태스크가 Google Cloud에 있는 가져오기 클러스터의 데이터 노드에서 실행될 때) 모든 블록이 소스 클러스터에서 바로 나와서 네트워크를 통해 한 번만 이동합니다. 전체 네트워크 트래픽은 다음 다이어그램과 같이 파일 전체 크기로 제한됩니다.

가져오기 모델을 사용하는 경우의 네트워크 사용량

가져오기 모델을 사용하는 경우 다수의 병렬 연결로 인해 소스 클러스터가 혼잡해지지 않도록 distcp 맵 태스크 수와 사용되는 대역폭을 모니터링해야 합니다.

데이터를 이동할 위치 결정

Hadoop 이전의 최종 결과는 클라우드 네이티브 솔루션 또는 하이브리드 솔루션입니다. 두 솔루션의 차이는 시스템에서 온프레미스 구성요소가 유지되는지 여부입니다. 클라우드 네이티브 솔루션에서는 데이터를 클라우드에 저장하고 데이터에 대한 작업을 클라우드에서 실행합니다. 하이브리드 솔루션에서는 일부 데이터가 온프레미스로 유지됩니다. 이러한 데이터에 대한 작업을 온프레미스로 실행할 수도 있고, 온프레미스 데이터를 사용하는 작업을 클라우드에서 실행할 수도 있습니다.

클라우드 네이티브 솔루션은 유지관리하기가 가장 쉽지만, 비즈니스 또는 기술상의 요구로 인해 일부 데이터 또는 처리를 온프레미스로 유지해야 할 수 있습니다. 하이브리드 솔루션은 저마다 크게 다르며, 워크로드에 맞게 고유한 기술 및 서비스의 조합을 포함합니다.

데이터를 Cloud Storage 이외의 제품으로 이전

대부분의 데이터를 Cloud Storage로 이동합니다. 하지만 데이터를 다른 Google Cloud 제품으로 이동하는 것이 좋은 경우도 있습니다.

  • Apache HBase에서 데이터를 이전하는 경우에는 같은 기능을 제공하는 Bigtable로 이전하는 것이 좋습니다.

  • Apache Impala에서 데이터를 이전하는 경우에는 같은 기능을 제공하는 BigQuery로 이전하는 것이 좋습니다.

데이터를 Bigtable 또는 BigQuery에 저장하지 않고 HBase 또는 Impala에 저장하여 사용하는 경우가 있습니다. 작업에 Bigtable 또는 BigQuery의 기능이 필요하지 않으면 데이터를 Cloud Storage에 저장합니다.

사용 권한을 고려한 데이터 위치 계획

Google Cloud는 HDFS 온프레미스에서 부여받을 수 있는 세분화된 파일 권한을 사용하지 않습니다. 파일 권한에 대한 덜 복잡한 방식은 파일 권한을 각 Cloud Storage 버킷 수준에서 설정하는 것입니다. 여러 HDFS 데이터 세트에 서로 다른 권한을 설정한 경우에는 Cloud Storage에서 각자 다른 권한을 가진 여러 버킷을 만드는 것이 좋습니다. 그런 다음 HDFS 데이터를 데이터에 맞는 적절한 권한이 있는 버킷에 저장합니다.

Cloud Storage와 HDFS의 구조가 서로 다른 경우 이러한 구조로 파일을 이동할 때는 모든 변경사항을 추적해야 합니다. 작업을 Dataproc로 이동할 경우 데이터의 올바른 새 위치 경로를 제공해야 합니다.

증분 이동 계획

시간을 두고 데이터를 별개의 청크로 이전할 계획을 세우세요. 관련 작업을 클라우드로 이동하려면 데이터 이전 사이에 충분한 시간을 두어야 합니다. 이전을 시작할 때는 백업, 아카이브처럼 우선 순위가 낮은 데이터부터 이전하세요.

데이터 분할

데이터를 증분식으로 이동하려면 데이터를 여러 부분으로 분할해야 합니다. 다음 섹션에서는 데이터 세트를 분할하는 가장 일반적인 전략에 대해 설명합니다.

타임스탬프로 데이터 분할

증분 이동을 위해 데이터를 분할하는 일반적인 방법은 오래된 데이터를 클라우드에 저장하고 새로운 데이터를 온프레미스 시스템의 HDFS에 보관하는 것입니다. 이렇게 하면 더 오래되고 덜 중요한 데이터를 대상으로 새로운 작업과 이전된 작업을 테스트할 수 있습니다. 이런 방식으로 데이터를 분할하면 소량의 데이터로 이전을 시작할 수 있습니다.

중요 고려사항:

  • 데이터를 분할할 때 시간으로 분할하는 것 외에 다른 방법으로 분할할 수 있나요? 데이터를 데이터가 지원하는 작업을 기준으로 또는 데이터를 소유한 조직을 기준으로 분할한 다음 다시 시간으로 분할하면 데이터 세트가 더 세부적으로 표적화됩니다.
  • 절대 날짜/시간 또는 상대 시간/날짜 중에서 무엇을 사용하나요? 때로는 특정 시점을 기준으로 데이터를 분할하는 방식이 적절합니다. 예를 들면 시스템에서 중요한 변경 이전에 생성된 모든 데이터를 보관하는 경우가 있습니다. 이전 데이터를 처리하여 현재 기준에 맞게 만들 수 있는지 확인하기 위해 클라우드에서 시스템을 테스트하는 백필링 작업을 만들려면 절대 날짜/시간을 사용하는 것이 적절한 경우가 많습니다. 그 밖에 현재 날짜에 상대적인 타임스탬프를 기준으로 데이터를 클라우드로 이전하는 경우가 있습니다. 예를 들면 1년 전에 생성된 모든 데이터를 이전하거나, 지난 3달 동안 편집되지 않은 모든 데이터를 이전할 수 있습니다.
  • 결정을 내리는 데 어떤 날짜/시간 값을 사용하나요? 파일에 날짜/시간 값이 여러 개 존재하는 경우가 많습니다. 경우에 따라서는 파일 생성 날짜가 가장 중요합니다. 또는 마지막으로 편집한 시간 또는 파일의 메타데이터에 있는 다른 타임스탬프를 사용해야 하는 경우도 있습니다.
  • 모든 데이터의 타임스탬프 형식이 동일한가요? 타임스탬프를 처리하는 방법은 여러 가지입니다. 데이터가 두 개 이상의 소스에서 제공되었으면 타임스탬프가 서로 다른 형식으로 저장되었을 가능성이 있습니다. 타임스탬프를 사용하여 데이터를 분할하기 전에 타임스탬프에 일관성이 있는지 확인하세요.

작업으로 데이터 분할

때로는 데이터를 사용하는 작업을 살펴보고 데이터를 분할할 수 있습니다. 작업을 증분식으로 이전하는 경우에 이렇게 하면 특히 유용합니다. 이렇게 하면 이전하는 작업에 사용되는 데이터만 이전할 수 있습니다.

중요 고려사항:

  • 클라우드로 이전할 작업이 독립 실행형인가요? 작업을 기준으로 분할하는 방식은 독립적인 데이터 단위를 대상으로 하는 작업에는 유용한 옵션이지만, 시스템 전체에 분산된 데이터를 대상으로 하는 작업의 경우에는 관리하기가 어려울 수 있습니다.
  • 데이터가 나중에 동일한 용도로 사용될 가능성이 있나요? 데이터를 다른 방식으로 사용할 가능성이 있다면 데이터를 격리하기 전에 신중하게 생각하세요.
  • 데이터를 관리하기 편한 규모로 분할할 수 있도록 작업 이전 범위가 적절하게 지정되었나요?

단순히 작업 세트 대신 더 광범위한 기능적 기준을 사용하여 데이터를 분할할 수도 있습니다. 예를 들어 클라우드에서 모든 ETL 작업을 실행한 후 온프레미스에서 분석 및 보고 작업을 실행할 수 있습니다.

소유권으로 데이터 분할

때로는 소유권 영역을 기준으로 데이터를 분할할 수 있습니다. 이 방식의 장점 중 하나는 데이터 조직이 비즈니스 조직과 일치한다는 점입니다. 또 다른 장점은 Google Cloud 역할 기반 액세스 관리를 활용할 수 있다는 점입니다. 예를 들어 특정 비즈니스 역할에서 사용하는 데이터를 격리된 Cloud Storage 버킷으로 마이그레이션하면 권한을 보다 쉽게 설정할 수 있습니다.

중요 고려사항:

  • 소유자 간의 경계가 명확한가요? 일반적으로는 특정 데이터 항목의 기본 소유자가 누구인지가 명확하지만, 때때로 소유자가 아닌 사람이 데이터에 가장 자주 액세스하는 경우가 있습니다.
  • 소유권과 결합할 수 있는 다른 분할 기준이 있나요? 소유권을 기준으로 분할하면 데이터 세트의 크기가 지나치게 커질 수 있습니다. 작업이나 시간을 기준으로 해서 데이터를 추가로 분할하여 규모를 좁히면 유용합니다.

하이브리드 솔루션에서 데이터 동기화 유지

하이브리드 솔루션을 사용할 때의 문제 중 하나는 작업 하나가 Google Cloud의 데이터와 온프레미스 시스템의 데이터에 모두 액세스해야 하는 경우입니다. 데이터 세트 하나가 두 환경 모두에 액세스해야 할 경우 한 환경에는 기본 스토리지 위치를 설정하고 다른 환경에서는 동기화된 복사본을 유지해야 합니다.

데이터를 동기화할 때의 문제는 선택한 기본 위치에 관계없이 비슷합니다. 데이터가 변경된 시기를 식별하는 방법과 변경사항을 해당 사본에 전파하는 메커니즘이 필요합니다. 변경사항이 충돌할 가능성이 있으면 이를 해결하기 위한 전략도 개발해야 합니다.

중요 고려사항:

  • 가능하면 항상 데이터 사본을 읽기 전용으로 설정하세요. 새로운 편집의 소스가 늘어날수록 동기화 전략이 더 복잡해집니다.
  • 하이브리드 솔루션에서는 데이터 복사본을 두 개를 초과하여 유지하지 마세요. 복사본을 온프레미스와 Google Cloud에 각각 한 개씩만 유지하세요.

Apache Airflow 같은 기술을 사용하여 데이터 동기화를 관리할 수 있습니다.

데이터 이동

다음 섹션에서는 데이터를 Google Cloud로 이동할 때 고려해야 할 사항을 간략하게 설명합니다.

데이터에 대한 액세스 구성

파일 권한은 서로 다른 방식으로 Cloud Storage와 HDFS에 적용됩니다. 데이터를 Cloud Storage로 이동하기 전에 Identity and Access Management(IAM)를 숙지해야 합니다.

액세스 제어를 처리하는 가장 쉬운 방법은 액세스 요구사항에 따라 데이터를 Cloud Storage 버킷으로 분류하고 버킷 수준에서 승인 정책을 구성하는 것입니다. 액세스 권한을 부여하는 역할을 개별 사용자 또는 그룹에 할당할 수 있습니다. 그룹별로 액세스 권한을 부여한 다음 필요에 따라 사용자를 그룹에 할당하세요. Cloud Storage에서 데이터를 가져오고 구조화할 때 데이터 액세스와 관련된 결정을 내려야 합니다.

모든 Google Cloud 제품에는 각각 고유한 권한과 역할이 있습니다. Cloud Storage 액세스 제어와 Dataproc 액세스 제어 간의 관계를 이해해야 합니다. 각 제품의 정책을 개별적으로 평가하세요. 역할과 권한이 제품 간에 직접적으로 매핑된다고 가정하지 마세요.

클라우드 기반 Hadoop 시스템에 대한 정책 결정을 준비하려면 다음 문서를 숙지합니다.

개별 파일에 보다 세부적인 권한을 지정해야 하는 경우 Cloud Storage는 액세스 제어 목록(ACL)을 지원합니다. 하지만 가장 선호되는 옵션은 IAM입니다. 권한이 특히 복잡한 경우에만 ACL을 사용하세요.

DistCp를 사용하여 데이터를 Cloud Storage에 복사

Cloud Storage는 Hadoop 호환 파일 시스템이므로 Hadoop DistCp를 사용하여 데이터를 온프레미스 HDFS에서 Cloud Storage로 이전할 수 있습니다. DistCp를 사용하여 데이터를 이전하는 방법은 여러 가지가 있지만 다음과 같은 방법을 권장합니다.

  1. Cloud Interconnect 또는 Cloud VPN을 사용하여 온프레미스 네트워크와 Google 네트워크 간에 비공개 링크를 설정합니다.

  2. 데이터 전송에 사용할 Dataproc 클러스터를 만듭니다.

  3. Google Cloud CLI를 사용하여 클러스터의 마스터 인스턴스에 연결합니다. 예를 들면 다음과 같습니다.

    gcloud compute ssh [CLUSTER_NAME]-m

    CLUSTER_NAME은 작업에 만든 Dataproc 클러스터의 이름입니다. -m 서픽스는 마스터 인스턴스를 나타냅니다.

  4. 클러스터의 마스터 인스턴스에서 DistCp 명령어를 실행하여 데이터를 이동합니다.

데이터를 이동하는 데 필요한 실제 DistCp 명령어는 다음과 유사합니다.

hadoop distcp hdfs://nn1:8020/20170202/ gs://bucket/20170202/

이 예시에서 nn1 및 8020은 소스 데이터가 저장된 namenode와 포트이고 bucket은 파일을 복사할 Cloud Storage 버킷의 이름입니다.

Cloud Storage 트래픽은 기본적으로 전송 계층 보안(TLS)을 통해 암호화됩니다.

데이터 전송 유효성 검사

여러 HDFS 클러스터 또는 HDFS와 Cloud Storage와 같은 고유한 스토리지 시스템간에 데이터를 복사하거나 이동할 때 데이터 무결성을 보장하기 위해 일부 유형의 유효성 검사를 수행하는 것이 좋습니다. 이 유효성 검사는 전송 중에 데이터가 변경되지 않았음을 확인하는 데 필수적입니다. 자세한 내용은 데이터 전송 유효성 검사 가이드를 참조하세요.

요청 비율 높이기

Cloud Storage는 일관된 객체 목록을 제공하기 위해 각 버킷의 객체 키 색인을 유지보수합니다. 이 색인은 사전 순으로 저장되며 버킷에서 객체가 작성되거나 삭제될 때마다 업데이트됩니다. 모든 키가 작은 범위의 색인에 있는 객체를 추가 및 삭제하면 자연스럽게 경합이 발생할 가능성이 증가합니다.

Cloud Storage는 이러한 경합을 감지하고 영향을 받은 색인 범위의 부하를 여러 서버에 자동으로 다시 분배합니다. 새로운 프리픽스로 객체를 작성하고 초당 1000건 이상의 쓰기 요청을 받을 것으로 예상되는 경우 Cloud Storage 문서에 설명된 대로 요청 비율을 점차적으로 늘려야 합니다. 이렇게 하지 않으면 일시적으로 지연 시간과 오류 발생률이 증가할 수 있습니다.

데이터 마이그레이션 속도 향상

온프레미스 클러스터에서 Google Cloud로 데이터를 전송하는 가장 간단한 방법은 공개 인터넷을 통해 VPN 터널을 사용하는 것입니다. VPN 터널 한 개가 필요한 처리량을 제공하지 못하면 VPN 터널을 여러 개 만들 수 있으며 Google Cloud는 자동으로 트래픽을 터널 여러 개에 분산하여 대역폭을 추가 제공합니다.

때로는 다중 VPN 터널로의 마이그레이션에 필요한 대역폭 또는 연결 안정성도 제공하지 못하는 경우가 있습니다. 처리량을 개선하려면 다음과 같은 방법을 고려하세요.

  • 네트워크와 Google의 에지 접속 지점(PoP) 간에 직접 피어링을 사용하세요. 이렇게 하면 네트워크와 Google Cloud 간의 홉 수가 줄어듭니다.

  • Cloud Interconnect 서비스 제공업체를 사용하여 Google 네트워크에 직접 연결합니다. 서비스 세부 사항은 파트너마다 다릅니다. 대부분은 네트워크 가용성과 성능을 위한 SLA를 제공합니다. 자세한 내용은 서비스 제공업체에 직접 문의하세요.

Google Cloud 파트너와 협력

Google Cloud는 데이터 마이그레이션에 도움이 되는 여러 파트너와 협력합니다. 데이터 마이그레이션에 유용한 서비스에 대한 자세한 내용은 Cloud Storage를 지원하는 파트너를 참조하세요. 사용 가능한 서비스와 조건은 제공업체마다 다르므로 세부 정보를 얻으려면 직접 문의하시기 바랍니다.

다음 단계