앱별 아키텍처 없이는 불변 인프라를 구축할 수 없습니다.

2013년에 우리는 변경 불가능한 서버라는 개념을 처음 접했습니다 . 변경 불가능한 서버는 '변경 불가능하다'는 용어에서 알 수 있듯이 정적입니다. 그 구성은 고정되어 있어서 변경할 수 없습니다(적어도 변경해서는 안 됩니다). 변경이 필요한 경우, 새로운 구성을 갖춘 새 서버가 실행 중인 서버를 대체합니다. 이것이 바람직한 이유는, 특히 클라우드와 고도로 자동화된 온프레미스 환경에서, 구성을 간소화하고 배포를 구동하는 자동화 시스템의 안정성을 향상시키기 때문입니다.

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

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

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

왜 불변 인프라인가?

왜 기업 네트워크 아키텍처를 이렇게 크게 바꾸려고 하시나요? 오늘은 이보다 더 나은 표현을 생각할 수 없어서 제 말을 인용해보겠습니다.

엔트로피 때문이죠.

소프트웨어 엔트로피의 법칙은 Ivar Jacobson 등이 " 객체 지향 소프트웨어 엔지니어링"에서 설명합니다. 사용 사례 중심 접근 방식 ":

열역학 제2법칙은 원칙적으로 폐쇄계 의 무질서는 감소될 수 없고, 단지 변함없이 유지되거나 증가할 수만 있다고 말합니다. 이러한 무질서를 측정하는 기준이 엔트로피 이다. 이 법칙은 소프트웨어 시스템 에도 적용될 수 있다. 시스템이 수정되면 무질서, 즉 엔트로피가 항상 증가하기 때문이다. 이것을 소프트웨어 엔트로피라고 합니다.

이 법은 펌웨어 또는 시스템 수준 업데이트를 적용해야 하는 시스템에도 적용됩니다. 핫픽스와 패치가 배포되는 위치입니다. 완벽한 세상에서라면 구성에 대한 긴급 조정은 엄격하게 따르는 변경 관리 프로세스를 통해서만 변경되어야 합니다. 변경 불가능한(일회용) 인프라가 해결하려는 문제는 시스템에 도입하는 변화가 많을수록 시스템이 점점 더 지저분하고 불안정해지는 것처럼 보인다는 것입니다. 무질서. 혼돈. 엔트로피.

이는 앱 서비스 구성을 변경하거나 최근에 발견된 취약성에 대한 긴급 가상 패치를 배포하는 것만이 아닙니다. 이는 애플리케이션 서비스 구성을 변경하는 데 좋은 이유이지만 유일한 이유는 아닙니다. 핫픽스, 패치, 버전 종속성도 공유 인프라에서 실행되는 123개 구성 중 하나를 변경해야 하는 좋은 이유입니다.

앱별 아키텍처로 전환하면 공유 인프라에서 실행되는 다른 수백 개의 인스턴스 중 하나나 둘, 심지어 열 개가 중단될 가능성을 없앨 수 있습니다. 각 앱에 고유한 데이터 경로를 제공하면 기본적으로 변경 불가능한 인프라 접근 방식을 지원할 수 있는 토대가 마련되며, 이를 통해 코드 기반 자동화 인프라 배포 관행으로의 전환을 보다 잘 지원할 수 있습니다.

이는 전적으로 소프트웨어 기반 애플리케이션 서비스 파이프라인을 의미합니다. 애플리케이션 서비스는 컨테이너 내에서 마이크로서비스가 배포되는 방식과 유사한 "마이크로 애플리케이션 서비스" 아키텍처에 따라 배포됩니다. 

Chef의 Julian Dunn은 그의 블로그 Immutable Infrastructure에서 다음과 같이 잘 설명했습니다. 실용적이냐 아니냐?

변경 불가능한 인프라는 일반적으로 한 번 구축한 스택(가상 머신 이미지, 컨테이너 이미지 또는 기타)으로 정의되며, 하나 이상의 인스턴스를 실행하고 다시는 변경하지 않아도 됩니다. 배포 모델은 인스턴스/컨테이너를 종료하고 1단계부터 다시 시작하는 것입니다. 즉, 새 이미지를 빌드하고 기존 인스턴스는 삭제합니다.

따라서 이를 주어진 애플리케이션에 가장 밀접하게 결합된(affine) 애플리케이션 서비스에 적용하면 네트워크 DDoS 및 기존 포트 기반 방화벽을 통한 액세스와 같은 핵심 공통 공유 서비스로 구성된 2계층 네트워크 아키텍처가 생성되고, 이는 불변으로 처리되고 인프라를 코드 개념으로 사용하여 배포/관리되는 애플리케이션별 "스택"으로 공급됩니다.

하지만 관련 애플리케이션 서비스를 공유 플랫폼에서 먼저 분리해야 하므로, 앱별 인프라 없이는 불변성을 구현할 수 없습니다. 동일한 플랫폼을 소프트웨어 폼 팩터로 사용할 수 있다면 이 프로세스는 더욱 쉬워집니다. 앱별 불변 모델을 본격적으로 구축하는 데 필요한 많은 지식과 툴셋이 이미 갖춰져 있기 때문입니다.

진정한 불변 인프라를 고려하지 않더라도 가장 합리적인 시점(새로운 인프라 버전, 핫픽스, 패치 등)에 이를 활용할 수 있는 능력은 귀하와 인프라가 지원하는 앱의 DevOps 소유자 모두에게 삶을 더 쉽게 만들어 줄 것입니다.