🧱 GKE로 Monolith에서 Microservices 이전 - 개념잡기

처음 웹앱을 만들 때 대부분은 하나의 코드베이스로 시작합니다. 이것이 바로 모놀리스(Monolith) 구조입니다.

처음엔 쉽고 빠르지만, 시간이 지나고 규모가 커지면 유지보수가 어려워집니다.

그래서 등장한 것이 마이크로서비스(Microservices)와 GKE(Google Kubernetes Engine)입니다.

이 글에서는 이 개념들을 초보자 눈높이에서 설명하고, 간단한 예제로 GKE를 이용한 전환 과정을 보여드릴게요.

🏷 Monolith

모놀리스 구조는 모든 기능(프론트, 백엔드, DB 등)이 한 서버, 하나의 코드베이스에 모여 있는 구조입니다.

즉, 단일 프레임워크 기반으로 제작된 형태로 보면 됩니다.

- 백엔드: Spring Boot(Java), Django/Flask(Python), Express/Nest.js(Node.js), Rails(Ruby) 등의 단일 프레임워크

- 프론트엔드: 같은 프로젝트 내에 함께 포함되거나 별도로 분리되어도 단일 앱으로 배포

Monolith Architecture

├── src/
│   ├── controllers/ (또는 routes/)
│   ├── models/
│   ├── services/
│   ├── views/ (또는 templates/)
│   ├── utils/
│   └── app.js (또는 main 파일)
├── public/ (또는 static/)
│   ├── css/
│   ├── js/
│   └── images/
└── package.json (또는 해당 언어의 종속성 관리 파일)

처음에는 간단하지만, 기능이 많아질수록 관리가 힘들어집니다.

🏷 Microservices

마이크로서비스는 기능을 작은 단위의 서비스로 나눈 구조입니다. 각각 독립적으로 개발, 배포, 스케일링이 가능합니다.

- 프론트엔드 서비스 – 사용자 화면 처리

- 주문 서비스 – 주문 처리

- 상품 서비스 – 상품 데이터 처리

Microservices Architecture

__ Frontend Service
      |__ 사용자 화면 UI 처리
      |__ API Gateway 또는 BFF와 통신

__ Order Service
      |__ 주문 생성, 조회, 취소
      |__ 주문 상태 관리
      |__ 메시지 큐 또는 이벤트 기반 처리

__ Product Service
      |__ 상품 목록, 상세 정보 제공
      |__ 상품 등록/수정/삭제
      |__ 재고 관리

이처럼 마이크로서비스한 서비스는 문제가 생겨도 전체 서비스가 멈추지 않습니다.

그럼 많이들 사용하는 API 와의 비슷해 보이는데.. 맞습니다. 마이크로서비스는 보통 API를 사용하여 서로 통신을 합니다.

마이크로서비스가 상위 개념(설계 철학?)으로 보면 되며, 그 하위에 API가 있다면 보시면 됩니다.

(반드시 마이크로 서비스에 API가 탑재되어야 하는 것은 아닙니다.)

🏷 Google Kubernetes Engine (GKE)

GKE는 Google Cloud의 관리형 쿠버네티스 서비스입니다. 컨테이너화된 애플리케이션의 오케스트레이션을 도와주며, 배포, 확장 및 관리의 복잡한 부분을 처리합니다.

이 부분은 앞으로 좀 더 다루어 보면, 감이 잡힐거라 생각이 됩니다.

🏷 Migration 을 하는 이유

그럼 왜 잘 작동하던 Monolith를 Microservices 로 이전을 하느냐는 근본적인 질문을 던질 수 밖에 없습니다.

✅ 모놀리스의 문제점:

• 비효율적인 확장 (특정 기능만 트래픽이 많아도 전체 애플리케이션을 확장해야 해서 리소스 낭비)
• 긴 배포 주기와 다운타임 (작은 수정도 전체 시스템을 재배포해야 해서 시간 소요)
• 단일 장애 지점 (한 부분의 오류가 전체 시스템을 다운시킬 수 있음)
• 복잡성이 증가할수록 이해하기 어려움 (코드베이스가 커지면서 개발자가 모든 부분을 파악하기 어려워짐)
• 전체 애플리케이션에 기술 스택이 고정됨 (새로운 기술 도입 시 전체 시스템에 영향을 줌)

✅ 마이크로서비스의 이점:

• 수요에 따라 서비스를 독립적으로 확장 (인기 있는 결제 서비스만 추가 서버로 확장 가능)
• 전체 시스템에 영향을 주지 않고 업데이트 배포 (사용자 서비스만 업데이트해도 다른 기능 정상 작동)
• 더 나은 장애 격리 (상품 서비스가 다운되어도 장바구니와 결제는 계속 작동)
• 명확한 경계를 가진 팀의 독립적인 작업 (상품팀, 결제팀이 서로 간섭 없이 개발 가능)
• 다양한 서비스에 다른 기술을 사용할 자유 (데이터 처리에 Python, 실시간 기능에 Node.js 등 최적 기술 선택)

이 내용을 보면 왜 microservices로 전환을 해야 하는지에 대한 이유가 명확해 질겁니다.

🏷구현 과정

✅서비스 경계 구분하기

모놀리스를 분석하고 독립적인 서비스가 될 수 있는 논리적 구성 요소를 식별해서 다음과 같은 특성을 가진 부분을 찾아서 구분해 줘야 합니다.

• 특정 비즈니스 기능을 제공
• 다른 부분에 대한 의존성이 최소화됨
• 독립적으로 수정 가능

✅각 서비스 컨테이너화하기

# 프론트엔드 (Frontend UI) 도커 빌드
docker build -t frontend-service:1.0 ./frontend

# 상품 API (Products Service) 도커 빌드
docker build -t products-service:1.0 ./products

# 주문 API (Orders Service) 도커 빌드
docker build -t orders-service:1.0 ./orders

✅GKE로 배포

gcloud container clusters create shop-cluster --num-nodes=3

GKE 클러스터 생성하고 난뒤 각각 서비스를 빌드하면 됩니다.

Products Service

# Docker 이미지 빌드 + 푸시
cd ~/monolith-to-microservices/microservices/src/products
gcloud builds submit --tag gcr.io/${GOOGLE_CLOUD_PROJECT}/products:1.0.0 .

# GKE 배포
kubectl create deployment products --image=gcr.io/${GOOGLE_CLOUD_PROJECT}/products:1.0.0

# 외부 노출(외부 접근을 허용)
kubectl expose deployment products --type=LoadBalancer --port=80 --target-port=8082

Orders Service

# Docker 이미지 빌드 + 푸시
cd ~/monolith-to-microservices/microservices/src/orders
gcloud builds submit --tag gcr.io/${GOOGLE_CLOUD_PROJECT}/orders:1.0.0 .

# GKE 배포
kubectl create deployment orders --image=gcr.io/${GOOGLE_CLOUD_PROJECT}/orders:1.0.0

# 외부 노출(외부 접근을 허용)
kubectl expose deployment orders --type=LoadBalancer --port=80 --target-port=8081

Frontend Service

# Docker 이미지 빌드 + 푸시
cd ~/monolith-to-microservices/microservices/src/frontend
gcloud builds submit --tag gcr.io/${GOOGLE_CLOUD_PROJECT}/frontend:1.0.0 .

# GKE 배포
kubectl create deployment frontend --image=gcr.io/${GOOGLE_CLOUD_PROJECT}/frontend:1.0.0

# 외부 노출(외부 접근을 허용)
kubectl expose deployment frontend --type=LoadBalancer --port=80 --target-port=8080

✅ 요약

서비스

Docker Build

GKE 배포

포트 노출 (LoadBalancer)

Products

8082 포트로 설정

products Deployment

외부 80 → 내부 8082

Orders

8081 포트로 설정

orders Deployment

외부 80 → 내부 8081

Frontend

8080 포트로 설정

frontend Deployment

외부 80 → 내부 8080

모든 서비스는 LoadBalancer를 통해 외부에 공개되면, 프론트엔드와 연결이 되게 됩니다.

🔥 결론

간단히 명령어로 모놀리스에서 마이크로 서비스로 이전하는 맛보기를 보여드렸습니다.

보시면 아시겠지만, 간단한 작업은 아닙니다. 그럼으로 충분한 기획과 준비를 해서 작업을 진행해야 합니다.

우선 중요하지 않는 서비스부터 분리를 시작해서 모니터링을 구현한 뒤 테스트와 배포를 자동화하는 것이 좋을것입니다.

이것을 스트랭글러 패턴(Strangler Pattern)이라고 합니다.(레거시 시스템을 점진적으로 새로운 시스템으로 대체하는 마이그레이션 전략)

다음에는 google cloud를 통해 간단히 이 과정을 실제 처리하는 과정을 알아보겠습니다.

그럼 오늘도 즐거운 코딩 되시기를 바라겠습니다. ^^;

끝.

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