리전 및 영역

Compute Engine 리소스는 전 세계 여러 곳에서 호스팅됩니다. 이러한 위치는 리전과 영역으로 구성됩니다. 리전은 리소스를 호스팅할 수 있는 특정한 지리적 위치로, 영역이 3개 이상 있습니다. 예를 들어 us-west1 리전은 us-west1-a, us-west1-b, us-west1-c 등 3개의 영역이 있는 미국 서해안의 리전을 나타냅니다.

가상 머신 인스턴스 또는 영역 영구 디스크와 같이 영역에 있는 리소스를 영역 리소스라고 합니다. 고정 외부 IP 주소와 같은 기타 리소스는 리전 리소스입니다. 리전 리소스는 영역에 관계없이 해당 리전의 모든 리소스를 사용할 수 있지만, 영역 리소스는 같은 영역에 있는 리소스만 사용할 수 있습니다.

예를 들어 영역 영구 디스크를 인스턴스에 연결하려면 두 리소스가 모두 동일한 영역에 있어야 합니다. 마찬가지로 고정 IP 주소를 인스턴스에 할당하려면 인스턴스가 고정 IP 주소와 동일한 리전에 있어야 합니다.

한 리전의 서로 다른 영역에 리소스를 배치하면 대부분의 실제 인프라 및 인프라 소프트웨어 서비스 장애 유형으로부터 리소스를 격리하는 효과가 있습니다. 또한 리소스를 여러 리전에 배치하면 더욱 높은 수준의 장애 독립성을 얻을 수 있습니다. 이를 통해 리소스가 여러 장애 도메인에 분산된 강력한 시스템을 설계할 수 있습니다.

특정 리소스만 리전 또는 영역별 리소스에 해당합니다. 이미지를 비롯한 기타 리소스는 위치에 상관없이 다른 어떠한 리소스도 사용할 수 있는 전역 리소스입니다. 전역, 리전 및 영역 Compute Engine 리소스에 대한 자세한 내용은 전역, 리전 및 영역 리소스를 참조하세요.

영역 및 클러스터

Compute Engine은 영역과 영역이 호스팅되는 실제 클러스터 사이에서 추상화 계층을 구현합니다. 클러스터는 데이터 센터에 있는 고유한 실제 인프라를 나타냅니다. 각 클러스터에는 독립적인 소프트웨어 인프라, 전원, 냉각장치, 네트워크 및 보안 인프라가 있으며 대규모 Compute 및 스토리지 리소스 풀이 포함되어 있습니다.

각 영역은 하나 또는 여러 개의 클러스터에 호스팅되며 Compute Engine은 조직별로 영역을 클러스터에 독립적으로 매핑합니다. 예를 들어 us-central1-a 영역이 다른 조직의 us-central1-a 영역과 동일한 클러스터에 매핑되지 않을 수 있습니다.

클러스터와 영역을 분리하면 사용자와 Compute Engine은 다음과 같은 이점을 기대할 수 있습니다.

  • Compute Engine에서 한 리전에 있는 클러스터 사이의 리소스 균형을 유지할 수 있습니다.
  • 시간이 지나면서 Compute Engine에서 더 많은 클러스터를 추가하여 리전을 계속 늘리더라도 선택 가능한 영역 목록을 관리 가능한 상태로 계속 유지할 수 있습니다.

대부분의 조직에서 Compute Engine은 조직의 모든 프로젝트가 일관된 영역-클러스터 매핑을 갖도록 합니다. VPC 네트워크 피어링 또는 비공개 서비스 액세스를 사용하여 다른 조직과 네트워크 또는 서비스를 공유하는 프로젝트가 있는 조직의 경우 Compute Engine은 피어링된 모든 조직의 영역-클러스터 매핑이 일관되게 하려고 합니다. 예를 들어 대규모 SaaS 제공업체의 경우 Compute Engine은 피어링된 모든 조직에 일관된 매핑을 제공하지 못할 수도 있습니다. 이러한 경우 Compute Engine은 피어링된 프로젝트의 영역-클러스터 매핑이 일관되도록 합니다.

리전 및 영역 선택

리소스를 호스팅하여 데이터가 저장 및 사용되는 위치를 제어하게 될 리전 또는 영역을 선택합니다. 리전과 영역을 선택하는 것이 중요한 이유는 다음과 같습니다.

오류 처리
리소스를 여러 영역 및 리전에 분산하여 중단에 대비합니다. Google은 영역을 서로 독립적으로 설계합니다. 즉, 영역은 일반적으로 다른 영역과 분리된 전력, 냉각, 네트워킹 및 제어 플레인을 보유하므로 대부분의 단일 장애 이벤트는 단일 영역에만 영향을 미칩니다. 따라서 한 영역을 사용할 수 없게 되면 같은 리전의 다른 영역으로 트래픽을 전송하여 서비스를 계속 실행할 수 있습니다. 마찬가지로 한 리전에서 장애가 발생하면 다른 리전에서 백업 서비스가 계속 실행되도록 해야 합니다. 리소스 분산 및 강력한 시스템 설계에 대한 자세한 내용은 강력한 시스템 설계를 참조하세요.
네트워크 지연 시간 감소
네트워크 지연 시간을 줄이기 위해 서비스 지점과 가까운 리전이나 영역을 선택하려 할 수 있습니다. 예를 들어 미국 동부 해안에 대부분의 고객이 있는 경우 이 영역과 가까운 기본 리전 및 영역을 선택하고 가까운 백업 리전 및 영역을 선택할 수 있습니다.

리전 또는 영역 식별

Compute Engine의 각 리전에는 많은 영역이 포함되어 있습니다. 각 영역 이름은 각 영역을 자세히 설명하는 두 부분으로 구성됩니다. 영역 이름의 첫 번째 부분은 리전이고, 이름의 두 번째 부분은 리전 내 해당 영역을 설명합니다.

  • 리전

    리전은 영역의 집합입니다. 영역에서 같은 리전의 다른 영역으로 고대역폭, 낮은 지연 시간으로 네트워크 연결이 가능합니다. 고가용성을 제공하는 내결함성 애플리케이션을 배포하기 위해 Google은 다중 영역 및 다중 리전에 애플리케이션을 배포할 것을 권장합니다. 이렇게 하면 단일 영역이나 리전을 포함하는 경우에도 예기치 않은 구성 요소 장애를 방지하는 데 도움이 됩니다.

    사용자 시나리오에 적합한 리전을 선택합니다. 예를 들어 미국에만 고객이 있거나 데이터가 미국에 있어야 하는 등 특정 요구 사항이 있는 경우 리소스를 us-central1 리전이나 us-east1 리전 내의 영역에 저장하는 것이 좋습니다.

  • 영역

    영역은 리전 내에 있는 독립된 위치입니다. 영역의 정규화된 이름은 <region>-<zone>으로 구성됩니다. 예를 들어 us-central1 리전 내 a 영역의 정규화된 이름은 us-central1-a입니다.

    리소스를 배포하고자 하는 범위에 따라, 여러 리전의 여러 영역에 인스턴스를 만들어 중복성을 확보합니다.

사용 가능한 리전 및 영역

정렬 가능한 다음 표에서 다양한 옵션을 선택하면 리소스를 사용할 수 있는 위치를 확인할 수 있습니다. 예를 들어 위치 선택 드롭다운 메뉴에서 Europe을 선택하고 머신 유형 선택 드롭다운 메뉴에서 M2를 선택하면 M2 머신을 사용할 수 있는 유럽 내 영역의 목록을 볼 수 있습니다.

각 영역은 Ivy Bridge, Sandy Bridge, Haswell, Broadwell, Skylake 또는 Cascade Lake 플랫폼과 AMD EPYC Rome 플랫폼의 조합을 지원합니다. 영역에 인스턴스를 만들면 인스턴스는 이 영역에서 지원되는 기본 프로세서를 사용합니다. 예를 들어 us-central1-a 영역에서 인스턴스를 생성하는 경우, 다른 옵션을 지정하지 않는 한 인스턴스는 기본적으로 Haswell 프로세서를 사용합니다.

또는 원하는 CPU 플랫폼을 선택할 수 있습니다. 자세한 내용은 VM 인스턴스에 최소 CPU 플랫폼 지정을 참조하세요.

영역 위치 머신 유형 CPU 리소스
asia-east1-a 아시아 태평양 타이완 창후아 현 E2, N2, N2D, N1, M1, C2 Ivy Bridge, Broadwell, Skylake, Cascade Lake, AMD EPYC Rome GPU
asia-east1-b 아시아 태평양 타이완 창후아 현 E2, N2, N2D, N1, M1, C2 Ivy Bridge, Broadwell, Skylake, Cascade Lake, AMD EPYC Rome GPU
asia-east1-c 아시아 태평양 타이완 창후아 현 E2, N2, N2D, N1, M1, C2 Ivy Bridge, Broadwell, Skylake, Cascade Lake, AMD EPYC Rome GPU
asia-east2-a
asia-east2-b
asia-east2-c
아시아 태평양 홍콩 E2, N2, N1 Broadwell, Skylake, Cascade Lake
asia-northeast1-a 아시아 태평양 일본 도쿄 E2, N2, N1, M1, C2 Broadwell, Skylake, Cascade Lake GPU
asia-northeast1-b 아시아 태평양 일본 도쿄 E2, N2, N1 Broadwell, Skylake, Cascade Lake
asia-northeast1-c 아시아 태평양 일본 도쿄 E2, N2, N1, M1, C2 Broadwell, Skylake, Cascade Lake GPU
asia-northeast2-a
asia-northeast2-b
asia-northeast2-c
아시아 태평양 일본 오사카 E2, N1 Skylake
asia-northeast3-a
asia-northeast3-b
asia-northeast3-c
아시아 태평양 대한민국 서울 E2, N1, C2 Skylake
asia-south1-a 아시아 태평양 인도 뭄바이 E2, N1, M2, M1, C2 Broadwell, Skylake, Cascade Lake GPU
asia-south1-b 아시아 태평양 인도 뭄바이 E2, N1, M2, M1 Broadwell, Skylake GPU
asia-south1-c 아시아 태평양 인도 뭄바이 E2, N1, M1 Broadwell, Skylake
asia-southeast1-a 아시아 태평양 싱가포르 주롱웨스트 E2, N2, N2D, N1, M1, C2 Broadwell, Skylake, Cascade Lake, AMD EPYC Rome
asia-southeast1-b 아시아 태평양 싱가포르 주롱웨스트 E2, N2, N2D, N1, M1, C2 Broadwell, Skylake, Cascade Lake, AMD EPYC Rome GPU
asia-southeast1-c 아시아 태평양 싱가포르 주롱웨스트 E2, N2, N2D, N1, M1, C2 Broadwell, Skylake, Cascade Lake, AMD EPYC Rome GPU
asia-southeast2-a
asia-southeast2-b
asia-southeast2-c
아시아 태평양 인도네시아 자카르타 E2, N1 Skylake
australia-southeast1-a 아시아 태평양 오스트레일리아 시드니 E2, N2, N1, C2 Broadwell, Skylake, Cascade Lake
australia-southeast1-b 아시아 태평양 오스트레일리아 시드니 E2, N2, N1, C2, M1 Broadwell, Skylake, Cascade Lake GPU
australia-southeast1-c 아시아 태평양 오스트레일리아 시드니 E2, N2, N1, M1 Broadwell, Skylake, Cascade Lake GPU
europe-north1-a 유럽 핀란드 하미나 E2, N2, N1, C2, M1 Broadwell, Skylake, Cascade Lake
europe-north1-b 유럽 핀란드 하미나 E2, N1, C2 Broadwell, Skylake
europe-north1-c 유럽 핀란드 하미나 E2, N1, C2, M1 Broadwell, Skylake
europe-west1-b 유럽 벨기에 셍기슬랑 E2, N2, N2D, N1, M1, C2 Sandy Bridge, Haswell, Broadwell, Skylake, Cascade Lake, AMD EPYC Rome GPU
europe-west1-c 유럽 벨기에 셍기슬랑 E2, N2, N2D, N1, C2 Ivy Bridge, Haswell, Broadwell, Skylake, Cascade Lake, AMD EPYC Rome
europe-west1-d 유럽 벨기에 셍기슬랑 E2, N2, N2D, N1, M1, C2 Haswell, Broadwell, Skylake, Cascade Lake, AMD EPYC Rome GPU
europe-west2-a 유럽 잉글랜드 런던 E2, N2, N2D, N1, C2 Broadwell, Skylake, Cascade Lake, AMD EPYC Rome GPU
europe-west2-b 유럽 잉글랜드 런던 E2, N2, N2D, N1, M1, C2 Broadwell, Skylake, Cascade Lake, AMD EPYC Rome GPU
europe-west2-c 유럽 잉글랜드 런던 E2, N2, N1, M1, C2 Broadwell, Skylake, Cascade Lake
europe-west3-a 유럽 독일 프랑크푸르트 E2, N2, N1, M1, M2, C2 Broadwell, Skylake, Cascade Lake
europe-west3-b 유럽 독일 프랑크푸르트 E2, N2, N1, M1, M2, C2 Broadwell, Skylake, Cascade Lake GPU
europe-west3-c 유럽 독일 프랑크푸르트 E2, N1, M1 Broadwell, Skylake
europe-west4-a 유럽 네덜란드 엠스하벤 E2, N2, N2D, N1, C2 Broadwell, Skylake, Cascade Lake, AMD EPYC Rome GPU
europe-west4-b 유럽 네덜란드 엠스하벤 E2, N2, N2D, N1, M2, M1, C2 Broadwell, Skylake, Cascade Lake, AMD EPYC Rome GPU
europe-west4-c 유럽 네덜란드 엠스하벤 E2, N2, N2D, N1, M2, M1, C2 Broadwell, Skylake, Cascade Lake, AMD EPYC Rome GPU
europe-west6-a
europe-west6-b
europe-west6-c
유럽 스위스 취리히 E2, N1 Skylake
northamerica-northeast1-a 북미 퀘벡 몬트리올 E2, N2, N1 Broadwell, Skylake, Cascade Lake GPU
northamerica-northeast1-b 북미 퀘벡 몬트리올 E2, N2, N1, M1 Broadwell, Skylake, Cascade Lake GPU
northamerica-northeast1-c 북미 퀘벡 몬트리올 E2, N2, N1, M1 Broadwell, Skylake, Cascade Lake GPU
southamerica-east1-a 남미 브라질 상파울루 오사스쿠 E2, N2, N1 Broadwell, Skylake, Cascade Lake
southamerica-east1-b 남미 브라질 상파울루 오사스쿠 E2, N2, N1, M1, C2 Broadwell, Skylake, Cascade Lake
southamerica-east1-c 남미 브라질 상파울루 오사스쿠 E2, N2, N1, M1, C2 Broadwell, Skylake, Cascade Lake GPU
us-central1-a 북미 아이오와 카운슬블러프즈 E2, N2, N2D, N1, M1, C2 Sandy Bridge, Haswell, Broadwell, Skylake, Cascade Lake, AMD EPYC Rome GPU
us-central1-b 북미 아이오와 카운슬블러프즈 E2, N2, N1, M2, M1, C2 Haswell, Broadwell, Skylake, Cascade Lake GPU
us-central1-c 북미 아이오와 카운슬블러프즈 E2, N2, N2D, N1, M2, M1, C2 Haswell, Broadwell, Skylake, Cascade Lake, AMD EPYC Rome GPU
us-central1-f 북미 아이오와 카운슬블러프즈 E2, N2, N2D, N1, C2 Ivy Bridge, Haswell, Broadwell, Skylake, Cascade Lake, AMD EPYC Rome GPU
us-east1-b 북미 사우스캐롤라이나 몽크스 코너 E2, N2, N2D, N1, M1, C2 Haswell, Broadwell, Skylake, Cascade Lake, AMD EPYC Rome GPU
us-east1-c 북미 사우스캐롤라이나 몽크스 코너 E2, N2, N2D, N1, M1, C2 Haswell, Broadwell, Skylake, Cascade Lake, AMD EPYC Rome GPU
us-east1-d 북미 사우스캐롤라이나 몽크스 코너 E2, N2, N2D, N1, M1, C2 Haswell, Broadwell, Skylake, Cascade Lake, AMD EPYC Rome GPU
us-east4-a 북미 버지니아 애쉬번 E2, N2, N2D, N1, M2, M1, C2 Broadwell, Skylake, Cascade Lake, AMD EPYC Rome GPU
us-east4-b 북미 버지니아 애쉬번 E2, N2, N2D, N1, M2, M1, C2 Broadwell, Skylake, Cascade Lake, AMD EPYC Rome GPU
us-east4-c 북미 버지니아 애쉬번 E2, N2, N1, M1, C2 Broadwell, Skylake, Cascade Lake GPU
us-west1-a 북미 오리건 댈러스 E2, N2, N1, M1, C2 Broadwell, Skylake, Cascade Lake GPU
us-west1-b 북미 오리건 댈러스 E2, N2, N2D, N1, M1, C2 Broadwell, Skylake, Cascade Lake, AMD EPYC Rome GPU
us-west1-c 북미 오리건 댈러스 E2, N2, N2D, N1, C2 Broadwell, Skylake, Cascade Lake, AMD EPYC Rome
us-west2-a 북미 캘리포니아 로스앤젤레스 E2, N1, M2, C2 Broadwell, Skylake, Cascade Lake
us-west2-b 북미 캘리포니아 로스앤젤레스 E2, N1, M1 Broadwell, Skylake GPU
us-west2-c 북미 캘리포니아 로스앤젤레스 E2, N1, M2, M1, C2 Broadwell, Skylake, Cascade Lake GPU
us-west3-a
us-west3-b
us-west3-c
북미 유타 솔트레이크시티 E2, N1 Skylake
us-west4-a
us-west4-b
us-west4-c
북미 네바다 라스베이거스 E2, N2, N1 Skylake, Cascade Lake

발표된 리전

Google은 다음과 같은 리전을 신규로 계속 확장할 예정입니다.

  • 폴란드 바르샤바
  • 오스트레일리아 멜버른
  • 캐나다 토론토
  • 인도 델리
  • 카타르 도하

투명한 유지보수

Google은 최신 소프트웨어로 시스템을 패치하고, 정기적인 테스트 및 예방 유지보수를 수행하고, Google 인프라가 목표한 것만큼 빠르고 효율적이도록 유지함으로써 인프라를 정기적으로 유지 관리하고 있습니다.

기본적으로 모든 인스턴스는 이러한 유지보수 이벤트가 애플리케이션 및 작업 부하에 투명하게 확인되도록 구성됩니다. Google은 데이터 센터 혁신, 운영 모범 사례 및 실시간 이전 기술을 조합하여, 수행 중인 유지보수로 인해 실행 중인 가상 머신 인스턴스가 영향을 받지 않도록 합니다. 인스턴스는 사용자 개입 없이 같은 영역 내에서 계속 실행됩니다.

기본적으로 모든 가상 머신은 라이브 마이그레이션되도록 설정되어 있지만 가상 머신이 중지되었다가 재부팅되도록 설정할 수도 있습니다. 두 옵션은 다음과 같은 측면에서 다릅니다.

  • 실시간 마이그레이션

    Compute Engine이 실행 중인 인스턴스를 자동으로 마이그레이션합니다. 마이그레이션 프로세스는 게스트 성능에 어느 정도 영향을 미치긴 하지만 인스턴스는 마이그레이션 프로세스 동안 가동 상태를 유지합니다. 게스트 성능에 미치는 정확한 영향과 지속 기간은 다양한 요인에 따라 다르지만 대부분의 애플리케이션과 작업 부하에서는 인식되지 않습니다. 자세한 내용은 라이브 마이그레이션을 참조하세요.

  • 중지 및 재부팅

    Compute Engine이 인스턴스에 종료하도록 자동으로 신호를 보내고, 완전히 종료될 때까지 잠시 동안 대기한 후 유지보수 이벤트 이후에 인스턴스를 다시 시작합니다.

인스턴스에 위 옵션을 설정하는 방법에 대한 자세한 내용은 인스턴스 예약 옵션 설정을 참조하세요.

영역 해제

기존 영역을 해제하지 않고도 전체 인프라를 리프레시(전력, 냉각장치, 네트워크 패브릭, 서버 등)할 수 있습니다. 인프라 리프레시는 드물게 진행되며 영역은 일반적으로 리프레시가 있기까지 3~5년 동안 실행됩니다. 이러한 리프레시는 고객에게 투명하게 진행되어야 합니다.

영역을 해제해야 하는 경우 Compute Engine은 가상 머신 인스턴스 및 작업 부하를 이동할 시간을 충분히 확보할 수 있도록 영역이 가동 중단될 것임을 사용자에게 미리 알립니다.

할당량

정적 IP, 이미지, 방화벽 규칙 및 VPC 네트워크와 같은 특정 리소스에는 프로젝트 전체 할당량 한도 및 리전별 할당량 한도가 지정되어 있습니다. 이러한 리소스를 만들면 총 프로젝트 전체 할당량 또는 리전별 할당량에 반영됩니다(해당되는 경우). 영향을 받는 할당량 한도를 초과하면 해당 프로젝트나 리전에서 동일한 유형의 리소스를 더 추가할 수 없게 됩니다.

프로젝트에 적용되는 포괄적인 할당량 목록을 보려면 Google Cloud Console에서 할당량 페이지를 참조하세요.

예를 들어 전역 대상 풀 할당량이 50이고 example-region-1에서 25개의 대상 풀을 만들고 example-region-2에서 25개의 대상 풀을 만들면 프로젝트 전체 할당량에 도달하게 되므로 여유 공간을 확보할 때까지 프로젝트 내의 어떤 리전에서도 대상 풀을 추가로 만들 수 없게 됩니다. 마찬가지로 리전별로 예약된 IP 주소 수가 7개로 할당된 경우 단일 리전에서 최대 7개의 IP 주소만 예약할 수 있습니다. 이 한도에 도달하면 새 리전에서 IP 주소를 예약하거나 일부 IP 주소를 해제해야 합니다.

영역을 선택할 때는 다음 사항에 유의하세요.

  • 리전 내 통신과 리전 간 통신은 부과되는 요금이 다릅니다.

    일반적으로 리전 내 통신이 리전 간 통신보다 언제나 더 저렴하고 빠릅니다.

  • 여러 영역 간에 이중화를 갖추도록 중요한 시스템을 디자인합니다.

    특정 시점에 인스턴스에 예기치 않은 장애가 발생할 수 있습니다. 이러한 가능한 이벤트의 영향을 완화하려면 여러 영역 및 리전에 중요한 시스템을 복제해야 합니다.

    예를 들어 europe-west1-beurope-west1-c 영역에서 인스턴스를 호스팅할 경우 europe-west1-b에서 예기치 않은 장애가 발생하더라도 europe-west1-c 영역의 인스턴스를 계속 사용할 수 있습니다. 하지만 모든 인스턴스를 europe-west1-b에서 호스팅하면 europe-west1-b이 오프라인이 될 경우 인스턴스에 액세스할 수 없습니다. 또한 여러 리전에 리소스를 호스팅하는 것이 좋습니다. 예를 들어 드문 경우지만 europe-west1 리전에 장애가 발생해도 europe-west3 리전의 영역에서 백업 인스턴스를 호스팅할 수 있습니다. 가용성을 위해 시스템을 설계하는 방법에 대한 추가 팁은 강력한 시스템 설계를 참조하세요.

다음 단계