모놀리식 VM 마이그레이션 - 최적화
워크로드가 VM에서 컨테이너로 마이그레이션되면 많은 가능성이 열립니다. 컨테이너를 최적화하고 현대화 도구 및 프로세스를 적용할 수 있습니다. 워크로드와 배포의 소스 코드를 수정하면 훨씬 더 쉬워집니다. 로깅 및 모니터링과 같은 작업 도구를 즉시 워크로드와 완전히 통합할 수 있습니다.
목표
이 튜토리얼에서는 다음 방법을 배웁니다.
- 마이그레이션 아티팩트를 살펴봅니다.
- 마이그레이션된 워크로드의 소스 코드와 Dockerfile을 수정합니다.
- Cloud 운영을 활용하여 마이그레이션된 워크로드의 로그를 모니터링하고 확인합니다.
- 현대화 권장사항을 사용하여 워크로드를 추가로 최적화합니다.
시작하기 전에
이 튜토리얼은 마이그레이션 및 배포의 후속 튜토리얼입니다. 시작하기 전에 안내에 따라 VM의 마이그레이션 계획을 만들고 맞춤설정합니다. 그런 다음 컨테이너화된 아티팩트를 배포합니다.
마이그레이션 아티팩트 살펴보기
이 섹션에서는 마이그레이션 프로세스 과정에서 생성된 일부 아티팩트와 해당 역할에 대해 알아봅니다. 그런 다음 이 파일을 수정하여 향후 워크로드를 보강하고 업데이트할 수 있습니다.
Dockerfile구성을 봅니다.cat ${HOME}/bank-of-anthos/src/ledgermonolith/DockerfileFROM anthos-migrate.gcr.io/v2k-run-embedded:v1.12.1 as migrate-for-anthos-runtime FROM gcr.io/my-project/ledgermonolith-service-non-runnable-base:8-25-2022--22-12-57 as source-content COPY --from=migrate-for-anthos-runtime / / ADD blocklist.yaml /.m4a/blocklist.yaml ADD logs.yaml /code/config/logs/logsArtifact.yaml ADD services-config.yaml /.m4a/ ENTRYPOINT [ "/.v2k.go" ]
이 파일에는 이 워크로드의 컨테이너 이미지를 생성하는 데 필요한 단계가 포함되어 있습니다. 라이브러리를 추가 및 업데이트하고 소스 코드를 수정하며 새 파일을 추가할 수 있습니다. 여기에서 이 구성에 대한 최신 참조를 확인할 수 있습니다.
deployment_spec.yaml파일을 봅니다.cat ${HOME}/bank-of-anthos/src/ledgermonolith/deployment_spec.yamlapiVersion: apps/v1 kind: StatefulSet metadata: creationTimestamp: null labels: app: ledgermonolith-service migrate-for-anthos-optimization: "true" migrate-for-anthos-version: v1.12.1 name: ledgermonolith-service spec: replicas: 1 selector: matchLabels: app: ledgermonolith-service migrate-for-anthos-optimization: "true" migrate-for-anthos-version: v1.12.1 serviceName: ledgermonolith-service template: metadata: creationTimestamp: null labels: app: ledgermonolith-service migrate-for-anthos-optimization: "true" migrate-for-anthos-version: v1.12.1 spec: containers: - env: - name: HC_V2K_SERVICE_MANAGER value: "true" image: gcr.io/my-project/ledgermonolith-service:8-25-2022--22-12-57 imagePullPolicy: IfNotPresent name: ledgermonolith-service resources: {} volumeMounts: - mountPath: /var/lib/postgresql name: ledgermonolith-db subPath: var/lib/postgresql volumes: - name: ledgermonolith-db persistentVolumeClaim: claimName: ledgermonolith-db updateStrategy: {} . . . . . .이 파일에는 마이그레이션된 워크로드에 대한 Kubernetes 리소스 정의가 포함됩니다. 프로세스의 StatefulSet, 포트의 서비스, 마이그레이션된 데이터베이스를 포함하는 PersistentVolumeClaim 및 PersistentVolume 쌍을 정의합니다.
이 샘플 출력에서 StatefulSet의 Docker 이미지 세트는 마이그레이션 프로세스 중에 생성되고 원본 VM의 워크로드를 포함하는
gcr.io/my-project/ledgermonolith-service:11-24-2021--16-22-59입니다.
소스 코드 수정
다음으로 워크로드 및 Dockerfile의 소스 코드를 수정하고, 새 컨테이너 이미지를 태그하고 푸시하고, 업데이트된 워크로드를 클러스터에 배포하는 방법을 알아봅니다.
잔액을 쿼리할 때 항상 정적 잔액을 반환하도록 원장의 기본 컨트롤러를 수정합니다. 다음 명령어를 실행하여
Long balance = 12345L;을Long balance = info.getBalance();로 바꿉니다.sed -i 's/Long balance = info.getBalance();/Long balance = 12345L;/g' \
${HOME}/bank-of-anthos/src/ledgermonolith/src/main/java/anthos/samples/bankofanthos/ledgermonolith/LedgerMonolithController.java서비스 소스 코드의 루트로 이동하여 자바 아티팩트를 빌드합니다.
cd ${HOME}/bank-of-anthos/src/ledgermonolith/mvn -f . packageDockerfile에
COPY명령어를 추가하여 새로 빌드된 자바 아티팩트를 컨테이너 이미지에 복사합니다.echo "COPY ${HOME}/bank-of-anthos/src/ledgermonolith/target/ledgermonolith-1.0.jar /opt/monolith/ledgermonolith.jar" >> ${HOME}/bank-of-anthos/src/ledgermonolith/Dockerfile컨테이너 이미지를 빌드하고 푸시합니다.
docker build . -t gcr.io/$PROJECT_ID/ledgermonolith-service:static-balance --no-cache
docker push gcr.io/$PROJECT_ID/ledgermonolith-service:static-balance이미지 소스를 최근에 푸시된 이미지로 변경합니다.
sed -i 's/image:.*/gcr.io\/$PROJECT_ID\/ledgermonolith-service:static-balance/g' ${HOME}/bank-of-anthos/src/ledgermonolith/deployment_spec.yamlkubectl apply -f ${HOME}/bank-of-anthos/src/ledgermonolith/deployment_spec.yaml다음 명령어를 사용하여 포드 상태를 볼 수 있습니다.
kubectl get pods
ledgermonolith-service포드가 작동 및 실행되는 데 몇 초 정도 걸릴 수 있습니다.NAME READY STATUS RESTARTS AGE accounts-db-0 1/1 Running 0 3m53s contacts-d5dcdc87c-jbrhf 1/1 Running 0 3m53s frontend-5768bd978-xdvpl 1/1 Running 0 3m53s ledgermonolith-service-0 1/1 Running 0 1m11s loadgenerator-8485dfd-582xv 1/1 Running 0 3m53s userservice-8477dfcb46-rzw7z 1/1 Running 0 3m53s
모든 포드가
Running으로 설정되면 LoadBalancer의frontend외부 IP 주소를 찾을 수 있습니다.kubectl get service frontend
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE frontend LoadBalancer 10.79.248.161 ##.##.##.##. 80:31304/TCP 46m
브라우저를 열고 앞서 확인한 외부 IP 주소로 웹페이지를 방문합니다. HTTPS 대신 HTTP를 사용하세요.
http://EXTERNAL_IP
기본 사용자 인증 정보로 로그인하고 트랜잭션을 볼 수 있어야 합니다. 이제 소스 코드 변경에서 예상한 대로 잔액이 $123.45로 표시됩니다.
컨테이너 모니터링
이 섹션에서는 워크로드를 컨테이너로 마이그레이션하여 로그 탐색, 애플리케이션 및 서비스 모니터링과 같은 관측 가능성을 지원하는 방법을 알아봅니다.
Google Cloud 콘솔을 열고 GKE 제품으로 이동하여 워크로드를 클릭합니다.
ledgermonolith-service워크로드를 찾아 클릭하여 현재 및 이전 상태를 봅니다. 이 페이지에서 메모리와 CPU 사용량뿐만 아니라 이벤트 및 사양을 볼 수 있습니다.
로그 탭을 클릭하여 워크로드의 이전 로그를 확인합니다. Cloud Logging을 사용하여 이 정보를 확인할 수도 있습니다.
추가 최적화
여기에는 컨테이너 환경을 개선할 수 있는 다양한 최적화 프로세스와 활동이 있습니다. 다음은 이 튜토리얼의 범위를 벗어나는 몇 가지 활동의 예시입니다.
보안 및 ID 정책을 추가합니다. 정책을 설정하면 다양한 워크로드와 구성에 대한 액세스를 외부뿐만 아니라 서비스 간에 내부적으로 제한할 수 있습니다. 역할 기반 액세스 제어, 인그레스 및 이그레스 액세스와 같은 정책이 포함됩니다.
지속적 통합 및 배포 파이프라인과 통합합니다. 지속적 통합 및 배포 파이프라인에 워크로드를 통합하면 기능 개발 및 테스트 속도를 가속화할 수 있습니다.
마이그레이션된 워크로드를 마이크로서비스로 분리합니다. 현재 마이그레이션된
ledgermonolith-service워크로드는 3개의 논리 프로세스 및 데이터베이스로 구성됩니다. 이러한 서비스는 여러 마이크로서비스로 분할 가능하여 특정 서비스 및 프로세스를 대상으로 하는 보다 상세한 확장 및 정책을 설정할 수 있습니다. 덕분에 개발 및 반복 시 문제를 줄일 수 있습니다.서비스 메시를 구성합니다. 워크로드에서 서비스 메시를 구현하면 트래픽 관리, 상호 인증, 관측 가능성과 같은 기능이 제공됩니다. 서비스 메시는 단일 클러스터 내에서 또는 여러 클러스터에서 구현될 수 있습니다.
자동 확장 및 순차적 업데이트를 사용 설정합니다. 자동 확장 및 순차적 업데이트를 설정하면 Kubernetes에서 워크로드의 내결함성과 가용성이 높아집니다. 자동 확장에는 노드와 포드의 수평 확장, 할당된 리소스의 수직 확장이 포함됩니다. 워크로드의 복제본을 여러 개 예약하고 복원력이 우수한 방식으로 한 번에 하나씩 업그레이드하여 이 기능을 구성합니다.
요약
여러 개의 서비스로 구성된 실시간 애플리케이션으로 이 튜토리얼 시리즈를 시작했습니다. 일부 서비스는 GKE 클러스터에 상주하며 일부 서비스는 Compute Engine의 VM에 상주합니다. 모놀리식 서비스와 데이터베이스를 VM에서 GKE 클러스터로 성공적으로 마이그레이션했습니다. 이 프로세스는 컴퓨팅 비용을 절감하고 개발자의 개발 편의성을 높여줍니다. 마지막으로 소스 코드와 현대화 권장사항을 빠르게 반복하는 방법을 배웠습니다.
삭제
불필요한 Google Cloud 요금이 청구되지 않게 하려면 사용을 마친 후 이 튜토리얼에서 사용한 리소스를 삭제해야 합니다. 이러한 리소스는 다음과 같습니다.
boa-clusterGKE 클러스터migration-processingGKE 클러스터ledgermonolith-serviceCompute Engine VM
이러한 리소스를 수동으로 삭제하거나 다음 단계에 따라 프로젝트를 삭제하여, 모든 리소스를 삭제할 수도 있습니다.
다음 단계
- 마이그레이션 계획을 위한 권장사항을 알아봅니다.