티스토리 뷰
Resource Managememt
목차:
1. Resource Management
2. Quotas
3. Labels and names
4. Billing
1. Resource Management
- Resource management를 사용하면 project, folder 및 Organization별로 리소스를 계층적으로 관리할 수 있습니다.
- policy에는 일련의 roles과 member가 포함되고 policy는 resource에 설정됩니다. 이러한 resource는 왼쪽에서 볼 수 있듯이 부모로부터 policy를 상속합니다. 따라서 resource policy는 parent와 resource의 결합입니다. 또한 상위 정책이 덜 제한적이면 더 제한적인 리소스 정책보다 우선한다는 점에 유의하셔야 합니다.
- IAM 정책은 위에서 아래로 상속되지만 오른쪽에서 볼 수 있듯이 billing은 아래에서 위로 누적됩니다. 리소스 소비는 사용률 또는 시간, 항목 수 또는 기능 사용과 같은 수량으로 측정됩니다. 리소스는 하나의 프로젝트에만 속하므로 프로젝트는 모든 리소스의 소비를 누적합니다. 각 프로젝트는 하나의 결제 계정과 연결되어 있으므로 조직에 모든 결제 계정이 포함됩니다. 조직, 프로젝트 및 리소스를 더 자세히 살펴보겠습니다.
- 프로젝트는 모든 리소스의 소비를 누적하므로 리소스 및 할당량 사용을 추적하는 데 사용할 수 있습니다. 특히 프로젝트를 사용하면 결제를 활성화하고 권한 및 사용자 인증 정보를 관리하며 서비스 및 API를 활성화할 수 있습니다. Cloud Platform 리소스와 상호 작용하려면 모든 요청에 대해 식별 프로젝트 정보를 제공해야 합니다.
- 프로젝트는 다음으로 식별할 수 있습니다.
-
사람이 읽을 수 있는 방식으로 프로젝트를 식별할 수 있는 프로젝트 이름이지만 Google API에서는 사용되지 않습니다.
-
서버에 의해 자동으로 생성되고 프로젝트에 할당되는 프로젝트 번호도 있습니다.
-
그리고 프로젝트 이름에서 생성된 고유 ID 인 프로젝트 ID가 있습니다.
- GCP 콘솔의 대시 보드에서 또는 Resource Manager API를 쿼리 하여 이러한 세 가지 식별 속성을 찾을 수 있습니다.
- 마지막으로 리소스 계층에 대해 이야기하겠습니다. 물리적 조직의 관점에서 리소스는 global, regional 또는 zonal으로 분류됩니다.
- 몇 가지 예를 살펴보겠습니다.
-
이미지, 스냅 샷 및 네트워크는 global 리소스입니다.
-
외부 IP 주소는 regional 리소스입니다.
-
인스턴스와 디스크는 zonal 리소스입니다.
- 그러나 유형에 관계없이 각 리소스는 프로젝트로 구성됩니다. 이를 통해 각 프로젝트는 자체 청구 및 보고를 가질 수 있습니다.
2. Quotas
- GCP의 모든 리소스에는 프로젝트 할당량 또는 한도가 적용됩니다. 일반적으로 여기에 표시된 세 가지 범주 중 하나에 속합니다.
-
프로젝트 당 생성할 수 있는 리소스 수. 예를 들어 프로젝트당 5개의 VPC 네트워크만 가질 수 있습니다.
-
프로젝트 또는 속도 제한에서 API 요청을 얼마나 빨리 할 수 있는지. 예를 들어 기본적으로 Cloud Spanner API를 사용할 때 프로젝트 당 초당 5 개의 관리 작업만 수행할 수 있습니다.
-
Regional 할당량도 있습니다. 예를 들어 기본적으로 Region당 24 개의 CPU 만 가질 수 있습니다.
- 시간이 지남에 따라 GCP 사용이 확장됨에 따라 할당량도 증가할 수 있습니다. 향후 사용량이 눈에 띄게 증가할 것으로 예상되는 경우 GCP Console의 할당량 페이지에서 할당량 조정을 사전에 요청할 수 있습니다. 이 페이지에는 현재 할당량도 표시됩니다.
- 프로젝트 할당량은 오류 또는 악의적인 공격 시 폭주 소비를 방지합니다.
- 예를 들어 gcloud 명령 줄을 사용하여 실수로 Compute Engine 인스턴스 10 개 대신 100 개를 만들었다 고 가정해 보겠습니다. 할당량은 청구 급증을 방지합니다. 할당량은 결제와 관련이 있지만 나중에 예산 및 알림을 설정하는 방법을 살펴보겠습니다. 이러한 설정은 결제 관리에 큰 도움이 됩니다.
- 마지막으로 할당량은 크기 조정 및 주기적인 예산 검토를 강제합니다. 예를 들어 실제로 96 코어 인스턴스가 필요할까요? 아니면 더 작고 저렴한 대안을 선택할 수 있을까요?라는 질문을 던질 수 있습니다.
- 할당량은 해당 리소스를 사용할 수 있는 한 해당 리소스 유형에 대해 만들 수 있는 최대 리소스 양입니다. 할당량은 리소스가 항상 사용 가능하다는 것을 보장하지 않습니다. 예를 들어 한 지역이 로컬 SSD를 벗어난 경우 로컬 SSD에 대한 할당량이 남아 있더라도 해당 지역에서 로컬 SSD를 만들 수 없습니다.
3. Labels and names
- 라벨은 GCP 리소스를 구성하는 유틸리티입니다. 라벨은 VM, 디스크, 스냅 샷, 이미지와 같은 리소스에 연결할 수 있는 key-value 쌍입니다. GCP 콘솔, gcloud 또는 Resource Manager API를 사용하여 라벨을 만들고 관리할 수 있으며 각 리소스는 최대 64 개의 라벨을 가질 수 있습니다.
- 예를 들어 가상 머신의 환경을 정의하는 레이블을 만들 수 있습니다. 그런 다음 각 인스턴스의 레이블을 프로덕션 또는 테스트로 정의합니다. 이 레이블을 사용하여 재고 목적으로 모든 생산 자원을 검색하고 나열할 수 있습니다.
- 비용을 분석하거나 여러 리소스에서 대량 작업을 실행하는 데 도움이 되도록 스크립트에서 레이블을 사용할 수도 있습니다. 위의 의 그림은 인스턴스에 생성된 4 개의 라벨 예를 보여줍니다.
- 라벨을 사용할 용도에 대한 몇 가지 예를 살펴보겠습니다.
-
여러 팀이 소유한 인스턴스를 구별하기 위해 팀 또는 비용 센터를 기반으로 레이블을 추가하는 것이 좋습니다. 원가 계산 또는 예산 책정에 이 유형의 레이블을 사용할 수 있습니다. 예를 들어, team : marketing 및 team : research입니다.
-
레이블을 사용하여 구성 요소를 구분할 수도 있습니다. 예 : component : redis, component : frontend.
-
다시 말하지만 환경 또는 단계에 따라 레이블을 지정할 수 있습니다.
-
또한 레이블을 사용하여 리소스의 소유자 또는 기본 연락처를 정의하는 것도 고려해야 합니다. 예 : owner : gaurav, contact : opm.
-
또는 리소스에 라벨을 추가하여 상태를 정의하세요. 예 : state : inuse, state : readyfordeletion
- 라벨과 태그를 혼동하지 않는 것이 중요합니다. 방금 배운 라벨은 리소스를 구성하는 데 사용되는 key-value 형식의 사용자 정의 문자열이며 billing를 통해 전파할 수 있습니다. 반면에 태그는 인스턴스에만 적용되는 사용자 정의 문자열이며 주로 방화벽 규칙 적용과 같은 네트워킹에 사용됩니다.
4. Billing
- 프로젝트 계획 및 비용 관리를 돕기 위해 예산을 설정할 수 있습니다. 예산을 설정하면 해당 금액에 대한 지출이 어떻게 증가하는지 추적할 수 있습니다. 위 스크린 샷은 예산 생성 인터페이스를 보여주고 있습니다.
-
먼저 예산 이름을 설정하고 예산이 적용되는 프로젝트를 지정합니다.
-
그런 다음 예산을 특정 금액으로 설정하거나 전월 지출과 일치시킬 수 있습니다.
-
예산 금액을 결정한 후 예산 알림을 설정할 수 있습니다. 이러한 알림은 지출이 예산의 비율 또는 지정된 금액을 초과한 후 결제 관리자에게 이메일을 보냅니다.
- 예시의 경우 지출이 예산 금액의 50 %, 90 %, 100 %에 도달하면 이메일을 보냅니다. 예산 기간이 끝날 때까지 지출이 예산 금액의 비율을 초과할 것으로 예상되는 경우 알림을 보내도록 선택할 수도 있습니다. 이메일을 받는 것 외에도 Cloud Pub/Sub 알림을 사용하여이 예산에 대한 지출 업데이트를 프로그래매틱 방식으로 받을 수 있습니다. 비용 관리를 자동화하기 위해 Pub/Sub 주제를 수신하는 Cloud 함수를 만들 수도 있습니다.
- 이메일 알림의 예입니다. 이메일에는 프로젝트 이름, 초과된 예산 비율 및 예산 금액이 포함되어 전송됩니다.
- GCP 지출을 최적화하는 또 다른 방법은 라벨을 사용하는 것입니다. 예를 들어 여러 지역에 분산된 VM 인스턴스에 라벨을 지정할 수 있습니다. 아마도 이러한 인스턴스는 대부분의 트래픽을 다른 대륙으로 보내고 이로 인해 더 많은 비용이 발생할 수 있습니다. 이 경우 이러한 인스턴스 중 일부를 재배치하거나 Cloud CDN과 같은 캐싱 서비스를 사용하여 사용자에게 더 가까운 콘텐츠를 캐시 하여 네트워킹 지출을 줄이는 것을 고려할 수 있습니다.
- 모든 리소스에 라벨을 지정하고 결제 데이터를 BigQuery로 내보내 지출을 분석하는 것이 좋습니다. BigQuery는 SQL과 빠른 응답 시간을 제공하는 Google의 확장 가능한 완전 관리 형 엔터프라이즈 데이터웨어 하우스입니다. 다음 실습에서 살펴볼 이 스크린 샷에 표시된 것처럼 간단하게 쿼리를 생성할 수 있습니다.
- 데이터 스튜디오로 시간 경과에 따른 지출을 시각화할 수도 있습니다. 데이터 스튜디오는 데이터를 읽기 쉽고 공유하기 쉬우며 완전히 맞춤 설정할 수 있는 유익한 대시 보드 및 보고서로 변환합니다. 예를 들어 라벨을 사용하여 결제 보고서를 분할할 수 있습니다.