49일차 Infrastructure as Code

IaC의 의미와 필요성

 

코드형 인프라(Infrastructure as Code), 즉 IaC는 설정을 코드로 작성하여 클라우드 인프라스트럭처의 생성/수정/삭제를 자동화하는 방법이며 이는 서버, 데이터베이스, 네트워크, 배포 프로세스, 테스트 등 거의 모든 것을 코드로 관리할 수 있다는 의미이다. 기존에는 (하드웨어) 서버 준비, 네트워킹과 같은 운영적 측면이 물리적 영역과 대응했다. 실제로, 선을 연결하고, 하드웨어를 준비하는 것처럼 말이죠. 그러나 현재와 같은 클라우드 네이티브 환경에서는, 운영적 측면이 모두 코드로 대체될 수 있다.

 

이는 달리 얘기하면, IaC는 인프라스트럭처의 설계도가 될 수 있다.

 

IaC의 등장배경

콘솔을 통해 수동으로 설정을 하면 쉽게 서비스를 제공하고, 아키텍처를 빠르게 실험해볼 수 있다는 장점이 있지만 많은 단점도 있다.

 

• 휴먼 에러 때문에 서비스를 설정할 때에 잘못 설정하기 쉽다
• 설정을 통해 예측되는 상태를 관리하기 어렵다
• 환경 설정에 대한 내용을 다른 팀 멤버에 전달하기 어렵다

 

IaC의 특징과 장점

• 인프라를 만드는 과정이 자동화되므로, 오류가 훨씬 덜 발생하고 안전하다.
• IaC는 쉽게 공유할 수 있고, 버전 관리에도 용이하다.
• 코드와 현재 상태를 비교하여, 추후 인프라 상태의 변경에 따르는 위험을 분석하고 검증할 수 있다.
• 배포 과정을 소수의 시스템 관리자만 진행하는 것이 아닌, 개발자 스스로가 배포하고 인프라를 통제할 수 있는 환경으로 만들 수 있다.

 

 

 

 

프로비저닝 vs. 배포 vs. 오케스트레이션

 

프로비저닝

시스템, 데이터 및 소프트웨어로 서버를 준비하고 네트워크 작동을 준비한다. Puppet, Ansible 등과 같은 구성 관리 도구를 사용하여 서버를 프로비저닝할 수 있다.

 

이처럼, 클라우드 서비스를 시작하고 구성하는 것을 "프로비저닝"이라고 부른다.

 

배포

배포는 프로비저닝된 서버를 실행하기 위해 애플리케이션 버전을 제공하는 작업이다. 배포는 AWS CodePipeline, Jenkins, Github Actions를 통해 수행할 수 있다.

 

오케스트레이션

오케스트레이션은 여러 시스템 또는 서비스를 조정하는 작업이다. 오케스트레이션은 마이크로서비스, 컨테이너 및 Kubernetes로 작업할 때 일반적인 용어이며 오케스트레이션도구로는 Kubernetes, Salt, Fabric가 있다.

 

 

예상치 못한 인프라 변경에 따른 사고

 

AWS와 같은 클라우드 서비스에 여러분이 인프라 관리자로 일하고 있다고 가정할 때 일반적으로 IAM을 통해 각 팀 또는 개인에게 필요한 만큼의 권한을 주고 인프라를 사용할 수 있게 할 것이다. 그러나 도구를 각자의 손에 쥐어줄 경우 모두가 이를 제대로 사용하라는 법은 없다.

예를 들어, 프로덕션 레벨에 있는 어떤 특정한 인스턴스를 권한을 갖고 있는 누군가가 실수로 삭제해서 제품에 영향을 미칠 수도 있다. 이를 어떻게 알아내고, 어떻게 고칠 수 있을까? 위험 요소는 지우는 것을 포함한 어떤 보안 그룹의 설정을 변경하여 시스템 전체에 영향을 미치는 경우는 될 수 있다.

 

이처럼, 예상치 못한 인프라 변경에 대한 사고와 미치는 영향을 Configuration Drift 라고 부른다.

 

 

 

어떻게 알아내고, 어떻게 고칠까?

사건을 알아내는 방법은 접근 방법에 따라 조금씩 다릅니다. AWS를 기준으로 접근 방법과, 도구를 알아보자.

• 잘못 설정된것을 찾기 위한 도구: AWS Config
  • 바른 설정을 지정해놓고, 찾고 고칠 수 있게 만들어준다.
• 사고 감지 도구: AWS CloudFormation Drift Detection

이러한 관리형 서비스 외에 보다 개발 방법에 가까운 솔루션은 다음과 같이 있다.

• 정상 작동 상태를 파일로 저장: Terraform state files

Terraform의 상태 정의 파일은 인프라의 실제 상태와의 비교 대상으로서 현재 상황을 진단/점검할 수 있다.

 

 

 

어떻게 방지할까?

 

불변한(Immutable) 인프라스트럭처는 인프라 변경을 원천적으로 막을 수 있는 방법론이며 실제로 인프라를 수동 설정으로 변경할 수 있지만, 다음의 실천적인 방법을 통해 애초에 그 가능성을 막는 것이다.

 

원칙

1. 한번 생성했으면 수정하지 않는다.
   • 프로비저닝 및 배포했으면, 콘솔에 접속해서 수동으로 설정하지 않는다.
   • 즉 변경은 삭제 후 생성을 의미한다.
2. 인스턴스 내부 구성(사용자 스크립트 등)이 필요할 경우 AMI로 만들어 놓는다.
   • 즉 Develop → Deploy → Configure가 아니라 Develop → Configure → Deploy여야한다.
3. 코드형 인프라(IaC)를 사용한다.

 

 

절차형 IaC와 선언형 IaC

 

절차형

프로그래밍 언어를 이용해서 직접 순차적으로 인프라를 생성하도록 코드를 작성하는 방법이다. 선언형에 비해 더 강력한 일들을 할 수 있으나, 실제 적용된 결과를 가늠하기 어렵고, 코드를 읽기에 직관적이지 않다.

 

절차형 IaC의 종류

• AWS CDK
• Pulumi

절차형 IaC

- ec2:
	count: 10
	image: ami-000000000
	instance_type: t2.micro

 

 

선언형 IaC

 

선언형 언어 JSON, YAML 등을 사용하며 실제 인프라가 적용된 결과(기대하는 상태)와 적용할 내용(YAML 등)이 직관적으로 매핑된다.

 

선언형 IaC 종류

• CloudFormation (AWS에서만 사용가능)
• Azure Blueprint (Azure에서만 사용가능)
• Cloud Deployment Manager (GCP에서만 사용가능)
• Terraform: 어떤 클라우드 서비스에도 적용되는 범용 IaC 도구이다.

 

선언형 IaC

resource "aws_instance" "example" {
	count = 10
	ami = "ami-000000000"
	instance_type = "t2.micro"
}