PKOS 2기 4주차 - Argo Rollout(feat. Prometheus)

3주차때 우리는 Rollout을 하는법을 알아보았다. 이번에는 Prometheus를 통해 메트릭을 측정하여 자동으로 정상인 상황이면 promo하는 구성을 해보려고 한다. 물론 이 부분은 Prometheus가 아니더라도 다양한 메트릭을 활용할 수 있다. 대표적인게 DataDog이다.

참고 : https://argoproj.github.io/argo-rollouts/analysis/datadog/

DataDog - Argo Rollouts - Kubernetes Progressive Delivery Controller

자 그러면 우선 이번에 쓸 prometheus에 대해 알아보자

Archiectecture

prometheur architecture

근데 참고로 저 Prometheus Server 가 문제가 많다. 실제 운영 황경을 들어가면 단일 server는 터지는 경우가 심심하지 않게 발생하고 조금 헤비하게 사용한다면 Federation을 구성해서 사용하는데 remote-write 하는 구성에 심각한 부하가 생긴다.

 

대강 보면 Prometheus Server가 하는 행위들인데 여기서 Config부터 memory에 적제하는 영역의 부하가 상당하다. 그래서 각 클러스터에는 작은 server를 구성하고 Prometheus 서버를 따로 두어 Federation 거는 형태로 만들 수 있다.(이건 만약에 AMP에 기능이 나오게 된다면 시도해 볼거다...)

자 그럼 본론으로 다시 들어가서 저 Prometheus가 각 Node별로 긁은 정보를 쿼리해보자.

잘 찍힌다. 그러면 이 쿼리를 가지고 AnalysisTemplate을 만들거다. AnalysisTemplate는 Progrtessive Delivery에 중요한 역할을 한다.

참고 : https://argoproj.github.io/argo-rollouts/features/analysis/

Overview - Argo Rollouts - Kubernetes Progressive Delivery Controller

각 정보를 긁어서 successCondition에 맞으면 성공으로 보고 프로모션을 자동으로 진행한다. interval과 count 값을 함께 주어 적당한 선에서 성공 여부를 판단할 수 있다. 

apiVersion: argoproj.io/v1alpha1
kind: AnalysisTemplate
metadata:
  name: success-rate
spec:
  args:
    - name: service
    - name: namespace
  metrics:
    - count: 1
      initialDelay: 10s
      interval: 60s
      name: success-rate
      provider:
        prometheus:
          address: http://prometheus.istio-system:9090
          query: "sum(irate(istio_requests_total{\n  reporter=\"source\",\n  destination_service=~\"{{args.service}}.{{args.namespace}}.svc.cluster.local\",\n
            \ response_code!~\"5.*\"}[2m])\n) / sum(irate(istio_requests_total{\n  reporter=\"source\",\n
            \ destination_service=~\"{{args.service}}.{{args.namespace}}.svc.cluster.local\"}[2m])\n)
            \   \n\n"
      successCondition: isNaN(result[0]) || result[0] >= 0.90

우선 난 위처럼 istio의 트래픽을 활용했다. 마침 최근 Istio를 깊게 들여볼일이 있다 보니 자연스럽게 세팅까지 마무리 되었다. 우선 위처럼 템플릿을 만들고 이전에 만든것처럼 argo rollout에 적용해 주면끝이다.

strategy:
    canary:
      canaryService: rollouts-demo-canary
      maxUnavailable: 0
      stableService: rollouts-demo-stable
      steps:
        - setWeight: 25
        - pause:
            duration: 10
        - analysis:
            args:
              - name: service
                value: rollouts-demo-root
              - name: namespace
                value: default
        - setWeight: 40
        - pause:
            duration: 10
        - setWeight: 60
        - pause:
            duration: 10
        - setWeight: 80
        - pause:
            duration: 10
      trafficRouting:
        alb:
          ingress: rollouts-demo-ingress
          rootService: rollouts-demo-root
          servicePort: 80

이렇게 Step 항목에 넣어주면 된다. 그리고 rollout dashboard를 보면 아래와 같이 나온다.

초기에 25% 트래픽 전달후 analysis을 기다리며 트래픽을 확인한뒤 promo를 하라는 의미다. 

 

이렇게 되면 보다 안정적으로 서비스를 배포할 수 있다. 물론 이 트래픽은 위에서 언급한것처럼 다른 모니터링 시스템과 결합되지 필요에 따라 다양한 쿼리를 조합해서 사용해보자!