Infrastructure as Code

Jaeminst·2022년 4월 15일
0
post-thumbnail

IaC의 의미와 필요성

지금까지 인프라를 수동으로 일일이 구성하였다면, Terraform 같은 IaC로 인프라를 빠르게 구성할 수 있다.

즉, 코드를 통해서 인프라를 관리하고 프로비저닝할 수 있다.

다음 상황들을 가정해보기

  • 위 그림에서 인프라를 완전히 다른 리전이나 IaaS에 똑같이 복제하고 싶을 경우
  • 특히, 해당 리전이 갑자기 사용할 수 없는 상황에 직면했을 경우
  • 기존과는 다른 새로운 아키텍처를 빠른 시간 내에서 적용해야할 경우

수동 설정

수동설정은 쉽게 서비스를 제공하고, 아키텍처를 빠르게 실험해볼 수 있다는 점에서 유리하지만, 많은 단점도 가지고 있습니다.

  • 휴먼 에러 때문에 서비스를 설정할 때에 잘못 설정하기 쉽습니다
  • 설정을 통해 예측되는 상태를 관리하기 어렵습니다
  • 환경 설정에 대한 내용을 다른 팀 멤버에 전달하기 어렵습니다

IaC

DevOps의 주요 가치 중 하나는 바로 자동화입니다.
코드형 인프라(Infrastructure as Code), 즉 IaC는 설정을 코드로 작성하여 클라우드 인프라스트럭처의 생성/수정/삭제를 자동화하는 방법입니다.

이는 서버, 데이터베이스, 네트워크, 배포 프로세스, 테스트 등 거의 모든 것을 코드로 관리할 수 있다는 의미입니다. 기존에는 (하드웨어) 서버 준비, 네트워킹과 같은 운영적 측면이 물리적 영역과 대응합니다. 실제로, 선을 연결하고, 하드웨어를 준비하는 것처럼 말이죠. 그러나 현재와 같은 클라우드 네이티브 환경에서는, 운영적 측면이 모두 코드로 대체될 수 있습니다.

이는 달리 얘기하면, 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 plan Command

terraform plan 명령은 실행 계획을 생성하여 Terraform이 인프라에 적용할 변경 사항을 미리 볼 수 있도록 합니다. 기본적으로 Terraform은 계획을 생성할 때 다음을 수행합니다.

  • 이미 존재하는 원격 개체의 현재 상태를 읽어 Terraform 상태가 최신 상태인지 확인합니다.
  • 현재 구성을 이전 상태와 비교하고 차이점을 확인합니다.
  • 적용되는 경우 원격 개체가 구성과 일치하도록 하는 일련의 변경 작업을 제안합니다.

어떻게 방지할까?

불변한(Immutable) 인프라스트럭처는 인프라 변경을 원천적으로 막을 수 있는 방법론입니다.
실제로 인프라를 수동 설정으로 변경할 수 있지만, 다음의 실천적인 방법을 통해 애초에 그 가능성을 막는 것입니다.

Immutable InfraStructure

  • 한번 생성했으면 수정하지 않는다.
    • 프로비저닝 및 배포했으면, 콘솔에 접속해서 수동으로 설정하지 않습니다.
    • 즉 변경은 삭제 후 생성을 의미합니다.
  • 인스턴스 내부 구성(사용자 스크립트 등)이 필요할 경우 AMI로 만들어 놓습니다.
    • 즉, Develop → Deploy → Configure가 아니라
    • Develop → Configure → Deploy여야 합니다.
  • 코드형 인프라(IaC)를 사용합니다.

IaC 종류

절차형 IaC

프로그래밍 언어를 이용해서 직접 순차적으로 인프라를 생성하도록 코드를 작성하는 방법입니다.
선언형에 비해 더 강력한 일들을 할 수 있으나, 실제 적용된 결과를 가늠하기 어렵고, 코드를 읽기에 직관적이지 않습니다.

실제로 EC2를 추가로 생성할 갯수를 입력한다.

절차형 IaC의 종류

선언형 IaC

선언형 언어 JSON, YAML 등을 사용합니다.
실제 인프라가 적용된 결과(기대하는 상태)와 적용할 내용(YAML 등)이 직관적으로 매핑됩니다.

최종적으로 원하는 EC2 갯수를 입력한다.

선언형 IaC의 종류

  • Amazon Web Services
    CloudFormation

  • Microsoft Azure
    Blueprint

  • Google Cloud Platform
    Cloud Deployment Manager

  • Terraform
    어떤 클라우드 서비스에도 적용되는 범용 IaC 도구입니다.

프로그래밍

Programming

  • imperative
    • Object-oriented
    • Procedural
  • declarative
    • Logic
    • Functional

절차형 프로그래밍

imperative programming === How to
원하는 결과를 절차를 통하여 얻는다.

절차형 프로그래밍 언어에서는 비선언적인 형태를 라이브러리나 프레임워크 등으로 캡슐화하여
선언형 프로그래밍을 흉내낸다.

선언형 프로그래밍

declarative programming === What is
원하는 결과를 선언한다.

따라서, 선언형 프로그래밍은 작업에 대한 깊은 이해가 높게 요구되지 않는다.

profile
DevOps !

0개의 댓글