Google PCA: 마이그레이션, 현대화 및 하이브리드 클라우드 전략 — 학습 가이드
다음의 일부입니다: Google Professional Cloud Architect — 학습 가이드. 검증된 답안으로 연습하기: Google 시험 허브, 또는 다음에서 시간 제한 모의고사 풀기: ExamRoll.io.
개요
성공적인 마이그레이션, 현대화 및 하이브리드 클라우드 전략은 가용성, 데이터 무결성, 지연 시간, 보안 및 비용에 대한 리스크를 관리하면서 플랫폼 선택을 비즈니스 성과에 맞게 조정합니다. 이 과정은 데이터 센터 리스크를 줄이기 위한 신속한 리호스트(rehost)와 클라우드의 이점을 활용하기 위한 목표 지향적인 리팩터링(refactoring) 사이에서 균형을 맞춥니다. 개선 사항을 지속하기 위해서는 기술과 함께 운영 모델도 발전해야 합니다. 이 섹션에서는 평가 및 웨이브(wave) 계획, 의사결정 프레임워크, 마이그레이션 메커니즘, 하이브리드 통합, 현대화 패턴, 정책 및 멀티 클라우드 고려사항, 마이그레이션 후 최적화에 대한 실용적인 청사진을 제공하며, 실패 모드와 트레이드오프(trade-off)를 강조합니다.
평가, 준비 상태 및 웨이브 계획
탐색 및 종속성 분석
- 워크로드, 버전, OS 커널, 스토리지, IAM 및 데이터 분류를 인벤토리화합니다. 웹→API→DB 흐름, 공유 서비스(LDAP/AD, DNS, NTP), 배치 파이프라인, 외부 API 전반의 종속성을 매핑합니다.
- 마이그레이션 전 환경에서 애플리케이션 프로파일링 및 분산 추적을 사용하여 숨겨진 종속성과 롱테일(long-tail) 지연 시간을 파악합니다. VPC Flow Logs와 애플리케이션 수준의 계측(Cloud Logging, Cloud Monitoring, Cloud Trace)을 활성화합니다.
- 상태 경계와 데이터 그래비티(data gravity)를 식별합니다: 크기, 액세스 패턴(읽기/쓰기 혼합), 일관성 요구 수준, 복제 토폴로지.
준비 상태 및 기술
- 클라우드 기본 사항, IaC, CI/CD, SRE, 보안, 네트워킹, 데이터베이스 기술을 평가합니다. 역할 기반 교육 및 자격증 로드맵을 정의하고 기술 향상(upskilling) 및 섀도우 온콜(shadow on-call)을 위한 시간을 책정합니다.
- 첫 번째 웨이브 이전에 랜딩 존(landing zone)(프로젝트, 폴더, Shared VPC, 조직 정책, 감사 싱크, CMEK 전략)을 구축합니다.
마이그레이션 웨이브 계획
- 애플리케이션을 관련성 및 영향 반경(blast radius)에 따라 웨이브로 그룹화합니다: 공유 데이터, 동기식 종속성, 변경 기간. 리스크가 높은 종속성은 동일한 웨이브에 포함시키거나, 잘 정의된 API 계약으로 스텁(stub) 처리합니다.
- 웨이브별 SLO, RTO/RPO, 롤백 기준, 검증 게이트(스키마 검사, 가상 사용자 여정, 성능 임계값)를 정의합니다.
- 런북(runbook) 및 변경 관리를 준비합니다: 컷오버(cutover) 단계, 체크포인트, 롤백, 승인을 위한 증거 수집.
호환성, 라이선스 및 성능 기준선 설정
- Compute Engine 및 관리형 서비스에서 OS와 미들웨어 지원 여부를 확인합니다. 상용 라이선스 조건, BYOL 제약 조건, 커널 모듈 요구사항, 하드웨어 선호도(affinity)를 확인합니다.
- 대상 리소스의 크기를 산정하고 이점을 검증하기 위해 최대값 및 95번째 백분위수 값으로 CPU, 메모리, IOPS, 처리량, 지연 시간 기준선을 수집합니다.
데이터 거버넌스
- PII/PCI 데이터를 분류합니다. Cloud DLP를 사용하여 수집 시점에 비식별화 또는 토큰화를 계획합니다. 첫 프로덕션 로그가 저장되기 전에 감사, 보존, 내보내기 정책을 정의합니다.
일반적인 실패 모드: 컷오버 후 연쇄적인 타임아웃을 유발하는 알려지지 않은 동기식 종속성, 연결을 차단하는 중복 IP 범위, 라이선스 규정 준수 격차, 데이터 변경을 되돌릴 수 없는 롤백 패리티(parity) 부족.
마이그레이션 패턴, 데이터 이동 및 컷오버
의사결정 프레임워크 (6R)
- 리호스트(Rehost): Compute Engine으로 그대로 이동합니다. 클라우드 전환까지 가장 빠른 시간이 걸리며 변경 사항이 최소화됩니다. 위험: 기술 부채를 그대로 가져오고 비효율적인 사이징의 위험이 있습니다.
- 리플랫포밍(Replatform): 관리형 서비스(예: Cloud SQL, Cloud Load Balancing)를 채택하기 위해 약간의 변경을 수행합니다. 적은 코드 변경으로 더 빠른 운영상의 이점을 얻을 수 있습니다.
- 리팩터링(Refactor): GKE/Cloud Run을 위해 애플리케이션을 분해하거나 컨테이너화하고, 이벤트 기반 패턴을 채택합니다. 장기적으로 가장 큰 이점을 얻을 수 있지만, 구현상의 위험이 따릅니다.
- 폐기(Retire): 사용량 및 종속성이 없는 것으로 확인된 후 사용하지 않는 시스템을 제거합니다.
- 유지(Retain): 규제 또는 지연 시간 문제로 온프레미스에 유지하고, 하이브리드 방식으로 통합합니다.
- 이전(Relocate): vSphere 워크로드를 Google Cloud VMware Engine으로 이동합니다. 기존 도구를 보존하고 변경을 최소화합니다.
컴퓨팅 및 데이터베이스 마이그레이션 도구
- Migrate to Virtual Machines는 디스크와 네트워크 구성을 보존하면서 Compute Engine으로의 리호스트를 가속화합니다. 게스트 OS 지원 및 커널 드라이버를 확인해야 합니다.
- Database Migration Service는 다운타임을 최소화하면서 Cloud SQL로의 동종(homogeneous) 온라인 복제(예: MySQL, PostgreSQL)를 제공합니다. binlog/복제 설정이 올바른지, 그리고 지연 시간이 거의 실시간에 가까운 따라잡기(catch-up)를 지원하는지 확인해야 합니다.
- 워크로드에 맞는 데이터베이스 선택:
- 관리형 관계형 데이터베이스 요구사항에는 Cloud SQL을 사용합니다. 자동 스토리지 증가를 활성화하고 코어당 CPU 사용률이 75%에 가까워지면 모니터링합니다. 복제 지연(replication lag)을 추적하고 임계값에 가까워지면 샤딩하거나 스케일업합니다.
- 지연 시간이 짧고 처리량이 높은 시계열 데이터 수집(예: 센서 데이터)에는 Bigtable을 사용합니다.
- 글로벌 확장성과 강력한 일관성이 필요할 때는 Spanner를 사용합니다. 특정 기술에 대한 종속성(lock-in)과 이식성(portability)의 장단점을 이해해야 합니다.
- 데이터 이동
- 지속적이거나 예약된 전송에는 Storage Transfer Service를 사용합니다. 병렬화 및 재시도 기능을 지원합니다.
- 네트워크 시간과 위험을 줄이기 위한 대량의 일회성 로드(수십~수백 TB)에는 Transfer Appliance를 사용합니다.
- 중소 규모 데이터 세트에는 gsutil 및 병렬 복합 업로드를 사용합니다.
온라인 vs 오프라인 마이그레이션
- 온라인: 짧은 컷오버 기간을 갖는 지속적인 복제 방식입니다. 장점: 다운타임 최소화, 단점: 안정적인 지연 시간과 대역폭이 필요하며, 이중 쓰기(dual-write)를 신중하게 방지해야 합니다.
- 오프라인: 스냅샷을 생성하고 대량으로 가져오는 방식입니다. 장점: 간단하고 예측 가능함, 단점: 다운타임이 복사 소요 시간과 동일합니다.
컷오버 계획, 롤백 및 다운타임 제어
- 컷오버 며칠 전에 DNS TTL 값을 낮추고, 필수적이지 않은 변경을 동결하며, 유지보수 기간을 예약합니다.
- 검증 단계를 실행합니다: 스키마 일치 여부, 체크섬 또는 행 수 확인, 애플리케이션 스모크 테스트, 카나리 트래픽, 성능 프로브.
- 롤백: 하위 호환성을 갖는 스키마 변경, 기능 플래그(feature flags), 원본 데이터(source-of-truth) 보존을 보장합니다. 안정성이 입증될 때까지 되돌릴 수 없는 쓰기 작업을 피합니다.
- 다운타임을 최소화하는 VM 디스크 확장 예시:
- 콘솔 또는 CLI에서 디스크 크기 조정:
undefined
- Linux ext4에서:
undefined
GKE에서 영향을 최소화하는 롤링 앱 업데이트:
undefined
일반적인 실패 유형: Cloud VPN을 통한 패킷 손실로 인한 데이터베이스 복제 중단(Dedicated Interconnect 또는 Partner Interconnect 사용), 컷오버 중 이중 쓰기(dual-write) 데이터 불일치, 상태 확인(health check) 누락으로 인한 롤링 업데이트 중단.
하이브리드 ID, 연결 및 온프레미스 통합
ID
- Active Directory를 신뢰할 수 있는 단일 소스(source of truth)로 유지합니다. 계정 및 그룹 동기화를 위해 Google Cloud Directory Sync를 사용하고, 사용자가 Google Cloud에 액세스할 수 있도록 SAML SSO를 구성합니다.
- 역할을 통해 최소 권한의 IAM을 부여하고, 워크로드에는 서비스 계정을 사용하며, 수명이 긴 키 대신 Workload Identity Federation을 사용하는 것을 선호합니다.
하이브리드 연결 및 라우팅
- 초기 낮은 처리량 요구사항 및 테스트에는 Cloud VPN을 사용하고, 지속적인 대역폭, 더 낮은 지연 시간, 예측 가능한 복제 성능이 필요하면 Dedicated Interconnect로 전환합니다. 복원력을 위해 이중화된 VLAN 연결과 HA VPN 또는 이중 인터커넥트를 배포합니다.
- 엔드투엔드(end-to-end) 연결성을 보장하기 위해 Google Cloud IP 범위가 온프레미스 CIDR과 겹치지 않도록 합니다.
방화벽 규칙과 태그를 사용하여 계층형 액세스를 강제합니다. 웹→API만 허용하는 예시:
undefined
공개 이그레스(public egress) 없이 서비스 간 통신을 위해 Private Service Connect 및 비공개 Google 액세스를 사용하고, 필요한 경우 VPC Service Controls로 분할합니다.
하이브리드 DNS: 전달(forwarding) 및 인바운드/아웃바운드 정책과 함께 Cloud DNS를 사용하여 온프레미스 및 클라우드 이름을 모두 확인(resolve)합니다.
온프레미스 통합 및 지연 시간
- 상태(state)를 컴퓨팅 리소스 가까이에 두거나 그 반대로 배치합니다. 온프레미스 DB가 계속 신뢰할 수 있는 소스여야 한다면, 비공개 액세스를 위해 Cloud VPN/Interconnect와 함께 App Engine 가변형 환경 또는 Compute Engine을 고려합니다.
- 동기식 경로를 분리하고 지연 시간 변동(jitter)을 흡수하기 위해 캐시와 큐를 도입합니다. 평균이 아닌 p95/p99 지연 시간을 측정합니다.
일반적인 실패 유형: 겹치는 CIDR로 인한 경로 차단, 불충분한 BGP 세션 이중화, 공개 DNS 또는 이그레스 유출로 인한 비공개 서비스 노출, 예상치 못한 채티(chatty) 프로토콜이 높은 지연 시간의 링크에서 성능 저하를 겪는 문제.
현대화, 운영 모델 및 최적화
레거시 현대화 패턴
- 스트랭글러 피그(Strangler fig): 모놀리스 앞에 API 퍼사드(facade)를 배치하고 점진적으로 도메인을 새로운 서비스로 라우팅합니다.
- 컨테이너화: 기본 이미지를 표준화하고(호환되는 경우 Alpine과 같은 슬림 이미지 선호), 소스 코드를 복사하기 전에 종속성 설치를 캐시하도록 Dockerfile 레이어 순서를 조정하여 빌드 시간을 단축하며, 스테이징 환경에서 자동화된 테스트를 포함하는 CI/CD 파이프라인을 채택합니다.
- 관리형 데이터: 운영 저장소를 관리형 데이터베이스로 이전합니다. 도메인별로 선택합니다: 트랜잭션 워크로드는 Cloud SQL, 시계열 데이터는 Bigtable, 전역적으로 일관된 워크로드는 Spanner를 사용합니다.
애플리케이션 호환성, 일관성 및 성능 검증
- OS 및 미들웨어 지원, 스레드 및 연결 제한, 파일 시스템 시맨틱을 확인합니다. 라이선스 이전 가능성 및 사용량 측정을 검증합니다.
- 데이터 일관성 요구사항(쓰기 후 읽기(read-your-write), 단조 읽기(monotonic reads), 최종적(eventual) 일관성 대 강력한(strong) 일관성)을 정의합니다. 이를 대상 데이터베이스 및 액세스 패턴에 맞게 조정합니다.
- 부하 테스트 및 합성 사용자 경험 시뮬레이션으로 성능을 검증합니다. 마이그레이션 후 SLO 예산을 달성할 수 있는지 확인합니다.
관측 가능성 및 규정 준수
- Cloud Logging, Monitoring, Trace로 애플리케이션을 계측하여 마이크로서비스 전반의 지연 시간을 파악합니다.
- 감사 로그 및 IAM 정책 변경 사항을 BigQuery로 내보내고, 뷰 및 데이터 세트에 대한 IAM을 통해 감사자와 공유합니다. 다년간의 보존 요구사항을 충족하기 위해 장기 지표를 Cloud Storage로 내보냅니다.
운영 모델 및 소유권
- SRE 프랙티스를 채택합니다: SLO, 오류 예산, 인시던트 대응, 비난 없는(blameless) 사후 분석. 서비스 소유권, 런북, 온콜 로테이션을 정의합니다.
- IaC(예: Terraform)를 사용하여 인프라를 일관되게 프로비저닝합니다. Deployment Manager는 Google에 특화되어 있어 멀티 클라우드 리소스 자동화를 제한할 수 있으며 많은 엔지니어에게 익숙하지 않다는 점을 인지해야 합니다.
- 조직 정책(Organization Policy), IAM Conditions, Config Sync, Policy Controller(OPA Gatekeeper)를 사용하여 프로젝트와 환경 전반에 걸쳐 정책 일관성을 자동화합니다.
멀티 클라우드 전략 및 종속성(lock-in) 절충
- Kubernetes, 12-factor 앱 프랙티스, OpenAPI로 정의된 계약, 데이터 송신(egress) 추상화를 통해 이식성을 높입니다. 이식성과 운영 부담 및 성능 사이의 균형을 맞춥니다. 관리형 서비스는 단순 반복 작업(toil)을 줄이지만 전환 비용을 증가시킬 수 있습니다.
비용 및 성능 최적화, 서비스 해제
- 관리형 인스턴스 그룹 및 자동 확장을 통해 상태 비저장 Compute Engine을 확장합니다. 0으로 확장(scale-to-zero)의 이점을 누릴 수 있는 폭증(bursty) 워크로드나 MVP 워크로드에는 서버리스(Cloud Functions 또는 Cloud Run)를 선택합니다.
- VM 크기를 적정하게 조정하고, GKE에서 자동 확장을 활성화하며, 약정 사용 할인을 적용하고, 사용하지 않는 아티팩트를 서비스 해제합니다. KPI(가용성, 지연 시간, 서비스 제공 비용)를 통해 혜택 실현을 추적합니다.
- 안정화 기간(cooling period)과 종속성 확인 후 온프레미스 시스템을 서비스 해제합니다. 보존 정책에 따라 데이터를 보관하거나 삭제하고 CMDB를 업데이트합니다.
실용적인 문제 시나리오
Acme Weather Networks는 실시간 센서 플랫폼과 레거시 J2EE 관리 UI를 온프레미스 데이터 센터에서 Google Cloud로 마이그레이션해야 합니다. 이 시스템은 초당 10개의 측정값을 보내는 50,000개의 센서로부터 데이터를 수집하고 5년간의 과거 데이터(75TB)를 저장합니다. 전환 기간 동안 온프레미스 ERP 및 Active Directory에 대한 비공개 액세스를 유지해야 하며, 온프레미스 MySQL 데이터베이스의 다운타임을 최소화하고, VPN을 통해 관찰되던 간헐적인 복제 실패를 제거해야 합니다.
안전한 랜딩 존 구축
- 조직, 폴더, 프로덕션/비프로덕션 프로젝트를 생성합니다. 하이브리드 연결을 통해 온프레미스에 연결할 수 있도록 겹치지 않는 IP 범위를 가진 공유 VPC(Shared VPC)를 설정합니다. 조직 정책과 중앙 집중식 감사 로그를 BigQuery로 내보내는 설정을 최소 권한 액세스로 적용합니다.
- 근거: 워크로드가 배포되기 전에 라우팅 충돌을 방지하고 기본 거버넌스를 강제합니다.
하이브리드 ID 구현
- Google Cloud Directory Sync를 구성하여 AD ID와 그룹을 미러링하고 SAML SSO를 설정합니다. 플랫폼과 워크로드에는 서비스 계정과 IAM 커스텀 역할을 사용합니다.
- 근거: 기업 ID를 신뢰할 수 있는 단일 소스(source of truth)로 유지하고 최소 권한 액세스 제어를 가능하게 합니다.
연결성 프로비저닝 및 성능 계획
- 개발/테스트용으로 HA Cloud VPN으로 시작합니다. 프로덕션 데이터베이스 복제 및 안정적인 센서 데이터 수집을 위해 이중 VLAN 연결 및 BGP 세션을 갖춘 Dedicated Interconnect를 프로비저닝합니다.
- 근거: Interconnect는 VPN보다 지연 시간이 짧고 패킷 손실이 적어 MySQL 복제 및 스트리밍 데이터 수집을 안정화합니다.
과거 데이터 효율적으로 이전
- Transfer Appliance를 주문하고, 온프레미스에서 75TB 데이터 세트를 로드한 후, 배송하여 Cloud Storage로 재구성합니다. 필요한 경우 지속적인 증분 업데이트를 위해 Storage Transfer Service를 사용합니다. Bigtable 또는 BigQuery에 저장하기 전에 지원 로그에 Cloud DLP를 실행하여 개인 식별 정보(PII)를 비식별화합니다.
- 근거: 오프라인 대량 전송은 컷오버 기간의 위험을 줄이고 회선 포화를 방지합니다.
J2EE 관리 UI 리호스팅
- Migrate to Virtual Machines를 사용하여 J2EE VM을 Compute Engine으로 리프트 앤 시프트(lift-and-shift)합니다. 인스턴스를 HTTP(S) 부하 분산기 뒤의 관리형 인스턴스 그룹에 배치합니다. 태그를 사용하여 방화벽 규칙을 적용하여 웹→API→DB 흐름만 허용하도록 강제합니다. 예:
- gcloud compute firewall-rules create allow-web-to-api –network=prod-vpc –direction=INGRESS –action=ALLOW –rules=tcp:8443 –source-tags=web –target-tags=api
- 근거: 익숙한 런타임으로 신속하게 위험을 줄이면서 최소 권한 네트워크 경로를 강제합니다.
- Migrate to Virtual Machines를 사용하여 J2EE VM을 Compute Engine으로 리프트 앤 시프트(lift-and-shift)합니다. 인스턴스를 HTTP(S) 부하 분산기 뒤의 관리형 인스턴스 그룹에 배치합니다. 태그를 사용하여 방화벽 규칙을 적용하여 웹→API→DB 흐름만 허용하도록 강제합니다. 예:
최소한의 다운타임으로 MySQL을 Cloud SQL로 마이그레이션
- 소스에서 성능을 기준 측정하고 바이너리 로깅을 활성화합니다. Database Migration Service를 사용하여 Cloud SQL로의 지속적인 복제를 설정합니다. 자동 스토리지 증가를 활성화하고 CPU가 75%에 근접하고 복제 지연이 60초 미만일 때 알림을 생성합니다.
- 근거: 온라인 마이그레이션은 다운타임을 최소화하고, 관리형 SQL은 단순 반복 작업을 줄이고 운영 SLO를 강제합니다.
통제된 컷오버 실행
- 48시간 전에 DNS TTL을 낮추고, 스키마 변경을 동결하며, 유지보수 기간을 예약합니다. 온프레미스에서 쓰기를 중지하고, DMS 지연이 0인지 확인하고, 체크섬 및 애플리케이션 스모크 테스트를 실행한 다음, 클라이언트가 Cloud SQL을 가리키도록 합니다. 검증에 실패할 경우 쓰기를 다시 온프레미스로 리디렉션할 수 있는 롤백 계획을 유지합니다.
- 근거: 결정론적인 단계는 RTO를 제한하고 데이터 일관성을 유지합니다.
실시간 원격 측정 데이터 수집 시스템 구축
- Pub/Sub를 통해 데이터를 수집하고, Dataflow로 처리하며, 시계열 데이터를 Bigtable에 저장하여 낮은 쓰기 및 읽기 지연 시간을 확보합니다. ERP 통합은 Interconnect를 통해 비공개로 유지합니다.
- 근거: Bigtable은 처리량이 높은 시계열 데이터 프로필에 적합하며, Pub/Sub는 폭증하는 생산자와 소비자를 분리합니다.
서비스 컨테이너화 및 CI/CD 도입
- GKE용으로 상태 비저장 서비스를 컨테이너화합니다. 슬림 기본 이미지를 사용하고 종속성 설치가 소스 복사보다 먼저 오도록 레이어 순서를 정하여 Dockerfile을 최적화합니다. 스테이징에서 자동화된 테스트와 카나리 배포를 포함하는 CI/CD 파이프라인을 구현합니다. 최소한의 다운타임으로 업데이트합니다:
- kubectl set image deployment/ingester ingester=gcr.io/acme/ingester:v2
- 근거: 빅뱅 방식의 재작성 없이 배포 속도, 안정성, 확장성을 향상시킵니다.
- GKE용으로 상태 비저장 서비스를 컨테이너화합니다. 슬림 기본 이미지를 사용하고 종속성 설치가 소스 복사보다 먼저 오도록 레이어 순서를 정하여 Dockerfile을 최적화합니다. 스테이징에서 자동화된 테스트와 카나리 배포를 포함하는 CI/CD 파이프라인을 구현합니다. 최소한의 다운타임으로 업데이트합니다:
관측 가능성 및 감사 기능 향상
- Cloud Logging, Monitoring, Trace를 계측하여 마이크로서비스 전반의 지연 시간을 정확히 찾아냅니다. 감사 로그를 BigQuery로 내보내고 감사자 범위의 뷰를 공유합니다. 5년 보존 요구사항을 충족하기 위해 장기 지표를 Cloud Storage로 내보냅니다.
- 근거: 완전한 충실도의 원격 측정 데이터는 SLO 및 규정 준수를 지원합니다.
최적화 및 서비스 해제
- MIG 및 GKE에서 자동 확장을 활성화하고, 인스턴스 크기를 적정하게 조정하며, 약정 사용 할인을 적용하고, 24x7이 아닌 워크로드(예: 보조 작업을 위한 Cloud Functions)를 서버리스에서 실행하여 0으로 확장(scale-to-zero)합니다. 안정성과 안정화 기간(cooling period)이 지난 후, 온프레미스 시스템을 서비스 해제하고, CMDB를 업데이트하며, 실현된 혜택을 공표합니다.
- 근거: 이중 운영 비용을 제거하면서 비용 및 운영 효율성을 확보합니다.
운영화 및 교육
- 런북, RACI, 온콜 로테이션, SLO/오류 예산을 최종 확정합니다. 기술 격차를 해소하기 위해 목표에 맞는 교육 및 인증 계획을 제공합니다. IaC에는 Terraform을 선호합니다. Deployment Manager는 Google에 특화되어 있어 Google 이외의 리소스를 처리하지 못할 수 있음을 유의합니다.
- 근거: 성숙한 운영 모델은 마이그레이션 이벤트 이후에도 안정성과 속도를 유지합니다.
이 문제 연습하기 → · ExamRoll.io에서 시간 제한 연습 →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
시험 합격하기 →