VM을 생성하면 아래와 같이 내부 IP가 생기고 사용자의 설정에 따라 외부 IP도 생긴다.
여기서 내부 IP는 GCP 네트워크 내부에 설치된 가상 컴퓨터 안에서만 사용되고, 외부에서 접속을 해야할 경우 외부 IP를 사용해서 접속을 할 수 있다.
다만 외부 IP의 경우 인스턴스를 중지하고 다시 실행할 경우 IP주소가 바뀌는 문제가 있다.
따라서 VPC네트워크에서 외부 고정 IP 주소 예약을 통해서 인스턴스가 새로 시작할 때 연결될 IP를 고정시킬 수 있다.
이를 통해 프로그램을 동작할 때 IP주소를 따로 수정없이 실행이 가능하게 할 수 있다.
VPC에는 물리적 네트워크와 동일하게 라우팅 테이블이 있다.
따라서 제공되는 사용자가 별도로 라우터를 프로비저닝하거나 관리할 필요가 없고 같은 네트워크 내 인스턴스 간, 서브네트워크 간, Google Cloud의 다양한 존간, 외부 IP 주소 없이 통신이 가능하다.
VPC는 글로벌 방화벽을 제공하여 인스턴스에 대한 들어오고 나가는 트래픽을 제어 가능하다.
이는 네트워크 태그를 사용해 규칙 정의 가능한데 태그에 따라 특정 포트의 트래픽을 허용하는 규칙을 통해 IP주소와 관계없이 같은 태그를 가진 모든 VM에 적용할 수 있다.
만약 여러개의 Google Cloud프로젝트가 있어 VPC가 서로 통신해야하는 경우 두 VPC 간 트래픽 교환을 위해 VPC 피어링 관계를 설정 하여 트래픽을 교환할 수 있다.
또는 IAM(Identity Access Management)을 활용하여 다른 프로젝트에 있는 VPC와의 상호작용을 제어 가능하다.
VPC네트워크를 온프레미스 네트워크나 다른 클라우드 네트워크에 연결하는 법
1. Virtual Private Network(VPN)
Cloud VPN을 사용해 터널링을 하거나, 더 동적인 연결을 원한다면, Cloud Router를 활용할 수 있다.
Cloud Router는 Border Gateway Protocol(BGP)을 통해 Google VPC와 다른 네트워크 간 라우팅 정보를 교환하게 한다. 이를 통해 Google VPC에 새로운 서브넷을 추가하면 온프레미스 네트워크가 자동으로 해당 서브넷의 라우팅 정보를 받을 수 있다. 하지만 인터넷을 사용한 연결은 보안 문제나 대역폭 신뢰성 때문에 항상 최선의 선택은 아니다.
2. Direct Peering
피어링은 Google의 접속 지점이 있는 동일한 공용 데이터 센터에 라우터를 배치하고 이를 통해 네트워크 간 트래픽을 교환하는 방식이다. Google은 전 세계적으로 100개 이상의 접속 지점을 운영한다. 접속 지점에 없는 고객은 Carrier Peering 프로그램의 파트너와 협력해 연결할 수 있다. Carrier Peering은 서비스 제공자의 네트워크를 통해 온프레미스 네트워크에서 Google Workspace 및 Google Cloud 제품에 직접 액세스하도록 한다. 하지만 피어링은 Google의 서비스 수준 협약(SLA)에 포함되지 않는다는 단점이 있다.
3. Dedicated Interconnect
이 옵션은 Google과의 하나 이상의 직접적인 전용 연결을 제공하며, 연결이 Google의 사양을 충족하면 최대 99.99%의 SLA가 보장된다. 또한, 이러한 연결은 VPN을 백업으로 사용해 신뢰성을 더욱 높일 수 있다.
4. Partner Interconnect
이는 지원되는 서비스 제공자를 통해 온프레미스 네트워크와 VPC 네트워크 간의 연결을 제공한다. Partner Interconnect는 데이터 센터가 Dedicated Interconnect 접속 시설에 물리적으로 도달할 수 없는 위치에 있거나 10Gbps 전용 연결이 필요하지 않은 경우 유용하다. 필요에 따라 Partner Interconnect는 중요한 서비스 또는 다소의 다운타임을 허용할 수 있는 애플리케이션을 지원하도록 구성할 수 있다. Dedicated Interconnect와 마찬가지로 Google의 사양을 충족하는 경우 최대 99.99% SLA가 보장되지만, 제3자 서비스 제공자에 의해 제공되는 Partner Interconnect와 Google 네트워크 외부의 문제는 Google의 책임이 아니다.
5. Cross-Cloud Interconnect
Google Cloud와 다른 클라우드 서비스 제공자 간 고대역폭 전용 연결을 제공한다. Google은 자체 네트워크와 다른 클라우드 서비스 제공자의 네트워크 간에 전용 물리적 연결을 설정하며, 이를 통해 Google VPC 네트워크와 다른 클라우드 서비스 제공자에 호스팅된 네트워크를 연결할 수 있다. Cross-Cloud Interconnect는 통합 멀티클라우드 전략을 지원하며, 단순화된 구성, 사이트 간 데이터 전송, 암호화를 제공한다. 이 연결은 10Gbps와 100Gbps 두 가지 크기로 제공된다.
클라우드 로드 밸런싱(Cloud Load Balancing)
애플리케이션에 접속할 때 사용자의 상황에 따라서 VM의 수를 조정할 필요가 있는 경우가 있다. 이는 로드 밸런서에서 자동으로 해주는데, 로드 밸런서의 주요 역할은 사용자의 트래픽을 애플리케이션의 여러 인스턴스에 분산시키는 것이다. 로드를 분산함으로써 애플리케이션이 성능 문제를 겪을 가능성을 줄인다. Google Cloud의 클라우드 로드 밸런싱은 완전히 분산된 소프트웨어 정의형 관리 서비스로, 모든 트래픽 유형에 대해 사용할 수 있다.
백엔드
백엔드는 클라우드 부하 분산기로부터 트래픽을 수신하는 끝점의 그룹이다.
여기에는 인스턴스 그룹이 있으며, 이는 여러 VM 인스턴스로 구성된다.
마이크로서비스 아키텍처에서는 단일 부하 분산기에 여러 백엔드 서비스를 연결할 수 있다.
프런트엔드
프런트엔드는 부하 분산기가 사용자 요청을 수신하는 접점이다.
사용자는 특정 IP 주소, 프로토콜, 포트를 통해 부하 분산기에 요청을 보낸다.
HTTPS를 사용할 경우 SSL 인증서를 부하 분산기에 할당하여 안전한 통신을 보장할 수 있다.
호스트 및 경로 규칙
부하 분산기는 요청의 호스트 및 경로에 따라 트래픽을 특정 백엔드로 리디렉션할 수 있다.
예를 들어, 경로 /A는 백엔드 A로, /B는 백엔드 B로 리디렉션된다.
SSL 종료 및 오프로딩
SSL 종료는 HTTPS 트래픽을 부하 분산기에서 처리하고, 부하 분산기와 VM 인스턴스 간 통신은 HTTP로 진행하는 방식이다.
이는 부하 분산기가 SSL/TLS 처리를 담당함으로써 VM 인스턴스의 부담을 줄이는 역할을 한다.
레이어 7에서는 SSL 종료를, 레이어 4에서는 TLS 종료라고 부른다.
TLS 종료 및 오프로딩
클라이언트와 부하 분산기 간에는 TLS를 사용하여 보안 통신을 수행하고, 부하 분산기와 VM 간에는 TCP를 통한 비보안 통신을 사용한다.
SSL/TLS 처리를 부하 분산기가 담당함으로써 VM 인스턴스는 HTTPS나 TLS 처리 부담에서 벗어나 요청 처리 성능이 향상된다. 결론적으로 클라우드 부하 분산은 사용자 요청을 효율적으로 분배하고 보안 통신을 지원하며, SSL/TLS 처리를 통해 인스턴스의 부하를 줄이는 데 기여한다.
클라우드 로드 밸런싱의 특징
- VM 관리 필요 없음: 로드 밸런서가 VM에서 실행되지 않으므로, 이를 관리하거나 확장할 필요가 없다.
- 다양한 트래픽 지원: HTTP/HTTPS, TCP, SSL, UDP 등 모든 종류의 트래픽에 대응 가능하다.
- 크로스 리전 로드 밸런싱: 여러 지역에 걸쳐 로드 밸런싱을 수행하여 자동으로 다중 지역 장애를 처리한다. 만약 백엔드가 비정상 상태로 전환될 경우 트래픽을 점진적으로 다른 곳으로 이동하는 방식을 통해 장애를 처리한다.
- 빠른 반응성: 사용자 수, 트래픽, 네트워크, 백엔드 상태 등 다양한 조건 변화에 빠르게 대응한다.
- 사전 준비 불필요: 갑작스러운 수요 급증이 예상되더라도 Google에 미리 알릴 필요 없이, 즉각적으로 확장 가능하다.
프로토콜과 계층 구조
네트워크 통신은 여러 레이어로 구성되며, 주요 레이어는 네트워크 계층, 전송 계층, 응용 계층이다.
● 네트워크 계층: IP(인터넷 프로토콜)를 사용하여 비트와 바이트를 전송한다. 신뢰성이 낮아 데이터 손실이 발생할 수 있다.
● 전송 계층: 데이터를 안정적으로 전송하며, 주요 프로토콜로 TCP, TLS, UDP가 있다.
- TCP(전송 제어 프로토콜): 신뢰성과 순서를 보장한다.
- TLS(전송 계층 보안): TCP에 보안 기능을 추가하여 데이터를 암호화한다.
- UDP(사용자 데이터그램 프로토콜): 신뢰성을 희생하고 성능을 중시하며, 실시간 스트리밍과 같은 고성능이 필요한 애플리케이션에 사용된다.
● 응용 계층: 사용자와 가까운 레이어로, HTTP, HTTPS, SMTP, FTP 등의 프로토콜이 있다.
- HTTP/HTTPS: 웹 애플리케이션 통신에 사용되며, HTTPS는 암호화된 통신을 지원한다.
- SMTP: 이메일 전송에 사용된다.
- FTP: 파일 전송에 사용된다.
모든 레이어는 상위 레이어를 지원하며, 각 레이어가 협력하여 데이터를 안전하고 효율적으로 전달한다. 일부 고성능 애플리케이션은 응용 계층을 건너뛰고 전송 계층으로 직접 접근한다. 통신 프로토콜은 컴퓨터가 서로 대화하는 공통 언어이며, 각 프로토콜은 특정 목적에 맞게 설계되었다.
Google Cloud의 로드 밸런싱 솔루션 분류
Google Cloud는 OSI 모델의 계층과 기능에 따라 다양한 로드 밸런싱 솔루션을 제공한다.
1. 애플리케이션 로드 밸런서
동작 계층: 애플리케이션 계층
지원 트래픽: HTTP 및 HTTPS
HTTP 및 HTTPS 트래픽을 처리하도록 설계되어 콘텐츠 기반 라우팅, SSL/TLS 종료와 같은 고급 기능이 필요한 웹 애플리케이션에 사용된다.
외부(인터넷 연결)와 내부 애플리케이션 모두 지원하고, 정의된 규칙에 따라 들어오는 트래픽을 여러 백엔드 인스턴스로 분산한다.
2. 네트워크 로드 밸런서
동작 계층: 전송 계층
지원 트래픽: TCP, UDP 및 기타 IP 프로토콜
- 프록시 네트워크 로드 밸런서
클라이언트 연결을 종료하고 새 연결을 백엔드 서비스에 설정한다.
고급 트래픽 관리 기능 제공하고, 온프레미스 및 다양한 클라우드 환경의 백엔드 지원도 한다.
- 패스스루 네트워크 로드 밸런서
연결을 수정하거나 종료하지 않고 그대로 백엔드로 전달하는 것으로 원본 소스 IP 주소를 유지하며, 직접 서버 응답이 필요한 애플리케이션에 적합하다.
Load balance 유형 | 트래픽 유형 | 프록시 또는 패스스루 |
대상 포트 |
외부 HTTP(S) | 글로벌, 외부, HTTP 또는 HTTPS | 프록시 | HTTP: 80 또는 8080HTTPS: 443 |
내부 HTTP(S) | 지역, 내부, HTTP 또는 HTTPS | 프록시 | HTTP: 80 또는 8080HTTPS: 443 |
SSL 프록시 | 글로벌, 외부, SSL 오프로딩이 적용된 TCP | 프록시 | 많은 포트 리스트 |
TCP 프록시 | 글로벌, 외부, SSL 오프로딩이 없는 TCP | 프록시 | 많은 포트 리스트 |
외부 네트워크 TCP/UDP | 지역, 외부, TCP 또는 UDP | 패스스루 | 모든 포트 |
내부 네트워크 TCP/UDP | 지역, 내부, TCP 또는 UDP | 패스스루 | 모든 포트 |
이 표는 클라우드 부하 분산기의 주요 특징을 나타낸다.
DNS (Domain Name Service)
DNS는 인터넷 호스트명을 IP 주소로 변환하는 역할을 하는것으로 Google의 대표적인 무료 서비스 중 하나로 8.8.8.8이 있다. 이 서비스는 전 세계에 공개된 퍼블릭 DNS를 제공한다. Google은 이를 위해 고도로 발전된 DNS 인프라를 보유하고 있다.
Cloud DNS
Google Cloud에서는 Cloud DNS를 통해 Google Cloud에서 구축된 애플리케이션의 호스트명과 주소를 전 세계에서 쉽게 찾을 수 있도록 돕는다. Cloud DNS는 Google의 인프라 위에서 실행되는 관리형 DNS 서비스로, 낮은 대기 시간과 높은 가용성을 제공하며 비용 효율적인 방식으로 애플리케이션과 서비스를 사용자에게 제공한다. 사용자가 게시한 DNS 정보는 전 세계의 중복된 위치에서 제공된다.
Cloud DNS는 프로그래밍이 가능하며, Cloud 콘솔, CLI, API를 통해 수백만 개의 DNS 영역과 레코드를 게시하고 관리할 수 있다.
edge cache
엣지 캐싱은 캐싱 서버를 사용하여 콘텐츠를 사용자에게 더 가까운 위치에 저장하는 것을 말한다. 이를 통해 Cloud CDN을 활용해 애플리케이션의 콘텐츠 전달을 가속화할 수 있다. 이를 사용하면 고객은 더 낮은 네트워크 지연을 경험하고, 콘텐츠의 원본 서버는 부하가 줄어들며 비용 절감도 가능하다.
Application Load Balancer를 설정한 후에는 Cloud CDN을 단일 체크박스로 활성화할 수 있다. 물론 다른 CDN 서비스도 많이 존재하며, 이미 사용 중인 CDN이 있다면 Google Cloud의 CDN Interconnect 파트너 프로그램에 포함될 가능성이 높아 그대로 사용할 수 있다.
Google Cloud 하이브리드 클라우드
하이브리드 클라우드는 온프레미스 데이터센터와 클라우드 환경을 연결하여 사용하는 네트워크 아키텍처이다.
온프레미스 환경: 기업 내부에서 직접 운영하는 데이터센터를 뜻하는 것으로 높은 보안 요구사항, 자체 인프라 제어 가능하다.
클라우드 환경: Google Cloud 같은 퍼블릭 클라우드를 뜻하는 거승로 자동 확장, 유연한 비용 모델, 높은 가용성을 가지고 있다.
Google Cloud에서는 온프레미스와 클라우드를 연결하는 3가지 주요 옵션을 제공한다.
옵션 | 연결 방식 | 대역폭 | 네트워크 유형 | SLA |
Cloud VPN | VPN(IPSec) | 최대 3Gbps | 인터넷(공용) | 99.9% ~ 99.99% |
Cloud Interconnect | 물리적 연결 | 최대 100Gbps | 사설(Private) | 99.99% |
Direct Peering | 네트워크 피어링 | 다양한 속도 | 사설(Private) | 미보장 |
Cloud VPN
Cloud VPN은 온프레미스 네트워크와 Google Cloud VPC를 인터넷을 통해 연결하는 방식이다.
IPSec VPN 터널을 사용하여 데이터를 암호화하고 인터넷을 통해 전송한다.
공용 네트워크를 사용하므로 보안에 신경 써야 한다.
저비용이며 빠르게 설정 가능하지만 고속 트래픽에는 적합하지 않는다.
따라서 온프레미스에서 Google Cloud로 보안이 필요한 트래픽을 인터넷을 통해 전송할 때, 상대적으로 낮은 대역폭으로 연결할 때, 빠르게 설정하고 비용을 절감하고 싶을 때 주로 사용한다.
Cloud Interconnect
Cloud Interconnect는 온프레미스와 Google Cloud를 직접 연결하는 고속 물리적 네트워크이다.
인터넷을 거치지 않고 사설 네트워크로 직접 연결하여 트래픽 비용이 절감된다.
대규모 데이터 전송이 가능하고 99.99% SLA 제공한다.
따라서 고속 트래픽이 필요한 경우, 보안상 인터넷을 거치지 않고 사설 네트워크를 원할 때, Google Cloud 리소스를 내부 사설 IP로 직접 접근하고 싶을 때 주로 사용한다.
Direct Peering
Direct Peering은 Google의 네트워크와 온프레미스 네트워크를 직접 연결하는 방식이다.
온프레미스와 Google 네트워크 간 직접 연결하고, Cloud Interconnect보다 더 낮은 수준의 네트워크 연결을 한다.
Google Cloud의 특정 서비스와 직접 통신이 가능하다.
SLA 보장되지 않기 때문에 기업 환경에서는 비추천한다.
따라서 Google Cloud API 서비스와 직접 통신할 때, 고가용성 및 보안이 덜 중요한 경우 주로 사용한다.
Cloud VPN vs Cloud Interconnect vs Direct Peering 비교
특징 | Cloud VPN | Cloud Interconnect | Direct Peering |
연결 방식 | IPSec VPN 터널 | 물리적 네트워크 연결 | 네트워크 피어링 |
네트워크 타입 | 공용(인터넷) | 사설(Private) | 사설(Private) |
대역폭 | 최대 3Gbps | 최대 100Gbps | 다양한 속도 지원 |
SLA | 99.9% ~ 99.99% | 99.99% | 없음 |
보안 | 암호화(IPSec) | 사설 네트워크 | 사설 네트워크 |
비용 | 낮음 (인터넷 사용) | 높음 (사설 네트워크) | 보통 |
Google API 직접 접근 | 불가능 | 가능 | 가능 |
주요 사용 사례 | 저속 연결, 빠른 설정 | 고속 대용량 트래픽 | Google API 전용 |
'컴퓨터 > 클라우드' 카테고리의 다른 글
[GCP Associate Cloud Engineer] 컨테이너 (0) | 2025.01.03 |
---|---|
[GCP Associate Cloud Engineer] Google Cloud storage (3) | 2025.01.02 |
[GCP Associate Cloud Engineer] 가상 네트워킹(Virtual Networking) & Compute Engine (0) | 2024.12.24 |
[GCP Associate Cloud Engineer] Google Cloud 서비스 계정과 상호작용 (2) | 2024.12.21 |
[GCP Associate Cloud Engineer] IAM 및 역할 관리 (3) | 2024.12.21 |