1. 소개
모놀리식 애플리케이션을 마이크로서비스 아키텍처로 마이그레이션해야 하는 이유는 무엇일까요? 애플리케이션을 마이크로서비스로 분할하면 다음과 같은 이점이 있습니다. 마이크로서비스가 느슨하게 결합된 점과 관련된 이점이 대부분입니다.
- 마이크로서비스는 독립적으로 테스트하고 배포할 수 있습니다. 배포 단위가 작을수록 배포가 쉬워집니다.
- 다양한 언어와 프레임워크로 구현할 수 있습니다. 각 마이크로서비스마다 특정 사용 사례에 가장 적합한 기술을 자유롭게 선택할 수 있습니다.
- 여러 팀이 관리할 수 있습니다. 마이크로서비스 간에 경계가 있어 하나 또는 여러 개의 마이크로서비스에 전담 팀 하나를 배정하기가 더 쉽습니다.
- 마이크로서비스로 전환하면 팀 간 종속성이 느슨해집니다. 각 팀은 사용 중인 마이크로서비스의 API만 신경 쓰면 됩니다. 마이크로서비스의 구현 방식, 출시 주기 등에 대해 생각할 필요가 없습니다.
- 오류에 대비한 설계를 더 쉽게 수행할 수 있습니다. 서비스 간에 명확한 경계를 두면 서비스가 중지된 경우에 해야 할 일을 더 쉽게 판단할 수 있습니다.
모놀리식과 비교했을 때 몇 가지 단점은 다음과 같습니다.
- 마이크로서비스 기반 앱은 상호작용 방식이 대체로 불분명한 여러 서비스의 네트워크이기 때문에 시스템의 전반적인 복잡성이 증가하는 경향이 있습니다.
- 모놀리식의 내부 기능과 달리 마이크로서비스는 네트워크를 통해 통신합니다. 경우에 따라 이는 보안 문제로 볼 수 있습니다. Istio는 마이크로서비스 간의 트래픽을 자동으로 암호화하여 이 문제를 해결합니다.
- 서비스 간 지연 시간 때문에 모놀리식 접근법과 동일한 수준의 성능을 달성하기가 어려울 수 있습니다.
- 시스템의 동작은 단일 서비스로 인해 발생하는 것이 아니라 많은 서비스와 상호작용으로 인해 발생합니다. 따라서 시스템이 프로덕션 환경에서 어떻게 작동하는지 이해하는 것(모니터링 가능성)이 더 어렵습니다. 이 문제도 Istio로 해결할 수 있습니다.
이 실습에서는 Google Kubernetes Engine (GKE)에서 마이크로서비스를 실행합니다. Kubernetes는 컨테이너를 관리, 호스팅, 확장, 배포하는 플랫폼이며, 컨테이너는 이식 가능한 방식으로 코드를 패키징하고 실행하는 데 사용됩니다. 이들은 각 마이크로서비스가 자체 컨테이너에서 실행될 수 있는 마이크로서비스 패턴에 매우 적합합니다.
이 실습에서는 기존 모놀리식 애플리케이션을 Google Kubernetes Engine 클러스터에 배포한 다음 마이크로서비스로 분할합니다.
마이크로서비스 아키텍처 다이어그램
먼저 모놀리식을 한 번에 하나씩 세 개의 마이크로서비스로 분할합니다. 마이크로서비스에는 주문, 제품, 프런트엔드가 포함됩니다. 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가 사용 설정되어 있는지 확인해야 합니다. 다음 명령어를 실행하여 컨테이너 API를 사용 설정하면 Google Kubernetes Engine을 사용할 수 있습니다.
gcloud services enable container.googleapis.com
이제 클러스터를 만들 준비가 되었습니다. 아래 명령어를 실행하여 3개의 노드가 있는 fancy-cluster라는 GKE 클러스터를 만듭니다.
gcloud container clusters create fancy-cluster --num-nodes 3
클러스터가 생성되려면 몇 분 정도 걸릴 수 있습니다. 명령어가 완료되면 다음 명령어를 실행하여 클러스터의 3개 작업자 VM 인스턴스를 확인합니다.
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 주소를 확인한 후 복사합니다. 모놀리식에 액세스할 수 있는지 확인하려면 브라우저가 이 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에 넣을 수 있습니다. 이렇게 하면 단일 명령어를 실행하여 이미지를 빌드하고 컨테이너 레지스트리로 이동할 수 있습니다. docker 파일을 직접 만들고 푸시하는 프로세스를 보려면 여기로 이동하세요.
Google Cloud Build는 디렉터리의 파일을 압축하여 Google Cloud Storage 버킷으로 이동합니다. 그러면 빌드 프로세스가 버킷의 모든 파일을 가져와 Dockerfile을 사용하여 Docker 빌드 프로세스를 실행합니다. Docker 이미지에 대해 호스트를 gcr.io로 지정하여 --tag 플래그를 지정했으므로 결과 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
배포 확인
배포가 성공적으로 생성되었는지 확인하려면 다음 명령어를 실행합니다. 포드 상태가 'Running'이 되기까지 시간이 걸릴 수 있습니다.
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에서 서비스를 노출했습니다. 이 서비스를 외부에 노출하려면 LoadBalancer 유형의 Kubernetes 서비스를 만들어 포트 80의 트래픽을 외부에서 주문 서비스의 내부 포트 8081로 라우팅해야 합니다. 다음 명령어를 실행하여 웹사이트를 인터넷에 노출합니다.
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을 업데이트해야 합니다. 마이크로서비스 마이그레이션 프로세스 중에 마이크로서비스와 모놀리식을 프로덕션으로 이동할 계획을 세울 때 이를 고려해야 합니다.
모놀리식에서 구성 파일을 업데이트하여 새로운 주문 마이크로서비스 IP 주소를 가리키도록 해야 합니다. nano 편집기를 사용하여 로컬 URL을 새 주문 마이크로서비스의 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에 배포했습니다.
다음 단계
다음 Codelab을 확인하여 Kubernetes에 대해 자세히 알아보세요.
- 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