개요
웹사이트 개편 작업 이후 도입된 외부 API는 요청 헤더값에 우리 웹사이트의 vm 인스턴스 정보가 담긴다. 이러한 VM 인스턴스 IP 주소는 유동 IP로 설정되어있어서, IP가 변경될 때마다(배포할 때마다 - 블루∙그린배포) 매번 VM 인스턴스의 IP를 화이트리스트에 업로드해야 한다. 이러한 수동 업데이트 방식은 문제의 소지가 다분하다.
이 문제를 해결하기 위한 개편작업을 담당하였다. 그 과정을 시리즈로 블로그에 정리해보려 한다. 이 포스팅은 그 시작점인 Instance Template의 설정과 MIG이다.
Instance Template
- Instance Template은 MIG를 통해 서버를 운영하기 위해서 가상머신 생성을 위한 일종의 규칙 사항들을 정리해 놓은 것이다.
- GCP의 Instance Template은 immutable한 특성이 있다. 즉, 수정이 불가능하기 때문에 처음 작성을 할 때 네트워크 스펙, 서버 스펙 등에 대해 신중하게 생성해야 한다.
- 위 템플릿 관리 페이지 경로로 접속하여 인스턴스 템플릿 만들기를 통해서 정의할 수 있다.
사용할 이름과 머신 스펙, 가용성 정책을 정한다.
가용성 정책은 표준/스팟 두 가지 선택지가 있는데, 스팟으로 해두면 용량이 부족할 때 인스턴스가 중단될 수 있으므로 위험성이 크다. 저렴하다는 장점이 있어서 사용자 없이 연습을 할 때나 인스턴스가 중단되어도 상관없는 경우에만 사용하도록하자.
부팅 디스크는 원하는 운영체제와 버전, 크기를 세팅한다.
크기는 20 이상으로 키우는 것이 좋다. 이것도 너무 작게 잡으면 인스턴스가 강제로 중단될 위험성이 있다.
GCP는 Cloud API를 사용하기 위해서 서비스 계정이 필요하므로 서비스 계정을 설정하고 액세스 범위를 모든 것으로 잡는다.
로드밸런서 세팅을 위해 부하 분산기 상태 점검 허용을 해준다.
그리고 필요한 네트워크 태그들을 설정하는데, firewall-allow-health-check 관련해서는 따로 트러블 슈팅 포스팅을 첨부할 것이다.
웹 애플리케이션을 배포할 것이므로, HTTP와 HTTPS 트래픽을 허용한다.
템플릿을 생성할 때 고정 외부 IP를 쓰기 위해서 VPC > 네트워킹에서 고정 ip를 생성한다. 이후 인스턴스 템플릿을 정의할 때 위와 같이 할당만 해주면 된다. 고정 외부 ip를 생성하는 부분은 이 포스팅에서는 생략하도록 한다.
Instance Group
Instance Template을 생성한 이후로는 IG를 생성해 준다.
- 관리형 인스턴스 그룹(MIG)은 자동 확장, 자동 복구, 리전 배포, 자동 업데이트 등등 자동화된 인스턴스 그룹 관리 서비스다.
앞서 설명했듯, Instance Group은 인스턴스 템플릿에 의해 생성된다. 그래서 인스턴스 그룹 만들기를 하면 위와 같이 템플릿 옵션이 나온다. 이렇게 인스턴스 그룹을 만들면 VM 인스턴스를 관리하고 확장하기 쉽다.
인스턴스 그룹을 통해 서버를 세팅하게 되면 실제로 간단하게 서버 하나 띄우고 사용했던 것과 달리, VM 인스턴스를 관리해 주는 관리자가 생기는 것이기 때문에 VM 인스턴스에 직접적으로 접근 불가능하다.
인스턴스 템플릿에 정의된 내용대로 인스턴스 그룹을 생성했기에, 외부 IP 주소에는 인스턴스 템플릿에서 정의한 IP 주소가 잘 담겨있는 것을 확인할 수 있다.
참고로 IP에 대한 자세한 내용은 GCP의 VPC 네트워크 > IP주소에서 확인할 수 있다.
IG를 통한 VM 생성 및 블루/그린 배포
지금까지 GCP에서 ① Instance Template을 생성하는 방법, 이 서버의 ② 이 Template으로 Instance Group과 VM 인스턴스를 생성하는 방법을 알아보았다.
MIG를 통해 블루∙그린 방식으로 서버를 배포하고 무중단으로 운영하는 방법은 다음과 같다.
애플리케이션 변동사항이 생겼을 때 IG의 RESTART/REPLACE VMS로 배포를 하게되는데, 이때 배포 방식을 바꾸기로 선택하면 SUBSITUTE 방식으로 배포가 된다. (블루-그린 배포: 이전 버전과 거의 동일한 새 버전으로 점진적으로 이전하는 애플리케이션 릴리스 방식)
- SUBSTITUE 방식은 기존 인스턴스를 삭제를 함과 동시에 새로운 인스턴스를 만들기 때문에 시간이 단축 가능과 무중단 배포가 가능한 대신 이름과 ip가 변경된다.
- 만약 외부 통신을 할 때 항상 고정된 공인 IP를 사용해야 한다면 NAT 구축을 고려할 수 있다.
'DevOps > DevOps' 카테고리의 다른 글
[GCP] Google Cloud Load Balancer, GCP 로드밸런서 구축 | Cloud NAT와 로드밸런서 | Cloudflare (0) | 2024.01.29 |
---|---|
[GCP] Cloud Nat Gateway 구축 과정 및 작동 방식 (1) | 2024.01.29 |
[GCP] Cloud Build 커밋/푸시없이 트리거 실행하기 (0) | 2024.01.15 |
[Redis] Redis 4편. 운영 방식과 호스팅 (0) | 2024.01.08 |
[Redis] Redis 3편. Spring Boot와 Redis | Lettuce, RedisTemplate, RedisRepository (1) | 2024.01.08 |