회사에서 좋은 기회로 GCP Associate Cloud Engineer 자격증 취득 프로그램 참여를 하게 되어 공부 내용을 기록한다.

Definition of Cloud Computing

클라우드 컴퓨팅이란 아래 다섯가지 특성을 만족하는 정보 기술(IT)을 의미한다.

1. 고객이 컴퓨팅 자원을 온디맨드(주문형, 원할 때 즉각적인 요구에 따라 필요한 형태에 맞춰 주문) 방식, 그리고 자기 주도적으로 사용할 수 있다.
2. 고객이 이러한 컴퓨팅 자원들에 인터넷을 통해 어디서나 접근할 수 있다.
3. 해당 자원의 제공자는 공유된 컴퓨팅 자원들의 집합으로부터 꺼내어 사용자 요구에 따라 할당한다.
4. 자원은 탄력적이고(elastic) 고객 필요에 따라 사용량을 늘리거나 줄일 수 있다.
5. 고객은 그들이 사용한 만큼 비용을 지불하거나, 필요에 따라 사전에 예약한 만큼 비용을 지불한다.

History of Cloud Computing

클라우드 컴퓨팅 모델은 아래와 같은 역사적 흐름에 따라 만들어지게 되었다.

1. Colocation: 데이터 센터 부지를 구매하거나 실제로 건설하지 않고 물리적 공간을 임대하는 방식
2. Virtualized data center: 로드밸런서, CPU, 디스크 등 실제 장치를 구매하여 프라이빗 데이터 센터 및 콜로케이션에 배치하는 형태가 아닌, 장치들을 소프트웨어 형태로 가상화 하여 제공하는 방식
   • 이를 통해 가상 서버를 만들 수 있게 되었지만, 해당 서버에 대한 관리 및 운영 책임은 여전히 기업에 존재
   • 서버 배치, 설치할 OS, 보안 업데이트 등 서버 컴퓨팅 셋업 자체를 가상화 데이터 센터를 이용하는 고객이 직접 해야됨.
   • 물리적인 장비만 쉽게 대여 할 수 있는 방식일 뿐
3. Container-based architecture: 자동화된 서비스들과 확장 가능한 데이터 시스템의 조합으로 구성
   • 컨테이너 기술(예: Docker)과 이를 관리하는 오케스트레이션 도구(예: Kubernetes)를 활용하면, 애플리케이션 실행에 필요한 인프라 프로비저닝을 자동화할 수 있다. 여기서 인프라 프로비저닝이란, 애플리케이션이 실행될 수 있도록 서버, 네트워크, 스토리지 등 컴퓨팅 자원을 준비하고 구성하는 과정을 의미한다.

IaaS & PaaS

가상화 데이터 센터로의 국면 전환은 IaaS와 PaaS라는 새로운 형태의 서비스를 제공했다.

1. IaaS(Infrastructure as a Service): 클라우드를 통해 온디맨드 인프라 자원을 전달 (디스크 등 로우레벨 컴퓨팅 자원, 스토리지, 네트워크 지원 기능 - 로드 밸런서 등), ex) GCP Compute Engine
   • IaaS는 고객이 미리 할당한 자원에 대해 비용을 지불한다. (4시간 할당 예약, 4시간 만큼 비용지불)
2. PaaS(Platform as a Service): 애플리케이션이 필요한 인프라에 접근할 수 있도록 코드를 라이브러리와 연결해준다. 이때 라이브러리는 개발자가 인프라에 직접 접근하지 않고 GCP 라이브러리를 통해 간접적으로 인프라에 접근한다.(ex - DB 연결 시 google.cloud.datastore, 로깅 시 google.cloud.logging 활용 등)
   • PaaS는 고객이 실제로 사용한 자원에 대해서만 비용을 지불한다. (4시간 트래픽 발생, 4시간 만큼 비용지불)
   • IaaS와 다르게 PaaS는 인프라 자원을 미리 할당받아서 사용하는 형태가 아님
3. SaaS(Software as a Service): 완전한 어플리케이션 스택을 제공하여 고객이 완전한 클라우드 기반 애플리케이션에 바로 접근 및 사용할 수 있게 해준다. (ex - Gmail, Drive 등이 묶여 Google Workspace로 사용)

서버리스 컴퓨팅

서버리스 컴퓨팅은 인프라에 대한 관리를 전혀 하지 않고 오직 코드에만 집중할 수 있는 환경을 제공하는 것을 의미한다. 서버 구성 및 자원 설정 없이도 어플리케이션 실행이 가능하다.

GCP에서는 아래와 같은 서버리스 컴퓨팅 서비스들을 제공한다.

• Cloud Run: 컨테이너화된 마이크로 서비스를 쉽게 배포 가능
• Cloud Function: 이벤트 기반 코드 모음, 파일 업로드 및 DB 변경과 같은 이벤트 발생 시 자동으로 등록해둔 함수가 실행된다.

Google Cloud Network

구글은 더 많은 처리량(throughput) 감당과 최대한 낮은 지연(latency)을 위해 글로벌 네트워크망을 구축했다. 전세계 곳곳에 100개 이상의 컨텐츠 캐싱 노드를 마련해두고 있다.

구글 인프라 위치가 고객 작업의 중요한 기반이 되는데, 전 세계 7개 리전에 기반을 두고 있다. 그 지역들은 북아메리카, 남아메리카, 유럽, 아프리카, 중동, 아시아, 오스트레일리아에 해당한다.

여러 지역에 걸쳐 인프라 망을 구축해둔 이유는 가용성(availability), 내구성(durability), 그리고 **지연(latency)**과 같은 품질 요소들이 영향을 받기 때문이다. 지연은 정보의 패킷이 출발지에서 목적지까지 이동하는 데 걸리는 시간을 의미한다.

Regions and Zones

클라우드 환경에서 각 지역은 리전으로 구성되어 있고, 각 리전은 Zone으로 구성되어 있다.

영국 런던이라는 지역에는 europe-west2라는 리전이 존재하고, 해당 리전에는 europe-west2-a, europe-west2-b, europe-west2-c.. 등의 Zone들로 구성되어 있다.

Zone은 구글 클라우드 리소스가 배포되는 물리적 영역이다. 가상 머신 배포를 가정하면, 해당 가상 머신은 하나의 Zone에 배포된다. Zone 구조를 통해 리소스의 중복성과(redundancy) 고가용성을(high-availability) 충족시킬 수 있다.

리소스 중복성은 같은 기능을 하는 리소스를 여러개로 복제해두는 것을 의미하며, 고가용성은 서비스가 장애 없이 지속적으로 운영될 수 있도록 설계된 시스템의 특성이다.

멀티존 배포 외에 멀티 리전 배포도 가능하다. 리소스 중복성, 고가용성을 만족하면서 추가적으로 멀리 떨어진 리전과의 애플리케이션 연결성을 보장하기 위한 목적도 추가된다.

Google Cloud Spanner가 위와 같은 역할을 한다. 여러 존 및 여러 리전에 DB 복제(replication)를 할 수 있게 해준다. 해당 복제본들은 멀티 리전에 배포될 수 있고, 이를 통해 낮은 레이턴시로 다른 리전에서 DB에 접근할 수 있게 된다.

Security

Hardware level

구글은 하드웨어 단에서부터 데이터 센터 보안성 및 신뢰성을 보장하려고 노력한다.

1. 하드웨어 설계: 구글 데이터센터의 서버보드와 네트워킹 장비는 구글이 직접 디자인한다. 현재 서버 및 주변 장치에 탑재중인 보안 하드웨어 칩 등을 직접 디자인 한다.
2. 부팅 스택 관리: 데이터 센터의 서버 부팅시 올바른 소프트웨어만 부팅되도록 보안 기술을 사용한다. (BIOS, 부트로더, 커널, 운영체제 이미지에 대해 암호학적 서명(cryptographic signatures) 적용, 허가되지 않은 코드 실행 방지)
3. 물리적 보안: 데이터 센터 출입 통제 등 실질적 보안

Service deployment level

다음은 서비스 배포 레벨의 보안이다.

• GCP 인프라 내 서비스 간 RPC라는 방식을 통해 소통한다. 구글의 모든 인프라는 데이터 센터간 RPC 트래픽 전체를 암호화 하고 있다.

User identity level

Google의 중앙 신원 확인 서비스(central identity service)는 단순히 아이디와 비밀번호만 요구하는 수준을 넘어서 더 정교한 방식으로 동작한다.

1. 위험 기반 접근 제어(Risk-based authentication)
   • 사용자의 로그인 시도를 평가하여, 이전과 동일한 기기 또는 위치인지 등의 정보를 기반으로 추가 인증 절차(챌린지)를 자동으로 요청한다.
     • 낯선 국가에서 로그인 시도 → 추가 인증 요청
     • 새 기기에서 로그인 → 이메일/휴대폰 확인 요구
2. 이차 인증 수단(Secondary factors) 지원
   • 사용자는 계정 보호 강화를 위해 추가 인증 수단을 선택할 수 있다.
   • **U2F (Universal 2nd Factor)**라는 오픈 스탠더드 기반 장치를 사용할 수 있다.
     • 보안 키(YubiKey) 같은 물리 보안 장치

Storage services level

구글은 데이터가 저장(rest)되어 있는 상태에서도 암호화를 적용한다.

1. 간접 접근 + 계층적 암호화
   • 대부분의 Google 애플리케이션은 **물리적 스토리지(파일 저장소)**에 직접 접근하지 않고, 스토리지 서비스 계층을 통해 간접적으로 접근한다.
     • Google Cloud Storage, Spanner, Bigtable 등
   • 이 스토리지 서비스 계층에서 암호화가 자동 적용됩니다.
   • 암호화 키는 Google이 **중앙에서 안전하게 관리(centrally managed keys)**합니다.
2. 하드웨어 수준 암호화도 지원
   • Google은 **하드 디스크(HDD)**와 SSD에 대해 **하드웨어 암호화 기능(hardware encryption support)**도 활성화합니다.
   • 저장 장치 자체에서 데이터가 암호화되어 보관됨

Internet communication level

구글의 인터넷 통신 레벨에서는 인프라 구성 요소 중 하나인 GFE(Google Front End)라는 장치가 보안에 있어 중요하게 사용된다.

GFE는 Google 서비스가 인터넷에 노출되기 위해 반드시 등록하는 인프라 서비스이다. 모든 외부 요청은 먼저 GFE를 통해 들어오며, GFE는 아래와 같은 역할을 수행한다.

• 보안 통신 처리: TLS 연결 종료 (HTTPS 트래픽 처리)
  • GFE는 공개키/개인키 쌍과 **공인 인증기관(CA)**에서 발급된 X.509 인증서를 사용하여 TLS 연결을 안전하게 종료한다.
• Perfect Forward Secrecy (PFS) 지원:
  • 과거의 키가 유출되더라도 이전 통신 내용을 해독할 수 없도록 최신 TLS 보안 관행을 따른다.

이러한 형태로 GFE는 인프라에서 외부 요청에 대해 프록시 역할을 수행하며, 동시에 DoS 공격에 대해 방어를 할 수 있는 기능이 있다.

구글 인프라의 DoS 공격에 대한 방어 체계는 아래와 같다.

• 인프라 규모 기반 흡수(Absorption)
  • Google은 워낙 전 세계적으로 확장된 인프라를 보유하고 있어, 일정 수준의 DoS 공격은 별도 조치 없이도 자체 흡수할 수 있다.
• 다단계, 다계층 방어 체계
  • 네트워크 레벨, 전송 계층, 애플리케이션 계층까지 포함한 다계층의 방어 메커니즘을 통해 공격의 탐지 → 차단 → 대응을 자동화한다.
  • 이 보호 체계는 GFE 뒤에 배치된 모든 서비스에 기본적으로 적용된다.

Operational security level

Google이 인프라와 내부 운영 보안을 강화하기 위해 수행하고 있는 다양한 보안 전략들을 보유하고 있다.

1. Intrusion detection (침입 탐지 시스템) - 의심되는 보안 사고에 대한 모니터링 및 대응
2. Reducing insider risk (내부자 위험 최소화) - 관리 권한 대상직원 지속 모니터링
3. Employee U2F use (직원 계정 보안) - 직원들의 계정은 Universal 2nd Factor 호환 물리 보안 키를 사용
4. Secure development practices (안전한 소프트웨어 개발 관행)

Open-source friendly

GCP는 텐서플로우, 쿠버네티스 등과 같은 핵심 기술들을 오픈소스 라이센스 하에 제공하여 고객 애플리케이션이 GCP라는 클라우드 공급 업체에만 종속되지 않도록 한다.

Google은 **상호운용성(interoperability)**을 제공한다. Kubernetes 및 **Google Kubernetes Engine(GKE)**를 통해 고객은 다양한 클라우드에 걸쳐 마이크로서비스를 혼합 구성 및 운영할 수 있다.(ex - 일부 마이크로서비스는 Google Cloud에서, 다른 일부는 AWS나 Azure에서 실행 가능)

**Google Cloud Observability(모니터링 서비스)**는 고객이 멀티 클라우드 기반 환경도 통합하여 장애 등을 모니터링할 수 있게 해준다.

Billing

GCP는 Compute Engine, GKE, Dataproc, App Engine Flexible Environment VMs과 같은 서비스에 대해 초단위 사용요금 비용 정책을 제공한다. 초단위 비용정책을 통해 불필요한 비용 청구를 줄일 수 있다.

또한 Compute Engine은 sustained-use 할인을 제공하는데, 이는 한달 간 25% 이상 VM 인스턴스를 운영한 경우 추가적으로 사용한 시간을 분단위로 계산하여 할인을 적용해주게 된다.

또한 VM 타입을 직접 커스텀 할 수 있어서 자신의 작업 사양에 맞게 vCPU 갯수, 메모리 크기 등을 조절하여 비용을 최적화 할 수 있다.

GCP에서 몇 가지 도구를 활용하면 비용 관리를 지혜롭게 할 수 있다.

1. Budget: 결제 계정 및 프로젝트 단위로 예산을 설정 가능
2. Alert: 예산 한도에 가까워질 때 알럿 설정 가능
3. Reports: Google Cloud Console에서 프로젝트별, 서비스별, 시간대별 비용 지출 현황 시각화
4. Quotas: 리소스마다 할당량을 설정할 수 있다. (Compute Engine 인스턴스 생성 할당량, 초당 API 호출 리밋 등 설정 가능 - 실수에 의한 호출 및 악의적 공격에 의한 비용 지출 방지)
   • Rate Quota: 시간/초당 속도율 제한, 일정 시간이 지나면 초기화됨. (GKE API 호출 수 제한 등)
   • Allocation Quota: 리소스 총량 제한, 명시적으로 자원을 할당해야 증가 (VM 수 등)