왜 무중단 배포가 중요한가?

IT분야의 빠른 변화와 함께 다양한 키워드들이 부상하고 있다. MSA, Agile, docker 등등, 다양한 기술들이 활발하게 적용된다. 필자는 이런 기술들이 적용되는 이유는 빠르게 변화하는 환경에 대응할 수 있는 확장성을 갖추기 위한 것이라고 생각한다.

MSA를 통해 서비스 별로 적합한 기술스택과 소규모 배포를 가능하게 하고,
Agile 프로세스를 통해 시장의 흐름에 걸맞게 스프린트 단위로 기능을 유동적으로 개발할 수 있게 하고,
docker를 통해 가상화 환경과 높은 이식성으로 안정적이고 빠른 배포 환경을 구축한다.

즉, 위 모든 기술들은 결국 DevOps와 깊은 연관이 있다. 결국 시장 흐름을 따라가기 위해 잦은 수정과 배포를 진행하기 위한 베이스라는 것이다. 하지만 배포를 하면서 사용자들이 매번 서비스를 사용하지 못하는 문제가 발생한다면, 이 모든 노력이 결국에는 마이너스 요소가 될 것이다. 따라서 이번에는 배포 중에도 정상적으로 서비스가 운영될 수 있도록 하는 몇 가지 기술들에 대해 알아보려고 한다.

무중단 배포

앞서 말했듯, 무중단 배포는 배포 중에 서비스 기능은 멈추지 않고, 실제 사용자들이 정상적으로 서비스를 사용할 수 있는 편의를 제공하는 배포 방법이다. 이 무중단 배포 방법들에 공통점으로는 2가지가 있다.

1. 단일 서버로는 불가능하다

배포 중에는 결국 잠깐이라도 서비스 중인 서버가 내려가고 새 서버가 동작하는 시간(Downtime)이 필요하기 때문에 절대 단일 서버로는 구축할 수 없다
즉, 무중단 배포는 최소 2개 이상의 서버로 구성되어야 한다.

2. 로드밸런서가 필요하다

먼저, 프론트와 백엔드가 직접적으로 연결되어 있는 상황을 가정해보자. 무중단 배포를 위해서, 프론트는 모든 서버의 IP를 알고 있어야하며, 이 중 어떤 서버가 가능한지 알고 그 서버에 요청을 날려야한다. 또한, 트래픽에 대한 정보가 일괄적으로 관리되지 않기 때문에 유동적인 트래픽 관리도 불가능해서 배포 과정에서 서비스가 정상적으로 운영될 수 있는지 확인도 힘들 것이다.
즉, 보안적으로도, 효율적으로도, 안정적인 측면에서도 프론트와 백엔드가 직접 연결되면 안된다.
( 사실 무중단 배포가 아니라도 해당되는 내용이지만, 무중단 배포에서는 특히 그렇다고 생각한다 )

따라서 앞단에 로드밸런서를 둬서 클라이언트에서 들어오는 모든 요청을 받아서 처리하는 환경을 구성해야한다. 배포 정책에 따라 적절한 서버로 요청을 넘겨주고, 분산시켜주는 방식으로 무중단 배포 중에도 안정적으로 서비스를 운영할 수 있다.

무중단 배포 방법 종류

무중단 배포 방식은 크게 3가지가 있다. 각각의 방식은 호환성, 자원 효율성, 안정성 등의 측면에서 차별화된다.

1. 롤링 배포

먼저 롤링 배포의 경우에는 기존 운영중인 서버 중 일부 단위만큼씩 새 버전으로 점진적으로 교체하는 방식이다. 하지만 그 동안 가용 가능한 서버 자원이 줄어들기 때문에, 서버 자원이 충분한지 확실한 검증 하에 진행되어야 한다. 또한, 구 버전과 신 버전이 같이 서비스되기 때문에 호환성 검증도 필요하다.

단점

• 구 버전, 신 버전의 호환성 확인 필요
• 배포 동안 가용 가능한 서버 자원 감소

2. 블루-그린 배포

기존 버전(블루)에 연결되어 있던 트래픽을 일괄적으로 신 버전(그린)으로 전환하는 배포 방식이다. 이를 위해서는 신 버전을 미리 배포해놓는 사전 작업이 필요하다. 또한, 한꺼번에 모든 서비스를 전환하기 때문에, 신 버전이 정상적으로 동작하는지에 대한 테스팅이 뒷받침되어야 한다. 다만, 일반적인 배포 방식보다 서버 자원을 두배로 유지해야한다는 단점이 있다.

장점

• 신, 구버전 호환성 검증 필요 없음
• 신 버전을 미리 배포해놓기 때문에, 실제와 동일한 환경 하에서 미리 테스팅 가능

단점

• 서버 자원을 두 배로 유지해야함
• 신 버전에 대한 확실한 테스팅 필요

3. 카나리 배포

카나리 배포는 롤링 배포와 블루-그린 배포를 복합적으로 융합한 배포 방식이다. 신 버전의 대상, 비율 등을 관리자 입장에서 직접 조절해가며 배포해가는 방식이다.
신 버전의 비율을 유동적으로 늘려간다는 부분에서 롤링 배포와 유사하며, 실제 환경에서 미리 테스팅을 진행한다는 점에서 블루-그린 배포와 비슷하다.

하지만 롤링 배포의 경우에는 단순히 신 버전으로의 전환을 위해 점진적으로 교체해나간다면, 카나리 배포는 일부 사용자들, 혹은 기기에 대한 모니터링 및 테스팅 과정을 위해 신 버전의 비율을 조절한다. 그리고 블루-그린처럼 서버 자원도 신 버전 서버를 별도로 구성하여 배포 진행 중에 가용 자원이 줄어들지 않는다.
또한, 블루-그린 배포의 경우에는 프로덕션 환경 기반이지만 실제 사용자로 테스팅하지 않으며, 자원을 기존보다 2배 더 사용해야하지만, 카나리 배포는 실 사용자의 동작에서 발생하는 문제들을 모니터링할 수 있으며, 유동적인 자원 관리가 가능하다.

장점

• 실제 사용자의 동작을 기반으로 신 버전의 테스팅 및 모니터링을 진행할 수 있다.
• 원하는 사용자 스펙트럼을 지정해서 신 버전을 제공할 수 있다.

단점

• 신, 구 버전의 호환성을 검증해야함

마치며

사용자의 니즈가 매 순간 바뀌고 새로운 기술이 발생하고 있는 현대 사회에서 경쟁력있는 서비스를 만들기 위해서는 무중단 배포를 기반으로 다양한 DevOps 환경을 구축하는 것이 선택이 아닌 필수로 보인다.