May 11, 2023 4 min to read

Infrastructure as Code/ TIL

IaC의 의미와 필요성

Infrastructure as Code

---

DevOps의 주요 가치 중 하나는 자동화이다. IaC는 설정을 코드로 작성하여 클라우드 *인프라스트럭처의 생성/수정/삭제를 자동화하는 방법이다.

이는 서버, DB, 네트워크, 배포 프로세스, 테스트 등 거의 모든 것을 코드로 관리할 수 있다는 의미이다. 실제로 선을 연결하고, 하드웨어를 준비하는 것 처럼 기존에는 서버 준비, 네트워킹과 같은 운영적 측면이 물리적 영역과 대응한다.

현재와 같은 *클라우드 네이티브 환경에서는, 운영적 측면이 모두 코드로 대체될 수 있다. 이는 달리 얘기하면, IaC는 인프라스트럭처의 설계도가 될 수 있다.

IaC의 장점

• 인프라를 만드는 과정이 자동화되므로, 오류가 훨씬 덜 발생하고 안전하다.
• IaC는 쉽게 공유할 수 있고, 버전 관리에도 용이하다.
• 코드와 현재 상태를 비교하여, 추후 인프라 상태의 변경에 따르는 위험을 분석하고 검증할 수 있다.
• 배포 과정을 소수의 시스템 관리자만 진행하는 것이 아닌, 개발자 스스로가 배포하고 인프라를 통제할 수 있는 환경으로 만들 수 있다.

AWS 콘솔을 이용하여 인프라를 구성한 그림이다.

위와 같은 수동 설정의 경우 쉽게 서비스를 제공하고, 아키텍처를 빠르게 실험해 볼 수 있다는 점에서 유리하다. 하지만 다음과 같은 한계가 존재한다.

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

필요성

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

Configuration Drift : 예상치 못한 인프라 변경에 따른 사고

일반적으로 IAM을 통해 각 팀 또는 개인에게 필요한 만큼의 권한을 주고 인프라를 사용한다. 예를 들어, 프로덕션 레벨에 있는 특정 인스턴스 권한을 가지고 있는 누군가가 실수로 삭제하여 제품에 영향을 미치면, 이를 어떻게 알아내고 고칠 수 있을까? 지우는 것 이외에도 어떤 보안 그룹의 설정을 변경하여 시스템 전체에 영향을 미치는 경우는 어떨까?

접근 방법, 도구

• AWS Config : 잘못 설정된 것을 찾기 위한 도구 (바른 설정을 지정해 놓고, 찾고 고칠 수 있게 만들어준다.)
• AWS CloudFormation Drift Detection : 사고 감지 도구
• Terraform state files : 정상 작동 상태를 파일로 저장 (테라폼의 상태 정의 파일은 인프라의 실제 상태와의 비교 대상으로서 현재 상황을 진단/점검할 수 있다.)

위와 같은 접근 방법에 따른 도구들이 있다. 그렇다면 방지하는 방법에 대해 알아보자. 불변한(Immutable) 인프라 스트럭처는 인프라 변경을 원천적으로 막을 수 있는 방법론이다. 실제로 인프라를 수동 설정으로 변경할 수 있지만, 다음의 실천적 방법을 통해 애초에 그 가능성을 막으면 된다.

원칙

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

가변적 인프라와 불변적 인프라의 차이

가변적 인프라는 기존 인프라 구성 요소를 직접 수정할 수 있는 반면, 불변적 인프라는 인프라를 변경할 수 없는 것으로 취급하고 원하는 변경 사항으로 새 인스턴스를 생성한다. 불변적 인프라는 일관성 및 재현성과 같은 이점을 제공하지만, 자동화된 배포 방식으로 전환해야 한다.

• 가변적 인프라

  인프라가 제자리에서 직접 수정되거나 업데이트 되는 기존 접근 방식을 나타낸다. 일반적으로 개별 서버나 시스템에 로그인하여 필요한 수정을 한다.

  이 접근 방식을 사용하면 임시 변경을 유연하게 수행할 수 있지만 인프라의 서로 다른 인스턴스 간에 구성 드리프트 및 불일치가 발생할 수도 있다.

  이 모델에서는 서버, 가상 머신 또는 구성 설정과 같은 기존 인프라 구성 요소를 직접 변경한다.

• 불변적 인프라

  인프라 구성 요소를 불변으로 취급하고 일단 생성되면 수정하지 않는 접근 방식이다. 기존 구성 요소를 업데이트 하는 대신 사전 구성된 템플릿 또는 이미지에서 인프라의 새 인스턴스를 생성하여 모든 변경 또는 업데이트가 이루어진다.

  불변적 인프라는 종종 Docker와 같은 컨테이너화 기술을 사용하거나 VM 이미지를 활용하여 달성된다. 변경이 필요할 때마다 원하는 구성으로 새 컨테이너 또는 VM 이미지가 빌드되고 배포되는 반면 이전 인스턴스는 종료되거나 폐기된다.

  안정성, 확장성, 재현성이 확장되었고, 각 인스턴스는 알려지고 일관된 상태에서 생성되므로 가변적 인프라에서 발생할 수 있는 예기치 않은 변경 또는 불일치의 위험을 제거한다.

  일반적으로 IaC 및 구성 관리와 같은 도구를 사용해 프로비저닝 및 배포 프로세스를 자동화하여 새 인스턴스를 효율적이고 일관돠게 생성할 수 있다.

*인프라스트럭처 : 사회, 경제 또는 조직의 운영, 기능에 필요한 기본적인 물리적 및 조직적 시스템, 시설, 구조를 의미한다.

*클라우드 네이티브 환경 : 클라우드 컴퓨팅 원칙과 기술을 활용하여 애플리케이션을 구축하고 실행하는 소프트웨어 개발, 배포 및 운영에 대한 접근 방식을 의미한다. 클라우드 플랫폼 용으로 특별히 애플리케이션을 설계하고 클라우드의 확장성, 유연성 및 복원력을 활용하는 것이 특징이다.

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

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

*오케스트레이션 : 여러 시스템 또는 서비스를 조정하는 작업. 마이크로서비스, 컨테이너 및 쿠버네티스로 작업할 때 일반적인 용어이다. (Kubernetes, Saly, Fabric 등)