고객 관리형 비공개 네트워크를 통한 AWS 또는 Azure에서의 전송

Google Cloud Cross-Cloud Interconnect 또는 Partner Interconnect를 사용하여 설정된 비공개 네트워크 연결은 AWS 또는 Azure와 Cloud Storage 간의 데이터 전송에 다음과 같은 상당한 이점을 제공할 수 있습니다.

  • 잠재적인 비용 최적화: 잠재적으로 출구 비용을 절감할 수 있습니다. 이는 기존 상호 연결이 있거나 대규모 또는 반복적인 데이터 전송을 수행하는 고객에게 유용하며, 장기적으로 상당한 비용 절감 효과를 가져올 수 있습니다.
  • 전용 네트워크 대역폭: 인터커넥트를 사용하면 일관되고 높은 용량의 처리량과 짧은 지연 시간을 제공할 수 있으며, 이는 대규모의 시간 민감형 마이그레이션과 실시간 데이터 동기화에 중요합니다.
  • 규정 준수 요구사항 충족: 규제 요건에 따라 데이터를 공개 인터넷에 저장할 수 없는 워크로드에 적합합니다. 이 기능을 사용하면 상호 연결을 사용하여 비공개로 데이터를 전송하여 규정을 준수하고, 데이터 주권을 지원하고, 감사를 간소화할 수 있습니다.

개요

이 문서에서는 다음 단계를 안내합니다.

  • Cross-Cloud Interconnect 주문 및 구성
  • S3 또는 Azure에서 엔드포인트 만들기
  • 하이브리드 연결로 리전 내부 프록시 네트워크 부하 분산기 설정
  • 서비스 디렉터리에 부하 분산기 등록
  • 전송 만들기
  • 트래픽이 상호 연결을 사용하고 있는지 확인

필수 권한

다음 각 섹션을 완료하려면 특정 권한이 필요합니다. 이러한 권한은 해당 단계의 문서에 나열되어 있습니다.

상호 연결 옵션

Storage Transfer Service는 크로스 클라우드 인터커넥트(CCI) 또는 파트너 인터커넥트를 통해 AWS 및 Azure에서 데이터를 전송할 수 있습니다.

아래 단계는 CCI에만 적용되지만 Partner Interconnect의 네트워킹을 구성할 때도 적용됩니다.

Cross-Cloud Interconnect 주문 및 구성

Cross-Cloud Interconnect는 Google Cloud와 다른 클라우드 제공업체 간의 전용 물리적 연결입니다.

이미 CCI 연결이 있는 경우 다음 섹션으로 건너뜁니다.

AWS

안내에 따라 Amazon Web Services에 연결하여 새 교차 Cloud Interconnect를 주문하고 구성합니다. Google Cloud와 AWS에서 네트워킹을 구성하려면 올바른 권한이 필요합니다.

AWS와 Google Cloud 간에 CCI를 주문하고 구성하는 단계를 설명하는 동영상을 시청하세요.

Azure

안내에 따라 Microsoft Azure에 연결하여 새 Cross-Cloud Interconnect를 주문하고 구성합니다. Google Cloud와 Azure에서 네트워킹을 구성하려면 적절한 권한이 필요합니다.

Azure와 Google Cloud 간에 CCI를 주문하고 구성하는 단계를 설명하는 동영상을 시청하세요.

Cloud Storage 버킷이 리전 버킷인 경우 버킷과 동일한 리전에 CCI를 구성하여 네트워크 지연 시간을 줄여야 합니다.

S3 또는 Azure에서 엔드포인트 만들기

S3 또는 Azure 계정에 엔드포인트를 만듭니다.

AWS

Amazon Web Services 계정에서 S3에 연결되는 VPC 엔드포인트를 만듭니다.

인터페이스 VPC 엔드포인트를 사용하여 AWS 서비스에 액세스라는 AWS 안내에 따라 엔드포인트를 만듭니다.

Azure

이 단계에 따라 Azure의 스토리지 계정에 비공개 엔드포인트를 구성합니다.

Storage Transfer Service에는 *.blob.core.microsoft.net 엔드포인트가 필요합니다. *.dfs.core.microsoft.net 엔드포인트는 지원되지 않습니다.

생성되면 엔드포인트의 IP 주소를 기록해 둡니다. 다음 섹션에서 부하 분산기를 만들 때 IP 주소를 지정해야 합니다.

하이브리드 연결로 리전 내부 프록시 네트워크 부하 분산기 설정

Google Cloud에서 하이브리드 연결로 리전 내부 프록시 네트워크 부하 분산기를 설정합니다. 이렇게 하면 부하 분산기와 동일한 VPC 네트워크에서 실행되는 클라이언트로 제한되고 이전 섹션에서 만든 S3 VPC 엔드포인트 또는 Azure Storage 비공개 엔드포인트로 트래픽을 라우팅하는 내부 IP 주소가 제공됩니다.

Cloud Interconnect와 인터페이스하는 VLAN 연결과 동일한 프로젝트 및 VPC 네트워크에 부하 분산기를 만들어야 합니다. 인터커넥트는 동일한 조직 내의 다른 프로젝트에 있을 수 있지만 연결은 부하 분산기와 동일한 VPC 및 리전에 있어야 합니다.

하이브리드 연결 NEG에 엔드포인트 추가 단계에 도달하면 S3 VPC 엔드포인트 또는 Azure Storage 비공개 엔드포인트 IP 주소를 지정합니다.

다음 섹션에서 지정해야 하므로 NLB의 프런트엔드 IP 주소와 포트를 기록해 둡니다.

연결 유효성 검사

계속하기 전에 부하 분산기가 원격 스토리지 엔드포인트에 연결할 수 있는지 확인하는 것이 좋습니다.

방법은 다음과 같습니다.

  1. 부하 분산기와 동일한 VPC 네트워크에 Compute Engine VM을 만듭니다.
  2. VM에서 curl을 사용하여 부하 분산기의 IP 주소와 포트에 대한 연결을 테스트합니다.

    curl -v --resolve HOSTNAME:LOAD_BALANCER_IP:PORT https://HOSTNAME
    

    각 항목의 의미는 다음과 같습니다.

    • <var>HOSTNAME</var>은 소스 스토리지 제공업체의 호스트 이름입니다.
      • AWS S3의 경우 버킷의 리전에 해당하는 S3 API 엔드포인트(예: s3.us-west-1.amazonaws.com)를 사용합니다.
      • Azure Storage의 경우 스토리지 계정의 blob 엔드포인트(예: mystorageaccount.blob.core.windows.net)를 사용합니다.
    • <var>PORT</var>은 부하 분산기의 전달 규칙에 구성된 포트입니다(일반적으로 443).
    • <var>LOAD_BALANCER_IP</var>는 부하 분산기의 프런트엔드 IP 주소입니다.

오류를 포함한 원격 엔드포인트의 응답은 연결이 성공했음을 나타냅니다. 연결 제한 시간은 계속하기 전에 해결해야 하는 네트워크 설정의 잘못된 구성을 나타냅니다.

서비스 디렉터리에 NLB 등록

서비스 디렉터리에 NLB를 등록합니다. Storage Transfer Service는 서비스 디렉터리를 사용하여 부하 분산기의 주소를 확인하고 여기에 직접 연결합니다.

안내에 따라 내부 부하 분산기를 등록합니다. 전달 규칙을 지정할 때 만든 부하 분산기의 IP 주소와 포트를 사용합니다.

생성되면 서비스의 자체 링크를 기록해 둡니다. projects/{project_id}/locations/{location}/namespaces/{namespace}/services/{service} 형식을 사용합니다. 전송 작업을 만들 때 이 값이 필요합니다.

전송 만들기

서비스 에이전트에 다음 권한을 부여합니다. 서비스 에이전트를 가져오고 서비스 에이전트에 권한을 부여하는 방법은 Google 관리 서비스 에이전트 권한을 참고하세요.

Cross-Cloud Interconnect를 사용하는 전송 작업을 만들려면 Storage Transfer Service REST API를 사용해야 합니다. 다음과 같이 요청을 보냅니다. privateNetworkService 필드를 확인합니다. 여기에 서비스 디렉터리 서비스의 selfLink를 지정합니다.

AWS

POST https://storagetransfer.googleapis.com/v1/transferJobs

{
  "status": "ENABLED",
  "projectId": "PROJECT_ID",
  "transferSpec": {
    "awsS3DataSource": {
        "privateNetworkService": "SERVICE_SELF_LINK",
        "bucketName": "S3_BUCKET_NAME",
        "awsAccessKey": {
          "accessKeyId": "ACCESS_KEY_ID",
          "secretAccessKey": "SECRET_ACCESS_KEY"
        }
    },
    "gcsDataSink": {
        "bucketName": "GCS_BUCKET_NAME"
    }
  }
}

Azure

POST https://storagetransfer.googleapis.com/v1/transferJobs

{
  "status": "ENABLED",
  "projectId": "PROJECT_ID",
  "transferSpec": {
      "azureBlobStorageDataSource": {
          "privateNetworkService": "SERVICE_SELF_LINK",
          "storageAccount": "AZURE_SOURCE_NAME",
          "container": "AZURE_CONTAINER",
          "azureCredentials": {
              "sasToken": "AZURE_SAS_TOKEN",
          }
      },
      "gcsDataSink": {
          "bucketName": "GCS_BUCKET_NAME"
      }
  }
}

각 항목의 의미는 다음과 같습니다.

  • SERVICE_SELF_LINK은 서비스 디렉터리 서비스의 자체 링크입니다. projects/{project_id}/locations/{location}/namespaces/{namespace}/services/{service} 형식을 사용합니다.

다른 필드에 관한 자세한 내용은 transferSpec 참조 문서를 참고하세요.

트래픽이 상호 연결을 사용하고 있는지 확인

Cloud Monitoring을 사용하여 AWS 또는 Azure에서 인터커넥트를 통해 흐르는 트래픽을 확인합니다.

  1. Google Cloud 콘솔에서 하이브리드 연결 > Cloud Interconnect로 이동합니다.
  2. AWS/Azure 환경에 연결되는 VLAN 연결을 선택합니다.
  3. 연결 세부정보 페이지에서 모니터링 탭을 선택합니다. 데이터 전송을 나타내는 측정항목을 찾습니다. 구체적으로는 다음과 같습니다.
    • 수신 바이트: AWS 또는 Azure에서 Google Cloud VPC로 들어오는 데이터를 보여주는 측정항목입니다.
    • 운영 상태: 물리적 연결과 BGP 세션이 모두 정상적인 운영 상태인지 확인합니다.