[GCP] Professional Cloud Architect 정리

 

 

 

AWS	GCP	차이점
EC2	Compute Engine	-
Auto Scaling Group	Managed Instance Group	-
AMI	Custom Image / Image Family	이미지는 글로벌 리소스임
Spot Instance	Spot VM	-
EKS	GKE	-
ECS / Fargate	Cloud Run
Lambda	Cloud Run Functions	지금은 Cloud Run으로 통합되긴 함
S3	Cloud Storage
Standard / IA / Glacier / Deep Archive	Standard / Nearline / Coldline / Archive	Archive도 밀리초 단위로 조회 가능
EBS	Persistent Disk / HyperDisk	-
EFS	Filestore
Storage Gateway	Storage Transfer Service	-
RDS	Cloud SQL	MySQL / PostgreSQL / SQL Server
Aurora Global	Spanner	수평 확장 RDBMS
DynamoDB	Firestore	문서형
-	Bigtable	시계열 IoT 대용량 / 페타바이트
ElastiCache	MemoryStore	Redis
Redshift	BigQuery	서버리스
Neptune	Spanner Graph
VPC	VPC	AWS 는 리전 / GCP 는 글로벌
Subnet	Subnet	AWS 는 AZ / GCP 는 리전
Security Group + NACL	VPC Firewall Rules	-
Route 53	Cloud DNS	-
ALB / NLB	Application LB / Network LB	-
Direct Connect	Cloud Interconnect	-
Site to Site VPN	Cloud VPN	-
WAF + Shield	Cloud Armor	-
-	Shared VPC	호스트가 네트워크 소유
Kinesis Data Streams	Pub/Sub	-
Kinesis Firehose	Dataflow	-
Glue ETL	Dataflow / Dataproc / Dataform	-
Athena	BigQuery	-
SQS	Pub/Sub	-
SNS	Pub/Sub	Pub/Sub가 다 처리함

 

 

AWS 에서 EC2를 하나 만들면 그건 계정 안에 만들어진다. 다른 계정에서는 볼 수 없고, 청구서도 계정 단위로 나온다. 

다만 GCP 에서는 계정 단위가 아니라 프로젝트 단위로 처리됨. 

 

AWS 계정을 만드려면 이메일 결제수단 루트유저 등 다뤄야 할 게 많지만 GCP는 명령어 한 줄으로 만들 수 있다.

그러니 AWS에서는 계정 하나에 VPC나 태그로 환경을 구분한다면 GCP에서는 환경마다 프로젝트를 쪼갠다. 

 

AWS 에서는 VPC를 만들 때 리전을 고르고 서브넷을 만들 때 AZ를 고른다. 그러니 VPC 끼리 통신하려면 VPC Peering이나 Transit Gateway로 이어붙여야 함. 다중 AZ를 구성할 때도 서브넷을 AZ마다 하나씩 만들어야 함. 그래서 ALB 만들 때 서브넷을 2개 이상 선택해야 한다. 

GCP에서는 VPC를 만들 때 리전을 고르지 않음. 서브넷을 만들 때 리전을 고르고 AZ를 고르지 않음. AZ는 VM을 띄울 때 정하는 속성일 뿐이다. 

 

서브넷은 IP 주소 덩어리를 잘라내는 조각이다. /24 는 앞에서부터 24비트는 고정이라는 뜻. 고정된 부분이 많으면 대역은 작아진다.

VPC를 10.0.0.0/16 으로 잡으면 65000 가량의 주소를 할당할 수 있음. 여기에 용도별로 구역을 나눠서 사용한다. 

 

 

 

 

서브넷을 나누면 라우팅 단위와 보안 경계를 잡을 수 있다. 대역은 절대 겹치면 안됨. AWS 는 인터넷 노출 여부까지 서브넷으로 결정함. 

 

GCP에서는 프로젝트를 잘개 쪼개는게 기본이지만 프로젝트마다 VPC를 따로 만들면 Peering 개수가 폭증하고 관리가 힘들어진다. 그러니 Shared VPC를 도입함. 

네트워크는 프로젝트 하나가 소유하고, 나머지 프로젝트들은 그 서브넷에 각각의 VM을 꽂아넣는 방식이다. 

 

퍼블릭 / 프라이빗 서브넷은 AWS 에서 사용하는 개념이다. 서브넷의 라우팅 테이블에 IGW 경로가 있는지의 차이인데, GCP 에는 해당 개념 자체가 없고 VM에 외부 IP를 붙이는지 아닌지로 결정되고 아웃바운드만 필요하면 Cloud NAT를 사용한다.

 

다만 VPC 개념은 같음. Virtual Private Cloud 약자로 클라우드 안에서 내가 할당받은 논리적으로 격리된 나만의 사설 네트워크로 내 IP 대역을 내가 정하고 라우팅과 방화벽을 내가 통제할 수 있다.  

 

AWS의 IAM은 사용자에게 정책을 붙이지만 (S3 버킷 정책처럼 리소스 정책도 있긴함) GCP IAM은 리소스에 정책을 붙인다. 프로젝트에 정책을 붙이면 그 안의 모든 VM과 버킷에 자동으로 적용된다. 꼭 프로젝트에 붙여야 하는건 아닌데 웬만하면 프로젝트에 붙임. 상위에 붙은 권한은 아래로 그대로 이어짐. 

 

GKE는 EKS처럼 관리형 쿠버네티스지만 GCP에는 Autopilot 모드가 있어 이걸 켜면 구글이 알아서 노드를 만들고 Pod 리소스 기준으로만 과금한다. 운영 부담을 최소화 할 수 있음. Autopilot을 사용하면 k8s의 노드 개념을 아예 다루지 않아도 됨. Pod 스펙만 주면 알아서 구글이 용량을 마련함. 이러면 낭비되는 용량에 돈을 내지 않아도 된다. 어떻게 보면 내가 노드를 직접 조작할 수 없어서 제어할 수 있는 부분이 줄어드는 거긴 함. 그리고 GKE Standard보다 단가가 비싸기도 하다. 운영 부담 최소화가 요구사항이라면 Autopilot을 사용하는게 합리적이다. FinOps를 한다면 빌링 데이터를 바탕으로 대시보드를 만들고 어떤 비용이 어디서 나오는지 기록해야 함. 단가는 높지만 유휴 낭비가 없어서 총 비용은 더 저렴할 수 있음.

 

Aurora는 쓰기 노드가 하나지만 Spanner는 쓰기가 수평으로 쪼개져서 수평 확장 RDBMS. Aurora는 읽기 확장만 함. Spanner는 쓰기도 확장함. RPO도 0이다. 성능이 굉장히 좋음.

 

Cloud SQL은 RDS와 유사하고 Firestore는 문서형 NoSQL을 다룰 때 사용한다. BigTable도 NoSQL이지만 실시간으로 읽고 쓰는게 필요할 때는 BigTable을 사용한다. BigQuery는 분석 전용 웨어하우스로 SQL으로 분석할 때 사용함. Firestore는 초당 수백만 건 쓰기 정도의 성능을 낼 수 는 없다. 다만 유연한 쿼리가 가능하고 모바일 SDK로 사용할 수 있음. 

 

Pub/Sub는 SQS SNS Kinesis를 합친 역할을 수행한다. 글로벌 서비스이고 자동 확장되며 필요한 경우 순서 보장을 켜야한다. 기존에 Hadoop이 있다면 Dataproc을 사용하고 서버리스로 운영 부담을 최소화 할 때는 Dataflow를 사용한다. 

 

Site Reliability Engineering은 운영 업무를 엔지니어링으로 푸는걸 의미한다. 데브옵스는 철학이고 SRE는 그걸 숫자와 규칙으로 구현한 결과물이라고 생각하면 됨 (class SRE implements DevOps) 100%를 목표로 하지 않는다. 비즈니스적으로 타당한 수치가 어느정도인지 찾고 그 수치를 목표로 함. SLI는 실제로 재는 수치로 요청 중 200응답 비율 등을 의미하고 SLO는 그 숫자의 내부 목표를 의미하고 SLA는 목표를 고객과의 계약으로 약속한 것을 의미한다. CPU 사용률은 90%여도 사용자가 잘 쓰고 있으면 문제되지 않으니 사용자가 느낄 수 있는 것으로 SLI를 측정해야 한다. SLO가 99.9%면 한달에 43분은 실패해도 된다는 것. 사용자 실패율같은 증상에 알림을 걸어야 한다. 

 

GCP는 네트워크 서비스 티어를 고를 수 있음. 프리미엄 티어를 선택하면 구글 백본을 사용하고 스탠다드 티어를 선택하면 공용 인터넷을 타고 저렴하다. NLB ALB 4계층 7계층인거는 똑같음. GCP에서는 VPC가 글로벌이라서 같은 VPC에 있으면 그냥 사설 IP로 통신하고 구글 백본을 탄다. 차이점으로는 AWS 에서 A국가에서 B국가로 갈 때 공용 인터넷을 타지만 GCP 에서는 A의 집결지까지 간 후에 구글 백본을 통해 빠르게 동작한다. 

 

Terraform은 Infrastructure as Code로 인프라를 코드 파일로 정의할 수 있음. GUI 콘솔에서 딸깍딸깍으로 인프라 구축하면 기록도 없고 검토도 안된다. IaC는 이런 문제를 해결함. AWS 에서는 IaC로 CloudFormation을 사용하지만 GCP 에서는 Terraform을 사용한다. 구글이 만든거는 아니지만 가져다 씀. 

 

GCP는 따로 설정하지 않아도 저장 데이터가 항상 암호화 되어 있음. 그리고 그 위에 키 통제권으로 단계가 갈린다. CMEK는 키를 내가 직접 통제하고, EKM은 키를 클라우드 밖에다 두고 CSEK는 구글이 키를 가지지 못하도록 설정한다. 비밀번호나 API 키는 Secret Manager를 사용함. 

 

클라우드간 연결은 VPN 터널을 사용하는 경우가 많다. 양쪽에 VPN 게이트웨이를 세우고 IPsec 터널로 잇는다. GCP는 HA VPN을 사용하고 AWS는 Site to Site VPN을 사용함. 저걸 안 쓰면 Cross Cloud Interconnect를 사용함. GCP는 AWS 등 클라우드에 직접 물리 연결을 제공한다.