IaC의 의미와 필요성
수동 설정의 한계
수동 설정은 쉽게 서비스를 제공하고 아키텍처를 빠르게 실험해볼 수 있다는 점에서 유리하지만, 많은 단점도 가지고 있다.
- 휴먼 에러 때문에 서비스를 설정할 때, 잘못 설정하기 쉽다.
- 설정을 통해 예측되는 상태를 관리하기 어렵다.
- 환경 설정에 대한 내용을 다른 팀 멤버에 전달하기 어렵다.
IaC
DevOps의 주요 가치 중 하나는 바로 자동화이다.
코드형 인프라(Infrastructure as Code), 즉 IaC는 설정을 코드로 작성하여 클라우드 인프라스트럭처의 생성/수정/삭제를 자동화하는 방법이다.
이는 서버, 데이터베이스, 네트워크, 배포 프로세스, 테스트 등 거의 모든 것을 코드로 관리할 수 있다는 의미이다.
기존에는 (하드웨어) 서버 준비, 네트워킹과 같은 운영적 측면이 물리적 영역과 대응한다.
실제로, 선을 연결하고, 하드웨어를 준비하는 것처럼 말이다.
그러나 현재와 같은 클라우드 네이티브 환경에서는, 운영적 측면이 모두 코드로 대체될 수 있다.
이는 달리 얘기하면, IaC는 인프라스트럭처의 설계도가 될 수 있다는 말과 같다.
IaC의 장점
- 인프라를 만드는 과정이 자동화되므로 오류가 훨씬 덜 발생하고 안전하다.
- IaC는 쉽게 공유할 수 있고 버전 관리에도 용이하다.
- 코드와 현재 상태를 비교하여 추후 인프라 상태의 변경에 따르는 위험을 분석하고 검증할 수 있다.
- 배포 과정을 소수의 시스템 관리자만 진행하는 것이 아닌 개발자 스스로가 배포하고 인프라를 통제할 수 있는 환경으로 만들 수 있다.
프로비저닝과 배포
프로비저닝 vs. 배포 vs. 오케스트레이션
프로비저닝
시스템, 데이터 및 소프트웨어로 서버를 준비하고 네트워크 작동을 준비한다.
Puppet, Ansible 등과 같은 구성 관리 도구를 사용하여 서버를 프로비저닝할 수 있다.
이처럼, 클라우드 서비스를 시작하고 구성하는 것을 '프로비저닝'한다고 한다.
배포
배포는 프로비저닝된 서버를 실행하기 위해 애플리케이션 버전을 제공하는 작업이다.
배포는 AWS CodePipeline, Jenkins, Github Actions를 통해 수행할 수 있다.
오케스트레이션
오케스트레이션은 여러 시스템 또는 서비스를 조정하는 작업이다.
오케스트레이션은 마이크로서비스, 컨테이너 및 Kubernetes로 작업할 때 일반적인 용어이다.
오케스트레이션 도구로는 Kubernetes, Salt, Fabric이 있다.
예상치 못한 인프라 변경에 따른 사고
Configuration Drift
AWS와 같은 클라우드 서비스에 우리가 인프라 관리자로 일하고 있다고 가정해보자.
일반적으로 IAM을 통해 각 팀 또는 개인에게 필요한 만큼의 권한을 주고 인프라를 사용할 수 있게 할 것이다.
그렇지만 도구를 각자의 손에 쥐어줄 경우 모두가 이를 제대로 사용하라는 법은 없다.
예를 들어 프로덕션 레벨에 있는 어떤 특정한 인스턴스를 권한을 갖고 있는 누군가가 실수로 삭제해서 제품에 영향을 미칠 경우 이를 어떻게 알아내고, 어떻게 고칠 수 있을까?
꼭 지우는 것만이 위험 요소가 아니다.
어떤 보안 그룹의 설정을 변경하여 시스템 전체에 영향을 미치는 경우는 어떨까?
이처험 예상치 못한 인프라 변경에 대한 사고와 미치는 영향을 Configuration Drift라고 부른다.
어떻게 알아내고, 어떻게 고칠까?
사건을 알아내는 방법은 접근 방법에 따라 조금씩 다르다.
AWS를 기준으로 접근 방법과 도구를 알아보면 아래와 같다.
- 잘못 설정된 것을 찾기 위한 도구: AWS Config
- 바른 설정을 지정해놓고, 찾고 고칠 수 있게 만들어준다.
- 사고 감지 도구: AWS CloudFormation Drift Detection
이러한 관리형 서비스 외에 보다 개발 방법에 가까운 솔루션은 아래와 같다.
- 정상 작동 상태를 파일로 저장: Terraform state files
Terraform의 상태 정의 파일은 인프라의 실제 상태와의 비교 대상으로 현재 상황을 진단/점검할 수 있다.
어떻게 방지할까?
불변한(Immutable) 인프라스트럭처는 인프라 변경을 원천적으로 막을 수 있는 방법론이다.
실제로 인프라를 수동 설정으로 변경할 수 있지만. 다음의 실철적인 방법을 통해 애초에 그 가능성을 막는 것이다.
- 한번 생성했으면 수정하지 않는다.
- 프로비저닝 및 배포를 했으면 콘솔에 접속해서 수동으로 설정하지 않는다.
- 즉, 변경은 삭제 후 생성을 의미한다.
- 인스턴스 내부 구성(사용자 스크립트 등)이 필요할 경우 AMI로 만들어 놓는다.
- 즉 Develop → Deploy → Cofigure가 아니라,
Develop → Configure → Deploy여야 한다.
- 즉 Develop → Deploy → Cofigure가 아니라,
- 코드형 인프라(IaC)를 사용한다.
