변경 불가능한 인프라란 무엇인가요?

조직은 변경 가능 및 변경 불가능의 두 가지 접근 방식을 통해 인프라를 관리할 수 있습니다. 변경 불가능 인프라는 서버를 수정하는 것이 아니라 완전히 대체합니다. 변경 가능한 인프라는 현재 위치에서 서버를 수정하여 업데이트, 패치 및 구성 변경 사항을 프로덕션 서버에 직접 적용합니다.

주로 기존 서버를 수정하기 때문에 변경 가능한 인프라가 더 효율적으로 보일 수 있습니다. 그러나 두 가지 요인으로 인해 변경 불가능한 인프라가 더 실용적이고 선호되는 경우가 많습니다.

첫째, 클라우드 컴퓨팅과 컨테이너화로 인해 배포 속도가 변화했습니다. 조직은 이제 물리적 서버에 필요한 시간이 아닌 몇 분 만에 가상 머신(VM)과 컨테이너를 교체할 수 있습니다. 인프라 자동화 툴은 새로운 서버 및 IT 리소스를 프로비저닝 및 구성하고 대규모로 균일한 변경 사항을 적용할 수 있습니다.

둘째, 변경 불가능한 인프라는 변경 사항이 누적됨에 따라 시스템이 의도한 상태에서 점차적으로 벗어나는 변경 가능한 인프라의 일반적인 기능인 구성 드리프트를 크게 줄일 수 있습니다. 구성 드리프트는 네트워크 문제로 인해 배포 프로세스가 중단되어 부분 업데이트 또는 실패가 발생할 때 특히 일반적입니다. 이러한 드리프트는 성능 저하, 보안 취약성 및 규정 준수 위반으로 이어질 수 있습니다. 

예를 들어, 100개의 프로덕션 서버에 보안 업데이트를 배포하는 경우 자동화 툴은 업데이트가 사전 설치된 100개의 새 서버를 생성하고 격리된 상태에서 검증할 수 있습니다. 검증이 완료되면 트래픽을 리디렉션하고 기존 서버를 폐기하며, 이 모든 작업은 가동 중지 시간 없이 몇 분 안에 완료됩니다.

불변 인프라는 새 리소스를 프로비저닝하고, 배포하고, 필요할 때 즉시 복구할 수 있도록 하는 워크플로를 따릅니다.

이 워크플로는 수명 주기 전반에 걸쳐 서버, 컨테이너, VM, 함수 또는 기타 인프라 리소스에 적용됩니다.

프로비저닝은 선언적 템플릿이나 코드를 사용해 의도된 인프라 상태를 정의하는 방식인 IaC(Infrastructure as Code)를 활용하여 새로운 IT 인프라 구성 요소를 자동으로 생성합니다.

변경할 수 없는 환경을 업데이트하기 위해 팀은 SSH(보안 원격 서버 액세스를 위한 네트워크 프로토콜)를 사용하여 기존 리소스를 수정하는 대신 정의된 구성으로 완전히 새로운 리소스를 만듭니다. 

모든 인프라 변경 사항은 Git과 같은 버전 관리 시스템에 기록되어, 변경 내용이 반드시 테스트되고 재현 가능하도록 보장됩니다.

일반적인 프로비저닝 툴은 다음과 같습니다. 

• Terraform: HashiCorp의 코드형 인프라 플랫폼은 변경 사항을 추적하기 위한 선언적 HCL 구문 및 상태 파일과 함께 API를 통해 AWS, Google Cloud, Azure 및 온프레미스 환경 전반에서 인프라를 프로비저닝하고 관리합니다.

• Docker: 주로 Linux 시스템뿐만 아니라 Windows 및 macOS에서 계층화된 파일 시스템 및 OS 수준 가상화를 기반으로 경량 컨테이너 이미지를 구축하여 기존 VM보다 더 빠르게 배포할 수 있습니다.

• Packer: 단일 JSON 또는 HCL 구성에서 여러 클라우드 제공업체 및 플랫폼(AWS용 AMI, VMware 템플릿, Docker 컨테이너)에 대해 동일한 머신 이미지를 동시에 생성하는 HashiCorp의 툴입니다.

• AWS CloudFormation: JSON/YAML 템플릿을 기반으로 하는 AWS 네이티브 툴로, 내장된 롤백 및 드리프트 감지 기능을 통해 AWS 리소스를 프로비저닝할 수 있습니다. 

• Pulumi: 도메인별 언어 대신 익숙한 프로그래밍 언어(Python, TypeScript, Go)를 사용하는 IaC 플랫폼으로, 개발자가 루프와 조건문과 같은 표준 프로그래밍 구조를 사용할 수 있도록 해줍니다.

Puppet과 Chef는 원래 서버를 업데이트하는 변경 가능한 인프라용으로 설계되었지만 일부 팀은 현재 변경할 수 없는 접근 방식과 함께 이를 적용한다는 점을 언급할 가치가 있습니다.

변경 불가능한 인프라에서의 배포는 원자적이며, 완전히 성공하거나 아예 실행되지 않거나 둘 중 하나입니다. 이 접근 방식은 자동화된 테스트, 빠른 반복 및 안정적인 배포를 강조하는 DevOps 관행 및 지속적 통합 파이프라인과 일치합니다.

자동화 툴은 새 버전의 리소스를 배포하고 트래픽을 리소스로 리디렉션한 다음 이전 버전을 폐기합니다. 배포 중에 문제가 발생하면 기존 리소스는 그대로 유지되고 운영되므로 다운타임과 종속성 위험이 없습니다.

일반적인 배포 및 오케스트레이션 툴은 다음과 같습니다. 

• Kubernetes: 머신 클러스터 전반에서 자가 복구, 자동 확장 및 롤링 업데이트를 통해 클라우드 네이티브 컨테이너화된 애플리케이션을 대규모로 관리하는 오픈 소스 컨테이너 오케스트레이션 플랫폼입니다.

• Jenkins: 빌드, 테스트 및 배포 파이프라인을 사용자 지정하기 위한 광범위한 플러그인 에코시스템(1,800개 이상의 플러그인)을 통해 구축, 테스트 및 배포를 자동화하는 서버 기반 CI/CD 파이프라인입니다.

• GitHub 작업: GitHub 리포지토리에 내장된 이벤트 기반 CI/CD 플랫폼으로, 외부 서버 없이 코드 커밋, 끌어오기 요청 또는 일정에 의해 트리거됩니다.

• Ansible(Red Hat): 주로 구성 관리 툴이지만 배포에도 사용됩니다. 에이전트 없는 자동화를 위해 YAML 플레이북을 사용하며 Puppet 또는 Chef와 달리 노드에 소프트웨어를 설치할 필요가 없습니다. 

변경 불가능한 인프라의 서버는 계속 교체되는 임시적인 것이므로 영구적인 데이터는 외부에 저장해야 합니다. 조직은 cloud databases, block storage 또는 object storage 서비스를 사용하여 교체 대상 서버와 별도로 데이터를 유지 관리합니다. 

새 서버가 온라인 상태가 되면 이러한 외부 스토리지 시스템을 통해 기존 데이터에 다시 연결됩니다. 구성과 메타데이터는 Git과 같은 버전 제어 시스템에 있는 경우가 많습니다. 

업데이트할 때마다 새 인스턴스가 생성되어 롤백을 위한 깨끗한 이미지를 유지합니다. 프로비저닝 및 배포하는 것과 동일한 자동화 툴을 사용하여 몇 분 안에 이전 버전을 복원할 수 있습니다. 팀은 수정된 서버를 디버깅하고 문제를 해결하는 대신 이전 이미지를 다시 배포하므로 구성 관리 변경이 실패할 때 기존에 필요한 탐지 작업이 크게 줄어듭니다.

불변 인프라의 이점은 주로 배포 프로세스와 관련이 있으며, 불변성은 더 간단하고 일관성을 높입니다.

불변 인프라는 원자성 배포를 통해 모호한 서버 상태를 제거하며, 업데이트는 완전히 성공하거나 전혀 성공하지 않습니다.

변경 가능한 인프라는 관리자가 완전히 알지 못하는 특성을 가진 예측할 수 없는 "중간" 상태로 이어지는 부분 업데이트의 위험이 있습니다. 이러한 상황은 문제 해결을 어렵게 만들고 보안 위험을 증가시킬 수 있습니다.

변경 불가능한 인프라는 이러한 상태의 가능성을 제거합니다. 업데이트가 실패하면 서버는 잘 문서화된 상태로 유지됩니다. 성공하면 새 서버가 완전히 구성되고 테스트된 상태로 도착합니다.

변경할 수 없는 인프라는 대규모 시스템(대형 시스템 한 대가 아닌) 네트워크에 더 많은 수의 소규모 시스템을 추가하여 수요를 충족하는 방식인 빠른 수평 확장을 가능하게 합니다. 수평으로 확장된 시스템은 내결함성이 뛰어나며 워크로드를 분산하여 처리 병목 현상을 줄일 수 있습니다.

이 접근 방식은 성능을 향상시키기 위해 여러 서버에 네트워크 트래픽을 분산하는 로드 밸런서를 사용하여 수행됩니다. Nginx 및 Amazon의 AWS ELB(Elastic Load Balancing)와 같은 툴은 알고리즘을 사용하여 특정 순간에 가장 효율적인 서버에 사용자 요청을 할당함으로써 이러한 관행을 지원하는 데 도움이 됩니다.

로드 밸런싱과 컨테이너 오케스트레이션의 이러한 조합은 재현 가능한 템플릿을 갖춘 불변의 인프라를 단기간에 여러 개의 동일한 서버를 구축하는 데 필수적입니다. 이 설정은 쇼핑 연휴나 티켓 판매 기간과 같이 네트워크에 대규모 트래픽 급증이 예상되는 경우에 특히 유용합니다. 또한 트래픽이 서로 다르고 때로는 겹치는 시간에 최고조에 달하는 글로벌 리전을 조정할 때도 도움이 됩니다.

변경 불가능한 인프라는 실패한 업데이트 이후 구성 상태를 알 수 없는 서버들, 즉 예측 불가능한 “스노플레이크 상태”를 제거하고 모든 변경 사항에 대한 완전한 감사 추적을 유지함으로써 보안을 강화합니다.

각 서버는 이를 설명하는 소스 이미지 파일을 정확하게 준수하므로 무단 소프트웨어 설치 또는 권한 상승과 같은 보안 취약점을 더 쉽게 식별하고 보안 감사를 실행할 수 있습니다. 버전 관리 시스템은 누가, 언제, 왜 변경했는지 등 시스템에 대한 각 변경 사항을 추적합니다. 이 변경 불가능한 기록을 통해 더 빠른 포렌식 분석과 인시던트 대응이 가능합니다. 팀은 손상된 구성을 즉시 식별하고 필요한 경우 정상 작동이 확인된 상태로 롤백할 수 있습니다.

또한 변경 불가능한 인프라는 서버를 제자리에서 편집하기 위해 보안 셸(SSH) 로그인을 사용할 필요가 없으므로 네트워크의 전체 공격 표면이 줄어듭니다.

또한 불변성은 주로 데이터 스토리지와 관련하여 기존의 변경 가능한 인프라와 비교하여 장단점이 있습니다.

변경 가능한 인프라에서 서버는 중요한 애플리케이션 데이터를 로컬 디스크에 쓸 수 있으므로 해당 서버와 디스크를 삭제하고 교체하는 것이 위험하거나 잠재적으로 시스템을 손상시킬 수 있습니다. 따라서 변경할 수 없는 인프라에서는 데이터를 외부에 저장해야 하므로 시스템에 복잡성이 추가됩니다.

이 방법은 Cloud Databases, Block Storage 또는 Object Storage와 같은 외부 데이터 스토리지를 사용하여 수행할 수 있습니다. 새 가상 머신이 온라인 상태가 되면 이 외부 스토리지를 통해 기존 데이터와 원활하게 다시 연결할 수 있습니다. 조직은 일반적으로 Git과 같은 버전 제어 시스템에서 구성 및 메타데이터를 유지 관리합니다.

그러나 변경할 수 없는 인프라의 진정한 '불변성'에 대해서는 때때로 논쟁이 있습니다. 이러한 제한은 외부에 저장된 네트워크 사용자 데이터는 일정한 유동 상태에 있으므로 알려진 상태와 비교할 수 없기 때문입니다.