1. 소개
모놀리식 애플리케이션에서 마이크로서비스 아키텍처로 마이그레이션해야 하는 이유 애플리케이션을 마이크로서비스로 분할하면 다음과 같은 이점이 있습니다. 대부분 마이크로서비스가 느슨하게 결합되어 있다는 사실에서 비롯됩니다.
- 마이크로서비스는 독립적으로 테스트하고 배포할 수 있습니다. 배포 단위가 작을수록 배포가 쉬워집니다.
- 다양한 언어와 프레임워크로 구현할 수 있습니다. 각 마이크로서비스마다 특정 사용 사례에 가장 적합한 기술을 자유롭게 선택할 수 있습니다.
- 여러 팀이 관리할 수 있습니다. 마이크로서비스 간에 경계가 있어 하나 또는 여러 개의 마이크로서비스에 전담 팀을 배정하기가 더 쉽습니다.
- 마이크로서비스로 전환하면 팀 간의 종속 항목이 느슨해집니다. 각 팀은 사용 중인 마이크로서비스의 API만 신경 쓰면 됩니다. 마이크로서비스의 구현 방식, 출시 주기 등에 대해 생각할 필요가 없습니다.
- 오류에 대비한 설계를 더 쉽게 수행할 수 있습니다. 서비스 간에 명확한 경계가 있으면 서비스가 다운되었을 때 취해야 할 조치를 더 쉽게 결정할 수 있습니다.
모놀리식과 비교하면 다음과 같은 단점이 있습니다.
- 마이크로서비스 기반 앱은 종종 불분명한 방식으로 상호작용하는 다양한 서비스의 네트워크이기 때문에 시스템의 전반적인 복잡성이 증가하는 경향이 있습니다.
- 모놀리식의 내부 기능과 달리 마이크로서비스는 네트워크를 통해 통신합니다. 경우에 따라 이는 보안 문제로 볼 수 있습니다. Istio는 마이크로서비스 간의 트래픽을 자동으로 암호화하여 이 문제를 해결합니다.
- 서비스 간 지연 시간으로 인해 모놀리식 접근 방식과 동일한 수준의 성능을 달성하기가 어려울 수 있습니다.
- 시스템의 동작은 단일 서비스로 인해 발생하는 것이 아니라 많은 서비스와 상호작용으로 인해 발생합니다. 따라서 시스템이 프로덕션 환경에서 어떻게 동작하는지 (관측 가능성) 이해하는 것이 더 어렵습니다. 이 문제도 Istio로 해결할 수 있습니다.
이 실습에서는 Google Kubernetes Engine (GKE)에서 마이크로서비스를 실행해 보겠습니다. Kubernetes는 컨테이너를 관리, 호스팅, 확장, 배포하는 플랫폼입니다. 컨테이너는 이식 가능한 방식으로 코드를 패키징하고 실행하는 데 사용됩니다. 이는 각 마이크로서비스가 자체 컨테이너에서 실행될 수 있는 마이크로서비스 패턴에 매우 적합합니다.
이 실습에서는 기존 모놀리식 애플리케이션을 Google Kubernetes Engine 클러스터에 배포한 다음 마이크로서비스로 분류해 보겠습니다.
마이크로서비스 아키텍처 다이어그램
먼저 모놀리식을 한 번에 하나씩 마이크로서비스 3개로 나누겠습니다. 마이크로서비스에는 주문, 제품, 프런트엔드가 있습니다. Cloud Shell 내에서 트리거하는 Cloud Build를 사용하여 각 마이크로서비스의 Docker 이미지를 빌드합니다. 그런 다음 Kubernetes 서비스 유형 LoadBalancer를 사용하여 마이크로서비스를 Google Kubernetes Engine (GKE)에 배포하고 노출합니다. 각 서비스에 이 작업을 수행하는 동시에 모놀리식에서 리팩터링합니다. 이 과정에서 모놀리식을 삭제할 수 있을 때까지 모놀리식과 마이크로서비스를 모두 실행하게 됩니다.
학습할 내용
- 모놀리식에서 마이크로서비스로 분할하는 방법
- Google Kubernetes Engine 클러스터를 만드는 방법
- Docker 이미지를 만드는 방법
- Kubernetes에 Docker 이미지를 배포하는 방법
기본 요건
- 프로젝트 또는 프로젝트 소유자 역할이 있는 프로젝트를 만들 수 있는 관리 액세스 권한을 가진 Google Cloud Platform 계정
- Docker 및 Kubernetes에 관한 기본적인 이해
2. 환경 설정
자습형 환경 설정
아직 Google 계정(Gmail 또는 Google Apps)이 없으면 계정을 만들어야 합니다. Google Cloud Platform 콘솔 ( console.cloud.google.com)에 로그인하고 새 프로젝트를 만듭니다.
모든 Google Cloud 프로젝트에서 고유한 이름인 프로젝트 ID를 기억하세요(위의 이름은 이미 사용되었으므로 사용할 수 없습니다). 이 ID는 나중에 이 Codelab에서 PROJECT_ID라고 부릅니다.
다음으로 Google Cloud 리소스를 사용하고 Container Engine API를 사용 설정하려면 Developers Console에서 결제를 사용 설정해야 합니다.
이 codelab을 실행하는 과정에는 많은 비용이 들지 않지만 더 많은 리소스를 사용하려고 하거나 실행 중일 경우 비용이 더 들 수 있습니다(이 문서 마지막의 '삭제' 섹션 참조). Google Kubernetes Engine 가격 책정은 여기에 설명되어 있습니다.
Google Cloud Platform의 신규 사용자에게는 $300의 무료 체험판이 제공됩니다.
Google Cloud Shell
Google Cloud 및 Kubernetes는 노트북에서 원격으로 작동할 수 있지만, 이 Codelab에서는 Cloud에서 실행되는 명령줄 환경인 Google Cloud Shell을 사용합니다.
이 Debian 기반 가상 머신에는 필요한 모든 개발 도구가 로드되어 있습니다. 영구적인 5GB 홈 디렉터리를 제공하고 Google Cloud에서 실행되므로 네트워크 성능과 인증이 크게 개선됩니다. 즉, 이 Codelab에 필요한 것은 브라우저뿐입니다(Chromebook에서도 작동 가능).
- Cloud Console에서 Cloud Shell을 활성화하려면 단순히 Cloud Shell 활성화
를 클릭합니다. 환경을 프로비저닝하고 연결하는 데 몇 정도만 소요됩니다.
Cloud Shell에 연결되면 사용자 인증이 이미 완료되었고 프로젝트가 내 PROJECT_ID에 설정되어 있음을 확인할 수 있습니다.
gcloud auth list
명령어 결과
Credentialed accounts: - <myaccount>@<mydomain>.com (active)
gcloud config list project
명령어 결과
[core] project = <PROJECT_ID>
어떤 이유로든 프로젝트가 설정되지 않았으면 다음 명령어를 실행하면 됩니다.
gcloud config set project <PROJECT_ID>
PROJECT_ID를 찾고 계신가요? 설정 단계에서 사용한 ID를 확인하거나 Cloud Console 대시보드에서 확인하세요.
또한 Cloud Shell은 기본적으로 이후 명령어를 실행할 때 유용할 수 있는 몇 가지 환경 변수를 설정합니다.
echo $GOOGLE_CLOUD_PROJECT
명령어 결과
<PROJECT_ID>
- 마지막으로 기본 영역 및 프로젝트 구성을 설정합니다.
gcloud config set compute/zone us-central1-f
다양한 영역을 선택할 수 있습니다. 자세한 내용은 리전 및 영역을 참조하세요.
3. 소스 저장소 클론
단순한 시작 페이지, 제품 페이지, 주문 내역 페이지가 있는 가상의 전자상거래 웹사이트를 보여주는 기존의 모놀리식 애플리케이션을 사용합니다. git 저장소에서 소스를 클론하기만 하면 되므로 이를 마이크로서비스로 분할하여 Google Kubernetes Engine (GKE)에 배포하는 데 집중할 수 있습니다.
다음 명령어를 실행하여 git 저장소를 Cloud Shell 인스턴스에 클론하고 적절한 디렉터리로 변경합니다. 배포하기 전에 모놀리식을 테스트할 수 있도록 NodeJS 종속 항목도 설치합니다. 이 스크립트를 실행하는 데 몇 분 정도 걸릴 수 있습니다.
cd ~ git clone https://github.com/googlecodelabs/monolith-to-microservices.git cd ~/monolith-to-microservices ./setup.sh
그러면 GitHub 저장소가 클론되고 디렉터리로 변경되고 애플리케이션을 로컬에서 실행하는 데 필요한 종속 항목이 설치됩니다. 이 스크립트를 실행하는 데 몇 분 정도 걸릴 수 있습니다.
4. GKE 클러스터 만들기
이제 작업 중인 개발자 환경이 마련되었으니 모놀리식과 마이크로서비스를 배포할 Kubernetes 클러스터가 필요합니다. 클러스터를 만들기 전에 적절한 API가 사용 설정되어 있는지 확인해야 합니다. Google Kubernetes Engine을 사용할 수 있도록 다음 명령어를 실행하여 컨테이너 API를 사용 설정합니다.
gcloud services enable container.googleapis.com
이제 클러스터를 만들 준비가 되었습니다. 아래 명령어를 실행하여 노드가 3개인 fancy-cluster라는 이름의 GKE 클러스터를 만듭니다.
gcloud container clusters create fancy-cluster --num-nodes 3
클러스터가 생성되려면 몇 분 정도 걸릴 수 있습니다. 명령어가 완료되면 다음 명령어를 실행하여 클러스터의 작업자 VM 인스턴스 3개를 확인합니다.
gcloud compute instances list
출력:
NAME ZONE MACHINE_TYPE PREEMPTIBLE INTERNAL_IP EXTERNAL_IP STATUS gke-fancy-cluster-default-pool-ad92506d-1ng3 us-east4-a n1-standard-1 10.150.0.7 XX.XX.XX.XX RUNNING gke-fancy-cluster-default-pool-ad92506d-4fvq us-east4-a n1-standard-1 10.150.0.5 XX.XX.XX.XX RUNNING gke-fancy-cluster-default-pool-ad92506d-4zs3 us-east4-a n1-standard-1 10.150.0.6 XX.XX.XX.XX RUNNING
Google Cloud 콘솔에서 Kubernetes 클러스터 및 관련 정보를 볼 수도 있습니다. 왼쪽 상단의 메뉴 버튼을 클릭하고 Kubernetes Engine까지 아래로 스크롤한 후 클러스터를 클릭합니다. fancy-cluster라는 이름의 클러스터가 표시됩니다.
축하합니다. 이제 첫 번째 Kubernetes 클러스터를 만들었습니다!
5. 기존 모놀리식 배포
이 실습에서는 모놀리식을 마이크로서비스로 분할하는 방법을 중점적으로 다루므로 모놀리식 애플리케이션을 준비하고 실행해야 합니다. 이 실습에서는 다음 스크립트를 실행하여 GKE 클러스터에 모놀리식 애플리케이션을 배포합니다.
cd ~/monolith-to-microservices ./deploy-monolith.sh
모놀리식 액세스하기
모놀리식 애플리케이션의 외부 IP 주소를 찾으려면 다음 명령어를 실행합니다.
kubectl get service monolith
다음과 비슷한 출력이 표시됩니다.
NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE monolith 10.3.251.122 203.0.113.0 80:30877/TCP 3d
참고: 이를 위해서는 외부 부하 분산기와 IP를 프로비저닝해야 하므로 다소 시간이 걸립니다. 출력에 외부 IP가 다음과 같이 표시되는 경우
<pending> 몇 분 정도 기다린 후 다시 시도합니다.
모놀리식의 외부 IP 주소를 확인했으면 IP 주소를 복사합니다. 브라우저에서 이 URL (예: http://203.0.113.0)을 가리켜 모놀리식에 액세스할 수 있는지 확인합니다.
위 그림과 같이 모놀리식 웹사이트의 시작 페이지가 표시됩니다. 시작 페이지는 나중에 프런트엔드 마이크로서비스에 의해 제공되는 정적 페이지입니다. 이제 Kubernetes에서 모놀리식이 완전히 실행됩니다.
6. 마이크로서비스로 주문 이전
이제 GKE에서 기존 모놀리식 웹사이트를 실행했으므로 각 서비스를 마이크로서비스로 분할할 수 있습니다. 일반적으로 비즈니스 도메인과 같은 애플리케이션의 특정 부분을 중심으로 어떤 서비스를 더 작은 청크로 분할할 것인지 계획해야 합니다. 시연을 위해 간단한 예를 만들고 비즈니스 도메인, 주문, 제품, 프런트엔드를 중심으로 각 서비스를 분류해 보았습니다. 코드는 이미 마이그레이션되었으므로 Google Kubernetes Engine (GKE)에서 서비스를 빌드하고 배포하는 데 중점을 두겠습니다.
새 주문 마이크로서비스 만들기
첫 번째로 살펴볼 서비스는 주문 서비스입니다. 제공된 별도의 코드베이스를 활용하고 이 서비스를 위한 별도의 Docker 컨테이너를 만들겠습니다.
Google Cloud Build로 Docker 컨테이너 만들기
이미 코드베이스를 이전했으므로 첫 번째 단계는 Google Cloud Build를 사용하여 주문 서비스의 Docker 컨테이너를 만드는 것입니다.
일반적으로는 Docker 컨테이너를 빌드하고 레지스트리로 푸시하여 GKE가 가져올 이미지를 저장하는 2단계 접근 방식을 취해야 합니다. 하지만 작업을 더 쉽게 할 수 있습니다. Google Cloud Build를 사용하여 Docker 컨테이너를 빌드하고 단일 명령어로 Google Cloud Container Registry에 이미지를 저장할 수 있습니다. 이렇게 하면 단일 명령어를 실행하여 이미지를 빌드하고 Container Registry로 이동할 수 있습니다. Docker 파일을 만들고 푸시하는 수동 프로세스를 보려면 여기로 이동하세요.
Google Cloud Build가 디렉터리의 파일을 압축하여 Google Cloud Storage 버킷으로 이동합니다. 그러면 빌드 프로세스가 버킷의 모든 파일을 가져와 Dockerfile을 사용하여 Docker 빌드 프로세스를 실행합니다. 호스트와 함께 --tag 플래그를 Docker 이미지의 gcr.io로 지정했으므로 결과로 생성되는 Docker 이미지가 Google Cloud Container Registry로 푸시됩니다.
다음 명령어를 실행하여 Docker 컨테이너를 빌드하고 Google Container Registry로 푸시합니다.
cd ~/monolith-to-microservices/microservices/src/orders
gcloud builds submit --tag gcr.io/${GOOGLE_CLOUD_PROJECT}/orders:1.0.0 .
이 프로세스는 몇 분 정도 걸리지만 완료되면 터미널에 다음과 비슷한 출력이 표시됩니다.
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- ID CREATE_TIME DURATION SOURCE IMAGES STATUS 1ae295d9-63cb-482c-959b-bc52e9644d53 2019-08-29T01:56:35+00:00 33S gs://<PROJECT_ID>_cloudbuild/source/1567043793.94-abfd382011724422bf49af1558b894aa.tgz gcr.io/<PROJECT_ID>/orders:1.0.0 SUCCESS
빌드 기록을 보거나 프로세스를 실시간으로 보려면 Google Cloud 콘솔로 이동하세요. 왼쪽 상단의 메뉴 버튼을 클릭하고 도구 → Cloud Build로 스크롤한 후 기록을 클릭합니다. 여기에서 이전 빌드 목록을 모두 확인할 수 있습니다. 방금 만든 빌드는 1개만 있어야 합니다.
빌드 ID를 클릭하면 로그 출력을 포함하여 해당 빌드에 대한 모든 세부정보를 볼 수 있습니다.
빌드 세부정보 페이지의 빌드 정보 섹션에서 이미지 이름을 클릭하면 생성된 컨테이너 이미지를 볼 수 있습니다.
GKE에 컨테이너 배포
웹사이트를 컨테이너화하고 컨테이너를 Google Container Registry로 푸시했으므로 이제 Kubernetes에 배포해 보겠습니다.
Kubernetes는 애플리케이션을 포드로 나타냅니다. 포드는 컨테이너 (또는 긴밀하게 결합된 컨테이너의 그룹)를 나타내는 단위입니다. 포드는 Kubernetes에서 배포 가능한 최소 단위입니다. 이 튜토리얼에서는 각 포드에 마이크로서비스 컨테이너만 포함됩니다.
GKE 클러스터에서 애플리케이션을 배포하고 관리하려면 Kubernetes 클러스터 관리 시스템과 통신해야 합니다. 이 작업은 일반적으로 Cloud Shell 내에서 kubectl 명령줄 도구를 사용하여 수행합니다.
먼저 배포 리소스를 만듭니다. 배포는 복제본이라고 하는 애플리케이션의 여러 복사본을 관리하고, 이러한 복사본이 클러스터의 개별 노드에서 실행되도록 예약합니다. 이 경우 배포는 애플리케이션의 포드 하나만 실행합니다. 배포는 ReplicaSet를 만들어 이를 보장합니다. ReplicaSet는 지정된 수의 복제본이 항상 실행되도록 하는 역할을 합니다.
아래 kubectl create deployment 명령어를 실행하면 Kubernetes에서 복제본이 1개 있는 클러스터에 orders라는 배포를 만듭니다.
다음 명령어를 실행하여 애플리케이션을 배포합니다.
kubectl create deployment orders --image=gcr.io/${GOOGLE_CLOUD_PROJECT}/orders:1.0.0
배포 확인
배포가 성공적으로 생성되었는지 확인하려면 다음 명령어를 실행합니다. 포드 상태가 '실행 중'으로 바뀌려면 몇 분 정도 걸릴 수 있습니다.
kubectl get all
출력:
NAME READY STATUS RESTARTS AGE pod/monolith-779c8d95f5-dxnzl 1/1 Running 0 15h pod/orders-5bc6969d76-kdxkk 1/1 Running 0 21s NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/kubernetes ClusterIP 10.39.240.1 <none> 443/TCP 19d service/monolith LoadBalancer 10.39.241.130 34.74.209.57 80:30412/TCP 15h NAME READY UP-TO-DATE AVAILABLE AGE deployment.apps/monolith 1/1 1 1 15h deployment.apps/orders 1/1 1 1 21s NAME DESIRED CURRENT READY AGE replicaset.apps/monolith-779c8d95f5 1 1 1 15h replicaset.apps/orders-5bc6969d76 1 1 1 21s
이 출력은 몇 가지를 보여줍니다. 현재 배포 상태, 원하는 포드 수가 1인 ReplicaSet, 실행 중인 포드를 확인할 수 있습니다. 모든 항목이 성공적으로 생성된 것 같습니다.
GKE 컨테이너 노출
애플리케이션을 GKE에 배포했지만 클러스터 외부에서는 애플리케이션에 액세스할 방법이 없습니다. 기본적으로 GKE에서 실행하는 컨테이너는 외부 IP 주소가 없기 때문에 인터넷에서 액세스할 수 없습니다. 서비스 리소스를 통해 애플리케이션을 인터넷 트래픽에 명시적으로 노출해야 합니다. 서비스는 애플리케이션의 포드에 네트워킹 및 IP 지원을 제공합니다. GKE는 애플리케이션의 외부 IP와 부하 분산기 ( 청구 대상)를 만듭니다.
주문 서비스를 배포할 때 Kubernetes 배포를 통해 내부적으로 포트 8081에 노출했습니다. 이 서비스를 외부에 노출하려면 포트 80의 트래픽을 외부에서 주문 서비스의 내부 포트 8081로 라우팅하는 LoadBalancer 유형의 Kubernetes 서비스를 만들어야 합니다. 다음 명령어를 실행하여 웹사이트를 인터넷에 노출합니다.
kubectl expose deployment orders --type=LoadBalancer --port 80 --target-port 8081
서비스 액세스
GKE는 외부 IP 주소를 배포가 아닌 서비스 리소스에 할당합니다. GKE가 애플리케이션에 프로비저닝한 외부 IP를 찾으려면 kubectl get service 명령어로 서비스를 검사하면 됩니다.
kubectl get service orders
출력:
NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE orders 10.3.251.122 203.0.113.0 80:30877/TCP 3d
애플리케이션의 외부 IP 주소를 확인했으면 IP 주소를 복사합니다. 새로운 주문 서비스를 가리키도록 모놀리식을 변경할 때 다음 단계를 위해 이 파일을 저장하세요.
모놀리식 재구성
모놀리식에서 주문 서비스를 삭제했으므로 새 외부 주문 마이크로서비스를 가리키도록 모놀리식을 수정해야 합니다.
모놀리식을 분해할 때는 코드 조각을 단일 코드베이스에서 여러 개로 제거한 후 별도로 배포합니다. 마이크로서비스가 다른 서버에서 실행되기 때문에 더 이상 서비스 URL을 절대 경로로 참조할 수 없으므로 주문 마이크로서비스의 새 서버 주소로 라우팅해야 합니다. 이 경우 분할된 각 서비스의 URL을 업데이트하기 위해 모놀리식 서비스에서 약간의 다운타임이 필요합니다. 마이크로서비스 마이그레이션 프로세스 중에 마이크로서비스와 모놀리식을 프로덕션으로 이전할 때 이 점을 고려해야 합니다.
새 Orders 마이크로서비스 IP 주소를 가리키도록 모놀리식의 구성 파일을 업데이트해야 합니다. nano 편집기를 사용하여 로컬 URL을 새로운 Orders 마이크로서비스의 IP 주소로 바꿉니다. 다음 명령어를 실행하여
cd ~/monolith-to-microservices/react-app nano .env.monolith
편집기가 열리면 파일은 다음과 같이 표시됩니다.
REACT_APP_ORDERS_URL=/service/orders REACT_APP_PRODUCTS_URL=/service/products
REACT_APP_ORDERS_URL를 새 형식으로 바꾸고, 아래와 일치하도록 주문 마이크로서비스 IP 주소로 바꿉니다.
REACT_APP_ORDERS_URL=http://<ORDERS_IP_ADDRESS>/api/orders REACT_APP_PRODUCTS_URL=/service/products
CTRL+O, ENTER, CTRL+X를 차례로 눌러 파일을 nano 편집기에 저장합니다.
이 파일에서 방금 설정한 URL로 이동하여 새 마이크로서비스를 테스트할 수 있습니다. 웹페이지가 주문 마이크로서비스의 JSON 응답을 반환해야 합니다.
다음으로는 모놀리식 프런트엔드를 다시 빌드하고 빌드 프로세스를 반복하여 모놀리식용 컨테이너를 빌드하고 GKE 클러스터에 재배포해야 합니다. 다음 명령어를 실행하여 다음 단계를 완료합니다.
모놀리식 구성 파일 다시 빌드
npm run build:monolith
Google Cloud Build로 Docker 컨테이너 만들기
cd ~/monolith-to-microservices/monolith
gcloud builds submit --tag gcr.io/${GOOGLE_CLOUD_PROJECT}/monolith:2.0.0 .
GKE에 컨테이너 배포
kubectl set image deployment/monolith monolith=gcr.io/${GOOGLE_CLOUD_PROJECT}/monolith:2.0.0
이제 브라우저에서 모놀리식 애플리케이션으로 이동한 후 주문 페이지로 이동하여 새 주문 마이크로서비스에 도달했는지 확인할 수 있습니다. 모든 주문 ID는 아래와 같이 서픽스 -MICROSERVICE로 끝나야 합니다.
7. 마이크로서비스로 제품 마이그레이션
신제품 마이크로서비스 만들기
다음에 제품 서비스를 마이그레이션하여 서비스 세분화를 계속 진행할 수 있습니다. 이전 단계와 동일한 절차를 따릅니다. 다음 명령어를 실행하여 Docker 컨테이너를 빌드하고, 컨테이너를 배포하고, Kubernetes 서비스를 통해 노출합니다.
Google Cloud Build로 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
GKE 컨테이너 노출
kubectl expose deployment products --type=LoadBalancer --port 80 --target-port 8082
다음 명령어를 사용하여 주문 서비스에서와 동일한 방식으로 제품 서비스의 공개 IP를 찾습니다.
kubectl get service products
출력:
NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE products 10.3.251.122 203.0.113.0 80:30877/TCP 3d
새로운 제품 마이크로서비스를 가리키도록 모놀리식을 재구성할 때 다음 단계를 위해 IP 주소를 저장하세요.
모놀리식 재구성
nano 편집기를 사용하여 로컬 URL을 새로운 제품 마이크로서비스의 IP 주소로 바꿉니다.
cd ~/monolith-to-microservices/react-app nano .env.monolith
편집기가 열리면 파일은 다음과 같이 표시됩니다.
REACT_APP_ORDERS_URL=http://<ORDERS_IP_ADDRESS>/api/orders REACT_APP_PRODUCTS_URL=/service/products
REACT_APP_PRODUCTS_URL를 새 형식으로 바꾸고 제품 마이크로서비스 IP 주소로 바꿉니다.
REACT_APP_ORDERS_URL=http://<ORDERS_IP_ADDRESS>/api/orders REACT_APP_PRODUCTS_URL=http://<PRODUCTS_IP_ADDRESS>/api/products
CTRL+O, ENTER, CTRL+X를 차례로 눌러 파일을 nano 편집기에 저장합니다.
이 파일에서 방금 설정한 URL로 이동하여 새 마이크로서비스를 테스트할 수 있습니다. 웹페이지가 제품 마이크로서비스의 JSON 응답을 반환해야 합니다.
다음으로는 모놀리식 프런트엔드를 다시 빌드하고 빌드 프로세스를 반복하여 모놀리식용 컨테이너를 빌드하고 GKE 클러스터에 재배포해야 합니다. 다음 명령어를 실행하여 다음 단계를 완료합니다.
모놀리식 구성 파일 다시 빌드
npm run build:monolith
Google Cloud Build로 Docker 컨테이너 만들기
cd ~/monolith-to-microservices/monolith
gcloud builds submit --tag gcr.io/${GOOGLE_CLOUD_PROJECT}/monolith:3.0.0 .
GKE에 컨테이너 배포
kubectl set image deployment/monolith monolith=gcr.io/${GOOGLE_CLOUD_PROJECT}/monolith:3.0.0
이제 브라우저에서 모놀리식 애플리케이션으로 이동한 후 제품 페이지로 이동하여 새 제품 마이크로서비스에 도달했는지 확인할 수 있습니다. 모든 제품 이름에는 아래와 같이 MS-를 접두사로 붙여야 합니다.
8. 프런트엔드를 마이크로서비스로 마이그레이션
마이그레이션 프로세스의 마지막 단계는 프런트엔드 코드를 마이크로서비스로 이동하고 모놀리식을 종료하는 것입니다. 이 단계가 완료되면 모놀리식을 마이크로서비스 아키텍처로 성공적으로 마이그레이션한 것입니다.
새 프런트엔드 마이크로서비스 만들기
마지막 두 단계와 동일한 절차를 따라 새 프런트엔드 마이크로서비스를 만들어 보겠습니다.
이전에는 모놀리식을 다시 빌드할 때 모놀리식을 가리키도록 구성을 업데이트했지만 이제는 프런트엔드 마이크로서비스에도 동일한 구성을 사용해야 합니다. 다음 명령어를 실행하여 마이크로서비스 URL 구성 파일을 프런트엔드 마이크로서비스 코드베이스에 복사합니다.
cd ~/monolith-to-microservices/react-app cp .env.monolith .env npm run build
이 작업이 완료되면 이전 단계와 동일한 절차를 따릅니다. 다음 명령어를 실행하여 Docker 컨테이너를 빌드하고, 컨테이너를 배포하고, Kubernetes 서비스를 통해 노출합니다.
Google Cloud Build로 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
GKE 컨테이너 노출
kubectl expose deployment frontend --type=LoadBalancer --port 80 --target-port 8080
모놀리식 삭제
이제 모든 서비스가 마이크로서비스로 실행되므로 모놀리식 애플리케이션을 삭제할 수 있습니다. 실제 마이그레이션에서는 기존 도메인 이름이 애플리케이션의 새로운 프런트엔드 마이크로서비스를 가리키도록 DNS를 변경하는 등의 작업도 수반됩니다. 다음 명령어를 실행하여 모놀리식을 삭제합니다.
kubectl delete deployment monolith kubectl delete service monolith
작업 테스트
모든 것이 제대로 작동하는지 확인하려면 모놀리식 서비스의 이전 IP 주소가 작동하지 않아야 하고 프런트엔드 서비스의 새 IP 주소가 새 애플리케이션을 호스팅해야 합니다. 모든 서비스와 IP 주소의 목록을 보려면 다음 명령어를 사용합니다.
kubectl get services
출력은 다음과 비슷하게 표시됩니다.
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE frontend LoadBalancer 10.39.246.135 35.227.21.154 80:32663/TCP 12m kubernetes ClusterIP 10.39.240.1 <none> 443/TCP 18d orders LoadBalancer 10.39.243.42 35.243.173.255 80:32714/TCP 31m products LoadBalancer 10.39.250.16 35.243.180.23 80:32335/TCP 21m
프런트엔드 마이크로서비스의 외부 IP 주소를 확인한 후 IP 주소를 복사합니다. 브라우저에서 이 URL (예: http://203.0.113.0)을 가리키면 프런트엔드에 액세스할 수 있는지 확인할 수 있습니다. 웹사이트는 모놀리식을 마이크로서비스로 분류하기 전과 같아야 합니다.
9. 삭제
준비가 되면 수행된 모든 활동을 삭제하는 가장 쉬운 방법은 프로젝트를 삭제하는 것입니다. 프로젝트를 삭제하면 이 Codelab 내에서 생성된 모든 리소스가 삭제되므로 예상치 못한 반복 요금이 발생하지 않습니다. Cloud Shell 내에서 다음을 실행합니다. 여기서 PROJECT_ID는 프로젝트 이름만이 아니라 전체 프로젝트 ID입니다.
gcloud projects delete [PROJECT_ID]
삭제하려면 'Y'를 입력하세요. 표시됩니다.
10. 축하합니다.
모놀리식 애플리케이션을 마이크로서비스로 세분화하고 Google Kubernetes Engine에 배포했습니다.
다음 단계
Kubernetes에 관한 자세한 내용은 다음 Codelab을 확인하세요.
- Google Kubernetes Engine에서 웹사이트 배포, 확장, 업데이트
- Kubernetes에서 Node.js로 Slack 봇 빌드
- Spinnaker를 사용하여 Kubernetes에 지속적 배포
- Google Kubernetes Engine에서 Kubernetes에 Java 애플리케이션 배포
추가 리소스
- Docker: https://docs.docker.com/
- Kubernetes: https://kubernetes.io/docs/home/
- Google Kubernetes Engine (GKE): https://cloud.google.com/kubernetes-engine/docs/
- Google Cloud Build: https://cloud.google.com/cloud-build/docs/
- Google Container Registry: https://cloud.google.com/container-registry/docs/
- 모놀리식을 마이크로서비스로 마이그레이션 - https://cloud.google.com/solutions/migrating-a-monolithic-app-to-microservices-gke