IaC

What is IaC

뮤셍 2023. 5. 22. 14:02

IaC

IaC(Infrastructure as Code)는 기존 IT 환경에서 클라우드 환경으로 변화하며 중요해진 개념 중 하나로 자리잡고 있다.

기존 IT 환경에서는 서버를 증걸하기 위해 서버 전문 업체에서 서버를 구매한 뒤 서버실에 서버를 추가하는 물리적인 프로세스가 있었기 때문에 IT 인프라를 코드로서 관리하는 것이 쉽지 않았다.

하지만, 클라우드 환경은 논리적인 구성이기에 Terraform이나 CloudFormation과 같은 툴을 사용하여 코드 형태로 인프라를 구성할 수 있게 되었고, 이런 방식으로 인프라를 구성함으로써 인프라 변경에 대해 증가하는 요구 사항을 충족시키거나, 확장 가능하고 추적 가능한 인프라의 관리가 가능해졌기 때문이다.

코드 기반 인프라

코드형 인프라(Infrastructure as Code, IaC)는 수동 프로세스가 아닌 코드를 통해 인프라를 관리하고 프로비저닝하는 것을 뜻한다.

IaC를 사용하면 원하는 인프라 사양을 담은 구성 파일이 생성되고, 구성을 편집하여 인프라를 관리하기 때문에 배포하기가 더 쉬워진다. 그리고 기존의 인프라 구성을 쉽게 재활용 할 수 있다.

또한, IaC는 매번 동일한 환경을 프로비저닝하도록 보장한다.

이처럼 IaC는 구성 사양을 코드화하고 문서화함으로써 구성 관리를 지원하고, 구성 변경 사항을 문서화하지 않고 임시로 변경하는 일을 막을 수 있다.

프로비저닝 vs 배포 vs 오케스트레이션

프로비저닝
시스템, 데이터 및 소프트웨어로 서비스를 준비하고 네트워크 작동을 준비한다.
Puppet, Ansible 등과 같은 구성 관리 도구를 사용하여 서버를 프로비저닝 할 수 있다.
이처럼, 클라우드 서비스를 시작하고 구성하는 것을 프로비저닝한다고 한다.

배포
배포는 프로비저닝 된 서버를 실행하기 위해 애플리케이션 버전을 제공하는 작업이다.
배포는 AWS CodePipeline, Jenkins, Github Actions를 통해 수행할 수 있다.

오케스트레이션
오케스트레이션은 여러 시스템 또는 서비스를 조정하는 작업이다.
오케스트레이션은 마이크로서비스, 컨테이너 및 Kubenetes로 작업할 때 일반적인 용어이다.
오케스트레이션 도구로는 Kubernetes, Salt, Fabric가 있다.

IaC의 장점

IaC는 자동화된 프로세스를 통해 기업이 다양한 방법으로 IT 인프라의 요구를 관리할 수 있도록 지원한다.

 

일관성

  • IaC는 일관성을 개선하고 수동 구성 중에 자주 발생하는 오류를 줄일 수 있다.
    또한 수동 프로세스 중에 발생할 수 있는 구성 드리프트를 제거한다.
  • IaC는 구성 사양을 코딩하고 문서화하여 문서화되지 않은 임시 구성 변경을 방지하는데 도움이 된다.

비용절감

  • IaC를 사용하면 가상 시스템을 프로그래밍 방식으로 관리할 수 있어 수동 하드웨어 구성 및 업데이트가 필요하지 않다.
  • 운영자 한 명이 동일한 코드를 사용하여 1대 또는 1,000대의 시스템을 구축하고 관리할 수 있다.
    즉, 필요한 인력이 줄어들고 새 하드웨어를 구입할 필요가 없어 비용이 크게 절감된다.

효율성

  • 인프라를 코딩하면 프로비저닝용 템플릿이 제공되어 시스템 구성, 유지 보수 및 관리가 간소화 된다.
    이를 통해 반복 가능하고 확장 가능한 탄력적인 인프라를 구축할 수 있다.
  • 따라서 DevOps를 통해 소프트웨어 개발 시 모든 단계의 속도를 높여 매일 더 많은 애플리케이션을 출시할 수 있다.

속도

  • IaC를 이용하면 개발자의 시간을 많이 빼앗는 프로비저닝 작업을 스크립트를 실행하면 되는 간단한 작업으로 전환하여 인프라를 준비할 수 있다.
    그 결과 인프라를 기다리지 않고 애플리케이션을 구축할 수 있으며 새로운 소프트웨어를 훨씬 더 신속하게 출시할 수 있다.

위험 감소

  • IaC는 또한 다른 소프트웨어 소스 코드 파일과 마찬가지로 구성 파일이 소스 통제를 받을 수 있도록 버전 제어를 지원한다.
    이 방식을 통해 위험이 감소된다.

IaC에 대한 선언 접근 방식과 명령 접근 방식

IaC에 대한 접근 방식에는 선언적 방식과 명령적 방식 두 가지가 있다.

선언적 접근 방식

선언적 방식은 필요한 리소스와 리소스의 속성 등 원하는 시스템 상태를 정의하면 IaC 툴이 원하는 인프라 상태로 구성해준다.

또한 선언적 접근 방식에서는 시스템 오브젝트와 현재 상태 목록을 유지하며, 이를 통해 인프라를 더 쉽게 관리할 수 있다.

즉, 선언적 IaC는 사람이 작업하지 않아도 동일한 결과로 여러 번 실행될 수 있다.

명령적 접근 방식

명령적 방식은 원하는 구성을 얻기 위해 인프라를 구성하는 방법 뿐만 아니라 이를 달성하는 방법을 정확하게 정의해야 한다.

이는 특정 구성을 달성하는 데 필요한 명령을 정의해야 하며, 그런 다음 이러한 명령을 한 번에 한 단계씩 적절한 순서로 실행시켜야 한다.

명령적 접근 방식은 업데이트를 허용하지 않고 명시적인 방향을 사용하는 불안정한 접근 방식이다.

인프라의 변경이 필요한 경우, 명령적 IaC 툴은 운영자가 변경 사항이 어떻게 적용되어야 하는지를 해독해야 한다.

 

많은 IaC 툴이 선언적 접근 방식에 따라 원하는 인프라를 자동으로 프로비저닝한다.

원하는 인프라 상태를 변경하면 선언적 IaC 툴은 그러한 변경 사항을 적용해야하고, 명령적 접근 방식의 툴을 사용하려면 변경 사항을 어떻게 적용하는지 이해해야 한다.

보통 IaC 툴은 두 가지 방식을 모두 사용하지만, 둘 중 하나를 더 선호하는 경향이 있다.

코드 기반 인프라(IaC) Tool

IaC를 위한 툴 중에는 인프라 관리에서 구성 관리에 이르기까지, 오픈 소스 툴에서 플랫폼별 툴에 이르기까지 다양한 종류의 툴이 있다.

그 중 대표적인 툴 몇가지에 대해서 알아보자.

Terraform

Terraform(테라폼)은 HashiCorp에서 개발한 오픈 소스 툴이다.

AWS, Azure, GCP, Oracle Cloud, Ailbaba Cloud, Kubernetes 및 Heroku와 같은 다양한 플랫폼에서 인프라 관리에 적합한 IaC 툴이다.

이처럼 플랫폼에 구애받지 않는 툴인 Terraform은 구성 전반에 걸쳐 원하는 상태를 보장하면서 다양한 플랫폼 및 공급자 전반에 걸쳐 인프라 프로비저닝 및 관리에 사용할 수 있다.

 

Ansible

Ansible은 인프라 프로비저닝, 관리와 SW 구축 및 배포의 자동화에 많이 사용되는 툴이다.

Ansible을 이용하여 어려운 수동 반복 작업을 자동화할 수 있고 오류에 덜 취약하게 할 수 있다.

 

Puppet

Puppet은 루비(Ruby)로 만들어진 형상 관리 툴이다.

주로 설정, 관리, 배포, 오케스트레이션과 같은 작업에 사용된다.

 

AWS CloudFormation

AWS에 구축한 구성을 템플릿화하여 재사용하기 쉽게 해주는 서비스이다.

IaC와 DevOps

IaC는 DevOps 사례 및 지속적 통합/지속적 제공(CI/CD)에서 중요한 부분을 차지한다.

CI/CD는 통합 및 테스트에서 제공 및 배포에 이르는 애플리케이션 라이프사이클 전반에 걸쳐 지속적인 자동화와 지속적인 모니터링에 의존한다.

 

인프라 환경을 자동화하기 위해선 환경에 일관성이 있어야 한다.

개발 팀의 애플리케이션 배포 또는 환경 구성 방식이 운영 팀의 배포 및 구성 방식과 다른 경우 애플리케이션 배포 자동화는 효과가 없다.

 

DevOps 접근 방식을 통해 개발 팀과 운영 팀의 방식을 서로 일치시키면 오류, 수동 배포, 비일관성 문제가 줄어든다.

두 팀이 동일한 설명에 따라 애플리케이션을 배포할 수 있으므로 IaC는 개발과 운영을 조율하는 데 도움이 되고, 따라서 DevOps 접근 방식을 지원한다.

즉, 프로덕션 환경을 비롯한 모든 환경에서 동일한 배포 프로세스를 사용해야 하고, IaC는 사용될 때마다 동일한 환경을 생성한다.

또한, IaC는 자동으로 다시 생성할 수 없고 고유한 구성을 지닌 개별 배포 환경을 유지관리할 필요가 없으므로 프로덕션 환경의 일관성이 보장된다.

 

DevOps 모범 사례는 IaC 내 인프라에도 적용된다.

소프트웨어 개발 과정에서 애플리케이션과 동일한 CI/CD 파이프라인을 인프라 내에도 적용함으로써 동일한 테스트 및 버전 제어를 인프라 코드에 반영할 수 있다.

CI/CD 프로세스와 IaC

CI/CD 프로세스에서 IaC 제어 권한은 IT 운영 팀에서 개발자로 이동한다.

이로 인해 DevOps 팀이 인프라 변경을 코드의 다른 부분과 동일한 방식으로 처리하고 DevOps 및 SRE(Site Reliability Engineering) 도구 및 제품을 사용하여 전체 가치 흐름에 감독 기능을 제공할 수 있다.

IaC 베스트 프랙티스

IaC 전략을 최대한 활용하려면 베스트 프랙티스를 파악하고 이에 따라야 한다.

이러한 검증된 사례를 통해 구성 및 배포에 대한 효과적인 IaC 접근 방식을 활용할 수 있다.

 

사양에 대한 문서 사용 지양

  • 인프라 사양에 대한 외부 문서는 명확하지 않으며 파악하기가 쉽지 않다.
  • 외부 문서를 사용하는 습관을 버리고, 대신 항상 정확하고 액세스하기 쉬운 구성 파일 자체에 대한 코드 사양을 활용한다.

코드를 단일 소스로 사용

  • 외부 문서를 사용하는 것보다 인프라 사양을 구성 파일로 코딩하는 것이 바람직하다.
  • 사양의 코딩이 완료되면 구성 파일을 인프라 관리에 관련한 모든 정보에 대한 단일 소스로 참조해야 한다.

철저한 테스트

  • 물리적 구성에 비해 코드가 가지는 이점 중 하나는 테스트가 가능하다는 점이다.
  • IaC 테스트 도구를 사용하여 구성이 프로덕션으로 진행되기 전에 구성에 오류와 비일관성이 없도록 할 수 있다.

전체적인 버전 관리

  • IaC는 개발에 대한 CI/CD 접근 방식에 매우 적합하기 때문에 엄청난 속도로 진행될 수 있다.
  • 새로운 변경이 배포되면 소스 통제를 사용하여 이전 버전이 안전하게 사용할 수 있는 상태로 보관된다.
  • 따라서 새로운 배포로 인해 예상치 못한 문제가 발생하는 경우 이전 버전을 다시 검토하여 로드할 수 있다.