GSP699

개요

모놀리식 애플리케이션을 마이크로서비스 아키텍처로 마이그레이션해야 하는 이유는 무엇일까요? 애플리케이션을 마이크로서비스로 분할하면 다음과 같은 이점이 있는데, 대부분은 마이크로서비스가 느슨하게 결합된 점과 관련된 특성입니다.

• 마이크로서비스는 독립적으로 테스트하고 배포할 수 있습니다. 배포 단위가 작을수록 배포가 쉬워집니다.
• 다양한 언어와 프레임워크로 구현할 수 있습니다. 각 마이크로서비스마다 특정 사용 사례에 가장 적합한 기술을 자유롭게 선택할 수 있습니다.
• 여러 팀이 관리할 수 있습니다. 마이크로서비스 간에 경계가 있어 하나 또는 여러 개의 마이크로서비스에 전담 팀 하나를 배정하기가 더 쉽습니다.
• 마이크로서비스로 전환하면 팀 간 종속성이 느슨해집니다. 각 팀은 사용 중인 마이크로서비스의 API만 신경 쓰면 됩니다. 마이크로서비스의 구현 방식, 출시 주기 등에 대해 생각할 필요가 없습니다.
• 오류에 대비한 설계를 더 쉽게 수행할 수 있습니다. 서비스 간에 명확한 경계를 두면 서비스가 중지된 경우에 해야 할 일을 더 쉽게 판단할 수 있습니다.

모놀리식과 비교했을 때 몇 가지 단점은 다음과 같습니다.

• 마이크로서비스 기반 앱은 상호작용 방식이 대체로 불분명한 여러 서비스의 네트워크이기 때문에 시스템의 전반적인 복잡성이 증가하는 경향이 있습니다.
• 모놀리식의 내부 기능과 달리 마이크로서비스는 네트워크를 통해 통신합니다. 경우에 따라 이는 보안 문제로 볼 수 있습니다. Istio는 마이크로서비스 간의 트래픽을 자동으로 암호화하여 이 문제를 해결합니다.
• 서비스 간 지연 시간 때문에 모놀리식 접근법과 동일한 수준의 성능을 달성하기가 어려울 수 있습니다.
• 시스템의 동작은 단일 서비스로 인해 발생하는 것이 아니라 많은 서비스와 상호작용으로 인해 발생합니다. 따라서 시스템이 프로덕션 환경에서 어떻게 작동하는지 이해하는 것(모니터링 가능성)이 더 어렵습니다. 이 문제도 Istio로 해결할 수 있습니다.

이 실습에서는 기존 모놀리식 애플리케이션을 Google Kubernetes Engine 클러스터에 배포한 다음 마이크로서비스로 분할합니다. Kubernetes는 컨테이너를 관리, 호스팅, 확장, 배포하는 플랫폼이며, 컨테이너는 이식 가능한 방식으로 코드를 패키징하고 실행하는 데 사용됩니다. 이들은 각 마이크로서비스가 자체 컨테이너에서 실행될 수 있는 마이크로서비스 패턴에 매우 적합합니다.

마이크로서비스 아키텍처 다이어그램

먼저 모놀리식을 한 번에 하나씩 세 개의 마이크로서비스로 분할합니다. 마이크로서비스에는 주문, 제품, 프런트엔드가 포함됩니다. Cloud Build를 사용하여 각 마이크로서비스의 Docker 이미지를 빌드한 다음 Kubernetes 서비스 유형 LoadBalancer를 사용하여 Google Kubernetes Engine(GKE)에 마이크로서비스를 배포하고 노출합니다. 이 작업은 각 서비스에 대해 수행하며 동시에 모놀리식에서 리팩터링합니다. 이 프로세스 동안 모놀리식을 삭제할 수 있는 마지막 단계까지 모놀리식과 마이크로서비스가 모두 실행됩니다.

학습할 내용

• 모놀리식을 마이크로서비스로 분할하는 방법
• Google Kubernetes Engine 클러스터를 만드는 방법
• Docker 이미지를 만드는 방법
• Kubernetes에 Docker 이미지를 배포하는 방법

설정 및 요건

실습 시작 버튼을 클릭하기 전에

다음 안내를 확인하세요. 실습에는 시간 제한이 있으며 일시중지할 수 없습니다. 실습 시작을 클릭하면 타이머가 시작됩니다. 이 타이머는 Google Cloud 리소스를 사용할 수 있는 시간이 얼마나 남았는지를 표시합니다.

실무형 실습을 통해 시뮬레이션이나 데모 환경이 아닌 실제 클라우드 환경에서 실습 활동을 진행할 수 있습니다. 실습 시간 동안 Google Cloud에 로그인하고 액세스하는 데 사용할 수 있는 새로운 임시 사용자 인증 정보가 제공됩니다.

이 실습을 완료하려면 다음을 준비해야 합니다.

• 표준 인터넷 브라우저 액세스 권한(Chrome 브라우저 권장)

참고: 이 실습을 실행하려면 시크릿 모드(권장) 또는 시크릿 브라우저 창을 사용하세요. 개인 계정과 학습자 계정 간의 충돌로 개인 계정에 추가 요금이 발생하는 일을 방지해 줍니다.

• 실습을 완료하기에 충분한 시간(실습을 시작하고 나면 일시중지할 수 없음)

참고: 이 실습에는 학습자 계정만 사용하세요. 다른 Google Cloud 계정을 사용하는 경우 해당 계정에 비용이 청구될 수 있습니다.

실습을 시작하고 Google Cloud 콘솔에 로그인하는 방법

1. 실습 시작 버튼을 클릭합니다. 실습 비용을 결제해야 하는 경우 결제 수단을 선택할 수 있는 대화상자가 열립니다. 왼쪽에는 다음과 같은 항목이 포함된 실습 세부정보 창이 있습니다.

   • Google Cloud 콘솔 열기 버튼
   • 남은 시간
   • 이 실습에 사용해야 하는 임시 사용자 인증 정보
   • 필요한 경우 실습 진행을 위한 기타 정보

2. Google Cloud 콘솔 열기를 클릭합니다(Chrome 브라우저를 실행 중인 경우 마우스 오른쪽 버튼으로 클릭하고 시크릿 창에서 링크 열기를 선택합니다).

   실습에서 리소스가 가동되면 다른 탭이 열리고 로그인 페이지가 표시됩니다.

   팁: 두 개의 탭을 각각 별도의 창으로 나란히 정렬하세요.

   참고: 계정 선택 대화상자가 표시되면 다른 계정 사용을 클릭합니다.

3. 필요한 경우 아래의 사용자 이름을 복사하여 로그인 대화상자에 붙여넣습니다.

   {{{user_0.username | "Username"}}}

   실습 세부정보 창에서도 사용자 이름을 확인할 수 있습니다.

4. 다음을 클릭합니다.

5. 아래의 비밀번호를 복사하여 시작하기 대화상자에 붙여넣습니다.

   {{{user_0.password | "Password"}}}

   실습 세부정보 창에서도 비밀번호를 확인할 수 있습니다.

6. 다음을 클릭합니다.

   중요: 실습에서 제공하는 사용자 인증 정보를 사용해야 합니다. Google Cloud 계정 사용자 인증 정보를 사용하지 마세요. 참고: 이 실습에 자신의 Google Cloud 계정을 사용하면 추가 요금이 발생할 수 있습니다.

7. 이후에 표시되는 페이지를 클릭하여 넘깁니다.

   • 이용약관에 동의합니다.
   • 임시 계정이므로 복구 옵션이나 2단계 인증을 추가하지 않습니다.
   • 무료 체험판을 신청하지 않습니다.

잠시 후 Google Cloud 콘솔이 이 탭에서 열립니다.

참고: Google Cloud 제품 및 서비스에 액세스하려면 탐색 메뉴를 클릭하거나 검색창에 제품 또는 서비스 이름을 입력합니다.

Cloud Shell 활성화

Cloud Shell은 다양한 개발 도구가 탑재된 가상 머신으로, 5GB의 영구 홈 디렉터리를 제공하며 Google Cloud에서 실행됩니다. Cloud Shell을 사용하면 명령줄을 통해 Google Cloud 리소스에 액세스할 수 있습니다.

1. Google Cloud 콘솔 상단에서 Cloud Shell 활성화 를 클릭합니다.

2. 다음 창을 클릭합니다.

   • Cloud Shell 정보 창을 통해 계속 진행합니다.
   • 사용자 인증 정보를 사용하여 Google Cloud API를 호출할 수 있도록 Cloud Shell을 승인합니다.

연결되면 사용자 인증이 이미 처리된 것이며 프로젝트가 학습자의 PROJECT_ID, (으)로 설정됩니다. 출력에 이 세션의 PROJECT_ID를 선언하는 줄이 포함됩니다.

Your Cloud Platform project in this session is set to {{{project_0.project_id | "PROJECT_ID"}}}

gcloud는 Google Cloud의 명령줄 도구입니다. Cloud Shell에 사전 설치되어 있으며 명령줄 자동 완성을 지원합니다.

3. (선택사항) 다음 명령어를 사용하여 활성 계정 이름 목록을 표시할 수 있습니다.

gcloud auth list

4. 승인을 클릭합니다.

출력:

ACTIVE: * ACCOUNT: {{{user_0.username | "ACCOUNT"}}} To set the active account, run: $ gcloud config set account `ACCOUNT`

5. (선택사항) 다음 명령어를 사용하여 프로젝트 ID 목록을 표시할 수 있습니다.

gcloud config list project

출력:

[core] project = {{{project_0.project_id | "PROJECT_ID"}}} 참고: gcloud 전체 문서는 Google Cloud에서 gcloud CLI 개요 가이드를 참고하세요.

기본 영역 및 프로젝트 구성을 설정합니다.

gcloud config set compute/zone {{{project_0.default_zone | (zone)}}}

작업 1. 소스 저장소 클론

간단한 시작 페이지, 제품 페이지, 주문 내역 페이지가 있는 가상의 전자상거래 웹사이트의 기존 모놀리식 애플리케이션을 사용합니다. 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

이 스크립트를 실행하는 데 몇 분 정도 걸릴 수 있습니다.

작업 2. GKE 클러스터 만들기

이제 개발자 환경이 작동하므로 모놀리식 애플리케이션과 최종적으로 마이크로서비스를 배포할 Kubernetes 클러스터가 필요합니다. 클러스터를 만들기 전에 적절한 API가 사용 설정되어 있는지 확인합니다.

1. 다음 명령어를 실행하여 Containers API를 사용 설정하면 Google Kubernetes Engine을 사용할 수 있습니다.

gcloud services enable container.googleapis.com

2. 아래 명령어를 실행하여 3개의 노드가 있는 fancy-cluster라는 GKE 클러스터를 만듭니다.

gcloud container clusters create fancy-cluster --num-nodes 3 --machine-type=e2-standard-4 경고: 영역/리전이 지정되지 않았다는 오류가 발생하면 환경 설정 섹션을 참조하여 기본 컴퓨팅 영역을 설정했는지 확인하세요.

클러스터가 생성되려면 몇 분 정도 걸릴 수 있습니다.

3. 명령어 실행이 완료되면 다음 명령어를 실행하여 클러스터의 3개 작업자 VM 인스턴스를 확인합니다.

gcloud compute instances list

출력:

NAME ZONE MACHINE_TYPE PREEMPTIBLE INTERNAL_IP EXTERNAL_IP STATUS gke-fancy-cluster-default-pool-ad92506d-1ng3 {{{project_0.default_zone | (zone)}}} e2-standard-4 10.150.0.7 XX.XX.XX.XX RUNNING gke-fancy-cluster-default-pool-ad92506d-4fvq {{{project_0.default_zone | (zone)}}} e2-standard-4 10.150.0.5 XX.XX.XX.XX RUNNING gke-fancy-cluster-default-pool-ad92506d-4zs3 {{{project_0.default_zone | (zone)}}} e2-standard-4 10.150.0.6 XX.XX.XX.XX RUNNING

또한 Cloud 콘솔에서 Kubernetes 클러스터와 관련 정보를 볼 수 있습니다. 탐색 메뉴에서 Kubernetes Engine까지 아래로 스크롤한 다음 클러스터를 클릭합니다.

fancy-cluster라는 이름의 클러스터가 표시됩니다.

수고하셨습니다. 첫 번째 Kubernetes 클러스터를 만들기가 완료되었습니다.

내 진행 상황 확인하기를 클릭하여 목표를 확인합니다. GKE 클러스터 만들기

작업 3. 기존 모놀리식 배포

이 실습의 초점은 모놀리식을 마이크로서비스로 분할하는 것이므로 모놀리식 애플리케이션을 가동해야 합니다.

• 다음 스크립트를 실행하여 모놀리식 애플리케이션을 GKE 클러스터에 배포합니다.

cd ~/monolith-to-microservices ./deploy-monolith.sh

모놀리식 액세스

1. 모놀리식 애플리케이션의 외부 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

2. 출력에 외부 IP가 <pending>으로 표시되면 잠시 기다린 후 명령어를 다시 실행합니다.

3. 모놀리식의 외부 IP 주소를 확인한 후 복사합니다. 모놀리식에 액세스할 수 있는지 확인하려면 브라우저가 이 URL(예: http://203.0.113.0)을 가리키도록 합니다.

참고: 이 IP 주소는 앞으로 계속 사용되므로 기억해 두세요. 동일한 명령어를 통해 언제든지 다시 찾을 수 있습니다.

모놀리식 웹사이트의 시작 페이지가 표시됩니다. 시작 페이지는 나중에 프런트엔드 마이크로서비스에서 제공할 정적 페이지입니다. 이제 모놀리식이 Kubernetes에서 완전히 실행됩니다.

내 진행 상황 확인하기를 클릭하여 목표를 확인합니다. 기존 모놀리식 배포

작업 4. 주문을 마이크로서비스로 마이그레이션

이제 GKE에서 실행되는 모놀리식 웹사이트가 있으므로 각 서비스를 마이크로서비스로 분할하기 시작합니다. 일반적으로 계획 단계에서 어떤 서비스를 더 작은 단위로 분할할지 결정해야 합니다. 보통 비즈니스 도메인과 같은 애플리케이션의 특정 부분을 중심으로 분할합니다.

이 실습에서는 비즈니스 도메인(주문, 제품, 프런트엔드)을 중심으로 각 서비스를 분리하여 예시를 만듭니다. 코드가 이미 마이그레이션되어 있으므로 Google Kubernetes Engine(GKE)에서 서비스를 빌드하고 배포하는 데 집중할 수 있습니다.

주문 마이크로서비스 생성

가장 먼저 분리할 서비스는 주문 서비스입니다. 제공된 별도의 코드베이스를 활용하고 이 서비스에 대한 별도의 Docker 컨테이너를 만듭니다.

Cloud Build로 Docker 컨테이너 만들기

코드베이스가 이미 제공되어 있으므로 첫 번째 단계는 Cloud Build를 사용하여 주문 서비스의 Docker 컨테이너를 만드는 것입니다.

일반적으로 이 작업은 Docker 컨테이너를 빌드하고 레지스트리로 푸시하여 GKE가 가져올 이미지를 저장하는 2단계 프로세스로 수행됩니다. Cloud Build를 사용하면 단일 명령어로 Docker 컨테이너를 빌드하고 이미지를 Artifact Registry에 넣을 수 있습니다.

Google Cloud Build는 디렉터리의 파일을 압축하여 Cloud Storage 버킷으로 이동합니다. 그러면 빌드 프로세스가 버킷의 모든 파일을 가져와 Dockerfile을 사용하여 Docker 빌드 프로세스를 실행합니다. --tag 플래그는 Docker 이미지의 호스트를 gcr.io로 지정하며, Docker 이미지 결과물은 Artifact Registry로 푸시됩니다.

1. 다음 명령어를 실행하여 Docker 컨테이너를 빌드하고 Artifact Registry에 푸시합니다.

cd ~/monolith-to-microservices/microservices/src/orders gcloud builds submit --tag gcr.io/${GOOGLE_CLOUD_PROJECT}/orders:1.0.0 .

이 프로세스는 1분 정도 걸리지만 완료되면 터미널에 다음과 비슷한 출력이 표시됩니다.

----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- ID CREATE_TIME DURATION SOURCE IMAGES STATUS 1ae295d9-63cb-482c-959b-bc52e9644d53 2019-08-29T01:56:35+00:00 33S gs://_cloudbuild/source/1567043793.94-abfd382011724422bf49af1558b894aa.tgz gcr.io//orders:1.0.0 SUCCESS

2. 빌드 기록을 보거나 프로세스를 실시간으로 확인하려면 콘솔에서 Cloud Build를 검색한 다음 Cloud Build 결과를 클릭합니다.

3. 기록 페이지에서 모든 빌드 목록을 확인할 수 있습니다. 방금 생성한 빌드 1개만 있어야 합니다. 빌드 ID를 클릭하면 로그 출력을 포함한 해당 빌드의 모든 세부정보를 확인할 수 있습니다.

4. 빌드 세부정보 페이지에서 생성된 컨테이너 이미지를 보려면 오른쪽 섹션에서 실행 세부정보 탭을 클릭하고 이미지를 확인합니다.

GKE에 컨테이너 배포

웹사이트를 컨테이너화하고 컨테이너를 Artifact 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 참고: Kubernetes 클러스터에 대한 변경사항(예: 배포 또는 서비스 생성 또는 수정)을 선언할 때는 YAML 파일을 사용하고 GitHub와 같은 소스 제어 시스템을 사용하여 변경사항을 저장하는 것이 좋습니다. 자세한 내용은 Kubernetes 배포 문서를 참조하세요.

배포를 확인합니다.

• 배포가 성공적으로 생성되었는지 확인하려면 다음 명령어를 실행합니다.

kubectl get all

포드 상태가 'Running(실행 중)'으로 바뀌는 데 약간의 시간이 소요될 수 있습니다.

출력:

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 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, 실행 중인 포드를 확인할 수 있습니다. 모든 것이 성공적으로 생성된 것 같습니다.

Cloud 콘솔에서 탐색 메뉴 > Kubernetes Engine > 워크로드로 이동하여 Kubernetes 배포를 볼 수도 있습니다.

GKE 컨테이너 노출

GKE에 애플리케이션을 배포했지만 클러스터 외부에서 애플리케이션에 액세스할 방법이 없습니다. 기본적으로 GKE에서 실행하는 컨테이너에는 외부 IP 주소가 없으므로 인터넷에서 이 컨테이너에 액세스할 수 없습니다. 서비스 리소스를 통해 애플리케이션을 인터넷 트래픽에 명시적으로 노출해야 합니다. 서비스는 애플리케이션의 포드에 네트워킹 및 IP 지원을 제공합니다. GKE는 외부 IP와 부하 분산기를 만듭니다.

이 실습에서는 서비스 노출을 단순화했습니다. 일반적으로 API 게이트웨이를 사용하여 공개 엔드포인트를 보호합니다.

주문 서비스를 배포할 때 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 3s

애플리케이션의 외부 IP 주소를 확인한 후 IP 주소를 복사합니다. 모놀리식이 새 주문 서비스를 가리키도록 변경하는 다음 단계에서 사용하기 위해 저장해 둡니다.

모놀리식 재구성

모놀리식에서 주문 서비스를 삭제했으므로 모놀리식을 수정하여 새로운 외부 주문 마이크로서비스를 가리키도록 해야 합니다.

모놀리식을 분할할 때는 단일 코드베이스에서 여러 마이크로서비스로 코드 조각을 제거하고 이를 개별적으로 배포합니다. 마이크로서비스가 다른 서버에서 실행되고 있으므로 더 이상 서비스 URL을 절대 경로로 참조할 수 없습니다. 주문 마이크로서비스 서버 주소로 라우팅해야 합니다. 이렇게 하려면 모놀리식 서비스의 다운타임이 필요하며, 다운타임 동안 분리된 각 서비스의 URL을 업데이트해야 합니다. 마이크로서비스 마이그레이션 프로세스 중에 마이크로서비스와 모놀리식을 프로덕션으로 이동할 계획을 세울 때 이를 고려해야 합니다.

모놀리식에서 구성 파일을 업데이트하여 새로운 주문 마이크로서비스 IP 주소를 가리키도록 해야 합니다.

1. nano 편집기를 사용하여 로컬 URL을 주문 마이크로서비스의 IP 주소로 바꿉니다.

cd ~/monolith-to-microservices/react-app nano .env.monolith

편집기가 열리면 파일이 다음과 같이 표시됩니다.

REACT_APP_ORDERS_URL=/service/orders REACT_APP_PRODUCTS_URL=/service/products

2. REACT_APP_ORDERS_URL을 새 형식으로 바꾸고 주문 마이크로서비스 IP 주소로 바꿔 아래와 일치하도록 합니다.

REACT_APP_ORDERS_URL=http://<ORDERS_IP_ADDRESS>/api/orders REACT_APP_PRODUCTS_URL=/service/products

3. Ctrl+O, Enter, Ctrl+X를 차례로 눌러 nano 편집기에서 파일을 저장합니다.

4. 파일에서 방금 설정한 URL을 탐색하여 새 마이크로서비스를 테스트합니다. 웹페이지는 주문 마이크로서비스에서 JSON 응답을 반환해야 합니다.

5. 다음으로 모놀리식 프런트엔드를 다시 빌드하고 빌드 프로세스를 반복하여 모놀리식의 컨테이너를 빌드하고 GKE 클러스터에 다시 배포합니다.

npm run build:monolith

6. Cloud Build로 Docker 컨테이너를 만듭니다.

cd ~/monolith-to-microservices/monolith gcloud builds submit --tag gcr.io/${GOOGLE_CLOUD_PROJECT}/monolith:2.0.0 .

7. GKE에 컨테이너를 배포합니다.

kubectl set image deployment/monolith monolith=gcr.io/${GOOGLE_CLOUD_PROJECT}/monolith:2.0.0

8. 브라우저에서 모놀리식 애플리케이션으로 이동하여 주문 페이지로 가서 애플리케이션이 이제 주문 마이크로서비스를 호출하는지 확인합니다. 아래와 같이 모든 주문 ID가 -MICROSERVICE라는 접미사로 끝나야 합니다.

9. 내 진행 상황 확인하기를 클릭하여 목표를 확인합니다. 주문을 마이크로서비스로 마이그레이션

작업 5. 제품을 마이크로서비스로 마이그레이션

새로운 제품 마이크로서비스 만들기

다음으로 제품 서비스를 마이그레이션하여 서비스를 계속 분리합니다. 이전과 동일한 프로세스를 따릅니다. 다음 명령어를 실행하여 Docker 컨테이너를 빌드하고, 컨테이너를 배포하고, Kubernetes 서비스를 통해 노출합니다.

1. Cloud Build로 Docker 컨테이너를 만듭니다.

cd ~/monolith-to-microservices/microservices/src/products gcloud builds submit --tag gcr.io/${GOOGLE_CLOUD_PROJECT}/products:1.0.0 .

2. GKE에 컨테이너를 배포합니다.

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

3. GKE 컨테이너를 노출합니다.

kubectl expose deployment products --type=LoadBalancer --port 80 --target-port 8082

4. 주문 서비스와 동일한 방식으로 제품 서비스의 공개 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 주소를 사용합니다.

모놀리식 재구성

1. 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

2. 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

3. Ctrl+O 키를 누르고 Enter 키를 누른 다음 Ctrl+X 키를 눌러 파일을 저장합니다.

4. 파일에서 방금 설정한 URL을 탐색하여 새 마이크로서비스를 테스트합니다. 웹페이지는 제품 마이크로서비스에서 JSON 응답을 반환해야 합니다.

5. 다음으로 모놀리식 프런트엔드를 다시 빌드하고 빌드 프로세스를 반복하여 모놀리식의 컨테이너를 빌드하고 GKE 클러스터에 다시 배포합니다. 이 단계를 완료하려면 다음 명령어를 실행합니다.

6. 모놀리식 구성 파일을 다시 빌드합니다.

npm run build:monolith

7. Cloud Build로 Docker 컨테이너를 만듭니다.

cd ~/monolith-to-microservices/monolith gcloud builds submit --tag gcr.io/${GOOGLE_CLOUD_PROJECT}/monolith:3.0.0 .

8. GKE에 컨테이너를 배포합니다.

kubectl set image deployment/monolith monolith=gcr.io/${GOOGLE_CLOUD_PROJECT}/monolith:3.0.0

9. 브라우저에서 모놀리식 애플리케이션으로 이동한 다음 제품 페이지로 가서 애플리케이션이 이제 새로운 제품 마이크로서비스를 호출하는지 확인합니다. 아래와 같이 모든 제품 이름에 MS- 프리픽스가 있어야 합니다.

10. 내 진행 상황 확인하기를 클릭하여 목표를 확인합니다. 제품을 마이크로서비스로 마이그레이션

작업 6. 프런트엔드를 마이크로서비스로 마이그레이션

마이그레이션 프로세스의 마지막 단계는 프런트엔드 코드를 마이크로서비스로 이동하고 모놀리식을 종료하는 것입니다. 이 단계를 완료하면 모놀리식을 마이크로서비스 아키텍처로 성공적으로 마이그레이션한 것입니다.

새 프런트엔드 마이크로서비스 만들기

앞의 두 작업과 동일한 절차에 따라 새 프런트엔드 마이크로서비스를 만듭니다.

이전에는 모놀리식을 재빌드할 때 모놀리식을 가리키도록 구성을 업데이트했습니다. 이제 프런트엔드 마이크로서비스에 동일한 구성을 사용해야 합니다.

1. 다음 명령어를 실행하여 마이크로서비스 URL 구성 파일을 프런트엔드 마이크로서비스 코드베이스에 복사합니다.

cd ~/monolith-to-microservices/react-app cp .env.monolith .env npm run build

2. 이 작업이 완료되면 이전 단계와 동일한 프로세스를 따릅니다. 다음 명령어를 실행하여 Docker 컨테이너를 빌드하고, 컨테이너를 배포하고, Kubernetes 서비스를 통해 노출합니다.

3. Google Cloud Build로 Docker 컨테이너를 만듭니다.

cd ~/monolith-to-microservices/microservices/src/frontend gcloud builds submit --tag gcr.io/${GOOGLE_CLOUD_PROJECT}/frontend:1.0.0 .

4. GKE에 컨테이너를 배포합니다.

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

5. GKE 컨테이너를 노출합니다.

kubectl expose deployment frontend --type=LoadBalancer --port 80 --target-port 8080

6. 내 진행 상황 확인하기를 클릭하여 목표를 확인합니다. 프런트엔드를 마이크로서비스로 마이그레이션

모놀리식 삭제

이제 모든 서비스가 마이크로서비스로 실행되므로 모놀리식 애플리케이션을 삭제합니다. 실제 마이그레이션에서는 기존 도메인 이름이 애플리케이션의 새로운 프런트엔드 마이크로서비스를 가리키도록 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 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)을 가리키도록 합니다. 웹사이트는 모놀리식 애플리케이션을 마이크로서비스로 분할하기 전과 동일해야 합니다.

수고하셨습니다.

모놀리식 애플리케이션을 마이크로서비스로 성공적으로 분할하고 Google Kubernetes Engine에 배포했습니다.

다음 단계 / 추가 리소스

• Docker 문서
• Kubernetes 문서
• Google Kubernetes Engine(GKE) 문서
• Google Cloud Build 문서
• 모놀리식을 마이크로서비스로 마이그레이션
• 마이크로서비스 권장사항
• Google Cloud에서 정적 웹 앱 호스팅에 관한 이 동영상을 시청하세요.

Google Cloud 교육 및 자격증

Google Cloud 기술을 최대한 활용하는 데 도움이 됩니다. Google 강의에는 빠른 습득과 지속적인 학습을 지원하는 기술적인 지식과 권장사항이 포함되어 있습니다. 기초에서 고급까지 수준별 학습을 제공하며 바쁜 일정에 알맞은 주문형, 실시간, 가상 옵션이 포함되어 있습니다. 인증은 Google Cloud 기술에 대한 역량과 전문성을 검증하고 입증하는 데 도움이 됩니다.

설명서 최종 업데이트: 2024년 4월 26일

실습 최종 테스트: 2023년 9월 20일

Copyright 2026 Google LLC. All rights reserved. Google 및 Google 로고는 Google LLC의 상표입니다. 기타 모든 회사명 및 제품명은 해당 업체의 상표일 수 있습니다.