도커 교과서 14장 업그레이드와 롤백을 이용한 업데이트 자동화

14장 업그레이드와 롤백을 이용한 업데이트 자동화

14.1 도커를 사용한 애플리케이션 업그레이드 프로세스

배포 주기는 애플리케이션의 버전을 제외하고 아래 4가지를 고려해야 한다.

A. 의존 모듈의 업데이트

B. 애플리케이션 코드를 컴파일하는 데 사영하는 SDK 업데이트

C. 애플리케이션이 동작하는 플랫폼의 업데이트

D. 운영체제 업데이트

• 애플리케이션에 변경이 없더라도 매달 새 버전을 배포해야 하는것은 부담스러운 일이다.
• 하지만, 주기적인 배포를 자동화하면 빌드에 신뢰감이 생기고, 다음 배포 주기를 기다리지 않고도 작업이 끝난 새 기능을 바로 배포에 포함시킬 수 있다.
• 빌드에 대한 신뢰감은 성공적인 배포가 계속 되어야만 쌓을 수 있다.
• 이 때 중요한 것은 애플리케이션 헬스 체크이고, 헬스 체크 없이는 애플리케이션이 자기 수복성을 가질 수 없고 안전한 업데이트와 롤백도 불가능하다.

$ docker compose -f docker-compose.yml -f prod.yml config > stack.yml

$ vi stack.yml

name: numbers
services:
  numbers-api:
    deploy:
      replicas: 6
      resources:
        limits:
          cpus: 0.5
          memory: "78643200"
    image: diamol/ch08-numbers-api
    networks:
      app-net: null
  numbers-web:
    deploy:
      mode: global
      resources:
        limits:
          cpus: 0.75
          memory: "157286400"
    environment:
      RngApi__Url: <http://numbers-api/rng>
    image: diamol/ch08-numbers-web
    networks:
      app-net: null
    ports:
      - mode: host
        target: 80
        published: "80"
        protocol: tcp
networks:
  app-net:
    name: numbers-prod

도커 스웜에서는 어떤 방식으로 서비스가 배포될지 결정할 수 있는 서비스 모드가 있다.

• global
  • 클러스터 내의 모든 노드에 서비스의 작업을 하나씩 배포한다.
  • 즉, 노드의 수만큼 서비스의 인스턴스가 생성된다.
  • 한 노드에 문제가 발생하더라도 다른 노드에서 서비스가 계속 작동한다.
  • 모든 노드에 부하가 고르게 분산된다.
  • 그러나, 불필요하게 서비스가 많이 배포될 수 있다.
• replicated
  • 사용자가 직접 서비스의 인스턴스 수를 지정한다.
  • 스케줄러가 지정된 수만큼의 인스턴스를 클러스터 내의 노드에 분산하여 배포한다.
  • 필요한 만큼의 인스턴스만 생성하여 자원을 효율적으로 사용할 수 있다.
  • 그러나, 인스턴스 수를 직접 관리해야한다.
  • 기본적으로 도커 스웜에서는 replicated 로 동작한다.

14.2 운영 환경을 위한 롤링 업데이트 설정하기

롤링 업데이트란?

$ docker compose -f docker-compose.yml -f prod.yml -f prod-healthcheck.yml -f v2.yml --log-level ERROR config > stack.yml

$ docker stack deploy -c stack.yml numbers

$ docker stack ps numbers

• 롤링 업데이트란 기존 컨테이너를 먼저 종료시키고 새로운 컨테이너를 실행하는 방식이다.
• 기존 컨테이너가 호스트 컴퓨터의 포트를 계속 연결하고 있다면, 새 컨테이너를 실행할 수 없기 때문이다.
• 레플리카는 하나씩 교체되며, 새 컨테이너가 정상 실행 확인이 완료된 후 다음 컨테이너 업데이트를 진행한다.
• 새 컨테이너가 정상적으로 시작되지 않으면 전체 업데이트가 중단된다.

도커 스웜에서 롤링 업데이트를 제어하기 위해 컴포즈 파일의 deploy 항목에서 설정할 수 있다.

numbers-api:
	deploy:
		update_config:
			parallelism: 3
			monitor: 60s
			failure_action: rollback
			order: start-first

• parallelism
  • 한 번에 교체하는 레플리카의 수
  • 기본값 1
• monitor
  • 다음 컨테이너 교체로 넘어가기 전에 새로 실행한 컨테이너의 이상 여부를 모니터링하는 시간
  • 기본값 0
  • 헬스 체크 설정을 포함한 이미지의 경우 설정값을 늘려야 됨.
  • monitor 시간이 길수로 롤링 업데이트의 신뢰성이 증가한다.
• failure_action
  • monitor에 설정한 시간 이내에 헬스 체크가 실패하거나 컨테이너가 실행되지 않아 롤링 업데이트가 실패한 경우의 조치
  • 기본값은 업데이트 중지.
• order
  • 서비스 업데이트 할 때 기존 컨테이너를 제거하고 새로운 컨테이너를 생성하는 순서를 정의하는 옵션.
  • 기본값 stop-first
  • 새로운 레플리카를 생성하기 전에 기존 레플리카를 먼저 중지.

14.3 서비스 롤백 설정하기

• 도커 스웜에 따로 롤백 명령어는 존재하지 않는다.
• 롤백은 업데이트 과정에서 오류를 일으켰을때 수행된다.
• 애플리케이션을 이전 상태로 되돌리는 것은 서비스 단위로 이루어 진다.

numbers-api:
	deploy:
		rollback_config:
			parallelism: 6
			monitor: 0s
			failure_action: continue
			order: start-first

• start-first
  • 기존 레블리카 종료를 신경 쓰지 않고 먼저 새 레플리카를 실행
• monitor
  • 기본값 0
  • 롤백이 실패하더라도 다음 레플리카를 교체할 것이므로 모니터링 시간이 불필요하다.

14.4 클러스터의 중단 시간

• 컨테이너 오케스트레이션 도구는 여러 대의 컴퓨터를 묶어 하나의 클러스터로 만드는 것이다.
• 하지만, 결국 실제 컨테이너를 실행하는 것은 각각의 컴퓨터이기 때문에 중단 시간이 발생할 수 있다.

드레인 모드(drain mode)

• 노드를 유지보수 모드로 전환하여 서비스에 미치는 영향을 최소화하면서 노드를 안전하게 제거하거나 업데이트하기 위한 목적.
• 드레인 모드로 설정된 노드는 새로운 작업을 받지 않고, 기존에 실행 중이던 작업드을 순차적으로 종료.
• 매니저 노드의 경우, 클러스터 관리 기능은 유지하지만 새로운 작업 분배는 참여하지 않음.
• 단, 드레인 모드는 노드를 완전히 제거하는것이 아님. 노드를 완전히 제거하려면 docker node rm 명령어를 사용.

리더 매니저

• 클러스터의 상태를 관리하고, 다른 노드에 작업을 분배하는 역할.
• 매니저 노드 중 하나가 리더로 선출, 리더가 고장 나면 나머지 매니저 노드 중 하나가 새로운 리더로 선출.
• 리더 매니저가 고장 나더라도 다른 매니저 노드가 자동으로 역할을 수행. 가용성을 보장.

장애 발생 시 시나리오

• 모든 매니저 노드 고장: 클러스 관리 기능이 상실되어 서비스 배포밀 관리가 불가능. 새로운 매니저 노드를 추가하여 클러스터를 복구해야 함.
• 리더가 아닌 한 대의 매니저 노드 고장: 남은 매니저 노드가 리더 역할을 이어받아 클러스터 정상 동작.
• 모든 워커 노드 고장: 서비스 실행을 위한 노드가 없으므로 서비스가 중단. 새로운 워커 노드 추가를 통한 서비스 복구.

14.5 스웜 클러스터의 고가용성

• 여러 데이터 센터에 분산된 도커 스웜 클러스터에서 네트워크 지연으로 인한 성능 저하 문제가 발생할 수 있다.
• 특히, 매니저 노드와 워크 노드 간의 네트워크 지연이 심각한 경우 클러스터 성능에 큰 영향을 미친다.
• 이를 해결하기 위해 데이터 센터벼로 독립적인 클러스터를 구성하는것이 좋다.
• 각 클러스터가 독립적으로 운영되므로, 한 데이터 센터에 장애가 발생하더라도 다른 데이터 센터의 서비스에는 영향을 미치지 않는다.
• 외부 DNS 서비스를 활용하여 사용자 트래픽을 가장 가까운 클러스터로 라우팅하여 사용하면 된다.