IaC란 무엇인가?
IaC란 코드형 인프라(Infrastructure as Code), 즉 IaC는 설정을 코드로 작성하여 클라우드 인프라스트럭처의 생성/수정/삭제를 자동화하는 방법입니다.
쉽게 말해 IaC는 인프라스트럭처의 설계도로
서버, 데이터베이스, 네트워크, 배포 프로세스, 테스트 등 거의 모든 것을 코드로 관리할 수 있다.
IaC의 장점?
- 인프라를 만드는 과정이 자동화되므로, 오류가 훨씬 덜 발생하고 안전하다.
- IaC는 쉽게 공유할 수 있고, 버전 관리에도 용이하다.
- 코드와 현재 상태를 비교하여, 추후 인프라 상태의 변경에 따르는 위험을 분석하고 검증할 수 있다.
- 배포 과정을 소수의 시스템 관리자만 진행하는 것이 아닌, 개발자 스스로가 배포하고 인프라를 통제할 수 있는 환경으로 만들 수 있다.
IaC의 종류
■ 절차형
프로그래밍 언어를 이용해서 직접 순차적으로 인프라를 생성하도록 코드를 작성하는 방법이다. 선언형에 비해 더 강력한 일들을 할 수 있으나, 실제 적용된 결과를 가늠하기 어렵고, 코드를 읽기에 직관적이지 않다.
■ 절차형 IaC의 종류
- AWS CDK
- Pulumi
■ 선언형 IaC
선언형 언어 JSON, YAML 등을 사용한다. 실제 인프라가 적용된 결과(기대하는 상태)와 적용할 내용(YAML 등)이 직관적으로 매핑된다.
■ 선언형 IaC 종류
- CloudFormation (AWS에서만 사용가능)
- Azure Blueprint (Azure에서만 사용가능)
- Cloud Deployment Manager (GCP에서만 사용가능)
- Terraform: 어떤 클라우드 서비스에도 적용되는 범용 IaC 도구이다.
인프라 변경에 의한 사고
인프라 변경에 의한 사고를 Configuration Drift라고 한다. 사람에 의해 배포된 인프라가 삭제 혹은 잘못 변경되거나 AWS의 경우 보안 그룹등을 잘 못 변경하는 경우 시스템 전체의 영향을 미칠 수 있다.
■ 문제 해결 방법?
AWS를 기준으로 문제를 해결하기 위한 도구들을 설명한다.
관리형 서비스
1. 잘못 설정된것을 찾기 위한 도구: AWS Config
- 바른 설정을 지정해놓고, 찾고 고칠 수 있게 만들어준다
2. 사고 감지 도구: AWS CloudFormation Drift Detection
개발 방법에 가까운 솔루션
정상 작동 상태를 파일로 저장: Terraform state files
- Terraform의 상태 정의 파일은 인프라의 실제 상태와의 비교 대상으로서 현재 상황을 진단/점검할 수 있다.
Configuration Drift 예방책
Immutable Infrastructure (불변적 인프라 방법론)
-
한번 생성했으면 수정하지 않는다.
- 프로비저닝 및 배포했으면, 콘솔에 접속해서 수동으로 설정하지 않습니다.
- 즉 변경은 삭제 후 생성을 의미합니다.
-
인스턴스 내부 구성(사용자 스크립트 등)이 필요할 경우 AMI로 만들어 놓습니다.
- 즉 Develop → Deploy → Configure가 아니라
- Develop → Configure → Deploy여야 합니다.
-
코드형 인프라(IaC)를 사용합니다.
가변적(mutable) 인프라와 불변적(immutable) 인프라의 차이
■ 가변적(mutable) 인프라
- 서버는 끊임없이 업데이트 되고 수정된다.
- 엔지니어 관리자는 서버에 ssh로 접속하고 수동으로 패키지를 업/다운그레이드 하고 서버 하나하나의 설정 파일을 수정하고 새 코드를 직접 서버에 배포한다.
■ 불변적(immutable) 인프라
- 서버가 배포된 이후 절대 변경되지 않는 형태의 인프라 패러다임이다.
- 업데이트 및 수정 사항의 발생 경우 공용 이미지에 적절한 수정을 한 새 서버가 프로비저닝 되어 기존 서버를 대체 한다.
- 새 서버의 검증이 완료되면 기존 서버는 더 이상 사용하지 않게 된다.
■ 둘은 어떠한 차이가 있는가?
- ‘정책’의 도입 시점
가변적 인프라의 경우 ‘배포 이후’ 변경되도록 설계되어 있다. 불변적 인프라의 경우 ‘변경되지 않고 아예 교체되도록’ 만들어졌다.
- ‘클라우드’를 수용하는가?
가변적 인프라의 도입 시기는 클라우드 컴퓨팅이 상용화 되기 이전 물리서버를 중심으로 서버를 구성할때이다.
불변적 인프라의 서버를 ‘변경’한다는 개념은 가변적 인프라의 도입 시기였던 주된 서버였던 물리서버에서는 ‘교체’를 의미한다.
이는 많은 비용 투자를 수반하기에 서버의 다운타임을 최대한 줄인채 서버를 ‘조금씩 변경하는’것에 초점을 맞추었고 당시에는 이것이 가장 효율적인 방법이었다.
하지만 이런 수동적인 변경은 인프라의 통일성을 해치고 이로 인해 서버 복제에 있어 치명적인 단점을 가지고 있으며 서버 하나하나가 동일하지 않은 각각의 고유한 객체로써 작용하며 매우 취약한 서비스 구조를 가지게 되었다.
하지만 불변적 인프라에 대한 개념이 대두된 시기는 클라우드 컴퓨팅이 상용화되면서 온디멘드/가상화를 통해 저렴하고 적은 시간 비용을 투자해 서버의 생성이 가능해졌다. 이를 통해 기존의 ‘물리적 서버’가 가지는 단점을 개선하는 방향으로 멱등성을 가지는 불변적 인프라의 개념이 등장하게 되었다.
- ‘문제 해결’에서의 차이점
서버에 문제가 발생했을 때 둘의 대처 방법과 그 장단점이 극명하게 드러난다.
가변적 인프라의 경우 서버에 작은 문제가 발생하면 즉흥적인 변경으로 그 문제를 해결하곤 한다. 이를 문서화하려는 노력으로 문제에 대한 로깅을 할 수도 있겠지만 이미 생겨난 수많은 변경점들은 계속해서 새로운 충돌점을 생성해내고 이로인한 컨피그레이션 드리프트의 딜레마에 빠지곤 한다.
불변적 인프라는 이러한 단점을 극복하기 위해 선언적 코드를 통해 서버를 문서화하고 이로 인해 원자성이 보장되기에 급작스러운 트래픽 증감에 따른 유연한 대처에 있어 효율적이다. 또한 서버 에러가 발생시에도 새로운 서버를 간단하게 배포 후 기존 서버를 닫는 형식으로 문제를 쉽게 해결할 수 있다.
