IaC(Infrastructure-as-code)를 통해 개발자와 운영 팀은 컴퓨터로 해독 가능한 정의 파일을 사용하여 컴퓨터 데이터 센터를 자동으로 관리할 수 있습니다.
얼핏 보면 IaC는 과거에 수작업이었던 일(IT 인프라 구성)을 단순히 디지털화하는 것으로 새롭지 않은 것처럼 보입니다. 하지만 이러한 전환에 따라 IT 직원들이 수십 년 동안 겪어 온 다양한 주요 문제를 해결할 수 있습니다.
IT 인프라 관리는 복잡하고 많은 인력이 필요할 뿐 아니라 비용도 많이 듭니다. 프로세스의 각 단계에서 엔지니어, 유지관리 기술 전문가, 기타 담당자들이 필수 작업을 수행할 수 있어야 합니다. 조직은 이러한 전문가의 급여 요구 사항을 충족할 수 있어야 합니다. 또한 적절한 조율 및 자원 배치 요구 사항을 충족하려면 더 많은 관리 비용이 필요합니다.
모니터링 및 가시성 문제도 기존 구성의 잠재적인 문제입니다. 기존 인프라 구성은 여러 개인 또는 팀에 의존하므로 일관성이 없으며 모니터링 및 성과 최적화가 매우 어려워지는 경우가 종종 있습니다. 이러한 비일관성으로 인해 잘못된 매개변수가 사용되는 경우 잘못된 구성 문제로 인해 잠재적으로 심각한 영향이 발생할 수 있습니다. 잘못된 구성으로 인해 많은 사람에게 영향을 주는 대규모 시스템 중단이 발생하는 경우가 많습니다.
마지막으로, 수작업 구성을 위해서는 시스템 관리자가 새로운 서버를 구성해야 하기 때문에 수요 증가에 대한 대응 속도가 느립니다. 자원에 대한 수요가 급증함에 따라, 수작업 구성으로 인해 효과적인 확장이 불가능하고 기업이 증가하는 업무를 처리하기가 어렵습니다. 또한 사용할 수 있는 백업 서버가 없어 애플리케이션 가용성이 낮아집니다.
DevOps에서도 기존의 구성 기법을 사용하는 경우 문제가 발생합니다. 기존 관리에서는 빌드 프로세스 중에 잘못된 구성과 기타 문제를 식별하고 제거하는 대신, 런타임까지 이러한 문제가 파악되지 않은 채로 남아있을 수 있습니다. 개발자 자원을 재할당하여 런타임 시 이러한 문제를 해결해야 하기 때문에, 조직은 핵심적인 결함을 실질적으로 해결하지 않고 다른 중요한 작업에서 숙련된 전문가를 차출할 수밖에 없습니다.
또한 새롭게 구성된 인프라는 조직의 기존 환경에 통합될 수 있어야 합니다. 특히 엔터티가 동적이고 끊임없이 변화하는 상황에서는 광범위한 환경에서 수작업 구성으로 인해 보안 및 규정 준수 문제가 발생할 수 있습니다.
효과적인 IaC는 기존의 인프라 구성에 관련한 수많은 문제와 비효율성에 대한 해결책을 제공합니다. 조직이 IaC를 통해 얻을 수 있는 장점은 다음과 같습니다.
IaC를 사용하면 스크립트를 실행하는 것만으로 완전한 인프라를 간단하고 빠르게 구축할 수 있습니다. 이는 환경에 상관없이 소프트웨어 개발 수명주기의 모든 단계에 걸쳐 가능합니다.
IT 직원과 운영 팀이 직접 구성을 담당하는 경우에는 불일치가 발생할 수밖에 없습니다. 하지만 IaC 파일이 정보의 기본 소스인 경우에는 조직이 데이터 관리 도구 및 정책을 추가하여 필요할 때마다 여러 번 적합한 구성을 지속적으로 배포할 수 있습니다.
IaC 파일의 장점인 모든 변경 사항에 대한 명확한 기록을 유지관리한다는 점은 종종 간과되기도 합니다. 누가(책임 소재가 문제가 되는 경우) 언제 어떤 변경 사항을 적용했는지 손쉽게 검토할 수 있습니다. 그리고 IaC는 액세스 가능한 리포지토리에서 이전 버전을 유지관리하므로 문제가 발생하는 경우 개발자가 이전 인스턴스로 돌아가 이전 환경을 재배포할 수 있습니다.
조직은 인프라 아키텍처 배포를 코드화하고 자동화하여 개발 수명주기 전체에 걸쳐 효율성과 생산성을 크게 향상할 수 있습니다. 테스트는 여러 스테이징 환경에서 동시에 발생할 수 있으며, 이러한 스테이징 환경은 몇 분만에 생성되고 배포될 수 있습니다. 또한 IaC를 통해 지속적 통합 및 지속적 배포 기법을 손쉽게 적용할 수 있습니다.
IaC의 모든 장점 중에서도 가장 큰 장점은 비용 절감과 수익 증대일 것입니다. 조직은 구성 및 배포를 자동화하여 하드웨어, 인사, 교육, 관리에 관련한 다양한 비용을 절감함과 동시에 숙련된 IT 인력이 보다 큰 가치를 창출하는 작업에 에너지를 다시 집중할 수 있습니다.
여기에 앞서 언급된 속도, 일관성, 효율성이 더해져 IaC 투자에 대한 수익이 매우 빠르게 발생하게 됩니다.
IaC는 DevOps가 소스 코드에 사용하는 것과 동일한 버전 관리를 사용합니다. 실제로 DevOps는 IaC를 DevOps 툴체인의 다른 코드 개발과 마찬가지로 취급합니다. 따라서 모든 인프라 코드 변경 사항은 나머지 DevOps 작업과 함께 관리됩니다.
또한 DevOps는 IaC 변경에 정책을 적용하고 자동화된 변경에 ServiceNow DevOps를 사용하는 등의 방식으로 변경 추적 및 승인을 자동화할 수 있습니다. 그리고 DevOps는 IaC를 통해 개발 주기의 모든 단계에서 프로덕션이 동일한 테스트 환경을 손쉽게 구축할 수 있어 잠재적으로 중대한 배포 문제가 발생할 가능성을 낮춥니다. DevOps는 IaC를 통해 일관된 관행과 도구를 사용하여 효과적으로 조율하고, 빠르고 안정적으로 수요를 충족하기 위해 확장할 수 있는 애플리케이션과 인프라를 제공할 수 있습니다.
CI/CD 프로세스에서 IaC 제어 권한은 IT 운영 팀에서 개발자로 이동합니다. 이로 인해 DevOps 팀이 인프라 변경을 코드의 다른 부분과 동일한 방식으로 처리하고 DevOps 및 SRE(Site Reliability Engineering) 도구 및 제품을 사용하여 전체 가치 흐름에 감독 기능을 제공할 수 있습니다.
IaC 전략을 최대한 활용하려면 베스트 프랙티스를 파악하고 이에 따라야 합니다. 이러한 검증된 사례를 통해 구성 및 배포에 대한 효과적인 IaC 접근 방식을 활용할 수 있습니다.
인프라 사양에 대한 외부 문서는 명확하지 않으며 파악하기가 쉽지 않습니다. 외부 문서를 사용하는 습관을 버리고, 대신 항상 정확하고 액세스하기 쉬운 구성 파일 자체에 대한 코드 사양을 활용하십시오.
이전 항목에서 언급된 바와 같이, 외부 문서를 사용하는 것보다 인프라 사양을 구성 파일로 코딩하는 것이 바람직합니다. 사양의 코딩이 완료되면 구성 파일을 인프라 관리에 관련한 모든 정보에 대한 단일 소스로 참조해야 합니다.
물리적 구성에 비해 코드가 가지는 이점 중 하나는 테스트가 가능하다는 점입니다. IaC 테스트 도구를 사용하여 구성이 프로덕션으로 진행되기 전에 구성에 오류와 비일관성이 없도록 할 수 있습니다.
IaC는 개발에 대한 CI/CD 접근 방식에 매우 적합하기 때문에 엄청난 속도로 진행될 수 있습니다. 새로운 변경이 배포되면 소스 통제를 사용하여 이전 버전이 안전하게 사용할 수 있는 상태로 보관됩니다. 따라서 새로운 배포로 인해 예상치 못한 문제가 발생하는 경우 이전 버전을 다시 검토하여 로드할 수 있습니다.
앞서 언급된 바와 같이, 잘못된 구성은 인프라의 주요 당면 과제 중 하나입니다. 이로 인해 보안 문제, 개인정보 노출, 수백만 명의 사용자에게 영향을 주는 대규모 시스템 중단이 발생할 수 있습니다.
2020년 ServiceNow는 Sweagle이라는 회사를 인수했고, Sweagle은 현재 DevOps Config라는 이름으로 DevOps 포트폴리오에 편입되었습니다. DevOps Config를 통해 구성 데이터를 한곳에서 관리할 수 있습니다. 이에 따라 DevOps에서 IaC 사용 시 남아 있는 문제가 해결됩니다. 예를 들면 다음과 같습니다.
- 구성 데이터에 액세스 통제를 적용하여 승인된 사용자에게만 변경 사항을 적용하고 IaC에서 사용할 구성 파일을 정의할 수 있는 권한을 부여할 수 있습니다. 이를 통해 비밀번호 및 기타 중요 데이터를 보호하고 독립 실행형 구성 도구에서 발생할 수 있는 변경을 방지할 수 있습니다.
- 구성 정보에 정책을 적용할 수 있습니다. 예를 들면 여러 데이터베이스를 프로덕션에서 사용하는 대신 애플리케이션 테스트에 사용하는 것이 일반적입니다. 정책을 통해 내부 테스트와 프로덕션으로의 릴리스 사이에 데이터베이스 구성 문자열이 IaC에서 정확히 변경되었는지 확인할 수 있습니다.
- 시스템은 문제로 인해 구축된 이전 구성으로부터 학습할 수 있습니다. 인공 지능과 머신 러닝을 사용하여 문제가 재발하지 않도록 하는 새로운 정책을 작성할 수 있습니다.
- 인프라 구성을 한곳에서 관리하면 단일 리포지토리로 인해 가능한 감독 기능을 사용할 수 있습니다. Git 코드 리포지토리, 네트워크 구성 도구, 기타 소스를 들여다보지 않아도 구성을 이해할 수 있습니다. 모두 한곳에 있기 때문입니다. 향후 문제 해결을 지원하기 위해 이전 구성 버전의 스냅샷을 보관하는 기능도 포함됩니다.
DevOps의 성공을 전사적으로 확장합니다. 앞서 가는 것에 따른 위험 요소를 없애고 IT 운영과 개발 사이의 마찰을 최소화합니다.