개요
회사 서버 개편 작업을 위해서 다음과 같은 작업을 수행하였다.
- Instance Template, Instance Group 생성 (https://cobinding.tistory.com/229)
- Cloud NAT Gateway 구축 (https://cobinding.tistory.com/244)
[GCP] Cloud Nat Gateway 구축 과정 및 작동 방식
요구사항 서버 상황 현재 VM 인스턴스의 외부 ip는 임시 ip로 되어있다. 배포는 수동으로 “인스턴스 바꾸기”를 통해서 새로운 인스턴스 이름과 ip를 부여받는 방식으로 운영하고 있다. 인스턴스
cobinding.tistory.com
[GCP] Instance Template과 Instance Group을 통한 VM 서버 생성과 블루-그린 배포
개요 웹사이트 개편 작업 이후 도입된 외부 API는 요청 헤더값에 우리 웹사이트의 vm 인스턴스 정보가 담긴다. 이러한 VM 인스턴스 IP 주소는 유동 IP로 설정되어있어서, IP가 변경될 때마다(배포할
cobinding.tistory.com
이제 클라이언트 요청을 효율적으로 처리하는 로드밸런서까지 구축하여 개편을 마무리해보자..!
Google Cloud Load Balancing
GCP에서 제공하는 로드밸런서는 세 가지 종류가 있다.
① 애플리케이션 레이어 7 부하 분산기
② TLS 오프로딩을 지원하는 레이어 4 부하 분산기
③ IP 프로토콜을 지원하는 네트워크 부하 분산기
필자는 http/https 요청을 처리하는 웹 애플리케이션 프로젝트를 배포하여 운영할 것이므로, 1번 애플리케이션 레이어 7 부하 분산기를 구축한다. 애플리케이션 부하 분산기는 프록시 기반의 부하 분산기로, 단일 IP 주소로 서비스를 실행 및 확장한다.
외부/내부 애플리케이션 부하 분산기
외부 애플리케이션 부하 분산기
- GFE 또는 Envoy 프록시에 관리형 서비스로 구현된다. 클라이언트는 인터넷 어디에서나 이 부하분산기에 연결할 수 있다. 전역/리전 따로 설정이 가능하다. 전역으로 설정하면 단일 Anycast IP가 전세계 여러 지역에 트래픽을 분산한다.
내부 애플리케이션 부하 분산기
- Andromeda 네트워크 가상화 스택 및 Envoy 프록시를 기반으로 구축된다. 동일한 VPC 네트워크에 있는 클라이언트 또는 VPC 네트워크에 연결된 클라이언트에서만 액세스할 수 있는 내부 IP 주소를 사용한다.
GCP Load Balancer 아키텍처
로드밸런서의 기본적인 아키텍처이다.
필자의 경우 MIG 백엔드가 있는 외부 애플리케이션 부하 분산기를 구축하는 상황이므로 아래 아키텍처가 더 정확하다.
각각 순서에 대한 이벤트는 다음과 같다.
- 클라이언트가 외부 IPv4 주소로 요청을 보낸다.
- HTTPS 부하 분산기는 이 요청을 HTTPS 프록시로 전달한다. GCP Load Balancer 외부 부하분산기는 프록시 기반의 부하 분산기다.
- 대상 프록시는 URL 맵의 규칙을 사용하여 단일 백엔드 서비스가 모든 요청을 수신하는지 확인한다.
- 부하 분산기는 백엔드 서비스에 인스턴스 그룹이 하나만 있는지 확인하고, 해당 그룹의 VM으로 요청을 전달한다.
- VM은 사용자가 요청한 콘텐츠를 제공한다.
Google Cloud Load Balancing 구축 과정
외부 고정 IP 만들기
외부 전역 부하분산기에 연결해줄 고정 IP를 생성한다.
사용자는 이 부하분산기의 IP를 통해 웹사이트에 접속할 수 있고, outbound는 일정하게 NAT ip를 통해 나간다.
프론트엔드 구성
프론트엔드 구성은 클라이언트가 접속하는 데에 사용될 IP 주소와 포트를 지정한다.
- VPC 네트워크에서 만들어준 전역 외부 고정 IP를 할당해준다.
- 프로토콜은 웹사이트 스펙에 맞게 HTTPS로 설정한다. HTTPS의 기본 포트인 443을 설정한다.
- HTTPS를 사용하기 위한 인증서를 설정한다.
- HTTP-HTTPS 간 리디렉션은 HTTPS 부하 분산기와 동일한 IP 주소를 사용하는 추가적인 부분 HTTP 부하 분산기를 만들고 수신되는 HTTP 요청을 부하 분산기의 HTTPS 프론트엔드로 리디렉션하는 것이다. 체크 해준다.
백엔드 구성
- 백엔드 프로토콜은 프론트엔드로부터 요청을 받는 것이므로 HTTP로 설정한다. HTTP의 기본 포트는 80이다.
- 이전 게시물에서 만든 Instance Group을 백엔드 단으로 설정해준다.
[GCP] Instance Template과 Instance Group을 통한 VM 서버 생성과 블루-그린 배포
개요 웹사이트 개편 작업 이후 도입된 외부 API는 요청 헤더값에 우리 웹사이트의 vm 인스턴스 정보가 담긴다. 이러한 VM 인스턴스 IP 주소는 유동 IP로 설정되어있어서, IP가 변경될 때마다(배포할
cobinding.tistory.com
상태 확인을 위한 GCP 서비스를 하나 생성해준다. 이를 통해 백엔드 인스턴스가 제대로 응답하는지 확인할 수 있다.
VPC default에 health check 방화벽 설정하기
(이 작업은 VPC 네트워크에서 진행한다.)
HTTP 로드 밸런서는 상태 확인을 통과한 인스턴스에게만 트래픽을 보낸다!
그래서 이 상태확인에 걸리지 않도록 로드 밸런서 IP에 상태 확인 방화벽 규칙을 할당해주어야 한다.
자세한 내용은 이 문서에서 확인할 수 있는데,
상태 점검 만들기 | 부하 분산 | Google Cloud
의견 보내기 상태 점검 만들기 컬렉션을 사용해 정리하기 내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요. Google Cloud는 백엔드 인스턴스가 트래픽에 제대로 응답하는지 확인하는 상태
cloud.google.com
HTTP는 전송 레이어에서 TCP 통신을 하므로, 프로토콜 및 포트는 tcp:80으로 설정하고
IP 범위는 위 공식 문서에 나와있는 외부 애플리케이션 부하 분산기에 사용되는 소스 IP 범위를 할당한다.
라우팅 규칙 설정
라우팅 규칙은 특별한 세팅이 필요없다면 단순한 모드로 설정해준다.
여기까지 모두 세팅하고 점검을 한 뒤 만들기를 누르면 로드밸런서가 잘 생성된다.
미리 생성한 외부 ip에 접속 요청을 날려서 해당 서비스에 접근할 수 있다. 이 ip를 도메인에 연결하여 사용자가 좀 더 간편하게 웹사이트를 이용할 수 있도록 도메인까지 설정해보자.
Cloudflare를 통해 도메인을 설정하고 접속해보기
현재 회사에서는 Cloudflare라는 DNS 서비스를 이용하고 있다.
- VM 인스턴스에 접속하여 소스코드 저장소에서 소스를 가져오고 웹 애플리케이션 배포를 해준다.
- 이후 로드밸런서 프론트 IP를 도메인과 연결하여 접속을 확인해보면 잘 되는 것을 확인할 수 있다!!
Linux 명령어를 통해 outbound 확인하기
ssh키로 VM 인스턴스에 접속하여 outbound ip를 확인해보자.
콘솔에서는 분명히 개별 vm은 외부 ip를 가지지않고, NAT가 잘 할당되어있지만 직접 확인하는 작업도 필요하다.
해당 명령어를 통해 Public IP를 확인할 수 있다. 이 명령어를 쳐서 NAT와 같은 IP가 나온다면 성공한 것이다🎉
'DevOps > GCP' 카테고리의 다른 글
[GCP] GCP 하나의 LB로 여러 서비스 운영하기 (1) | 2024.05.13 |
---|---|
[GCP] Cloud Logging 에러 사항을 메일로 모니터링하기 (0) | 2024.02.14 |
[GCP] Cloud NAT 구축 과정 및 작동 방식 (1) | 2024.01.29 |
[GCP] Instance Template과 Instance Group을 통한 VM 서버 생성과 블루-그린 배포 (0) | 2024.01.29 |
[GCP] Cloud Build 커밋/푸시없이 트리거 실행하기 (0) | 2024.01.15 |