[GCP] Node.js(NestJS) 클라우드 배포 : (2) VM 인스턴스 데이터베이스로 Cloud SQL 이용하기

 

 

이전 포스팅에서 GCP에서 VM 인스턴스를 사용하여, Docker를 이용하여, API 서버 및 데이터베이스를 구축하는 과정을 살펴보았었다.

 

https://sjh9708.tistory.com/95

[GCP] Node.js(NestJS) 프로젝트를 Docker를 이용하여 클라우드 배포해보기

 

그렇다면 이번 포스팅에서는, Docker를 이용해서는 API 서버만 구축하고, 데이터베이스를 GCP에서 제공해주는 클라우드 관리형 데이터베이스로 바꾸어 보는 것을 해보려고 한다.

 

 

---

클라우드 관리형 데이터베이스의 이모저모

 

AWS든, GCP든 클라우드 관리형 데이터베이스는 매우 악명이 높다. 왜냐하면, 관리를 까딱 잘못했다가는 엄청난 과금의 원흉이 되기 때문이다.

 

우리는 그런 생각이 들 수 있다. VM 인스턴스 안에 데이터베이스 직접 깔아서 하면 되는데 왜 굳이 돈을 주고 클라우드 관리형 데이터베이스를 사는 것인가?

 

쉽게 말해서 두 가지 방법의 차이는 이거다. 돈 내고 전문가가 관리해주느냐, 돈 안내고 내가 관리하느냐.

 

데이터베이스를 인스턴스 안에서 Docker 등을 사용하여 직접 구축하여 사용한다고 가정해보자. 데이터베이스의 데이터가 날아가면 매우 난리가 나기 때문에, 백업 및 복원이 원활하게 돌아가도록 인프라를 구축해야 할 것이며, 트래픽을 모니터링하면서, 트래픽 상승에 대응해야 하고, 보안, 버전 패치 관리 등에도 힘써야 한다.

 

따라서 차라리 해당 과정을 유능하게 처리할 DevOps 개발자가 없다면, 클라우드 관리형 데이터베이스에 이를 맡기는 것도 한 가지 선택지일 수 있다.

 

아래는 클라우드 관리형 데이터베이스를 사용할 때의 장점이다.

 

• 간편한 관리: 데이터베이스 관리에 필요한 일련의 복잡한 작업을 대신 수행
• 자동 백업 및 복원: 클라우드 관리형 데이터베이스는 자동 백업 기능을 제공합
• 고가용성: 클라우드 관리형 데이터베이스는 여러 가용 영역에 데이터를 복제하여 시스템 고장에 대비
• 자동 확장: 데이터베이스 트래픽이 증가하면 클라우드 관리형 데이터베이스는 자동으로 확장하여 추가 리소스를 할당
• 보안: GCP는 데이터베이스 서비스에 엄격한 보안 기능을 포함시켜 민감한 데이터를 안전하게 보호
• 버전 및 패치 관리: 클라우드 관리형 데이터베이스 서비스는 데이터베이스 엔진의 버전 및 보안 패치 관리를 담당
• 모니터링 및 경고: 데이터베이스 서비스는 모니터링 및 경고 기능을 제공하여 성능 이슈나 잠재적인 문제를 식별
  
  
  

 

 

 

---

GCP Cloud SQL 생성하기

 

 

GCP 탭에서 SQL을 찾아서 들어가보자.

들어가서 인스턴스 만들기를 클릭하면, MySQL, PostgreSQL, MSSQL 등 데이터베이스 엔진을 선택하여 인스턴스를 생성할 수 있는 인터페이스를 제공한다.

 

 

 

 

 

 

주요 입력 사항은, 데이터베이스의 Root 사용자 비밀번호와, 데이터베이스 버전, Cloud SQL 버전 및 리전이다.

특히 Cloud SQL에 따라서 데이터베이스의 성능이 결정되는데, 샌드백스로 했음에도 불구하고, 꽤 많은 금액이 청구되는 것을 볼 수 있다.

 

 

 

그래서 일단 서비스의 용도로 생성한 것은 아니므로, 인스턴스 맞춤 설정에서 CPU 사양과 스토리지 용량을 최소화하여 Cloud SQL 인스턴스를 생성하였다.

 

 

 

 

 

 

 

 

---

데이터베이스 생성하기

 

 

 

이제 인스턴스 안에 데이터베이스를 만들어야 한다.

인스턴스 인터페이스에서 데이터베이스 만들기를 클릭하여 데이터베이스를 생성하도록 하자.

 

 

 

 

해당 과정을 모두 거치면 Database를 돌리는 Cloud SQL VM 인스턴스를 하나 더 생성하는 것을 마친 것이다.

 

---

환경변수 변경

 

이제 기존에 App을 돌리고 있던 VM 인스턴스의 SSH 터미널로 접속하여, 이전 포스팅에서 작성했던 .env파일의 Database Connection 정보를 변경해주자.

 

기존 Docker-compose.yaml에서 데이터베이스 컨테이너 제거

version: "3.7" #Docker-compose 버전, 2버전과 3버전은 차이가 큼
services:
  my-backend:
    build:
      context: .
      dockerfile: Dockerfile
    ports:
      - 8000:3000
    env_file:
      - ./.env.prod
  # my-database:
  #   platform: linux/x86_64 #M1사용시
  #   image: mariadb:latest
  #   #   build:
  #   #     context: ./database
  #   #     dockerfile: Dockerfile
  #   environment:
  #     MYSQL_DATABASE: "mydocker03"
  #     MYSQL_ROOT_PASSWORD: "1111"
  #   ports:
  #     - 3306:3306
  #   volumes:
  #     - ./local-mariadb:/var/lib/mysql

이제 데이터베이스는 Docker를 통해 가동하지 않을 것이므로, compose 파일에서 제외시킨다.

 

 

 

 

 

컨테이너 재실행

 

 

docker-compose stop

docker-compose rm -f

docker-compose build

docker-compose up -d

컨테이너를 다시 빌드하여 실행시켰다. 그런데 데이터베이스와의 커넥션에 실패하였다.

그 이유는 데이터베이스도 마찬가지로 네트워크 접근 허용을 위한 방화벽 설정을 해야 접근이 가능하기 때문이다.

데이터베이스를 돌리는 Cloud SQL VM 인스턴스와 와, App을 돌리고 있는 VM 인스턴스는 다른 VM으로 취급되므로, 이 둘 간의 통신을 위해서는 네트워크 설정을 해 주어야 할 필요성이 있다.

 

 

 

 

 

---

Cloud SQL 네트워크 설정

 

 

 

Cloud SQL의 네트워킹 탭에서 SQL 인스턴스의 커넥션 IP를 공개 IP로 변경하고, 네트워크에서 0.0.0.0/0, 즉 모든 IPv4 클라이언트들이 네트워크 방화벽을 통과할 수 있도록 설정하였다. 이렇게 설정한다면 앱에서는 물론 접근이 잘 된다. 하지만, 데이터베이스는 모든 사용자에게 열려있을 필요가 없고, 열러 있어서도 안 된다. 

 

 

 

연결은 잘 되지만..

 

 

 

 

VPC Peering

 

Google Cloud Platform (GCP)의 VPC(Virtual Private Cloud)는 클라우드 환경에서 네트워크를 격리하고 보안을 강화하기 위한 가상 네트워크 환경을 제공하는 서비스이다.

 

따라서 현재 DB가 외부에 있어 누구나 접속이 가능해지므로, DB 서버를 VPC 내부에서 가동시키려고 한다.

또한, 백엔드 서버의 VPC와 DB 서버의 VPC가 서로 다른 경우, 두 VPC를 연결하여 서로 통신이 가능하게 하도록 할 수 있다. 이를 VPC 피어링이라고 하며, 보안을 유지하면서 데이터 교환을 가능하게 해 준다.

 

 

 

 

Cloud SQL의 네트워크를 비공개 IP로 변경하고, 네트워크를 default로 설정하게 되면, default VPC 안으로 데이터베이스 인스턴스가 들어오게 된다. default VPC는 인스턴스 생성 시 기본으로 생성되어 있던 VPC이다. 그리고 승인된 네트워크에서 아까 작성해두었던 0.0.0.0/0을 삭제하여, 모든 클라이언트가 접근하지 못하도록 해주자.

 

 

 

 

 

 

 

이제 해당 비공개 IP 주소는 같은 VPC 안에 있는 App을 가동시키는 VM은 공유가 가능하면서, 외부에서는 접근이 불가능해졌다.

환경변수의 Connection Host 정보를 Cloud SQL 비공개 IP 주소로 변경한 후 Docker 컨테이너를 재실행시켜보자.

 

 

 

 

사진찍기 귀찮아서 위에꺼를 재탕하지만, 어쨌든 데이터베이스 연결은 성공적으로 돌아가면서, 외부 호스트 컴퓨터에서는 데이터베이스 GUI 따위를 통해서 접속시도를 하면 이제 방화벽에 의해 막히는 것을 확인할 수 있을 것이다.