Google Cloud로 온프레미스 Hadoop 인프라 마이그레이션

이 가이드에서는 온프레미스 Apache Hadoop 시스템을 Google Cloud로 옮기는 방법을 간략히 설명합니다. 여기에서 설명하는 마이그레이션 프로세스는 Hadoop 작업을 Google Cloud로 옮길 뿐 아니라 클라우드 컴퓨팅에 최적화된 Hadoop 시스템의 장점을 활용하도록 작업을 조정해 줍니다. 또한 Hadoop 구성을 Google Cloud로 변환하기 위해 이해해야 하는 몇 가지 근본적인 개념을 소개합니다.

이 가이드는 온프레미스 Hadoop을 이동하는 방법을 설명하는 일련의 가이드 중 첫 번째입니다.

Google Cloud로 마이그레이션할 때의 이점

다양한 방식으로 Google Cloud를 사용하여 온프레미스 Hadoop 솔루션을 사용할 때보다 시간, 비용, 노력을 절약할 수 있습니다. 클라우드 기반 방식을 채택하면 전체 솔루션이 단순해지고 관리하기 쉬워지는 경우가 많습니다.

Hadoop 기본 지원

Google Cloud는 관리형 Hadoop 및 Spark 환경인 Dataproc을 포함합니다. Dataproc을 사용하면 대부분의 기존 작업을 최소한의 수정만으로 실행할 수 있으므로 이미 익숙한 모든 Hadoop 도구를 계속 사용해도 무방합니다.

관리형 하드웨어 및 구성

Google Cloud에서 Hadoop을 실행할 때는 물리적 하드웨어에 신경쓸 필요가 없습니다. 클러스터 구성을 지정하면 Dataproc이 리소스를 자동으로 할당합니다. 언제든지 클러스터를 확장할 수 있습니다.

간편한 버전 관리

오픈소스 도구를 최신 버전으로 유지하면서 협업하는 것은 Hadoop 클러스터 관리에서 가장 복잡한 부분 중 하나입니다. Dataproc을 사용하면 Dataproc 버전 관리가 이러한 작업 중 상당 부분을 해결해 줍니다.

유연한 작업 구성

일반적인 온프레미스 Hadoop 설정에서는 다용도로 사용되는 단일 클러스터를 사용합니다. Google Cloud로 이전하면 개별 작업에 집중하고 필요한 만큼 클러스터를 만들 수 있습니다. 따라서 종속 항목과 소프트웨어 구성 상호작용이 늘어나는 단일 클러스터를 유지보수하는 데 따르는 복잡성이 상당 부분 사라집니다.

마이그레이션 계획

온프레미스 Hadoop 솔루션에서 Google Cloud로 마이그레이션하려면 접근 방식의 전환이 필요합니다. 일반적인 온프레미스 Hadoop 시스템은 여러 업무 영역의 다양한 워크로드를 지원하는 모놀리식 클러스터로 구성됩니다. 따라서 시간이 지남에 따라 시스템이 점점 복잡해지고 관리자는 모놀리식 클러스터로 모든 작업을 처리하기 위해 일정한 절충을 해야 합니다. Hadoop 시스템을 Google Cloud로 옮기면 관리 업무의 복잡성을 낮출 수 있습니다. 그러나 Google Cloud에서 이러한 단순화를 이루고 최소한의 비용으로 최대한의 처리 효율을 끌어내려면 데이터와 작업을 구조화하는 방식을 다시 생각해야 합니다.

Dataproc은 Google Cloud에서 Hadoop을 실행하므로 영구 Dataproc 클러스터를 사용하여 온프레미스 설정을 그대로 복제하는 것이 가장 쉬운 솔루션처럼 여겨질 수 있습니다. 그러나 이 방식에는 몇 가지 제한사항이 있습니다.

  • Dataproc을 사용하여 영구 HDFS 클러스터에 데이터를 보관하는 방법은 Cloud Storage에 데이터를 저장하는 방법보다 비용이 높으며, 후자의 방법이 권장됩니다. 여기에 대해서는 이후에 자세히 설명합니다. 데이터를 HDFS 클러스터에 보관하면 다른 Google Cloud 제품에서 데이터를 사용하는 기능도 제한됩니다.
  • 오픈소스 기반 도구 중 일부를 다른 관련 Google Cloud 서비스로 보완하거나 대체하면 사용 사례에 따라 효율성 또는 경제성을 높일 수 있습니다.
  • 작업에 단일 영구 Dataproc 클러스터를 사용하는 방법은 개별 작업 또는 작업 영역을 처리하는 타겟 클러스터로 전환하는 방법보다 관리하기가 어렵습니다.

Hadoop 시스템을 Google Cloud로 마이그레이션하는 가장 경제적이고 유연한 방식은 대규모 다목적 영구 클러스터라는 개념에서 탈피하여 특정 작업을 실행하도록 설계된 단기적 소규모 클러스터라는 개념을 도입하는 것입니다. Cloud Storage에 데이터를 저장하여 여러 개의 임시 처리 클러스터를 지원합니다. 작업을 처리하는 데 사용하는 클러스터가 필요에 따라 할당되었다가 작업 완료와 함께 해제되므로 이 모델을 임시 모델이라고도 합니다.

아래 다이어그램은 온프레미스 시스템에서 Google Cloud의 임시 모델로 마이그레이션하는 가상적인 상황을 보여줍니다.

Google Cloud로 마이그레이션할 때 온프레미스 클러스터를 재배치하는 방법을 보여주는 다이어그램

이 예시에서는 온프레미스 클러스터 2개에서 실행되는 작업 4개를 Dataproc으로 옮깁니다. Google Cloud에서 작업을 실행하는 데 사용되는 임시 클러스터는 개별 작업의 효율을 극대화하도록 정의됩니다. 처음 두 개의 작업은 동일한 클러스터를 사용하고 세 번째 및 네 번째 작업은 각각 자체 클러스터에서 실행됩니다. 자체 작업을 마이그레이션할 때 작업의 구체적인 특성에 따라 적절하다고 판단되면 개별 작업 또는 작업 그룹에 맞추어 클러스터를 최적화할 수 있습니다. Dataproc으로 여러 클러스터를 빠르게 정의하고, 온라인화하고, 필요에 따라 확장할 수 있습니다.

이 예시에서는 온프레미스 HDFS 클러스터 2개의 데이터를 Cloud Storage 버킷으로 이동합니다. 첫 번째 클러스터의 데이터는 여러 버킷으로 분할되고, 두 번째 클러스터는 단일 버킷으로 옮겨집니다. Cloud Storage의 데이터 구조를 애플리케이션 및 비즈니스의 요구사항에 따라 맞춤설정할 수 있습니다.

예시에서는 전체 Google Cloud 마이그레이션을 시작할 때의 상태와 마쳤을 때의 상태를 표현합니다. 따라서 마치 한 단계로 완료되는 것처럼 생각될 수 있지만 Google Cloud로 마이그레이션하는 작업을 한 번에 완전히 끝내려고 생각하면 최선의 결과를 얻기 어렵습니다. 그보다는 온프레미스에서는 불가능했던 방식으로 새로운 도구 세트를 사용하도록 솔루션을 재구성한다는 개념으로 접근하시기 바랍니다. 이러한 재구성에 성공하려면 점진적 마이그레이션이 권장됩니다.

워크플로를 Google Cloud로 마이그레이션하는 데 권장되는 단계는 다음과 같습니다.

  1. 데이터부터 이동

    • 데이터를 Cloud Storage 버킷으로 이동합니다.
    • 소규모로 시작합니다. 백업 또는 보관 데이터를 사용하여 기존 Hadoop 시스템에 대한 영향을 최소화합니다.

  2. 실험

    • 데이터 중 일부를 사용하여 테스트하고 실험합니다. 각 작업에 대해 소규모 개념 증명을 진행합니다.
    • 데이터를 다루는 새로운 접근 방식을 시도합니다.
    • Google Cloud 및 클라우드 컴퓨팅 패러다임에 적응합니다.

  3. 특화된 임시 클러스터라는 관점에서 생각합니다.

    • 최대한 작은 클러스터를 사용합니다. 단일 작업 또는 긴밀하게 관련된 소규모 작업 그룹으로 범위를 제한합니다.
    • 작업에 필요할 때마다 클러스터를 만들고, 작업이 끝나면 클러스터를 삭제합니다.

  4. Google Cloud 도구를 적재적소에 사용합니다.

임시 모델로 이동

온프레미스 Hadoop에서 실행하던 워크플로를 Google Cloud에서 실행할 때 요구되는 가장 큰 발상의 전환은 모놀리식 영구 클러스터에서 탈피하여 특화된 임시 클러스터로 전환하는 것입니다. 작업을 실행해야 할 때 클러스터를 가동했다가 작업이 완료되면 삭제합니다. 작업에 필요한 리소스는 사용 중에만 활성화되므로 사용한 만큼만 비용을 지불하면 됩니다. 따라서 개별 작업에 맞추어 클러스터 구성을 조정할 수 있습니다. 영구 클러스터를 유지하고 구성하지 않으므로 리소스 사용 및 클러스터 관리에 따르는 비용이 절감됩니다.

이 섹션에서는 기존 Hadoop 인프라를 임시 모델로 이동하는 방법에 대해 설명합니다.

데이터와 연산 분리

워크플로의 영구 저장소로 Cloud Storage를 사용하면 다음과 같은 장점이 있습니다.

  • 액세스 권한을 더 쉽게 관리할 수 있습니다.
  • Hadoop 호환 파일 시스템(HCFS)이므로 기존 작업에서 쉽게 사용할 수 있습니다.
  • 많은 경우에 HDFS보다 빠릅니다.
  • HDFS보다 유지보수가 덜 필요합니다.
  • HDFS보다 데이터를 더 쉽게 마이그레이션할 수 있습니다.
  • 광범위한 Google Cloud 제품으로 데이터를 손쉽게 사용할 수 있습니다.
  • 영구 Dataproc 클러스터의 HDFS에 데이터를 보관하는 방법보다 비용이 상당히 저렴합니다.

데이터를 Cloud Storage에 영구적으로 저장해 두고 Dataproc에서 관리하는 임시 Hadoop 클러스터에서 작업을 실행할 수 있습니다.

경우에 따라서는 데이터를 BigQuery 또는 Bigtable 등의 다른 Google Cloud 기술 제품으로 이동하는 것이 더 합리적일 수 있습니다. 그러나 대부분의 범용 데이터는 Cloud Storage에 유지하는 것이 좋습니다. 이러한 대안적 저장소 옵션에 대해서는 이 가이드의 뒷부분에서 자세히 설명합니다.

임시 클러스터에서 작업 실행

Dataproc으로 손쉽게 클러스터를 만들고 삭제할 수 있으므로 단일 모놀리식 클러스터를 사용하는 방식에서 탈피하여 복수의 임시 클러스터를 사용할 수 있습니다. 이 방식의 장점은 다음과 같습니다.

  • 단일 장애점을 방지하고 데이터 파이프라인의 신뢰성을 높일 수 있습니다. 공유 장기 실행 클러스터가 오류 상태로 실행되면 전체 데이터 파이프라인이 차단될 수 있습니다. 스테이트풀(Stateful) 장기 실행 클러스터를 복구하는 데 시간이 오래 걸리므로 서비스 수준 목표(SLO) 위반이 발생합니다. 반면 문제가 있는 스테이트리스(Stateless) 임시 클러스터를 더 쉽게 삭제한 후 작업 재시도로 다시 만들 수 있습니다.
  • 작업 간 리소스 경합을 제거하여 더 예측 가능한 작업 성능을 제공하고 SLO 위반을 방지할 수 있습니다.
  • 개별 작업의 클러스터 구성과 자동 확장 정책을 최적화할 수 있습니다.
  • 작업의 임시 클러스터를 만들 때 최신 보안 패치, 버그 수정, 최적화를 가져올 수 있습니다.
  • 로그 및 임시 파일이 디스크에 가득 차거나 영역 부족으로 인해 클러스터를 확장할 수 없는 경우와 같은 장기 실행 클러스터의 일반적인 문제를 방지할 수 있습니다.
  • 임시 클러스터는 개발자가 사용할 때마다 구성되므로 시간이 경과하면 클러스터를 유지할 필요가 없습니다. 클러스터를 유지할 필요가 없으므로 작업 전반에서 도구를 관리하는 데 따른 관리 부담이 사라집니다.
  • 개발, 테스트, 프로덕션용 인프라를 별도로 관리할 필요가 없습니다. 필요에 따라 같은 정의를 사용하여 서로 다른 여러 클러스터 버전을 만들 수 있습니다.
  • 격리된 단일 작업 클러스터로 문제를 더 빨리 해결할 수 있습니다.
  • 작업에서 리소스를 사용할 때만 비용을 지불합니다.

Dataproc 초기화 작업을 사용하여 클러스터의 노드 구성을 정의할 수 있습니다. 따라서 개별 작업 및 관련 작업 그룹을 면밀하게 지원하는 데 필요한 여러 가지 클러스터 구성을 손쉽게 관리할 수 있습니다. 처음 시작하는 경우를 위해 제공된 샘플 초기화 작업을 참고해 보시기 바랍니다. 이 샘플에서는 초기화 작업을 직접 만드는 방법을 보여줍니다.

임시 클러스터의 수명 최소화

임시 클러스터의 요점은 작업의 수명 동안만 사용한다는 점입니다. 작업을 실행할 시점에 다음 프로세스를 따르시기 바랍니다.

  1. 적절히 구성된 클러스터를 만듭니다.

  2. 작업을 실행하고, Cloud Storage 또는 다른 영구 위치로 출력을 전송합니다.

  3. 클러스터를 삭제합니다.

  4. 필요에 따라 작업 출력을 사용합니다.

  5. Cloud Logging 또는 Cloud Storage에서 로그를 봅니다.

아래 다이어그램은 이 프로세스를 보여줍니다.

클라우드의 임시 작업 흐름을 보여주는 다이어그램

꼭 필요할 때만 소규모 영구 클러스터 사용

작업을 수행하는 데 영구 클러스터가 반드시 필요하다면 영구 클러스터를 만들 수 있습니다. 이 옵션은 비용이 많이 발생할 수 있으며, 임시 클러스터에서 작업을 수행할 방법이 있다면 권장되지 않습니다.

다음과 같은 방법으로 영구 클러스터의 비용을 최소화할 수 있습니다.

  • 최대한 소규모로 클러스터 생성
  • 해당 클러스터의 작업 범위를 최대한 적은 수의 작업으로 제한
  • 작업에 필요한 최소 규모로 클러스터의 노드 수를 맞추고 수요에 따라 동적으로 추가

점진적 이전

점진적 이전에는 여러 가지 장점이 있습니다. 예를 들면 다음과 같습니다.

  • 성숙한 환경에 내재된 복잡성으로부터 기존 Hadoop 인프라의 개별 작업을 분리할 수 있습니다.
  • 분리된 각 작업을 조사하여 요구사항을 평가하고 최선의 이전 경로를 판단할 수 있습니다.
  • 예기치 않은 문제가 발생해도 독립된 작업을 지연시키지 않으면서 대응할 수 있습니다.
  • 프로덕션 환경에 영향을 주지 않으면서 복잡한 각 프로세스에 대한 개념 증명을 진행할 수 있습니다.
  • 권장되는 임시 모델로 작업 부하를 신중하고 주의깊게 이동할 수 있습니다.

이전 방식은 Hadoop 환경에 따라 다르므로 모든 이전 시나리오에 걸맞는 보편적인 계획은 없습니다. 각 요소를 클라우드 컴퓨팅 패러다임으로 자유롭게 전환할 수 있는 이전 계획을 수립하시기 바랍니다.

점진적 마이그레이션의 일반적인 순서는 다음과 같습니다.

  1. 데이터의 일부를 Google Cloud로 이동합니다.

  2. 해당 데이터로 실험합니다.

    1. 데이터를 사용하는 기존 작업을 복제합니다.

    2. 데이터를 다루는 새 프로토타입을 만듭니다.

  3. 추가 데이터로 반복합니다.

가급적 중요도가 가장 낮은 데이터부터 시작하세요. 초기 단계에서는 백업 데이터 및 보관 파일을 사용하는 것이 좋습니다.

위험도가 낮으면서 시작 테스트로 적합한 작업 중 하나는 보관 데이터에 대해 급증 처리를 실행하는 백필 작업입니다. 현재 작업이 실행되기 전에 있었던 데이터 처리의 간극을 메우는 작업을 설정할 수 있습니다. 마이그레이션 계획의 초반 단계에서 버스트 처리 작업부터 시작하면 Google Cloud의 확장에 대한 경험을 쌓을 수 있습니다. 더 중요한 작업을 마이그레이션하기 시작할 때 이러한 경험이 도움이 됩니다.

아래 다이어그램은 일반적인 백필 하이브리드 아키텍처의 예입니다.

클라우드의 일반적인 백필 아키텍처를 보여주는 다이어그램

이 예시에는 두 개의 주요 구성요소가 있습니다. 첫 번째로, 온프레미스 클러스터에서 실행되는 예약된 작업이 인터넷 게이트웨이를 통해 Cloud Storage로 데이터를 푸시합니다. 두 번째로, 임시 Dataproc 클러스터에서 백필 작업이 실행됩니다. 백필 이외에도 Google Cloud에서 임시 클러스터를 실험적으로 사용하면서 향후 작업을 위한 개념 증명을 진행할 수 있습니다.

마이그레이션 완료 상황을 고려한 계획

지금까지 이 가이드에서는 전체 Hadoop 시스템을 온프레미스에서 Google Cloud로 이동하는 것이 목표라고 가정했습니다. 전적으로 Google Cloud에서 실행되는 Hadoop 시스템은 클라우드와 온프레미스에서 함께 실행되는 시스템보다 관리하기가 쉽습니다. 그러나 비즈니스 또는 기술적 요구사항에 따라서는 하이브리드 방식이 필요할 때도 많습니다.

하이브리드 솔루션 설계

다음과 같은 이유로 하이브리드 솔루션이 필요할 수 있습니다.

  • 클라우드 네이티브 시스템을 개발하는 중이므로, 개발이 끝나기 전까지는 해당 시스템에 의존하는 기존 시스템을 온프레미스로 계속 실행해야 합니다.
  • 비즈니스 요구사항에 따라 데이터를 온프레미스에 유지해야 합니다.
  • 온프레미스로 실행되는 다른 시스템과 데이터를 공유해야 하는데, 해당 시스템이 기술 또는 비즈니스 제한사항으로 인해 Google Cloud와 상호작용할 수 없습니다.

일반적인 하이브리드 솔루션은 4가지 주요 부분으로 구성됩니다.

  1. 온프레미스 Hadoop 클러스터

  2. 온프레미스 클러스터에서 Google Cloud로 연결

  3. Google Cloud의 중앙 집중식 데이터 스토리지

  4. Google Cloud에서 데이터를 다루는 클라우드 네이티브 구성요소

하이브리드 클라우드 솔루션에서 처리해야 하는 문제 중 하나는 시스템의 동기화 유지입니다. 즉, 한 곳에서 변경한 데이터를 다른 곳에 확실히 반영되도록 하는 것이 문제입니다. 서로 다른 환경에서 데이터가 사용되는 방식을 명확히 구분하면 동기화 문제가 단순해질 수 있습니다.

예를 들어 하이브리드 솔루션에서 보관 데이터만 Google Cloud에 저장하는 경우, 데이터가 특정 사용 기간에 도달할 때 온프레미스 클러스터에서 Google Cloud로 데이터를 이동하는 예약 작업을 설정할 수 있습니다. 그런 다음 Google Cloud의 보관 데이터를 다루는 모든 작업에서 온프레미스 클러스터에 변경사항을 동기화할 필요가 없도록 설정할 수 있습니다.

시스템을 분할하는 또 다른 방법은 특정 프로젝트 또는 작업 그룹의 모든 데이터와 작업을 Google Cloud로 이동하고 다른 작업은 온프레미스에 유지하는 것입니다. 그러면 복잡한 데이터 동기화 시스템을 만드는 대신 작업에만 집중할 수 있습니다.

보안 또는 장비 문제로 인해 온프레미스 클러스터를 Google Cloud에 연결하는 방법이 복잡해질 수 있습니다. 해결책 중 하나는 Cloud VPN을 통해 온프레미스 네트워크에 연결되는 Virtual Private Cloud를 사용하는 것입니다.

아래 다이어그램은 하이브리드 클라우드 설정의 예입니다.

일반적인 하이브리드 클라우드 Hadoop 아키텍처를 보여주는 다이어그램

설정 예시에서는 Cloud VPN을 사용하여 Google Cloud VPC를 온프레미스 클러스터에 연결합니다. 시스템은 VPC 내부에서 Dataproc을 사용하여 온프레미스 시스템이 보내는 데이터를 처리하는 영구 클러스터를 관리합니다. 이 과정에서 시스템 간에 데이터를 동기화해야 할 수 있습니다. 또한 영구 Dataproc 클러스터는 온프레미스 시스템이 보내는 데이터를 Google Cloud의 적절한 스토리지 서비스로 전송합니다. 위에서는 예시를 위해 Hadoop 워크로드가 처리하는 데이터의 목적지로 Google Cloud에서 가장 널리 사용되는 Cloud Storage, BigQuery, Bigtable을 스토리지로 사용합니다.

예시 솔루션의 나머지 절반에서는 필요에 따라 퍼블릭 클라우드에 생성되는 여러 임시 클러스터를 보여줍니다. 새 데이터를 수집하고 변환하는 작업을 비롯하여 다양한 작업에 이러한 클러스터를 사용할 수 있습니다. 이러한 작업의 결과는 VPC에서 실행되는 클러스터에서 사용하는 것과 동일한 저장소 서비스에 저장됩니다.

클라우드 네이티브 솔루션 설계

반면에 클라우드 네이티브 솔루션은 간결합니다. Cloud Storage에 저장된 데이터를 사용하여 모든 작업을 Google Cloud에서 실행하므로 데이터 동기화에 따르는 복잡성이 전혀 없지만, 서로 다른 작업에서 동일한 데이터를 어떻게 사용하는지 주의깊게 살펴볼 필요는 여전히 있습니다.

아래 다이어그램은 클라우드 네이티브 시스템의 예입니다.

일반적인 클라우드 네이티브 Hadoop 아키텍처를 보여주는 다이어그램

예시 시스템에는 몇 개의 영구 클러스터와 임시 클러스터가 있습니다. 두 가지 클러스터는 스토리지, 모니터링 등의 클라우드 도구와 리소스를 공유합니다. Dataproc은 표준화된 머신 이미지를 사용하여 클러스터에 속하는 VM의 소프트웨어 구성을 정의합니다. 이러한 사전 정의된 이미지를 필요한 VM 구성의 기초로 사용할 수 있습니다. 이 예에서는 대부분의 영구 클러스터가 버전 1.1에서 실행되고, 클러스터 중 하나는 버전 1.2에서 실행됩니다. 필요한 경우 언제든지 맞춤 VM 인스턴스로 새 클러스터를 만들 수 있습니다. 따라서 테스트 및 개발 환경을 중요한 프로덕션 데이터 및 작업에서 격리할 수 있습니다.

예시된 임시 클러스터는 다양한 작업을 실행합니다. 이 예시에서는 Apache Airflow를 Compute Engine에서 실행하여 임시 클러스터 관련 작업을 예약합니다.

Google Cloud 서비스 작업

이 섹션에서는 Hadoop을 Google Cloud로 마이그레이션할 때 추가로 고려해야 할 몇 가지 사항을 설명합니다.

오픈소스 도구를 Google Cloud 서비스로 교체

Google Cloud는 Hadoop 시스템과 함께 사용할 수 있는 여러 가지 제품을 제공합니다. Google Cloud 제품을 사용하면 Google Cloud에서 해당하는 오픈소스 제품을 실행할 때보다 여러 가지 장점이 있습니다. 플랫폼이 제공하는 폭넓은 제품에 대해서는 Google Cloud 제품 및 서비스를 참조하세요.

리전 및 영역 사용

데이터와 작업을 구성하기 전에 지역과 리전에 따른 영향을 이해해야 합니다. 리소스를 할당할 리전 또는 영역을 지정해야 하는 Google Cloud 서비스가 많습니다. 요청을 보내는 리전이 리소스가 저장된 리전과 다르면 요청 지연 시간이 증가할 수 있습니다. 또한 서비스의 리소스와 영구 데이터가 서로 다른 리전에 위치할 경우 Google Cloud 서비스를 호출할 때 필요한 데이터 중 일부가 처리 전에 영역 간에 복사되지 않을 수도 있습니다. 이로 인해 성능이 상당히 저하될 수 있습니다.

인증 및 권한 구성

Google Cloud 서비스의 권한 관리는 온프레미스 Hadoop 환경에서 익숙해진 관리보다 세밀하지 않을 가능성이 높습니다. 마이그레이션을 시작하기 전에 Google Cloud에서 액세스 관리가 작동하는 방식을 이해해야 합니다.

Identity and Access Management(IAM)는 클라우드 리소스에 대한 액세스를 관리합니다. 관리 작업의 단위는 계정 및 역할입니다. 계정은 사용자 또는 요청을 식별(인증)하고, 계정에 부여된 역할은 액세스 수준을 결정(승인)합니다. 대부분의 Google Cloud 서비스는 권한을 세부적으로 설정하는 데 도움이 되는 자체 역할 세트를 제공합니다. 마이그레이션을 계획하는 과정에서 IAM이 Cloud Storage 및 Dataproc과 상호작용하는 방식을 숙지해야 합니다. 각 Google Cloud 서비스를 시스템에 추가하면서 해당 서비스의 권한 모델을 알아보고, 사용할 서비스 전반을 대상으로 어떻게 역할을 정의할지를 고민해 보세요.

Cloud Logging으로 작업 모니터링

Google Cloud 작업은 Cloud Logging으로 로그를 전송하며, 여기에서 로그에 손쉽게 액세스할 수 있습니다. 다음과 같은 방법으로 로그를 가져올 수 있습니다.

Compute Engine으로 에지 노드 관리

Compute Engine을 사용하여 Dataproc Hadoop 클러스터의 에지 노드에 액세스할 수 있습니다. 대부분의 Google Cloud 제품과 마찬가지로 웹 기반 콘솔, 명령줄, 웹 API 등의 다양한 관리 옵션이 있습니다.

Google Cloud 빅데이터 서비스 사용

Google Cloud에서 구조화되지 않은 데이터를 저장하는 기본적인 방법은 Cloud Storage이지만 다른 스토리지 옵션도 있습니다. 데이터에 따라서는 빅데이터 전용으로 설계된 제품의 저장소가 더 적합할 수 있습니다.

Bigtable을 사용하여 대량의 희소 데이터를 저장할 수 있습니다. Bigtable은 낮은 지연 시간과 작업에 대응하는 높은 확장성을 제공하는 HBase 규격 API입니다.

데이터 웨어하우징에는 BigQuery를 사용할 수 있습니다.

다음 단계