Daily Record

GCP - Professional Cloud Architect 후기

51 min read

certificate image

시험 정보

  • 준비기간 :
    • 연휴 중 6~7일 을 집중적으로 투자했다.
    • 학부생 때 GCP StaudyJam 등 접한 경험이 있었고, 이후 AWS 와 Kubernetes 에 대한 기초 지식은 있는 상태였다.
    • 만약 본인이 AWS, Kubernetes, 그외 기본적인 네트워크 지식이 있다면 길게 잡으면 한달이면 충분히 준비할 수 있다.
  • 시험 등록 :
  • 시험장소 :
    • online / offline 중 하나를 택하면 되며, 나는 강남구의 SRTC 에서 offline 으로 시험을 봤다.
  • 시험시간 : 120분
  • 언어 : English (한국어 지원 X)
  • 문항 수 : 60문항
  • 통과 점수 : 정확한 근거는 없으나 80% 이상을 커트라인으로 잡고 공부하면 된다.
  • 문제 유형 :
    • 단답형(multi-choice, 둥근박스)
    • 다답형(multi-select, 네모 박스)
    • Case Studies
      • EHR Healthcare : 규모 확장중인 헬스케어 SW 회사.
      • Helicopter Racing : 헬리콥터 경주 리그(HRL) 에서 성능/AI/ML 병합하고자 함
      • Mountkirk Games : 모바일 플랫폼용 게임으로 GKE 로 성능최적화 해서 배포하고자 함
      • TerramEarth : 중장비 제조업체로, 실시간으로 데이터 수집하고자 함.
  • 결과 : 즉시 Pass 여부 확인 가능하며, ~10일 이내로 결과가 도착한다. 나는 바로 다음날 합격 메일이 도착했다.

시험 Tips

  • 소거법을 사용한다.
  • 구글에서 recommended 로 추천하는 보기가 정답일 확률이 높다.
  • 권한 관련 문제에서는 항상 최소 권한으로! (granular Access Control Lists (ACLs))
  • PII(개인 식별 정보) 는 거의 대부분 Cloud DLP 필수 적용
  • Regulation 등 꼼꼼히 읽고, data residency 등 특정 지역에 데이터가 보관되어야 하는 지 확인해야 함.
  • preemptible(선점형) 의 ‘선점’ 은 유저가 아닌 GCP 관점이다. 선점 권한이 GCP에 있어 회수당할 수 있고 종료될 수 있지만 저렴하다.
  • 수동(manually) 처리는 오답인 경우가 많고 지문을 꼼꼼하게 살펴야 한다.

참고 레퍼런스

시험 덤프

추가로, 아래에는 이번 시험을 준비하면서 도움이 되었던 내용들을 정리해보았다.

기초 개념

Global > Regional > Zonal 범위의 구분

  • Global Service : VPC, Images
  • Regional Service : App Engine(지역 배포, zone 에 복제), Managed Instance Group
  • Zonal Service : Instance(VM), Persistent Disk)

Resource Hierarchy

  • Organization(기업) > Folders(부서, Optional) > Projects(부서&팀, Must) > Resources
  • billing은 project 단위로 생성된다.

SRE(Site Reliability Engineering) 개념

  • SLI (Service Level Indicator) : 서비스 성능을 측정하는 실제 지표, measure(예: “측정결과 성공적인 요청 비율 = 99.95%”)
  • SLO (Service Level Objective) : 그 지표가 달성해야 하는 목표값, threshold 정의(예: “99.9% 이상의 가용성을 유지해야 함”)
  • SLA (Service Level Agreement) : SLO를 기반으로 고객과 체결하는 계약 문서, promise(예: “가용성 99.9% 미달 시 환불”)

Cost

  • 부과 단위
    • Per Resource
    • Per Consumptions
    • Reservations
  • 가격 추정치 계산기
  • Budgets & Alerts : 실제 비용 지출을 막지 않음. 모니터링과 알람만 함

주요 개념

Compute Engine

  • 개념 : OS, Kernel, file 등 full control이 필요한 경우, On-premise 에서 마이그레이션 하고 싶은 경우

  • 종류 :

    • General Purpose : web, microservice, virtual desktops, database
      • E2 : Low traffic web server, back office apps, virtual desktops
      • N2,N2D,N1 : medium traffic web server, microservice, BI
      • C3 : High traffic web server, database, in-memory cache
      • TAU T2D, T2A : ARM architecture, Cost effective
    • Compute Optimized : HPC(high performance computing, game, media)
      • H3 : HPC
      • C2, C2D : gaming, media, model serving
    • Memory Optimized : SAP HANA databases, in-memory like redis
      • M1, M2, M3 : memory intensive
    • Accelerator Optimized : ML Training
      • A2, A3 : HPC, ML Traning
      • G2 : Video Transforming
    • GPU(엔비디아 기반)
      • A2, G2 시리즈는 GPU 지원을 위해 만들어 졌고 추후 별도로 추가할 필요없음
      • N1 머신들에도 GPU 추가 가능
    • Custom Machines
      • E2, N2, N2D, N1

  • 특징 :

    • VM instance는 zonal service 이다. (regional service 가 아님)

  • VM 비용 절약 :

    • scheduled shutdown : 테스트나 개발 목적으로 24시간 내내 실행할 필요가 없는 경우
    • spot instances : 배치나 분석처럼 일회성으로 사용하기 좋고 비용을 91% 까지 절감할 수 있다. (무료계정 불가)
    • committed use discounts : 사용량과는 별개로 처음 계약한 비용으로 기간 임대가 가능하다.
    • 비용을 줄이려면 VM은 꺼 두고(Instance Schedule), 데이터는 남겨둔다(Persistent Disk).
    • disk types : local SSD, Persistent → N1 등에서 지원함
      • Local SSD : 물리적으로 다이렉트로 연결된 SSD
        • 성능이 좋고, 임시 데이터 저장에 좋음 (단, shutdown 시 데이터 사라짐)
        • SIZE 는 항상 375GB
        • VM당 여러개의 local SSD를 붙일 수 있다.
      • Persistent Disk(PD) : 네트워크로 연결된 디스크
        • 지속가능한 네트워크 SSD, Zonal or Regional 이다.
        • VM으로부터 제거되거나 이동될 수 있다.
        • disk capacity를 늘리는 것 만으로 성능개선(throughput, IOPS) 이 있다.
        • 종류 : 아래로 내려갈 수록 성능이 좋다.
          • pd-standard : HDD
          • pd-balanced : SSD
          • pd-ssd
          • Hyperdisk Balanced : SSD (single digit ms latency 목적)
          • Hyperdisk Extreme : SSD (타겟 IOPS 설정 가능)
    • Sole Tenancy : 노드 전체를 단일 호스트가 임대 (고비용)
      • To create a VM instance that uses the custom BYOL image, you must provision the VM instance on a sole-tenant node. (자기 고유 라이센스에는 sole-tenant 가 필수이다.)
    • Instance Template
      • Snapshot → 디스크용, 다른 zone 으로 복제 뜰 때 가장 쉬운 방법
        • Standard
        • Archive
        • Instant
      • Images → 풀 머신용
        • cloud storage bucket 에 저장됨
        • local SSD 데이터는 포함되지 않음
        • name, ip address 는 포함하지 않음
        • types
          • machine images
          • disk images
        • machine images 로 부터 동일한 인스턴스를 추가 생성할 수 있음.

  • Instance Group

    • single instance 로 처리하기 힘들 때, multi-zone으로 Instance Group 생성하여 부하를 분산시켜줄 수 있다.
    • 종류 :
      • managed instance group (MIG):
        • webapp, database, batch, 고가용성, 확장성, 자동 업데이트 제공
        • identically-configured, (동일 설정) 인 경우
        • 업데이트 방법
          • Rolling Update (Proactive) : 모든 인스턴스를 순차적으로 교체하여 새로운 템플릿 적용
          • Rolling Update (Opportunistic) : 새로 생성되는 인스턴스만 새 템플릿 사용, 기존 인스턴스는 그대로 유지
        • Cloud Run 보다는 비용이 비싸다.
        • MIG 는 정지하는 등 제어를 할 수 없다.
      • unmanaged instance group :
        • heterogeneous(이종) workloads 인 경우나 개별 instance 관리가 필요한 경우
        • non-identical configurations, 서로 다른 설정으로 구성된 경우
    • 생성 절차 :
      • disk 정의 → disk image 정의 → instance template using image 정의 → managed instance group 정의

  • vm manager

    • os patch management
    • os inventory management
    • os configuration management

App Engine

  • 개념 : Google Cloud의 완전관리형 PaaS로, 코드를 올리면 인스턴스 관리·오토스케일·보안 패치·로깅/모니터링까지 구글이 대신 해준다.
  • 특징 :
    • 프로젝트당 하나의 앱 엔진만 사용이 가능하다.
    • 단일 리전에만 배포된다. 따라서 리전 옮기려면 새로 만들어서 배포해야 한다.
    • 멀티 버전을 가질 수 있다. → 동일 어플리케이션에서 버전/리비전 간 트래픽 스플리팅(퍼센트 배분)을 지원한다.
    • App Engine 은 예외적으로 VPC 안에 배포되지 않고 자체 네트워크에 생성된다.
  • 타입 : Standard vs Flexible
    • Standard (저비용)
      • 경량 샌드박스로 특정 언어만 지원하며 수초 단위 startup, scaling이 빠르고 이전 버전 즉시 복원 가능
      • 0개 인스턴스로 스케일링 될 수 있다. (Scale to Zero)
      • WebSocket 을 지원하지 않는다.
      • 백그라운드 프로세스 불가능함.
      • Instance 실행시간에 비례해 비용 발생한다.
      • Serverless 환경으로 전용 네트워크 경로로 온프레미스와 통신할 수 없다.
      • platform : python java 등
      • autoscaling support
        • automatic : minimun number of instances
        • basic : based on received requests
        • manual : manually specify
    • Flexible (고비용)
      • run docker container on regional MIG
      • 시작과 스케일링에 수분 정도 시간이 걸린다. (spike traffic 에는 부적합하다.)
      • 백그라운드 배치 프로세스를 실행한다.
      • Minimum 1개 인스턴스는 떠있게된다.
      • WebSocket 지원하고 vCPU, Memory에 근거한 비용을 청구한다.
      • 장시간 최대 60분의 타임아웃을 지원한다.
      • platform : 언어 제한 없음
      • autoscailing support
        • automatic
        • manual
  • scheduling app engine
    • cron job
    • cloud scheduler

Cloud Build

  • 개념 : gcp ci/cd 서비스
  • 특징 :
    • app engine, cloud run, GKE, cloud functions, firebase 등 연계
    • version
      • 버전 간 트래픽 경로를 틀어 점진적인 업데이트에 활용할 수 있다.
      • split traffic (아래 값에 따라)
        • ip
        • cookie
        • random
  • deployment strategy
    • basic : 한번에 새로운 버전으로 전부 넘어가는 것
    • rolling: 인스턴스를 재기동해가면서 점진적인 배포 (zero 다운타임)
    • blue-green : 새로운 버전에는 테스터만 접근 가능하도록 하고, 확인이 끝난 이후 한번에 바꾼다. (롤백이 빠르고, 다운타임 최소)
    • canary : 테스터가 오류를 찾지 않는 한 점진적으로 배포한다. (운영에서 최소한의 위험으로 새 기능 도입)

Working with containers

  • 중요 원칙 :
    • Privileged 컨테이너 회피(privileged는 컨테이너 탈주·노드 권한 상승 리스크 → 최소 권한 원칙 준수.)
    • 컨테이너 모니터링 필수
    • 네이티브 로깅(플랫폼(GCP/GKE)에서 기본으로 제공·통합되는 로깅) 사용

Cloud Run

  • autoscailing, microservice 배포도 지원한다. (GKE에 비해 관리요소가 훨씬 줄어듦)
  • 버전/리비전 간 트래픽 스플리팅(퍼센트 배분)을 지원
  • public, private
  • services, job(배치) 둘 다 지원하나 스트리밍에 적합하지 않음
  • cpu allocation 정책
    • only during requests (default) → 백그라운드 실행이 필요한 경우
    • always allocated
  • 배포방식 :
    • ide → artifact registry → cloud run
    • ide → artifact registry(cloud-run-source-deploy 고정 생성) → cloud run (deploy from source)

Google Kubernetes Engine(GKE)

  • 개념 : Google Cloud Platform(GCP) 위에서 동작하는 완전관리형 Kubernetes 서비스
  • 구성요소 :
    • Control Plane, Node, Pod, Deployment / Service, Ingress(LB와 연결되어 외부 트래픽 처리)
    • Anthos : 중앙 집중화된, 다중 GKE cluster 관리
      • Istio : service mesh that provides traffic management, policy enforcement, and telemetry collection
    • DaemonSet : 로깅, 모니터링용
  • 특징 :
    • autoscaling, platform management, security, auto-repair 지원
    • preemptible VM(싸지만 언제든지 꺼질 수 있는 임시 서버), non-preemptible VM 지원
    • gcloud container clusters resize 커맨드로 gracefully draining
    • service type
      • clusterIP : 내부 IP 주소에만 노출
      • NodePort: 각 노드 IP를 노출
      • LoadBalancer : 외부 IP 노출
    • types
      • standard
      • enterprise : multi-cluster deployments, anthos
    • modes
      • standard : 노드(VM) 직접 관리 (머신 타입, OS, 업그레이드, 스케일링 등)
      • autopilot(recommended)
  • 보안 :
    • Use Binary Authorization : 컨테이너 이미지의 “서명(Signature)”을 검증해서, 신뢰된 이미지만 GKE에 배포되도록 강제
    • Workload Identity : GKE Pod(쿠버네티스 서비스 계정) 를 Google Cloud 서비스 계정(GCP IAM) 과 안전하게 연결(mapping)
    • SSH 대신 kubectl 사용

Artifact Registry vs Container Registry

  • Artifact Registry(AR) 는 GCP의 차세대 레지스트리로, 컨테이너 이미지, language & OS package 까지 단일 제어면으로 관리
  • Container Registry(GCR) 는 예전 세대의 컨테이너 이미지 전용 레지스트리로 더이상 사용을 권장하지 않음

Cloud Functions

  • serverless 이며 단일 목적의 간단한 함수를 실행하는 비용효율적인 함수
  • versions
    • v1 : 동시 1개요청, traffic split 안됨
    • v2 : 16GB/4vCPU 지원, eventarc, revommended
  • cold start
    • 최소 실행 instance 를 보장해서 새로 instance를 띄우는 시간을 아낀다.
  • flow
    • ide → cloud functions 에 업로드 → Cloud Storage (GCS) 에 코드 저장 → Cloud Build 에 이미지 생성 → Artifact Registry / Container Registry 에 코드 저장 → Cloud Run (managed) 에 배포
  • 오답노트
    • 내부 동작은 cloud functions 에 업로드 → Cloud Storage (GCS) 에 코드 저장 → Cloud Build 에 이미지 생성 → Artifact Registry / Container Registry 에 코드 저장 → Cloud Run (managed) 에 배포 순이다.

[ Networking ]

  • VPC(글로벌 단위)

    • 가상 사설 클라우드.
    • 클라우드 리소스를 배포할 수 있는 클라우드이며, 논리적으로 네트워크가 분리되어 있음
    • VPC 내부에서는 서로 문제없이 통신 할 수 있음.
    • peering 없이는 다른 VPC 간에는 통신할 수 없음
    • 최대 15개 까지는 무료
    • 특징
      • 클로벌이다. 서도 다른 리전간 통신 가능
      • 기본적으로 생성됨
      • peering으로 연결되고
      • subnet으로 분할된다.
      • app engine 은 예외적으로 VPC 안에 배포되지 않고 자체 네트워크에 생성된다.
      • VPC 방화벽은 L3/L4(IP/포트/프로토콜) 제어 수준이다.
    • VPC Network Peering
      • 다른 VPC 간 통신하기 위한 방법
      • 보안을 위해 별도 VPC 에 배포한 리소스와 통신하기 위한 방법
      • 사용자 관점에서는 단일 VPC 로 보이게 하며, 주소가 겹치면 안된다.
      • 방화벽 규칙을 적용해야 한다. (기본적으로 VPC는 in/out 트래픽을 막기 때문에)
    • Shared VPC
      • Organization 단위의 하위에 프로젝트가 있다.
      • 여러 프로젝트(Project)가 보안 목적으로 하나의 중앙 VPC 네트워크를 공유해서 사용하는 구조
      • 최소 비용으로 최대 효율을 내기 위해 조직 내의 여러 프로젝트에서 공유하는 VPC (무료계정은 없고, 조직이 있어야 사용 가능하다.)
      • 네트워크를 중앙 집중 관리
      • 구조
        • Host Project (네트워크를 실제로 보유하고 관리하는 프로젝트)
        • Service Project (해당 네트워크를 “빌려 쓰는” 프로젝트 (VM, GKE 등 리소스를 띄움))
    • VPC Service Controls(Service Perimeter)
      • 민감한 데이터가 GCP 경계 밖(또는 다른 리전, 다른 프로젝트)으로 빠져나가는 걸 방지
      • Service Perimeter 내 리소스 간 접근은 허용하지만 외부(다른 프로젝트, 리전, 인터넷 등) 접근은 차단.

  • Secure VM Access 강화하기

    • Firewal Rules : 필요한 소스 IP 에서만 접근 가능하도록 제한
    • VPN : VPC 로 접근하는 보안 터널. VPN software, license 필요하다.
    • Jump Box : VPC에 외부 접속을 허용하는 VM을 만들어서 연결하고자 하는 VM 과 연결한다. 그래서 단일 IP 만 열어둔다.

  • Secure Access from On Premises

    • 온프램과 클라우드가 안전하게 상호 통신하는 방법
      • Cloud VPN (Virtual Private Network) : 온프레미스 네트워크(회사 내부망)와 Google Cloud VPC 네트워크를 암호화된 IPsec 터널로 연결
        • HA VPN (High Availability VPN) : 고가용성(2개 터널, SLA 99.99%) 제공
        • Cloud Interconnect 에 비해 비용효율적이다.
        • Cloud VPN은 IP 겹침이 일부 있어도 NAT 설정으로 트래픽 분리 가능.
      • Cloud Interconnect : direct physical connection
        • Direct Interconnect Type : 100Gbig/s, 하지만 비쌈, 물리 하드웨어 장비 필요함
        • Partner Interconnect Type : 비용효율적임, 물리 하드웨어 장비 필요없음
        • 여러 connections 로 HA 확보 가능
        • 비용이 부담된다면 Cloud VPN 으로 bridge 를 생성한다.
    • redundant network connection 으로 견고함을 확보한다.

  • Private Access

    • VPC : vm instance, GKE, App Engine Flexible

    • Not in VPC : App Engine Standard, Cloud Functions, Cloud Run, Cloud Storage, Cloud SQL, BigTable

    • 기본적으로 VPC 사용하는 리소스와 VPC 사용하지 않는 리소스 간 통신은 공용 인터넷 망을 사용하게 된다. 하지만 그러면 보안상 취약하게 된다.

    • Private Access 는 공용망을 사용하지 않고, Private Access (사설 IP) 를 통해 접근한다.

    • Types

      • Private Google Access (PGA) : 외부 IP 없는 VM이여도 퍼블릭 Google API에 나갈 수 있게 하는 기능(사설 경로로 공인 엔드포인트 접근)
        • 의도: 외부 IP가 없는 VM 이라도 *.googleapis.com 같은 공인 Google API를 VPC 내부 경로로 접근 가능하게. (NAT 게이트웨이 없어도 됨)
        • 트래픽 경로: 내 VM(사설 IP) → VPC 내부 경로 → 공인 Google API VIP → 목적지는 공인 IP이며, 사설 IP로 노출되지 않음.
      • Private Service Connect (PSC): 엔드포인트(프록시) 기반. 내 VPC에 사설 엔드포인트를 만들고 거기로 Google API/3rd-party/내 서비스에 프라이빗 접속.
        • 의도: 내 VPC 서브넷에 사설 엔드포인트(ILB/Forwarding Rule) 를 만들고, 그 엔드포인트로 트래픽만 주면 뒤에서 Google API/프로듀서 서비스로 프라이빗 프록시. - 트래픽 경로: 내 VM → 내 VPC의 PSC 엔드포인트(사설 IP) → Google/타사/내 서비스의 서비스 어태치먼트
        • 예: Google API 사설 엔드포인트(GCS, BigQuery, Pub/Sub, Vertex 등), Cloud SQL / Memorystore의 Private IP(최신 구현)
      • Private Service Access (PSA): VPC 피어링 기반. Google이 운영하는 관리형 서비스에 사설 IP로 직접 붙고 싶을 때.
        • 의도: 내 VPC에서 실제 사설 IP로 보이는 Google-managed 리소스에 붙기. (내 서브넷처럼 보이는 전용 대역을 할당하고, Google 쪽 프로듀서 VPC와 VPC 피어링을 맺음)
        • 트래픽 경로: 내 VM(10.x) → 피어링 → 서비스(사설 IP)
        • 예: Cloud Spanner(Private IP) 등.

    • 고르는 방법

      • VPC 에 호스트 되었나 ? → private service access
      • VPC host 아니고, public ip 있나? → private service access
      • VPC host 아니고, public ip 없나? -? private google access

    • Serverless VPC Access

      • 예를들어 VPC 안쓰는 서비스에서 VPC 내부와 통신하기를 바란다면 공용망을 사용하겠지만 이건 보안상 위험하다.
      • serverless service 에서 vpc 내부 private ip 통해 접속한다.
      • Cloud Run, Cloud Functions , App Engine Standard 등이 사용한다.
      • 이 견결을 위한 최소 단위의 Connector 가 생성된다.

    • 암기 포인트

      • PGA : 공인 IP없는 Private IP VM이 Google API(Cloud Storage, BigQuery) 접근할 수 있게. → Private IP
      • PSA : VPC가 Cloud SQL 등 Managed Service(Cloud SQL, Memorystore, AI Platform, AlloyDB) 와 사설 통신. → VPC + Managed Service
      • PSC : VPC가 Private Endpoint로 타 프로젝트·파트너 서비스 접근. → VPC + Other Partner Service
      • Serverless VPC Access : Serverless(Cloud Run / App Engine / Cloud Functions) → Serverless
                         ┌────────────────────────────────────────────┐
                         │                Google Cloud                │
                         │────────────────────────────────────────────│
                         │                                            │
                         │   ┌────────────────────────────┐           │
                         │   │     Google API & Services  │◄──────────┤
                         │   │ (BigQuery, Cloud Storage,  │   ▲       │
                         │   │  Pub/Sub, Secret Manager…) │   │       │
                         │   └────────────────────────────┘   │       │
                         │                 ▲                  │       │
                         │                 │                  │       │
                         │                 │  [1️⃣ Private Google Access]  
                         │                 │                  │
                         │                 │                  │
┌────────────────────────┴─────────────────┴──────────────────┴────────┐
│                         VPC Network                                  │
│──────────────────────────────────────────────────────────────────────│
│                                                                      │
│   ┌────────────────────┐    ┌────────────────────┐                   │
│   │  VM (Private IP)   │    │ Cloud Run /        │                   │
│   │  (no external IP)  │    │ Cloud Functions    │                   │
│   │                    │    │ (Serverless App)   │                   │
│   └──────┬─────────────┘    └──────┬─────────────┘                   │
│          │                          │                                │
│          │                          │                                │
│          │                          │ [4️⃣ Serverless VPC Access]     │
│          │                          │                                │
│          ▼                          ▼                                │
│   ┌────────────────────┐    ┌────────────────────┐                   │
│   │ Cloud SQL (Private │    │ Memorystore,       │                   │
│   │  IP via PSA)       │    │ AI Platform, etc.  │                   │
│   └─────────┬──────────┘    └─────────┬──────────┘                   │
│             │                         │                              │
│     [2️⃣ Private Service Access]  (Service Networking)                │
│                                                                      │
│   ┌────────────────────┐                                             │
│   │ Private Endpoint   │◄────────────────────────────────────────────┤
│   │ (PSC)              │    [3️⃣ Private Service Connect]             │
│   │ External Partner / │                                             │
│   │ Other Project API  │                                             │
│   └────────────────────┘                                             │
│                                                                      │
└──────────────────────────────────────────────────────────────────────┘
  • Subnets(리전 단위)
    • VPC의 논리 세그먼트이며 고유 IP 범위가 있다.
    • 같은 VPC 내에 새로운 Subnet 추가만으로 서로 private ip 로 통신 가능, 리전 확장 가능 (VPC Peering 추가 필요 없음)
    • 필수적인 항목이다. (subnet 없이 VPC에 바로 리소스를 둘 수 없음)
    • creation mode
      • auto mode (default) : 자동으로 생성되고 IP 가 분배된다. 10.128.0.0/9 *CIDR block.
      • custom mode (production recommended)
    • CIDR 표기법
      • IP 범위를 나타내는 표기법
      • X.X.X.X/주소범위
      • 예: 주소범위가 24면 24가 address, 남은 8이 range
  • Firewall
    • default 로 22, 3389, icmp 프로토콜만 허용한다.
    • 신규 VPC는 모든것을 차단한다.
    • App Engine 에서도 FireRule 이 있다.
      • 특정 범위 IP 제한, 허용 가능하다.
  • Load-Balancers
    • cloud load balancing : Transport, Application Layer 에서 동작함
    • distribution algorithm
      • based on 5 tuple hash(src ip, src port, dst ip, dst port, protocal)
      • backend utilization, weight
    • 백엔드 서버들을 외부로 다이렉트로 노출시키지 않는다
    • IP Addresses 에서 external static ip 할당받은 뒤 이걸 load balancer 서비스에서 사용하는 방식으로 사용한다.
    • Network Endpoint group(LB 가 라우팅할 트래픽 그루핑) 을 생성하고, 이를 load-balancer 에 연결한다.
    • factors
      • Traffic type
        • HTTP/S : Application LB (layer 7), can route based on http path, proximity-based(LB에 도착할때는 암호화, 백엔드로 갈때는 평문)
        • TCP : Network LB (layer 4), proxy based
        • TCP, UDP, ICMP : Passthrough LB (multiple protocals), 종료 없이 백엔드 경로로 라우팅 되게 됨.
      • external or internal
        • external : 외부 트래픽 유입
        • internal : VPC 내부에서 유입
      • deployment mode
        • global : 전 리전에 배포, DR 시나리오에 적절 (external 만 제공)
        • cross-region : 여러 리전에 배포 (internal 만 제공)
        • regional : 단일 리전(멀티 존) 에 설치됨
    • types
      • Application LB : (global & regional) external / (regional, cross-regional) interal
      • Proxy Network LB : (global & regional) external / regional internal
      • Passthrough Network LB : regional external / regional internal
    • routing strategy
      • Proximity-based routing : 클라이언트와 가장 가까운(지연이 가장 낮은) 리전에 트래픽을 라우팅
      • Capacity-based routing : 가까운 리전이 포화 상태이면, 여유가 있는 다른 리전으로 분산
      • Geo-based routing (Geolocation) : 클라이언트의 지역(국가/IP)에 따라 지정된 리전으로 트래픽 전달
      • Weighted routing : 특정 비율로 트래픽을 나눠 전송 (예: 70% US, 30% EU)
      • Failover routing : 주 리전이 비정상일 때만 다른 리전으로 전환
    • App Engine 은 고유 LB를 가지고 있다. 다만 CDN 통합 등 특정 기능은 없으므로 LB 가 필요할 때도 있다.
    • Affinity → stateless pattern을 지향해야 하므로 설정은 안한다.
    • Hub and Spoke

[ Data Store Services ]

Cloud SQL
  • 완전 관리형 RDBMS
  • regional, 기본적으로 다른 zone 에 HA 구성으로 standby 띄워줌
  • SQL server, MySQL, Postgresql
  • 백업 방안
    • Binary logging (binary log를 이용해 복구 시점(point-in-time recovery, PITR))
    • Automated backups
  • automatically Encryption - (AES-256) algorithm
  • enterprise, enterprise plus(mysql, postgresql)
  • NOT designed for large-scale analytics (→ BigQuery)
  • price
    • edition, vCPU used
  • 보안
    • private service access 사용한다.
  • App engine 과 Cloud cloud sql 연결하기
    • Cloud SQL private ip 와 동일한 VPC 내에 있어야 한다.
AlloyDB
  • 완전 관리형 PostgreSQL, extreamly fast
  • regional database
  • built in generative ai
  • cloud SQL 보다 비쌈
  • instance type
    • primary : read/write accress, standby 가질 수 있음. primary 기반으로 요청 허용 수치 결정
    • read pool : read datta 허용함 (read only)
  • backup
  • AlloyDB omni : AlloyDB의 downloadable 에디션 (온프레미스 용)
Spanner

개념 : 완전 관리형 scalable, 비싼, 글로벌 RDBMS 특징 :

  • distributed acress regions, global size 서비스에 적합하다.
  • Dialects
    • GoogleSQL
    • postgresql
  • capacity
    • processing units
    • nodes
BigTable

개념 :

  • 완전관리형, 분산형 NoSQL 와이드-컬럼(Wide-Column) 데이터베이스 특징 :
  • 저지연 인터랙티브 조회: Cloud Bigtable은 시계열/시간범위 조회에 최적화된 밀리초 단위 응답. (BigQuery 에 비해 조금 더 빠름)
  • 무거운 쓰기 작업에도 최적화 되어 있음
  •  real-time decision making
  • key-value store
  • distributed across regions (~8)
  • HBase compatible
  • schema
    • ensure reads as fast as posible
    • elements
      • table : 비정규화 한다.
      • column families : 관계있는 컬럼은 같은 familiy에 있어야 한다. 이른이 짧을수록 좋다.
      • columns : 컬럼 이름 자체에 데이터가 들어가 있다.
      • rows : 모든 엔티티의 데이터는 1개 row에 들어가하 한다. 100MB 넘으면 안된다.
      • cells : 10MB 넘으면 안된다.
      • row keys : rowkey 기반으로 쿼리한다. 짧은게 좋다.
  • SQL 이 아닌 API 를 통해 질의한다. (cbt 커맨드 활용)
Firestore
  • 완전 관리형 scalable NoSQL document store
  • distributed across regions
  • built-in synchronization, offline mode
  • 비용효율적
  • webapp이나 mobile의 rest api based backend DB 에 적당하다.
  • offline client 들과 synchronize 가능하다.
  • modes
    • native : document database, offline support
    • datastore : legacy mode, order api, no offline support
  • Datamodel 은 document(key, value) 가 최소 단위 이며 이게 모이면 collection 이 된다. 중첩도 된다.
BIgQuery
  • 완전 관리형 DW 솔루션
  • 모든 유형의 데이터를 다룰 수 있음
  • 비용효율적
    • On-Demand Pricing (기본값) : 쿼리 실행 시 스캔한 데이터 양(GB) 기준 과금
    • Flat-Rate Pricing (정액제 모델) : 쿼리 실행에 필요한 Slot(연산 리소스) 를 고정 요금으로 예약
    • Materialized views 를 활용해서 미리 계산결과를 저장해두고, 비용을 절약한다.
  • 빈번하고 예측하기 힘든 쿼리 부하도 견딜 수 있다.
  • realtime + batch process 에 적합하며, 이벤트 알람 등 즉시 판단이 필요한 경우는 DataFlow 가 적합
  • Role
    • BigQuery Job User : 쿼리 실행(Job 생성) 권한
    • BigQuery Data Viewer : Dataset/테이블을 조회할 수 있지만 수정 불가
  • editions
    • standard
    • enterprise
    • enterprise plus
  • load
    • batch loading
      • load jobs
      • sql
      • BigQuery Data Transfer
      • storage write api
      • other managed services
    • streaming
      • dataflow
      • datastream
      • connector for sap
      • storage write
      • pub/sub
    • generated data
      • CREATE TABLE … AS
    • 3rd Party apps
      • informatica, fivetran
  • bq
    • bq 명령어로 BigQuery 테이블 생성과, Cloud Storage 데이터 로드 까지 할 수 있다.
MemoryStore
  • 완전 관리형 인메모리 분산 캐쉬 (redis, memcached 와 호환됨)
  • regional
  • 250개 노드까지 autoscales 가능
  • cache frequently changing dynamic content (정적 컨텐츠인 CDN 과 반대)
  • tiers
    • basic : primary 1개 노드
    • standard : primary 1개, replica 1개 노드
    • standard with read replicas : 1개 primary node, 여러 replica 노드들
  • redis
    • 300GB 가 최대
    • connection 은 vpc 에서 private IP 만 허용함
  • cloud run 에서 memorystore 연결하기.
    • cloud run 은 serverless, memorystore 은 VPC에 있다.
    • 따라서 serverless vpc access 를 이용해서 private ip 로 접속하게 한다.
  • gke cluster 에서 memorystore 연결하기
    • yaml 파일에서 환경변수로 IP 주소 선언해서 접속하게 한다.
Cloud Storage
  • 완전 관리형 object storage
  • 원시데이터 파일저장에 효과적이고 비용효율적이다. (기존 FTP → 리눅스 중계 → gsutil 업로드만 추가하면 되므로 구현·운영 비용 최소.)
  • buckets 에 buckets 을 둘 수 없고 globally unique 하다.
  • GCS FUSE (Filesystem in USErspace) : 애플리케이션이 로컬 파일처럼 접근할 수 있게 리눅스의 디렉터리처럼 mount
  • location type
    • regional : single region, 제일 저렴, 성능 좋음
    • dual region : two region, 제일 비쌈, DR 시나리오 등에서 사용
    • multi region : multiple region, limited performance. dual region 보다는 저렴 contents serving 등에서 사용
  • cloud storage classes → 여전히 필요할 때 접속할 수 있다.
    • standard : short lived, frequently access
    • nearline : lives at least 30 days (1달!)
    • coldline : accessed once a quater (1분기!)
    • archive : archive, dr, backup
    • *autoclass : 자동으로 class 옮겨서 bucket level 에 적용할 수 있음
  • Signed URL
    • 클라우드가 서명한 URL 로 구글 계정과 관계없이 특정 object를 외부에 공개한 것
  • 사용자 encryption key 는 .boto configuration file 에 설정한다.
Cloud Datastore

개념: web and mobile 에서 사용하는 NoSQL database.

[ Messaging ]

Pub/Sub

  • publish, subscribe, async, scalable
  • editions
    • pub/sub : global, multizone , auto provisioned
    • pub/sub lite : regional, single or dual zone, provision before use, single project
  • pattern
    • many to one : 여럿 publish 해서 한명이 구독
    • many to many : 여럿 publish 해서 여럿이 구독
    • one to many(Fan-out) : 하나가 publish 해서 여럿이 구독
  • 사용 예시
    • 신뢰성 있는 스케줄링 : App Engine Cron → Pub/Sub → Compute Engine subscriber

EventArc (Pub/Sub 기반)

  • event driven architecture를 위한 built-in utilize 용(cloud function trigger 등)
  • event providers
    • google services : 서비스의 변경사항이 트리거되어 이를 알리는 경우
    • 3rd party : eventarc를 지원하는 서드파티 솔루션 등
    • custom source : 사용자 코드에서 이벤트가 발생하는 경우
  • event destinations
    • Cloud Functions
    • Cloud Run
    • GKE
    • Workflows
  • 모든 이벤트들은 CloudEvents format으로 전송된다.

Identity Management

  • Least Priviliege Principle 을 기억하자. Cloud IAM 을 사용한다.
  • Cloud IAM : Identity and Access Management
    • Who → Principal
      • Concept
        • Google Account : 가장 기본 단위 구글 계정
        • Service Account : 다른 서비스에 접속하도록 권한을 승인해주는 계정
        • Google Group : google account, service account 를 모은 컬렉션, 사용자 컬렉션에 엑세스 컨트롤 적용
        • Google Workspace Account : organization 의 모든 계정들이 들어가 있음
        • Cloud Identity Domain : Google Workspace Account 와 유사하나 docs, slides 접근 안하는 유저
        • All Authenticated Users : 통합된 승인을 원하는 경우 유용함
        • All Users : 특정 리소스를 인터넷상에 오픈하는 데 유용함

        • 주로 사용하는 것은 Google Account, Service Account 이다.

        • 상위 리소스(Org, Folder, Project)에 부여된 권한은 하위 리소스에 자동 상속된다.
      • Federation
        • 온프레미스와 클라우드 상에 사용자 sync 를 맞추는 것
        • implemented using Google Cloud Directory Sync(free to sync users and groups)
        • Flow
          • 사용자가 Google Cloud Directory Sync 통해 Cloud Identity 에 등록된다.
          • Cloud Identity 는 미리 설정한 Federation Service 에 SSO 요청을 보낸다.
          • 사용자 인증을 한다.
          • Cloud Identity 는 승인된 사용자 임을 확인한다.
    • Can do What → Role
      • 미리 정의된 권한을 사용자에게 할당한다.
      • types
        • Basic Roles : IAM 이전부터 사용했으므로 지양해야한다.→ 권장되지 않음!!
          • viewer : 조회만
          • editor : 조작 가능
          • owner : 권한부여, 빅쿼리 잡 캔슬 같은 민감작업, 프로젝트 비용 설정
        • Predefined Roles : Google 이 업데이트 중이므로 지향해야 함 → 권장됨!!
          • 예) Compute Admin : Compute Engine 전체 권한 포함
          • 예) Cloud SQL Instance User : SQL Instance 접속 허용
      • permissions
        • 특정 동작의 세부적인 권한들을 설정한 것
        • 예) cloudsql.databases.list : list 만 가능
      • custom roles
        • 사용자 정의 role
    • with which Resource → Allow Policy
      • 특정 자원에 특정 권한을 얻어주는 것
  • quotas(할당량)
    • 리소스의 사용량을 제한하고 spike 비용을 예방하는데 도움을 준다.
    • notification channel 을 통해 alert 를 제공해준다.
  • identity platform
    • 클라우드 리소스가 아니라 우리가 개발한 시스템이나 코드에 대한 권한
    • Customer Idendity and Access Managed platform (CIAM)
    • scaled automatically
    • social providers (apple, google, facebook, etc)
    • MFA 지원
    • MAU 50K 까지는 Free
  • Cloud DLP (Data Loss Prevention)
    • 개념 : PII(개인 식별 정보) 를 자동 탐지, 분류, 마스킹, 토큰화, 익명화하는 Google Cloud 서비스.
    • 특징 :
      • PII (Personally Identifiable Information) 식별 및 비식별화(Anonymization)
      • ML 학습용 데이터셋을 사용할 때 규제 준수(GDPR, HIPAA, PCI DSS 등) 를 만족시킬 수 있음.

Monitoring

  • mechanisms
    • Logs
      • types
        • platform logs
        • component logs
        • security logs
        • user written logs
      • storage
        • Required
        • Default
      • view
        • Logs Explorer, alert 생성 가능, 로그 집계는 불가
        • Logs Analytics, 집계 지원, 무료지만 log bucket을 업그레이드 해야 하고, 한번 업그레이드하면 다운그레이드는 불가함.
    • Metrics
      • 대부분의 리소스에 build-in으로 들어가 있음
    • DashBoard

Tags and Labels

  • 예) cost of all backends resources?
  • 예) 전체 웹서버에 방화벽 룰 적용
  • 예) 특정 시스템에 속한 모든 리소스는?
  • 예) 네트워크 계층분리 (tier-frontend, tier-middleware, tier-db) 를 하고 싶을 때
  • 이 문제를 해결하기 위해 Tags, Labels 를 사용한다.
  • Tags
    • key-value 값이며 리소스에 표기할 수 있다.
    • 예) env 환경을 dev, test, prod 로 만든다.
    • 예) IAM 과 연계한 Tag 를 만들어 계정에 연계할 수 있다.
  • Labels
    • 리소스에 붙어있는 key-value 형태의 메타데이터 이다.
    • 상속할 수 없고 메트릭 모니터링 등으로 쓸 수 없다.
    • 예) 특정 부서의 소속을 나타내거나 해당 그룹의 비용을 집계하는 등 용도.

Security in GCP

  • 보안 패턴을 따르는 것은 매우 중요하다.
  • vm
    • 최소 포트, IP 만 허용, VM 접근 제어
  • network
    • private resourece 만 있다면 해당 vpc 는 인터넷 접근 막는다.
    • 방화벽 통해 subnet 접속을 막는다.
    • private access 통해 리소스 접근을 막는다.
    • hub and spoke 모델을 최대한 활용한다.
  • database
    • 거래 주고 받을때 항상 암호화 한다.
    • private access 통해서 접속하고 public ip 통해 접속하지 않는다.
    • 인터넷에 오픈시켜야 한다면 방화벽 룰을 적용한다.
  • app engine
    • 외부에 공개적으로 오픈하지 말고 LB 사용한다.
    • private ip 만 사용해서 접속 허용한다.
    • Identity Platform 등 사용해서 접근 보안을 유지한다.
  • secret manager (secret management system)
    • connection string, keys, certificates, api keys … 를 보관해주고 rest api 등을 통해 관리할 수 있게 해준다.
    • secret manager 로의 방화벽 허용은 필요없다.
    • 비용 효율적이다.
      • key management
      • certificate manager
  • cloud armor
    • DDoS protection
    • Layer7 attacks 보호
    • IP, Geo Based Protection
  • secure command center
    • 리소스를 모니터링하고 관제하며, compliance report 를 생성하기도 함
  • IAP(Identity-Aware Proxy)
    • Zero Trust / BeyondCorp 모델 : 내부망 VPN 없이, 사용자·기기 신뢰 기반 접근
    • Google Workspace 사용자 인증 : SSO 기반 인증 필요
    • Cloud Run, App Engine, Compute Engine, GKE 등 모든 웹앱 접근 제어 가능
  • Cloud Key Management Service (KMS)
    • Google Cloud에서 암호화 키(Encryption Key) 를 생성·저장·관리
    • GCP 서비스들과 연동해 데이터를 안전하게 암호화·복호화할 수 있게 해주는 관리형 키 관리 시스템
    • 사용자 관리형 키(Customer-Managed Key) 를 적용하려면 KMS를 사용
    • CMEK (Customer-Managed Encryption Key) ←> 기본 GMEK(Google-managed key)
  • SAML 2.0 Federation
    • 기존 로그인 절차를 유지(사용자 경험 유지) + 비밀번호 외부 저장 금지
    • Google Cloud / Workspace 계정이 기업의 기존 IdP(예: Active Directory, Okta, ADFS)를 통해 인증되도록 연동.

Deployment manager

  • GCP IaC(Infrastructure as Code) 엔진이다.
  • code 를 사용해 infrastructure 를 managing, provisioning 한다.
  • 배포할 리소스를 설명한 configuration file.
  • 배포, 보안, 버전 측면에서 편리하다.
  • 완전 무료이며, 비용이 들지 않는다.

DR

  • DR site 를 정하고 필요한 경우 동작할 수 있도록 설정해야 한다.
  • 기본 동작하는 primary region 을 설정해 두고, secondary region 에서 복구한다. (프로젝트는 굳이 따로 따지 않는다.)
  • concept
    • Hot/Cold DR
      • hot DR : data loss, down time 없이 자동으로 넘어간다. 중복된 인프라가 필요하다.
      • cold DR : 데이터 소실 될 수 있고 메뉴얼로 기동이 필요할 수 있다.
    • RTO/RPO
      • RTO
        • Recovery Time Objective
        • DR 상황에서 얼마만큼의 다운타임을 견딜 수 있는가?
        • = system 이 복구되기까지 얼마나 걸리는가?
        • 주로 compute resource
      • RPO
        • Recovery Point Objective
        • DR 상황에서 얼마만큼의 데이터 Loss 를 허용할 것인가?
        • = secondary region 과 data sync 주기가 어떻게 되는가?
        • 주로 data resourece

Organization Policy

  • 제약조건
    • List : 허용/금지 서비스 속성들을 리스트로 나열한 것
    • Boolean : True/False 로 제약조건 설정 한 것

Architecting Apps For GCP

  • Compute Platform 고르기
    • on-premise 에 있던 레거시 앱인가? → VM
    • container based? → Cloud Run(mono) , GKE(msa)
    • just source code? → App Engine
  • Data Platform 고르기
    • RDBMS ? NoSQL?
    • 고성능?
  • API 활성화 단계
    1. GCP Console → APIs & Services → Library에서 필요한 Cloud Service API 활성화
    2. 서비스 계정 확인
    3. 필요 권한(Role) 부여

Migrating to GCP

  • migration step
    1. Motivation Assessment (동기 부여 평가)
      • 시스템 현대화, 비용 최적화, scailability redundancy 등등
      • CapEx vs OpEx
    2. System Assessment
      • 클라우드에 시스템을 mig 하는 데 가장 최적의 방법은 무엇인가?
      • 어떻게 배포되는가?
      • 인증 프로토콜은 무엇인가?
    3. Migration
      • 시스템 평가 결과에 따라 마이그레이션 전략이 결정된다.
      • Strategies
        • Rehost: lift and shift → VM 처럼 통째로 들어 올려 옮긴 것
        • Replatform: lift and optimize → 코드의 일부만 수정해서 cloud run 등에 배포
        • Refactor: move and improve
        • Re-architect: continue to modernize
        • Rebuild: remove and replace, sometimes called rip and replace → 앱을 처음부터 모던 플랫폼에 맞게 재작성한다.
        • Repurchase
    4. Enhancement
      • Cloud logging(Log), Cloud monitoring(Metric)
      • LB, Cloud Armor 통한 Network Protection
    5. Testing
      • logging, monitoring 체크
      • system data 접근 확인
      • auto-scaling, DR 확인
      • performance 확인
    6. Go Live
      • setup budget alert
      • tagging
  • Data Migration
    • Transfer Appliance
      • 구글이 제공하는 고용량 데이터 이송용 하드웨어 장비
      • 인터넷으로 업로드하기 어려운 대규모 데이터를 물리적으로 Google Cloud로 전송할 수 있게 해주는 서비스
      • Google이 하드디스크 박스를 보내준다
    • Storage Transfer Service(with Cloud VPN)
      • 물리 장비를 사용할 수 없는 상황에서 대용량의 데이터를 효과적으로 Cloud Storage 로 전송
    • Database Migration Service (DMS)
      • 온프레미스나 다른 클라우드, 또는 Cloud SQL 간에 있는 데이터베이스를 Cloud SQL로 안전하게 이전하는 Google Cloud의 완전관리형(Managed) 서비스
  • ETC
    • Google Marketplace 에는 이미 다양한 솔루션들이 제공되어 쉽게 GCP 에 구성할 수 있다.
    • Capacity planning, TCO calculations, OPEX/CAPEX allocation 가 주요 변경사항이다.
    • VM → Compute Engine의 경우 Migrate for Compute Engine 콘솔에서 Runbook 생성 (자동화된 이관 시나리오).

Cost-Effective

  • Cloud Scheduler + Cloud Functions + automatic VM shutdowns

심화(특화) 개념

Cloud Emulator

  • 개념 : Google Cloud의 여러 서비스(Bigtable, Firestore, Pub/Sub 등)를 로컬 환경(또는 CI/CD 파이프라인) 에서 모의(Mock) 실행할 수 있게 해주는 개발용 테스트 도구 세트
  • 특징 :
    • 테스트 시 실제 GCP 리소스 생성/삭제 비용 없음
    • 프로덕션 데이터와 분리된 안전한 테스트 환경

Dataproc

  • 개념 : 관리형 Hadoop/Spark 서비스
  • 특징 :
    • 온프레미스 Hadoop 워크로드를 거의 그대로 옮겨 자동 스케일링·빠른 클러스터 생성·저렴한 선점형(Preemptible) 노드 등을 활용해 트래픽 증가에 유연하게 대응
    • HDFS 대신 GCS+Hadoop/Spark 커넥터를 쓰면 스토리지-컴퓨트 분리로 확장성/비용도 개선

DataFlow

  • 개념 : Dataflow는 완전관리형(서버리스) 스트리밍/배치 ETL 서비스로, 센서 스트림을 분석·정제·풍부화(enrich) 하는 솔루션
  • 특징
    • Streaming/Batch Data Processing
    • 완전관리형, autoscale, 비용효율적
    • Pub/Sub, BigQuery 와 함께 petabyte-scale, real-time data analytics 지원.
      • Pub/Sub (데이터 입수) : 비동기 이벤트 스트리밍 / 분산 시스템 간 decoupling 지원하므로 같이 쓰는게 좋음
      • DataFlow (데이터 처리) : 실시간 ETL, 윈도우 처리, 데이터 변환 파이프라인

APIgee

  • API 관리 툴로 백엔드 API의 추상화를 제공한다.

AI services

  • Cloud Machine Learning Engine
  • AutoML Tables
    • pecifically designed for tabular or structured data, like historic purchase data
    • automatic model training, tuning, and deployment
  • AutoML Vision
  • BigQuery ML
    • machine learning models to be built using SQL queries
  • AI Platform Training
    • ML training job을 infrastructure 매니징 없이 가능하게 하는 서비스

Google Cloud Healthcare API

  • specifically designed to manage and process healthcare data - personal health information (PHI)

Looker

  • 개념
    • Looker : Google Cloud의 데이터 분석 & BI (Business Intelligence) 플랫폼
    • BigQuery, Snowflake, Redshift, Databricks 같은 데이터 웨어하우스 위에 올라가서 SQL을 대신해 분석 모델링, 시각화, 대시보드, 권한 관리를 해주는 도구
    • LookML (Looker Modeling Language) : Looker에서 데이터 모델(Data Model) 을 정의하는 DSL(Domain-Specific Language)
  • 특징 :
    • Persistent Derived Tables (PDTs)
      • LookML에서 정의한 Derived Table(파생 테이블) 을 데이터베이스 안에 영구 테이블 형태로 저장(persist) 해두는 것.
      • 한 번 계산해서 DB(BigQuery, Snowflake 등)에 결과 테이블로 저장해두고 이후 쿼리는 그 “결과 테이블”을 빠르게 참조하도록 하는 기능

Cloud Dataprep (by Trifacta)

  • 개념 : 데이터 이상치 탐지 및 시각 탐색·정제·프로파일링 도구
  • 특징 : GUI 기반의 시각화 및 이상치 탐지, 결측치 확인, 변환 추천 기능 제공

Cloud Operations Suite (구 Google StackDriver)

  • 개념 : 관측성(Observability) 통합 스택: 메트릭(모니터링), 로그, 트레이스, 에러, 프로파일링, 디버깅을 한곳에서.
  • 대상 : GCE, GKE, Cloud Run/App Engine, Cloud SQL, Pub/Sub 등 GCP 전역 + 온프렘/다른 클라우드(에이전트/OTel로 수집).

Recent Notes

Graph View

Recent Notes