우선, IaC가 무엇의 약어인지 먼저 알아보자!
IaC는 Infrastrucutre as Code, 즉 ‘코드형 인프라’ 라는 뜻이다.
코드형 인프라? 인프라 지식에 거의 무지한 나에겐 각각의 단어는 익숙하지만, 합쳐진 코드형 인프라 라는 단어는 전혀 이해가 되지 않는다.
Red Hat에 따르면, IaC(코드형 인프라)란 수동 프로세스가 아닌 코드를 통해 인프라를 관리하고 프로비저닝하는 것을 말한다고 한다. 수동 프로세스가 아닌 코드를 통해 관리한다고 하니, 코드로 관리하는 것이 더 이점이 많다는 것일 것 같고, 그리고 프로비저닝이라는 단어도 아직 익숙하지가 않다. 그럼 본격적으로 IaC의 개념에 대해 알아보기 전에, ‘프로비저닝’이 무슨 뜻인지 한번 알아보자.
프로비저닝이란 IT 인프라를 설정하고 준비하는 과정을 말하고, 서버, 스토리지, 네트워크 등의 리소스를 필요에 맞게 구성하고 배포하는 작업이다. 간단히 말해서, ‘필요한 IT 자원을 준비해서 사용할 수 있게 만드는 과정’ 이다.
그렇다면 위에서 말했던 문장을 다시 이해하기 쉽게 정리해보자.
IaC(코드형 인프라)란 ‘수동으로 인프라를 관리하는 대신, 코드를 통해 IT 인프라의 설정과 준비 과정(프로비저닝)을 자동화하는 방식’ 이다.
전통적인 방식에서는 서버, 네트워크, 스토리지 등의 인프라를 수동으로 관리하고 구성하였지만, IaC에서는 이러한 과정을 자동화된 코드로 정의한다. IaC를 사용하면 인프라 사양을 담은 구성 파일이 생성되기에, 구성을 편집하고 배포하는 것이 더 쉬워진다. IaC는 매번 동일한 환경을 프로비저닝하도록 보장하고, 구성 사양을 코드화하고 문서화함으로써 구성 관리를 지원한다. 따라서 구성 변경 사항을 문서화하지 않고, 임시로 변경하는 것을 방지할 수 있다.
- 전통적인 수동 방식: 서버실에 가서 물리적으로 서버 설치 → 관리자 콘솔에 접속해서 운영체제 설치 → 각종 설정값을 하나씩 입력 → 필요한 소프트웨어 설치 → 보안 설정 등 추가 작업
- IaC 방식: 서버 설정을 정의한 코드 작성 → 명령어 한 번으로 모든 설정과 설치 자동 완료
IaC의 중요한 부분 중에 하나는 ‘버전 컨트롤’ 이다. 개발을 할 때에도, Git을 활요한 버전 관리를 중요하게 여기듯이, 인프라를 코드로 관리하기로 결정했으면 이 또한 코드의 버전 관리가 중요할 것이다. 다시 말해, 인프라와 관련된 구성 파일 또한 버전 관리가 필요하고, 인프라를 모듈식 구성 요소로 분리하고 자동화를 통해서 또 결합을 할 수 있어야 한다. 인프라를 코드화하여 템플릿을 미리 만들어두고, 프로비저닝을 할 때 이 템플릿을 다시 사용하면 된다. 이러한 작업 또한 수동으로 할 수도 있고, ‘Terraform’ 혹은 ‘Ansible’ 과 같은 자동화 도구를 사용할 수 있다.
그렇다면 IaC는 어떻게 우리가 접근, 활용할 수 있을까? IaC에는 2가지 접근 방식이 있다.
바로 선언형 접근과 명령형 접근 방식이다. 선언형 접근 방식과 명령형 접근 방식이 무엇인지 알아보기 위하여 AWS의 문서를 참고해보았다.
https://aws.amazon.com/ko/what-is/iac/
- 선언적 IaC를 사용하면 개발자가 원하는 시스템의 최종 상태를 구성하는 리소스와 설정을 설명할 수 있습니다. 그러면 IaC 솔루션이 인프라 코드에서 이 시스템을 생성합니다. 따라서 개발자가 애플리케이션을 실행하는 데 필요한 구성 요소와 설정을 알고 있으면 선언적 IaC를 쉽게 사용할 수 있습니다.
- 명령적 IaC를 사용하면 개발자가 리소스를 설정하고 원하는 시스템 및 실행 상태에 도달하는 모든 단계를 설명할 수 있습니다. 명령적 IaC를 작성하는 것은 선언적 IaC만큼 간단하지 않지만, 복잡한 인프라 배포에서는 명령적 접근 방식이 필요합니다. 이벤트 순서가 중요한 경우 특히 그렇습니다.
그렇다면, 이제 IaC를 적용하였을 때 얻게 되는 이점을 추상적으로는 이해할 수 있지만, 조금 더 구체적으로 어떤 이점이 존재하는지 알아보고, 이번 포스팅을 마무리해보자.
기존의 전통적인 방식은 인프라 프로비저닝을 할 때, 시간과 비용이 많이 들었다. 하지만 이제 데이터 센터의 물리적 하드웨어가 아니라 가상화, 컨테이너, 클라우드 컴퓨팅을 이용하여 인프라 관리와 세팅을 하고 있다.
클라우드 컴퓨팅의 영역이 점점 넓혀짐에 따라서, 인프라를 구성하기 위한 요소들이 이에 따라 늘어나게 되었고, 적지 않은 MSA 아키텍처를 가지고 있는 환경들이 늘어남에 따라 더 많은 서버와 코드가 배포되고 있다.
기존보다 더 많은 빈도로 인프라를 관리하고, 다시 배포하는 등 IaC를 적용하지 않으면, 현재 인프라의 규모를 점점 감당하기 힘들 것이다. IaC를 적용한다면 기존 방식 대비 시간과 비용을 절감할 수 있고, 배포 속도가 더욱 향상되며, 재사용성으로 인한 인프라의 일관성이 향상된다.
그럼 정말 마지막으로 이 IaC가 왜 DevOps 엔지니어 혹은 환경에서 중요한 요소로 자리잡았을까? 딱 이것만 정리하고 마무리해보자.
하나라도 자동화를 추구하는 이 상황에서 지속적인 통합과 지속적인 배포(CI/CD)는 매우 중요한 부분을 차지한다. 개발자가 직접 수동으로 하던 프로비저닝 작업을 대부분 IaC로 처리하게 되며, 개발자는 스크립트를 실행하여 인프라를 준비할 수 있다. 따라서 인프라를 준비하는 동안, 애플리케이션의 새로운 기능 혹은 기존 오류를 다시 배포하는것을 미룰 일이 없으며, 시간이 많이 소요되는 수동 프로세스를 관리하지 않아도 된다.
환경을 자동화하려면 환경에 일관성이 있어야 한다. 예를 들어, 개발팀의 애플리케이션 배포 혹은 환경 구성 방식이 운영팀의 배포 그리고 구성 방식과 다른 경우에는 애플리케이션 자동화의 효과가 없는 셈이다.
DevOps 접근 방식을 통해서 개발팀과 운영팀의 방식을 서로 일관되게 한다면, 불일치, 수동 배포 등의 부분에서 비일관적인 배포로 인해 생기는 문제는 줄어들 것이다.
즉, 프로덕션 환경을 비롯한 모든 환경에서 동일하고 일관된 배포 프로세스를 채택해야 한다는 것이다. IaC는 한번 사용될 때마다 동일한 환경을 구성하는데, IaC는 자동으로 다시 생성할 수 없고, 고유한 구성을 지닌 개별 배포 환경을 유지, 관리할 필요가 없어지기에 프로덕션 환경의 일관성이 보장된다.
이 말을 다시 정리하면 아래와 같다.
IaC의 핵심은 '코드를 실행할 때마다 항상 동일한 환경이 만들어진다'는 것이다.
- 기존 수동 방식:
- 개발 환경: A 엔지니어가 서버 설정
- 테스트 환경: B 엔지니어가 서버 설정
- 프로덕션 환경: C 엔지니어가 서버 설정
- 결과: 각자 조금씩 다른 설정으로 환경이 구성됨 (문제 발생 가능성↑)
- IaC 방식:
- 모든 환경: 동일한 코드로 자동 생성
- 결과: 모든 환경이 100% 동일하게 구성됨 (문제 발생 가능성↓)
그리고 마지막으로 소프트웨어 개발 과정 속에서 애플리케이션과 통일된 CI/CD 파이프라인을 인프라에도 적용함으로써, 동일한 테스트 및 버전 제어를 인프라 코드에 반영할 수 있다. 즉, 애플리케이션 개발할 때 사용하는 CI/CD 파이프라인(자동화된 테스트와 배포 프로세스)을 인프라 코드에도 똑같이 적용할 수 있다는 뜻이다.
-
애플리케이션 개발: 코드 작성 → Git에 저장 → 자동 테스트 → 자동 배포
-
IaC도 똑같이: 인프라 코드 작성 → Git에 저장 → 자동 테스트 → 자동 배포
