“클라우드 시대 서버 관리에 필수” 코드형 인프라의 이해

InfoWorld
서버 프로비저닝과 환경 설정을 해본 사람이라면 그 고충을 잘 안다. 하드웨어 연결, 소프트웨어 스택, 상호종속성을 구성하기 위한 과정을 생각해 보라. 게다가 배포하는 서버 수만큼 그 과정이 반복된다. 지루한 작업이 며칠이고 계속된다.

반복적인 작업에는 보통 스크립트가 해결책이 되지만 한계가 있다. 스크립트는 대부분 선형적인 if-then 문으로 구성되므로 애플리케이션 코드가 가진 강점과 기능성을 제공하지 못한다.

그래서 등장한 것이 코드형 인프라(infrastructure as code, 이하 IAC)다. IAC는 프로그래밍 가능한 인프라 또는 소프트웨어 정의 인프라(SDI)로 지칭되기도 하며, 스크립팅에 비해 제어 범위가 넓고 훨씬 더 많은 부분에서 자동화할 수 있는, 하드웨어부터 소프트웨어 계층에 이르기까지 기술 스택을 자동으로 관리하고 프로비전하기 위한 IT 구성의 한 형태다.
 
ⓒGettyImagesBank


코드형 인프라(IAC)의 정의

오픈소스 구성 관리 업체인 퍼펫(Puppet)의 아키텍처 부사장 나이젤 커스텐은 “IAC를 가장 간단히 정의하면 인프라를 마치 소프트웨어처럼 취급할 수 있게 되는 것”이라면서 “가상 API, IaaS, 클라우드 리소스 프로비저닝, 프로비저닝 프로세스를 시작하도록 하드웨어에 프로그램으로 지시하기 등이 모두 IAC”라고 설명했다.

엔지니어는 IAC를 통해 “코드”(일반적으로 고수준 스크립팅 또는 프로그래밍 언어)를 사용해서 모든 애플리케이션 또는 서비스를 위한 인프라 설정을 프로그램할 수 있다. 이를 통해 승인된 모든 사용자는 사전 정의되고 반복 가능한, 알려진 프로세스를 실행해서 매번 같은 방식으로, 인간이 아닌 기계의 속도로 IT 인프라를 자동으로 빌드/리빌드할 수 있다.

관리 및 컴플라이언스 모니터링 소프트웨어 업체인 스플렁크(Splunk)의 최고 기술 지지자인 앤디 맨은 “소프트웨어 개발자와 프로덕션 엔지니어는 코드를 사용해서 애플리케이션을 빌드할 수 있을 뿐만 아니라, 이 애플리케이션이 실행되는 시스템도 빌드할 수 있다”고 말했다.

스크립트는 다음과 같은 몇 가지 이유로 인프라 및 구성 관리에서는 효과가 떨어진다.

- 스크립트는 할 수 있는 일이 제한적이다. 주로 일련의 if-then 문으로 구성되므로 실제 코드와 같은 다양한 기능을 할 수 없다.
- 체크인/체크아웃, 리비전, 롤백, 테스트, 배포 등이 있는 구조적 코딩 프로젝트에 비해 스크립트 작성은 느슨하고 약식으로 수행되는 경우가 많다.
- 스크립트에는 보통 말하는 멱등성(idempotence)이 없다. 멱등성이란 스크립트를 여러 번 실행할 때 매번 동일한 결과를 얻는 것을 의미한다. 대부분의 스크립트는 이 점을 보장할 수 없다.

시스템을 설정하고 연결을 구성하는 것 외에 IAC는 인증 정보의 설정도 다룬다. 새 시스템이 온라인 상태가 되면 마스터 인증 정보가 비활성화되고 액티브 디렉토리(Active Directory)와 같은 회사의 신뢰된 인증 정보로 변환된다.

기존 접근 방식에서는 담당 직원이 마스터 인증 정보를 사용해 로그인해서 비공개 인증 정보를 추가하고 마스터 인증 정보를 비활성화한 다음 로그아웃해야 한다. IAC 시스템에서는 유틸리티가 신뢰된 시스템과 통신해서 새 시스템을 사용할 수 있음을 알리며 신뢰된 시스템은 신뢰 인증 정보를 자동으로 설정하기 위한 모든 프로세스를 진행한다.
 

구성 관리 대 코드형 인프라(IAC)

일부 초기 구성 관리 제품은 IAC를 포함하도록 업데이트됐다. 퍼펫, 셰프(Chef), 솔트스택(SaltStack), CFengine이 여기에 포함된다. 모두 공유 클라우드 컴퓨팅 플랫폼에서 자동화된 코드 프로비저닝을 관리할 수 있게 해준다. 그러나 IAC는 그보다 한 걸음 더 나간다.

업체마다 동일한 구성요소에 대해 다른 명칭을 사용하기 때문에 다소 혼란스러울 수 있다. 예를 들어 퍼펫은 IAC 스크립트를 매니페스트라고 하고, 셰프에서는 레시피와 쿡북이라고 한다. 그러나 이름은 달라도 기능은 똑같이 코드 명령을 저장하는 것이다.
 

코드형 인프라(IAC)의 이점

IAC는 모든 조직과 모든 IT 팀에 도움이 되지만 클라우드 컴퓨팅, 애자일 개발, 데브옵스와 같이 더 기민한 새로운 IT 접근 방식을 활용하고자 하는 조직에 가장 적합하다.

IAC는 개발자 방법론과 원칙을 사용하므로 대안인 스크립팅에 비해 더 코드의 품질이 높다. 일반적으로 스크립트는 누구든 그 시점에 시간이 있는 사람이 작성하므로 유지관리가 철저하지 않다.

IAC 코드는 개발, 테스트, 품질 보증, 스테이징, 릴리스까지 애플리케이션 코드와 동일한 사이클을 거친다. 개발 중 더 엄격한 품질 관리가 적용되며 사전 정의된 “정상 작동하는 것으로 이미 알려진” 프로비전 프로세스, 수작업 또는 대역 외 변경을 되돌리기 위한 상태 제어 기능 등을 제공한다. IAC는 프로덕션의 잘못 구성된 인프라로 인해 발생하는 문제를 줄이는 데 도움이 되며, 코드에 문제가 있는 경우 “알려진 정상” 상태로 롤백할 수 있다.

그러나 IAC의 이점을 얻기 위해 꼭 이와 같은 새로운 접근 방식을 도입할 필요는 없다. 비교적 단순한 온프레미스 서버 구축에서도 명확한 이점을 제공하기 때문이다. IAC의 이점은 온프레미스, 클라우드, 그리고 빠르게 증가 중인 에지 컴퓨팅에서 하드웨어를 신속하게 배포하는 데 있다. 많은 IT 조직 관점에서 이 접근 방법은 아직도 새로운 개념이다.

에지 컴퓨팅용 가상화 및 오케스트레이션 소프트웨어 개발업체인 제디다(Zededa)의 제품 및 전략 담당 부사장 로만 샤포슈닉은 “90년대 방식에 묶여 있는 프로세스가 많다. 고객은 보유 중인 인프라가 지원하지 않는다는 이유로 클라우드 네이티브 개발을 도입하지 못한다. 우리는 고객에게 SDI의 기본 사항을 교육하면서 정적으로 정의된 인프라가 지극히 자연스럽게 확장된 것이라고 설명하지만 많은 고객이 그것조차 가지고 있지 않다”면서 “고객의 문제는 ‘어떻게 변경을 안정적으로 추진할 것인가?’에 있다. 개발에는 단위 테스트가 있다. 통과하거나 실패하거나 둘 중 하나다. 전통적인 SDI에는 현재 이와 같은 요소가 없다. IAC는 이러한 기술 중 일부를 활용할 수 있게 해준다”고 말했다.


이전 방법 대비 IAC의 가장 중요한 이점은 하드웨어 프로비저닝과 배포, 그리고 유지보수에도 적용되는 빠른 속도와 민첩성이다. 스토리지 및 스위치에 서버 연결하기와 같은 일상적인 프로세스를 자동화함으로써 IT 팀은 여유 시간을 확보해 다른 작업에 투자할 수 있다.

하드웨어 구성은 여전히 다른 기술에 비해 뒤처져 있으므로 IAC 도입에 따른 혜택도 그만큼 크다. 베어메탈 클라우드 구성 자동화를 전문으로 하는 신생 업체인 RackN의 CEO 롭 허쉬펠드는 주요 하드웨어 업체들이 운영에는 큰 가치를 두고 있지 않다면서 “우리가 전파하는 IAC의 핵심 이점은 인프라를 더 동적으로, 유연하게 해주고 지속적인 업데이트와 최신 상태로 패치할 수 있게 해준다는 점이다. 보통 생각과 달리 사람들은 꼭 필요한 경우가 아니면 서버를 패치하지 않는다”고 말했다.

많은 데이터센터에는 그 대신 담당자가 인쇄된 지침에 따라 작업한다. 허쉬펠드는 “대부분의 데이터센터는 여전히 이와 같은 실정이다. 담당자 한 명이 시스템이 올바르게 구성되는지 확인하고 업체 툴이나 자체 스크립트를 실행한다. 그 다음 이런 여러 조각을 합쳐서 앤서블(Ansible)과 같은 또 다른 자동화 툴로 넘겨 작업을 마친다”고 설명했다.

퍼펫의 커스텐은 IAC가 클라우드로의 이전에서 더욱 중요하다면서 “IAC 접근 방식은 온프레미스 환경에서는 선택이지만 클라우드 환경에서는 필수다. 애초에 하드웨어가 없어 모든 것을 소프트웨어로 취급해야 하기 때문이다. 소프트웨어를 빌드하고 이를 배포할 방법을 찾는 한 IAC는 유효하다”고 말했다.

제디다의 샤포슈니크는 특히 멀티클라우드 환경에서는 더욱 그렇다면서 “작은 회사라면 단일 클라우드로 충분하지만 큰 회사는 멀티클라우드로 가야 한다. 소프트웨어 정의 API는 클라우드마다 다르다. IAC는 기반 클라우드의 이와 같은 이질성으로부터 추상화하기 위한 최선의 방법”이라고 말했다.
 

코드형 인프라(IAC) 툴

IAC 툴은 구성 오케스트레이션과 구성 관리, 두 가지 범주로 분류된다. 시중에는 상용과 오픈소스를 불문하고 두 가지 기능을 모두 제공하는 제품이 많이 나와 있다.

구성 오케스트레이션 툴에는 AWS 클라우드포메이션(CloudFormation)과 테라폼(Terraform)이 있다. 서버 및 기타 인프라 배포를 자동화하는 기능을 제공한다. PXE의 업데이트된 버전이라고 생각하면 된다.

셰프, 퍼펫과 같은 구성 관리 툴은 프로비전된 시스템에서 소프트웨어와 시스템을 구성하는 데 사용된다.

툴을 선택할 때는 그 대상이 되는 환경을 고려해야 한다. 예를 들어 AWS 클라우드포메이션은 아마존 웹 서비스의 인프라만 프로비저닝하고 관리하도록 설계됐다. 당연한 일이지만, AWS가 구글 클라우드 플랫폼을 지원할 이유가 없다. 물론 그렇지 않은 경우도 있어서, 레드햇의 앤서블은 레드햇 엔터프라이즈 리눅스뿐만 아니라 다른 다양한 플랫폼에서도 실행된다.

퍼펫, 셰프와 같은 서드파티 툴은 온프레미스 서버와 여러 클라우드 업체의 IaaS에서 작동한다. 클라우드에 초점을 두는 테라폼은 클라우드를 가리지 않으므로 여러 클라우드 서비스 업체의 인프라 스택을 동시에 자동화하고 다른 서드파티 서비스를 통합할 수 있게 해준다.

각 툴에는 자체 도메인 특화 언어(Domain Specific Language, DSL)가 있지만, DSL은 일반적으로 YAML이나 JSON을 기반으로 한다. 예를 들어 테라폼은 해시코프 구성 언어(Hashicorp Configuration Language, HCL)라는 JSON 기반의 자체 DSL을 사용한다. AWS 클라우드포메이션 템플릿은 YAML과 JSON으로 만들 수 있다. 셰프와 퍼펫은 루비 언어를 사용한다.

대부분의 개발자는 다른 사람의 작업을 보면서 학습하므로 많은 IAC 업체는 자체 저장소를 통해 샘플 패턴/레시피/블루프린트를 제공한다. 예를 들어 퍼펫은 퍼펫 포지(Puppet Forge)라는 저장소를 통해 IAC 코드 샘플을 제공하고 개발자가 각자의 작업을 공유할 수 있도록 한다. 여기에는 SQL 서버 데이터베이스 또는 아파치 서버를 구성하고 관리하는 방법 등이 있다.  editor@itworld.co.kr