반응형
✅ 전체 요청 흐름 (Cloud Armor까지)
예: 클라이언트가 https://www.example.com/wp-admin/login 접속했다고 가정
DNS A레코드 IP는 3x.160.xxx.50
🔢 1. 클라이언트가 도메인 접속
- 브라우저가 www.example.com 입력 → DNS 조회
- A레코드: 3x.160.xxx.50 확인됨
- 클라이언트는 3x.160.xxx.50:443 으로 접속 시도 (HTTPS)
🔢 2. GCP의 Forwarding Rule이 응답
- GCP는 클라이언트의 IP:포트 요청을 보고 매칭되는 전달 규칙을 찾음
- 예: 3x.160.xxx.50:443 → new-https-lb-forwarding-rule
- 이 전달 규칙은 new-https-lb-target-proxy 라는 Target HTTPS Proxy를 가리킴
🔢 3. Target Proxy가 요청 수신
- Target Proxy는 SSL 종료도 담당함 (HTTPS 인증서 여기서 작동함)
- 여기서 클라이언트의 Host 헤더 (www.example.com) 와 URL (/wp-admin/login) 정보가 파악됨
🔢 4. ▶️ URL Map 확인 + 라우팅 결정 ← [요청 흐름의 핵심 분기점]
이 단계가 요청 흐름에서 "어떤 백엔드로 보낼지" 결정하는 두뇌 같은 역할이에요.
4-1. URL Map이 보는 정보:
- Host 헤더 = www.example.com
- Path = /wp-admin/login
4-2. URL Map에 등록된 규칙과 매칭 시작:
예를 들어 URL Map에 아래와 같은 규칙이 있다고 해봅시다:
Host Path Backend Service
| www.example.com | /wp-admin/* | backend-http-test |
| www.example.com | 기본 경로 | backend-http |
→ 이 요청은 /wp-admin/* 경로에 해당되므로,
✅ URL Map은 backend-http-test로 보내라고 판단합니다.
※ 이때 우회 필터링처럼 /admin/* 요청을 테스트용 backend로 보내거나,
일부 요청만 다른 backend로 분기시켜 특정 동작을 제한할 수 있어요.
🔢 5. URL Map이 선택한 Backend Service로 넘김
- 이제 요청은 backend-http-test로 전달됩니다.
- 이 백엔드 서비스에 Cloud Armor 정책이 연결되어 있다면 → 다음 단계에서 평가 시작
🔢 6. Cloud Armor 정책이 실행됨
- 예를 들어 backend-http-test에 cl-armor 정책이 붙어 있으면:
- IP 차단
- 지역 차단
- 헤더 조건 등 확인
- 차단 대상이면 403 반환, 아니면 정상적으로 서버에 요청 전달
🔢 7. 요청이 백엔드 서버(VM, NEG 등)로 도달
- 백엔드는 요청 처리 후 응답 반환 (또는 아무 응답 안 하고 무시도 가능)
🎯 요약 핵심 포인트 – 4번에서 하는 일
구분 설명
| 어떤 역할? | 요청의 도메인(Host) 와 경로(Path) 를 기준으로 → 어떤 백엔드 서비스로 보낼지 결정 |
| 누가 판단함? | Target Proxy 가 연결된 URL Map |
| 판단 방식은? | URL Map에 등록된 호스트/경로 규칙과 요청 정보 비교 |
| 왜 중요해? | 여기에 따라 Cloud Armor가 어떤 백엔드에서 작동할지 결정되기 때문! |
✅ 최종 한 줄 요약
🔹 URL Map은 요청의 Host + Path를 보고, 요청이 어디로 갈지를 정하는 “경로 스위치”
🔹 Cloud Armor는 그 다음 단계에서 선택된 백엔드에 붙어서 IP 차단 등을 수행
반응형