GCP Monitoring에서 여러 프로젝트를 한 번에 모니터링하는 방법 (Metrics Scope 실습 가이드)

이 글은 여러 GCP 프로젝트를 운영하면서 각 프로젝트를 따로 모니터링해야 하는 비효율을 해결하고 싶은 클라우드 학습자를 위한 실습 기록입니다.
문제는 프로젝트가 늘어날수록 VM 상태, 업타임, CPU 사용량, 장애 여부를 한 화면에서 보기 어려워진다는 점입니다.
이 글을 통해 Metrics Scope를 활용해 여러 프로젝트를 하나의 모니터링 구조로 통합하고, Group, Uptime Check, Dashboard까지 연결하는 방법을 실습으로 이해할 수 있습니다.

이 글의 핵심 질문
GCP에서 여러 프로젝트의 리소스를 하나의 화면에서 통합 모니터링하려면 어떻게 구성해야 하는가?

---

실습 환경

• Cloud: Google Cloud Platform
• 서비스: Cloud Monitoring, Compute Engine
• 프로젝트 구성:
  • Monitoring Project (모니터링 전용 프로젝트)
  • Worker Project 1
  • Worker Project 2
• 주요 구성요소: Metrics Scope, Monitoring Group, Uptime Check, Custom Dashboard
• 모니터링 대상: 각 Worker 프로젝트의 NGINX 웹서버 VM

---

아키텍처

이번 실습의 핵심 구조는 세 개의 프로젝트를 분리해 운영하는 방식입니다. 실제 서비스 리소스는 Worker Project 1과 Worker Project 2에 두고, Monitoring Project는 모니터링 전용 허브로 사용합니다. 두 Worker 프로젝트의 Metrics와 Logs는 Metrics Scope를 통해 Monitoring Project에 연결되고, 그 위에서 Monitoring Group, Uptime Check, Dashboard, Alert 흐름이 구성됩니다. 즉, 여러 프로젝트의 리소스를 하나의 중앙 관제 구조로 묶는 형태입니다.

" alt="GCP Monitoring Metrics Scope 아키텍처" style="max-width:100%; height:auto; border-radius:12px;">

Worker Projects → Metrics Scope → Monitoring Group / Uptime Check → Dashboard / Alert

---

전체 흐름

이번 실습은 크게 5단계로 진행됩니다.

1. Worker 프로젝트에 웹서버 VM 생성
2. Monitoring Project에서 Metrics Scope 구성
3. 라벨 기반 Monitoring Group 생성
4. Group 대상 Uptime Check 생성 및 장애 테스트
5. Custom Dashboard로 Uptime과 CPU 지표 시각화

즉, 이번 실습의 핵심은 단순 VM 모니터링이 아니라 여러 프로젝트를 운영 구조 관점에서 하나의 관측 시스템으로 묶는 것입니다.

---

■ 강사 설명

실습 문서는 세 개의 프로젝트를 사용합니다. Project ID 1은 Monitoring Project, Project ID 2와 3은 Worker 프로젝트로 사용하며, Google 권장 방식대로 모니터링용 프로젝트와 실제 리소스 프로젝트를 분리합니다. 그 후 Worker 프로젝트 두 개를 Monitoring Project의 Metrics Scope에 연결하고, 라벨 기반 Group, Uptime Check, Dashboard를 통해 중앙 모니터링 구조를 만듭니다. :contentReference[oaicite:0]{index=0}

---

■ 내가 이해한 핵심

이번 실습의 본질은 아래 한 줄입니다.

모니터링은 서버를 따로따로 보는 것이 아니라, 여러 프로젝트의 상태를 하나의 구조로 통합해 보는 것이다

프로젝트가 하나일 때는 해당 프로젝트 안에서 Compute Engine, Monitoring, Logs를 보면 됩니다. 하지만 프로젝트가 여러 개로 쪼개지면, 운영자는 점점 각 프로젝트를 오가며 상태를 확인해야 합니다. 이 구조가 커질수록 장애 탐지 속도와 대응 품질은 떨어집니다. Metrics Scope는 바로 이 문제를 해결하는 연결 계층입니다.

---

■ 내가 실제로 겪은 문제

프로젝트가 하나일 때는 큰 불편이 없었습니다. 하지만 프로젝트가 두세 개 이상으로 늘어나면 아래 문제가 바로 드러납니다.

• 서버 상태를 프로젝트마다 따로 봐야 한다
• 한 프로젝트의 Uptime Check와 다른 프로젝트의 CPU 지표를 같은 화면에서 보기 어렵다
• 장애가 나도 어느 프로젝트, 어느 서버에서 문제인지 한 번에 안 보인다

이 실습을 하며 분명해졌습니다. 리소스 분산보다 더 무서운 건 모니터링 분산입니다.

---

실습 단계

1단계. Worker 프로젝트에 NGINX 웹서버 VM 생성

목적: Metrics Scope에 연결할 실제 모니터링 대상 리소스를 준비하는 단계입니다.

실습 문서는 Worker 1 프로젝트와 Worker 2 프로젝트 각각에 Compute Engine VM을 하나씩 생성하도록 안내합니다. VM 이름은 worker-1-server, worker-2-server이며, 머신 타입은 e2-medium(2 vCPU), 운영체제는 Debian 11, 그리고 Allow HTTP traffic를 체크합니다. :contentReference[oaicite:1]{index=1}

생성 후에는 SSH로 접속해 NGINX를 설치합니다.

sudo apt-get update
sudo apt-get install -y nginx

그리고 아래 명령으로 NGINX 프로세스가 실행 중인지 확인합니다.

ps auwx | grep nginx

실습 문서는 이 과정에서 root master process와 worker process가 보이면 정상이라고 설명합니다. 이후 External IP로 접속하면 Welcome to nginx! 화면이 나타나야 합니다. 페이지 7 이미지도 이 기본 NGINX 환영 페이지를 보여줍니다. :contentReference[oaicite:2]{index=2}

이 단계가 중요한 이유는 모니터링은 빈 구조만으로는 의미가 없기 때문입니다. 실제로 살아 있는 웹서버가 있어야 Uptime Check, CPU 지표, 장애 테스트가 가능한 데이터가 생깁니다.

---

2단계. Monitoring Project에서 Metrics Scope 구성

목적: 여러 프로젝트의 리소스를 하나의 중앙 모니터링 범위로 묶는 단계입니다.

실습 문서는 총 세 개의 프로젝트 중 첫 번째 프로젝트를 Monitoring Project로, 두 번째와 세 번째 프로젝트를 Worker 프로젝트로 사용합니다. 그리고 모니터링 전용 프로젝트에는 실제 워크로드를 두지 않는 것이 권장된다고 설명합니다. 즉, Monitoring Project는 관제 허브 역할만 담당합니다. :contentReference[oaicite:3]{index=3}

Monitoring Project에서 Observability > Monitoring > Settings > Metric Scope로 이동한 뒤, Add GCP projects를 선택합니다. 그 다음 Worker 1과 Worker 2 프로젝트를 추가합니다. 설정이 끝난 뒤 Dashboards 페이지로 이동하면, 잠시 후 다른 두 프로젝트의 Disks, Firewalls, Infrastructure Summary, VM Instances 같은 리소스 정보가 중앙에서 보이기 시작합니다. 실습 문서도 반영까지 1~2분 정도 걸릴 수 있다고 안내합니다. :contentReference[oaicite:4]{index=4}

이 단계가 실습의 핵심 전환점입니다. 이제부터 모니터링은 프로젝트 단위가 아니라 Metrics Scope 단위가 됩니다. 즉, 운영자의 시야가 “한 프로젝트”에서 “여러 프로젝트를 포함한 시스템 전체”로 확장됩니다.

---

3단계. 라벨을 활용해 Monitoring Group 만들기

목적: 여러 프로젝트에 흩어진 리소스를 논리적으로 하나의 그룹으로 묶는 단계입니다.

실습에서는 먼저 각 Worker 프로젝트의 VM에 라벨을 붙입니다. Worker 1의 worker-1-server에는 아래 라벨을 추가합니다.

• component=frontend
• stage=dev

Worker 2의 worker-2-server에는 아래 라벨을 추가합니다.

• component=frontend
• stage=test

그 후 Monitoring Project의 Monitoring > Groups에서 새 그룹을 생성합니다. 그룹 이름은 Frontend Servers, 기준은 component = frontend입니다. 실습 문서는 이 조건으로 만들면 오른쪽에 선택된 리소스가 2개 VM으로 보여야 한다고 안내합니다. 잠시 기다리면 이 그룹 전용 차트와 메트릭이 나타납니다. :contentReference[oaicite:5]{index=5}

이후 하위 그룹으로 Frontend Dev를 만들고, 기준을 component = frontend AND stage = dev로 설정합니다. 이렇게 하면 Worker 1의 개발 서버만 따로 묶을 수 있습니다.

이 단계의 핵심은 아주 중요합니다. Metrics Scope가 프로젝트를 묶는 구조라면, Group은 리소스를 역할 기준으로 묶는 구조입니다. 즉, 프로젝트 경계를 넘어서도 “프런트엔드 서버”, “개발 서버”, “운영 서버”처럼 업무 의미로 그룹을 만들 수 있습니다.

---

4단계. Uptime Check 생성과 장애 테스트

목적: 실제 사용자 관점에서 서비스가 살아 있는지 확인하고, 장애 시 어떤 식으로 보이는지 검증하는 단계입니다.

Monitoring Project에서 Uptime checks > +Create Uptime Check로 이동합니다. 설정은 다음과 같습니다.

• Protocol: HTTP
• Resource Type: Instance
• Applies To: Group
• Group: Frontend Servers
• Path: /
• Check Frequency: 1 minute
• Title: Frontend Servers Uptime

실습 문서는 먼저 Test를 눌러 HTTP 200 응답이 나오는지 확인한 뒤 생성하도록 안내합니다. 생성 후 몇 분 지나면 Uptime Check 대시보드에 Passed Checks, Latency, 상태 정보가 차기 시작합니다. 그리고 오른쪽 Configuration 박스에 보이는 Check ID를 메모해 두라고 설명합니다. :contentReference[oaicite:6]{index=6}

이후 장애 테스트를 위해 Worker 1 프로젝트로 이동해 worker-1-server를 Stop 합니다. 그리고 다시 Monitoring Project의 Uptime Check 화면으로 돌아오면, 시간이 조금 지난 뒤 체크 실패가 나타납니다. 실습 문서는 특히 중요한 주의점을 하나 설명합니다. 그룹이 라벨 기반일 경우, 꺼진 서버는 약 5분 후 그룹 구성원에서 제외될 수 있고, 그러면 Uptime Check도 그 서버를 더 이상 확인하지 않아 갑자기 다시 통과처럼 보일 수 있다는 점입니다. :contentReference[oaicite:7]{index=7}

이 단계는 매우 실무적입니다. 단순히 “체크가 된다”에서 끝나지 않고, 장애가 발생했을 때 모니터링 구조가 어떻게 반응하는지까지 이해해야 하기 때문입니다.

---

5단계. Custom Dashboard로 Uptime과 CPU를 한 화면에 구성

목적: 운영자가 실제로 보는 단일 화면을 만드는 단계입니다.

먼저 Worker 1의 worker-1-server를 다시 Start 합니다. 그런 다음 Monitoring Project의 Dashboards에서 +Create Custom Dashboard를 선택하고, 이름을 Developer's Frontend로 입력합니다. 첫 번째 위젯으로 Line chart를 추가하고, Metric은 VM Instance > Uptime_check > check_passed를 선택합니다. 이후 필터에서 checked_resource_id를 선택해 개발 서버만 보이도록 설정합니다. Alignment function은 Count true, Min interval period는 5m로 설정합니다. :contentReference[oaicite:8]{index=8}

두 번째 위젯으로는 CPU 사용률 차트를 추가합니다. Metric은 VM Instance > Instance > cpu utilization이고, 필터에서 instance_name = worker-1-server를 선택합니다.

이제 Worker 2 서버에서 Apache Bench를 설치하고 부하를 발생시킵니다. 실습 문서는 Cloud Shell보다 Worker 2 VM을 부하 발생용으로 쓰는 편이 더 안정적이라고 설명합니다. 설치 명령은 다음과 같습니다.

sudo apt-get update
sudo apt-get install apache2-utils

그 다음 Worker 1 서버의 외부 IP를 이용해 URL 환경 변수를 설정합니다.

URL=http://[worker-1-server ip]

이후 아래 두 번의 부하 테스트를 실행합니다.

ab -s 120 -n 100000 -c 100 $URL/
ab -s 120 -n 500000 -c 500 $URL/

실습 문서는 두 번째 부하가 진행되는 동안 Dashboard로 돌아가면 CPU 차트에 두 번의 뚜렷한 스파이크가 보인다고 설명합니다. 즉, Custom Dashboard는 단순 예쁜 화면이 아니라 “운영자가 실제 상태 변화를 한눈에 확인하는 도구”라는 뜻입니다. :contentReference[oaicite:9]{index=9}

---

실습 증거

1. Monitoring Project와 Worker 프로젝트 분리

실습 문서는 첫 번째 프로젝트를 Metrics Scope 호스트인 Monitoring Project로, 두 번째와 세 번째를 실제 리소스가 있는 Worker 프로젝트로 사용하며, 모니터링 전용 프로젝트에는 리소스를 두지 않는 구성을 권장합니다. :contentReference[oaicite:10]{index=10}

2. NGINX 설치 및 웹페이지 확인

페이지 6~7에서는 sudo apt-get install -y nginx 설치 후 ps auwx | grep nginx로 프로세스를 확인하고, External IP 접속 시 Welcome to nginx! 화면이 나오는 흐름을 보여줍니다. 페이지 7 이미지가 그 결과를 직접 보여줍니다. :contentReference[oaicite:11]{index=11}

3. Metrics Scope에 두 Worker 프로젝트 연결

실습은 Monitoring Settings에서 Metric Scope에 Worker 1, Worker 2 프로젝트를 추가한 뒤, Dashboard 화면에서 다른 두 프로젝트의 리소스가 보이기 시작한다고 설명합니다. 이는 멀티 프로젝트 중앙 모니터링이 실제로 형성되었음을 보여주는 핵심 증거입니다. :contentReference[oaicite:12]{index=12}

4. Uptime Check와 부하 테스트

실습은 Frontend Servers 그룹에 HTTP Uptime Check를 생성하고, 이후 서버를 중지해 실패를 확인하며, Apache Bench로 ab -s 120 -n 100000 -c 100, ab -s 120 -n 500000 -c 500 부하를 발생시켜 CPU 스파이크를 Dashboard에서 확인하게 합니다. :contentReference[oaicite:13]{index=13}

---

트러블슈팅

문제 증상:
Monitoring Project에서 Worker 프로젝트의 리소스가 보이지 않는다.

원인 분석:
Metrics Scope 연결이 완료되지 않았거나, 연결 후 데이터 반영 시간이 아직 부족할 수 있다.

확인 방법:
Monitoring Settings의 Metric Scope에 Worker 1, Worker 2가 추가되어 있는지 확인하고, Dashboards 페이지를 새로고침한다.

해결 방법:
Add GCP projects로 두 Worker 프로젝트를 다시 연결하고, 1~2분 정도 기다린 뒤 확인한다.

재발 방지 방법:
멀티 프로젝트 모니터링을 시작할 때는 먼저 “리소스 프로젝트가 Metrics Scope에 실제 연결되어 있는가”부터 점검한다.

---

문제 증상:
Uptime Check가 정상처럼 보이는데 실제로는 서버가 중지되어 있다.

원인 분석:
라벨 기반 Group에서 중지된 서버가 일정 시간 후 그룹에서 제외되면, 해당 서버에 대한 Uptime Check 대상 자체가 사라질 수 있다.

확인 방법:
Groups 화면에서 그룹 구성원이 실제로 남아 있는지, Uptime Check의 checked_resource_id가 어떤 리소스를 보고 있는지 확인한다.

해결 방법:
Group 기준과 Uptime Check 적용 대상을 함께 검토하고, 필요 시 개별 인스턴스 기준 체크와 그룹 기준 체크를 분리한다.

재발 방지 방법:
그룹 기반 모니터링은 “멤버십 변화”까지 고려해서 설계해야 한다.

---

문제 증상:
Dashboard에 Uptime 또는 CPU 차트가 표시되지 않거나 값이 비어 있다.

원인 분석:
Metric 선택이 잘못되었거나, 필터에 올바른 checked_resource_id 또는 instance_name가 들어가지 않았을 수 있다.

확인 방법:
위젯 설정에서 Metric과 Filter 값을 다시 확인하고, 원본 Uptime Check 화면과 VM 이름을 대조한다.

해결 방법:
Uptime 차트는 VM Instance > Uptime_check > check_passed, CPU 차트는 VM Instance > Instance > cpu utilization를 사용하고, 서버 식별 필터를 정확히 지정한다.

재발 방지 방법:
커스텀 대시보드는 먼저 “원본 메트릭 화면에서 값이 보이는지” 확인한 뒤 위젯으로 옮긴다.

---

실무 핵심 포인트

이번 실습의 핵심은 아래 한 문장으로 정리할 수 있습니다.

모니터링의 수준은 데이터를 얼마나 많이 모으느냐가 아니라, 흩어진 데이터를 얼마나 빨리 운영 판단으로 바꿀 수 있느냐로 결정된다

즉, 멀티 프로젝트 환경에서 진짜 중요한 것은 CPU 차트 하나가 아니라 다음 구조입니다.

• Metrics Scope로 프로젝트를 하나의 관측 범위로 묶고
• Group으로 역할 단위 리소스를 논리적으로 나누고
• Uptime Check로 실제 서비스 생존 여부를 검증하고
• Dashboard로 운영자에게 즉시 보이게 만드는 것

이 4개가 함께 있어야 모니터링이 “데이터 수집”에서 “운영 시스템”으로 올라갑니다.

---

결론

핵심 원칙
여러 GCP 프로젝트를 운영할 때는 각 프로젝트를 따로 보는 대신, Monitoring Project와 Metrics Scope를 중심으로 중앙 모니터링 구조를 먼저 설계해야 한다.

실무 적용 시 주의점

• Monitoring Project는 가능하면 실제 워크로드와 분리하는 것이 좋다
• Metrics Scope가 먼저 연결되어야 중앙 모니터링이 성립한다
• Group은 프로젝트 기준이 아니라 역할 기준으로 설계하는 것이 더 유용하다
• Uptime Check는 실제 사용자 관점이지만, 그룹 멤버 변화까지 고려해야 한다
• Dashboard는 예쁜 화면보다 “운영자가 바로 판단할 수 있는 구성”이 중요하다

다음 학습 단계 제안
다음에는 이 구조 위에 Alert Policy, Notification Channel, Logs Explorer 연계를 붙여 장애 탐지부터 알림, 로그 추적까지 하나의 운영 흐름으로 확장해보면 좋습니다.