이번 가변 인프라 구조와 불변 인프라 구조를 통해서 장단점을 명확하게 비교해보고자 한다.
가변 인프라 구조는 무엇인가? 가변성은 변화를 뜻한다. 즉, 인프라 입장에서 배포된 서버가 변화함을 의미한다.
서버를 운영할 때, 베어메탈 서버 위에 OS를 설치하고, 필요한 소프트웨어와 애플리케이션들을 설치하여 운영한다. 또 만약 이 서버에 문제가 생기거나 하면, 그걸 위한 튜닝, 패치등의 변화들이 추가되게 된다. 그런 서버에 애플리케이션은 CI/CD 형태로 배포하는 구조를 가지고 있다.
이처럼 한번 설치된 서버에 계속해서 설정을 변경하고 어떤 패치를 적용하는 등의 업데이트를 하면서 운영하는 서버를 "눈송이 서버"라고 한다. 이런 서버들은 관리자들이 바뀌고, 유지보수하는 사람들이 바뀌고 서버가 기존에 본래 역할로 사용되기보다는 또 다른 목적으로 사용되기도 하면서 히스토리 관리가 잘 되지않고, 같은 애플리케이션이 배포되어있지만 각각의 서버에는 예전에 업데이트된 패치 버전이 다를 수도 있고, 이런 것들은 개발자들에게
"A 인스턴스는 잘 동작하는데 B 인스턴스는 왜 동작을 이상하게 하지?"
위와 같은 혼란을 줄 수도 있다.
NOTE
NOTE
초기의 PC방도 SnowFlake 방식이였다. 여러 사용자들이 하나의 PC를 사용하다보면 각자 설치하고싶은 프로그램들을 설치하고 다양한 파일들을 다운로드 받는다. 그러면서 PC 상태는 시간이 흐를수록 좋지 않게 되고, 단골 손님들은 자연스럽게 상태가 안좋은 PC는 피해서 자리를 선택한다. 물론, 현재는 사용자가 사용 종료를 하면 매번 새롭게 초기화를 하여 이런 문제를 해결했다.
SnowFlake 서버는 멀리서보면 같은 서버처럼 보이지만, 사실 눈송이 처럼 가까이서보면 모두 다르게 생긴 것이다. 이렇기 때문에 사실 눈송이 서버들은 운영할 때 부담이 생길 수 밖에 없고, 한 두대가 아니라, 수십대, 수백대의 눈송이 서버라면 관리하기가 더욱 어려워진다.
이런 단점을 극복하고자 Immutable Infra Strcture 가 필요하게 되었다.
위와 같은 SnowFlake 서버를 만들지 않으려면 어떤 방법이 있을까? SnowFlake 는 같은 서버에 계속적인 변화를 주고 이 변화가 쌓이면서 생기는 문제다.
NOTE
변화가 쌓이더라도 잘 관리하면 되는 것 아닌가 싶을 수 도 있다. 하지만 관리하는 주체가 사람이라는 것을 잊어서는 안된다. 사람은 실수를 하고, 때로는 어떤 변화를 준 것에 대한 문서화를 하기보다는 문서화 하지않고 변화를 주는 경우도 많다.
계속적인 변화를 주지 않으려면, 변화를 주기보다는 매번 새롭게 할당하면 된다. 그러면 이전에 변경된 기록은 모두 날아가기 때문이다.
그러면 백엔드 서버도 이처럼 관리할 수 있을까? 이런 SnowFlake 를 극복하기 위해 나온 패턴이 Phoenix Server (피닉스 서버) `이다. 피닉스는 re-born 하는 특징이 있다.
이런 피닉스의 특징에 따라서 해당 패턴에서는 무언가 새로 배포할 때 항상 초기화를 한다.
만약에 우리가 linux os 기반에 java 프로그램을 운영한다고 해보자. 여기에 에이전트를 하나 설치한다고 가정하자. 그러면 기존에는 각각의 서버에 CI/CD 를 이용해서 에이전트를 설치하거나, 이런 배포 파이프라인이 구성되어있지 않다면 각각의 인스턴스에 직접 접속하여 에이전트를 설치해주어야 할 것이다.
피닉스 패턴에서는 이런 방식으로 하지않고, 새 VM을 다시 만들고, OS를 설치하고, 자바 환경을 만들고, 에이전트를 설치한 다음에 이 VM으로 기존의 VM과 교체한다.
그렇다면 매번 이렇게 다시 설치를 해야하나? 그러면 시간과 비용이 많이 들지않을까? 물론 매번 새롭게 설치하는 개념은 아니다. 기존에 반복적으로 설치되는 것은 Base Image 로 만들어놓고 새롭게 추가되는 Image 만 추가하여서 생성되는 것이다. 이런 것이 가능하게 된 것은 프로세스 격리 기술인 컨테이너 기술이 발전하면서 가능해졌다. 이번 글에서는 컨테이너 기술에 관련된 얘기가 아니기 때문에 이 부분에 대한 설명은 스킵한다.
이런 피닉스 패턴에서는 어떤 장점이 있을까? 먼저 배포하기 위한 서버 환경이 스크립트에 남기 때문에 이 스크립트가 배포되면 어떤 서버 환경이 구축되는지 알 수 있다. 또, 베어메탈 인스턴스에 배포하기 때문에 이전에 눈송이 서버 같은 형태가 아니라 같은 이미지를 사용한 동일한 서버들을 쉽게 생성해낼 수 있다. 만약 긴급한 상황에 서버를 늘려야 할때 서버에 여러 필요한 서비스들을 설치해야 한다고 생각해보자. 그만큼 시간 소요가 될것이지만, 이렇게 이미지로 관리를 하면 이미지를 배포만 하면 해결되는 것이다.