Google PCA: 컴퓨팅, 애플리케이션 플랫폼 및 워크로드 아키텍처 — 학습 가이드

By Laurynas Brazys · 5 September 2026 · #google #PCA #certification #exam-prep #study-guide

다음의 일부입니다: Google Professional Cloud Architect — 학습 가이드. 검증된 답안으로 연습하기: Google 시험 허브, 또는 다음에서 시간 제한 모의고사 풀기: ExamRoll.io.

개요

이 도메인은 Google Cloud에서 컴퓨팅 플랫폼을 선택하고 설계하는 방법, 애플리케이션을 패키징하고 배포하는 방법, 안정성, 성능, 보안 및 비용 효율성을 위해 워크로드를 운영하는 방법을 다룹니다. 가상 머신, Kubernetes, 서버리스 런타임, 부하 분산, 출시 전략, 스테이트풀(stateful) 및 특수 컴퓨팅, 변화하는 요구를 충족하면서 기술 부채를 줄이는 현대화 패턴까지 포괄합니다.

Compute Engine 및 VM 기반 아키텍처

Compute Engine은 운영 체제, 네트워킹, 머신 형태에 대한 세분화된 제어를 제공합니다. 워크로드 특성에 따라 머신 계열을 선택하세요:

E2: 비용에 최적화된 범용 계열. 개발/테스트, 버스트(bursty) 앱에 적합합니다.
N2/N2D: 대부분의 프로덕션 워크로드에 적합한 균형 잡힌 가격/성능. N2D는 강력한 메모리 대역폭을 갖춘 AMD CPU를 사용합니다.
C2/C2D/C3: CPU 집약적인 작업(예: 높은 QPS의 API, 배치 컴퓨팅)에 최적화된 컴퓨팅 계열.
M3: 대규모 인메모리 데이터세트(캐시, 인메모리 분석)에 최적화된 메모리 계열.
A3: 학습/추론을 위한 GPU 최적화(NVIDIA) 계열. 다른 계열에도 GPU를 연결할 수 있습니다.
Confidential VM(지원되는 CPU에서 사용 가능)은 최소한의 코드 변경으로 사용 중인 데이터를 암호화합니다.

관리형 인스턴스 그룹(MIG)은 탄력성과 복원성을 제공합니다:

불변의 구성을 위해 인스턴스 템플릿을 사용하고, 여러 영역에 걸쳐 수평적으로 확장하기 위해 MIG를 사용합니다.
자동 확장 정책: CPU, 부하 분산기 사용률, Cloud Monitoring 측정항목 또는 커스텀 측정항목을 통한 큐 깊이. 버스트(bursty) 부하 시 과도한 변동(thrash)을 피하기 위해 최소/최대 복제본 수와 재사용 대기시간(cooldown)을 설정합니다.
순차적 업데이트(Rolling update)와 카나리(canary) 배포는 위험을 줄여줍니다. 스테이트풀(stateful) 서비스나 콜드 스타트가 많은 서비스의 경우, 서지(surge) 및 사용 불가(unavailable) 설정을 보수적으로 유지합니다.

부하 분산 및 상태 확인:

전역 외부 HTTP(S) 부하 분산기는 TLS를 종료하고 URL 매핑을 지원하며 웹 API의 표준 프런트엔드입니다. 내부 HTTP(S) LB는 east-west 트래픽에 사용됩니다.
상태 확인(Health check)은 백엔드에 도달해야 합니다. 일반적인 장애 원인은 차단된 프로브(probe)로 인해 인스턴스가 계속 재시작되고 트래픽이 유실되는 것입니다. VPC 방화벽 규칙과 대상 태그를 사용하여 상태 확인 소스 범위가 백엔드 포트에 접근하도록 허용해야 합니다.

MIG에 대한 HTTP 상태 확인을 허용하는 예시:

gcloud compute firewall-rules create allow-lb-health-checks –network=my-net –direction=INGRESS –action=ALLOW –rules=tcp:80 –source-ranges=35.191.0.0/16,130.211.0.0/22 –target-tags=web-backend

VM 수명 주기 고려사항:

시작 스크립트나 이미지 메타데이터를 사용하여 부트스트랩하고, 런타임 구성은 이미지에 포함(bake)하지 말고 Secret Manager에 저장합니다.
선점형(preemptible)/Spot VM의 경우, 종료 알림 시 작업을 정상적으로 마칠 수 있도록 종료 스크립트(shutdown-script)를 추가합니다.
구성 드리프트(configuration drift)를 방지하기 위해 미리 패치된 이미지(baked image)와 순차적 교체(rolling replacement)를 통해 패치를 적용합니다.
영구 디스크(Persistent disk) 크기 조절은 온라인으로 가능합니다. 디스크 크기를 늘린 다음, 최소한의 다운타임으로 파일 시스템을 확장합니다(예: ext4에서 resize2fs 사용).

영구 디스크(PD) 크기 조절 예시:

gcloud compute disks resize my-disk –size=500GB –zone=us-central1-a
sudo resize2fs /dev/sdb

보안 ID 및 관측 가능성:

인스턴스에 최소 권한의 서비스 계정을 연결하고, 정적 사용자 인증 정보를 포함하지 마세요.
Cloud Logging 및 Cloud Monitoring을 위해 Ops Agent를 설치하세요. Cloud Trace와 Cloud Profiler를 사용하여 테일 레이턴시(tail latency)와 핫스팟(hot spot)을 줄이세요.
장기 보관 및 분석을 위해 감사 및 측정항목 데이터를 BigQuery 또는 Cloud Storage로 내보내세요.

배치 및 특수 컴퓨팅:

비용 절감을 위해 내결함성 있는 배치 작업에 Cloud Batch 또는 선점형 VM을 사용하는 MIG를 활용하고, 체크포인팅(checkpointing)을 구현하세요.
ML 가속이 필요한 경우 GPU/TPU를 연결하세요. 규정 준수/격리 요구사항을 충족하기 위해 전용 노드 풀 또는 단독 테넌트 노드를 사용하세요.
Confidential VM은 메모리 내의 민감한 데이터를 보호합니다. 요구사항 대비 오버헤드를 측정하세요.

상태(State) 고려사항:

애플리케이션 인스턴스를 스테이트리스(stateless)하게 유지하세요. 확장 시 사용자에게 보이는 이상 현상을 방지하기 위해 세션을 공유 저장소(예: Memorystore, Cloud SQL)로 외부화하세요.
VM에 종속된 상태의 경우, 리전 영구 디스크(regional persistent disk)나 복제된 데이터베이스를 사용하고, 장애 조치 경로를 테스트하세요.

Kubernetes 및 컨테이너 플랫폼 (GKE)

GKE는 유연한 워커 노드 풀과 함께 관리형 제어 영역을 제공합니다:

리전 클러스터는 고가용성을 위해 여러 영역에 걸쳐 제어 영역과 노드를 복제합니다. 영역 클러스터는 리소스를 한 곳에 집중하여 비용을 절감하고 지연 시간에 대한 민감도를 낮춥니다.
여러 노드 풀을 사용하여 워크로드(예: 범용, GPU, 고용량 메모리, 스팟)를 분할합니다. 테인트(taints)/톨러레이션(tolerations) 및 어피니티(affinity)/안티-어피니티(anti-affinity)를 적용하여 포드 배치를 제어하고 노이지 네이버(noisy-neighbor) 효과를 줄입니다.
자동 확장 레이어: 클러스터 자동 확장 처리는 노드를 추가/제거하고, 수평형 포드 자동 확장 처리(HPA)는 CPU/커스텀 측정항목에 따라 복제본 수를 조정하며, 수직형 포드 자동 확장 처리(VPA)는 요청 리소스를 적정 크기로 조정합니다. 탄력성을 위해 HPA와 클러스터 자동 확장 처리를 결합하여 사용합니다.

워크로드 스케줄링 및 서비스:

CPU/메모리 요청(requests)/한도(limits)를 적정 크기로 설정하여 축출(eviction) 위험을 최소화하고 빈 패킹(binpacking) 효율성을 극대화합니다.
업그레이드 중 가용성을 유지하기 위해 PodDisruptionBudgets를 사용합니다.
서비스 유형: ClusterIP(클러스터 내부), NodePort/LoadBalancer(외부-내부 트래픽), 그리고 전역 LB를 사용한 HTTP(S) 라우팅을 위한 Ingress가 있습니다. 카나리 배포의 경우, 별도의 Service/Ingress 백엔드 또는 서비스 메시를 통해 트래픽을 전달합니다.

업그레이드 및 복원력:

서지 업그레이드(surge upgrades)와 maxUnavailable을 사용하여 변동(churn)을 제어하고, 중요한 워크로드는 여러 영역과 풀에 고정합니다.
비즈니스에 중요한 기간에는 유지보수 기간/제외를 설정합니다.
전체 롤아웃 전에 사전 프로덕션 환경과 카나리 노드 풀에서 검증합니다.

이미지 및 보안:

컨테이너 이미지는 Artifact Registry에 저장하고, 취약점 스캔을 활성화하며, 출처(provenance) 확인을 위해 바이너리 승인 또는 증명(attestations)을 설정합니다.
Workload Identity를 사용하여 GSA를 KSA에 매핑함으로써, 자격 증명 없이 최소 권한으로 Google API에 액세스할 수 있도록 합니다.
CSI 드라이버를 통해 Secret Manager에서 런타임 구성을 가져옵니다. 매우 민감한 값의 경우, CMEK로 암호화하고 RBAC를 엄격하게 설정하지 않았다면 Kubernetes Secrets 사용을 피합니다.

롤아웃 및 롤백:

작은 단계와 상태 프로브를 사용하는 Deployment 롤링 업데이트를 선호합니다. 장애 허용 범위가 낮은 시스템의 경우, 단일 Service 뒤에 두 개의 Deployment를 두는 블루-그린(blue-green) 방식을 사용하고 레이블/셀렉터를 전환합니다.
항상 준비성(readiness) 및 활성(liveness) 프로브를 정의해야 합니다. 잘못 구성된 프로브는 롤아웃 중에 연쇄적인 재시작이나 트래픽 블랙홀을 유발합니다.

서버리스 및 이벤트 기반 플랫폼

Google Cloud 서버리스는 인프라를 추상화하는 동시에 규모, 보안, 비용에 대한 강력한 제어 기능을 제공합니다:

Cloud Run: 컨테이너 네이티브 방식이며, HTTP 요청 또는 Eventarc를 통해 트리거됩니다. 0으로 축소(scale to zero)가 가능하고, 동시성을 구성할 수 있으며, 리비전별 트래픽 분할을 통해 카나리 배포 및 롤백을 지원합니다. 지연 시간에 민감한 엔드포인트의 경우 최소 인스턴스(min instances)를 설정하여 콜드 스타트를 줄입니다. 비공개 이그레스(private egress)를 위해 서버리스 VPC 액세스를 통해 VPC와 통합합니다.
App Engine: 특정 방식이 정해진(opinionated) PaaS입니다. 표준(Standard) 환경은 빠른 확장과 언어별 요청당 동시성 제약 조건을 제공하며, 가변형(Flexible) 환경은 VM에서 컨테이너를 실행하여 더 많은 제어권을 제공합니다. 인스턴스 로컬 세션 상태 사용을 피하고, 공유 스토리지로 외부화하여 부하 시 오래되거나 중복된 사용자 경험이 발생하는 것을 방지합니다.
Cloud Functions: 이벤트 기반 로직을 위한 함수 수준의 세분화를 제공합니다. 가벼운 마이크로 작업을 위해 Pub/Sub, Cloud Storage 또는 Eventarc 트리거를 사용하고, 함수는 멱등성(idempotent)을 가지며 상태 비저장(stateless)으로 유지합니다. 기존 코드 없이 배치/스트림 파이프라인을 결합해야 하는 경우, Dataflow가 자동 확장을 통해 통합된 처리 환경을 제공합니다.

플랫폼 선택 시 고려사항:

운영 제어 수준: Compute Engine > GKE > Cloud Run/App Engine > Cloud Functions.
이식성: 컨테이너 기반(GKE/Cloud Run/App Engine 가변형) > VM 이미지 > 함수 및 App Engine 표준 환경.
지연 시간: 낮은 테일 레이턴시(tail latency)를 위해서는 최소 인스턴스를 설정한 Cloud Run 또는 GKE를 사용합니다. 대화형 워크로드의 경우 콜드 스타트를 피해야 합니다.
확장성: Cloud Functions/Run이 가장 빠르게 확장됩니다. GKE는 HPA와 클러스터 자동 확장 처리의 조합으로 확장하고, MIG는 준비(warm-up) 시간과 상태 확인이 필요합니다.
비용: 트래픽이 급증하거나 평상시 사용량이 적은 경우 서버리스의 사용량 기반 과금 방식이 유리합니다. 처리량이 높고 안정적인 서비스에는 약정 사용 할인을 적용한 GKE/VM이 적합하며, 배치 작업에는 선점형(preemptible)/스팟(Spot) 인스턴스를 사용합니다.

ID 및 구성:

각 서비스는 최소 권한 원칙에 따라 전용 서비스 계정을 사용해야 합니다. Cloud Run 및 Functions의 경우 런타임 서비스 계정을 명시적으로 설정합니다.
보안 비밀은 Secret Manager에 저장하고 IAM을 통해 액세스 권한을 바인딩합니다. 환경 변수나 볼륨 마운트를 통해 주입합니다.

아키텍처 패턴, 배포 및 운영

서비스 분해 및 경계:

Monolith: 배포와 트랜잭션이 가장 단순하지만, 독립적인 확장과 장애 영향 반경(blast-radius) 제어에 한계가 있습니다. 호출 체인 깊은 곳의 성능 문제를 가릴 수 있습니다.
Modular monolith: 명확한 내부 모듈, 공유 프로세스. 분산 환경의 단점 없이 인터페이스를 강제할 수 있어 좋은 중간 단계입니다.
Microservices: 독립적인 배포 및 확장성. 네트워크 지연, 분산 트랜잭션, 일관성 문제를 야기합니다. 명확한 경계 컨텍스트(bounded context)와 데이터 소유권을 정의하고, 결합(coupling)을 방지하기 위해 공유 데이터베이스를 피해야 합니다.

현대화 패턴:

Strangler-fig: 트래픽의 일부를 점진적으로 새 구성 요소로 라우팅하고, 레거시 엔드포인트를 점차적으로 폐기합니다.
Lift and shift: 먼저 컨테이너화 또는 VM 마이그레이션을 통해 안정화한 후 리팩터링합니다.
Anti-corruption layer/facade: 새 서비스를 구축하는 동안 레거시 계약(contract)을 격리합니다.
비즈니스 가치를 극대화하고 리스크를 줄이기 위해 변경이 잦고 마찰이 심한 도메인을 먼저 우선순위로 지정합니다.

배포 및 롤아웃:

자동화된 테스트와 스테이징 환경을 갖춘 CI/CD는 롤백을 줄여줍니다. 카나리 분석, 오류 예산(error budget), 점진적 배포(progressive delivery)를 추가합니다.
Blue-green: 두 배의 용량을 사용하는 대신 다운타임을 최소화하고 롤백을 단순화합니다.
트래픽 분할: Cloud Run/App Engine은 리비전/버전 간의 백분율 기반 라우팅을 지원합니다. 엄격한 SLO 오류 예산 하에 실제 트래픽으로 테스트합니다.

부하 분산 및 상태 확인:

HTTP에는 전역 L7을, 비-HTTP 프로토콜에는 TCP 프록시를 사용합니다. 내부 서비스에는 내부 LB를 사용합니다. 세션 어피니티(session affinity)는 필요할 때만 구성하고 세션 상태는 외부화합니다.
상태 확인은 앱의 가용성(예: 종속성 상태)을 반영해야 합니다. 데이터 저장소 장애를 가리는 단순한 200 OK 응답은 잘못된 트래픽 전달을 유발할 수 있습니다.

관측 가능성 및 거버넌스:

서비스 간 엔드투엔드 지연 시간의 원인을 파악하기 위해 추적(trace)을 계측합니다. 로그와 추적을 연관시키기 위해 요청 ID 로깅을 활성화합니다.
보관 및 감사 요구사항을 위해 로그/메트릭/감사 추적을 BigQuery 또는 Cloud Storage로 내보냅니다. 뷰(view)와 IAM을 통해 액세스를 보호합니다.
VM 로그의 경우 Ops Agent를 설치합니다. 비용과 규정 준수를 제어하기 위해 보관 기간과 싱크(sink)를 정의합니다.

안전한 소프트웨어 공급망:

스캔 기능이 있는 Artifact Registry를 사용하고 이미지를 최소화합니다. Dockerfile 최적화: slim 기반 이미지를 선호하고, 종속성을 먼저 설치한 후 소스를 복사하여 빌드 캐시를 활용합니다.

네트워킹 및 세분화:

VPC 방화벽 태그와 규칙을 통해 계층형 액세스를 강제하여 예상된 흐름(예: web → API → DB)만 허용합니다. web → DB 직접 액세스를 거부합니다.

용량, 성능 및 특수 컴퓨팅

가변적인 수요에 대한 설계:

GCE: 선행 지표(큐 길이)를 기준으로 MIG를 자동 확장하여 CPU 포화 상태를 미리 방지하고, 요청 속도 제한 및 백프레셔를 추가하여 다운스트림을 보호합니다.
GKE: 초당 요청 수 또는 커스텀 측정항목에 대한 HPA와 클러스터 자동 확장 처리를 결합하고, 확장 지연을 피하기 위해 작은 버퍼를 프로비저닝합니다.
서버리스: 동시 실행 및 최소 인스턴스를 조정하여 비용과 지연 시간의 균형을 맞추고, 사용자와 가까운 지연 시간을 위해 리전 배포를 사용합니다.

복원력 및 테스트:

가상 부하를 실행하여 자동 확장 및 SLO를 검증하고, 장애 및 업그레이드 중에도 시스템이 가용성을 유지하는지 확인하기 위해 카오스 테스트(예: 임의의 인스턴스/포드 종료)를 포함합니다.
포드/VM 종료 전에 연결을 드레이닝하도록 PodDisruptionBudgets 및 정상 종료(graceful termination) 후크를 구성합니다.

성능 및 스토리지 선택:

처리량이 높고 지연 시간이 짧은 시계열 및 클릭스트림 수집은 Bigtable에 적합합니다. 핫스팟을 피하기 위해 와이드 로우(wide row)와 시간 버킷 키(time-bucketed key)를 설계합니다.
운영 변경을 최소화하면서 Spark/Hadoop을 사용하려면 Dataproc을 사용하고, 자동 확장으로 클러스터 크기를 적절하게 조정합니다.
기존 코드 없이 시간별 배치와 스트리밍을 결합하려면, 자동 확장 및 윈도잉 기능이 있는 Dataflow를 사용하여 파이프라인을 통합합니다.

데이터 이동 및 연결:

지속적이고 높은 대역폭의 비공개 복제(예: 멀티 테라바이트 데이터베이스)에는 Dedicated Interconnect를 고려하고, 동적 라우팅을 위해 VLAN 연결과 Cloud Router를 사용합니다. 임시 또는 낮은 처리량의 경우 Cloud VPN으로 충분합니다.

스테이트풀(Stateful) 워크로드:

GKE에서는 영구 볼륨(HA를 위한 리전 PD)과 순서가 있고 안정적인 ID를 가진 StatefulSet을 사용하고, NFS 시맨틱을 위해 Filestore를 고려합니다.
가능한 경우 내구성과 확장을 위해 관리형 데이터베이스(Cloud SQL, AlloyDB, Spanner)를 사용하고, 읽기 복제본 및 장애 조치를 계획합니다.

보안 및 규정 준수:

제한된 성능 오버헤드로 사용 중인 데이터를 보호하기 위해 Confidential VM을 고려하고, 워크로드 요구사항에 따라 평가합니다.
고객이 키를 제어해야 하는 경우 CMEK를 사용하고, 환경별 격리를 강제하며, 개발/테스트/프로덕션용 프로젝트를 분리합니다.

비용 제어:

안정적인 상태의 컴퓨팅에는 약정 사용 할인 및 지속 사용 할인을 사용하고, 내결함성 배치 작업에는 선점형/Spot VM을, 서버리스에서는 0으로 자동 확장하는 기능을 사용합니다.
Monitoring 권장사항으로 리소스 크기를 적절하게 조정하고, 유휴 서비스를 제거하며, 예상치 못한 비용 발생을 피하기 위해 로그 기반 측정항목 할당량을 설정합니다.

지연 시간 문제 해결:

Cloud Trace를 사용하여 가장 많은 지연 시간을 유발하는 마이크로서비스를 식별하고, 해당 서비스의 코드 경로, 캐싱 또는 데이터베이스 인덱스를 최적화합니다. A/B 카나리 배포로 개선 사항을 검증합니다.

실제 문제 시나리오

FerroLine Logistics는 배송 추적 및 고객 알림을 처리하는 J2EE 모놀리스를 현대화할 계획입니다. 워크로드는 지역별 마감 시간에 급증하며, 99.9%의 가용성 목표를 충족해야 합니다. 팀은 이벤트 기반 기능을 도입하면서 운영 부담을 최소화하고 이식성을 확보하기를 원합니다.

현재 시스템 안정화 및 관찰

근거: 변경 전에 기준 동작 및 오류를 파악하여 롤백 위험을 줄입니다. 기존 VM에 Ops Agent를 배포하여 Cloud Logging 및 Monitoring을 사용하고, 지연 시간이 긴 요청 경로에 분산 추적을 계측합니다. 로그와 측정항목을 BigQuery로 내보내 과거 데이터 분석 및 SLO 보고에 사용합니다.

단계적 랜딩 존 및 플랫폼 조합 선택

근거: 제어와 속도의 균형을 맞춥니다. 모놀리스를 컨테이너화하여 배치 구성요소는 Cloud Run 작업으로, 스테이트리스(stateless) HTTP API는 Cloud Run 서비스로 마이그레이션하고, 지연 시간에 민감한 엔드포인트에는 최소 인스턴스를 설정합니다. 스테이트풀(stateful) Oracle DB는 초기에 Compute Engine에 유지하고, 내부 API를 위해 리전 내부 HTTP(S) LB를 앞에 두며, 향후 AlloyDB로의 이전을 계획합니다.

세션 및 구성 상태 외부화

근거: 인스턴스 로컬 세션 문제를 피하고 안전한 자동 확장을 활성화합니다. 최소 권한 액세스를 위해 서비스별 계정을 사용하여 Secret Manager에 보안 비밀을 저장합니다. 세션 상태는 Memorystore로, 공유 파일은 Cloud Storage로 이전합니다. 이를 통해 사용자가 최대 부하 시 오래된 데이터를 보는 것을 방지합니다.

ID 및 레지스트리 제어 설정

근거: 최소 권한 및 출처(provenance)를 강제합니다. 취약점 스캔을 활성화하여 Artifact Registry에 이미지를 저장합니다. 각 Cloud Run 서비스 및 GKE 워크로드(나중에 분해될 구성요소용)에 고유한 런타임 서비스 계정을 할당하고, 필요한 역할(예: Pub/Sub Publisher)만 부여합니다.

안전한 롤아웃 전략으로 CI/CD 구현

근거: 계획되지 않은 롤백을 줄입니다. 단위/통합 테스트를 실행하고 스테이징 환경에 배포하는 파이프라인을 구축합니다. Cloud Run 트래픽 분할을 사용하여 새 리비전으로 트래픽의 5~10%를 카나리 배포하고 빠른 롤백을 활성화합니다. VM 기반 DB 변경의 경우, 블루/그린 스키마 마이그레이션 패턴을 사용하여 애플리케이션과 데이터베이스 배포를 분리합니다.

변경이 잦은 도메인부터 분해

근거: 낮은 위험으로 점진적인 가치를 제공합니다. 스트랭글러(strangler) 패턴을 적용합니다. 알림 전송 기능을 GKE 기반 마이크로서비스로 분리하여 급증하는 트래픽에 HPA를 활용하고 Pub/Sub으로 디커플링합니다. 나머지 모놀리스는 인터페이스가 안정화될 때까지 Cloud Run에서 모듈형 모놀리스로 유지합니다.

자동 확장 및 부하 차단(load shedding) 설계

근거: 연쇄적인 장애 없이 급증하는 트래픽을 처리합니다. 엔드포인트별로 Cloud Run 동시 실행 및 최소 인스턴스를 구성하고, 전역 HTTP(S) LB에서 Cloud Armor 속도 제한을 설정하여 인증되지 않은 급증으로부터 보호합니다. GKE 서비스의 경우, 커스텀 측정항목(초당 요청 수)에 대해 HPA를 활성화하고 클러스터 자동 확장 처리를 통해 작은 노드 버퍼를 프로비저닝합니다.

스테이트풀(Stateful) 서비스 및 데이터 경로 준비

근거: 내구성과 성능을 보장합니다. GKE 알림 재시도를 위해, 고객-리전 및 시간 버킷을 키로 사용하는 Bigtable 테이블을 사용하여 높은 쓰기 속도로 일시적인 전송 상태를 저장합니다. 전환 기간 동안 온프레미스 ERP와의 비공개적이고 일관된 연결을 위해 Cloud Router와 함께 Dedicated Interconnect를 사용합니다.

복원력 및 성능 테스트 실행

근거: 전체 전환 전에 SLO를 검증합니다. 가상화된 무작위 사용자 흐름을 실행하여 자동 확장 계층을 트리거합니다. 임의의 Cloud Run 인스턴스를 종료(제어 영역이 다시 생성하도록 허용)하고 GKE 포드를 축출(evict)하여 카오스를 주입하고, PodDisruptionBudgets 및 준비성 게이트(readiness gate)를 확인합니다. Trace를 사용하여 테일 레이턴시(tail latency)에 가장 큰 기여 요인을 식별하고 해결합니다.

비용 및 규정 준수 가드레일 하에 운영

근거: 프로덕션 환경에서 지속 가능하게 운영합니다. 서비스별 예산 및 알림을 설정하고, 필요한 경우 민감한 스토리지에 CMEK를 활성화하며, 안정 상태가 파악되면 GKE 노드 풀 및 AlloyDB에 약정 사용 할인을 사용합니다. 로그 보존 정책과 BigQuery 뷰를 구성하여 내부 감사자와 감사 데이터를 안전하게 공유합니다.

이 단계적 접근 방식은 즉각적인 안정성과 관측 가능성을 제공하고, 안전한 배포 관행을 도입하며, 자연스러운 서비스 경계를 따라 모놀리스를 점진적으로 분해하고, 플랫폼 선택을 제어, 지연 시간, 이식성, 확장성 및 비용 목표에 맞춥니다.

← 조직 설계 · 모든 도메인 · 데이터 스토리지 →

이 문제 연습하기 → · ExamRoll.io에서 시간 제한 연습 →