[Infrastructure as Code] IaC 조사 및 발표 준비

# 조사 및 발표

발표 주제 1

가변적(mutable) 인프라와 불변적(immutable) 인프라의 차이는 무엇인가요?

가변적 인프라 

가변적 인프라의 예시 : 서버를 수동으로 수정

- 웹 서버를 생성한다고 가정하면 Apache 2.4와 같은 것을 웹 서버로 배포한 다음 백엔드도 배포할 것 이것을 웹 서버 버전 1이라 가정

- 만일 apache를 NGINX와 같은 다른 웹 서버로 전환하고 싶을 경우, 웹서버 버전 1을 만들었던 것처럼 원하는 버전 2의 모습을 정의해야 함

- 웹서버 뿐 아니라 서버나 VM 또는 기타 등등을 변경하기 위해 가변적 인프라에서는 기존 서버를 새로운 버전 구성으로 업그레이드해야 해야 함

- 일반적으로 구성 관리 도구(Chef, Puppet, Ansible)를 이용해 수행하며, 구성 관리를 실행한 후 버전 1에서 버전 2로 이동하도록 정의를 업데이트한 후 재실행 함

 

가변적 인프라의 장단점

장점

- 이미 기존 서버가 존재한다는 점

- 로컬에서 작성했고 웹 서버에서 사용 중인 데이터가 있을 수 있다는 점

- 적절한 위치에서 업데이트하면 데이터를 다른 시스템으로 이동하거나 새 시스템을 생성하는 것에 대해 걱정할 필요가 없으며 모든 인프라가 이미 존재한다는 점

단점

- 다만 업그레이드를 수행해야 하는데 만일 제대로 업그레이드 할 수 없는 경우가 생길 수 있음

 > 예를 들어 NGINX 설치 자체가 잘못 되어 설치가 안되었다면?

 > NGINX가 설치되지 않은 상태로 배포는 가능하므로 버전 2는 배포되었으나 예를 들어 nginx가 설치되지 않았지만 apache가 남아있어 동작한다면?  데이터베이스 측면에서 생각하면 부분적으로 커밋된 트랜잭션이고, 변경 사항 중 일부는 발생했고 일부 변경 사항은 발생하지 않았기 때문에 불완전한 결과물이 됨 (버전 1이나 버전 2가 아닌 버전 1.57쯤)

- 즉, 연속적인 버전 관리가 됨

- 가변적인 인프라의 업그레이드 프로세스에는 위험이 따르는 단점이 존재

- 불명확한 변경 사항이 발생하면 이 문제의 원인을 알아내야하는 복잡성이 존재함

- 만일 서버가 여러대일 경우, 또 문제 원인이 각기 다를 경우도 발생할 수 있으므로 매우 복잡하고 비실용적임

- 즉 시스템을 제대로 파악하지 못한 상태에서는 디버깅하기가 매우 어려워짐

 

불변적 인프라

불변적 인프라의 예시 : 서버를 수정하지 않고 새롭게 생성

- 불변적 인프라는 업그레이드를 할 때 동일한 서버를 수정하지 않는다는 점 (즉 서버가 존재하면 V2로 업그레이드하지 않음)

- 서버를 만들 경우 다시 V1이라고 부르며 Apache를 설치하고 웹 서버를 설치한 다음 이 이미지의 스냅샷을 찍어 버전1로 칭함

- 만일 apache를 nginx로 변경하고 싶다면 새로운 서버를 생성하며, 기존 서버 V1와 별개의 시스템인 V2가 됨 (기존 인프라를 업그레이드X)

- 오류가 있으면 중단 후 폐기하고 재시도

- 만일 오류 없이 성공적으로 모두 설치, 생성되었다면 단순히 기존 서버의 트래픽을 V2로 전환하고, V1을 폐기해 프로덕션에서 제거하거나 파괴하거나 다른 목적을 위해 재활용하는 등의 작업을 수행

- 즉 불연속 버전 관리의 개념으로 V1과 V2만 존재하지 V1.5는 존재하지 않음

 

불변적 인프라의 장단점

장점

- 검증되지 않은 정의되지 않은 상태가 없으므로 가변적 인프라에 비해 위험과 복잡성이 낮음

- 또한 인프라의 복잡성도 감소

단점

- 만약 기존 서버의 로컬 디스크에 중요한 데이터가 있는 경우, 기존 서버를 폐기해야하므로 데이터 소실 가능성이 존재하며, 이를 방지하기 위해 데이터를 외부화해야 함

- 이 경우 공유하는 외부 데이터베이스를 사용 (ex. V1이 사용했던 DB를 V2가 사용)

- 외부 데이터베이스(클라우드 환경의 Elastic Block Store 또는 외부화된 소프트웨어 정의 스토리지 등)을 사용할 경우 기본 디스크를 변경할 수 있지만 DBMS는 변경하기 어려울 수 있음

- 이 경우 실행 중인 DBMS를 종료해 새로운 DBMS를 동일한 디스크에 연결(ex. MySQL 버전 7을 종료하고 MySQL 버전 8을 실행하는 새 VM을 가져와 동일한 디스크에 다시 연결)

- 불변성을 작동시키는 방법에는 여러 가지 접근 방식이 존재

---

발표 주제 2

Terraform의 선언적 방식으로 작성된 코드는 항상 인프라의 최신 상태를 의미합니다. Terraform은 어떤 방식으로 인프라를 최신 상태로 유지할 수 있는 걸까요?

Terraform의 작동 방식

- Terraform은 API를 통해 클라우드 플랫폼 및 기타 서비스에서 리소스를 만들고 관리

- 공급자(ex. AWS, Azure 등)는 액세스 가능한 API를 제공해 Terraform이 동작할 수 있음 

 

핵심 Terraform 워크플로

1. 쓰기
   • 여러 클라우드 공급자 및 서비스에 걸쳐 있을 수 있는 리소스를 정의
   • (ex) 보안 그룹 및 로드 밸런서가 있는 Virtual Private Cloud(VPC) 네트워크의 가상 머신에 애플리케이션을 배포하는 구성을 생성 가능
2. 계획
   • Terraform은 기존 인프라 및 구성을 기반으로 생성, 업데이트 또는 삭제할 인프라를 설명하는 실행 계획을 생성
3. 적용
   • 실행 계획이 승인되면 Terraform은 모든 리소스 종속성을 고려하여 올바른 순서로 제안된 작업을 수행
   • (ex) VPC의 속성을 업데이트하고 해당 VPC의 가상 머신 수를 변경하면 Terraform은 가상 머신을 확장하기 전에 VPC를 다시 생성

 

Terraform의 구성 파일 동작 방식

- Terraform 언어는 절차적으로 (순서대로) 기술하는 언어가 아닌 의도한 목표를 설명하는 선언적 언어이므로 블록의 순서와 블록이 구성되는 파일은 일반적으로 중요하지 않음

-  Terraform은 작업 순서를 결정할 때 리소스 간의 암시적 및 명시적 관계만 고려

- Terraform 공급자는 리소스 간의 종속성을 자동으로 계산하여 올바른 순서로 리소스를 생성하거나 삭제

- 공급자는 컴퓨팅 인스턴스(ex. EC2 등) 또는 사설 네트워크(ex. VPC 등)와 같은 개별 인프라 단위를 리소스로 정의하는데, 다양한 공급자의 리소스를 "모듈"이라는 재사용 가능한 Terraform 구성으로 구성하고 일관된 언어 및 워크플로로 관리

 

Terraform 인프라 배포 워크 플로 예시

1. Scope : 프로젝트에 필요한 인프라, 리소스 범위를 식별
2. Author : 인프라에 필요한 구성 내용을 Terraform을 이용해 작성
3. Initialize : 인프라를 관리하기 위해 Terraform이 필요한 플로그인들을 설치 
4. Plan : Terraform이 사용자가 원하는 인프라 구성을 위해 만든 계획을 사전 검토
5. Apply : 수정 계획을 실행

 

# References

https://www.hashicorp.com/resources/what-is-mutable-vs-immutable-infrastructure

Immutable Infrastructure: Benefits, Comparisons & More

https://developer.hashicorp.com/terraform/language

Overview - Configuration Language | Terraform | HashiCorp Developer

https://developer.hashicorp.com/terraform/intro

What is Terraform | Terraform | HashiCorp Developer

https://dev.to/faizanraza_interweave/terraform-understanding-the-value-declarative-language-terf-5m8

Terraform - Understanding the Value - Declarative Language (TERF)