GCP 공부 -1

Seunghyun Moon·2023년 4월 27일

GCP

gcp

목록 보기

1/15

회사에서 gcp 사용을 하게 돼 처음에 끄적이며 공부한 내용입니다. 미약하지만 조금이라도 도움이 됐으면 하는 마음에 공유합니다.

기본 인프라 구성

지역 및 영역

https://cloud.google.com/compute/docs/regions-zones

리전(Region)

리소스를 호스팅 하는 특정한 지리적 위치(영역의 집합)
3개 이상의 영역(Zone)으로 구성
여러 리전에 리소스를 구성하면 재해 복구 설계 가능(Disaster Recovery)
예) us-east1, asia-northeas3(서울)

영역(Zone)

하나 이상의 데이터 센터 구성
각 영역은 물리적으로 서로 떨어진 곳에 구성 됨
여러 영역에 리소스를 구성하면 높은 수준의 장애 독립성을 얻을 수 있음(High Availability)
예) asia-northeast3-a, asia-northeast3-b, asia-northeast3-c
논리적인 리소스 그룹입니다

접속 지점(PoP: Points of presence)

리전과 영역과는 별게로 접속 지점을 피어링하는 전 세계 네트워크를 운영
Cloud CDN 같은 캐시 서비스를 포함하여 전 세계 여러 edge PoPs에서 운영되고 있는 네트워크 서비스
- Edge Point of Presence
- Cloud CDN Point of Presence
- Media CDN Point of Presence
Google Cloud에 연결하기 위한 interconnect locations
Google Cloud 서비스에 연결하기 위한 network edge locations
고객 트래픽이 해당 대상에 가까워질 때까지 Google 네트워크 내에서 이동되어, 사용자들에게 더 나은 환경 및 보안 기능을 제공

gcp-disk-images
GCP의 핵심 리소스 중 일부는 전역적(Global)이지만 다른 리소스는 지역(Regional)이나 영역(Zone)에 따라 제한될 수 있습니다. 리전 리소스는 동일한 리전 내 어디에서나 사용할 수 있는 반면 영역 리소스는 동일한 영역 내에서 어디에서나 사용할 수 있지만 다른 리전간에는 사용할 수 없습니다.

예를 들어 동일한 영역 내에 있는 한 인스턴스에서 다른 인스턴스로 디스크를 연결할 수 있지만 서로 다른 영역 간에는 이 작업을 수행할 수 없습니다. 그러나 이미지와 스냅샷은 글로벌 리소스이므로 동일한 리전의 여러 영역에서 사용할 수 있습니다.

전역 / 지역 / 영역 리소스에 대하여 간략히 알아보면 다음과 같습니다.

https://cloud.google.com/compute/docs/regions-zones/global-regional-zonal-resources

집계 목록

기본적으로 리소스 목록 반환 요청은 특정 제어 영역으로 범위가 지정됩니다. 모든 영역 또는 리전의 리소스를 나열하려면 집계 목록 쿼리를 이행할 수 있습니다.

모든 지역의 모든 주소를 나열하려면 다음 URI에 요청을 합니다.
https://compute.googleapis.com/compute/v1/projects/<project_id>/aggregated/addresses
자세한 내용은 해당 리소스의 aggregateList 메서드를 참조하세요.

영역 가상화

Google이 데이터 센터 내에서 내부의 물리적 하드웨어 클러스터에 공개 영역을 매핑하는 데 사용하는 방법. 영역 가상화를 사용하면 고객에게 영향을 미치지 않으면서 영역을 원활하게 확장하고 하드웨어를 업그레이드하고 물리적 인프라를 사용 중단할 수 있습니다. 에플리케이션이 여러 프로젝트에 분산되어 있어 여러 물리적 인프라에 영역을 분산하는 방법

클러스터

모든 Google Cloud 하드웨어는 클러스터로 구성됩니다. 클러스터는 빌드, 전원, 냉각 인프라에서 지원하는 컴퓨팅, 네트워크, 스토리지 리소스를 나타냅니다. 인프라 구성 요소는 일반적으로 단일 클러스터를 지원하므로 다른 클러스터와 디펜던시가 없음.
asia-east1에는 3개의 영역과 3개의 클러스터가 있습니다.
하지만 안정성과 다운스트림 중복성이 충분히 입증된 구성요소는 클러스터 간에 공유될 수 있습니다. 예를 들어 다중 클러스터는 매우 안정적이며 클러스터에서 이중화된 전력 시스템을 사용하기 때문에 일반적으로 전력망 변전소를 공유합니다. Google Cloud에서는 Google Cloud 서비스의 서비스수준계약(SLA) 및 서비스 수준 목표(SLO)를 지원하도록 물리적 인프라를 설계합니다.

영역-클러스터 매핑

프로젝트에서 리전을 처음 사용하는 경우 리전의 영역마다 하나의 고유한 클러스터를 선택합니다. 이러한 선택을 영역-클러스터 매핑이라고 부릅니다. 프로젝트별로 기본 영역-클러스터 매핑이 선택되므로 모든 고객이 동일한 기능과 성능을 경험하게 됩니다. 한 프로젝트 내에서는 논리적 영역과 물리적 클러스터 간의 매핑이 일관되지만 다른 프로젝트에는 프로젝트의 영역 리소스에 따라 완전히 다른 영역-클러스터 매핑이 있을 수 있습니다. 한 프로젝트에서 동일한 물리적 클러스터에 두 영역이 매핑되지 않습니다.

Virtual Private Cloud(VPC) 네트워크를 사용하여 프로젝트 간의 영역-클러스터 매핑을 조정할 수 있습니다. Google Cloud는 VPC 네트워크를 공유하는 모든 프로젝트에 동일한 영역-클러스터 맵을 할당하려고 시도합니다. 프로젝트 간의 일관된 영역-클러스터 맵은 예측 가능한 원자적 애플리케이션 구성요소 장애에 적합합니다.

프로젝트 간 연결을 위해 여러 프로젝트에서 VPC 네트워크를 공유하거나 조직 간 연결을 위해 조직이 공유 VPC 네트워크를 피어링할 수 있습니다.

가상화 영역

리전이 확장되면 각 영역이 여러 클러스터에서 지원됩니다. Google은 공유 인프라 장애가 한 리전의 단일 영역에만 영향을 미치도록 건물 또는 냉각 인프라와 같은 공유 인프라가 포함된 클러스터를 논리적 영역으로 그룹화합니다.

asia-east1 영역 A 및 B는 각각 두 클러스터로 확장됩니다.
그림 2 asia-east1의 세 영역 중 두 영역이 확장되었으며 이제 2개의 클러스터가 포함됩니다.

고객 워크로드는 가능한 한 적은 수의 클러스터에서 유지보수됩니다. 일반적으로 영역 워크로드는 단일 클러스터에 포함됩니다. 그러나 영역-클러스터 매핑에 맵의 기본 클러스터에서 추가 용량 또는 특수 하드웨어를 사용할 수 없는 경우 추가 클러스터가 포함할 수 있습니다.

asia-east1 영역 A 및 B는 각각 두 클러스터로 확장됩니다.
그림 3 두 프로젝트의 영역-클러스터 매핑 다이어그램을 표시합니다.

프로젝트 Fizz에는 asia-east1-a에 매핑된 클러스터가 2개 있습니다. 클러스터 z만 GPU 워크로드를 지원하고 클러스터 y만 TPU 워크로드를 지원하기 때문입니다.
프로젝트 Fizz 및 프로젝트 Buzz에는 asia-east1-b에 매핑된 서로 다른 클러스터가 있습니다.

네트워크

gcp의 경우 traceroute 찍으면 언제나 하나의 홉만 찍힘. 네트웍 효율이 좋다.

vpc

모든 리전이 단일 VPC. 다른 리전이지만 서브넷과의 연결을 라우팅만 잡아주면 됨.

별도의 VPN이나 피어링이 필요하지 않음.

VPC 는 글로벌, Subnet은 지역 레벨로 구성 가능.

Anycast IP 사용한 글로벌 부하분산기.

한 리전에서 생성한 lb의 IP를 다른 리전에서 사용함. 글로벌 네트워크에 대한 백본을 가지고 있기 때문에.

shared vpc

하나의 vpc를 확장해서 사용함. 네트웍을 중앙에서 통제 가능.

다른 환경과 vpc 연결

VPN, Interconnect, Direct Peering

service perimeter

프로젝트 그룹별로 vm - 서비스, 서비스 - 서비스의 통신 규칙을 지정

네트워크 제품 포트폴리오

서브넷은 regional한 리소스
- AWS는 서브넷이 zonal
서로 다른 VPC 간은 통신이 되지 않는다. 격리된다는 뜻. 네트워크 단위임
vpc는 글로벌한 리소스. vs shared vpc?
vpc ↔ 다른 AWS 혹은 on-prem과의 연결
flexible 한 사설 ip 풀
cloud NAT
VPC내의 네트워크 플로우와 텔레메트리

shared vpc

한개 vpc에 여러개의 리전을 활용해 서브넷 구성 가능. 온프레미스 포함.
한개 리전의 vpn gateway를 온프렘과 연결하면 다른 리전의 서브넷과 따로 라우팅 설정 하지 않아도 됨.

한 조직의 호스트 프로젝트에 속한 VPC를 다른 프로젝트(서비스)에서 공유(허브)
서비스 프로젝트에 호스트 프로젝트의 네트워크, 보안 설정 적용 가능(스포크)
보안관리자와 서비스 오너가 다른 부분을 반영. 운영 주체를 다르게 해서 운영 가능.
온프렘과의 연결을 호스트 프로젝트와 하고 서비스 프로젝트는 연결 내용과 설정을 상속받아 사용함
호스트 프로젝트를 dev / ops 각각 분리해 운영하는 방법도 있음
각 레이어 별 어드민의 역할
호스트-서비스 프로젝트 마다 다른 레벨의 사용 가능한 gcp 리소스를 가지고 있음
- 권한 분리를 통해 엔터프라이즈 환경에 맞는 클라우드 환경 구축 가능
폴더 리소스
- 사용하지 않을 수도 있지만 폴더 안에 프로젝트 1000개까지 구성 가능