🌱 IaC
인프라가 코드로 표현된다
⇒ UI나 커맨드를 통한 수동 조작이 아닌 코드로 인프라를 관리하는 것
ex) Terraform에서는 하시코프 설정언어(HCL)를 사용
🌱 인프라 자동화의 변화
인프라 운영이 물리적인 데이터 센터(온 프레미스)에서부터 클라우드 환경에 이르기까지 형태가 변화하면서 운영하는 방식도 지속적으로 바뀌고 있다.
- 문서로 관리
- ex) 어떤 서비스가 어느 서버에서 실행되는 지 등을 엑셀에 기록
- 결국 사람이 실제 작업을 위한 명령어와 파일을 별도로 준비해야 함
- 재사용성이 낮음
- 스크립트
- 반복되는 작업을 스크립트로 작성해 자동화
- 스크립트는 현재의 상태와 관계없이 순서대로 각 단계를 실행하기 때문에 실행 중인 최종 상태가 스크립트의 결과와 일치하지 않을 수 있다.
- 가상 머신
- 미리 구성된 가상 머신 이미지는 템플릿화하여 저장하고 반복적으로 사용할 수 있음
- 하지만 이미지 변경을 위한 수동 작업은 여전히 존재
- 클라우드 인프라
- 상품화된 인프라와 데이터 센터 이용
- 확장성 뛰어남
- 컨테이너
- 운영체제를 가상화한 환경 제공
- 컨테이너 오케스트레이션 환경을 사용한다면 특정 컴퓨팅 서버가 아닌 적절한 리소스가 있는 어딘가의 서버에 배포된다.
🌱 IaC 개념의 등장 배경
이렇게 가상화 기술이 발전하면서, 여러 대의 서버를 더 많이 쉽게 만들 수 있게 됨
⇒ 늘어나는 서버들에 대한 프로비저닝과 운영에 대한 이슈 발생(인력을 무한정으로 늘릴 수 없음)
⇒ 서버 구축과 운영에 대한 자동화가 필요
⇒ 프로그래밍 코드로 인프라를 구축하고 운영할 수 있는 IaC 개념의 등장
🌱 IaC의 장점
- 자동화 수동으로 서버를 생성하는 게 아니라, 코드로 생성하기 때문에 서버 운명 및 관리를 모두 자동화할 수 있다. ex) AWS에서 새로운 서버를 생성 하기 위해서 AWS 콘솔에 로그인할 필요없이 Terraform 코드를 실행시키기기만 하면 됩니다.
- 휴먼 에러 방지
- 문서화
- 재사용성
- 여러 사람들 간 공유 가능
- 속도가 빠름 ⇒ 직접 cli에서 치는 것보다 문서화된 코드를 실행하는 게 훨씬 빠름
- 형상관리
- 리뷰 및 테스트 수동으로 서버 작업을 할 때는, 실제로 실행하기 전에 리뷰 하는 것이 굉장히 힘들수 밖에 없었습니다. 그래서 문제가 발견 되었을 때는 이미 프로덕션 애플리케이션에 영향을 주고 난 후인 경우가 많았는데, Terraform의 경우 코드 리뷰와 테스트를 통해 문제가 실제로 발생 되는 것을 어느 정도 예방할 수 있습니다.
🌱 IaC의 단점
- 코드 문법 학습
- 파이프라인 통합 ⇒ 기존 워크플로에 자동화를 위한 수고가 추가로 필요하다.
- IaC 자체 지식과 더불어 관리 대상이 되는 인프라 지식이 함께 필요하다.
🌱 테라폼의 특성
테라폼의 3가지 철학
- workflow
- IaC
- 실용주의
💡 workflow란?
어떤 기능 하나가 모든 문제를 해결해주지는 못한다
⇒ 테라폼은 개발자나 시스템 관리자가 일하는 방식과 유사한 “workflow”를 만들기 위한 도구로 설계되었다.
⇒ workflow의 대상은 인프라 구성과 배포, 보안 구성, 계정 추가 작업 등이 될 수 있다.
⇒ 어떤 기술이 사용되더라도 workflow를 통해 환경의 변화에 크게 구애받지 않도록 설계되었다.
ex) 몇 년 전에 도입한 특정 인프라 환경이 회사 전략에 따라 새로운 환경으로 변경되어도 workflow 자체는 그대로 유지될 수 있다.
🌱 프로바이더
테라폼 자체만으로는 다양한 인프라와 서비스를 프로비저닝 할 수 없다.
⇒ 인프라와 서비스 사이에서 프로바이더가 인터페이싱을 해줘야한다.
- 각 인프라와 서비스는 고유의 API를 가지고 있음
- 프로바이더는 각 API 명세를 테라폼 코드로 호출해 동작
- 마치 자바 코드에서 MySql을 연동할 때 해당 DB의 드라이버를 사용하는 것과 비슷한 원리
테라폼은 인프라를 코드로 관리하는 도구(IaC: Infrastructure as Code)이다. 하지만 테라폼 자체는 아마존 웹 서비스(AWS), 구글 클라우드(GCP), 마이크로소프트 애저(Azure) 등 다양한 클라우드 플랫폼이나 SaaS(Software as a Service) 시스템의 동작 방식이나 API를 알지 못한다.
그래서 테라폼이 직접 인프라 리소스에 접근하고 생성하는 것이 아니라, “프로바이더(Provider)”를 통해 각 서비스와 통신하고 조작한다.
자바에서 MySQL을 연결할 때도, 자바 코드가 MySQL 프로토콜을 직접 이해하진 않는다. 대신 MySQL JDBC 드라이버가 자바의 명령을 MySQL에 맞게 번역해준다.
ex) API와 테라폼 코드 사이의 중개자 역할
각 클라우드나 SaaS 서비스는 고유한 API를 제공한다. 예를 들어 AWS는 ec2:RunInstances 같은 API를 통해 EC2 인스턴스를 생성하고 이때 테라폼은 그 API를 직접 호출하지 않고, 대신 AWS 프로바이더에 다음과 같은 방식으로 명령을 내린다.
resource "aws_instance" "example" {
ami = "ami-123456"
instance_type = "t2.micro"
}
이걸 받은 AWS 프로바이더는 내부적으로 해당 값을 AWS API로 변환해서 호출하고, 결과를 받아서 테라폼에게 알려준다.
🌱 테라폼 진행순서
| 단계 | 설명 |
|---|---|
write | 인프라 리소스를 정의하는 테라폼 코드(HCL) 작성 |
plan | 코드대로 실행하면 무슨 일이 일어나는지 미리 확인 |
apply | 실제로 인프라를 생성하거나 변경 |
