[Smart Ad] Google Cloud Platform 환경 구축 - 1편

[Smart Ad] Google Cloud Platform 환경 구축 - 1편

🗒️ 개요

안녕하세요! [Smart Ad] 프로젝트의 Google Cloud Platform (GCP) 환경 구축 과정을 공유하고자 합니다. 이번 포스팅에서는 1편으로, 기본적인 인프라 구성 요소인 Cloud SQL(MySQL)과 Cloud Run을 중심으로 설명드리겠습니다. 특히, 민감 데이터 처리 방법과 배포 중 발생했던 오류에 대해 자세히 다루고, AWS 서비스와 비교하여 설명하겠습니다.

지난 "[Smart Ad] 프로젝트 소개 및 아키텍처 구성" 포스팅에서 밝혔듯이, 인프라는 최대한 단순하면서도 HA(고가용성) 구성을 통해 SPOF(단일 장애 지점)를 없애는 것을 목표로 했습니다.

🗄️ GCP Cloud SQL

• 데이터베이스: MySQL 8.0
• 연결 이름: [프로젝트 ID]:[리전]:[인스턴스 이름]

Cloud SQL은 AWS의 RDS (Relational Database Service) 와 유사한 서비스입니다. RDS와 마찬가지로 다양한 데이터베이스 엔진과 자동 백업, 복제, 패치 등의 기능을 제공합니다.

☁️ GCP Cloud Run 설정 (AWS Fargate, Lambda와 비교)

• 리전: asia-northeast3
• URL: https://[서비스 이름]-[해시]-[리전].run.app

Cloud Run은 서버리스 컨테이너 플랫폼으로, API 서버를 간편하게 배포하고 관리할 수 있게 해줍니다. smart-ad-api 서비스는 프론트엔드 서빙과 API 서버 역할을 모두 수행하는 역할을 할 예정입니다.

AWS 비교: Cloud Run은 AWS의 Fargate와 Lambda를 조합한 것과 유사한 서비스입니다.

• Fargate: 컨테이너를 서버리스 방식으로 실행하는 서비스
• Lambda: 함수 단위로 코드를 실행하는 서버리스 컴퓨팅 서비스

🐳 Dockerfile (api)

FROM amazoncorretto:17-alpine AS build
WORKDIR /app
COPY . /app
RUN ./gradlew bootJar

FROM amazoncorretto:17-alpine
WORKDIR /app
COPY --from=build /app/build/libs/api-0.0.1-SNAPSHOT.jar ./
EXPOSE 8080
ENTRYPOINT ["java", "-jar", "api-0.0.1-SNAPSHOT.jar"]

API 서버는 Spring Boot (Kotlin) 기반으로 개발되었으며, Docker를 이용하여 컨테이너 이미지로 빌드할 예정입니다.

🛠️ 로컬에서 Docker 빌드 및 푸시

# gcloud 초기화 및 인증 설정
gcloud init
gcloud auth configure-docker asia-northeast3-docker.pkg.dev

# smart-ad-api 디렉토리로 이동
cd smart-ad-api

# Docker 이미지 빌드 (이미지 이름 예시: asia-northeast3-docker.pkg.dev/[프로젝트 ID]/[저장소 이름]/[이미지 이름]:[태그])
docker build -t asia-northeast3-docker.pkg.dev/smart-ad-12345/smart-ad-artifacts/smart-ad-api:latest .

# 빌드된 Docker 이미지 확인
gcloud artifacts repositories list

# Docker 이미지 푸시 (이미지 이름은 빌드 시 사용한 이름과 동일해야 함)
docker push asia-northeast3-docker.pkg.dev/smart-ad-12345/smart-ad-artifacts/smart-ad-api:latest

# Artifact Registry 저장소 정보 확인 및 권한 설정 (필요시)
gcloud artifacts repositories describe [저장소 이름] --project=[프로젝트 ID] --location=[리전]
gcloud artifacts repositories add-iam-policy-binding [저장소 이름] --project=[프로젝트 ID] --location=[리전] --member="user:[이메일 주소]" --role="roles/artifactregistry.writer"

# 프로젝트에 Secret Manager 접근 권한 추가(필요시)
gcloud projects add-iam-policy-binding [프로젝트 ID] --member="user:[이메일 주소]"  --role="roles/secretmanager.secretAccessor"

🔒 Secret Manager 설정

Secret Manager는 API 키, 데이터베이스 비밀번호 등 민감한 정보를 안전하게 저장하고 관리하는 서비스입니다. application.yml에서 사용되는 민감정보를 환경변수로 전달해주기 위해 사용하였습니다.

1. Secret 생성:

   # Secret 생성 (secret_name: 원하는 시크릿 이름)
   gcloud secrets create [secret_name] --replication-policy="automatic"

2. Secret 버전 추가 (value: 실제 민감한 정보):

   # Secret 버전에 값 추가
   echo -n "[value]" | gcloud secrets versions add [secret_name] --data-file=-

   예) DB_PASSWORD 라는 시크릿을 생성하고, "mydbpassword"라는 값을 추가하는 경우:

   gcloud secrets create DB_PASSWORD --replication-policy="automatic"
   echo -n "mydbpassword" | gcloud secrets versions add DB_PASSWORD --data-file=-

3. Secret 접근 권한:
   Cloud Run 서비스가 Secret에 접근할 수 있도록 적절한 IAM 역할을 부여해야 합니다.

   Secret Manager의 Secret 이름은 projects/[프로젝트 번호]/secrets/[Secret 이름] 형식입니다.

Secret Manager는 AWS에도 동일한 서비스가 있습니다. Secrets Manager라는 이름으로 이름마저 비슷하며, 동일한 기능을 수행합니다. 두 서비스 모두 민감한 정보를 암호화하여 저장하고, 애플리케이션에서 쉽게 접근할 수 있도록 API를 제공합니다.

🚀 Cloud Run 배포 (Secret Manager 연동)

Cloud Run 배포 시 --set-secrets 옵션을 사용하여 Secret Manager의 Secret을 환경 변수로 주입합니다.

gcloud run deploy [서비스 이름] --image=[이미지 URI] --set-secrets=[환경 변수 이름]=[Secret 이름]:[버전]

예) DB_PASSWORD 환경 변수에 DB_PASSWORD Secret의 최신 버전을 연결하는 경우:

gcloud run deploy smart-ad-api --image=asia-northeast3-docker.pkg.dev/smart-ad-12345/smart-ad-artifacts/smart-ad-api:latest --set-secrets=DB_PASSWORD=projects/12345/secrets/DB_PASSWORD/versions/latest

latest 대신 특정 버전을 지정할 수도 있습니다.

🔥 배포 중 오류 해결: Secret Manager 권한 문제

Cloud Run 배포 중 다음과 같은 오류가 발생하였습니다. 클라우드나 인프라 작업에 가장 시간이 많이 쓰이는 이유가 원인 모를 오류가 대부분인데, 다행히 GCP에서는 친절하게 이유에 대해 설명해줬습니다.

ERROR: (gcloud.run.deploy) The service account used must be granted the 'Secret Manager Secret Accessor' role (roles/secretmanager.secretAccessor) at the secret, project or higher level.

이 오류는 Cloud Run 서비스 계정에 Secret Manager의 Secret에 접근할 수 있는 권한이 없기 때문에 발생합니다.

해결 방법:

1. Cloud Run 서비스 계정 확인:
   Cloud Run 서비스 설정에서 사용 중인 서비스 계정을 확인합니다. (기본적으로 [프로젝트 번호]-compute@developer.gserviceaccount.com 형태)

2. IAM 역할 부여:
   다음 명령어를 사용하여 서비스 계정에 Secret Manager Secret Accessor 역할을 부여합니다.

   gcloud projects add-iam-policy-binding [프로젝트 ID] --member="serviceAccount:[서비스 계정]" --role="roles/secretmanager.secretAccessor"

   예) 서비스 계정이 1234-compute@developer.gserviceaccount.com인 경우:

   gcloud projects add-iam-policy-binding smart-ad-1234 --member="serviceAccount:1234-compute@developer.gserviceaccount.com" --role="roles/secretmanager.secretAccessor"

   또는 Secret Manager에서 특정 Secret에 대한 권한을 부여할 수도 있습니다.

---

이번 포스팅에서는 프로젝트의 GCP 환경 구축 중 Cloud SQL과 Cloud Run에 대해 간략하게 정리했습니다.
느낀점은 sdk를 통해서 cmd에 명령어로 조작하는게 직접 콘솔에 메뉴를 찾는것보다 훨씬 간편하다고 느꼈습니다.
UI를 제공해주니 좋긴 하지만, 내가 했던 명령에 대해 기재해두고 어떤 경우 문제가 생기는지도 바로 알 수 있어서 더 편했던 것 같습니다.
다음 편에서는 Cloud Tasks, VPC, Cloud NAT 등 나머지 구성 요소에 대해 설명하겠습니다.