[cloud] GCP서버 자원 자동화 시스템 구축 및 운영시간 구분 (with Cloud Scheduler Cloud Function Cloud Build) - 100-hours-a-week/5-yeosa-wiki GitHub Wiki

GCP 서버 자원 자동화 및 Cloud Run 기반 DNS 전환 시스템 구축 보고서

1. 문서 개요

  • 작성자: aaron.lee(이유성) / 클라우드
  • 작성일: 2025-06-22
  • 목적
    • GCP 환경에서 Cloud Function + Cloud Build + Cloud Scheduler를 활용해 VM, MIG, Cloud SQL 등 자원 제어를 자동화하고,
    • 운영 외 시간에는 Cloud Run 기반 서비스로 전환하여 비용 절감과 사용자 대응 페이지를 제공한 사례를 정리합니다.

2. 도입 배경

  • 기존에는 수동으로 VM, MIG 등을 시작/종료하며 비용 통제가 어려웠음
  • 비운영 시간 동안 사용자는 502 또는 빈 페이지를 마주하게 되어 사용자 경험 저하 발생
  • 운영 외 시간에 간단한 공지나 대체 콘텐츠를 제공하고자 하였으며, 다음과 같은 두 가지 방식을 고려함:
방안 내용 장점 단점
A안: Route53 Health Check + Failover 서버 상태를 감지하여 죽으면 다른 페이지로 전환 자동화 단순, AWS에서 많이 사용 GCP는 유사 기능 부재, Cloud DNS 연동 어려움
B안: DNS 레코드 스위칭 (현재 사용 방식) 운영/비운영 시간에 따라 DNS를 변경 Cloud Scheduler와 통합 가능, 명확한 제어 스위칭 딜레이 존재, TTL 설정 필요

3. 선택한 방식: DNS 레코드 스위칭 + Cloud Run

  • GCP Cloud DNS를 활용해 서비스 도메인(dev.ongi.today)을 Cloud Run 또는 MIG로 라우팅
  • 운영 시간에는 MIG → Load Balancer
  • 비운영 시간에는 Cloud Run → 공지 페이지 서비스

운영 시간:

Cloud Scheduler → Cloud Function → gcloud DNS record → dev.ongi.today → MIG (ASG)

비운영 시간:

Cloud Scheduler → Cloud Function → gcloud DNS record → dev.ongi.today → Cloud Run (공지 페이지)

4. Cloud Run 공지 서비스 구성

  • 서비스명: ongi-notice
  • 설명: “운영 시간 외입니다” 안내 페이지 제공
  • 특징
    • Cloud Run + Static HTML (Vite 빌드 결과 배포)
    • Cloud CDN 적용 가능
    • 서버리스로 비용 없음
gcloud run deploy ongi-notice \
  --source=. \
  --platform=managed \
  --region=asia-northeast3 \
  --allow-unauthenticated

5. DNS 스위칭 자동화 구성

Cloud Function 내 DNS 스위칭 함수

import google.auth
from googleapiclient.discovery import build

def switch_dns(to_cloud_run=True):
    credentials, _ = google.auth.default()
    dns = build("dns", "v1", credentials=credentials)

    target_ip = "34.64.xx.xx" if not to_cloud_run else "ghs.googlehosted.com."  # MIG vs Cloud Run

    change_body = {
        "additions": [{
            "name": "dev.ongi.today.",
            "type": "CNAME",
            "ttl": 60,
            "rrdatas": [target_ip]
        }],
        "deletions": [{
            "name": "dev.ongi.today.",
            "type": "CNAME",
            "ttl": 60,
            "rrdatas": ["34.64.xx.xx" if to_cloud_run else "ghs.googlehosted.com."]
        }]
    }

    dns.changes().create(
        project="dev-ongi-3-tier",
        managedZone="ongi-zone",
        body=change_body
    ).execute()
  • /start 요청 시 MIG IP로 전환
  • /stop 요청 시 Cloud Run URL로 전환

6. 시스템 아키텍처 요약

[Cloud Scheduler] → [Cloud Function] → [Cloud Build 실행 및 Cloud DNS 수정]
                                      ↘ Discord Webhook 알림 전송
  • 모든 요청은 Discord Webhook으로 실시간 결과 공유
  • DNS TTL: 60초 설정 → 전환 속도 단축

7. 기대 효과

  • 운영 시간 외 자원 완전 종료 → 비용 최적화 (월 수십~수백 달러 절감)
  • 사용자에게 안내 페이지 제공 → UX 개선
  • 서버리스 + DNS 제어 조합으로 구조 간소화, 유지보수성 향상

8. 향후 개선점

  1. MIG 및 Cloud SQL 상태 모니터링을 기반으로 동적 판단 추가
  2. Cloud DNS TTL과 사용자 체감 지연 사이의 트레이드오프 최적화
  3. Cloud Run → 버전 구분 배포 및 UI/UX 강화 (운영/점검 모드 전환 페이지)

9. 결론

  • 단순히 자원을 껐다 켜는 수준을 넘어, 비운영 시간에도 사용자가 안내를 받을 수 있는 구조를 도입
  • GCP 내 한계와 장단점을 검토한 뒤 가장 실용적인 방법을 설계하여 적용함
  • 향후 다양한 모니터링 및 조건부 DNS 정책으로 발전 가능성이 높은 구조임