[Infrastructure as Code] 01. Infrastructure as Code (코드형 인프라)

# 학습 목표

• Infrastructure as Code(이하 IaC)의 의미와 필요성을 이해할 수 있다.
  • 수동으로 인프라를 설정하는 것의 장/단점을 파악할 수 있다.
  • IaC의 장점을 파악할 수 있다.

• IaC의 종류를 파악할 수 있다.
  • 선언형 IaC와 절차형 IaC의 차이를 이해할 수 있다.
• 테라폼의 특징 및 장점을 통해 테라폼의 주 사용 목적을 이해할 수 있다.
• 예상치 못한 인프라 변경을 어떻게 대비하는지 이해할 수 있다.
  • 불변(Immutable)한 인프라를 구성한다는 것의 의미를 이해할 수 있다.
• 테라폼의 작동 원리를 이해할 수 있다.
  • 테라폼 공식 문서를 통해, HCL 언어로 인프라를 구성할 수 있다.
  • 주요 명령어를 이해할 수 있다.
  • 테라폼 상태 파일의 의미를 이해할 수 있다.
  • 테라폼 상태 파일을 이용한 운영의 모범 사례를 이해할 수 있다.
• AWS VPC 구성을 더욱 잘 이해할 수 있다.
  • VPC 및 public/private 서브넷에 대한 개념을 보다 더 확실하게 이해할 수 있다.

 

---

# 학습 내용

1.  IaC의 의미와 필요성

AWS 서비스를 이용해 다음과 같은 인프라를 만든다고 가정하면?

- AWS 콘솔을 이용해 각각의 리소스를 만들고, 연결하는 과정 필요 

 

만약에..

- 인프라를 완전히 다른 리전에 똑같이 복제하고 싶을 경우

- 특히, 해당 리전이 갑자기 사용할 수 없는 상황에 직면했을 경우

- 기존과는 다른 새로운 아키텍처를 빠른 시간 내에서 적용해야 할 경우

 

수동 설정

장점

- 수동 설정은 쉽게 서비를 제공하고 아키텍처를 빠르게 실험해볼 수 있다는 점에서 유리

단점

- 휴먼 에러 때문에 서비스 설정 시 잘못 설정하기 쉬움

- 설정을 통해 예측되는 상태 관리가 어려움

- 환경 설정에 대한 내용을 다른 팀 멤버에게 전달하기 어려움

 

IaC

- DevOps의 주요 가치 중 하나는 바로 "자동화"

 - 코드형 인프라(Infrastructure as Code, IaC)는 설정을 코드로 작성해 클라우드 인프라스트럭처의 생성/수정/삭제를 자동화하는 방법

- 서버, DB, 네트워크, 배포 프로세스, 테스트 등 모든 것을 코드로 관리 가능

- 기존에는 하드웨어 서버 준비, 네트워킹과 같은 운영적 측면이 물리적 영역과 대응했음 (ex. 선 연결, 하드웨어 준비)

- 현재와 같은 클라우드 네이티브 환경에서는 운영적 측면이 모두 코드로 대체될 수 있음

∴ IaC는 인프라스트럭처의 설계도가 될 수 있음

 

IaC의 장점

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

 

2. 프로비저닝과 배포

프로비저닝

- 클라우드 서비스를 시작하고 구성하는 것

- 시스템, 데이터 및 소프트웨어로 서버를 준비하고 네트워크 작동을 준비

- 도구 : Puppet, Ansible 등과 같은 구성 관리 도구를 사용해 서버 프로비저닝 가능

배포

- 프로비저닝된 서버를 실행하기 위해 애플리케이션 버전을 제공하는 작업

- 도구 : AWS CodePipeline, Jenkins, Github Actions를 통해 수행 가능

오케스트레이션

- 여러 시스템 또는 서비스를 조정하는 작업

- 마이크로서비스, 컨테이너 및 Kubernetes로 작업할 때 일반적으로 사용한흔 용어

- 도구 : Kubernetes, Salt, Fabric

 

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

예상치 못한 인프라의 변경에 따른 사고 (Configuration Drift)

- AWS와 같은 클라우드 서비스에 인프라 관리자로 업무를 수행한다면 IAM을 이용해 각 팀 or 개인에게 필요한 만큼 권한 부여해 인프라 사용 가능하도록 할 것

- 즉 해당 인프라를 팀이나 개인에서 제대로 사용하지 않을 가능성 또한 존재

 

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

1. 예를 들어 프로덕션 레벨에 있는 어떤 특정한 인스턴스를, 권한 있는 누군가가 실수로 삭제한다면?
2. 제품에 영향을 미치는 걸 어떻게 알아내고 고칠 수 있을까?
3. 보안 그룹 설정을 변경해 시스템 전체에 영향을 미치는 경우?

 

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

(AWS 기준의) 접근 방법과 도구

1. 관리형 서비스

(1) 잘못 설정된 것을 찾기 위한 도구

- AWS Config : 바른 설정을 지정해두고 찾고 고칠 수 있도록 함

(2) 사고 감지 도구

- AWS CloudFormation

- Drift Detection

2. 개발 방법에 가까운 솔루션

(1) 정상 작동 상태를 파일로 저장하는 솔루션

- Terraform state files

- Terraform의 상태 정의 파일은 인프라의 실제 상태와의 비교 대상으로 현재 상황을 진단, 점검 가능

- terraform plan 명령어 : 

 

어떻게 방지할까?

불변한(Immutable) 인프라스트럭처

- 인프라 변경을 원천적으로 막을 수 있는 방법론

- 인프라를 수동 설정으로 변경할 수 있으나 다음 실천적인 방법을 통해 애초에 가능성을 차단하는 것

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