IaC(Infrastructure as Code)란?

  • 10분

코드 제공 인프라가 회사의 리소스 프로비전에 중요한 접근 방식일 수 있는지 평가하라는 요청을 받았고, 다음을 포함하여 배포에 사용할 수 있는 옵션을 검토하고 있습니다.

  • Azure portal
  • Azure CLI
  • Azure PowerShell
  • Azure Resource Manager 템플릿(JSON 및 Bicep)

반복 가능한 옵션을 찾고 있으며 Azure 인프라를 배포하는 데 사용할 기술을 결정해야 합니다.

이 단원에서는 코드 제공 인프라가 자동화되고 반복 가능한 방식으로 Azure 인프라를 배포하는 데 어떤 방식으로, 또 어떤 이유로 도움이 되는지 알아봅니다.

Azure CLI 명령은 개념을 설명하는 데 사용됩니다. 명령을 사용하여 Bicep 학습 경로의 다른 모듈에 리소스를 배포하는 방법에 대해 자세히 알아봅니다.

코드 제공 인프라 정의

회사에서 출시할 새 장난감을 설계하고 있습니다. 대부분의 새 장난감은 구매한 후 약간의 조립이 필요합니다. 회사의 설계 팀은 각 장난감에 들어가는 조립 설명서를 만듭니다. 각 설명서는 장난감을 적절히 조립하는 자세한 방법을 제공합니다.

이와 같이, 코드 제공 인프라를 인프라에 대한 지침 설명서로 생각할 수 있습니다. 설명서는 리소스의 최종 구성과 해당 구성 상태에 도달하는 방법을 자세히 설명합니다.

코드 제공 인프라는 인프라 프로비전을 자동화하는 프로세스입니다. 소스 코드에 사용되는 것과 비슷한 설명적인 코딩 언어와 버전 관리 시스템을 사용합니다. 애플리케이션을 만들 때 소스 코드는 컴파일될 때마다 동일한 결과를 생성합니다. 비슷한 방식으로 코드 제공 인프라 배포는 자동화되고 일관되며 반복할 수 있습니다. 코드 제공 인프라는 가상 네트워크, 가상 머신, 애플리케이션, 스토리지와 같은 인프라 리소스의 배포를 자동화할 수 있습니다.

Diagram that shows the infrastructure as code process using a source code repository with a template that deploys Azure resources.

새 장난감의 조립 설명서를 떠올려보면 설명서를 작성하는 방법은 여러 가지가 있습니다. 한 가지 방법은 조립 과정의 각 단계를 자세히 설명하는 것입니다. 또 다른 방법은 장난감을 조립하는 데 필요한 부품을 보여 주는 것입니다. 이 단원의 후반부에서는 명령형 코드와 선언형 코드 간의 차이점과 이러한 코드가 장난감 회사의 지침 설명서와 어떠한 관련이 있는지 알아봅니다.

코드 제공 인프라란?

코드 제공 인프라 접근 방식을 채택하는 것은 리소스 프로비전에 많은 이점을 제공합니다. 코드 제공 인프라를 사용할 경우 다음이 가능합니다.

  • 배포에 대한 신뢰도를 높일 수 있습니다.
  • 여러 환경을 관리할 수 있습니다.
  • 클라우드 리소스에 대한 이해를 향상할 수 있습니다.

신뢰도 향상

코드 제공 인프라를 사용하는 이점 중 하나는 일관성 및 보안 향상을 통해 배포에서 얻을 수 있는 신뢰 수준입니다.

  • 현재 프로세스와의 통합: 조직에서 이미 표준 소프트웨어 개발 방식을 사용하는 경우 인프라 배포에 동일한 프로세스를 채택할 수 있습니다. 예를 들어 동료 평가는 수동으로 변경할 때 검색하기 어려울 수 있는 구성 문제를 검색하는 데 도움이 될 수 있습니다.

  • 일관성: 코드 제공 인프라를 채택하면 팀이 잘 확립된 프로세스에 따라 인프라를 배포할 수 있습니다. 이러한 프로세스에 따라 책임은 소규모 그룹에서 자동화 프로세스 및 도구로 전환됩니다. 코드 제공 인프라는 리소스 프로비전에서 인적 오류를 줄이고 일관된 배포를 보장하는 데 도움이 됩니다.

  • 자동화된 검사: 코드에서 오류를 검사할 수 있는 자동화된 도구를 통해 코드 제공 인프라 구성을 검사할 수 있습니다. 또한 자동화된 도구는 제안된 변경 내용을 검토하여 보안 및 성능 규칙을 준수하도록 할 수 있습니다.

  • 비밀 관리: 많은 솔루션에는 연결 문자열, 암호화 키, 클라이언트 암호 및 인증서와 같은 비밀이 필요합니다. Azure에서 Azure Key Vault는 이러한 비밀을 안전하게 저장하는 데 사용되는 서비스입니다. 많은 코드 제공 인프라 도구가 Key Vault와 통합되어 배포 시 안전하게 이러한 비밀에 액세스할 수 있습니다.

  • 액세스 제어: 코드 제공 인프라 배포를 사용하면 관리 ID 또는 서비스 계정을 사용하여 리소스 프로비저닝을 자동화할 수 있습니다. 이 프로세스를 통해 이러한 ID로만 클라우드 리소스를 수정할 수 있습니다. 또한 프로덕션에 배포되는 잘못된 구성을 방지하는 데 도움이 됩니다. 필요한 경우 긴급 액세스 계정(break glass 계정이라고도 함)을 사용하거나 Microsoft Entra ID Privileged Identity Management 기능을 사용하여 이 프로세스를 재정의할 수 있습니다.

  • 구성 드리프트 방지: 멱등성은 코드 제공 인프라와 자주 연결되는 용어입니다. 작업이 멱등적일 경우 실행될 때마다 동일한 결과를 제공한다는 의미입니다. 멱등 작업을 사용하는 도구를 선택하는 경우에는 구성 드리프트를 방지할 수 있습니다.

멱등성의 예제로 다음 Azure CLI 명령을 고려합니다. 명령은 미국 동부 지역에서 storage-resource-group이라는 Azure 리소스 그룹을 만듭니다.

az group create \
  --name storage-resource-group \
  --location eastus

이 Azure CLI 명령이 idempotent로 설계되었기 때문에 이 명령을 두 번째로 실행하면 정확히 동일한 출력이 표시됩니다. 오류 또는 중복된 리소스 그룹을 수신하지 않습니다.

코드 제공 인프라를 사용하는 경우 솔루션의 각 릴리스에서 환경을 다시 배포할 수 있습니다. 이러한 릴리스는 소규모 구성 변경 또는 중요한 업데이트를 포함할 수 있습니다. 이 프로세스를 통해 구성 드리프트를 방지할 수 있습니다. 리소스를 실수로 변경한 경우 구성을 다시 배포하여 수정할 수 있습니다. 이 접근 방식을 따르면 코드를 사용하여 환경을 문서화하게 됩니다.

여러 환경 관리

많은 조직에서는 여러 애플리케이션 환경을 유지 관리합니다. 장난감 회사의 개발자에게는 여러 환경으로 릴리스하기 위해 리포지토리에서 준비한 여러 버전의 애플리케이션 코드가 있을 수 있습니다. 이러한 환경에는 개발, 테스트 및 프로덕션이 있을 수 있습니다. 일부 조직에서는 애플리케이션에 대해 전 세계적으로 분산된 여러 프로덕션 환경을 유지 관리합니다. ISV(독립 소프트웨어 공급업체)와 같은 다른 조직은 고객을 위해 다중 테넌트 환경을 유지 관리합니다.

다음은 코드 제공 인프라가 환경을 관리하는 데 도움이 될 수 있는 몇 가지 주요 방법입니다.

  • 새 환경 프로비전: 클라우드 컴퓨팅의 주요 이점 중 하나는 확장 기능입니다. 코드 제공 인프라는 애플리케이션의 여러 인스턴스로 확장하는 데 도움이 될 수 있습니다. 이러한 인스턴스는 부하가 증가한 시기에 활용하거나 세계의 다른 지역에 있는 사용자를 위해 배포할 수 있습니다. 이 민첩성은 침투 테스트, 부하 테스트, 버그 테스트와 같이 애플리케이션을 테스트할 때도 유용할 수 있습니다. 잘 정의된 코드베이스를 사용하면 이러한 새 환경을 일관된 방식으로 동적으로 프로비전할 수 있습니다.

  • 비프로덕션 환경: 조직이 직면하는 일반적인 문제는 프로덕션 환경과 비프로덕션 환경의 구별입니다. 별개의 환경에서 리소스를 수동으로 프로비전하는 경우 최종 구성이 일치하지 않을 수 있습니다. 한 예로 프로덕션 환경과 다른 비프로덕션 환경에 새 기능을 배포하는 경우를 들 수 있습니다. 두 환경 간의 차이로 인해 프로덕션 환경에서는 새 기능이 예상대로 작동하지 않을 수 있습니다. 코드 제공 인프라를 사용하면 이러한 문제를 최소화할 수 있습니다. 각 환경에 동일한 구성 파일을 사용하지만 다른 입력 매개 변수를 제공하여 고유성을 확보할 수 있습니다.

  • 재해 복구: 일부 상황에서는 코드 제공 인프라를 조직의 재해 복구 계획의 일부로 사용할 수 있습니다. 예를 들어 서비스 중단으로 인해 다른 지역에서 환경을 다시 만들어야 할 수 있습니다. 코드 제공 인프라를 사용하면 모든 것을 수동으로 배포하고 다시 구성하는 대신 새 인스턴스를 신속하게 프로비전하여 장애 조치(failover)할 수 있습니다.

클라우드 리소스에 대한 이해 향상

코드 제공 인프라를 통해 클라우드 리소스의 상태를 보다 잘 이해할 수 있습니다.

  • 감사 내역: IaC(infrastructure as code) 구성 변경 내용은 애플리케이션 소스 코드와 같은 방식으로 버전 관리됩니다. 이러한 변경 내용은 Git 버전 기록과 같이 도구에서 추적됩니다. 이 감사 내역은 각 변경 내용, 변경한 사람 및 변경한 시간을 검토할 수 있음을 의미합니다.

  • 설명서: 많은 코드 제공 인프라 구성을 사용하여 구성에서 코드의 용도를 설명하는 주석과 같은 메타데이터를 추가할 수 있습니다. 조직에서 이미 코드 설명서 프로세스를 따르는 경우 인프라 코드에도 이와 동일한 절차를 채택하는 것이 좋습니다.

  • 통합 시스템: 개발자가 새 기능을 개발할 때 애플리케이션 코드와 인프라 코드를 변경해야 합니다. 공통 시스템을 사용하면 조직에서 애플리케이션과 인프라 간의 관계를 더 잘 이해할 수 있습니다.

  • 클라우드 인프라에 대한 이해 향상: Azure Portal을 사용하여 리소스를 프로비전 할 때 많은 프로세스를 보기에서 추상화합니다. 코드 제공 인프라를 통해 Azure의 작동 방식 및 발생 가능한 문제를 해결하는 방법을 보다 잘 이해할 수 있습니다. 예를 들어 Azure Portal을 사용하여 가상 머신을 만들 때 만든 일부 리소스는 보기에서 추상화됩니다. 관리 디스크 및 네트워크 인터페이스 카드는 내부적으로 배포됩니다. 코드 제공 인프라를 사용하여 동일한 가상 머신을 배포하는 경우 생성되는 모든 리소스를 완전히 제어할 수 있습니다.

명령형 코드와 선언형 코드의 비교

새 장난감에 대한 조립 설명서를 다양한 방식으로 작성할 수 있습니다. 서비스 및 인프라 배포를 자동화할 때 두 가지 방식이 있는데, 하나는 명령형이고 다른 하나는 선언형입니다.

  • 명령형 코드를 사용하면 특정 순서로 명령 시퀀스를 실행하여 최종 구성에 도달합니다. 이 프로세스는 코드가 수행해야 하는 작업을 정의하고 작업을 수행하는 방법을 정의합니다. 명령적 접근 방식은 단계별 지침 설명서와 같습니다.

  • 선언형 코드를 사용하면 최종 구성만 지정합니다. 이 코드는 작업을 수행하는 방법을 정의하지 않습니다. 선언적 접근 방식은 전개도 지침 설명서와 같습니다.

리소스 프로비저닝에 명령적 접근 방식 또는 선언적 접근 방식 중에서 선택하는 경우 조직에서 이미 사용 중일 수 있는 도구를 고려하세요. 또한 사용자 자체 기술과 일치할 수 있는 방법도 고려해야 합니다.

명령형 코드

Azure에서 명령형 코드 접근 방식은 Bash 또는 Azure PowerShell 같은 스크립팅 언어를 사용하여 프로그래밍 방식으로 수행됩니다. 스크립트는 리소스를 만들고, 수정하고, 제거하는 일련의 단계를 실행합니다.

이 예제에서는 리소스 그룹과 스토리지 계정을 만드는 두 개의 Azure CLI 명령을 보여 줍니다.

#!/usr/bin/env bash
az group create \
  --name storage-resource-group \
  --location eastus

az storage account create \
  --name mystorageaccount \
  --resource-group storage-resource-group \
  --location eastus \
  --sku Standard_LRS \
  --kind StorageV2 \
  --access-tier Hot \
  --https-only true

첫 번째 명령은 미국 동부 지역에서 storage-resource-group이라는 Azure 리소스 그룹을 만듭니다. 두 번째 명령은 첫 번째 명령에서 만든 storage-resource-group 리소스 그룹에 mystorageaccount라는 스토리지 계정을 만듭니다. 또한 두 번째 명령은 스토리지 계정의 종류 및 해당 액세스 계층을 포함한 스토리지 계정의 몇 가지 속성을 구성합니다.

명령적 접근 방식을 사용하여 리소스 프로비전을 완전히 자동화할 수 있지만 이 접근 방식에는 몇 가지 단점이 있습니다. 아키텍처의 완성도가 증가하면서 스크립트 관리가 복잡해질 수 있습니다. 명령이 업데이트될 수 있거나 더 이상 사용되지 않을 수 있으며, 그러면 기존 스크립트의 검토가 필요합니다.

선언형 코드

Azure에서 선언형 코드 접근 방식은 템플릿을 사용하여 수행됩니다. 다음을 포함하여 다양한 유형의 템플릿을 사용할 수 있습니다.

  • JSON
  • Bicep
  • Ansible(RedHat)
  • Terraform(HashiCorp)

참고

이 모듈에서는 Bicep 템플릿을 사용하는 방법을 중점적으로 설명합니다.

스토리지 계정을 구성하는 다음 Bicep 템플릿 예제를 살펴보세요. 스토리지 계정의 구성은 Azure CLI 예제와 일치합니다.

resource storageAccount 'Microsoft.Storage/storageAccounts@2022-05-01' = {
  name: 'mystorageaccount'
  location: 'eastus'
  sku: {
    name: 'Standard_LRS'
  }
  kind: 'StorageV2'
  properties: {
    accessTier: 'Hot'
    supportsHttpsTrafficOnly: true
  }
}

리소스 섹션에서 스토리지 계정 구성을 정의합니다. 이 섹션에는 SKU 및 계정 종류를 포함하여 스토리지 계정의 이름, 위치 및 속성이 포함되어 있습니다.

Bicep 템플릿은 스토리지 계정을 배포하는 방법을 지정하지 않습니다. 스토리지 계정이 어떤 형태여야 하는지만을 지정합니다. 이 스토리지 계정을 사양과 일치하도록 만들거나 업데이트하기 위해 이면에서 실행되는 실제 단계는 Azure가 결정하도록 맡겨둡니다.