Rolling Update

SI관련 작업을 하다보면 롤링 패치인가? 롤링 업데이트가 가능한가? 라는 질문을 으레 들어본 적이 있었을 것이다.

관련하여 정리된 내용이 별로 없는 것 같아서 토막글로 정리해 놓음.

그래도 최근 쿠버네티스 기반의 분산 시스템이 늘어나면서 관련 정리 자료가 많아진 것 같아 크게 설명할 내용은 없을 것 같다. https://kubernetes.io/ko/docs/tutorials/kubernetes-basics/update/update-intro/

Rolling Update를 하는 목적

• 서비스 중단 없이 어플리케이션 업데이트를 수행 / 또는 롤백

짧게 줄이면 딱 이 한 구절로 설명이 끝난다.

Rolling Update가 불가능한 상황

아래와 같은 어플리케이션의 경우에는 Rolling Update가 불가능하거나, 제한적으로 가능할 수 있다.

• 어플리케이션 변경사항에 프로토콜 변경이 포함되었을 때
  • 프로토콜이 변경되면 다른 어플리케이션과의 상호 소통이 되지 않아, 클러스터 시스템에서는 문제가 될 수 있다.
  • 최근에는 이러한 상황을 방지하기 위해 버전 정보를 추가한 REST API 형태를 많이 쓰기도 하지만... 그럼에도 불구하고 새로운 프로토콜이 포함되는 설계가 들어오면 (major change) 어쨌든 힘들 가능성이 있음.
  • 절충안: 문제가 되는 프로토콜 사용을 전체 인스턴스의 롤링패치 하는 동안만 임시적으로 막도록 합의할 수 있으면, 롤링패치를 허용할 수 있음.
• 어플리케이션 자체가 인스턴스의 유연한 변경을 허용하지 않음
  • 직설적으로 말하면 어플리케이션 자체에서 instance 만 재생성 하는 것을 허용하지 않는 경우를 이야기한다 (...) 그런데 클러스터 구조의 어플리케이션이 그럴 수가 있을까?

롤링 업데이트가 불가능하다면, 전체 instance를 모조리 정리하고 다시 생성하는 재생성 전략(Recreate)를 수행해야 함.

Rolling Update의 원리

• 어떤 서비스를 구성하는 Instance가 하나 이상이어야 함
• instance로의 접속을 관장하는 Load balancer이 존재하거나, clustering 구조로 되어 있는 어플리케이션이어야 함.
• 이러한 상황에서, 각 instance(pod)를 하나하나씩 종료 및 재생성을 수행함. 이에 따라 기존 Replica Set을 대체하는 작업이 수행되고, 이것이 완료되었을 때 Rolling Update가 완료됨.

• instance가 내려갔을 때 순간적으로 다른 인스턴스에 오버헤드가 전이될 수는 있음 (성능 하락). 그래도 무중단 서비스가 가능하다는 것이 롤링패치의 가장 큰 의의이다.

출처

• 이미지 출처: https://ooeunz.tistory.com/124