Com2us Platform · Multi-cloud
서머너즈워: 천공의 아레나 멀티클라우드와 방화벽 재설계
GCP와 Tencent Cloud에 걸친 서버 600대·DB 70개 환경의 방화벽 정책을 전수 재설계하고, 무점검 원칙으로 운영한 대규모 게임 인프라입니다.
- 역할
- Cloud Engineer · 메인 엔지니어
- 기간
- 2023.02 – 2026.02
- CSP
- GCP · Tencent
- 규모
- 서버 600대 · DB 70개 · Massive
- 핵심 기술
- GCP · Tencent Cloud · Terraform · Terragrunt · Cloud Armor
- 600
- 서버
- 70
- DB
- - 40 %
- Terragrunt 전환 뒤 배포 시간
한눈에 보기
문제
회사에서 가장 큰 프로젝트로, 중국 서비스를 위해 Tencent를 함께 운영했습니다. 두 클라우드의 방화벽 정책이 오래 쌓여 중복되고 복잡해졌고, 여러 리전으로 커진 코드는 Terraform만으로 다루기 어려워졌습니다.
접근
클라우드 간 방화벽 정책을 전수 분석해 중복과 불필요한 규칙을 제거하고 웹, 게임, DB, 관리 역할 기준으로 다시 묶었습니다. Terraform을 Terragrunt 구조로 옮겨 코드 중복을 걷어 냈습니다. 대부분의 서버를 로드밸런서 백엔드로 두어 서버를 하나씩 빼고 넣는 방식으로 무점검 패치를 했습니다.
결과
방화벽 정책이 단순해져 검토와 변경이 쉬워지고 공격에 노출되는 범위가 줄었습니다. Terragrunt 전환으로 배포 시간을 40% 줄였고, GCP Cloud Armor로 DDoS 방어를 운영했습니다.
자세히 보기
규칙 맵으로 만드는 방화벽 (관련 공개 저장소 pf-02)
이 코드가 하는 일: 규칙 맵(var.rules)의 항목마다 GCP 방화벽 규칙을 하나씩 만들고, 맵의 키를 규칙 이름으로 씁니다. 방향이 INGRESS면 대역을 출발지로, EGRESS면 목적지로 넣고, use_service_accounts 값에 따라 대상과 출발지를 네트워크 태그로 지정할지 서비스 계정으로 지정할지 고릅니다. 규칙 하나하나를 리소스 블록으로 쓰지 않고 맵 항목으로 선언하므로, 역할별로 묶은 정책을 그대로 데이터로 관리할 수 있습니다.
resource "google_compute_firewall" "rules" {
for_each = var.rules
network = each.value.network
name = each.key
direction = each.value.direction
source_ranges = each.value.direction == "INGRESS" ? each.value.ranges : null
destination_ranges = each.value.direction == "EGRESS" ? each.value.ranges : null
source_tags = each.value.use_service_accounts || each.value.direction == "EGRESS" ? null : each.value.sources
source_service_accounts = each.value.use_service_accounts && each.value.direction == "INGRESS" ? each.value.sources : null
target_tags = each.value.use_service_accounts ? null : each.value.targets
target_service_accounts = each.value.use_service_accounts ? each.value.targets : null
priority = each.value.priority배운 점
방화벽 정책은 규칙을 추가만 하면 금방 아무도 읽을 수 없게 된다는 점을 크게 배웠습니다. 오래 쌓인 규칙을 웹, 게임, DB, 관리 역할 기준으로 다시 묶고 나니 변경할 때 어디를 봐야 하는지 바로 보였고, 공격에 노출되는 범위도 함께 줄었습니다. 규모가 커질수록 코드도 같은 문제를 겪어서, 여러 리전으로 늘어난 Terraform 코드를 Terragrunt 구조로 옮겨 중복을 걷어 내야 했습니다. 무점검 운영은 특별한 기술보다 서버를 로드밸런서 뒤에 두고 하나씩 빼고 넣을 수 있게 만든 구조에서 나왔습니다. 그리고 한 번의 전수 분석으로 정리한 정책도 시간이 지나면 다시 쌓이므로, 정리는 일회성 작업이 아니라 주기적으로 돌아가야 하는 점검이라는 것을 배웠습니다.