[Act 1 / Session 1 (45분)] 단일 VM & 베이스라인  ──▶ "Titanium/Hyperdisk로 고성능 단일 VM을 빚고 Global VPC와 OS Login 보안을 깐다"
        │
        ▼
[Act 2 / Session 2 (50분)] 무중단 클러스터(MIG) ──▶ "단일 서브넷 위에서 3개 존에 VM을 자동 분산하고 무중단 롤링 배포·자가 치유를 건다"
        │
        ▼
[Act 3 / Session 3 (55분)] SDN 로드밸런싱 제어  ──▶ "GFE/Maglev/Envoy로 트래픽을 라우팅하고 하이브리드 BGP 및 Keep-alive 502를 해결한다"
        │
        ▼
[Act 4 / Session 4 (30분)] Day-2 관측성 & IaC   ──▶ "LB 로그로 1분 안에 병목 구간을 특정하고, 전체 인프라를 Terraform으로 무중단 운영한다"

[기존 세대 호스트]  물리 CPU 코어 ──┬─▶ 고객 VM vCPU 실행
                                  └─▶ 하이퍼바이저 I/O 처리 (Andromeda vSwitch + PD 암호화/블록 처리) ──▶ 대량 I/O 시 CPU 경합 발생!

[Titanium 호스트] 물리 CPU 코어 ────▶ 100% 고객 VM vCPU 연산에만 독점 사용! (Noisy Neighbor 및 I/O 인터럽트 간섭 제로)
                  Titanium IPU ────▶ 전용 ASIC 하드웨어에서 Andromeda SDN 패킷 처리, Hyperdisk NVMe 에뮬레이션, 라인레이트 암호화 전담!

# 1. SMT(하이퍼스레딩) 비활성화: 물리 코어당 1개 스레드만 사용
gcloud compute instances create db-node-01 --machine-type=c3-standard-16 --threads-per-core=1 --zone=asia-northeast3-a

# 2. vCPU는 4개로 유지하면서 메모리만 32GB로 높인 Custom Machine 생성
gcloud compute instances create cache-node-01 --custom-cpu=4 --custom-memory=32GB --custom-vm-type=n2 --zone=asia-northeast3-a

[VirtIO-net (1·2세대)] 게스트 커널 ──▶ VirtIO 링 버퍼 복사 및 하이퍼바이저 에뮬레이션 오버헤드 ──▶ 50Gbps 이상에서 CPU 인터럽트 포화
[gVNIC (3·4세대 필수)] 게스트 커널(gve 드라이버) ◀──(Zero-Copy DMA 직접 메모리 교환)──▶ Titanium IPU & Andromeda SDN (최대 200Gbps 선형 확장)

gcloud compute instances create high-bw-node-01   --machine-type=c3-standard-44   --network-interface=nic-type=GVNIC   --network-performance-configs=total-egress-bandwidth-tier=TIER_1   --zone=asia-northeast3-a

[Phase 1: Pre-Copy (서비스 정상 가동 중)]
  호스트 A에서 VM이 정상 요청을 처리하는 동안, 백그라운드로 메모리 페이지(RAM)를 신규 호스트 B로 사전 복사
        │
[Phase 2: Dirty Page 반복 동기화]
  복사 도중 애플리케이션이 새로 수정한 메모리 조각(Dirty Pages)만 추려서 격차가 수 메가바이트 이하가 될 때까지 반복 전송
        │
[Phase 3: Blackout & SDN Cutover (수십~수백 ms 이내)]
  찰나의 순간 동안 CPU 레지스터와 마지막 메모리를 호스트 B로 넘기고, Andromeda SDN이 VM IP의 물리 호스트 포인터를 호스트 B로 즉시 전환!

# 메타데이터 값이 NONE에서 MIGRATE_ON_HOST_MAINTENANCE 또는 TERMINATE_ON_HOST_MAINTENANCE로 바뀔 때까지 블로킹 대기
EVENT=$(curl -s "http://metadata.google.internal/computeMetadata/v1/instance/maintenance-event?wait_for_change=true"   -H "Metadata-Flavor: Google")

if [ "$EVENT" = "TERMINATE_ON_HOST_MAINTENANCE" ]; then
  touch /tmp/drain_mode && sleep 10 && systemctl stop my-gpu-worker
fi

[GCE VM 호스트 (C3/N4)] ──(Titanium IPU 암호화 & Andromeda 고속 패브릭)──▶ [Google 분산 스토리지 풀 (다중 서버에 자동 샤딩 및 3중/다중 복제)]
   * 만약 물리 호스트 A의 메인보드가 완전히 타버려도? ──▶ 디스크 데이터는 외부 분산 스토리지에 안전하게 보존되어 옆 호스트 B에서 즉시 재마운트!

# 1. 100GB 작은 용량에 15,000 IOPS와 400 MB/s 처리량을 독립 지정하여 디스크 생성
gcloud compute disks create prod-db-hd --type=hyperdisk-balanced --size=100GB   --provisioned-iops=15000 --provisioned-throughput=400 --zone=asia-northeast3-a

# 2. 야간 대규모 배치 작업 시작 전: 무중단으로 IOPS를 50,000으로 상향 (작업 종료 후 다시 15,000으로 하향해 비용 절감!)
gcloud compute disks update prod-db-hd --zone=asia-northeast3-a --provisioned-iops=50000 --provisioned-throughput=800

# /etc/fstab 예시: nofail 옵션이 없으면 Local SSD 포맷 상태가 풀렸을 때 VM이 Emergency Mode로 빠져 SSH 접속이 불가해집니다.
UUID=xxxx-xxxx  /mnt/localssd  ext4  defaults,discard,nofail  0  2

[00분 00초] 트래픽 급증 감지 ──▶ MIG Autoscaler가 신규 VM 40대 동시 생성 명령
[00분 20초] 40대 VM이 동시에 외부 패키지 저장소(apt/yum/pip/npm)로 수백 MB 다운로드 요청 집중!
  ├─▶ 병목 1: 사내 NAT 게이트웨이 대역폭 포화 및 외부 오픈소스 미러 서버 Rate Limit(429 Too Many Requests) 차단 발생!
  ├─▶ 병목 2: 패키지 다운로드 및 컴파일에 6~8분 소요 ──▶ 그 사이 기존 살아있던 서버들이 트래픽을 못 버티고 연쇄 다운!
  └─▶ 병목 3: 일부 VM은 외부 저장소 일시 타임아웃으로 설치 실패 ──▶ 빈 껍데기 VM이 떠서 헬스 체크 무한 실패 반복!

[Git 저장소 (Packer HCL + Ansible/Shell)]
        │ (PR 머지 시 Cloud Build 트리거)
        ▼
[임시 빌더 VM 기동] ──▶ 1) OS 보안 하드닝(CIS) + 2) gVNIC/Ops Agent 설치 + 3) Keep-alive 620초 튜닝 + 4) 앱 아티팩트 내장
        │
        ▼
[GCE 커스텀 이미지 생성: prod-was-20261019-v1] ──▶ [Image Family 포인터: prod-was-family] ──▶ [MIG Rolling Update 트리거]

#!/bin/bash
# 1. LB Health Check가 즉시 이 노드를 제외하도록 상태 파일 변경 후 전파 대기
rm -f /var/run/app_ready
sleep 5

# 2. 애플리케이션에 SIGTERM을 보내 활성 요청만 마무리하고 종료 (최대 60초 타임아웃 제한)
timeout 60 systemctl stop prod-was.service

# 3. 남아있는 로컬 애플리케이션 로그를 Cloud Logging으로 강제 플러시
systemctl stop google-cloud-ops-agent

[타 클라우드]  서울 VPC (10.0.0.0/16) ──┬─▶ AZ-a 서브넷 (10.0.1.0/24)  * AZ-a 장애로 AZ-b로 넘어가면 서버 IP 대역이 바뀜!
                                       └─▶ AZ-b 서브넷 (10.0.2.0/24)  * 도쿄 VPC와 통신하려면 별도 Peering / TGW 구성 필수!

[Google Cloud] 단일 Global VPC ────────┬─▶ 서울 서브넷 (10.10.0.0/20) ──▶ [Zone A VM: 10.10.0.2] [Zone B VM: 10.10.0.3] [Zone C VM: 10.10.0.4]
                                       └─▶ 도쿄 서브넷 (10.20.0.0/20) ──▶ 별도 피어링이나 게이트웨이 없이 Andromeda 내부 라우팅으로 즉시 사설 통신!

# 1. 신규 VPC 생성 시 글로벌 동적 라우팅 모드 지정
gcloud compute networks create prod-global-vpc --subnet-mode=custom --bgp-routing-mode=global

# 2. 기존 운영 중인 VPC도 무중단으로 GLOBAL 모드로 즉시 전환 가능
gcloud compute networks update prod-global-vpc --bgp-routing-mode=global

[Host Project: net-prod-host (네트워크/보안 운영팀 독점 소유)]
  ├─ 중앙 VPC, 서브넷, Cloud Router, Dedicated Interconnect, Cloud NAT, 계층형 방화벽 정책 중앙 관리
  ├─ 서브넷 A (10.10.10.0/24) ──(Subnet-level IAM: compute.networkUser 위임)──▶ [Service Project 1: 결제팀 프로젝트 (VM/MIG/GKE 생성)]
  └─ 서브넷 B (10.10.20.0/24) ──(Subnet-level IAM: compute.networkUser 위임)──▶ [Service Project 2: 송금팀 프로젝트 (VM/MIG/GKE 생성)]

[1단계: Organization / Folder 계층 방화벽 정책] ──▶ 전사 필수 차단(Deny) 또는 공통 보안 에이전트 허용(Allow) 즉시 확정!
        │ (판정이 안 난 트래픽은 goto_next 액션으로 하위 계층에 위임)
        ▼
[2단계: Global / Regional Network Firewall Policy] ──▶ IAM Tags 기반 마이크로서비스 간 세밀한 허용/차단 규칙 평가
        │
        ▼
[3단계: VPC 암묵적 기본 규칙 (최하위 우선순위 65535)] ──▶ 모든 인바운드 차단(Implicit Deny Ingress) / 아웃바운드 허용

# [공격자의 단순 SSRF URL 호출 (헤더 주입 불가)] ──▶ 403 Forbidden 즉시 차단!
$ curl http://169.254.169.254/computeMetadata/v1/instance/service-accounts/default/token
MissingMetadata: Your request must specify a 'Metadata-Flavor: Google' header.

# [정상 SDK 및 내부 에이전트 호출] ──▶ 단기(Short-lived) OAuth2 액세스 토큰 발급
$ curl -H "Metadata-Flavor: Google" http://169.254.169.254/computeMetadata/v1/instance/service-accounts/default/token

[엔지니어 SSH 접속 시도] ──▶ [게스트 OS sshd & PAM/NSS 모듈 (google-oslogin)]
                                  │ (메타데이터 서버를 통해 Google Cloud IAM에 실시간 질의)
                                  ├─▶ 1. 계정 조회 (NSS): Cloud Identity 이메일 기반 고유 POSIX UID/GID 및 홈 디렉토리 매핑
                                  ├─▶ 2. 권한 검증 (IAM): roles/compute.osLogin (일반 유저) vs roles/compute.osAdminLogin (sudo 권한)
                                  └─▶ 3. 2단계 인증 (PAM): enable-oslogin-2fa=TRUE 설정 시 Google OTP / 보안키 2차 인증 강제!

[엔지니어 노트북 (gcloud compute ssh --tunnel-through-iap)]
        │ (HTTPS TLS 443 암호화 터널 + OAuth2 인증 + 기기 보안 상태 검증)
        ▼
[Google Identity-Aware Proxy (IAP) 서버: 35.235.240.0/20]  ◀── IAM 검증: roles/iap.tunnelResourceAccessor 보유 여부 확인
        │ (VPC 내부 사설 라우팅으로 22번 포트 전달)
        ▼
[Private GCE VM (공인 IP 없음! 방화벽은 오직 35.235.240.0/20 -> TCP 22만 허용!)]

[Cloud Load Balancer Backend Service]
        │
        ▼
[Regional MIG: prod-was-mig (Region: asia-northeast3, Subnet: 10.10.0.0/20)]
  ├──▶ Zone A (asia-northeast3-a): [was-vm-a1: 10.10.0.11]  [was-vm-a2: 10.10.0.12]
  ├──▶ Zone B (asia-northeast3-b): [was-vm-b1: 10.10.0.13]  [was-vm-b2: 10.10.0.14]
  └──▶ Zone C (asia-northeast3-c): [was-vm-c1: 10.10.0.15]  [was-vm-c2: 10.10.0.16]

[1. EVEN 모드인 경우]     Zone A: 4대 (성공) │ Zone B: 4대 (성공) │ Zone C: 2대 (2대 생성 실패 대기 중...) ──▶ 총 10대만 가동 (2대분 용량 부족 지속)
[2. BALANCED 모드인 경우] Zone A: 5대 (+1대!)│ Zone B: 5대 (+1대!)│ Zone C: 2대 (재고 부족)                ──▶ 가용한 Zone A/B에 즉시 대신 띄워 총 12대 100% 달성!

gcloud compute instance-groups managed update prod-cache-mig   --region=asia-northeast3   --instance-redistribution-type=NONE

[기존 템플릿: was-tpl-v1 (변경 불가, 스냅샷처럼 영구 보존)]
                                                          ├──▶ [MIG 컨트롤러] ──(롤링 업데이트 또는 카나리 전환)
[신규 템플릿: was-tpl-v2 (새 이미지/환경변수로 신규 생성)]  * 만약 v2 배포 중 장애 발생 시? ──▶ 포인터만 다시 v1으로 바꾸면 100% 동일한 스펙으로 즉시 롤백!

[기존 용량 6대 100% 유지] ──▶ Zone A(+1), Zone B(+1), Zone C(+1)에 신규 v2 VM 3대 동시 추가 생성 (총 9대)
                          ──▶ 신규 3대가 LB Health Check 통과 + minReadySec(60초) 예열 완료 확인!
                          ──▶ 그제야 기존 구버전 v1 VM 3대를 Connection Draining 후 안전 삭제 (다시 6대 유지하며 다음 배치 진행)

gcloud compute instance-groups managed rolling-action start-update prod-was-mig   --version=template=prod-was-tpl-v2   --minimal-action=refresh --most-disruptive-allowed-action=refresh --region=asia-northeast3

[단일 Regional MIG: prod-was-mig (총 10대)]
  ├─ Primary Version (template = was-tpl-v1) ──▶ 9대 가동 (전체 트래픽의 90% 처리)
  └─ Canary Version  (template = was-tpl-v2) ──▶ 1대(또는 3대) 가동 (전체 트래픽의 10% 처리 및 에러율 모니터링)

[Global / Regional / Internal ALB (Envoy 데이터 플레인)]
  ├─ 조건 1: 요청 헤더에 X-Canary-Test: true 포함 시 ──▶ 100% [Backend Service Canary (prod-was-mig-canary)]로 라우팅
  └─ 조건 2: 일반 고객 트래픽 가중치 분할(Weight Split)
       ├─▶ 99% 가중치 ──▶ [Backend Service Stable (prod-was-mig-stable: v1 20대)]
       └─▶  1% 가중치 ──▶ [Backend Service Canary (prod-was-mig-canary: v2  3대)]

최종 목표 인스턴스 대수 = MAX( CPU 권장 10대, 큐 메트릭 권장 18대, 출근 시간 스케줄 15대 ) ──▶ 즉시 18대로 스케일 아웃!

[미적용 시] 피크 100대 ──(트래픽 3분 감소)──▶ 즉시 20대로 80대 대량 삭제! ──(2분 뒤 트래픽 재유입)──▶ 20대가 과부하로 전멸!
[적용 시]   피크 100대 ──(timeWindow=600초 동안 최대 20% 축소 제한)──▶ 최소 80대 이하로 절대 내려가지 않고 10분간 버퍼 용량 유지!

[00:00] 백엔드 DB 마스터-슬레이브 페일오버로 인해 30초간 DB 연결 일시 실패 발생
[00:10] WAS 50대의 /health 엔드포인트가 일제히 "DB 연결 불가 -> HTTP 500 Unhealthy" 반환!
[00:25] MIG Autohealer가 "WAS 50대가 전부 고장 났다!"고 오판하여 WAS 인스턴스 대량 강제 삭제 및 재생성(RECREATE) 돌입!
[00:30] DB는 30초 만에 정상 복구 완료! ──▶ 하지만 이미 WAS 서버들은 삭제되어 부팅 중이므로 고객 요청을 받을 서버가 전멸!
[03:00] 새로 뜬 WAS 50대가 동시에 DB 커넥션 풀(수천 개) 생성을 시도하며 DB 재차 과부하 (Thundering Herd) 발생!

[T = 0s]    MIG가 인스턴스 삭제 시작
             ├─▶ 1) LB Backend Service가 해당 VM을 백엔드에서 제외하고 Connection Draining(예: 60초) 타이머 시작
             └─▶ 2) 동시에 VM 내부에 ACPI 종료 신호 전달 ──▶ Shutdown Script 즉시 시작!
[T = 0~5s]  Shutdown Script가 먼저 /healthz/ready를 503으로 바꾸고 5초간 sleep!
             * 이유: 아직 앱 프로세스를 죽이지 않은 상태에서, 전 세계 GFE/Envoy 프록시에 제외 신호가 100% 도달할 시간을 벌어줌!
[T = 5~45s] 웹서버/WAS에 SIGTERM(Graceful Stop) 전달 ──▶ 새로 들어오는 패킷은 0건인 상태에서 기존 처리 중이던 요청만 완료 후 종료!

[fep-gw-01 (IP: 10.10.1.50, Disk: fep-disk-01) 장애 발생]
  ──▶ 1) MIG가 고장 난 VM 컴퓨팅 껍데기만 삭제 (디스크 fep-disk-01과 예약된 IP 10.10.1.50은 안전하게 보관!)
  ──▶ 2) 동일한 이름(fep-gw-01)의 새 VM을 생성하면서 기존 fep-disk-01과 IP 10.10.1.50을 그대로 재장착하여 부팅!

gcloud compute instance-groups managed update prod-stateful-mig   --region=asia-northeast3   --stateful-disk=device-name=boot-disk,auto-delete=on-permanent-instance-deletion   --stateful-internal-ip=interface-name=nic0,auto-delete=on-permanent-instance-deletion

[정상 시] Zone A의 VM이 [Regional Hyperdisk (Replica: Zone A + Zone B)]를 마운트하여 쓰기 수행 (두 존에 실시간 동기 기록)
[Zone A 전면 장애 시] ──▶ Regional 디스크의 Zone B 복제본은 100% 최신 상태 유지!
                     ──▶ Zone B의 대기(Standby) VM 또는 복구 스크립트가 해당 디스크를 강제 부착(force-attach)하여 데이터 유실(RPO=0) 복구!

[잘못된 방법] 운영자가 gcloud compute instances delete was-vm-01 실행
              ──▶ MIG 컨트롤러: "앗! 목표 대수가 6대인데 1대가 비정상 유실되었다!" ──▶ 즉시 새 VM을 다시 생성해 버림!

[올바른 방법] 운영자가 gcloud compute instance-groups managed delete-instances prod-was-mig --instances=was-vm-01 실행
              ──▶ MIG 컨트롤러: "관리자가 명시적으로 was-vm-01 제거를 지시했군." ──▶ 목표 대수(targetSize)를 6 -> 5로 차감하며 영구 삭제!

[Standby Pool: 미리 부팅·초기화 후 메모리 상태를 얼려둔(Suspended) VM 5대 대기 (CPU 요금 미과금, 메모리/디스크 보관료만 과금)]
        │
        ▼ (스케일 아웃 신호 발생 시 새로 VM을 생성하는 대신 Standby Pool에서 즉시 깨움!)
[Active Pool: 메모리 상태 그대로 수 초 만에 Resume 되어 즉시 트래픽 처리 투입!] (빠진 Standby Pool은 백그라운드에서 다시 보충)

[타 클라우드 인스턴스 기반 LB]
  고객 VPC 서브넷 내부에 ENI(네트워크 카드)를 가진 숨겨진 LB 가상머신(노드)들을 프로비저닝하고 DNS( 다중 A레코드)로 분산
  ──▶ 문제점 1: 초당 요청이 1만 -> 100만으로 급증하면 LB 가상머신 자체를 새로 띄우고 DNS TTL이 퍼지는 데 수 분 소요 (그 사이 패킷 드롭!)
  ──▶ 문제점 2: 고객 서브넷의 사설 IP를 LB 노드들이 갉아먹음

[Google Cloud 소프트웨어 정의 LB]
  고객 VPC 안에 생성되는 개별 장비가 아님! 전 세계 80+ 엣지 거점의 GFE/Maglev 및 호스트 하이퍼바이저의 Andromeda SDN에 라우팅 규칙만 배포!
  ──▶ 결과: 평소 0 RPS이던 VIP에 1초 만에 100만 RPS가 꽂혀도, 이미 상시 가동 중인 글로벌 엣지 플릿이 예열(Pre-warming) 없이 즉시 처리!

[인터넷 클라이언트]
        │ (단일 글로벌 Anycast VIP 접속)
        ▼
[전 세계 80+ 엣지 PoP] ──▶ 1. Maglev (L3/L4 초고속 Consistent Hashing 패킷 분산기)
                       ──▶ 2. GFE (Google Front End: 최단 거리 TCP/TLS 종료, Cloud Armor WAF, DDoS 흡수)
                       ──▶ 3. Envoy (차세대 L7 프록시 엔진: 정규식/가중치 라우팅, 헤더 변환, mTLS)
        │ (Google 전용 광케이블 백본망 경유)
        ▼
[고객 VPC 호스트 서버] ──▶ 4. Andromeda SDN (호스트 하이퍼바이저/Titanium 내장 가상 네트워크 스택: 캡슐화 및 무중단 직접 전달)
        │
        ▼
[백엔드 MIG VM / GKE NEG]

[BGP ECMP 라우터] ──(아무 Maglev 노드로 패킷 전달)──▶ [Maglev Node 1..N (동일한 Consistent Hash 링 보유)] ──▶ 동일한 타겟 GFE/VM으로 정확히 전달!

[일반 리전 LB]     런던 사용자 ◀──(공용 인터넷 해저케이블 왕복 220ms × 3회 핸드셰이크 = 첫 요청까지 660ms 소요!)──▶ 서울 백엔드 서버
[Global ALB (GFE)] 런던 사용자 ◀──(런던 로컬 GFE PoP와 5ms 만에 TCP+TLS 핸드셰이크 완료!)──▶ [런던 GFE] ══(Google 전용 광케이블 + 기존 풀링 연결)══▶ 서울 백엔드

[클라이언트 VM (10.10.1.5)]
        │ 1) 패킷 전송 (Src: 10.10.1.5 ──▶ Dst: Internal ALB VIP 10.10.2.99)
        ▼
[Google 관리형 Envoy 프록시 풀 (고객 VPC의 Proxy-only Subnet 10.129.0.0/23에서 IP들을 자동 대여하여 장착!)]
        │ 2) 기존 연결 종료 후 새 TCP 연결 생성! (Src: 10.129.0.15 [Proxy-only IP로 SNAT!] ──▶ Dst: 백엔드 VM 10.10.2.10)
        ▼
[백엔드 WAS VM (10.10.2.10)]  * 주의: 백엔드 VM 입장에서 패킷의 출발지 IP는 클라이언트가 아니라 10.129.0.0/23 대역입니다!

# 1. 더 큰 대역(/22)을 가진 신규 Proxy-only Subnet을 먼저 BACKUP 역할로 생성
gcloud compute networks subnets create proxy-only-seoul-v2   --purpose=REGIONAL_MANAGED_PROXY --role=BACKUP --region=asia-northeast3 --network=prod-vpc --range=10.130.0.0/22

# 2. 방화벽에 신규 대역(10.130.0.0/22)을 추가 허용한 뒤, 신규 서브넷을 ACTIVE로 승격 (기존 연결 Draining 후 무중단 전환!)
gcloud compute networks subnets update proxy-only-seoul-v2 --role=ACTIVE --region=asia-northeast3 --drain-timeout=300s

[클라이언트 단말 (공인 IP: 203.0.113.7)]
   │  * TCP 세션 #1: Src IP = 203.0.113.7  ──▶  Dst IP = 34.120.55.10 (ALB VIP)
   ▼
[GFE / Envoy 프록시 (TCP 및 TLS 종료 후 HTTP 요청 파싱)]
   │  * TCP 세션 #2: Src IP = 35.191.x.x (또는 Proxy-only IP)  ──▶  Dst IP = 10.10.1.12 (백엔드 VM NIC IP)
   │  * 자동 추가되는 HTTP 헤더: X-Forwarded-For: 203.0.113.7, 34.120.55.10  /  X-Forwarded-Proto: https
   ▼
[백엔드 WAS VM (10.10.1.12)]

[클라이언트 (10.20.1.50)]
   │  * 요청 패킷: Src IP = 10.20.1.50  ──▶  Dst IP = 10.10.99.99 (Internal NLB VIP)
   ▼
[Andromeda SDN (프록시 서버 없음! 패킷 헤더의 Src/Dst IP를 전혀 고치지 않고 그대로 캡슐화하여 백엔드 VM 호스트로 워프!)]
   │  * 백엔드 VM의 ens4 랜카드에 도착한 패킷: Src IP = 10.20.1.50 (원본 그대로!)  ──▶  Dst IP = 10.10.99.99 (VIP 그대로!)
   ▼
[백엔드 VM (자신의 원래 IP는 10.10.1.12)]
   │  * 응답 패킷(DSR): 백엔드 VM이 직접 Src IP = 10.10.99.99 (VIP)  ──▶  Dst IP = 10.20.1.50 으로 클라이언트에게 바로 응답!

$ ip addr show ens4
  inet 10.10.1.12/32 brd 10.10.1.12 scope global dynamic ens4   # <-- NIC에는 내 IP(10.10.1.12)만 보입니다.

$ ip route show table local proto 66
  local 10.10.99.99 dev ens4 proto 66 scope host                # <-- 숨겨진 local 테이블에 LB VIP(10.10.99.99)가 등록되어 있습니다!

[1. Forwarding Rule]        ──▶ "어떤 IP(VIP)와 포트로 트래픽을 받을 것인가?" (예: 34.120.1.1:443, PREMIUM Tier)
         │
         ▼
[2. Target (HTTPS) Proxy]   ──▶ "어떻게 TLS를 종료하고 어떤 인증서/보안 정책을 적용할 것인가?" (Certificate Manager, TLS 1.3)
         │
         ▼
[3. URL Map]                ──▶ "호스트명(Host)과 경로(Path)/헤더를 보고 어느 백엔드 서비스로 보낼 것인가?" (/api -> BS-A, /static -> GCS)
         │
         ▼
[4. Backend Service]        ──▶ "어떻게 헬스 체크하고, 부하를 분산(RATE/UTILIZATION)하며, WAF(Cloud Armor)와 Draining을 걸 것인가?"
         │
         ▼
[5. Instance Group / NEG]   ──▶ "실제 패킷을 처리할 서버(MIG VM)나 컨테이너 파드(Zonal NEG) 또는 온프레미스 IP(Hybrid NEG)는 어디인가?"

gcloud compute ssl-policies create prod-tls12-policy --profile=MODERN --min-tls-version=1.2
gcloud compute target-https-proxies update prod-https-proxy --ssl-policy=prod-tls12-policy

[기본 상태 (allowGlobalAccess = false)]
  온프레미스 서버(192.168.1.10) ──(Dedicated Interconnect / VPN)──▶ [서울 리전 Internal LB VIP (10.10.99.99)] ──▶ 패킷 즉시 드롭!
  * 원인: Internal LB는 기본적으로 "자신과 동일한 리전의 GCP 서브넷 내부에서 출발한 패킷"만 허용하도록 설계되어 있음!

[해결 상태 (allowGlobalAccess = true 설정 후)]
  온프레미스 서버(192.168.1.10) ──(Dedicated Interconnect / VPN)──▶ [서울 리전 Internal LB VIP (10.10.99.99)] ──▶ 정상 수신 및 응답!

[Spoke VPC (업무망 VM)] ──(VPC 커스텀 라우트: 0.0.0.0/0 의 Next-Hop = Internal Passthrough NLB VIP!)
                                 │
                                 ▼ (Andromeda SDN Symmetric Hashing: 왕복 패킷이 100% 동일한 방화벽 VM을 지나가도록 보장!)
                 [Regional MIG: Active-Active 방화벽 어플라이언스 (NVA VM 1, VM 2, VM 3)]
                                 │
                                 ▼
                   [온프레미스 전용선 또는 인터넷 출구]

* 물리적 한계: NAT 공인 IP 1개가 특정 목적지(211.55.1.10:443)와 동시에 맺을 수 있는 최대 소스 포트 수 = 64,512개 (1024~65535)
* 만약 VM당 기본 정적 포트 할당(64개) 상태에서 HTTP Keep-Alive 없이 매번 새 소켓을 열고 닫는다면?
  ──▶ 닫힌 연결도 커널 및 NAT에서 120초(2분, TCP TIME_WAIT) 동안 포트 반환 불가!
  ──▶ 해당 VM이 2분 동안 단 64건(초당 0.53건!)만 외부 API를 호출해도 65번째 요청에서 즉시 포트 고갈 드롭 발생!

gcloud compute routers nats update prod-nat-gw --router=prod-cloud-router --region=asia-northeast3   --enable-dynamic-port-allocation   --min-ports-per-vm=1024   --max-ports-per-vm=16384   --no-enable-endpoint-independent-mapping

[상황: 서울 리전 MIG의 평균 CPU가 82%에 도달함]
  ├─▶ 1. MIG Autoscaler의 판단: "내 목표치는 85%니까 아직 여유 있네! 서버를 안 늘려도 되겠다." (스케일 아웃 안 함!)
  └─▶ 2. Load Balancer의 판단:  "앗! 이 그룹의 최대 허용 용량(80%)을 넘었다! 여긴 포화 상태니 잉여 트래픽을 다른 백엔드 그룹/타 리전으로 넘기자!"
      ──▶ 결과: 서버는 늘어나지 않은 채 다른 존이나 리전으로 트래픽이 쏟아지며 도미노 과부하 발생!

{
  "httpRequest": {
    "requestMethod": "POST",
    "status": 502,
    "latency": "0.003s"          // <-- 백엔드가 느려서 타임아웃 난 것이 아님! 단 3ms 만에 즉시 502 발생!
  },
  "jsonPayload": {
    "@type": "type.googleapis.com/google.cloud.loadbalancing.type.LoadBalancerLogEntry",
    "statusDetails": "backend_connection_closed_before_data_sent_to_client"   // <-- 100% Keep-alive 타임아웃 미스매치 시그니처!
  }
}

[GFE / Envoy 프록시 (Keep-alive: 600초)]                       [백엔드 Nginx / WAS (Keep-alive: 65초)]
        │                                                                      │
        │ ◀══════════════ (기존 요청 처리 후 64.999초 동안 유휴 상태 유지) ══════════════▶ │
        │                                                                      │
[T = 65.000초]                                                          1) "65초 동안 아무 요청이 없네! 소켓 닫자!"
        │                                     ◀──── [TCP FIN 패킷 출발] ─────── │ (백엔드가 먼저 연결 종료 시작)
        │
[T = 65.001초] (아직 백엔드의 FIN 패킷이 네트워크 선로를 날아오는 중이라 LB에 도착하기 직전!)
  2) "내 기준(600초)엔 아직 생생한 연결이네! 새로 들어온 고객의 결제 POST 요청을 이 소켓으로 보내자!"
        │ ─────── [HTTP POST /pay 패킷 출발!] ────▶ (공중에서 FIN과 엇갈림!) ────▶ │
        │                                                               3) "이미 닫은 소켓인데 데이터가 오네? 거부!"
        │ ◀────── [TCP RST (Reset) 패킷 폭탄 반환!] ─────────────────────────── │
        ▼
  4) LB가 클라이언트에게 즉시 502 Bad Gateway 반환! (POST 요청은 멱등성이 없으므로 LB가 다른 서버로 자동 재시도도 못 함!)

[GFE / Envoy 프록시 (고정 600초)]                              [백엔드 웹서버 / WAS (620초로 상향!)]
        │                                                                      │
[T = 600.000초] 1) LB가 먼저 "600초가 지났으니 이 소켓에는 더 이상 새 요청을 절대 배정하지 말자!"고 내부 풀에서 제외
        │ ─────── [LB가 먼저 TCP FIN 전송] ───────────────────────────────────▶ │
        │ ◀────── [백엔드가 안전하게 FIN-ACK 응답 및 소켓 정리 완료] ─────────────── │
        * 결과: LB가 스스로 닫기로 결정한 소켓에는 새 HTTP 요청을 보내지 않으므로 Race Condition 발생 확률 = 0%!

gcloud compute backend-services update prod-websocket-bs --global --timeout=3600s

[단일 설정 파일: /etc/google-cloud-ops-agent/config.yaml]
   ├─▶ 1. Metrics 엔진 (OpenTelemetry Collector 기반) ──▶ OS 커널(/proc), Nginx/Tomcat/Redis/JVM JMX 메트릭 ──▶ [Cloud Monitoring]
   └─▶ 2. Logging 엔진 (Fluent Bit 고성능 C 엔진 기반) ──▶ syslog, 애플리케이션 JSON 로그 파싱 및 스트리밍 ──▶ [Cloud Logging]

[클라이언트 앱] ◀──── (인터넷/모바일 무선망 RTT 및 대용량 요청·응답 본문 전송 시간) ────▶ [GFE / Envoy 프록시] ◀── (순수 WAS 처리 시간) ──▶ [백엔드 MIG VM]
               │◀────────────────────── 1. httpRequest.latency (Monitoring: total_latencies) ──────────────────────▶│
                                                                                │◀─ 2. jsonPayload.backend_target_latency ─▶│
                                                                                │      (Monitoring: backend_latencies)      │

resource.type="http_load_balancer"
httpRequest.status>=500
jsonPayload.statusDetails!="response_sent_by_backend"

resource.type="http_load_balancer"
httpRequest.status=502
jsonPayload.statusDetails="backend_connection_closed_before_data_sent_to_client"

resource.type="http_load_balancer"
jsonPayload.backend_target_latency>"3s"

# 1. 부팅 중인 VM의 커널/스타트업 스크립트 콘솔 로그 마지막 100줄 즉시 확인
gcloud compute instances get-serial-port-output prod-was-01 --zone=asia-northeast3-a --port=1 | tail -n 100

# 2. 긴급 복구 시 대화형 직렬 콘솔(ttyS0) 직접 접속 (복구 완료 후에는 보안을 위해 serial-port-enable=FALSE로 즉시 원복!)
gcloud compute connect-to-serial-port prod-was-01 --zone=asia-northeast3-a

[1단계] 고장 난 VM(broken-vm) 중지 후, 부팅 디스크(broken-boot-disk) 분리(Detach)
        │
[2단계] 같은 존에 있는 정상 Rescue VM에 broken-boot-disk를 추가 데이터 디스크(/dev/sdb)로 부착(Attach)
        │
[3단계] Rescue VM 안에서 mount /dev/sdb1 /mnt/recovery 실행 ──▶ /mnt/recovery/etc/fstab 오타 수정 후 umount!
        │
[4단계] 디스크를 다시 분리하여 원래 broken-vm의 부팅 디스크로 재부착 후 기동 ──▶ 정상 부팅 완료!

# 1. 고장 난 VM 중지 후 부팅 디스크 분리
gcloud compute instances stop broken-vm --zone=asia-northeast3-a
gcloud compute instances detach-disk broken-vm --disk=broken-boot-disk --zone=asia-northeast3-a

# 2. 정상 복구용 VM에 데이터 디스크로 마운트하여 파일 수정
gcloud compute instances attach-disk rescue-vm --disk=broken-boot-disk --zone=asia-northeast3-a

gcloud compute networks subnets update prod-was-subnet --region=asia-northeast3   --enable-flow-logs   --logging-aggregation-interval=interval-5-sec   --logging-flow-sampling=0.5   --logging-metadata=include-all

[입력: 출발지 192.168.10.5 (온프레미스) ──▶ 목적지 10.10.99.99:443 (서울 Internal ALB VIP)]
   ├──▶ [Hop 1: Cloud Router & VLAN Attachment]  PASS (BGP 경로 수신 정상)
   ├──▶ [Hop 2: VPC 라우팅 테이블]                PASS (10.10.0.0/20 서브넷 매칭)
   ├──▶ [Hop 3: Internal LB Forwarding Rule]     DROP! ──▶ 원인 즉시 지목: "Forwarding Rule에 allowGlobalAccess가 꺼져 있어 타 리전/온프레미스 패킷이 거부됨!"

[Terraform의 기본 동작 순서: 기존 리소스 먼저 삭제(Destroy) 후 새 리소스 생성(Create)]
  1) 운영자가 google_compute_instance_template의 startup_script를 수정하고 terraform apply 실행
  2) Instance Template은 수정 불가(Immutable) 리소스이므로, Terraform은 먼저 기존 템플릿(was-tpl) 삭제 API를 호출!
  3) GCP API의 응답: "Error 400: The instance_template resource 'was-tpl' is already being used by 'prod-was-mig' (resourceInUseByAnotherResource)"
  ──▶ 현재 MIG가 그 템플릿을 물고 돌아가고 있으므로 삭제 거부 및 배포 실패!

resource "google_compute_instance_template" "was_tpl" {
  name_prefix  = "prod-was-tpl-"          # [공식 1] 고정 name 대신 name_prefix를 써야 새 템플릿이 이름 충돌 없이 생성됨!
  machine_type = "c3-standard-4"
  # ... (디스크, 네트워크, 이미지, 메타데이터 설정) ...

  lifecycle {
    create_before_destroy = true          # [공식 2] 구버전을 먼저 지우지 말고, 새 템플릿 생성 및 MIG 교체 후 마지막에 삭제!
  }
}

resource "google_compute_region_instance_group_manager" "was_mig" {
  name               = "prod-was-mig"
  region             = "asia-northeast3"
  distribution_policy_target_shape = "BALANCED"

  version {
    # [공식 3] .self_link 대신 반드시 .self_link_unique 를 참조해야 템플릿 내부 속성 변경 시 MIG 업데이트가 정확히 트리거됨!
    instance_template = google_compute_instance_template.was_tpl.self_link_unique
  }

  update_policy {
    type                         = "PROACTIVE"
    minimal_action               = "REPLACE"
    replacement_method           = "SUBSTITUTE"
    max_surge_fixed              = 3      # 3개 존 동시 병렬 Surge
    max_unavailable_fixed        = 0      # 배포 중 가용 용량 100% 사수
    min_ready_sec                = 60     # 60초 예열 후 구버전 제거
  }
}

resource "google_compute_region_instance_group_manager" "was_mig" {
  # ...
  version {
    name              = "primary"
    instance_template = google_compute_instance_template.was_tpl_v1.self_link_unique
  }
  version {
    name              = "canary"
    instance_template = google_compute_instance_template.was_tpl_v2.self_link_unique
    target_size { percent = 10 }
  }
  lifecycle {
    ignore_changes = [target_size]   # <-- 오토스케일러가 늘려놓은 대수를 Terraform이 강제 축소하지 않도록 보호!
  }
}

[인터넷 클라이언트 / 부하 생성기 (trigger_502_race.py & watch_rollout.sh)]
        │
        ▼
[Global External Application Load Balancer (EXTERNAL_MANAGED, Envoy 데이터 플레인)]
        │ (Connection Draining = 60s, Readiness HC = /healthz/ready)
        ▼
[서울 리전 단일 서브넷 (10.10.0.0/20) + Cloud NAT (Dynamic Port Allocation) + IAP SSH 방화벽]
        │
        ▼
[Regional MIG (Zone A/B/C 균등 분산, Liveness HC = /healthz/live, maxSurge=3, maxUnavailable=0)]

현재 운영 중인 인프라/네트워크 환경과 관련하여 궁금하신 점이나 아키텍처 논의 사항을 자유롭게 질문해 주세요!