이 문서에서는 Google이 데이터 센터 내에서 내부의 물리적 하드웨어 클러스터에 공개 영역을 매핑하는 데 사용하는 방법인 영역 가상화에 대해 설명합니다. 영역 가상화를 사용하면 고객에게 영향을 미치지 않으면서 영역을 원활하게 확장하고 하드웨어를 업그레이드하고 물리적 인프라를 사용 중단할 수 있습니다. 에플리케이션이 여러 프로젝트에 분산되어 있어 Google에서 여러 물리적 인프라에 영역을 분산하는 방법을 알아보려면 이 주제를 읽어보세요.
Google Cloud 리소스는 전 세계 여러 리전에서 호스팅됩니다. 각 리전은 3개 또는 4개의 영역으로 구성됩니다. 영역은 상관 장애를 방지하도록 설계된 논리적 리소스 그룹입니다. 리전 내의 여러 영역에 리소스를 배치하면 애플리케이션에 영향을 주는 상관 장애 및 소프트웨어 인프라 장애 위험이 줄어듭니다. 리소스를 여러 리전에 배치하면 더 높은 수준의 장애 독립성을 얻을 수 있습니다.
Google Cloud 지리적 위치 목록은 리전 및 영역을 참조하세요. 복원력이 우수한 애플리케이션 빌드에 대한 자세한 내용은 재해 복구 계획에 대한 Google Cloud 솔루션 시리즈를 참조하세요.
클러스터
모든 Google Cloud 하드웨어는 클러스터로 구성됩니다. 클러스터는 건설, 전력, 냉각 인프라에서 지원되는 컴퓨팅, 네트워크, 스토리지 리소스 집합을 나타냅니다. 인프라 구성 요소는 일반적으로 단일 클러스터를 지원하므로 클러스터가 거의 종속 항목을 공유하지 않습니다.
그림 1: asia-east1 리전에 3개 영역이 있습니다. 각 영역에는 개별 리소스가 있는 고유 클러스터가 포함됩니다.
하지만 안정성과 다운스트림 중복성이 충분히 입증된 구성요소는 클러스터 간에 공유될 수 있습니다. 예를 들어 다중 클러스터는 매우 안정적이며 클러스터에서 이중화된 전력 시스템을 사용하기 때문에 일반적으로 전력망 변전소를 공유합니다. Google Cloud에서는 Google Cloud 서비스의 서비스수준계약(SLA) 및 서비스 수준 목표(SLO)를 지원하도록 물리적 인프라를 설계합니다.
영역-클러스터 매핑
프로젝트에서 리전을 처음 사용하는 경우 Google Cloud에서 해당 프로젝트의 영역 리소스의 기본 클러스터인 리전의 영역마다 고유한 클러스터를 선택합니다. 하지만 하드웨어 제약으로 인해 해당 영역에 추가 클러스터가 사용될 수 있습니다. 이러한 선택을 영역-클러스터 매핑이라고 부릅니다. 프로젝트별로 기본 영역-클러스터 매핑이 선택되므로 모든 고객이 동일한 기능과 성능을 경험하게 됩니다. 한 프로젝트 내에서는 논리적 영역과 물리적 클러스터 간의 매핑이 일관되지만 다른 프로젝트에는 프로젝트의 영역 리소스에 따라 완전히 다른 영역-클러스터 매핑이 있을 수 있습니다. 한 프로젝트에서 동일한 물리적 클러스터에 두 영역이 매핑되지 않습니다.
Virtual Private Cloud(VPC) 네트워크를 사용하여 프로젝트 간의 영역-클러스터 매핑을 조정할 수 있습니다. Google Cloud는 VPC 네트워크를 공유하는 모든 프로젝트에 동일한 영역-클러스터 맵을 할당하려고 시도합니다. 예측 가능하고 원자적인 애플리케이션 구성요소 장애를 위해서는 프로젝트 전반에 걸쳐서 일관적인 영역-클러스터 맵이 적합할 수 있습니다.
가상화 영역
리전이 확장되면 각 영역이 여러 클러스터에서 지원됩니다. Google은 공유 인프라 장애가 한 리전의 단일 영역에만 영향을 미치도록 건물 또는 냉각 인프라와 같은 공유 인프라가 포함된 클러스터를 논리적 영역으로 그룹화합니다.
그림 2 asia-east1의 세 영역 중 두 영역이 확장되었으며 이제 2개의 클러스터가 포함됩니다.
고객 워크로드는 가능한 한 가장 적은 수의 클러스터에서 유지보수됩니다. 일반적으로 영역 워크로드는 단일 클러스터 내에 포함됩니다. 그러나 영역-클러스터 매핑에 맵의 기본 클러스터에서 추가 용량 또는 특수 하드웨어를 사용할 수 없는 경우 추가 클러스터가 포함할 수 있습니다.
그림 3 두 프로젝트의 영역-클러스터 매핑 다이어그램을 표시합니다.
- 프로젝트 Fizz에는
asia-east1-a에 매핑된 클러스터가 2개 있습니다. 클러스터 z만 GPU 워크로드를 지원하고 클러스터 y만 TPU 워크로드를 지원하기 때문입니다. - 프로젝트 Fizz 및 프로젝트 Buzz에는
asia-east1-b에 매핑된 서로 다른 클러스터가 있습니다.
영역-클러스터 매핑은 거의 변경되지 않지만 용량 요구사항이 커지고 기본 하드웨어 제품이 발전함에 따라 변경사항이 발생합니다. 예를 들어 용량을 늘리기 위해 영역에 클러스터를 추가하고 사용이 중단되면 영역에서 클러스터를 삭제합니다. Google에서는 유지보수 이벤트 중에 가능한 경우 라이브 마이그레이션을 사용하여 다운타임을 제한하려고 합니다.
클러스터 중단 시 Google Cloud 상태 대시보드에서는 해당 클러스터와 연결된 논리 영역에서 서비스 중단이 발생한 것으로 보고하지만 여러 클러스터로 구성된 영역일 수 있기 때문에 모든 고객 리소스가 영향을 받는 것은 아닙니다. 따라서 단일 클러스터 중단으로 인한 영향을 받지 않는 고객도 있을 수 있습니다. 중단의 영향을 최소화하려면 멀티 영역 아키텍처를 채택하는 것이 좋습니다.
공유 네트워크 및 가상화 영역
Virtual Private Cloud(VPC) 네트워크는 한 프로젝트의 리소스 간에 연결을 제공하는 가상화된 네트워크입니다. 프로젝트 간 연결을 위해 여러 프로젝트에서 VPC 네트워크를 공유하거나 조직 간 연결을 위해 조직이 공유 VPC 네트워크를 피어링할 수 있습니다. 영역 가상화 매핑 알고리즘에서는 VPC 네트워크를 공유하는 모든 프로젝트에 동일한 영역-클러스터 맵을 할당하거나 VPC 피어링을 통해 VPC 네트워크를 확장하려고 시도합니다. 여러 프로젝트가 다른 Google Cloud 조직에 있는 경우에도 마찬가지입니다. 프로젝트 및 VPC 수가 증가하면 네트워크 복잡성이 커지므로 일관된 영역 매핑을 유지보수하기가 더 어려워져 일관성을 보장할 수 없게 됩니다.
다음 단계
- 전역, 리전 및 영역 리소스에 대해 자세히 알아보기
- 지역 및 영역 자세히 알아보기