당연히 무수히 많은 차이점이 있을테지만, 그냥 공부하면서 알게된 것들을 정리한 것이고 틀린 내용이 있을 수도 있다.
단순히 'AWS에서의 Object Storage는 S3이고, GCP에서의 Object Storage는 Cloud Storage다.'와 같은 비교글은 아니다.
장단점
GCP의 장점
-
빅쿼리
SQL지원 및 엄청난 쿼리 성능, 서버리스(NoOps) -
for the 개발자 of the 개발자 by the 개발자
개발자가 쓰기 편한 클라우드 (인프라 레벨에서 건드릴 게 거의 없다.) -
GKE
별도의 플러그인을 쓰지 않아도 yaml로 모든 설정 가능. -
Global
애초에 글로벌 단위인 서비스들이 있다.
IAM
IAM 관련해서도 GCP를 처음 접하면 많이 헷갈려한다.
익숙하지 않은 개념이 있기 때문이다. 바로 Service Acount.
쉽게 말해서 Service Account는 AWS의 역할..!
GCP에서도 역할이 있는데...? 라고 할 수 있다.
여기서 말하는 AWS 역할은 EC2에 붙여주는 인스턴스 프로파일.
즉, AWS 리소스가 다른 AWS 리소스에 접근하기 위해서 부여해주는 역할을 뜻하는데 이 개념이 AWS에선 '역할' 하나로 모두 가능한데 GCP는 Service Account라는 걸 사용한다.
Service Account의 용도는 애플리케이션에서 GCP에 인증하기 위한 수단.
사용하고자 하는 GCP 프로젝트에 Service Account를 생성하고 필요한 권한을 부여해준 다음 키 파일을 내려받을 수 있다.
Service Account를 생성한 화면
키 파일 생성
이 키 파일만 있으면 On=prem, 타 클라우드 혹은 로컬PC 등등 어디서든 GCP에 인증이 가능하다. 때문에 해당 키 파일은 절대로 외부에 노출되어선 안된다.
VPC
| Resource | AWS | GCP |
|---|---|---|
| VPC | regional | global |
| VPC CIDR | O | X |
| Subnet | Zonal | Regional |
| Subnet CIDR | O | O |
GCP는 기본적으로 vpc가 default로 글로벌 단위이고 리전마다 구글에서 정해놓은 대역이 있다. ex) us-central1은 10.128.x.x 이런식이다.
때문에 VPC에 따로 CIDR값을 부여하지 않고 서브넷별로 별로 독립적인 CIDR값을 가질 수 있다. 전혀 다른 IP여도 한 VPC내에 있기 때문에 내부통신엔 지장이 없다.
(물론 커스텀 모드로 흔히 알고 있는 AWS의 VPC, Subnet처럼 설정도 가능)
그리고 AWS는 방화벽이 3개이다. (AWS의 WAF, GCP의 Cloud Armor 제외)
- Security Group
- NACL
- Network Firewall
GCP는 Firewall 하나다.
이 방화벽을 주는 방식은 쿠버네티스와 비슷하다. 쿠버네티스에서는 뭐든지 라벨을 지정해줘서 라벨별로 서비스한다.
GCP는 해당 네트워크 대역에 모든 인스턴스에 방화벽 설정을 해줄지 아니면 태그를 기반으로 이 태그가 지정된 특정 인스턴스에만 방화벽 설정을 해줄지를 정해서 Access Control 한다.
Cloud SQL
AWS의 RDS는 오라클은 물론 Maria DB 등등 매우 많은 DB 솔루션이 지원된다.
하지만 Cloud SQL의 경우 MySQL, PostgreSQL, MSSQL 세가지밖에 지원되지 않는다.
AWS보다 나은 점도 있다.
AWS같은 경우 root사용자, 비번, 초기DB외엔 직접 인스턴스에 연결 후, 명령어를 통해서 사용자나 DB를 추가해줬어야 했다.
하지만 GCP는 아래 사진처럼 콘솔에서 바로 설정이 가능하다.
그러나 또 다른 단점은 AWS의 경우 RDS도 그냥 Security Group에서 EC2와 LB에 주는 것과 같이 방화벽 설정을 할 수 있지만 GCP는 Cloud SQL의 연결 탭에서 허용할 대역을 지정해주는 수밖에 없다. GCP의 Firewall로 컨트롤할 수 없고, 인바운드와 아웃바운드 트래픽 둘 다 제어할 수 없다는 뜻이다.
지속 할인
GCP에서 자랑하는 또 다른 정책이 있다. 바로 지속할인이다.
AWS의 경우 RI(Reserved Instances)라고 EC2 인스턴스를 x달, 1년 등등 계약했을 때만 할인해준다.
Compute Engine 지속 사용 할인 참고
GCP는 특정 기간을 쓸 것이라고 계약한 것이 아니더라도 인스턴스를 특정 기준 이상 사용할 때마다 추가 1시간에 대해 자동 할인 혜택을 받을 수 있는 가격정책이 있다.
사용량이 늘어날수록 할인이 점진적으로 증가하고 한달 내내 실행된 인스턴스의 경우 리소스 비용에서 최대 30%의 할인까지 받을 수 있다.
Peering
아래 사진처럼 보통 피어링을 A > B, B > C 이렇게 맺는다고 해서 A > C가 되진 않는다. 때문에 A와 C도 연결을 해주려면 A > C도 피어링해줘야 되고 이렇게되면 결국 Full-Mesh 방식으로 연결을 해주게 되는 것이다.
이에 대한 해결책으로 AWS에서는 Transit Gateway라는 서비스가 있다.
VPC들을 한 데 모아 허브 형식으로 중앙에서 관리하고 각각의 VPC에 이 허브를 통해 액세스할 수 있게 된다.
반면 구글엔 두 가지의 솔루션이 있다.
-
피어링
GCP는 피어링을 맺을 시 옵션에 'import custom routes', 'export custom routes'라는 옵션들이 있는데 둘 다 체크해줄 수 있다.
둘 다 체크해주면 a > b > c 피어링 했을 때 a > c로 연결이 된다. -
Shared VPC
연결할 VPC들이 존재하는 프로젝트와 따로 shared VPC용으로 프로젝트를 만들어서 연결해줄 수 있다. 같은 프로젝트 내에서는 안되고 따로 프로젝트를 파야하니까 Transit Gateway와 같이 중앙집중식으로 관리할 수 있다는 장점이 있지만 그뿐이지 싶다.
Load Balancer
GCP는 VPC가 글로벌 단위이고 http LB도 기본적으로 글로벌 LB이다.
GCP의 LB는 VPC 바깥에 존재하고 AWS의 LB는 VPC내부에 존재한다.
또한 AWS의 LB는 사실상 콘솔에선 보이지 않지만 AWS에서 LB라는 서비스의 컨테이너가 올라가는 것이다. 때문에 pre-warming이라는 것이 있는데 이것을 신청하면 AWS측에서 LB 컨테이너를 Scaling해준다.
GCP는 이런 pre-warming과 같은 기능은 없다.
동작 방식은 AWS의 LB와 비슷하다.
하지만 설정과 용어가 조금 다르므로 어색할 수 있다.
GCP에선 프론트, 백엔드 서비스 구성을 해줘야 한다.
받아올 트래픽을 프론트 구성에서 설정해주고 그 트래픽을 백엔드 서비스에 넘겨주는 것이다.
이때 백엔드 서비스에서 만들어주는 것이 AWS에서 Target Group, Autoscaling Group에 해당되는 상태 점검, Instance Group이다.
(정확히는 Managed Instance Group이다. Instance Group에 내가 수동으로 이미지가 전혀 다른 vm들을 넣을 수 있지만 Autoscaling이 불가능한 Unmanaged Instance Group을 생성할 수도 있기 때문이다.)
AWS에서 Autoscaling Group은 Launch Template에 근거해서 만들어줄 수 있었다. 이건 GCP도 마찬가지이다. 템플릿만 있으면 된다.
그리고 현재는 아니지만 예전에 GCP 네트워크 LB의 헬스체크가 http밖에 안됐었다.
http로 하나 tcp로 하나 뭐가 다르지?
- http는 반드시 200ok를 서버에서 던져줘야 healthy하다고 판단.
- tcp는 포트만 open되어 있으면 healthy하다고 판단.
또한 LB에 붙여준다는 백엔드 서비스에서 GCP는 Instance Group만 붙여줄 수 있는 것이 아니다. 총 세가지를 붙여줄 수 있다.
-
Instance Group
-
Cloud Storage
-
Network Endpoint Group
Network Endpoint Group
(AWS와의 차이점은 아니고 GCP에서 최근에 출시된 기능이 있어서 소개하려 한다.)
일반적으로 쿠버네티스에서 쓰이는 것인데 네트워크 엔드포인트 그룹(NEG)은 백엔드 엔드포인트 또는 서비스 그룹을 지정하는 구성 객체이다.
아래와 같은 구성이 가능할까?
원래는 안됐었다. 동일 서브넷에 있는 인스턴스와 인터넷에 있는것만 처음에 허용됐었다.
(아래 사진의 옵션 중에 있음.)
하지만 네트워크 엔드포인트 옵션에 Hybrid Connect가 추가됐다. Interconnect는 물론 LB를 통해서도 On-Prem으로 접근할 수 있는 것.
물론 Hybrid Connect를 생성해주고 AWS 라우팅 테이블과 GCP Cloud Router에서 LB 헬스체크 대역을 허용해줘야 한다.
