laC의 의미와 필요성
수동 설정의 한계
수동설정은 쉽게 서비스를 제공하고, 아키텍처를 빠르게 실험해볼 수 있다는 점에서 유리하지만, 많은 단점도 가지고 있다.
- 휴먼 에러 때문에 서비스를 설정할 때에 잘못 설정하기 쉽다.
- 설정을 통해 예측되는 상태를 관리하기 어렵습니다
- 환경 설정에 대한 내용을 다른 팀 멤버에 전달하기 어렵다.
IaC ?
DevOps의 주요 가치 중 하나는 바로 자동화. 코드형 인프라(Infrastructure as Code), 즉 IaC는 설정을 코드로 작성하여 클라우드 인프라스트럭처의 생성/수정/삭제를 자동화하는 방법이다.
이는 서버, 데이터베이스, 네트워크, 배포 프로세스, 테스트 등 거의 모든 것을 코드로 관리할 수 있다는 의미이며, 기존에는 (하드웨어) 서버 준비, 네트워킹과 같은 운영적 측면이 물리적 영역과 대응한다. 그러나 현재와 같은 클라우드 네이티브 환경에서는, 운영적 측면이 모두 코드로 대체될 수 있다.
이는 달리 얘기하면, IaC는 인프라스트럭처의 설계도가 될 수 있다.
IaC의 장점
IaC는 다음과 같은 특징 및 장점을 가진다.
- 인프라를 만드는 과정이 자동화되므로, 오류가 훨씬 덜 발생하고 안전하다.
- IaC는 쉽게 공유할 수 있고, 버전 관리에도 용이하다.
- 코드와 현재 상태를 비교하여, 추후 인프라 상태의 변경에 따르는 위험을 분석하고 검증할 수 있다.
- 배포 과정을 소수의 시스템 관리자만 진행하는 것이 아닌, 개발자 스스로가 배포하고 인프라를 통제할 수 있는 환경으로 만들 수 있다.
프로비저닝과 배포
프로비저닝
시스템, 데이터 및 소프트웨어로 서버를 준비하고 네트워크 작동을 준비한다. 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 → Configure가 아니라
- Develop → Configure → Deploy여야 합니다.
- 코드형 인프라(IaC)를 사용한다.
가변적 인프라와 불변적 인프라의 차이점
-
가변적 인프라는 일반적으로 자동화된 수단을 통해 쉽게 변경하거나 수정할 수 있는 인프라 유형을 나타냅니다. 유연성, 확장성 및 적응성이 특징입니다.
-
불변적 인프라는 일단 배치되면 수정할 수 없는 인프라 유형을 말합니다. 기존 구성 요소를 업데이트하거나 수정하는 대신 동일한 구성을 유지하면서 새 구성 요소를 배포하여 교체합니다.
가변적 인프라와 불변적 인프라는 IT 인프라를 관리하고 배포하는 서로 다른 두 가지 접근 방식입니다.
이 둘의 주요 차이점은 다음과 같다.
-
유연성
가변 인프라를 사용하면 인프라 구성 요소가 배포된 후 변경 및 수정이 가능하다.
불변 인프라는 일단 배포된 후에 변경이 허용되지 않는다. -
배포
가변적 인프라에는 일반적으로 기존 구성 요소에 대한 증분 업데이트 및 변경이 포함된다.
불변적 인프라에는 기존 구성 요소를 대체하기 위한 새 구성 요소 배포가 포함된다. -
일관성
가변적 인프라는 시간이 지남에 따라 업데이트 및 변경이 이루어짐에 따라 일관성이 없게 될 수 있다.
불변적 인프라는 모든 구성 요소가 동일한 구성으로 배포되기 때문에 더 큰 일관성을 제공한다.
- 보안성
불변적 인프라는 기존 구성 요소를 대체하기 위해 새로운 구성 요소가 배포되어 무단 변경 또는 취약성의 위험을 줄이기 때문에 안전성을 보장한다.
- 비용
가변적 인프라는 실시간으로 변경 및 업데이트가 가능하기 때문에 더 비용 효율적일 수 있다.
불변적 인프라는 변경이 필요할 때마다 새로운 구성 요소를 배포해야 하므로 비용이 더 많이 들 수 있습니다.
Terraform은 어떤 방식으로 인프라를 최신 상태로 유지할 수 있는 걸까?
Terraform은 선언적 접근 방식 을 사용하여 인프라 구성 요소의 변경 사항을 관리함으로써 인프라를 최신 상태로 유지합니다.
❓선언적 접근 방식 이란?
- 원하는 결과를 얻기 위한 단계나 과정을 정의하는 것이 아니라 원하는 결과나 결과를 프로그래밍하거나 특정하는 방법
- 선언적 접근법에서는 어떻게 달성하느냐보다는 무엇을 달성해야 하느냐에 초점이 맞춰져 있다.
여기에는 인프라의 원하는 상태를 코드로 정의하고 Terraform 을 사용하여 실제 인프라를 원하는 상태에 맞게 조정하기 위해 필요한 모든 변경을 자동으로 수행하는 작업이 포함됩니다.
인프라가 변경되면 Terraform은 변경 사항을 추적하고 인프라의 새로운 상태를 반영하도록 상태 파일을 업데이트합니다. 이를 통해 Terraform은 원하는 상태에서 드리프트를 감지 하고 인프라를 다시 정렬하기 위해 필요한 변경을 수행할 수 있습니다.
❓드리프트 란?
- Terraform에서는 Configuration Drift(정의한 형상과 달라지는 경우)
❓ 드리프트 감지 란?
- 스택의 실제 구성이 예상 구성과 다른지 또는 드리프트 되었는지 여부를 감지할 수 있습니다. CloudFormation을 사용하여 전체 스택 또는 스택 내의 개별 리소스에서 드리프트를 감지합니다.
테라폼은 또한 다양한 클라우드 제공자 및 툴과 통합되어 기반 인프라를 관리하며, 테라폼 외부에서 발생한 변경사항을 자동으로 감지하여 인프라를 원하는 상태로 되돌릴 수 있습니다.
정리하자면, Terraform은 버전 제어 방식 의 자동화된 접근 방식을 사용하여 변경 사항을 관리하고 원하는 상태에서 드리프트를 감지하고 수정할 수 있는 방법을 제공함으로써 인프라를 최신 상태로 유지하는 데 도움이 됩니다.
❓ 버전 제어 란?
버전 제어 시스템은 시간이 지남에 따라 코드에서 변경 내용을 추적하는 데 도움이 되는 소프트웨어.
개발자가 코드를 편집할 때 버전 제어 시스템이 파일의 스냅샷을 만들고 필요한 경우 나중에 회수할 수 있도록 해당 스냅샷을 영구적으로 저장한다.
정리(이해가 필요한 부분)
테라폼을 통해 생성한 인프라의 정보는 테라폼 상태 파일에 기록됩니다.
기본적으로 실행한 위치에 terraform.tfstate 파일이 생성되고 테라폼 구성 파일의 리소스를 실제 인프라 리소스와 매핑할 수 있는 형태로 기록됩니다.
하지만 실제 팀 단위 운영환경에서 최신 상태로 유지하려면 조건이 필요하다.
-
상태 파일을 위한 공유 스토리지
모든 팀원이 동일한 상태 파일에 접근하기 위해 공유 스토리지에 위치해야 합니다. -
상태 파일 동시 접근 제어를 위한 잠금기능
상태 파일이 공유 스토리지에 위치하기 위해서는 잠금 기능이 필요합니다. 여러 팀원이 동시에 접근하여 상태 파일을 업데이트하는 경우 데이터가 손실되거나 파손될 우려가 있기때문. -
상태 파일의 환경별 격리
구성파일 변경의 영향을 받는 범위를 해당 환경으로 격리하는 것이 좋습니다. 사용자의 실수로 개발이나 테스트 환경의 변경이 운영환경에 영향을 미쳐 장애로 이어지는 상황이 발생할 수 있습니다.
참고
https://learn.microsoft.com/ko-kr/devops/develop/git/what-is-version-control
https://heuristicwave.github.io/TerraformTips3
https://www.bridge-global.com/blog/mutable-vs-immutable-infrastructure/
https://blog.hwahae.co.kr/all/tech/tech-tech/8207
