인프라 자동화의 성숙도 변화
인프라 운영이 물리적인 자체 데이터 센터 같은 온프레미스 환경부터 클라우드 환경에 이르기까지 형태가 변화하면서, 운영하는 방식도 지속적으로 변화
단계 | 인프라 운영 | 장점 | 단점 |
---|---|---|---|
1 | 매뉴얼 | 물리적인 특성으로 즉시 확인 및 전달 가능 | 변경 사항 반영이 어렵고 실행을 위한 별도 요소 필요 |
2 | 스크립트 | 반복 작업을 줄이고 사용이 간단함 | 순차적으로만 실행되고 시간이 지나면서 최종 상태가 일치하지 않음 |
3 | 가상머신 | 미리 구성된 템플릿을 사용하여 관리와 확장이 용이함 | 가상화 범위 외적인 요소는 자동화가 불가능하고 하이퍼바이저에 의존적 |
4 | 클라우드 | API를 통해 더 많은 인프라를 가상화하고 자동화 도구 제공 | 클라우드 제공자마다 서로 상이한 API가 제공되어 각각을 위한 개별적 작업 필요 |
5 | 컨테이너 | 상호 호환되는 컨테이너 런타임을 통해 서비스 배포 자동화 및 높은 이동성 | 앱 배포 자동화를 위한 추가 플랫폼 레이어의 관리 추가 |
프로세스로서의 자동화
자동화를 위한 노력은 단일 프로세스부터 엔지니어링 기반으로 확장되었음
자동화는 각 프로세스 작업을 통합하고 재활용성을 높이는 것이 중요 → 워크플로우로 정의되는 프로세스 간 연계를 설계하면 모든 동작을 파악하기 쉽고, 언제든 더 나은 것으로 변경 수월
이전의 자동화 방향성 : ‘기술주도형 접근’ → 느리고 매뉴얼화된 절차적 단계 → 단계별 파편화된 자동화는 특정 환경에서만 동작하는 개별 맞춤형 → 내부에서 구축된 리소스를 자동화하는 데 적합
하지만, 클라우드 같은 동적인 인프라 환경과 서로 다른 플랫폼의 기술을 융합하는 자동화에선 어려움이 따름 → 프로세스적인 접근법 필요 → MSA와 같은 주기적인 변경과 적용 방식을 릴리즈하기 위한 반복적인 작업 효율화를 위해 코드적 표현 방식에 기반한 자동화의 설계
IaC의 이해
- Infrastructure as Code (IaC, 코드형 인프라) 이름 그대로 ‘코드로서의 인프라‘
- 동작하는 방식에 비유하면 인프라가 코드로 표현되고, 코드가 인프라를 설명한다는 의미로
사용자 인터페이스(UI)나 커맨드를 이용한 수동 조작이 아닌, 코드로 대상을 관리 - 컴퓨터에서 읽을 수 있는 정의 파일을 사용해 인프라나 서비스를 관리하고 프로비저닝하는 프로세스
- 코드로 인프라를 관리한다는 것 → 자유롭게 변경하고, 환경을 이해하고, 반복적으로 동일한 상태를 만들 수 있다
긍정적인 측면
- 속도와 효율성 : 사람이 수동으로 작업할 때보다 빠르고, 불필요한 인프라 구성을 방지하여 생산성을 높인다. 또한 코드를 변경하여 적용하면 인프라도 변경되어 기존 방식보다 변경 속도가 빠르다.
- 버전 관리 : 코드 형태로 관리하기 때문에 버전 관리 툴과 연계할 수 있다. 변경 내용을 추적하고 이전 코드로 되돌리거나 비교할 수 있다.
- 협업 : 파일 형태로 되어 있어 쉽게 공유할 수 있고, 버전 관리 툴과 연계하면 공동 작업을 위한 환경을 만들 수 있다.
- 재사용성 : 코드의 주요 반복 또는 표준화된 구성을 패키징하면 매번 새로 코드를 구성하지 않고 기존 모듈을 활용해 배포할 수 있다.
- 기술의 자산화 : 관리 노하우와 작업 방식이 코드에 녹아 있고, 파이프라인에 통합해 워크플로우 형태로 자산화되어 기술 부채를 제거한다.
우려되는 측면
- 코드 문법 학습 : 새로운 도구를 위한 학습이 필요하다.
- 파이프라인 통합 : 기존 워크플로우에 자동화를 위한 수고가 추가로 필요하다.
- 대상 인프라에 대한 이해 필요 : IaC 자체 지식과 더불어 관리 대상이 되는 인프라의 지식이 함께 필요하다.
테라폼의 특성
HashiCorp에서 공개한 IaC 도구
테라폼의 세 가지 철학 : 워크플로우에 집중, 코드형 인프라(IaC), 실용주의
테라폼은 terraform apply와 같은 명령으로 구현된 동작으로 만들어진 코드를 실행하고 배포하는 방식
대상 인프라와 서비스를 테라폼으로 작업하기 위해서는 대상의 제공자(프로바이더, Provider)가 둘 사이에서 인터페이싱해야함 → 각 인프라와 서비스는 고유의 API를 가지고 있고 프로바이더는 각 API 명세를 테라폼 코드로 호출해 동작
- Ex) 자바 - MySQL 연동 시, 드라이버 필요
테라폼 제공 유형
- On-premise : 일반적으로 ‘Terraform’이라 불리는 형태, 사용자의 컴퓨팅 환경에 오픈소스 바이너리 툴인 테라폼이 구성되며 가장 널리 이용
- Hosted SaaS : ‘Terraform Cloud’로 불리는 SaaS로 제공되는 구성 환경으로 HashiCorp가 관리하는 서버 환경이 제공
- Private Install : ‘Terraform Enterprise’로 불리는 서버 설치형 구성 환경, 기업의 사내 정책에 따라 프로비저닝과 관리가 외부 네트워크와 격리되어 이루어지는 환경
테라폼 제공 유형별 기능 리스트
Terraform Core(기본 기능) | Terraform Cloud/ Enterprise [협업] | Terraform Cloud/ Enterprise [거버넌스와 정책] | Terraform Cloud/ Enterprise [셀프 서비스 인프라 기능] |
---|---|---|---|
Infrastructure as Code(HCL) | Remote State | 코드 기반 정책 (PaC) | 구성 디자이너 |
워크스페이스 | VCS 연동 | 비용 추정 | No-Code |
입력 변수 | 워크스페이스 관리 | Run task | 인프라 편차 추적 |
Runs(Plan & Apply) | 민감 변수 저장소 | Audit | Service Now 연동 |
State | API | ||
리소스 종속성 관리 | 팀관리 | ||
프로바이더 사용 | 라이빗 모듈 저장소 | ||
공개된 모듈 레지스트리 사용 | SAML, SSO |
테라폼과 다른 도구의 비교
Terraform | Ansible | CloudFormation | ARM Template | |
---|---|---|---|---|
유형 | 프로비저닝 | 구성 관리 | 프로비저닝 | 프로비저닝 |
오픈소스 여부 | 공개 | 공개 | 비공개 | 비공개 |
적용 대상 클라우드 | 멀티 | 멀티 | AWS 전용 | Azure 전용 |
정책 설정 | 가능 | 불가능 | 부분적 | 부분적 |
구성 방식 | 이뮤터블 | 뮤터블 | 이뮤터블 | 이뮤터블 |
라이프사이클 관리 | 가능 | 불가능 | 부분적 | 부분적 |
온프레미스 지원 | 부분적 | 부분적 | 불가능 | 불가능 |
테라폼 사용 목적과 과제
- 워크플로
- 자산화
- 표준화
- 프로비저닝 자동화