콘텐츠로 이동

service mesh 마이크로서비스 아키텍처 개발부터 카나리 배포까지 전체 워크플로우 모범 사례 (하)

소개

이 장에서는 카나리 배포의 전체적인 상황을 소개하고, Guance을 활용하여 마이크로서비스의 메트릭, 트레이스, 로그를 관측합니다. Rancher에 대한 모든 작업은 k8s-solution-cluster 클러스터에서 수행하며, 별도로 반복 안내하지 않습니다.

카나리 배포

카나리 배포를 구현하기 위해 마이크로서비스를 배포할 Deployment에 app=reviews 레이블을 추가하여 마이크로서비스 이름을 구분합니다. 첫 번째 배포 버전에는 version=v1 레이블을, 두 번째 배포 버전에는 version=v2 레이블을 추가합니다. 이렇게 레이블을 기준으로 각 버전으로 유입되는 트래픽의 비율을 제어할 수 있습니다. 예를 들어 v2를 배포한 후 90%의 트래픽은 v1 버전으로, 10%의 트래픽은 v2 버전으로 보내고, 검증에 문제가 없으면 모든 트래픽을 v2 버전으로 전환한 후 v1 버전을 내립니다. 이렇게 전체 배포가 완료됩니다.

image

1단계: reviews 삭제

이전 편에서 Gitlab-CI 자동화 배포를 설명하기 위해 reviews의 세 가지 버전을 배포했습니다. 이번 작업 전에 세 가지 reviews 배포 버전을 삭제해야 합니다. 'Rancher'에 로그인하여 클러스터에서 '워크로드' -> 'Deployments'로 차례로 이동한 후 reviews-v1을 찾아 오른쪽에서 '삭제'를 선택합니다. 같은 방식으로 reviews-v2, reviews-v3도 삭제합니다.

image

2단계: reviews-v1 배포

'gitlab'에 로그인하여 bookinfo-views 프로젝트를 찾고, .gitlab-ci.yml 파일에서 APP_VERSION 값을 "v1"으로 수정한 후 커밋합니다. 'Rancher'에 로그인하여 클러스터에서 '워크로드' -> 'Deployments'로 차례로 이동하면 reviews-v1이 배포 완료된 것을 확인할 수 있습니다.

image

3단계: DestinationRule 생성

대상 주소를 정의하고, reviews Service의 서비스 디스커버리 시 subsets를 v1과 v2로 나누기 위해 다음 내용을 destination-rule-reviews.yaml 파일에 저장합니다. kubectl을 사용하여 이 리소스를 배포합니다.

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: reviews
  namespace: prod
spec:
  host: reviews
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2

kubectl create -f destination-rule-reviews.yaml

4단계: VirtualService 생성

v2를 배포하기 전에 먼저 모든 트래픽을 v1으로 전환합니다. 다음 내용을 virtual-service-reviews.yaml 파일에 저장합니다.

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: reviews
  namespace: prod
spec:
  hosts:
    - reviews
  http:
  - route:
    - destination:
        host: reviews
        subset: v1

kubectl create -f virtual-service-reviews.yaml

http://8.136.193.105:32156/productpage에 접속합니다.

image

5단계: reviews-v2 배포

'gitlab'에 로그인하여 bookinfo-views 프로젝트를 찾고, .gitlab-ci.yml 파일에서 APP_VERSION 값을 "v2"로 수정한 후 커밋합니다. 'Rancher'에 로그인하여 클러스터에서 '워크로드' -> 'Deployments'로 차례로 이동하면 reviews-v2가 배포 완료된 것을 확인할 수 있습니다. v2를 배포했지만 http://8.136.193.105:32156/productpage에 접속하면 reviews 마이크로서비스는 V1 버전으로만 요청을 보냅니다.

image

image

6단계: 10% 트래픽을 reviews-v2로 전환

virtual-service-reviews.yaml 파일을 다음과 같이 수정합니다.

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: reviews
  namespace: prod
spec:
  hosts:
    - reviews
  http:
  - route:
    - destination:
        host: reviews
        subset: v1
      weight: 90
    - destination:
        host: reviews
        subset: v2
      weight: 10

다시 배포합니다.

kubectl replace -f virtual-service-reviews.yaml

http://8.136.193.105:32156/productpage에 여러 번 접속하면 reviews 마이크로서비스의 v1 버전과 v2 버전이 각각 90%와 10%의 트래픽을 수신합니다.

image

image

7단계: reviews-v2 관측

1. APM

'Guance'에 로그인 -> 'APM' -> 오른쪽 상단의 토폴로지 차트. 환경 및 버전 구분 스위치를 켜면 reviews에 두 가지 버전이 있으며, reviews:test:v2가 ratings 서비스를 호출하는 것을 확인할 수 있습니다.

image

image

상단의 '트레이스'를 클릭하고, 리소스별 검색 기능을 사용하여 reviews.prod를 선택한 후 reviews 버전이 v2인 트레이스를 찾아 클릭합니다.

image

상세 페이지에서 플레임 그래프를 관측합니다. 트레이스 호출에 오류나 타임아웃 등의 문제가 있으면 명확하게 확인할 수 있습니다. 여기서 project, version, env 태그는 gitlab의 bookinfo-views 프로젝트에 있는 deployment.yaml 파일에 정의된 annotations입니다.

image

Span 목록에서 각 Span의 실행 시간을 확인합니다.

image

서비스 호출 관계에서 명확한 토폴로지 맵을 확인할 수 있습니다.

image

2 Istio Mesh 모니터링 대시보드

'Guance'에 로그인하여 '시나리오' -> '대시보드 생성'을 클릭하고 Istio Mesh 모니터링 대시보드를 선택합니다. 이 대시보드에서 reviews-v1과 reviews-v2의 호출 비율이 기본적으로 9:1인 것을 확인할 수 있습니다.

image

8단계: 배포 완료

reviews-v2 버전의 마이크로서비스가 정상적으로 검증된 후 모든 트래픽을 v2 버전으로 전환합니다. virtual-service-reviews.yaml 파일을 다음과 같이 수정합니다.

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: reviews
  namespace: prod
spec:
  hosts:
    - reviews
  http:
  - route:
    - destination:
        host: reviews
        subset: v2

다시 배포합니다.

kubectl replace -f virtual-service-reviews.yaml

image

'참고' reviews-v2 버전에 문제가 있는 경우, 'Guance'에 로그인하여 이 장 마지막 절의 트레이스 타임아웃 분석을 참고하여 문제를 분석하고, 6단계를 참고하여 모든 트래픽을 reviews-v1으로 다시 전환한 후 문제가 수정되면 다시 배포합니다.

메트릭

Bookinfo를 배포할 때 사용자 정의 구성을 사용하여 Pod를 활성화할 때 annotations 구성에 measurement_name = "istio_prom"을 추가했습니다. 이것이 바로 메트릭을 istio_prom 메저먼트로 수집하는 설정입니다. 'Guance'에 로그인하여 '메트릭'에서 istio_prom 메저먼트를 확인합니다.

image

이러한 메트릭을 활용하여 프로젝트 필요에 따라 위에서 소개한 Istio Mesh 모니터링 대시보드와 유사한 대시보드를 생성할 수 있습니다.

트레이스

RUM

'Guance'에 로그인하여 'RUM'으로 이동한 후 devops-bookinfo 애플리케이션을 찾아 클릭합니다.

image

UV, PV, 세션 수, 방문한 페이지 등의 정보를 확인합니다.

image

image

'참고' 프론트엔드와 백엔드가 분리된 프로젝트의 경우 탐색기에서 백엔드 트레이스 및 로그와 연동할 수 있습니다. 자세한 작업 단계는 Kubernetes 애플리케이션의 RUM-APM-LOG 연동 분석을 참고하세요.

image

image

image

APM

'Guance'에 로그인하여 'APM'으로 이동합니다. APM을 통해 트레이스 데이터를 확인합니다.

image

image

로그

stdout

DataKit 배포 시 구성에 따라 기본적으로 /dev/stdout으로 출력되는 로그를 수집합니다. 'Guance'에 로그인하여 '로그'로 이동한 후 로그 정보를 확인합니다.

image

'참고' 더 많은 로그 수집 방식은 다음을 참고하세요.

Pod 로그 수집 모범 사례

Kubernetes 클러스터에서 로그 수집의 여러 가지 방법

트레이스 타임아웃 분석

Bookinfo 프로젝트에는 타임아웃을 시연하는 예제가 있습니다. jason 사용자로 로그인하면 ratings 서비스가 타임아웃됩니다. virtual-service-ratings-test-delay.yaml 파일을 다음과 같이 생성합니다.

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: ratings
  namespace: prod
spec:
  hosts:
  - ratings
  http:
  - match:
    - headers:
        end-user:
          exact: jason
    fault:
      delay:
        percentage:
          value: 100.0
        fixedDelay: 7s
    route:
    - destination:
        host: ratings
        subset: v1
  - route:
    - destination:
        host: ratings
        subset: v1

리소스를 생성합니다.

kubectl apply -f virtual-service-ratings-test-delay.yaml

jason으로 로그인합니다. 비밀번호는 비어 있습니다.

image

http://8.136.193.105:32156/productpage에 접속하면 ratings 서비스에 연결할 수 없습니다.

image

'Guance'에 로그인하여 'APM'으로 이동합니다. 타임아웃된 트레이스를 클릭합니다.

image

플레임 그래프를 관측하여 타임아웃 호출을 찾습니다.

image

문서 평가

이 페이지가 도움이 되었나요?