Compute Engine 리전 선택 권장사항

이 문서에서는 Compute Engine 리소스에 사용할 Google Cloud리전을 선택할 때 고려해야 하는 기준에 대해 설명합니다. 일반적으로 클라우드 설계자나 엔지니어링 관리자가 결정합니다. 이 문서는 선택 프로세스 중 지연 시간에 중점을 두고 있으며 모바일이나 웹 앱, 게임과 같이 소비자가 액세스하는 앱을 대상으로 하지만 다른 사용 사례에도 적용되는 개념이 많습니다.

Google은 전 세계 여러 지역에 Compute Engine 리소스를 배포하고 있습니다. 지역 선택 시 고려해야 하는 여러 가지 요소는 다음과 같습니다.

리전별 제한
리전별 사용자 지연 시간
앱의 지연 시간 요구사항
지연 시간에 대한 제어 정도
짧은 지연 시간과 단순성 간 균형

용어

지역: 리소스를 실행하는 독립적인 지리적 영역입니다. 각 리전은 일반적으로 영역 3개 이상으로 구성됩니다.
영역: 리전 내에 있는 Google Cloud 리소스의 배포 영역입니다. 한 리전의 서로 다른 영역에 리소스를 배치하면 인프라 장애가 모든 리소스에 동시에 영향을 미치는 위험이 줄어듭니다.
Compute Engine 리소스: 가상 머신 인스턴스와 같은 Compute Engine의 리소스는 리전 내에 있는 영역에 배포됩니다. Google Kubernetes Engine 및 Dataflow와 같은 다른 제품은 Compute Engine 리소스를 사용하므로 동일한 리전이나 영역에 배포될 수 있습니다.
왕복 시간(RTT): IP 패킷을 보내고 확인을 받는 데 걸리는 시간입니다.

Compute Engine 리전을 선택해야 하는 경우

앱의 아키텍처 단계 초기에 어떤 Compute Engine 리전을 몇 개 사용할 것인지 결정합니다. 이 선택은 앱에 영향을 줄 수 있습니다. 예를 들면 다음과 같습니다.

동일한 사용자가 다른 시간에 다른 리전을 통해 연결할 수 있으므로 복사본 간에 데이터 일부를 동기화하면 앱의 아키텍처가 변경될 수 있습니다.
가격은 리전마다 다릅니다.
앱과 앱 데이터를 리전 간에 이동하는 프로세스는 번거롭고 때로는 비용이 많이 소요되므로 앱이 실행되면 이동을 피해야 합니다.

리전 선택 시 고려해야 할 요소

사용자는 일반적으로 자신이 있는 리전에 배포하지만 이 경우 이것이 가장 적합한 사용자 환경인지는 고려하지 않습니다. 글로벌 사용자층이 있는 유럽에서 단일 리전에 배포하려 한다고 가정해 보겠습니다. 대부분의 사람들은 유럽의 한 리전에 배포할 것을 고려하겠지만 일반적으로 미국이 다른 리전과 가장 많이 연결되어 있기 때문에 미국 리전 중 하나에 이 앱을 호스팅하는 것이 가장 좋습니다.

앱을 어디에 배포할 것인지에 영향을 주는 요소는 여러 가지가 있습니다.

지연 시간

고려해야 하는 기본 요소는 사용자 환경의 지연 시간입니다. 하지만 사용자 대기 시간은 캐싱 및 부하 분산 메커니즘과 같은 여러 측면의 영향을 받게 되므로 복잡한 문제입니다.

엔터프라이즈 사용 사례에서는 온프레미스 시스템에 대한 지연 시간이나 특정 사용자 또는 파트너 일부에 대한 지연 시간이 더 중요합니다. 예를 들어Google Cloud 에 상호 연결된 개발자 또는 온프레미스 데이터베이스 서비스에 가장 가까운 리전을 선택하는 것이 결정 요소가 될 수 있습니다.

가격 책정

Google Cloud 리소스 비용은 리전별로 다릅니다. 다음 리소스를 사용하여 가격을 예측할 수 있습니다.

여러 리전에 배포하려는 경우 리전 간에 동기화된 데이터에 적용되는 데이터 전송 비용이 있다는 점에 유의하세요.

다른 Google Cloud 서비스와 코로케이션

가능하면 Compute Engine 리소스를 다른 Google Cloud서비스와 같은 위치에 배치합니다. 지연 시간에 민감한 서비스 대부분을 모든 리전에서 사용할 수 있지만 일부 서비스는 특정 위치에서만 사용할 수 있습니다.

머신 유형 가용성

모든 리전에서 모든 CPU 플랫폼과 머신 유형을 사용할 수 있는 것은 아닙니다. 특정 CPU 플랫폼 또는 특정 인스턴스 유형의 가용성은 리전 및 영역(zone)별로 다릅니다. 특정 머신 유형을 사용하는 리소스를 배포하려면 해당 리소스의 영역 가용성을 확인하세요.

리소스 할당량

Compute Engine 리소스 배포는 리전 리소스 할당량에 따라 제한되므로 배포할 리전에 충분한 할당량을 요청해야 합니다. 대규모 배포를 계획하고 있는 경우 영업 팀과 영역 선택 사항을 초기에 논의하여 할당량이 충분한지 확인하세요.

무탄소 에너지 비율

Google은 리전이 위치한 전력망의 전기를 사용하여 각 Google Cloud 리전에 전력을 공급합니다. 전력망의 전기를 생산하는 발전소의 유형과 Google에서 전기를 사용하는 시점에 따라 전기에서 크고 작은 탄소 배출량이 발생합니다. 최근 Google은 2030년까지 모든 Google Cloud 리전에서 24시간 내내 언제 어디서나 애플리케이션에 무탄소 전기를 공급한다는 목표를 세웠습니다.

목표를 달성할 때까지 각 Google Cloud 리전에는 매 시간 탄소 기반 에너지원과 무탄소 에너지원이 혼합되어 공급됩니다. 이 측정항목을 무탄소 에너지 비율(CFE%)이라고 부르며 Google은 Google Cloud 리전의 CFE%를 게시하고 있습니다. 이 표를 사용하면 Google Cloud의 새 애플리케이션에 대한 아키텍처를 결정할 때 탄소가 미치는 영향을 고려할 수 있습니다. CFE%가 높은 리전을 선택하면 평균적으로 애플리케이션이 실행되는 시간 중 무탄소 에너지가 공급되는 시간이 늘어나 애플리케이션의 총 탄소 배출량이 감소합니다.

지연 시간 요구사항 평가

사용자 지연 시간이 길면 사용자 환경이 열악해질 수 있으므로 리전 선택에 있어 지연 시간은 중요한 고려 사항입니다. 사용자는 지연 시간의 일부 측면에 영향을 줄 수 있지만 일부는 제어할 수 없습니다.

지연 시간을 최적화할 때 많은 시스템 설계자는 네트워크 지연 시간 또는 사용자의 ISP와 가상 머신 인스턴스 간의 거리만을 고려합니다. 하지만 다음 다이어그램에서 볼 수 있듯이 이는 사용자 지연 시간에 영향을 줄 수 있는 다양한 요소 중 하나일 뿐입니다.

Compute Engine 리전 선택에서 지연 시간 평가

앱 설계자는 리전 선택 및 앱 지연 시간을 최적화할 수 있지만 가장 가까운 Google 에지 접속 지점(POP)에 대한 사용자의 라스트 마일과 지연 시간을 제어할 수 없습니다.

리전 선택은 지연 시간 전체가 아닌 Compute Engine 리전에 대한 지연 시간에만 영향을 미칩니다. 이는 사용 사례에 따라 전체 지연 시간의 일부일 수 있습니다. 예를 들어 사용자가 이동통신사 네트워크를 주로 사용하는 경우 전체 사용자 지연 시간에 거의 영향을 주지 않으므로 리전을 최적화하려는 시도는 중요한 일이 아닐 수 있습니다.

라스트 마일 지연 시간

이 세그먼트의 지연 시간은 인터넷에 액세스하는 데 사용되는 기술에 따라 달라집니다. 예를 들어 최신 네트워크에서 ISP에 연결하는 데 걸리는 일반적인 지연 시간은 1~10ms입니다. 반대로 3G 셀룰러 네트워크의 일반적인 지연 시간은 100~500ms입니다. DSL 및 케이블 제공업체의 지연 시간 범위는 약 10~60ms입니다.

Google 프런트엔드 및 에지 POP 지연 시간

배포 모델에 따라 Google 네트워크 에지에 대한 지연 시간도 중요합니다. 이 경우 전역 부하 분산 제품은 TCP 및 SSL 세션을 종료하고 Cloud CDN은 캐시된 결과를 제공합니다. 제공된 콘텐츠에 따르면 전체 데이터 중 일부만 검색하면 되므로 많은 왕복 이동이 여기에서 이미 종료되었을 수 있습니다. 표준 네트워크 서비스 등급을 사용하는 경우 이 지연 시간은 상당히 길 수 있습니다.

Compute Engine 리전 지연 시간

사용자 요청은 에지 POP의 Google 네트워크로 들어갑니다. Compute Engine 리전은 Google Cloud 리소스 처리 요청이 있는 위치입니다. 이 세그먼트는 에지 POP와 Compute Engine 리전 간의 지연 시간이며 완전히 Google 글로벌 네트워크에 있습니다.

앱 지연 시간

앱이 요청을 처리하는 데 필요한 시간을 포함하여 요청에 응답하는 앱의 지연 시간입니다.

앱마다 지연 시간 요구사항이 다릅니다. 사용자는 앱에 따라 지연 시간 문제에 관대할 수 있습니다. 비동기적으로 상호작용하는 앱 또는 지연 시간 기준점이 높은 모바일 앱(100밀리초 이상)을 사용자 환경 저하 없이 단일 리전에 배포할 수 있습니다. 하지만 실시간 게임과 같은 앱의 경우 지연 시간이 짧아도 사용자 환경에 더 큰 영향을 줄 수 있습니다. 이러한 앱 유형은 사용자에게 가까운 리전 여러 곳에 배포하세요.

글로벌 배포 패턴

이 섹션에서는 다양한 배포 모델이 지연 시간 요소에 어떤 영향을 미치는지에 대해 설명합니다.

단일 리전 배포

다음 이미지는 단일 리전 배포에 대해 설명합니다.

단일 프런트엔드 배포 지연 시간

앱이 전역 사용자층을 제공하더라도 대부분의 경우 단일 리전을 선택하는 것이 좋습니다. 짧은 지연 시간의 이점보다 멀티 리전 배포로 추가된 복잡성이 더 중요한 문제일 수 있습니다. 단일 리전 배포를 사용하더라도 Cloud CDN 및 글로벌 부하 분산과 같은 최적화를 사용하여 사용자 지연 시간을 줄일 수 있습니다. 백업 및 재해 복구를 위해 두 번째 리전을 사용할 수 있지만 이 리전은 앱의 서비스 경로에 영향을 미치지 않으므로 사용자 지연 시간에는 영향이 없습니다.

여러 리전의 분산 프런트엔드 및 단일 리전의 백엔드

다음 다이어그램은 여러 리전에 프런트엔드를 배포하지만 백엔드를 단일 리전으로 제한하는 배포 모델을 보여줍니다. 이 모델을 사용하면 여러 리전에서 데이터를 동기화할 필요 없이 프런트엔드 서버에 대한 지연 시간을 줄일 수 있습니다.

분산된 프런트엔드 배포 지연 시간

이 배포 모델을 사용할 경우 평균 사용자 요청에 데이터 요청이 필요하지 않거나 앱이 결과를 제공할 때까지 중앙 백엔드에 대한 데이터 요청이 거의 없으면 사용자 지연 시간이 줄어듭니다. 예시로는 프런트엔드에 지능형 캐싱 레이어를 배포하거나 데이터 쓰기를 비동기식으로 처리하는 앱이 있습니다. 백엔드로의 전체 왕복이 필요한 많은 요청을 보내는 앱은 이 모델의 이점을 활용할 수 없습니다.

여러 리전의 분산된 프런트엔드 및 백엔드

여러 리전에 프런트엔드 및 백엔드를 배포하는 배포 모델을 사용하면 앱이 로컬에서 요청을 완벽하게 처리하므로 사용자 지연 시간을 최소화할 수 있습니다. 하지만 모든 데이터를 로컬에서 저장하고 액세스해야 하기 때문에 이 모델에는 복잡성이 추가됩니다. 모든 사용자 요청을 처리하려면 데이터를 모든 리전에서 완전히 복제해야 합니다.

분산된 멀티 배포 지연 시간

전역적으로 일관된 관리형 데이터베이스를 제공하는 Spanner는 3대륙 멀티 리전 옵션을 제공합니다. 이 경우 미국의 읽기-쓰기 복제본 이외에도 유럽 및 아시아에 읽기 복제본 2개가 있습니다. 이 옵션은 데이터에 대한 지연 시간이 짧은 읽기 액세스를 제공하여 미국, 유럽, 아시아에 있는 인스턴스를 컴퓨팅합니다. 미국을 대상으로 서비스 중일 경우 미국 내에서 복제가 제공되는 다중 리전 옵션도 선택할 수 있습니다.

Compute Engine에서 자체 데이터베이스 서비스를 실행하려면 직접 데이터를 복제해야 합니다. 데이터를 전역에서 동기화 상태로 일관되게 유지하는 것이 어려우므로 이 복제는 중요한 작업입니다. 데이터베이스가 비동기 쓰기를 통해 한 리전에만 기록되고 다른 리전은 데이터베이스의 읽기 전용 복제본을 호스팅하는 경우 더 쉽게 관리할 수 있습니다.

여러 리전 간 데이터베이스 복제를 수행하는 것은 어렵기 때문에 Cassandra 복제용 Datastax와 같은 이 분야의 경험이 풍부한 강력한 파트너를 참여시키는 것이 좋습니다.

여러 가지 동시 앱

앱의 특성에 따라 이전 방식을 변형하여 사용하면 지속적인 데이터 복제 필요성을 줄이면서 사용자 지연 시간을 짧게 유지할 수 있습니다. 다음 이미지와 같이 프런트엔드와 백엔드로 구성된 동시 앱이 여러 개 있으며 사용자는 올바른 앱으로 연결됩니다. 사이트 간에는 소수의 데이터만 공유됩니다.

동시 앱 지연 시간

예를 들어 소매업체를 운영하는 경우 다른 국가 도메인을 통해 다른 리전에서 사용자에게 서비스를 제공하고 해당하는 모든 리전에서 동시 사이트를 실행하여 필요한 경우에만 제품과 사용자 데이터를 동기화할 수 있습니다. 로컬 사이트는 로컬 재고 가용성을 유지하고 사용자는 국가 도메인을 선택하여 로컬에서 호스팅되는 사이트에 연결합니다. 사용자가 다른 국가 도메인을 방문하면 올바른 도메인으로 리디렉션됩니다.

또 다른 예로 실시간 게임을 들 수 있습니다. 사용자는 자신의 위치와 가까우면서 데이터를 서로 공유하지 않는 게임룸이나 세계를 선택하는 글로벌 로비 서비스만 사용할 수도 있습니다.

세 번째 예는 다른 리전에서 서비스로서의 소프트웨어(SaaS)를 제공하는 것으로 이 경우 데이터 위치는 사용자 위치나 사용자의 선택을 바탕으로 계정 생성 시 선택됩니다. 사용자는 로그인한 후 위치별 하위 도메인으로 리디렉션되고 서비스를 지역적으로 사용하게 됩니다.

사용자 및 리전 간 지연 시간 최적화

배포 모델에 상관없이 최적화 방법을 결합하여 최종 사용자에게 표시되는 지연 시간을 줄일 수 있습니다. 이 방법 중 일부는Google Cloud 기능이며 다른 방법을 사용하려면 앱을 변경해야 합니다.

프리미엄 등급 네트워킹 사용

Google은 프리미엄(기본) 및 표준 네트워크 서비스 등급을 제공합니다. 표준 등급 트래픽은 Google Cloud리전에서 중계 접속 ISP를 통해 제공되는 반면 프리미엄 등급은 Google의 글로벌 비공개 네트워크를 통해 트래픽을 제공하므로 지연 시간이 짧습니다. 프리미엄 등급 네트워킹은 사용자 지연 시간을 줄이며 서비스 경로에서 앱의 모든 부분에 사용되어야 합니다. Google 글로벌 부하 분산 제품을 사용하려면 프리미엄 등급 네트워킹도 필요합니다.

Cloud Load Balancing 및 Cloud CDN 사용

HTTP(S) 부하 분산, TCP, SSL 프록시 부하 분산과 같은 Cloud Load Balancing을 사용하면 사용 가능한 용량을 갖춘 백엔드가 있는 가장 가까운 지역으로 사용자를 자동으로 리디렉션합니다.

앱이 단일 지역에만 있는 경우에도 TCP 및 SSL 세션이 네트워크 에지에서 종료되므로 Cloud Load Balancing을 사용하면 사용자 지연 시간이 줄어듭니다. HTTP/2 및 빠른 UDP 인터넷 연결(QUIC)을 통해 사용자 트래픽을 손쉽게 종료할 수 있습니다. 또한 Cloud CDN을 HTTP(S) 부하 분산과 통합하여 네트워크 에지에서 정적 애셋을 직접 제공하면 사용자 지연 시간을 더욱 줄일 수 있습니다.

로컬에서 캐시

프런트엔드 위치가 백엔드 위치와 다른 경우 가능하면 백엔드 서비스의 응답을 캐시해야 합니다. 프런트엔드 및 백엔드가 동일한 리전에 있으면 앱 지연 시간이 줄어듭니다. 시간을 많이 소모하는 쿼리도 줄어들기 때문입니다. Memorystore for Redis는 사용자가 사용할 수 있는 완전 관리형 인메모리 데이터 스토어입니다.

앱 클라이언트 또는 웹 프런트엔드 최적화

클라이언트 측의 기술(예: 모바일 앱 또는 웹 프런트엔드)을 사용하여 사용자 지연 시간을 최적화할 수 있습니다. 예를 들어 일부 애셋을 미리 로드하거나 앱 내에서 데이터를 캐시합니다.

가능할 때마다 요청 수를 줄이거나 정보를 동시에 검색하여 앱이 정보를 가져오는 방식을 최적화할 수도 있습니다.

사용자 지연 시간 측정

지연 시간 요구사항의 기준을 설정한 후 사용자층을 확인하여 Google Cloud 리소스의 최적 배치를 결정합니다. 새로운 앱인지 또는 기존 앱인지에 따라 다양한 전략을 사용할 수 있습니다.

다음 전략을 사용하여 앱을 제공하는 동안 액세스하는 파트너의 지연 시간을 측정하거나 Cloud VPN 또는 Dedicated Interconnect를 사용하여 Google Cloud 프로젝트와 상호 연결될 수 있는 온프레미스 네트워크의 지연 시간을 측정합니다.

새 워크로드의 지연 시간 예측

새 앱과 비슷한 사용자층이 있는 기존 앱이 없으면 예상 사용자층의 대략적인 위치 배포를 기준으로 다양한 Google Cloud 리전의 지연 시간을 예측합니다.

100km를 이동할 때마다 왕복 지연 시간 1ms가 예측됩니다. 네트워크는 소스에서 대상까지 적합한 경로를 따르지 않으므로 실제 거리는 일반적으로 지도에서 측정한 거리의 약 1.5~2배 정도로 추정할 수 있습니다. 물론 인구 밀도가 상대적으로 낮은 일부 리전에서는 네트워크가 덜 적합한 경로를 따를 수 있습니다. ISP 네트워크 내의 활성 장비를 통해 추가된 지연 시간은 일반적으로 리전 간 거리를 살펴볼 때 무시할 수 있는 정도입니다.

이 수치는 네트워크 맵에 나와 있는 전 세계의 Compute Engine 리전뿐 아니라 에지 POP 및 Cloud CDN 노드에 대한 지연 시간을 예측하는 데 도움이 됩니다.

기존 사용자의 지연 시간 측정

비슷한 사용자층을 가진 기존 앱이 이미 있으면 몇 가지 도구를 사용하여 지연 시간을 더 정확히 예측할 수 있습니다.

대표 사용자: 지리적 분포의 단면을 보여주며 사용자 또는 해당 국가의 직원과 일할 의사가 있는 사용자나 파트너가 있으면 다양한 Google Cloud 리전의 지연 시간을 측정하도록 요청합니다. Google Cloud 핑과 같은 서드 파티 웹사이트에서 측정에 대한 도움을 얻을 수 있습니다.
액세스 로그:Google Cloud외부에서 호스팅되는 활성 앱이 있는 경우, 액세스 로그의 데이터를 사용하여 사용자에 대한 대략적인 단면을 확인할 수 있습니다. 로그에서 국가 또는 도시 정보를 확인할 수 있으며 로그를 사용하여 지연 시간도 예측할 수 있습니다.
IP 주소: 사용자의 IP 주소에 액세스할 수 있는 경우 다양한 Google Cloud리전의 지연 시간 및 연결 가능성을 테스트하는 스크립트를 작성합니다. 방화벽이 프로브를 차단하는 경우 마지막 IP 옥텟을 무작위화하여 앱과 지연 시간이 비슷한 다른 기기에서 응답을 가져옵니다.
Google Cloud의 지연 시간 정보: Google Cloud에 기존 앱이 있는 경우 여러 가지 방법으로 지연 시간 정보를 수집할 수 있습니다.
- 사용자 정의 요청 헤더**: 부하 분산기와 클라이언트 간의 예상 RTT뿐만 아니라 고객의 국가, 하위 리전, 도시 정보 헤더도 활성화합니다.
- HTTP(S) 부하 분산을 위한 Cloud Monitoring 측정항목: 프런트엔드 RTT와 백엔드 지연 시간을 포함합니다.
- VPC 흐름 로그: 제공된 측정항목의 일부로 연결의 양단 간 TCP RTT를 가져옵니다.

글로벌 연결

지연 시간을 예측할 때는 Google 글로벌 네트워크의 토폴로지에 유의하세요.

POP: 사용자 트래픽이 네트워크에 진입하는 위치입니다.
Cloud CDN 노드: 트래픽이 캐시되는 위치입니다.
리전: 리소스를 찾을 수 있는 위치입니다.
연결: POP 및 리전 간 연결입니다.

Google이 PeeringDB에서 다른 ISP와 상호 연결하는 위치 목록을 찾습니다.

배포할 리전을 결정할 때 리전 간 토폴로지를 고려해야 합니다. 예를 들어 단일 리전에 글로벌 사용자층이 있는 앱을 배포하려면 일반적으로 미국이 다른 리전과 가장 많이 연결되어 있으므로 미국 리전에서 이 앱을 호스팅하는 것이 가장 좋습니다. 여러 대륙이 직접 연결되어 있긴 하지만 유럽과 아시아의 경우 연결이 누락되는 경우가 있으므로 유럽과 아시아 간 트래픽은 미국을 통과해야 합니다.

여러 리전에서 앱이 호스팅되는 상황에서 데이터를 동기화해야 하는 경우 해당 리전 간의 지연 시간을 고려해야 합니다. 이 지연 시간은 시간이 지나면서 변경될 수 있지만 일반적으로 안정적입니다. 모든 가능한 리전에서 테스트 인스턴스를 가져와서 지연 시간을 직접 측정하거나 타사 웹사이트를 사용하여 리전 간 현재 지연 시간에 대해 알아볼 수 있습니다.

하나로 결합

지연 시간 요구사항, 가능한 배포 모델, 사용자층의 지리적 분포를 살펴보면서 이러한 요소가 특정 리전의 지연 시간에 어떤 영향을 미치는지에 대해 이해했습니다. 이제는 앱을 실행할 리전을 결정해야 합니다.

다양한 요소를 비교할 수 있는 적합한 방법은 없지만 다음과 같은 단계별 방법론이 결정에 도움이 될 수 있습니다.

가격 또는 코로케이션과 같이 특정 리전에 대한 배포를 방해하는 지연 시간 외 관련 요소가 있는지 확인합니다. 리전 목록에서 이 요소를 삭제합니다.
지연 시간 요구사항 및 앱의 일반 아키텍처를 기반으로 배포 모델을 선택합니다. 대부분의 모바일 및 지연 시간이 중요하지 않은 앱의 경우에는 Cloud CDN이 전달하는 캐시 가능한 콘텐츠 및 에지에서의 SSL 종료를 사용하는 단일 리전 배포가 가장 적합할 수 있습니다.
배포 모델에 따라 사용자층의 지리적 분포와 지연 시간 측정을 토대로 리전을 선택합니다.
- 단일 리전 배포의 경우 다음과 같이 합니다.
  - 지연 시간이 짧은 회사 건물에 대한 액세스가 필요한 경우 이 위치와 가장 가까운 리전에 배포합니다.
  - 사용자가 한 국가 또는 리전에 주로 있는 경우 대표 사용자와 가장 가까운 리전에 배포합니다.
  - 글로벌 사용자층의 경우 미국의 한 리전에 배포합니다.
- 멀티 리전 배포인 경우 다음과 같이 합니다.
  - 지리적 분포 및 앱의 지연 시간 요구사항에 따라 사용자와 가까운 리전을 선택합니다. 앱에 따라 특정 중앙값 지연 시간을 최적화하거나 사용자의 95-99%에게 특정 목표 지연 시간이 제공되도록 합니다. 특정 지리적 위치에 있는 사용자는 인프라 제한으로 인해 지연 시간에 더 관대한 경우가 많습니다.
사용자 지연 시간이 여러 리전에서 비슷한 경우에는 가격이 결정 요소가 될 수 있습니다.

Compute Engine 리전을 선택할 때 지연 시간은 고려해야 할 매우 중요한 요소 중 하나입니다. 지연 시간 요구사항을 평가하고 측정하여 양질의 사용자 환경을 제공하고 사용자층의 지리적 분포가 변경되면 프로세스를 반복합니다.

다음 단계

Compute Engine 리전 및 영역(zone) 검토
부하 분산을 통한 애플리케이션 지연 시간 최적화에 대해 알아보기
데이터 센터 전문가를 위한Google Cloud 가이드 읽어보기
Cloud Performance Atlas 동영상 시리즈 시청하기
사용자 지연 시간을 최적화하는 방법에 대한 자세한 내용은 고성능 브라우저 네트워킹 사이트 참조
Google Cloud에 대한 참조 아키텍처, 다이어그램, 튜토리얼, 권장사항을 살펴봅니다. Cloud 아키텍처 센터 살펴보기