GCP에서 인스턴스들을 여러번 생성해보면서 느낀건 생각보다 이 작업들이 편하진 않다는 것이다. 물론 VM ware나 Virtual box같은 곳에서 보다야 편하긴한데 GCP 콘솔이 생각보다 그렇게 빠릿한 느낌도 들지않고, 만져야할 설정들도 꽤 많고, 수정사항이 있으면 기존 머신 이미지를 복사해놓은 것을 폐기하고 새로이 다시 만들어야하기 때문에 여러모로 번거로운 면이 있다.

게다가 머신 이미지가 있다고 하더라도 매번 콘솔에서 클릭해서 적용을 해줘야하기 때문에 인프라를 구성하는 과정이 그렇게 빠르지도 않아서 간단한 개인 프로젝트 수준이라면 몰라도, 대규모 인프라를 관리하는 기관에서는 이 단순 반복작업이 상당히 불필요한 리소스의 낭비라고 생각할 수 도 있다.

그런데 이러한 작업들을 모두 코드로 작성해서 사용할 수 있다면 어떨까?

개인적으로 프로그래밍의 장점을 하나 꼽자면 코드를 수정하면 그 변화가 즉각적으로 적용된다는 사실이다. 따라서 인프라도 이렇게 코드로 작성할 수 있다면, 인프라의 유지보수가 상당히 쉬워지고 프로비져닝도 용이할 것이다. 변경 사항이 있을 땐, 코드의 일부분만 수정해서 배포하면 되니 이것이야 말로 인프라의 자동화일 것이다. 그리고 이와 관련된 개념이 바로 오늘의 포스팅 주제인 Infrastructure as Code(IaC)가 되겠다.

개요

iac0

예전에는 Network, Compute, Storage로 된 단순한 형태의 인프라만이 존재했었다. 그래서 인프라를 관리하기 위해서는 SE(System Engineer)가 IDC에 상주하거나 방문해야만 했다. 그러다가 15년 전쯤 가상화라는 개념이 도입되면서 Private Cloud라는 것이 만들어지고, Public Cloud가 등장하기에 이르렀다. Private과 Public은 초기에는 각각 분리되어 운영되었지만, 최근에 들어서는 두 클라우드가 유기적으로 결합하는 Hybrid Cloud와 여러개의 Cloud를 운영하는 Multi Cloud라는 환경으로의 변화가 일어나고 있다. 이것이 Tranditional DataCenter에서 Modern DataCenter로의 전환이다.

현재 기업들에 있어서는 클라우드는 이제 선택이 아닌 필수의 영역이다. 급변하는 IT 환경에 적응하기 위해서는 반드시 클라우드가 필요하기 때문이다. 그런데 Modern DataCenter로 변화함에 있어서 문제는 종속된 복잡한 기술이다.

iac1

Infrastructure, Security, Networking, Application이라는 계층들과 전통적인 데이터센터, Private Cloud, Public Cloud 이 모든 환경들이 각각의 독립적인 도구들이 사용되고 있고 이 도구들은 서로 다른 환경들을 제어할 수 없다.

또한, 기업 IT부서의 입장에서도 담장자가 자주 바뀌거나, 다양한 클라우드 인프라를 사용해야하기 때문에 너무 많은 기술을 습득해야하니 담당자를 교육하는 것이 쉽지않고, 이러한 반복적인 인프라 작업을 단순 메뉴얼로 진행하면 누락이 되거나 갱신이 되지않아서 인프라의 장애로 이어지는 위험도 존재한다.

이러한 배경속에서 클라우드 인라를 효과적으로 관리하기 위해서 등장했고, 최근에 각광받기 시작한 클라우드 인프라 관리 방법이 바로 IaC이다.

IaC란?

IaC(Infrastructure as Code)는 컴퓨터에서 읽을 수 있는 정의 파일을 사용하여 클라우드 인프라를 관리하고 프로비저닝하는 프로세스를 의미한다. 즉, 코드로 스크립트를 작성해 인프라를 정의하여 관리하는 방법이다. 이로인해 코드형 인프라라는 말로 불리기도 한다.

IaC를 사용하면 인프라 사양을 담은 구성 파일이 생성되므로 구성을 편집하고 배포하기가 더 쉬워진다. 게다가 IaC는 매번 동일한 환경을 프로비저닝하도록 보장할 뿐만아니라 구성 사양을 코드화하고 문서화함으로써 구성 관리를 지원한다. 따라서 구성 변경 사항을 문서화하지 않고 임시로 변경하는 일을 막을 수 있다.

비전 제어는 IaC의 중요한 부분이다. 다른 소프트웨어 소스 코드 파일과 마찬가지로 구성 파일도 소스 제어가 필요하다. 코드로 인프라를 배포한다는 것은 인파를 모듈식 구성요소로 분할하고 자동화를 통해 다양한 방식으로 결합 할 수 있다는 의미기도 하다.

IaC로 인프라 프로비저닝을 자동화하면, 애플리케이션을 개발하거나 배포할 때마다 개발자가 직접 서버, 운영체제, 스토리지, 기타 인프라 구성요소를 수동으로 프로비저닝하고 관리할 필요가 없어진다. 인프라를 코드화하여 템플릿을 만들고 프로비저닝할 때 이 템플릿을 사용하면 되기 때문이다. 이러한 작업은 수동으로 진행할 수 도 있고, 다양한 자동화 툴을 사용할 수도 있다. IaC를 지원하는 자동화 툴에는 대표적으로 Terraform, Chef, Ansible 등이 있다.

iac2

IaC의 이점

IaC를 사용하여 가질 수 있는 장점은 크게 5가지이다.

일관성 : IaC는 일관성을 개선하고 수동 구성 중에 자주 발생하는 오류를 줄일 수 있다. 또한 수동 프로세스 중에 발생할 수 있는 구성 드리프트를 제거한다. IaC는 구성 사양을 코딩하고 문서화하여 문서화되지 않은 임시 구성 변경을 방지하는 데 도움이 된다.
비용절감 : IaC를 사용하면, 가상 시스템을 프로그래밍 방식으로 관리할 수 있어서 수동 하드웨어 구성 및 업데이트가 필요하지 않다. 운영자 한명이 동일한 코드를 사용하여 수많은 서버로 시스템을 구축하고 관리할 수 있다. 즉, 필요한 인력이 줄어들고, 하드웨어를 새로이 구입할 필요가 없어 비용이 크게 절감된다.
효율성 : 인프라를 코딩하면 프로비저닝용 템플릿이 제공되어 시스템 구성, 유지 보수 및 관리가 간소화 된다. 이를 통해 반복 가능하고 확장 가능한 탄력적인 인프라를 구축할 수 있다. 따라서 DevOps를 통해 소프트웨어 개발 시 모든 단계의 속도를 높혀 매일 더 많은 어플리케이션을 출시 할 수 있다.
속도 : IaC를 이용하면 개발자의 시간을 많이 빼앗는 프로비저닝 작업을 스크립트를 실행하면 되는 간단한 작업으로 전환하여 인프라를 준비할 수 있다. 그 결과 인프라가 구축되는 것을 기다리지 않고 어플리케이션을 구축할 수 있으며 새로운 소프트웨어를 훨씬 더 신속하게 출시할 수 있다.
위험 감소 : IaC는 다른 소프트웨어 소스 코드 파일과 마찬가지로 구성 파일이 소스 통제를 받을 수 있도록 비전 제어를 지원한다. 이를 통해 위험을 감소 시킬 수 있다.

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

IaC에 접근하는 방식에는 두가지가 있다. 대부분의 IaC 툴은 두 가지 접근 방식 모두에서 운용할 수 있지만, 사용할 툴은 한번에 많은 코드를 작성하는지 아니면 더 정교한 인프라를 구축하는지 등 현재의 작업에 따라 다르다.

우선 선언적 접근방식은 필요한 리소스와 리소스의 속성 등 바람직한 시스템 상태를 정의하면 IaC 툴이 바람직한 상태로 구성해주는 방식이다. 이 방식을 사용하면 시스템 오브젝트의 현재 상태 목록을 유지하여 인프라를 더 쉽게 관리할 수 있다.

반면 명령적 접근 방식에는 바람직한 구성을 얻기 위한 특정 명령을 정의하며 정의된 명령을 올바른 순서대로 실행해야 한다. 업데이트를 허용하지 않고 명시적인 방향을 사용하는 방식이기 때문에 다소 불안정한 접근방식이다.

많은 IaC 툴은 선언적 접근 방식에 따라 원하는 인프라를 자동으로 프로비저닝한다. 원하는 상태를 변경하면 선언적 IaC 툴은 그러한 변경 사항을 적용한다. 명령형 접근 방식의 툴을 사용하려면 변경 사항을 어떻게 적용하는지를 이해해야 한다.

IaC가 DevOps에 중요한 이유

IaC는 DevOps 사례 및 CI/CD에서 중요한 부분을 차지한다. 개발자가 하던 프로비저닝 작업을 대부분 IaC로 처리하고 개발자는 스크립트를 실행하여 인프라를 준비할 수 있다. 따라서 인프라 준비를 기다리는 동안 어플리케이션 배포를 보류할 필요가 없고, 시스템 관리자는 시간이 많이 소요되는 수동 프로세스를 관리하지 않아도 된다.

CI/CD는 통합 및 테스트에서 제공 및 배포에 이르는 어플리케이션 라이프사이클 전반에 걸쳐 지속적인 자동화와 지속적인 모니터링에 의존한다. 환경을 자동화하려면 환경에 일관성이 있어야하고 개발팀의 어플리케이션 배포 또는 환경 구성 방식이 운영팀의 배포 및 구성 방식과 다르면 어플리케이션 배포 자동화는 효과가 없다.

그러나 DevOps 접근 방식을 통해 개발 팀과 운영 팀의 방식을 서로 일치시면 오류, 수동 배포, 비일관성 문제가 줄어든다. 두 팀이 동일한 설명에 따라 어플리케이션을 배포할 수 있으므로 IaC는 개발과 운영을 조율하는 데 도움이 되고, 따라서 DevOps 접근방식을 지원가능하다.

다시말해 프로덕션 환경을 비롯한 모든 환경에서 동일한 배포 프로세스를 사용해야하며, IaC는 사용될 때마다 동일한 환경을 생성함으로써 이를 가능하게 한다. 또한 IaC는 자동으로 다시 생성할 수 없고 고유한 구성을 지난 개별 배포 환경을 유지 관리할 필요가 없으므로 프로덕션 환경의 일관성이 보장된다.

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