IaC의 의미와 필요성
여러분이 다음과 같은 인프라를 구성해야 한다고 가정해 봅시다. 여러분은 이 그림에서 요구하는 각각의 리소스를 만들고, 연결하는 과정을 AWS 콘솔을 통해 진행할 것입니다. 그런데 AWS 콘솔을 이용해 인프라 구성을 진행하는 것이 항상 좋은 일일까요?
다음을 가정해 봅시다
- 위 그림에서의 인프라를 완전히 다른 리전에 똑같이 복제하고 싶을 경우
- 특히, 해당 리전이 갑자기 사용할 수 없는 상황에 직면했을 경우
- 기존과는 다른 새로운 아키텍처를 빠른 시간 내에서 적용해야 할 경우
수동 설정의 한계
수동설정은 쉽게 서비스를 제공하고, 아키텍처를 빠르게 실험해 볼 수 있다는 점에서 유리하지만, 많은 단점도 가지고 있습니다.
- 휴먼 에러 때문에 서비스를 설정할 때에 잘못 설정하기 쉽습니다
- 설정을 통해 예측되는 상태를 관리하기 어렵습니다
- 환경 설정에 대한 내용을 다른 팀 멤버에 전달하기 어렵습니다
IaC
DevOps의 주요 가치 중 하나는 바로 자동화입니다. 코드형 인프라(Infrastructure as Code), 즉 IaC는 설정을 코드로 작성하여 클라우드 인프라스트럭처의 생성/수정/삭제를 자동화하는 방법입니다.
이는 서버, 데이터베이스, 네트워크, 배포 프로세스, 테스트 등 거의 모든 것을 코드로 관리할 수 있다는 의미입니다. 기존에는 (하드웨어) 서버 준비, 네트워킹과 같은 운영적 측면이 물리적 영역과 대응합니다. 실제로, 선을 연결하고, 하드웨어를 준비하는 것처럼 말이죠. 그러나 현재와 같은 클라우드 네이티브 환경에서는, 운영적 측면이 모두 코드로 대체될 수 있습니다.
이는 달리 얘기하면, IaC는 인프라스트럭처의 설계도가 될 수 있습니다.
IaC의 장점
IaC는 다음과 같은 특징 및 장점을 가집니다.
- 인프라를 만드는 과정이 자동화되므로, 오류가 훨씬 덜 발생하고 안전합니다.
- IaC는 쉽게 공유할 수 있고, 버전 관리에도 용이합니다.
- 코드와 현재 상태를 비교하여, 추후 인프라 상태의 변경에 따르는 위험을 분석하고 검증할 수 있습니다.
- 배포 과정을 소수의 시스템 관리자만 진행하는 것이 아닌, 개발자 스스로가 배포하고 인프라를 통제할 수 있는 환경으로 만들 수 있습니다.
예상치 못한 인프라의 변경에 따른 사고 (Configuration Drift)
AWS와 같은 클라우드 서비스에 여러분이 인프라 관리자로 일하고 있다고 가정해 봅시다. 일반적으로 IAM을 통해 각 팀 또는 개인에게 필요한 만큼의 권한을 주고 인프라를 사용할 수 있게 할 것입니다. 그렇지만 도구를 각자의 손에 쥐어줄 경우 모두가 이를 제대로 사용하라는 법은 없기 마련입니다. 예를 들어, 프로덕션 레벨에 있는 어떤 특정한 인스턴스를 권한을 갖고 있는 누군가가 실수로 삭제해서 제품에 영향을 미칠 경우 이를 어떻게 알아내고, 어떻게 고칠 수 있을까요? 꼭 지우는 것만이 위험 요소가 아닙니다. 어떤 보안 그룹의 설정을 변경하여 시스템 전체에 영향을 미치는 경우는 또 어떨까요?
이처럼, 예상치 못한 인프라 변경에 대한 사고와 미치는 영향을 Configuration Drift라고 부릅니다.
어떻게 알아내고, 어떻게 고칠까?
사건을 알아내는 방법은 접근 방법에 따라 조금씩 다릅니다. AWS를 기준으로 접근 방법과, 도구를 알아봅시다.
- 잘못 설정된 것을 찾기 위한 도구: AWS Config
- 바른 설정을 지정해 놓고, 찾고 고칠 수 있게 만들어준다
- 사고 감지 도구: AWS CloudFormation Drift Detection
이러한 관리형 서비스 외에 보다 개발 방법에 가까운 솔루션은 다음이 있습니다.
- 정상 작동 상태를 파일로 저장: Terraform state files
Terraform의 상태 정의 파일은 인프라의 실제 상태와의 비교 대상으로서 현재 상황을 진단/점검할 수 있습니다.
어떻게 방지할까?
불변한(Immutable) 인프라스트럭처는 인프라 변경을 원천적으로 막을 수 있는 방법론입니다. 실제로 인프라를 수동 설정으로 변경할 수 있지만, 다음의 실천적인 방법을 통해 애초에 그 가능성을 막는 것입니다. 원칙들을 살펴봅시다.
- 한번 생성했으면 수정하지 않는다.
- 프로비저닝 및 배포했으면, 콘솔에 접속해서 수동으로 설정하지 않습니다.
- 즉 변경은 삭제 후 생성을 의미합니다.
- 인스턴스 내부 구성(사용자 스크립트 등)이 필요할 경우 AMI로 만들어 놓습니다.
- 즉 Develop → Deploy → Configure가 아니라
- Develop → Configure → Deploy여야 합니다.
- 코드형 인프라(IaC)를 사용합니다.
IaC 종류와 Terraform의 장점
Terraform을 배우기 이전에, IaC 도구의 종류를 알아보고, 왜 Terraform을 선택했는지를 배웁니다.
절차형
프로그래밍 언어를 이용해서 직접 순차적으로 인프라를 생성하도록 코드를 작성하는 방법입니다. 선언형에 비해 더 강력한 일들을 할 수 있으나, 실제 적용된 결과를 가늠하기 어렵고, 코드를 읽기에 직관적이지 않습니다.
절차형 IaC의 종류
- AWS CDK
- Pulumi
선언형 IaC
선언형 언어 JSON, YAML 등을 사용합니다. 실제 인프라가 적용된 결과(기대하는 상태)와 적용할 내용(YAML 등)이 직관적으로 매핑됩니다.
선언형 IaC 종류
- CloudFormation (AWS에서만 사용가능)
- Azure Blueprint (Azure에서만 사용가능)
- Cloud Deployment Manager (GCP에서만 사용가능)
- Terraform: 어떤 클라우드 서비스에도 적용되는 범용 IaC 도구입니다.
