2019.03.12

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

Andy Patrizio | 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는 이러한 기술 중 일부를 활용할 수 있게 해준다”고 말했다.




2019.03.12

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

Andy Patrizio | 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는 이러한 기술 중 일부를 활용할 수 있게 해준다”고 말했다.


X