애플리케이션별 아키텍처 없이는 불변 인프라를 구현할 수 없습니다

F5

2013년으로 거슬러 올라가면, 불변 서버라는 개념이 소개되었습니다. 불변 서버는 '불변'이라는 용어가 시사하듯 정적인 서버입니다. 구성이 고정되어 있어 변경할 수 없으며(또는 적어도 변경해서는 안 됩니다). 변경이 필요한 경우에는 새 구성이 적용된 새 서버가 실행 중인 서버를 대체합니다. 특히 클라우드 및 고도로 자동화된 온프레미스 환경에서 이러한 방식이 바람직한 이유는 구성을 단순화하고 배포를 수행하는 자동화 시스템의 안정성을 높여 주기 때문입니다.

이 개념은 네트워크 및 애플리케이션 서비스에도 클라우드와 컨테이너화된 환경에서는 잘 적용되지만, 기존의 공유 인프라 아키텍처에서는 그렇지 않습니다.

공유 인프라는 여러 서비스가 실행되고 있음을 전제로 하기 때문입니다. F5 iHealth 데이터에 따르면, 여기서 '여러'란 평균 123개의 개별 구성(가상 서버)을 의미할 수 있습니다. 가상 서버 하나를 변경하기 위해 나머지 가상 서버 122개를 중지하고 재배포하는 것은 실용적이지도, 권장되지도 않습니다.

하지만 그렇다고 해서 이 개념이 비현실적이거나 바람직하지 않은 것은 아닙니다. 자동화 및 코드형 인프라(IaC) 시스템과 함께 불변 인프라를 도입하려면 애플리케이션별 아키텍처로 전환하는 것이 핵심입니다.

왜 불변 인프라를 사용해야 할까요?

왜 기업 네트워크 아키텍처를 이처럼 대대적으로 전환하려는 걸까요? 오늘은 이보다 더 잘 표현할 방법이 떠오르지 않으니, 제 말을 직접 인용해 보겠습니다:

왜냐하면 엔트로피 때문입니다.

소프트웨어 엔트로피 법칙은 Ivar Jacobson 등이 저서 "객체지향 소프트웨어 공학: 유스케이스 중심 접근법"에서 다음과 같이 설명합니다:

The 열역학 제2법칙은 원칙적으로 폐쇄계의 무질서도가 감소할 수 없으며, 그대로 유지되거나 증가할 수밖에 없다고 설명합니다. 이러한 무질서도를 측정한 값이 엔트로피입니다. 이 법칙은 소프트웨어 시스템에도 적용되는 것으로 보입니다. 시스템이 수정될수록 무질서도, 즉 엔트로피는 항상 증가합니다. 이를 소프트웨어 엔트로피라고 합니다.

이 법칙은 펌웨어 또는 시스템 수준의 업데이트를 적용해야 하는 시스템에도 해당됩니다. 핫픽스와 패치를 배포해야 하고, 이상적인 환경이라면 엄격한 변경 관리 프로세스를 통해서만 수정해야 할 구성을 긴급하게 조정해야 하는 시스템도 마찬가지입니다. 불변(일회용) 인프라가 해결하려는 문제는 시스템에 변경을 많이 도입할수록 불필요한 요소가 쌓이고 불안정성이 커진다는 것입니다. 무질서. 혼돈. 엔트로피.

단순히 애플리케이션을 지원하기 위해 구성을 변경하거나 최근 발견된 취약점에 대응해 긴급 가상 패치를 배포하는 것만이 문제가 아닙니다. 이러한 이유로 애플리케이션 서비스 구성을 변경할 수 있지만, 그 이유가 전부는 아닙니다. 핫픽스, 패치, 버전 종속성 역시 공유 인프라에서 실행되는 123개의 구성 중 하나를 변경해야 할 수 있는 타당한 이유입니다.

앱별 아키텍처로 전환하면 이러한 인스턴스 중 하나나 둘, 심지어 열 개로 인해 공유 인프라에서 실행 중인 나머지 수백 개의 인스턴스에 장애가 발생할 가능성을 없앨 수 있습니다. 기본적으로 각 앱에 자체 데이터 경로를 제공하면 불변 인프라 접근 방식을 지원할 기반이 마련되며, 이는 자동화된 코드형 인프라 기반 배포 방식으로의 전환을 더욱 효과적으로 뒷받침합니다.

이는 전적으로 소프트웨어 기반으로 구성된 애플리케이션 서비스 파이프라인을 의미합니다. 즉, 컨테이너 내에 마이크로서비스를 배포하는 방식과 유사한 ‘마이크로 애플리케이션 서비스’ 아키텍처로 애플리케이션 서비스를 배포하는 것입니다.

Julian Dunn은 Chef 블로그에서 이를 잘 설명했습니다. - 불변 인프라: 실용적인가, 그렇지 않은가?

불변 인프라는 일반적으로 한 번 구축한 후(가상 머신 이미지, 컨테이너 이미지 또는 그 밖의 형태로) 하나 이상의 인스턴스를 실행하며, 이후에는 절대 변경하지 않는 스택으로 정의됩니다. 이 배포 모델에서는 인스턴스나 컨테이너를 종료한 뒤 첫 단계부터 다시 시작합니다. 즉, 새 이미지를 빌드하고 기존 인스턴스는 폐기합니다.

따라서 이를 특정 애플리케이션과 가장 긴밀하게 결합된(연관성이 높은) 애플리케이션 서비스에 적용하면, 핵심 공통 공유 서비스(예: 네트워크 DDoS 방어 및 기존 포트 기반 방화벽을 통한 액세스)가 애플리케이션별 ‘스택’으로 연결되는 2계층 네트워크 아키텍처가 구성됩니다. 이 스택은 불변 인프라로 취급되며 코드형 인프라 개념을 사용해 배포 및 관리됩니다.

하지만 애플리케이션별 인프라 없이는 불변 인프라를 구현하기가 사실상 불가능합니다. 관련 애플리케이션 서비스를 공유 플랫폼에서 먼저 분리해야 하기 때문입니다. 동일한 플랫폼을 소프트웨어 형태로 사용할 수 있다면 이 과정은 더욱 쉬워집니다. 애플리케이션별 불변 모델을 향해 전속력으로 나아가는 데 필요한 지식과 도구가 이미 상당 부분 갖춰져 있기 때문입니다.

진정한 불변 인프라를 고려하고 있지 않더라도, 가장 적절한 시점(새 인프라 버전, 핫픽스, 패치 등)에 이를 활용할 수 있다면 인프라를 담당하는 여러분과 해당 인프라가 지원하는 애플리케이션의 DevOps 담당자 모두가 훨씬 수월하게 업무를 수행할 수 있습니다.

작성자 소개

F5

F5의 다른 블로그 게시물