dongineer

무중단 배포 - 등장

 나는 귀여운 주니어 개발자로 옛날과 비교하는게 좀 웃기지만, 옛날에 비해 요즘의 서비스는 릴리즈 주기가 몹시 짧다. 

 대부분의 SW 개발 방법론이 폭포수 방식에서 애자일 방식으로 바뀌며 릴리즈 주기가 긴 소프트웨어는 적어졌다. 그만큼 제품은 더 빨리 출시되고, 기능 추가 등의 업데이트 등을 위해 배포가 되는 주기가 짧아졌다. 

 또한 대부분의 큰 소프트웨어에서는 하나의 거대한 아키텍처로 서비스하는 모놀리식 아키텍처에서 서비스를 모듈화하여 개발하고, 모듈별로 배포할 수 있는 마이크로 서비스 아키텍처로 바뀌며 배포하는 크기와 빈도가 달라졌다. 

 폭포수에서 애자일, 모놀리식에서 마이크로서비스 등의 변화를 통해 얻은 이점은 보다 잦은 배포를 통해 시장과 사용자의 요구를 빠르게 충족시키고 서비스의 가치를 높이기 위함이다. 하지만 이런 변화는 운영 안정성 측면에서 부정적인 영향을 미칠 수 있다.

 예를 들어 개발 결과물을 제공하기위해 서버에 배포한다고 가정하자. 최신 어플리케이션은 클라우드 기반으로 구성되어 트래픽에 따라 탄력적인 확장과 고가용성을 보장하지만, 배포 시에는 서비스를 멈춰야 하는 중단 배포 방식의 경우 다운타임이 발생한다. 물론 다운타임이 계획적으로 허용될 수 있다. 은행과 같은 서비스에 유연함에 제한이 있는 서비스가 그렇다. 하지만 전 세계의 사용자를 대상으로 하거나, 24시간 운영이 필요한 서비스라면 항상 가동되어야하는게 좋다. 일반적으로 중단 배포 방식은 사용자에게 불편함과 손실을 야기할 수 있다. 새로운 배포로 인해 문제가 발생하는 경우엔.. 야근해야지 뭐...

 야근이 좋은게 아니라면, 혹은 팀원에게 형 지금 배포중인거 맞지? 소리 듣기 싫은 개발자들은 무중단 배포 방식을 공부하자. 안정적인 배포 체계를 갖추는 것은 다양한 요구사항에도 개발에 집중할 수 있으며 이는 곧 경쟁력이 되고 내 수면시간이 된다. ㅎㅎ;

무중단 배포 - 개념

 무중단 배포는 서비스 장애와 배포의 부담을 최소화 하기 위해 운영중인 서비스를 중단하지 않고, 신규 소프트웨어를 배포하는 기술이다. 

 핵심은 *로드밸런서(Load Balancer)를 통해 연결된 두 개 이상의 (서로 다른 IP 혹은 포트를 가진)인스턴스에 트래픽을 제어해 배포하는 것이다. 배포 작업이 서비스에 영향을 주지 않도록 하기 위해 사용자의 이용량에 따라 인스턴스는 물론, 로드밸런서도 다중화를 고려해야한다. 

 다양한 무중단 배포 방식이 있는데 대표적으로 3개의 방식을 앞으로 3번에 걸쳐 포스팅하려한다.

•  제한된 자원에서 하나씩 배포하여 변경해 나가는 롤링 배포
•  현재 사용중인 버전의 인스턴스 수만큼 새 버전의 인스턴스를 준비해 로드밸런서가 스위칭해주는 블루-그린 배포,
• 새로운 버전 소프트웨어의 모니터링과 검증에 초점을 맞춘 카나리 배포

로드밸런서가 오래된 버전의 서버와 새로운 버전의 서버를 구분하여 요청을 처리하는 것이 가장 큰 동작개념이다.

롤링, 블루-그린, 카나리 맛보기.

더보기

 윈도우 업데이트를 기다리는게 싫다.

(컴퓨터는 2대를 사용중이다.)

롤링 배포 : 1번 컴퓨터 업데이트하는 중엔 2번 컴퓨터를 쓰고, 1번 컴퓨터 업데이트가 끝나면 2번 컴퓨터를 업데이트하며 1번 컴퓨터를 사용

블루 그린 배포 : 누나 컴퓨터 2대에 업데이트 진행하면서 내꺼 쓰고 누나 컴퓨터에 업데이트 끝나면, 내꺼 2대랑 바꾸기.

카나리 배포 : 1번 컴퓨터 업데이트하고 잘되나 안되나 확인 후에 2번 컴퓨터도 업데이트.

로드밸런싱

 로드밸런싱은 서버가 처리해야 할 요청(Load)을 여러대의 서버로 나누어(Balancing) 처리하는 것을 의미한다. 한 대의 서버로 부하가 집중되지 않도록 트래픽을 관리해 각각의 서버가 최적의 퍼포먼스를 보일 수 있도록 하는 것이 목적이다. 

  서비스 초기, 하나의 서버로 모든 클라이언트의 요청을 처리할 수 있다면 로드밸런싱은 필요없다. 하지만 사용자가 많아져 현재의 서버에서 모든 요청을 처리할 수 없다면 *scale-up과 scale-out을 고려해야하고, scale-out을 선택한다면 로드밸런서는 필수적이다. 

scale-up VS scale-out

 scale-up의 경우 서버자체의 성능을 향상시키는 것을 뜻한다. 예를들어 CPU가 i3인 컴퓨터에서 i7으로, m1에서 m2로 업그레이드하는 것과 같다. 주로 하나의 서버에서 모든 데이터가 관리되는 데이터베이스 서버(==RDB)에 적합한 방식이다. 데이터 정합성이나, 이슈관리가 쉽지만 성능향상에 한계가 존재하고, 서버 교체나 업그레이시 다운타임이 발생하며 서버 한대가 부담하는 요청이 많으므로 문제가 생기면 더 큰 타격을 입게 된다. 

 scale-out의 경우 서버를 증설하는 것을 뜻한다. 기존 서버와 동일하거나 낮은 성능의 서버를 추가로 운영하는 것으로, i3인 컴퓨터 추가로 구매하는 것과 같다. 서버 증설은 서버 성능 향상보다 비교적 비용 부담이 적으며, 분산처리에 적합하다. 일반적으로 모든 서버가 동일한 데이터를 갖고 있어야 하므로, 데이터의 변화가 빈번하지 않은 웹 서버에 적합한 방식이다.