TFAS (TerraForm Addicted School)의 내용을 정리한 글입니다.
심각한 테라폼 중독입니다 - 책 으로 스터디를 진행합니다.
IaC는 인프라를 사람의 개입에 의한 물리적 방식에 의존하지 않고, 시스템화된 코드로 정의하여 인프라를 자동으로 관리하는 프로비저닝 방식을 말한다.
IaC가 관리하는 인프라는 베어메탈이든 가상 머신이든 가리지 않는다. 다만, IaC 개념의 대중화는 클라우드 네이티브 패러다임의 확산과 밀접한 관련이 있다.
IaC의 대장주 테라폼과 클라우드 대장주 AWS를 기반으로 알아보자.
클라우드 컴퓨팅 vs 온프레미스 컴퓨팅
클라우드 서비스는 인터넷을 통해서 원하는 컴퓨팅과 그에 부속된 리소스를 고객이 필요한 만큼 프로비저닝 할 수 있는 서비스다. 클라우드와는 반대되는 개념이 온프렘이라고 불리는 방식인데, 직접 물리 서버를 사서 인프라를 구축하는 것이다. 클라우드가 발전하면서 온프레미스의 단점들이 더욱 부각되었다.
클라우드의 장점 중 하나는 인프라 프로비저닝에 들어가는 초기 비용의 감소다. 필요한 만큼의 컴퓨팅 리소스만 클라우드를 통해서 프로비저닝 할 수 있기 때문에, 온프렘에서 서버 랙을 구해서 컴퓨팅 리소스를 준비하고 셋업 하는 데 드는 초기 비용을 엄청나게 줄일 수 있었다.
애플리케이션이 확장됨에 따라 컴퓨팅 리소스의 확장이 필요한데, 온프렘에서 구축한 서버는 더 높은 사양의 컴퓨터를 사서 컴퓨팅 리소스를 늘려야 한다. 리소스 축소가 필요한 경우에도 기존의 리소스를 줄이는 것은 이미 투자한 초기 비용이 있기 때문에 선택하기 어려운 옵션이다.
클라우드에서는 리소스에 대한 변경이 정말 쉬워졌다. 이 리소스의 변경은 두 가지 측면이 있다.
수직 확장성 (Vertical Scaling)
한 가지는 수직 확장성이라고 할 수 있는 컴퓨팅 리소스를 빵빵하게 늘리는 것이다. 컴퓨팅 리소스 중 램이든 CPU든 스토리지든 부족한 경우, 기존 컴퓨터를 대체해서 더 빵빵한 컴퓨터로 교체하는 것이 클라우드에서는 너무 쉬운 일이다. 확장뿐만 아니라 축소도 기존 리소스를 반납만 하면 되기 때문에 간편하다.
수평 확장성 (Horizontal Scaling)
다른 측면은 수평 확장성이라고 하는 관점이다. 여러 대의 컴퓨팅 리소스를 프로비저닝하는 것은 클라우드에서 식은 죽 먹기보다도 쉽다. 확장이 필요한 애플리케이션을 동일한 컴퓨팅 수준의 컴퓨터를 더 실행시켜서 확장하는 방식이다. 이는 동일한 사양의 컴퓨터를 추가하거나 축소하면서 쉽게 달성할 수 있다.
온프렘 환경에서는 기존 랙에 구성되어 있는 컴퓨터를 추가하기 위해 동일한 사양의 컴퓨터를 사서 랙에 추가하고 네트워크 구성까지 해야 한다. 축소 또한 쉽지 않았을 것이다. 따라서 수평 확장성은 클라우드 컴퓨팅이 발전하면서 더욱 빛을 발하게 되었다.
이렇게 클라우드 상에서 수평 확장성이 부각되면서 애플리케이션 레벨에서도 컨테이너 기반 서비스와 마이크로서비스의 개념이 탄생하고 확산하게 되었다.
클라우드 네이티브 패러다임
수평 확장성의 핵심은 유연성이다. 기존 컴퓨팅의 확장이 필요한 경우, 수직으로 사양을 늘리는 방식보다 수평으로 동일한 컴퓨터를 확장시키는 방식이 비용적으로도 그리고 리소스 활용 면에서도 훨씬 유리하다. 이런 수평 확장성은 클라우드 환경에서 더욱 쉽게 달성할 수 있기 때문에, 애플리케이션 개발부터 클라우드의 수평 확장성을 염두에 두는 클라우드 네이티브 패러다임이 인기를 얻게 되었다.
컴퓨팅 리소스가 수평으로 확장될 때, 기존 애플리케이션과 완전히 동일한 실행 환경이 새롭게 생성된 컴퓨터 환경에서 실행되어야 한다. 이를 가장 잘 달성할 수 있는 컨테이너 기반의 시스템을 설계하고 애플리케이션을 배포하는 것이 클라우드 네이티브의 표준이 되었다. 수평 확장에 유리한 컨테이너 환경은 수평으로 확장되는 컴퓨팅 환경에서 기존 애플리케이션과 동일한 실행 환경을 보장하면서도 확장이 쉽기 때문에 클라우드 네이티브의 표준으로 자리 잡았다.
애플리케이션 구조 또한 작은 규모로 쉽게 확장 가능한 방식으로 설계되었다. 거대한 단일 모놀리스 애플리케이션 구조가 아닌, 여러 개의 상호작용하는 작은 애플리케이션 규모로 분리해 실행하는 마이크로서비스 아키텍처가 인기를 얻게 되었다. 이를 통해서 성능 병목이 발생하는 일부 마이크로서비스에 대해서만 수평 확장이 가능하게 되며, 다양한 방식의 배포 프로세스를 적용할 수 있게 되었다.
클라우드의 복잡성?
위 내용을 보면 기존의 모놀리식 애플리케이션 아키텍처나 온프레미스에서 미리 리소스를 준비해서 사용하는 방식은 확장성이나 변경에 대한 제약이 많아 보이기 때문에 단점이 부각될 것이다. 하지만 클라우드 인프라도 단점이 존재한다.
클라우드는 모든 컴퓨팅 리소스를 인터넷을 통해 제공한다. 그렇기 때문에 하나의 서비스를 운영하기 위해선 수많은 클라우드 서비스의 프로비저닝 및 관리가 필요해졌다. 클라우드가 제공하는 수많은 서비스를 이해하고 사용해야 하며, 이에 따라 복잡성이 증가하게 되는 구조다.
AWS의 가장 기본적인 컴퓨팅 리소스인 EC2 인스턴스를 프로비저닝 하기 위해 AWS 클라우드에서 필요한, 혹은 고려해 보면 좋을 서비스들은 다음과 같다.
- 컴퓨팅: EC2, ASG 등
- 스토리지: EBS, EFS, S3 등
- 네트워크: VPC, Subnet, RT, NAT, IGW, ELB, EIP, SG 등
시스템이 고도화될수록 클라우드 상에서 사용하는 서비스도 많아지고, 리소스의 수도 늘어날 것이다. 복잡도가 점점 증가하면서 더 많은 사람이 관리를 위해 필요한 상황이 되는 것이다.
클라우드 인프라 관리
애플리케이션이 고도화될수록 클라우드 자원이 더 많이 필요하며, 더 많은 클라우드 리소스는 더 많은 클라우드 엔지니어가 함께 일하는 것을 의미한다. 이런 경우 클라우드 인프라를 API를 통해 실행하고 변경하고 삭제한다면 어떤 문제점이 있을 수 있을까?
1. 맥락 파악이 겁나 어렵다.
5명의 엔지니어가 클라우드 인프라를 API 호출을 통해서 관리한다고 해보자. 이에 대한 실행 로그가 기가 막히게 잘 남는다면 모르겠지만, 일반적으로는 어떤 목적으로 리소스를 생성, 변경, 삭제했는지 알기 어렵다. 클라우드 리소스에 대한 작업 사항을 함께 일하는 동료에게 일일이 물어보는 것으로 히스토리를 파악해야 할 것이다.
2. 재해 복구 또한 어려워.
인프라 조작 실수로 인해 장애가 발생하면 기억에 의존해서 롤백해야 한다. 클라우드 상에 어떤 요청이 발생했는지 기억해야 하며, 필요한 모든 변경 사항을 롤백하는 것도 정말 어려울 것이다.
스크립팅을 통한 클라우드 리소스 관리의 한계
API 기반 조작을 스크립트화하여 관리하면 반복적으로 작업을 빠르게 수행할 수 있고, API 호출에 대한 흐름이 스크립트에서 보이기 때문에 API 호출보다는 더 나은 사용성을 제공할 것이다. 하지만, 스크립트를 이용한 방법도 근본적인 문제점을 가지고 있다. 바로 사용자 요청에 의한 명령형 패러다임을 따른다는 것이다.
명령형 패러다임은 명령문을 통해 시스템 상태를 바꾸는 방식으로, 최종 결과물 상태의 인프라를 선언하는 것이 아닌 해당 상태가 될 수 있도록 사용자가 순서대로 명령을 작성하는 방식이다.
이런 명령형 패러다임은 1회성 작업인 애드혹(ad-hoc) 작업을 수행하는 데는 도움이 될 수 있다. 하지만 기존 프로비저닝 상태의 유지 및 점진적 수정에는 불리하다. 명령형의 경우에는 특정한 상태 변경을 요청하는 방식인데, 해당 상태를 요청하고 난 후에는 더 이상 해당 상태에 대한 추적이 이루어지지 않는다. 그렇기 때문에 스크립트의 버전 관리를 하면서 변경을 트래킹 하지 않는 이상, 단일 요청에만 유리하다.
또한, 인프라 리소스의 변경이 아닌 생성에는 문제가 더 크다. 만약 100개의 인스턴스를 생성하다가 50개까지 생성되는 중에 문제가 발생해 종료된다면? 그럼 다음 명령형 스크립트를 실행하면 100대가 더 실행되어 총 150대의 인스턴스가 실행될 것이다. 현재 상태는 고려하지 않기 때문에 상태 변화만 실행하게 되는 것이다.
마지막으로는 스크립트의 경우 인프라 리소스 중심이 아닌 사용자의 행동 중심이다. 앞서 말한 스크립트 버전 관리를 하더라도 사용자의 변경에 대한 액션 히스토리를 확인하여 현재 상태를 파악해야 하기 때문에 복잡도가 늘어나게 되는 것이다.
선언형 IaC 도구의 필요성
이처럼 클라우드 인프라는 다양한 종류의 리소스를 대규모로 관리해야 하기 때문에, 서비스가 성장할수록 관리 포인트가 많아진다. 인프라 복잡도뿐만 아니라 관리자 간의 협업 복잡도도 늘어나기 때문에 협업에 대한 안정성이 확보되어야 한다.
슬랙이나 지라 혹은 다양한 협업 툴을 통해서 함께 업무하는 사람들끼리 작업에 대한 영속성을 이어가면 좋겠지만, 분리된 채널에서 작업 히스토리를 관리하는 것은 오히려 더 큰 복잡도를 발생시킨다.
이런 관점에서 필요한 것이 바로 명령형 방식이 아닌 선언형 방식의 IaC 도구다. 프로그램이나 시스템의 최종 상태를 선언해 두면, 시스템은 해당 상태를 맞추기 위해 내부적으로 필요한 작업을 실행하는 방식이다.
이는 스크립트를 통한 관리 방식이나 API를 통한 관리 방식과는 다른 접근법을 취하는데, 사용자는 원하는 기대 상태를 변경하는 것만으로 목적을 달성할 수 있다.
최종 상태에 대한 선언을 통해 현재 인프라의 "상태"가 관리되기 때문에 동일한 변경을 100번 수행하더라도 멱등성이 보장된다.
사용자 명령에 대한 히스토리 관리가 아닌 인프라의 결과 상태에 대한 히스토리를 관리하기 때문에, 사용자가 내린 명령으로 바뀐 결과를 찾아서 히스토리를 트래킹 하는 방식과는 달리 최종 상태를 확인하여 변경 관리가 이뤄지는 점도 큰 특징이다.
'School > TFAS' 카테고리의 다른 글
| [TFAS] 테라폼 기능별 실무 사례 (챕터 6, 7, 8, 9) (1) | 2025.12.01 |
|---|---|
| [TFAS] 챕터 5 테라폼 모듈 & 챕터 10 모듈을 직접 만드는 이유와 만드는 방법 (1) | 2025.11.29 |
| [TFAS] 챕터 4 테라폼 기본 문법 (1) | 2025.11.25 |
| [TFAS] 챕터 3 테라폼 작동 방식 (0) | 2025.11.24 |
| [TFAS] 챕터 2 우리는 왜 테라폼을 쓰는가? (0) | 2025.11.15 |
