GSP736

개요

Cloud Logging 및 함께 사용하는 도구인 Cloud Monitoring은 모든 기능을 갖추고 Google Kubernetes Engine에 깊이 통합되어 있습니다. 이 실습에서는 일반적인 로깅 사용 사례를 통해 Cloud Logging이 GKE 클러스터 및 애플리케이션과 어떻게 작동하는지 학습하고 로그를 수집하는 몇 가지 권장사항을 알아봅니다.

목표

이 실습에서는 다음 작업을 수행하는 방법을 배웁니다.

• Cloud Monitoring을 사용하여 문제 감지
• Cloud Logging을 사용하여 GKE에서 실행되는 애플리케이션 문제 해결

실습에 사용되는 데모 애플리케이션

구체적인 예시를 위해 GKE 클러스터에 배포된 샘플 마이크로서비스 데모 앱의 문제를 해결해 보겠습니다. 이 데모 앱에는 많은 마이크로서비스와 종속 항목이 있습니다. loadgenerator를 사용하여 트래픽을 생성한 다음 Logging, Monitoring, GKE를 사용하여 오류(알림/측정항목)를 확인하고 Logging으로 근본 원인을 파악한 다음 Logging 및 Monitoring으로 문제를 수정/확인합니다.

설정 및 요건

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

다음 안내를 확인하세요. 실습에는 시간 제한이 있으며 일시중지할 수 없습니다. 실습 시작을 클릭하면 타이머가 시작됩니다. 이 타이머는 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 개요 가이드를 참고하세요.

리전 및 영역 설정하기

특정 Compute Engine 리소스는 여러 리전과 영역에 상주합니다. 리전은 리소스를 실행할 수 있는 특정한 지리적 위치로, 각 리전에는 영역이 하나 이상 있습니다.

Cloud 콘솔에서 다음 gcloud 명령어를 실행하여 실습의 기본 리전과 영역을 설정합니다.

gcloud config set compute/zone "{{{project_0.default_zone|ZONE}}}" export ZONE=$(gcloud config get compute/zone) gcloud config set compute/region "{{{project_0.default_region|REGION}}}" export REGION=$(gcloud config get compute/region)

작업 1. 인프라 설정

Google Kubernetes Engine 클러스터에 연결하고 클러스터가 올바르게 생성되었는지 확인합니다.

1. 프로젝트 ID 변수를 설정합니다.

export PROJECT_ID={{{project_0.startup_script.project | Project ID}}}

2. 다음 명령어를 사용하여 클러스터의 상태를 확인합니다.

gcloud container clusters list

클러스터 상태가 'PROVISIONING'이 됩니다.

3. 잠시 기다렸다가 상태가 'RUNNING'이 될 때까지 위의 명령어를 다시 실행합니다. 몇 분 정도 걸릴 수 있습니다.

4. central이라는 이름의 클러스터가 생성되었는지 확인합니다.

탐색 메뉴 > Kubernetes Engine > 클러스터로 이동하여 Cloud 콘솔에서 진행 상황을 모니터링할 수도 있습니다.

5. 클러스터가 'RUNNING' 상태가 되면 클러스터 사용자 인증 정보를 가져옵니다.

gcloud container clusters get-credentials central --zone $ZONE

출력:

Fetching cluster endpoint and auth data. kubeconfig entry generated for central.

6. 노드가 생성되었는지 확인합니다.

kubectl get nodes

다음과 비슷한 결과가 출력됩니다.

NAME STATUS ROLES AGE VERSION gke-central-default-pool-5ff4130f-qz8v Ready 24d v1.27.2-gke.1200 gke-central-default--pool-5ff4130f-ssd2 Ready 24d v1.27.2-gke.1200 gke-central-default--pool-5ff4130f-tz63 Ready 24d v1.27.2-gke.1200 gke-central-default--pool-5ff4130f-zfmn Ready 24d v1.27.2-gke.1200

작업 2. 애플리케이션 배포

다음으로 Hipster Shop이라는 마이크로서비스 애플리케이션을 클러스터에 배포하여 모니터링할 수 있는 워크로드를 만듭니다.

1. 다음을 실행하여 저장소를 클론합니다.

git clone https://github.com/xiangshen-dk/microservices-demo.git

2. microservices-demo 디렉터리로 변경합니다.

cd microservices-demo

3. kubectl을 사용하여 앱을 설치합니다.

kubectl apply -f release/kubernetes-manifests.yaml

4. 모든 것이 제대로 실행되고 있는지 확인합니다.

kubectl get pods

아래와 비슷한 결과가 출력됩니다.

NAME READY STATUS RESTARTS AGE adservice-55f94cfd9c-4lvml 1/1 Running 0 20m cartservice-6f4946f9b8-6wtff 1/1 Running 2 20m checkoutservice-5688779d8c-l6crl 1/1 Running 0 20m currencyservice-665d6f4569-b4sbm 1/1 Running 0 20m emailservice-684c89bcb8-h48sq 1/1 Running 0 20m frontend-67c8475b7d-vktsn 1/1 Running 0 20m loadgenerator-6d646566db-p422w 1/1 Running 0 20m paymentservice-858d89d64c-hmpkg 1/1 Running 0 20m productcatalogservice-bcd85cb5-d6xp4 1/1 Running 0 20m recommendationservice-685d7d6cd9-pxd9g 1/1 Running 0 20m redis-cart-9b864d47f-c9xc6 1/1 Running 0 20m shippingservice-5948f9fb5c-vndcp 1/1 Running 0 20m

5. 다음 단계로 넘어가기 전에 모든 포드에 실행 중 상태가 표시될 때까지 명령어를 계속 재실행합니다.

내 진행 상황 확인하기를 클릭하여 목표를 확인합니다. 애플리케이션 배포

6. 다음을 실행하여 애플리케이션의 외부 IP를 가져옵니다. 이 명령어는 서비스가 배포된 후에만 IP 주소를 반환하므로 외부 IP 주소가 할당될 때까지 명령어를 반복해야 할 수 있습니다.

export EXTERNAL_IP=$(kubectl get service frontend-external | awk 'BEGIN { cnt=0; } { cnt+=1; if (cnt > 1) print $4; }')

7. 마지막으로 앱이 실행 중인지 확인합니다.

curl -o /dev/null -s -w "%{http_code}\n" http://$EXTERNAL_IP

다음과 같은 확인 메시지가 표시됩니다.

200

애플리케이션이 배포된 후 Cloud 콘솔로 이동하여 상태를 확인할 수도 있습니다.

Kubernetes Engine > 워크로드 페이지에서 모든 포드가 정상 상태임을 확인할 수 있습니다.

8. 이제 게이트웨이, 서비스, 인그레스를 선택한 다음 서비스 탭을 클릭하여 모든 서비스가 정상인지 확인합니다. 이 화면에서 애플리케이션 모니터링을 설정합니다.

작업 3. 애플리케이션 열기

1. frontend-external까지 아래로 스크롤하고 서비스의 엔드포인트 IP를 클릭합니다.

그러면 애플리케이션이 열리고 다음과 같은 페이지가 표시됩니다.

작업 4. 로그 기반 측정항목 만들기

이제 Cloud Logging을 구성하여 로그 기반 측정항목을 만듭니다. 로그 기반 측정항목은 로그 항목으로 만든 Cloud Monitoring의 커스텀 측정항목입니다. 로그 기반 측정항목은 로그 항목 수를 계산하고 로그의 값 분포를 추적하는 데 유용합니다. 이 경우 로그 기반 측정항목을 사용하여 프런트엔드 서비스의 오류 수를 계산합니다. 그런 다음 대시보드와 알림 모두에서 측정항목을 사용할 수 있습니다.

1. Cloud 콘솔로 돌아가 탐색 메뉴에서 Logging을 열고 로그 탐색기를 클릭합니다.

2. 쿼리 표시를 사용 설정하고 쿼리 빌더 상자에 다음 쿼리를 추가합니다.

resource.type="k8s_container" severity=ERROR labels."k8s-pod/app": "recommendationservice"

3. 쿼리 실행을 클릭합니다.

사용 중인 쿼리를 사용하면 프런트엔드 포드의 모든 오류를 찾을 수 있습니다. 하지만 아직 오류가 없으므로 지금은 결과가 표시되지 않습니다.

4. 로그 기반 측정항목을 만들려면 작업 드롭다운을 클릭하고 측정항목 만들기를 선택합니다.

5. 측정항목의 이름을 Error_Rate_SLI로 지정하고 측정항목 만들기를 클릭하여 로그 기반 측정항목을 저장합니다.

이제 로그 기반 측정항목 페이지의 사용자 정의 측정항목에 측정항목이 표시됩니다.

내 진행 상황 확인하기를 클릭하여 목표를 확인합니다. 로그 기반 측정항목 만들기

작업 5. 알림 정책 만들기

알림을 통해 클라우드 애플리케이션의 문제를 적시에 파악하여 문제를 신속하게 해결할 수 있습니다. 이제 Cloud Monitoring을 사용하여 이전에 만든 프런트엔드 오류 로그 기반 측정항목을 바탕으로 알림 정책을 만들어 프런트엔드 서비스 가용성을 모니터링합니다. 알림 정책의 조건이 충족되면 Cloud Monitoring이 사고를 만들어 Cloud 콘솔에 표시합니다.

1. 탐색 메뉴에서 Monitoring을 열고 알림을 클릭합니다.

2. 작업공간이 생성되면 상단에서 정책 만들기를 클릭합니다.

참고: 필요한 경우 사용해 보기를 클릭하여 업데이트된 알림 만들기 흐름을 사용하세요.

3. 측정항목 선택 드롭다운을 클릭합니다. 활성을 선택 해제합니다.

4. 리소스 및 측정항목 이름으로 필터링 필드에 Error_Rate를 입력합니다.

5. Kubernetes 컨테이너 > 로그 기반 측정항목을 클릭합니다. logging/user/Error_Rate_SLI를 선택하고 적용을 클릭합니다.

화면에는 다음과 같이 표시됩니다.

6. 순환 기간 함수를 Rate로 설정합니다.

7. 다음을 클릭합니다.

8. 기준값으로 0.5를 설정합니다.

예상한 대로, 장애가 발생하지 않으면, 애플리케이션이 가용성 서비스 수준 목표(SLO)를 충족하고 있는 것입니다.

9. 다음을 다시 클릭합니다.

10. 알림 채널 사용을 사용 중지합니다.

11. Error Rate SLI와 같은 알림 이름을 입력한 다음 다음을 클릭합니다.

12. 알림을 검토한 후 정책 만들기를 클릭합니다.

참고: 이 실습에서는 알림 채널을 만들지 않지만 프로덕션에서 실행되는 애플리케이션의 경우 알림 채널을 만들어야 합니다. 알림 채널을 만들면 이메일, 모바일 앱, SMS, Pub/Sub, 웹훅 등의 방식으로 알림을 보낼 수 있습니다.

내 진행 상황 확인하기를 클릭하여 목표를 확인합니다. 알림 정책 만들기

애플리케이션 오류 트리거

이제 부하 생성기를 사용하여 웹 애플리케이션에 대한 트래픽을 생성합니다. 이 버전의 애플리케이션에는 의도적으로 생성된 버그가 있으므로 특정 트래픽 볼륨이 오류를 트리거합니다. 버그를 식별하고 수정하는 단계를 진행합니다.

1. 탐색 메뉴에서 Kubernetes Engine, 게이트웨이, 서비스, 인그레스를 차례로 선택하고 서비스 탭을 클릭합니다.

2. loadgenerator-external 서비스를 찾은 다음 endpoints 링크를 클릭합니다.

또는 새 브라우저 탭이나 창을 열고 IP를 복사하여 URL 필드에 붙여넣을 수 있습니다(예: http://\[loadgenerator-external-ip\]).

이제 Locust 부하 생성기 페이지가 표시됩니다.

Locust는 웹 앱의 부하 테스트를 수행할 수 있는 오픈소스 부하 생성기입니다. Locust는 특정 속도로 애플리케이션 엔드포인트를 동시에 요청하는 여러 사용자를 시뮬레이션할 수 있습니다.

1. 생성 속도 30으로 300명의 사용자가 앱에 접속하는 상황을 시뮬레이션합니다. Locust는 300명의 사용자에 도달할 때까지 초당 30명의 사용자를 추가합니다.

2. 호스트 필드에는 frontend-external을 사용합니다. '게이트웨이, 서비스, 인그레스' 페이지에서 URL을 복사합니다. 이때 포트는 제외해야 합니다. 예를 들면 다음과 같습니다.

3. 생성 시작 버튼을 클릭합니다. 몇 초 안에 미리 정의된 URL을 조회할 수 있는 사용자가 약 300명이 됩니다.

4. 실패 탭을 클릭하여 실패가 발생하기 시작했는지 확인합니다. 500 오류가 많이 발생한 것을 확인할 수 있습니다.

한편 홈페이지에서 제품을 클릭하면 눈에 띄게 느리거나 다음과 같은 오류가 발생합니다.

알림 및 애플리케이션 오류 확인

1. 콘솔의 탐색 메뉴에서 Monitoring, 알림을 차례로 클릭합니다. logging/user/Error_Rate_SLI에 관한 사고가 곧 표시됩니다. 사고가 바로 표시되지 않으면 1~2분 정도 기다렸다가 페이지를 새로고침하세요. 알림이 실행되는 데 최대 5분이 걸릴 수 있습니다.

2. 사고의 링크를 클릭합니다.

그러면 세부정보 페이지로 이동합니다.

3. 로그 섹션에서 로그 탐색기에서 보기를 클릭하고 드롭다운에서 프로젝트 ID를 선택하여 포드 로그를 봅니다.

4. 로그 필드 탐색기 패널에서 오류 라벨을 클릭하여 오류만 쿼리할 수도 있습니다.

또는 쿼리 미리보기 필드를 클릭하여 쿼리 빌더를 표시한 다음 심각도 드롭다운을 클릭하고 오류를 쿼리에 추가할 수 있습니다. 추가 버튼을 클릭한 다음 쿼리 실행을 클릭합니다. 드롭다운 메뉴를 사용하면 여러 심각도 값을 추가할 수 있습니다.

어떤 방법을 사용하든 쿼리에 severity=ERROR가 추가됩니다. 이렇게 하면 recommendationservice 포드의 모든 오류가 표시됩니다.

5. 오류 이벤트를 펼쳐 오류 세부정보를 확인합니다. 예를 들면 다음과 같습니다.

6. textPayload를 펼칩니다.

7. 오류 메시지를 클릭하고 요약 줄에 필드 추가를 선택하여 오류 메시지가 요약 필드로 표시되도록 합니다.

여기에서 RecommendationService 서비스에 실제로 많은 오류가 있음을 확인할 수 있습니다. 오류 메시지를 보면 RecommendationService가 일부 다운스트림 서비스에 연결하여 제품이나 추천을 가져올 수 없는 것으로 보입니다. 하지만 오류의 근본 원인이 무엇인지는 여전히 불분명합니다.

아키텍처 다이어그램을 다시 살펴보면 RecommendationService가 Frontend 서비스에 추천 목록을 제공합니다. 그러나 Frontend 서비스와 RecommendationService 모두 제품 목록을 위해 ProductCatalogService를 호출합니다.

다음 단계에서는 주요 용의자인 ProductCatalogService의 측정항목에서 이상치를 찾아봅니다. 로그를 드릴다운하여 몇 가지 인사이트를 얻을 수 있습니다.

Kubernetes 대시보드 및 로그를 사용한 문제 해결

1. 측정항목을 살펴볼 수 있는 첫 번째 위치 중 하나는 Monitoring 콘솔의 Kubernetes Engine 섹션(탐색 메뉴 > Monitoring> 대시보드 > GKE)입니다.

2. 워크로드 섹션을 확인합니다.

3. Kubernetes Engine > 워크로드 > productcatalogservice로 이동합니다. 서비스의 포드가 계속해서 비정상 종료되고 다시 시작되는 것을 확인할 수 있습니다.

다음으로 로그에 흥미로운 내용이 있는지 확인합니다.

컨테이너 로그에 쉽게 액세스하는 방법은 두 가지입니다.

1. 로그 탭을 클릭하여 최근 로그를 빠르게 확인합니다. 다음으로 로그 패널의 오른쪽 상단에 있는 외부 링크 버튼을 클릭하여 로그 탐색기로 돌아갑니다.

2. 개요 페이지의 배포 세부정보 페이지에서 컨테이너 로그 링크를 클릭합니다.

다시 로그 탐색기 페이지로 돌아왔습니다. 이제 GKE에서 확인한 컨테이너의 로그를 위해 특별히 필터링된 사전 정의된 쿼리가 표시됩니다.

로그 뷰어에서 로그 메시지와 히스토그램 모두 짧은 시간 내에 컨테이너가 제품 카탈로그를 반복적으로 파싱하고 있음을 보여줍니다. 매우 비효율적인 것 같습니다.

쿼리 결과 하단에 다음과 같은 런타임 오류가 있을 수도 있습니다.

panic: runtime error: invalid memory address or nil pointer dereference [signal SIGSEGV: segmentation violation

이로 인해 포드가 비정상 종료될 수 있습니다.

이유를 더 잘 이해하려면 코드에서 로그 메시지를 검색합니다.

1. Cloud Shell에서 다음 명령어를 실행합니다.

grep -nri 'successfully parsed product catalog json' src

출력은 다음과 같이 소스 파일 이름과 줄 번호가 포함되어야 합니다.

src/productcatalogservice/server.go:237: log.Info("successfully parsed product catalog json")

2. 소스 파일을 보려면 Cloud Shell 메뉴에서 편집기 열기 버튼을 클릭한 다음 새 창에서 열기를 클릭합니다. 서드 파티 쿠키가 사용 중지되어 코드 편집기를 로드할 수 없다는 오류가 표시되면 Chrome 페이지 상단의 눈 모양 아이콘을 클릭합니다.

3. microservices-demo/src/productcatalogservice/server.go 파일을 클릭하고 237번째 줄로 스크롤하면 readCatalogFile 메서드가 다음 메시지를 기록하는 것을 확인할 수 있습니다.

조금 더 자세히 살펴보면 불리언 변수 reloadCatalog가 true인 경우 서비스가 호출될 때마다 제품 카탈로그를 새로고침하고 파싱하는 것을 알 수 있습니다. 이는 불필요해 보입니다.

코드에서 reloadCatalog 변수를 검색하면 환경 변수 ENABLE_RELOAD에 의해 제어되고 상태에 대한 로그 메시지를 작성하는 것을 확인할 수 있습니다.

쿼리에 이 메시지를 추가하여 로그를 다시 확인하고 존재하는 항목이 있는지 확인합니다.

1. 로그 탐색기가 열려 있는 탭으로 돌아가서 다음 줄을 쿼리에 추가합니다.

jsonPayload.message:"catalog reloading"

따라서 쿼리 빌더의 전체 쿼리는 다음과 같습니다.

resource.type="k8s_container" resource.labels.location="{{{project_0.startup_script.zone | ZONE}}}" resource.labels.cluster_name="central" resource.labels.namespace_name="default" labels.k8s-pod/app="productcatalogservice" jsonPayload.message:"catalog reloading"

2. 쿼리 실행을 다시 클릭하고 컨테이너 로그에서 '카탈로그 새로고침 사용 설정' 메시지를 찾습니다. 카탈로그 새로고침 기능이 사용 설정되었음을 확인합니다.

이 시점에서 프런트엔드 오류는 모든 요청에 대해 카탈로그를 로드하는 오버헤드로 인해 발생한다는 것을 확신할 수 있습니다. 부하를 늘리면 오버헤드로 인해 서비스가 실패하고 오류가 발생합니다.

작업 6. 문제 해결 및 결과 확인

코드와 로그에 표시된 내용을 바탕으로 카탈로그 새로고침을 사용 중지하여 문제를 해결해 볼 수 있습니다. 이제 제품 카탈로그 서비스의 ENABLE_RELOAD 환경 변수를 삭제합니다. 변수를 변경한 후 애플리케이션을 재배포하고 변경사항이 관찰된 문제를 해결했는지 확인할 수 있습니다.

1. Cloud Shell 터미널이 닫힌 경우 터미널 열기 버튼을 클릭하여 Cloud Shell 터미널로 돌아갑니다.

2. 다음 명령어를 실행합니다.

grep -A1 -ni ENABLE_RELOAD release/kubernetes-manifests.yaml

출력에 매니페스트 파일의 환경 변수 줄 번호가 표시됩니다.

373: - name: ENABLE_RELOAD 374- value: "1"

3. 이 두 줄을 삭제하여 새로고침을 사용 중지합니다.

sed -i -e '373,374d' release/kubernetes-manifests.yaml

4. 그런 다음 매니페스트 파일을 다시 적용합니다.

kubectl apply -f release/kubernetes-manifests.yaml

productcatalogservice만 구성되어 있음을 알 수 있습니다. 다른 서비스는 변경되지 않습니다.

5. 배포 세부정보 페이지(탐색 메뉴 > Kubernetes Engine > 워크로드 > productcatalogservice)로 돌아가 포드가 성공적으로 실행될 때까지 기다립니다. 2~3분 정도 기다리거나 비정상 종료가 멈춘 것을 확인할 수 있을 때까지 기다립니다.

6. 컨테이너 로그 링크를 다시 클릭하면 반복되던 successfully parsing the catalog json 메시지가 사라진 것을 확인할 수 있습니다.

7. 웹 앱 URL로 돌아가서 홈페이지의 제품을 클릭하면 훨씬 응답이 빠르고 HTTP 오류가 발생하지 않습니다.

8. 부하 생성기로 돌아가서 오른쪽 상단의 통계 재설정 버튼을 클릭합니다. 실패율이 재설정되었으므로 더 이상 증가하지 않습니다.

위의 모든 검사에서 문제가 해결되었음을 나타냅니다. 500 오류가 계속 표시되면 몇 분 더 기다린 후 제품을 다시 클릭해 보세요.

수고하셨습니다

Cloud Logging과 Cloud Monitoring을 사용하여 의도적으로 잘못 구성된 마이크로서비스 데모 앱 버전에서 오류를 찾았습니다. 이는 프로덕션 환경에서 GKE 앱의 문제를 좁히기 위해 사용하는 것과 유사한 문제 해결 프로세스입니다.

먼저 GKE에 앱을 배포한 다음 프런트엔드 오류에 대한 측정항목과 알림을 설정했습니다. 다음으로 부하를 생성한 다음 알림이 트리거된 것을 확인했습니다. 알림을 통해 Cloud Logging을 사용하는 특정 서비스로 문제를 좁혔습니다. 그런 다음 Cloud Monitoring과 GKE UI를 사용하여 GKE 서비스의 측정항목을 살펴보았습니다. 이 문제를 해결하기 위해 업데이트된 구성을 GKE에 배포하고 수정사항이 로그의 오류를 해결했는지 확인했습니다.

다음 단계/더 학습하기

• 이 실습은 GKE에서 실행 중인 앱에 Logging을 사용하는 방법에 관한 블로그 게시물을 기반으로 합니다.
• DevOps팀이 Cloud Monitoring 및 Logging을 사용하여 문제를 빠르게 찾을 수 있는 방법을 다룬 후속 게시물도 흥미롭습니다.

Google Cloud 교육 및 자격증

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

설명서 최종 업데이트: 2025년 2월 21일

실습 최종 테스트: 2025년 2월 21일

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