🧱 GKE로 Monolith에서 Microservices 이전 - 실전편

이전에 이어 Google Kubernetes Engine(GKE)로 기존 Monolith에서 Microservices로 이전을 해 직접 해 보는 과정을 설명해 보겠습니다.

이 과정은 구글 클라우드의 study jam의 과정 중 일부 과정(chanlleng lab)입니다.

용어나 개념이 잘 안 잡히는 분은 이전 글을 보시면 좀 더 이해가 편하실겁니다.

(모놀리스 아키텍처 이해와 왜 마이크서비스로 이전을 해야 하는가는 이전 글을 보면 정리해 두었습니다.)

2025.04.26 - [개발/Google Cloud] - 🧱 GKE로 Monolith에서 Microservices 이전 - 개념잡기

🏷 프로젝트 개요

여기서는 https://github.com/googlecodelabs/monolith-to-microservices 프로젝트를 가져와 작업이 이루어집니다.

이 프로젝트에서는 이미 개발자들이 모놀리스 코드를 마이크로서비스로 분리하는 리팩토링 작업을 미리 해두었다는 전제로 시작이 됩니다. (Microservices로 이전하기 위해 준비된 프로젝트라는 말입니다.)

monolith-to-microservices/
├── monolith/          # 모놀리스 버전의 코드
└── microservices/
    └── src/
        ├── orders/    # 이미 분리된 Orders 마이크로서비스 코드
        ├── products/  # 이미 분리된 Products 마이크로서비스 코드
        └── frontend/  # 이미 분리된 Frontend 마이크로서비스 코드

여기서는 "FancyStore"라는 샘플 전자상거래 애플리케이션으로 작업하며 그 모놀리스 아키텍처를 마이크로서비스로 변환할 것입니다. 이 프로젝트는 다음과 같은 표준 지침이 있습니다.

• 클러스터 위치: europe-west1
• 리소스 명명 규칙: team-resource(예: fancystore-orderservice1)
• 머신 타입: e2-medium(비용 효율성을 위해)

여기서 목표는 모놀리스를 세 가지 마이크로서비스로 분해하는 것입니다.(Challenge Lab의 요구사항입니다.)

1. Orders 서비스 - 고객 주문 데이터 및 이력 처리
2. Products 서비스 - 제품 카탈로그 및 정보 관리
3. Frontend 서비스 - 사용자 인터페이스 제공

🏷 개발 환경 설정

먼저 저장소를 복제하고 환경을 설정해야 합니다.

# 프로젝트 ID 설정
gcloud config set project qwiklabs-gcp-00-09f9d6988b61

# 저장소 복제
git clone https://github.com/googlecodelabs/monolith-to-microservices.git
cd monolith-to-microservices

# 최신 Node.js LTS 버전 설치
nvm install --lts

# Cloud Build API 활성화
gcloud services enable cloudbuild.googleapis.com

이것은 프로젝트를 설정하고, 소스 코드를 가져오고, 올바른 Node.js 버전을 확보하고, 컨테이너 이미지 생성을 위한 Cloud Build API를 활성화합니다.

🏷모놀리스 컨테이너화

분해하기 전에 기존 모놀리식 애플리케이션을 컨테이너화를 먼저 해야 합니다.

왜??

당연히 마이크로서비스로 갑자기 전환하는 것은 위험성이 큽니다. 그래서 단계적으로 진행하는 것이 더 안전하죠.

그래서 기존 모놀리스를 코드 변경없이 그대로 컨테이너화를 시켜두고, 컨테이너 환경에서 제대로 작동하는지 확인을 해야 합니다.

그후 하나씩 각 서비스를 분리해야 합니다. 이것을 스트랭글러 패턴(Strangler Pattern)이라고 합니다.

레거시 시스템을 점진적으로 새로운 시스템으로 대체하는 마이그레이션 전략을 말하는 겁니다.

모놀리스를 먼저 컨테이너화하면 전환 기간 동안 시스템을 계속 운영하면서, 각 서비스를 마이크로 서비스를 추출하고 배포합니다.

그리고 해당 기능을 비활성화 하거나 마이크로서비스로 리디렉션(redirection)하고, 모든 기능이 다 이동이 되었으면 기존 모놀리스를 제거하는 과정을 거치게 됩니다.

여기서는 간단히 그 과정을 축약해서 간단해 보이지만, 실제로는 몇달이 걸릴수도 있는 과정입니다.

# 모놀리스 디렉토리로 이동
cd monolith

# 컨테이너 이미지 빌드 및 푸시
gcloud builds submit \
  --tag gcr.io/${GOOGLE_CLOUD_PROJECT}/fancy-monolith-203:1.0.0

이 명령은 모놀리스 디렉토리의 Dockerfile에서 Docker 컨테이너를 빌드하고 fancy-monolith-203:1.0.0 태그로 Google의 Artifact Registry에 푸시합니다.

Cloud Build는 디렉토리의 파일을 압축하여 Cloud Storage 버킷으로 이동한 다음 Dockerfile을 사용하여 이미지를 빌드합니다.

--tag 플래그는 Docker 이미지의 호스트 이름(gcr.io)을 지정합니다.

🏷Kubernetes 클러스터 생성

이제 애플리케이션을 호스팅할 GKE 클러스터를 생성해 보겠습니다.

# Containers API 활성화
gcloud services enable container.googleapis.com

# 3노드 GKE 클러스터 생성
gcloud container clusters create fancy-cluster-685 \
  --zone=europe-west1-b \
  --num-nodes=3 \
  --machine-type=e2-medium

# 인증 자격 증명 가져오기
gcloud container clusters get-credentials fancy-cluster-685 --zone=europe-west1-b

이것은 지정된 영역에 3개의 e2-medium 노드를 가진 fancy-cluster-685라는 Kubernetes 클러스터를 생성합니다.

두 번째 명령은 kubectl이 이 클러스터와 통신하도록 구성합니다.

클러스터 생성을 확인하기 위해서는 아래 명령어를 사용하면 된다.

gcloud compute instances list

위 명령어를 실행하면 클러스트 이름은 "fancy-cluster-685" 이 되어야 한다. 이 이미지처럼 출력이 된다는 것을 보여주기 위해 사용한 것이다.

🏷 Kubernetes에 모놀리스 배포

모놀리식 애플리케이션을 클러스터에 배포해 보겠습니다.

# Kubernetes 배포 생성
kubectl create deployment fancy-monolith-203 \
  --image=gcr.io/${GOOGLE_CLOUD_PROJECT}/fancy-monolith-203:1.0.0

# LoadBalancer 서비스로 배포 노출
kubectl expose deployment fancy-monolith-203 \
  --type=LoadBalancer \
  --port=80 \
  --target-port=8080

# 외부 IP를 가져오기 위해 서비스 상태 확인
kubectl get service fancy-monolith-203

이것은 모놀리스 컨테이너 이미지를 사용하여 Kubernetes 배포를 생성한 다음 LoadBalancer 유형의 서비스로 노출시킵니다.

서비스는 외부 포트 80을 내부 애플리케이션 포트 8080에 매핑합니다.

이제 외부 IP 주소를 통해 애플리케이션에 액세스할 수 있습니다.

Kubernetes의 LoadBalancer 유형은 서비스로 트래픽을 보내는 외부에서 접근 가능한 IP 주소를 가진 외부 로드 밸런서를 자동으로 생성합니다.

외부 아이피가 부여되는데는 1~2분정도 소요됩니다. <pending> 이 나오면 조금있다가 다시 명령어를 실행하면 됩니다.

그래서 외부 아이피로 접근하면 이미지처럼 정상적으로 서비스가 되는 것을 볼수 있습니다.

🏷 마이크로서비스로 분해하기

정상적으로 모놀리스로 서비스 되는 것을 확인했습니다. 이제부터 본격적으로 모놀리스를 마이크로서비스로 분해해 봅시다.

Orders, Products 및 Frontend 서비스를 위한 별도의 컨테이너를 생성할 것입니다.

✅Orders 마이크로서비스

먼저 Orders 서비스를 컨테이너화하고 배포해 보겠습니다.

위에서 언급했듯이 해당 프로젝트는 이미 마이크로서비스를 위해 코드들을 분리된 상태입니다.

# Orders 서비스 디렉토리로 이동
cd ~/monolith-to-microservices/microservices/src/orders

# 컨테이너 빌드 및 푸시
gcloud builds submit \
  --tag gcr.io/${GOOGLE_CLOUD_PROJECT}/fancy-orders-447:1.0.0 .

# Kubernetes에 배포
kubectl create deployment fancy-orders-447 \
  --image=gcr.io/${GOOGLE_CLOUD_PROJECT}/fancy-orders-447:1.0.0

# 서비스 노출
kubectl expose deployment fancy-orders-447 \
  --type=LoadBalancer \
  --port=80 \
  --target-port=8081

# 외부 IP 가져오기
kubectl get service fancy-orders-447

Orders 마이크로서비스가 내부적으로 포트 8081에서 지정 했습니다. 기억해 두세요.

이는 모놀리스를 마이크로서비스로 분할할 때 각 서비스가 일반적으로 자체 포트에서 실행되기 때문입니다.

이미 코드가 마이크로서비스로 분리된 상태이기 때문에 손쉽게 서비스를 분리 시켰습니다.

이것을 이제 기존 모놀리스에 적용해 업데이트를 하면 기존 모놀리스가 마이크로서비스로 전환이 됩니다.

모놀리스를 재구성하여 Orders 마이크로서비스 사용하기

이제 모놀리스가 새로운 Orders 마이크로서비스로 업데이트해야 합니다

# 구성 파일 편집
cd ~/monolith-to-microservices/react-app
nano .env.monolith

# REACT_APP_ORDERS_URL=/service/orders
# 이것을 아래처럼 변경해야 합니다.
# REACT_APP_ORDERS_URL=http://<ORDERS_IP_ADDRESS>/api/orders

# 모놀리스 프론트엔드 다시 빌드
npm run build:monolith

# 컨테이너 다시 빌드 및 재배포
cd ~/monolith-to-microservices/monolith
gcloud builds submit --tag gcr.io/${GOOGLE_CLOUD_PROJECT}/fancy-monolith-203:2.0.0 .
kubectl set image deployment/fancy-monolith-203 fancy-monolith-203=gcr.io/${GOOGLE_CLOUD_PROJECT}/fancy-monolith-203:2.0.0

모놀리스에서 마이크로서비스로 마이그레이션할 때 이 단계가 중요합니다.

내부 함수 호출을 하는 대신, 애플리케이션은 이제 별도의 서비스에 HTTP로 요청을 해야 합니다.

이게 제일 중요한 포인트이니, 반드시 기억해야 합니다.

✅Products 마이크로서비스

이제 Products 서비스를 배포해 보겠습니다.

# Products 서비스 디렉토리로 이동
cd ~/monolith-to-microservices/microservices/src/products

# 컨테이너 빌드 및 푸시
gcloud builds submit \
  --tag gcr.io/${GOOGLE_CLOUD_PROJECT}/fancy-products-894:1.0.0 .

# Kubernetes에 배포
kubectl create deployment fancy-products-894 \
  --image=gcr.io/${GOOGLE_CLOUD_PROJECT}/fancy-products-894:1.0.0

# 서비스 노출
kubectl expose deployment fancy-products-894 \
  --type=LoadBalancer \
  --port=80 \
  --target-port=8082

# 외부 IP 가져오기
kubectl get service fancy-products-894

Products 마이크로서비스는 내부적으로 포트 8082에서 실행되며, 이렇게 마이크로 서비스는 내부용 개별 포트를 지정해서 사용하게 구성해야 합니다.

모놀리스 다시 재구성하기

이제 Products도 분리되었으니, 이전처럼 기존 모놀리스를 업데이트 해야겠죠?

# 구성 파일 편집
cd ~/monolith-to-microservices/react-app
nano .env.monolith

# 두 마이크로서비스를 모두 포함하도록 변경:
# REACT_APP_ORDERS_URL=http://<ORDERS_IP_ADDRESS>/api/orders
# REACT_APP_PRODUCTS_URL=http://<PRODUCTS_IP_ADDRESS>/api/products

# 모놀리스 프론트엔드 다시 빌드
npm run build:monolith

# 컨테이너 다시 빌드 및 재배포
cd ~/monolith-to-microservices/monolith
gcloud builds submit --tag gcr.io/${GOOGLE_CLOUD_PROJECT}/fancy-monolith-203:3.0.0 .
kubectl set image deployment/fancy-monolith-203 fancy-monolith-203=gcr.io/${GOOGLE_CLOUD_PROJECT}/fancy-monolith-203:3.0.0

이렇게 Orders, Products를 마이크로서비스로 분리를 했습니다.

이제 마지막으로 frontend만 분리 시키면 됩니다.

✅Frontend 마이크로서비스 배포

마지막으로, 마이그레이션을 완료하기 위해 Frontend 마이크로서비스를 생성해야 합니다.

# 프론트엔드 구성 준비
cd ~/monolith-to-microservices/react-app
cp .env.monolith .env
npm run build

# Frontend 서비스 디렉토리로 이동
cd ~/monolith-to-microservices/microservices/src/frontend

# 컨테이너 빌드 및 푸시
gcloud builds submit \
  --tag gcr.io/${GOOGLE_CLOUD_PROJECT}/fancy-frontend-962:1.0.0 .

# Kubernetes에 배포
kubectl create deployment fancy-frontend-962 \
  --image=gcr.io/${GOOGLE_CLOUD_PROJECT}/fancy-frontend-962:1.0.0

# 서비스 노출
kubectl expose deployment fancy-frontend-962 \
  --type=LoadBalancer \
  --port=80 \
  --target-port=8080

# 외부 IP 가져오기
kubectl get service fancy-frontend-962

이렇게 Orders 및 Products 마이크로서비스와 직접 통신하는 전용 Frontend 마이크로서비스도 배포되었습니다.

그럼 이제 확인을 해 보면 아래와 비슷한 결과물을 볼수 있게 될겁니다.

study jam의 challenge lab에서는 json 타입으로 결과물을 볼수 있을겁니다..

✅ 기존 모놀리스 폐기

이제 모든 서비스가 마이크로서비스로 분리가 되었습니다. 그럼 이제 기존 모놀리스를 제거하면 됩니다.

kubectl delete deployment fancy-monolith-203 
kubectl delete service fancy-monolith-203

실 작업시에는 모놀리스에서 새로운 프론트엔드로 트래픽을 리디렉션하기 위한 DNS 변경 등을 포함한 신중한 계획이 필요합니다.

제대로 작업이 되었는지 확인하기 위해서 확인을 해 보겠습니다.

kubectl get services

이와 비슷한 화면을 볼수 있을겁니다. (이 이미지는 다른 테스트에서 스크린샷을 찍은 것으로 위 아이피와 일치하지 않으니 주의하세요.)

🏷 결론 및 주의사항

간단히 모놀리스로 된 프로젝트를 마이크로서비스로 분리를 해 보았습니다. 간단한 형태여서 별거 아닌거 같지만, 실 서비스에 적용시에는 많이 복잡해 집니다.

간단히나마 주의사항을 체크해 보면..

• 서비스 간 통신 관리: 마이크로서비스는 네트워크를 통해 통신하므로 지연 시간이 발생하고 장애 가능성이 높아집니다. 프로덕션 환경에서는 Istio 같은 서비스 메시를 도입하여 트래픽을 효율적으로 관리하고 보안을 강화하는 것이 좋습니다.
• 데이터 일관성 확보: 각 마이크로서비스가 독립적인 데이터베이스를 사용할 경우, 데이터 분할 전략과 일관성 유지 방안을 신중하게 계획해야 합니다. 서비스 간 데이터 동기화 문제가 발생할 수 있습니다.
• 관찰 가능성 확보: 여러 서비스로 분산되면 문제 추적과 디버깅이 복잡해집니다. 통합된 로깅, 모니터링, 분산 추적 시스템을 구축하여 전체 시스템의 가시성을 확보해야 합니다.
• 보안 체계 재설계: 마이크로서비스 환경에서는 서비스 간 인증과 권한 부여가 더 복잡해집니다. 서비스 간 안전한 통신을 위한 적절한 인증 메커니즘을 구현해야 합니다.

Google Kubernetes Engine(GKE)을 활용하여 모놀리스 애플리케이션을 마이크로서비스 아키텍처로 성공적으로 마이그레이션했습니다. 분리 시키는 과정이 쉽지는 않지만.. 그럼에도 분리를 하면 좋은 점을 다시 한번 확인해 보겠습니다.

1. 확장성: 각 서비스는 개별적인 수요에 맞춰 독립적으로 확장할 수 있습니다.
2. 복원력: 한 서비스에 발생한 문제가 다른 서비스의 기능에 영향을 미치지 않아 전체 시스템의 안정성이 향상됩니다.
3. 개발 민첩성: 개발 팀은 다른 서비스와 독립적으로 각자의 서비스를 개발하고 배포할 수 있어 개발 속도가 빨라집니다.
4. 기술적 유연성: 각 서비스마다 요구사항에 가장 적합한 기술 스택을 선택하여 사용할 수 있습니다.

직접 google cloud에서 테스트나 직접해 보시려면 https://www.cloudskillsboost.google/course_templates/638 에서 실습해 보실수 있습니다.

토큰이 있어야 하며, 매년 구글에서 행사하는 study jam을 통해서도 직접 실습해 볼수 있습니다.

간단히 적으려고 했는데, 무지 길어졌네요.

반응이 좋으면 다른 google cloud 서비스도 기술해 보겠습니다.

그럼 오늘도 좋은 하루 보내시기 바랍니다.

끝.

<i>이 글은 블로그 이전으로 티스토리에서 가져온 글입니다.</i>