GCP 마이그레이션 세팅 다시하기
GCP에서 GCP로
GCP에서는 300 크레딧을 무료로 사용할 수 있게 주기 때문에 처음에 POC를 만들거나 간단한 클라우드 테스트를 하기 정말 좋은 것 같습니다. Google Study Jam을 하면서 학습한 내용을 간단하게 적용해 보는 서비스를 만들어보고 싶다는 생각에 Gemini를 이용해 보기로 했습니다. Gemini 사용하고 크레딧을 무료로 사용할 수 있는 GCP로 프로젝트를 배포를 했었고 최근에는 크레딧을 다 사용한 뒤 계정을 변경해 다시 적용해보게 되었습니다. AWS 마이그레이션도 잠깐 고민했었지만 비용과 서비스 통일성을 고려했을 때 다시 GCP를 이용하는게 맞다고 판단했습니다.
처음 배포를 하면서 다양한 이슈를 만났고 그걸 다 옵시디언에 기록해두었지만 너무 맨땅에 헤딩한 것처럼 학습 부족으로 얻은 이슈들도 많았어서 테크 블로그 포스팅에 고민이 많았는데 이번 기회로 하나씩 순서대로 GCP 마이그레이션 과정을 작성해보고자 합니다.
현재 프로젝트는?
목표로 하는 프로젝트 구조도는 다음과 같습니다. 현재는 백엔드만 있는 서비스이기 때문에 간단한 구성의 프로젝트 구조도 형태입니다.
- GitHub Action을 사용해서 Docker 이미지를 Artifact Registry에 배포하고 그 다음 GCE 배포를 합니다.
- 로드밸런서에 SSL 인증으로 HTTPS를 이용한 서비스가 가능하게 합니다.
- 사전에 구매해 둔 가비아 도메인도 DNS 설정을 해줍니다.
- 로드밸런서로 상황에 따라 인스턴스를 증가시켜 유동적으로 이슈에 대응하게 합니다.
- Default가 아닌 VPC 네트워크 설정으로 보안 처리를 해줍니다.
초간단 마이그레이션
실제로 GCP 내에서 다른 계정으로 프로젝트를 옯기는 방법이 있겠지만 무료가 종료된 시점에서는 프로젝트 접근이 막혀서 되지 않았으므로 다시 세팅하는 방법을 선택했습니다. 그래서 결과적으로 마이그레이션이라 썼지만 그냥 다시 만드는(?) 것과 동일합니다. 순서는 임의대로 지정해서 하면 되지만 몇 번 GCP 배포를 하면서 익숙해진 방식으로 작성했습니다.
1. IAM 세팅하기
먼저, IAM을 세팅합니다. 서비스 계정을 GCE에 적용하기 위해 연관된 Artifact Registry, Cloud SQL, Compute 인스턴스 관리자(v1), Vertex AI 권한을 부여해줍니다. 사용에 따라 관리자 또는 리더를 선택해 주었습니다. 여기서 Artifact Registry는 Docker 이미지를 올리는 곳이고, Cloud SQL는 데이터베이스로 Postgresql을 사용했습니다. Vertex AI는 Gemini를 사용하기 위해 필요한 API로 기능을 추가해주었습니다.
2. VPC 만들기
네트워크 설정은 GCP에서 제공하는 default 값을 절대 사용하지 말라는 말이 많아서 새로 이 프로젝트에 적용할 것으로 만들었습니다. 그리고 일단 방화벽 인그레스 포트로 TCP 443, 22, 8080을 열어두었고 필요에 따라 확인하면서 추가합니다. VPC 네트워킹 및 Google Compute Engine 시작하기와 같이 사용해보면서 감을 익힐 수 있기 때문에 문서나 이런 코스를 잘 찾아보면 큰 도움이 됩니다. 설정 후에는 telnet으로 제대로 세팅되어 있는지 여부를 확인합니다.
3. 인스턴스 만들기
GCE 인스턴스를 만들면 바로 인스턴스 그룹으로 생성이 가능하기 때문에 템플릿 용도로 사용될 인스턴스를 만들어줍니다. 기본 OS, 용량 설정을 해주고 네트워킹 부분에서 앞서 열어둔 포트의 네임을 동일하게 작성해서 대상 포트로 적용될 수 있도록 합니다. 컨테이너 배포시 이전에 .env를 GitHub Action으로 처리해보려고 했는데 그것보다는 환경변수 어떻게 가지고 갈까?에서 고민한 것처럼 직접 GCE 컨테이너 환경변수 설정을 해주는 것이 좋습니다. 왜냐면 그전에 작성한 내역을 볼 수 있기도 하고 로드밸런서에 의해 인스턴스 템플릿으로 자동 설정될 수 있도록 세팅이 가능하기 때문입니다.
여기서 네트워크 태그 부분이 정말 중요한게 여기서 health check 설정을 이후에 로드밸런서에서 할 때 추가하지 않으면 no health upstream만 나오고 정상 동작하지 않습니다. 더 자세한 내용은 이후 로드밸런서 부분에 추가하겠습니다.
이렇게 설정이 끝나면 상단에 이 VM을 기반으로 인스턴스 그룹 만들기 버튼으로 템플릿과 그룹을 동시 생성 가능합니다. 이 때, ID 및 API 액세스에서 액세스 범위를 한 번 더 확인해서 🚴 GCE에서 Vertex AI 연동 이슈와 같은 불상사가 생기지 않도록 합니다.
방화벽 부분에서는 HTTP 트래픽 허용, HTTPS 트래픽 허용, 부하 분산기 상태 점검 허용을 모두 선택합니다. 인스턴스 그룹 구성 부분에서는 자동 확장 부분에서 연결이 안될 때 인스턴스의 수를 얼마까지 자동 확장할지 지정합니다.
4. 도메인, 로드밸런서 세팅하기
준비한 도메인을 Cloud DNS 영역에 등록해줍니다. 영역을 만들고 나면 표준추가로 네임서버(NS)를 등록해주고 www, api로 시작하는 요청을 만들기 위해 서브 도메인을 A 유형으로 추가합니다.
- A 레코드는 IPv4 주소를 AAAA 레코드는 IPv6 주소를 연결합니다.
- CNAME 레코드로는 도메인의 별칭이나 다른 도메인으로 리디렉션 처리를 할 수 있습니다.
- MX 레코드는 이메일을 수신하는 서버, TXT 레코드는 도메인과 관련된 임의의 텍스트 정보를 저장합니다.
- NS 레코드는 도메인 등록 업체에서 호스팅하는 네임 서버의 이름을 포함합니다. 부하 분산과 여러 위치에 배치하므로써 가용성과 성능향상을 위해 일반적으로 여러 개의 네임서버로 관리합니다.
프로젝트 내에 SSL 처리를 하거나 개별 인스턴스에 인증서 관리를 해야하는 상황이라면 너무 번거럽고 일정 기간(무료로 사용할 수 있는 90일 기한 인증서의 경우) 갈아줘야한다는 단점이 존재합니다. 따라서 구글 관리형 SSL로 로드밸런서를 통한 인증 확인 후 백엔드 서비스에서는 http 포트를 열어 통신하는 방향으로 정했습니다.
로드밸런서는 공식문서에 가이드가 잘 나와 있어서 순서대로 적용했습니다. 처음에 그룹과 템플릿 설정만 기본 인스턴스를 토대로 했기 때문에 상이하게 적용된 부분은 있지만 전체적인 흐름은 동일합니다. 프론트엔드 구성에서는 HTTPS(HTTP/2 및 HTTP/3 포함) 프로토콜로 구글 관리형 인증서를 연결해줍니다. 백엔드 서비스에서는 앞서 만든 인스턴스 그룹을 연결하고 캐시와 상태확인을 위한 설정을 해두었습니다. 자동확장은 대상 CPU 사용률 60%을 기준으로 해두었었는데 워낙 작은 인스턴스를 활용하니까 조금만 느려져도 확장이 발생하는 바람에 그 비율을 높이고 인스턴스 성능을 높여서 템플릿을 다시 만들었습니다.
완료되면 템플릿에 의해 만들어진 인스턴스가 새로 생성되는 것을 볼 수 있습니다. 이 때, Cloud SQL 단에서 생성된 인스턴스를 열어주고 고정 IP 예약을 통해 번거롭지 않도록 설정해둡니다.