[ IaaS ] Infrastructure as a Code(IaC)란?

클라우드를 이용하여 서버나 애플리케이션을 배포하는 것은 일상적인 일이 되었습니다. 하지만 이런 배포를 매번 개발자가 직접 수동으로 명령어를 스크립트나 순서대로 타이핑하며 배포하기에는 번거로움이 있고 일관성을 유지하기도 힘들다고 생각됩니다.

또한, 인프라를 구축하고 유지하기 위해 다양한 설정들을 해주어야 하는데, 이러한 과정에서 사람이 직접 수동 설정하게 되면 휴먼 에러가 발생하기 쉽고, 이러한 설정 상황을 팀원들에게 공유하기가 쉽지 않습니다.

또한, CLI등을 통해 설정 값 변경시 상태 관리도 어렵다는 여러 단점이 존재합니다. 물론, 능숙한 개발자에 의해 쉽고 빠르게 설정하여 테스트해볼 수 있다는 장점은 있을 수 있습니다.

 

이러한 인프라를 유지하기 위한 지속적인 배포와 오류를 줄이기 위해 자동화를 도와주는 툴을 사용하면 더 좋을 것 같습니다. 그래서 이번 게시글을 통해 IaaS, IaC란 무엇이며 그 특징들에 대해서 정리해보려 합니다.

 

 

 

IaC (Infrastructure as a Code)

코드형 인프라는 인프라의 설정을 수동 프로세스가 아닌 코드를 통해 인프라를 관리하고 프로비저닝(인프라를 생성하고 설정)하는 것을 의미합니다. 즉, 인프라 설정을 코드로 하여 클라우드 Infra structure의 생성, 수정, 삭제를 자동화하는 방법입니다.

 

IaC를 사용하면 인프라 사양을 담은 구성 파일을 코드로 생성하고 관리하므로, 구성을 변경 및 배포도 용이하게 됩니다. 그렇게 됨으로써 매번 동일한 환경을 프로비저닝하도록 보장합니다. 이렇게 되면, 사소한 실수에 의한 설정값 변경을 막을 수 있고, 동일한 코드에 의한 프로비저닝은 동일한 결과를 가져온다는 신뢰도를 쌓을 수 있습니다.

 

이러한 코드형 인프라에서도 버전 관리는 중요합니다. 서버나 애플리케이션을 위한 코드들도 버전 관리가 중요하듯, 인프라를 프로비저닝하기 위한 코드 버전 관리는 인프라의 안정성을 위해서 필수적인 요소입니다. 특정 코드를 수정한 이력이 남아 있지 않으면 변경된 인프라에 의해 발생하는 문제를 찾기가 앱에서와 마찬가지로 쉽지 않습니다.

 

위에서 설명한 두 가지 장점과 더불어 IaC를 사용하여 인프라 프로비저닝을 자동화하면 애플리케이션을 배포할 때마다 개발자가 직접 서버, 운영 체제, 스토리지, 기타 인프라 구성 요소를 수동으로 프로비저닝하고 관리할 필요가 없습니다.

즉, 코드로 서버, OS, 네트워크, 스토리지, 테스트 등을 자동화하여 관리할 수 있습니다. 인프라를 코드화하여 템플릿을 만들고 프로비저닝을 할 때 이 템플릿을 사용하면 가능합니다. (IaC의 주요 가치는 자동화입니다.)

즉, 프로비저닝을 위한 인프라스트럭처의 설계도가 IaC로 작성한 코드가 됩니다. ✔

 

 

[ 장점 ]

• 안정성: 인프라를 구축하는 과정이 자동화되므로 오류 발생이 감소하고 안전함
• 비용절감: 수동으로 하는 노동 비용이 감소함으로써 작업 효율 증대
• 일관성 확보: 표준화된 포맷과 규칙으로 작성된 코드 문서로 인프라를 일관되게 관리가 가능
• 관리 용이성: 코드로써 관리함으로 쉽게 공유가 가능하고 버전 관리 용이 (재사용성, 유지보수 개선)
• 구성의 변동 가능성 낮음 (실수에 의한)
• 배포 속도 향상 및 인프라 파이프라인 구축으로 효율적 개발 가능

인프라 프로비저닝은 진입 장벽이 꽤 높고, 러닝 커브가 있다 보니 시간과 비용이 꽤 많이 드는 프로세스입니다. 하지만, 이제 직접 데이터 센터의 물리적 하드웨어가 아니라 가상화, 컨테이너, 클라우트 컴퓨팅을 이용하여 인프라를 관리할 수 있습니다. 그렇게 되면서 점점 더 많은 인프라 구성요소가 생기고, 더 잦은 빈도로 실행시키고 중지하고, 확장할 수 있는 인프라가 필요해졌습니다.

이에 따라 IaC를 사용하지 않으면 관리가 갈수록 어려워질 것 입니다. IaC의 위와 같은 장점을 통해 인프라 요구사항을 손쉽게 구축하고 관리할 수 있을 것 입니다 :)

 

 

 

명령적 접근과 선언적 접근

IaC의 접근 방식에는 선언적 방식과 명령적 방식이 있습니다.

선언적 접근 방식은 필요한 리소스와 속성 등 바람직한 시스템 상태를 정의하면 IaC툴이 바람직한 상태로 구성합니다. 

또한 시스템 오브젝트의 현재 상태 목록을 유지하며, 이를 통해 인프라를 좀 더 쉽게 관리할 수 있게 해줍니다.

선언적 언어의 장점 중 하나는 멱등성이 뛰어납니다. 선언적 언어는 최종 상태만 정의하기 때문에 어디서부터 시작하든 항상 동일한 위치에 있게 되므로 사용자로 하여금 같은 상태를 보장합니다.

 

명령적 접근 방식은 바람직한 구성을 얻기 위한 특정 명령을 정의하며, 정의된 명령을 올바른 순서로 실행해야 합니다.

장점으로는 다층식 명령어 계층을 구축하여 매우 상세하고 복잡한 구성을 자동화할 수 있다는 것입니다. 또한, 명령적 시스템은 사용자에게 작업을 수행하는 방식에 대한 제어권을 보다 많이 제공하기 때문에, 선언적 시스템보다 특정 목적 최적화하기에 보다 효율적이고 간편할 때가 많습니다.

하지만, 명령적 도구 사용 시, 사용자는 자동화 플랫폼에 수행할 작업을 지시하기 위해 충분한 지식을 갖고 있어야 합니다.

 

두 접근 방식의 큰 차이점으로는 선언적 방식은 최종 상태를 알려주면 IaC가 달성해주는 것이고, 명령적 방식은 그 최종 상태를 달성하기 위해 필요한 명령들은 순서대로 명령을 내려야 합니다.

 

 

 

가변 인프라 불변 인프라

가변 인프라는 변할 수 있는 인프라라는 의미로 온프레미스 서버와 일맥상통합니다.
쉽게 말해 서버가 생성 된 후에 변경이 가능한 상태의 인프라입니다. 엔지니어와 관리자가 수동으로 애플리케이션을 업/다운그레이드하고, 서버의 설정파일을 일일이 수정하고, 새 코드를 기존 서버에 배포합니다. ex) on premise server

불변 인프라는 서버가 배포된 이후 변하지 않는 형태의 인프라를 의미합니다.
만약 업데이트, 수정이 필요한 경우에는 새 서버가 프로비저닝되고, 기존 서버는 삭제되며 대체됩니다.
그래서 변경사항이 발생하면 기존 인프라를 처분하고, 새 인프라로 교체하는 방식으로 진행되기에 간단하고, 일관성 있고, 예측 가능한 배포 프로세스를 가집니다. ex) 도커 컨테이너, EC2

 

불변 인프라의 장점으로는 서버의 교체와 확장에 용이합니다. 

• 문제가 발생한 경우에도 특정 부분만 수정하여 재 배포를 한다면 장애 대응이 가능하지만, 가변 인프라의 경우에는 서버를 다시 살려내기 위해 많은 노력이 필요할 수 있습니다.
• 또한, 불변 인 프라는 수평 확장에 용이합니다. 모든 서버가 동일한 프로세스를 이용하기에 서비스 환경을 복제하고 배포하는 것이 용이합니다.
• 간단한 롤백과 복구 프로세스를 가집니다. 롤백은 이전 버전의 이미지로 재 배포한다면 롤백이 간편하게 처리됩니다.

 

 

 

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

반복적으로 언급하고 있는 위 단어들의 차이점에 대해 알아보고자 합니다.

프로비저닝은 일반적으로 제공하는 것을 의미합니다. 요구 사항에 맞게 시스템나 서버, 클라우드 환경 자체를 제공하는 것을 의미합니다. 즉, IT인프라를 생성하고 설정하는 프로세스를 의미하며 다양한 리소스들에 대한 사용자 및 시스템 액세스를 관리하는데 필요한 단계를 포함합니다.

보통 클라우드 환경에서 자주 사용하는 프로비저닝의 의미는 각 서비스들을 용도에 맞게 세팅을 하여 환경 구성을 자동화 하는 것을 자동화 Provisioning이라 하며, 이를 통해 전반에서 뛰어난 일관성을 제공하고, 오류 가능성과 생산성 손실을 줄이며 지속적이고 일관적인 배포가 가능하게 됩니다.

 

 

그렇다면 배포는 무엇을 의미할까요? 배포란 프로비저닝된 인프라 위에 배포 환경을 구축하고, 개발자가 만든 애플리케이션등을 빌드 및 컴파일 과정을 거쳐 사용자가 사용할 수 있도록 운영 환경에 배포함을 의미합니다.

 

 

오케스트레이션은 시스템과 여러 애플리케이션 및 서비스의 자동화된 구성을 관리 및 조정을 의미합니다.

오케스트레이션의 목표는 빈도가 높고 반복할 수 있는 프로세스의 실행을 간소화 및 최적화하여 데이터 팀이 복잡한 작업과 워크플로를 간편하게 관리하도록 돕는 것입니다. 프로세스를 반복할 수 있고 작업을 자동화할 수 있다면 오케스트레이션을 사용하여 시간을 절약하고 효율성을 증대하고 중복성을 없앨 수 있습니다.

 

자동화와 오케스트레이션은 고도로 상호보완적이지만, 의미는 서로 다릅니다. 자동화는 사람이 개입할 필요 없이 작업이 실행되도록 프로그래밍하는 것이고 오케스트레이션은 여러 개의 작업(그중 일부는 자동화되어 있을 수도 있음)을 하나의 종단간 프로세스나 작업으로 구성하는 것을 말합니다. 또한 오케스트레이션 소프트웨어는 프로세스 전체에 걸쳐 이벤트나 활동에 반응해야 하고, 한 가지 자동화된 작업에서 얻은 출력을 바탕으로 의사 결정을 내려 다음 작업을 판단하고 조율할 줄도 알아야 합니다.

 

 

 

 

IaC가 DevOps에 중요한 이유

IaC는 DevOps 사례 및 지속적 통합/지속적 제공(CI/CD)에서 중요한 부분을 차지합니다. 개발자가 하던 프로비저닝 작업을 대부분 IaC로 처리하고 개발자는 스크립트를 실행하여 인프라를 준비할 수 있습니다.  

따라서 인프라 준비를 기다리는 동안 애플리케이션 배포를 보류할 필요가 없으며, 시스템 관리자는 시간이 많이 소요되는 수동 프로세스를 관리하지 않아도 됩니다.  CI/CD는 통합 및 테스트에서 제공 및 배포에 이르는 애플리케이션 라이프사이클 전반에 걸쳐 지속적인 자동화와 지속적인 모니터링에 의존합니다. 

 

환경을 자동화하려면 환경에 일관성이 있어야 합니다. 개발 팀의 애플리케이션 배포 또는 환경 구성 방식이 운영 팀의 배포 및 구성 방식과 다른 경우 애플리케이션 배포 자동화는 효과가 없습니다.

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

두 팀이 동일한 설명에 따라 애플리케이션을 배포할 수 있으므로 IaC는 개발과 운영을 조율하는 데 도움이 되고, 따라서 DevOps 접근 방식을 지원합니다. 다시 말해 프로덕션 환경을 비롯한 모든 환경에서 동일한 배포 프로세스를 사용해야 합니다. IaC는 사용될 때마다 동일한 환경을 생성합니다.

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

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