글로벌 데이터 배포를 위한 올바른 아키텍처 선택

이 솔루션은 Google Cloud 리전에 데이터를 배포하는 데 사용할 수 있는 세 가지 아키텍처 예시를 설명합니다.

많은 기업이 지리적으로 분산된 위치의 데이터로 작업하면서 거의 실시간으로 클라이언트 요청에 응답합니다. 예를 들어 디지털 광고를 위한 수요 측 플랫폼(DSP)에는 지리적 위치 또는 현재 네트워크 부하에 관계없이 데이터베이스 응답 시간이 20밀리초 미만일 것으로 예상하는 고객이 있을 수 있습니다. 네트워크 아키텍처가 물리적 거리에 기반한 대기 시간에 취약하고 사용량 급증의 영향을 크게 받는 단일 중앙 데이터베이스를 기반으로 하는 경우 이러한 종류의 전역 DSP 솔루션을 구현할 수 없습니다.

데이터 스토리지를 위한 분산 아키텍처를 통해 이러한 요구를 충족시킬 수 있습니다. 모든 아키텍처가 모든 비즈니스 요구에 적합한 것은 아니며 각 아키텍처에는 다양한 강점과 약점이 있습니다. 따라서 이 솔루션은 전반적인 비즈니스 전략을 구현하고 네트워크 구현 방식을 안내하는 데 도움이 되는 다양한 Google Cloud 대안을 제공합니다.

Google Cloud의 장점

Google Cloud는 전 세계적으로 강력하고 안정적인 네트워크 대역폭을 제공합니다. 또한 Google Cloud에는 다음과 같은 다양한 이점이 있습니다.

Google Cloud는 매우 유연하며 이를 사용하여 글로벌 가상 네트워크를 구축할 수 있으므로 애플리케이션이 비공개 IP 주소를 사용하여 여러 리전에서 보다 안전하게 통신할 수 있습니다. 예를 들어 us-central1asia-east1 같은 두 리전에서 Compute Engine 가상 머신(VM) 인스턴스를 설정할 수 있습니다. Virtual Private Cloud 네트워크를 만들면 이러한 VM 인스턴스가 사설 IP 주소를 사용하여 서로 직접 통신할 수 있습니다. 이 방법으로 조직은 인스턴스 간에 보안 통신을 유지할 수 있습니다.

Google Cloud Anycast IP를 사용하면 부하 분산과 같은 관리형 서비스에 단일 전역 IP 주소가 할당됩니다. Anycast IP를 사용하면 모든 리전에서 부하 분산기를 구성하는 대신 단일 전역 부하 분산기를 만들 수 있습니다. 전역 부하 분산기는 클라이언트 요청을 가장 가까운 리전에서 실행되는 애플리케이션으로 라우팅하고 변화하는 요구사항에 맞게 자동으로 확장합니다.

세 가지 예시 데이터 배포 아키텍처

이 섹션에서는 세 가지 배포 아키텍처를 설명하고 아키텍처가 적절한 상황이 무엇인지에 대해 설명합니다. 아키텍처 및 사용 사례는 다음과 같습니다.

  • Google Cloud 및 온프레미스 서비스로 구성된 하이브리드 배포. 일부 온프레미스 서비스를 유지하는 동시에 Google Cloud 기능을 이용하려는 경우에 적합합니다. Google Cloud는 현재 네트워크에 연결되며 진행 중인 회사 프로세스에 통합됩니다. 일부 또는 모든 온프레미스 데이터가 Google Cloud로 복사되거나 Google Cloud와 통합됩니다.

  • Google Cloud 및 기타 클라우드 서비스 공급자 플랫폼으로 구성된 하이브리드 배포. 현재 클라우드 서비스 제공업체의 운영을 유지하는 동시에 Google Cloud 기능을 일부 포함하고 두 시스템이 통신하도록 구성하려는 경우에 적합합니다.

  • 여러 리전을 사용하는 Google Cloud. 전역 규모로 준동기식 데이터 전송을 지원하려는 경우에 적합합니다. 여러 리전에서 Google Cloud를 구성하면 전역적으로 매우 신속하고 준동기식으로 데이터를 전송할 수 있습니다.

하이브리드 배포: Google Cloud 및 온프레미스 서비스

온프레미스 서비스와 Google Cloud를 결합하는 것은 데이터를 온프레미스로 저장하고 데이터를 Google Cloud로 전파하는 애플리케이션과 관련된 사용 사례에 적합합니다.

예를 들어 소매 업계에서 새 제품에 대한 기본 데이터(마스터 데이터라고도 함)는 이전 인벤토리 관리 시스템을 위해 온프레미스 데이터베이스에 삽입할 수 있습니다. 회사는 온라인 웹 스토어에 사용되는 Google Cloud 데이터베이스에 해당 데이터를 전파해야 할 수도 있습니다. 하이브리드 방식을 사용하면 기존 온프레미스 시스템에 영향을 주지 않고 Google Cloud를 사용하는 새로운 시스템을 구축할 수 있습니다. 이 아키텍처에서 Google Cloud는 본질적으로 온프레미스 네트워크 구조와 함께 작동합니다.

하이브리드 Google Cloud와 온프레미스 배포를 구현할지 여부를 결정할 때 다음 사항을 고려해야 합니다.

  • 데이터가 온프레미스 및 Google Cloud 모두에 있는 경우 기본 데이터로 취급할 데이터와 이 기본 데이터가 있어야 하는 위치를 결정해야 합니다. 예를 들어 Google Cloud 데이터를 기본 데이터로 정의할 수 있습니다. 이 경우 Google Cloud는 하나 또는 여러 개의 온프레미스 환경을 연결하는 데이터 허브 역할을 하며 데이터를 서로 교환합니다. Google Cloud 환경에서 추가되거나 업데이트된 데이터는 온프레미스 시스템으로 전송됩니다. 또는 온프레미스 시스템이 기본 데이터를 저장하고 주기적으로 Google Cloud를 업데이트할 수 있습니다.
  • 이 하이브리드 환경용 애플리케이션을 개발하는 경우 관리형 서비스는 Google Cloud의 리소스에만 사용할 수 있습니다. 온프레미스 및 Google Cloud 환경에서 실행되는 애플리케이션은 자동 백업, 중복성, 확장성 같은 관리형 서비스를 사용하지 못할 수 있습니다.
  • 데이터를 포팅 가능하게 유지하고 일관된 관리 작업을 보장하기 위해 온프레미스 및 Google Cloud 배포의 가상 머신에 MySQL과 같은 플랫폼 간 데이터 저장소를 호스팅하는 것이 더 쉬울 수 있습니다.

하이브리드 아키텍처 예시

다음 다이어그램은 Google Cloud 및 온프레미스 시스템을 사용하는 하이브리드 아키텍처의 예시입니다.

하이브리드 시스템의 아키텍처

예시 아키텍처에서 각 항목은 다음과 같습니다.

  • 온프레미스 파일 서버와 Cloud Storage 간에 데이터가 교환됩니다. 로컬 파일을 Google Cloud로 백업하거나, 파일을 입력으로 일괄 처리하거나, Google Cloud에서 온프레미스 네트워크로 파일을 다운로드하는 작업이 포함될 수 있습니다.
  • 로컬 데이터 센터의 커스텀 애플리케이션은 REST APIApp Engine의 애플리케이션에 액세스하여 데이터를 검색하거나 전송합니다. REST 요청은 일반적으로 동기식이고 결과가 반환될 때까지 클라이언트를 차단합니다. 이 아키텍처에서 App Engine은 필요에 따라 용량을 늘리기 위해 자동 확장 기능을 제공하므로 이러한 동기 호출에 대한 지연 시간을 낮게 유지할 수 있습니다.
  • 커스텀 애플리케이션은 나중에 처리하기 위해 Pub/Sub에 메시지를 직접 제출하여 복제된 큐에 저장합니다. Pub/Sub에 메시지가 도착하면 Pub/Sub가 즉시 상태를 반환하고 클라이언트를 차단하지 않습니다. Cloud Functions, Dataflow, Compute Engine에서 실행되는 애플리케이션 및 기타 방법을 사용하여 비동기적으로 메시지를 검색하고 처리할 수 있습니다. 온프레미스 환경의 클라이언트 애플리케이션도 메시지를 검색할 수 있습니다.
  • 온프레미스 데이터베이스에 저장된 데이터는 Cloud SQL에서 관리하는 데이터베이스에 일괄적으로 로드할 수 있도록 CSV 파일 형식으로 내보내지고 Google Cloud로 업로드됩니다.
  • Firebase 데이터베이스는 온프레미스 시스템과 Google Cloud 간에 데이터를 동기화하는 데 사용됩니다. 애플리케이션은 데이터베이스의 키를 구독하고 값이 업데이트될 때마다 애플리케이션에 실시간으로 알림을 보내 업데이트된 값을 받습니다. Firebase와 상호작용하는 애플리케이션은 온프레미스, Google Cloud 또는 이 둘 모두가 될 수 있습니다.

하이브리드 배포: Google Cloud 및 기타 클라우드 제공업체

Google Cloud를 다른 클라우드 제공업체와 결합하여 데이터를 보다 효과적으로 배포하고 여러 가지 안전 기기를 활용하거나 특정 Google Cloud 기능을 활용할 수 있습니다. 이 아키텍처는 이미 다른 클라우드 제공업체에서 실행 중인 프로덕션 서비스를 갖추고 있지만 Google Cloud 기능을 활용하고자 할 때 선택하는 것이 좋습니다. 예를 들어 BigQuery를 사용하여 애플리케이션 데이터는 물론 로그 및 모니터링 측정항목을 분석할 수 있습니다.

이 아키텍처는 앞에서 설명한 하이브리드 온프레미스 Google Cloud 아키텍처와 유사합니다. Google Cloud와 다른 클라우드 제공업체의 하이브리드 배포를 구현할 때 다음 사항을 고려해야 합니다.

  • jcloudslibcloud와 같은 오픈소스 멀티 클라우드 클라이언트 라이브러리를 사용하여 Google Cloud와 다른 클라우드 서비스 간에 API를 통합할 수 있습니다.
  • Google Cloud는 Amazon Web Services(AWS)의 데이터를 전송하는 방법을 제공합니다(예: Storage Transfer Service, Cloud Monitoring, Cloud Logging). 로그는 BigQuery로 내보내 추가 분석을 시행할 수 있습니다.
  • Pub/Sub는 전역 서비스이며 애플리케이션은 Pub/Sub 큐가 있는 리전을 알 필요가 없습니다. 메시지를 게시하거나 전역적으로 제공되는 주제를 구독할 수 있습니다. Google Cloud를 사용할 경우 클라이언트 앱은 하나의 IP 주소 및 포트 집합만 인식하면 됩니다. 다른 클라우드 제공업체의 경우 큐가 특정 리전으로 국한될 수 있습니다. 이러한 경우 여러 리전에 앱을 배포할 때 클라이언트 앱이 모든 리전의 엔드포인트를 인식해야 합니다. 엔드포인트 추적은 새로운 리전의 서비스를 추가하는 경우 특히 번거로울 수 있습니다.

다른 클라우드 제공업체와 결합된 Google Cloud의 아키텍처 예시

다음 다이어그램은 GCP 및 기타 클라우드 제공업체를 포함한 하이브리드 아키텍처를 보여줍니다.

Google Cloud와 다른 클라우드 제공업체가 관련된 시스템의 아키텍처

예시 아키텍처에서 각 항목은 다음과 같습니다.

  • Pub/Sub와 다른 퍼블릭 클라우드 간에 메시지가 교환됩니다. 애플리케이션은 메시지 큐가 실제로 존재하는 리전을 알 필요가 없으므로 Pub/Sub는 전역 엔드포인트를 제공하며 클라우드 간의 메시지 허브 역할을 할 수 있습니다.
  • Cloud Monitoring 에이전트의 인스턴스는 다른 퍼블릭 클라우드의 가상 머신에 설치되어 CPU 사용률, 메모리 사용량, 프로세스 정보 등에 대한 측정항목을 수집합니다. Cloud Monitoring은 하이브리드 클라우드 환경에서 리소스 사용량을 모니터링합니다.
  • 다른 클라우드 환경의 가상 머신에서 실행되는 커스텀 애플리케이션은 REST API로 App Engine에 호스팅된 애플리케이션을 호출하여 데이터를 제출하거나 검색합니다.
  • Storage Transfer Service는 필요 시 또는 주기적으로 Amazon S3에서 파일을 직접 전송합니다. 전송된 파일을 Compute Engine에서 처리하여 Cloud SQL에 로드할 수 있습니다.

하이브리드 배포: 여러 리전의 Google Cloud

여러 리전의 Google Cloud 기반 아키텍처는 애플리케이션이 전역 사용자에게 서비스를 제공하고 최소 대기 시간을 사용하여 리전 간에 데이터를 동기화해야 하는 경우 적합한 선택입니다. 예를 들어 플레이어 간에 거의 실시간으로 동기화하여 전역적으로 작동해야 하는 인터넷 가능 비디오 게임이 있습니다.

이 아키텍처는 Google Cloud 관리형 서비스의 장점을 활용하여 관리 작업을 줄이고 시스템 디자인을 용이하게 합니다. Google Cloud를 사용하면 인프라 설계에 시간을 들이지 않고도 애플리케이션에 집중할 수 있습니다. 여러 리전에 Google Cloud의 하이브리드 배포를 구현할 때 다음 사항을 고려해야 합니다.

  • 메시지 게시자와 구독자는 어느 리전에서나 실행될 수 있으므로 멀티 리전 데이터 처리 서비스를 쉽게 배포할 수 있습니다. Pub/Sub는 애플리케이션이 실행되는 위치를 지정하지 않고도 서로 다른 리전에서 실행되는 애플리케이션 간에 메시지를 교환할 수 있습니다. 이 아키텍처에서 Pub/Sub 메시지는 Google Cloud 내에만 저장되어 인터넷을 통해 전송되지 않으므로 지연 시간이 단축됩니다.
  • Compute Engine 인스턴스의 애플리케이션은 Google Cloud VPC 네트워크 내의 비공개 IP 주소를 사용하여 여러 리전에서 직접 통신할 수 있습니다.
  • REST API를 사용하여 커스텀 애플리케이션을 느슨하게 결합할 수 있습니다. 아키텍처가 Google Cloud 환경 내에 완전히 속해 있으므로 App Engine으로 애플리케이션을 관리하여 관리 작업을 최소화할 수 있습니다.
  • 리전 간에 데이터를 분산한 후에는 Dataflow 또는 Dataproc을 사용하여 ETL 또는 분석 워크로드를 처리할 수 있습니다.

멀티 리전 Google Cloud 아키텍처 예시

다음 다이어그램은 여러 리전이 있는 Google Cloud 배포의 아키텍처를 보여줍니다.

여러 Google Cloud 리전을 포함하는 시스템의 아키텍처

예시 아키텍처에서 각 항목은 다음과 같습니다.

  • 하이브리드 클라우드 아키텍처와 마찬가지로 Cloud Monitoring은 모든 컴퓨팅 리소스를 모니터링하고 리소스 사용에 대한 통합된 전역 뷰를 표시합니다. 수집된 로그와 측정항목은 BigQuery로 내보내 추가 분석을 시행합니다.
  • 하이브리드 클라우드 아키텍처와 마찬가지로 Pub/Sub는 메시지 허브로 사용됩니다. Pub/Sub를 사용하므로 애플리케이션이 실제로 실행되는 위치에 관계없이 서비스를 느슨하게 결합할 수 있습니다.
  • App Engine 또는 Compute Engine에서 실행되는 커스텀 애플리케이션은 REST API를 사용하여 다른 커스텀 애플리케이션과 직접 메시지를 교환합니다. 이는 하이브리드 아키텍처보다 긴밀하게 결합된 아키텍처이므로 보다 예측 가능한 지연 시간을 달성합니다.
  • Storage Transfer Service를 사용하여 Cloud Storage 버킷을 동기화합니다. 또는 gsutil 도구를 여러 리전의 버킷 간 주문형 전송에 사용할 수 있습니다.

다음 단계

다음 링크에서 Google Cloud의 데이터 관리에 대해 자세히 알아보세요.