불변 인프라 - Immutable Infrastructure

본 포스팅은 아리까리한 불변 인프라에 대해 O’Reilly [Infrastructure as Code]를 참고하여 개인적인 생각을 정리한 글입니다.
책에서는 불변 인프라와 불변 서버가 혼용되어 사용되는데, 개인적인 생각으로는 클라우드 서비스가 대중화 되면서 기존 서버에 대한 개념이 인프라에까지 확대된 것 같습니다.

불변 인프라란?

서버 변경 관리 모형(Server Change Management Models) 중 하나로, 불변 인프라란 서버를 완전히 교체해야만 구성을 변경할 수 있는 인프라를 말한다.

  • 두 가지 전제 조건이 필요함
    • 인프라를 템플릿으로 관리 가능해야 함
    • 구 인프라와 새 인프라의 끊김없는(무중단) 전환이 가능해야 함
  • 업데이트 대신 교체하기
    • 새 서버 템플릿을 만들고 이를 이용해 관련된 서버들을 전부 재생성해야 변경이 이루어 짐
    • 서버 템플릿을 소프트웨어 산출물로 취급, 버전관리 및 테스트를 통해 서버 구성 일관성을 높임
      • “서버 설정을 직접 수정하는 것은 마치 소스 코드를 상용 환경에서 바로 수정하는 것과 다를 바 없다.”
  • 장점
    • 시험용과 상용 서버 간에 차이가 거의 없으므로 예측 가능성이 커짐
    • 인프라 요소와 구성방법을 지정하는 구성 파일(JSON, YAML 등)을 서버에서 관리할 필요가 없어 구성 관리(Configuration Management)가 간편
  • 주의사항: 서버 템플릿을 세밀하게 관리할 것

서버 변경 관리 모형

서버 변경을 관리하는 방식

  • 일시적 변경 관리: 변경이 필요한 서버를 직접 수정, 전통적인 방식이지만 아직까지 많이 쓰임
    • 구성 편차, 눈송이(Snowflake) 서버에 취약
  • 구성 동기화: Puppet, Chef 등의 agent로 여러 서버들을 일시에 수정(동기화)
    • 시스템의 구성이 일치되는 것을 보장, IaC의 주류 방식
  • 불변 인프라: 상술
  • 컨테이너화된 서비스: 애플리케이션, 서비스를 Docker등과 같은 컨테이너로 패키징
    • 서버 구성과 서비스간의 결합도를 낮춤, 간단하고 관리가 쉬움
    • 단, 호스트 서버에는 기존 서버 변경 관리 모형을 적용해야 함

불변 서버를 위한 패턴과 관례

  • 산출물로서의 서버 이미지 관리: 서버 템플릿에 엄격한 테스트를 수행하여 템플릿 품질을 보장
  • 구성 관리 도구 간소화: 서버의 시작 상태를 예측할 수 있어, Ansible, Chef, Puppet등으로 서버 업데이트가 불필요
  • 흐름: 템플릿 정의 파일 변경 → 새 서버 이미지 패키징 → 새 서버 구성 → (중단없이)서버 교체
  • 부트스트랩 구성: 표준 서버 템플릿에 서버 시작시 특정 요소들을 추가로 실행
    • 매번 서버 템플릿을 제작하는것은 시간 및 비용이 많이 소요
    • 잦은 업데이트가 있는 마이크로 서비스에 적합
    • 서버마다 조금씩 다르게 동작할 수 있어, 일관성 원칙 위배 위험이 존재
  • 트랜잭션 서버 업데이트: 서버 업데이트 작업을 원자성 트랜잭션 방식으로 처리, 실패시 기존 상태로 롤백
  • 불변 서버라도 애플리케이션 및 시스템 데이터는 유지되어야 함 : HA와 관련

개인적인 생각

  • 심리적 부담
    • 클라우드 인프라를 사용하면서 자원을 생성하고 삭제하는 것이 간편해졌으나,
    • 간단하거나 잦은 업데이트 때문에 이미 구축된 서버 및 인프라들을 모두 제거하고 새로 구축하는 것은 부담스러움
    • 시간 단위별 가격이 있는 리소스의 경우 비용이 증가될 수 있고, Public IP 같은 요소가 갱신되는 것도 어느정도 부담
  • 불변 인프라의 범위
    • 전체 인프라를 모두 재생성할 필요는 없다고 생각
    • AWS를 예로들면, VPC/Subnet/SecurityGroup은 두고 EC2만 재생성하거나 할 수 있음
      • 인프라 구성 자체가 변경될 경우는 불가피 하겠지만.. → Update CloudFormation은?
    • Docker같은 컨테이너를 사용하여 보다 추상화된 범위를 재생성하는 것도 대안
  • 추상화(가상화)
    • 클라우드 서비스도 이미 물리적 인프라 위에 추상화 되어있지만,
    • Docker나 Kubernetes를 이용하여 DevOps 담당자의 입장에서 한 번더 추상화 하는게 좋을듯
  • 그러나…
    • 도구는 도구일 뿐, 불변 인프라 철학의 무분별한 수용이나 새로운 도구의 무리한 적용은 금물!
    • 자신이 담당한 서비스의 특성, 개발자/조직의 한계 등을 고려하여 어쨋든 최선의 결과를 도출하는게 중요