배포 자동화 시 고려해야 할 안정성 체크

1,510 단어·4 분·원문(.md)

배포 자동화에서 안정성 체크는 배포전 CI, 배포중 CD, 배포 이후 Post-Release의 3단계로 나뉘어

시스템적으로 강제 gatekeeping 되어야 한다. 사람이 직접 개입하여 확인하는 과정을 스크립트와 모니터링 툴로 대체하는것이 핵심이다.

배포 전 검증 Continuous Integration #

코드가 빌드되어 아키텍트(예: docker image, jar)로 만들어지기 전에 실행되는 품질 및 보안 검사다.

정적 코드 분석 static code analysis: sonarQube등을 연동하여 코드 스멜, 잠재적 버그 및 보안 취약점, 테스트 커버리지 기준 미달시 빌드 실패 처리하는 작업등이 있다.

컨테이너 이미지 스켄 vulnerability scanning도 있는데 이건 빌드된 도커 이미지 내에 알려진 os 취약점 CVE이나 만료된 라이브러리가 포함되어있는지 검사하는 것이다. High/Critical 등급의 취약점 발견시 배포를 차단한다.

배포 중 상태 검증 Continuous Deployment #

새로운 버전의 애플리케이션이 실제 서버나 컨테이너 오케스트레이션 환경에 올라갈때 트래픽을 받을 준비가 되어잇는지 시스템이 확인하는 검사다.

Readiness Probe(준비 상태 검사): 서버 프로세스가 뜬 직후가 아니라 db 커넥션 풀 초기화나 캐시 로딩등 실제 요청을 처리할 수 있는 상태가 되었는지를 확인한다. 이 검사를 통과해야만 로드밸런서가 해당 서버로 트래픽을 라우팅한다.

Liveness Probe(생존 상태 검사): 애플리케이션이 교착상태 deadlock에 빠지지 않고 정상 동작 중인지 주기적으로 확인한다.

배포 후 검증 Post-Deployment / Automated Rollback #

새 버전으로 트래픽이 인입되기 시작한 직후, 실제 지표 메트릭을 바탕으로 배포의 성공 여부를 판별하고 이상 발생시 자동으로 롤백하는 단계다.

스모크 테스트라고 하는 배포 직후 핵심 api 예를들어 /health, /api/v1/status에 자동화된 http 요청을 보내 200을 받고 응답시간을 확인한다.

지표 기반 자동 롤백 Metric-based Rollback은 배포 이후 5~10분간 에러율이나 지연 시간 지표를 수집하여, 설정된 임계치를 초과하면 사람의 승인 없이 즉시 이전 버전으로 트래픽을 원복한다.

실전 예시 자료 (코드, 명령어, 설정 파일) #

각 단계별 안정성 체크를 어떻게 코드로 구현하는지 예시를 알아보자/

CI단계 Trivy를 이용한 컨테이너 이미지 보안 스캔

CI 스크립트 github actions, jenkins 같은곳에 추가하여 배포될 이미지의 보안 취약점을 스캔하는 명령어다.

# Trivy를 사용하여 'CRITICAL' 등급의 취약점이 하나라도 발견되면 exit code 1을 반환하여 파이프라인을 중단시킴
trivy image --severity CRITICAL --exit-code 1 my-registry/my-backend-app:v2.0

my-registry/my-backend-app:v2.0 (alpine 3.15.0)
===============================================
Total: 1 (CRITICAL: 1)

+----------------+------------------+----------+-------------------+---------------+---------------------------------------+
|    Library     |  Vulnerability   | Severity | Installed Version | Fixed Version |                 Title                 |
+----------------+------------------+----------+-------------------+---------------+---------------------------------------+
| openssl        | CVE-2022-0778    | CRITICAL | 1.1.1l-r0         | 1.1.1n-r0     | openssl: Infinite loop in BN_mod_sqrt |
+----------------+------------------+----------+-------------------+---------------+---------------------------------------+

위의 결과를 해석해보면 OpenSSL 라이브러리에서 무한 루프 취약점이 발견되어 ci 파이프라인이 즉시 중단 되었다는 것을 의미한다.

이어서 CD 단계 k8s 파드 상태 검증 liveness,readiness probe를 확인해보자

가장 기본적이고 필수적인 쿠버네티스 안정성 체크 설정이다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: payment-api
spec:
  template:
    spec:
      containers:
      - name: payment-api
        image: my-registry/payment-api:v2.0
        ports:
        - containerPort: 8080
        
        # Readiness Probe: 트래픽을 받을 준비가 되었는지 검사
        readinessProbe:
          httpGet:
            path: /actuator/health/readiness # Spring Boot Actuator 경로 예시
            port: 8080
          initialDelaySeconds: 10 # 컨테이너 시작 후 10초 뒤부터 검사 시작
          periodSeconds: 5        # 5초 주기로 검사
          successThreshold: 1     # 1번 성공하면 Ready 상태로 전환 (트래픽 인입 시작)
          failureThreshold: 3     # 3번 연속 실패 시 Not Ready 처리 (트래픽 차단)

        # Liveness Probe: 앱이 죽어있는지(Deadlock 등) 검사
        livenessProbe:
          httpGet:
            path: /actuator/health/liveness
            port: 8080
          initialDelaySeconds: 20
          periodSeconds: 10
          failureThreshold: 3     # 3번 연속 실패 시 해당 파드를 강제 재시작(Restart)

배포 이후에 ArgoCD Rollouts를 활용해 메티륵 기반 자동 롤백을 구현해보자

카나리 배포 도중 프로메테우스 지표를 확인하여 에러율이 기준치를 넘으면 자동으로 롤백시키는 설정이다.

apiVersion: argoproj.io/v1alpha1
kind: AnalysisTemplate
metadata:
  name: error-rate-check
spec:
  metrics:
  - name: error-rate
    # 5분 간격으로 에러율을 측정하여, 5% 이하(<= 0.05)일 때만 배포를 통과시킴
    successCondition: result[0] <= 0.05
    provider:
      prometheus:
        address: http://prometheus.monitoring.svc.cluster.local:9090
        # 최근 5분간의 5xx 에러율을 계산하는 PromQL 쿼리
        query: >+
          sum(rate(http_requests_total{status=~"5.*", service="payment-api"}[5m])) 
          / 
          sum(rate(http_requests_total{service="payment-api"}[5m]))

ArgoCD가 새 버전을 배포한 후 이 쿼리를 평가한다 결과값이 0.06 (6%)가 되면 successCondition을 만족하지 못하므로, 즉시 배포 프로세스를 중단하고 구버전으로 트래픽을 100% 롤백 처리한다.

SRE/question/q_49.md