2016.11.01

데브옵스 구현 파트너 IaC를 구성하는 3가지 요소

BrandPost Sponsored by HPE
Gary Thome | HPE

사진: Flickr

배치 사이클을 자동화하는 통합 API, 소프트웨어 정의 인텔리전스, 리소스 풀이 있어야만 IaC는 '마법'을 부릴 수 있습니다.

데브옵스(DevOps)는 하드웨어 중심의 수작업 프로세스가 아닌 코드를 통해 자동으로 물리 인프라를 프로비저닝하고 관리는 데 목적이 있습니다. 실제로 IaC 역량을 구현하기까지 많은 도전 과제에 직면할 수 있습니다.

개발 주기 단축 및 단순화, 그리고 아주 최근까지 불가능했던 방식으로 기업의 비즈니스를 가속화할 수 있는 3가지 원칙을 소개합니다.

IaC가 필요한 이유
IaC가 데브옵스의 중요한 아젠다로 급부상한 이유는 명확합니다. 그동안 개발자들은 소프트웨어 제품을 만든 후, 이를 IT 운영 팀에 인계하고, IT 운영팀이 이를 운영할 인프라를 구축하는 방식을 따랐습니다. 그런데 하드웨어가 개발자 팀이 이용한 인프라와 크게 다른 경우도 있었고, 기대한 성과를 전달하지 못하는 경우도 있었습니다.

또 인프라를 신속하게 프로비저닝하는 것도 어려웠습니다. 비즈니스 케이스를 수립한 후 승인을 받고, 하드웨어를 선정해 조달해야 했는데, 최소 몇 주, 심지어는 몇 달이 소요될 수도 있는 프로세스였습니다.

소프트웨어 팀이 자동화된 개발 및 테스트 프로세스를 더 많이 구현하기 시작한 이유가 여기에 있습니다. 자동화된 개발 및 테스트 프로세스는 개별적인 코드 모듈을 따로 실행한 후, 더 큰 코드 기반에서 시스템 전반에 걸쳐 테스트를 할 수 있습니다.

개발자의 관점에서 시스템 테스트에서 프로덕션 환경으로의 이동은 제품 릴리즈 프로세스 사슬의 다음 단계에 불과합니다. 코드에 대한 신뢰도가 높아지면, 다음 단계로 이동한 후 최종적으로 프로덕션 단계로 옮길 수 있습니다. 이는 하나의 연속된 프로세스이므로, 인프라를 할당하는 시점에 문제가 발생하지 않아야 합니다.

데브옵스 팀 담당자는 인프라의 작동 방식에 대해 개발자보다 더 많은 지식을 갖고 있습니다. 최소한 더 많은 지식을 갖추고자 합니다. 데브옵스 조직의 개발 부문은 인프라의 출처를 신경 쓰지 않고, 필요할 때 이용할 수 있으면 됩니다. 또한, 개발자는 유연해서 변경하기 쉬운 인프라를 원합니다. 간단히 말해, 자신들이 개발한 애플리케이션 소프트웨어와 비슷한 방식으로 배포, 구성, 관리할 수 있는 인프라 계층을 원하는 것입니다.

클라우드를 이용하면 안되는 이유
많은 개발자가 퍼블릭 클라우드를 선호합니다. 아주 빨리, 그리고 실용적으로 인프라에 액세스할 수 있기 때문입니다. 글로벌 고객들이 액세스할 맞춤형 온라인 애플리케이션을 구축한다면, 클라우드 기반 IaaS를 선택하는 것이 당연한 선택입니다. 테스트와 변경도 쉽고, 이후 자동으로 배포할 수도 있습니다.

그러나 단점도 있습니다. 클라우드가 새로운 사일로가 된다는 점입니다. 사용하는 클라우드가 증가할 수록 생성되는 사일로도 증가합니다. 이렇게 각기 다른 클라우드에 적용된 애플리케이션은 엔터프라이즈 데이터센터에서 실행되는 앱과 달리 고유한 방식으로 관리해야 합니다. 이런 여러 갈래의 접근 방법은 조직 내부에 마찰을 불러올 수 있습니다. 새로운 클라우드 기반 앱을 지원하는 팀과 기존 인프라와 애플리케이션을 중시하는 팀을 갈라놓기 때문입니다.

개발(Dev) 팀과 운영(Ops) 팀에는 두 IT 모두를 포괄하고, 동일한 방식으로 관리할 수 있는 단일 인프라가 필요합니다. 동일한 팀과 동일한 도구를 사용하면, 새로운 사일로 생성과 관리를 걱정할 필요가 없습니다. IaC에는 프로그래밍 용이성과 클라우드의 속도 모두를 지원하는 온프레미스 인프라가 필요합니다.

IaC의 3대 구성요소
IaC에는 데이터센터 시스템을 애플리케이션을 실행할 수 있는 더 큰 시스템으로 탈바꿈하는 여러 기능이 통합되어 있습니다. IaC의 3대 구성요소는 컴포저블 인프라(Composable Infrastructure)로 불리는 새로운 IT 카테고리를 정의합니다.

1. 컴퓨팅, 스토리지, 네트워크 패브릭의 유동적인 리소스 풀
개발 환경에서는 인프라가 소프트웨어 관점에서 필요한 것과 일치하는지 알아야 합니다. 얼마나 많은 컴퓨팅과 스토리지가 필요한지, 어떤 네트워크를 연결해야 할지 등의 요소들이 구현되어 있고 준비된 인프라가 필요합니다. 서버 한 대를 프로비저닝하기 위해 수만 줄의 코드를 작성해야 하거나 환경 설정 때문에 골치를 앓아서는 곤란합니다.

인프라는 워크로드의 요구사항이 바뀔 때마다 조립하고 또 재조립할 수 있는 유연한 빌딩 블록이 되어야 합니다. 물리 서버와 가상 서버, 그리고 컨테이너 기반 워크로드의 용량은 특정 애플리케이션과 서비스의 요구사항을 지원하기 위해 지속적으로 통합, 해체, 재통합할 수 있어야 합니다. 데이터 스토리지 자원은 애플리케이션 요구사항을 기준으로 블록과 파일, 객체 수준에서 정의할 수 있어야 하고, 여러 프로토콜에 대해 동적으로 대역폭을 할당할 수 있어야 합니다.
이런 접근 방식의 이점 중 하나는 컴퓨팅과 스토리지, 네트워킹을 유동적이고 해체된 리소스 풀로 취급해 오버프로비저닝과 사용 불가 용량을 줄일 수 있다는 것입니다. 물론 자본 비용도 절감할 수 있습니다. 리소스가 더 이상 필요없게 되면, 리소스 풀로 반환해 다른 애플리케이션에 할당할 수 있습니다.

2. 소프트웨어 정의 인텔리전스
인프라 내의 네이티브 소프트웨어 정의 인텔리전스는 리소스를 구성하고 재구성해 애플리케이션 요구사항을 만족시킵니다. 반복해 사용할 수 있는 템플릿으로 리소스를 상태 정보(BIOS 설정, 펌웨어, 프로토콜 등), 운영체제 이미지와 함께 프로비저닝해 즉각적으로 논리 인프라를 생성합니다.

개발 팀과 운영 팀은 적절한 템플릿을 개발하기 위해 서로 협력합니다. IT 운영 팀은 물리 인프라의 작동 방식을 자세히 이해하고 있습니다. 탬플릿은 운영 팀이 지식을 추출하도록 도와 주며, 개발자가 할 일은 애플리케이션에 리소스를 프로비저닝할 수 있는 탬플릿을 선택하는 것뿐입니다.

개발자는 시스템 연결을 걱정하지 않고, 원하는 펌웨어 버전, 앱을 연결할 네트워크, 로드할 운영체제를 지정할 수 있습니다. 구성 변경 작업은 극히 단순화되어 수작업과 인적 오류를 줄여줍니다. 또 단일화된 관리 인터페이스를 제공하기 때문에 여러 가지 툴이 필요하지 않습니다.

3. 자동화된 인프라 배포를 지원하는 단일화된 통합 API
유동적인 리소스가 IaaS와 유사한 기능을 제공하기 때문에, 필요한 작업은 프로덕션 환경에서 워크로드를 실행하는 데 필요한 컴퓨팅 용량과 네트워크 연결, 스토리지 리소스를 요청하는 코드 한 줄을 작성하는 것뿐입니다. 그러면 이 지원은 런타임에 동적으로 할당됩니다. 이런 통합 API는 개발자들이 저수준 툴이나 인터페이스와 관련된 스크립트를 작성하는 데 시간을 낭비하지 않도록 해주며, 이를 관리할 수 있도록 만들어 줍니다. 인텔리전스 소프트웨어가 세부 작업을 처리해 애플리케이션에 필요한 컴퓨팅과 스토리지, 네트워킹 용량을 정확하게 전달합니다.

API는 가상 리소스 및 컨테이너 기반 리소스와 동일한 방식으로 물리 리소스를 처리합니다. 따라서 개발자는 기반 인프라에 대해 세부적으로 알 필요가 없습니다. 컴포저블 인프라의 API는 REST 기반이며, 자바와 파이썬 등 많이 사용되는 언어를 지원해 개발자가 이들 언어를 이용해 직접 액세스를 할 수 있습니다. 또 API를 Chef 및 Ansible 같은 도구와 쉽게 통합할 수 있어 개발자는 이미 애플리케이션을 배치하고 이를 인프라와 연계하는 방법을 알고 있는 익숙한 데브옵스 툴을 계속 사용할 수 있습니다.

IaC로 할 수 있는 일
IaC의 컴포저블 방식은 데브옵스 팀이 더 많은 일을 효율적으로 처리할 수 있도록 도와 줍니다. 대표적인 역할은 다음과 같습니다.

- 2개의 환경이 필요 없습니다. 데브옵스 방법론을 활용, 새로운 IT 스타일의 모바일과 클라우드 네이티브 애플리케이션을 생성할 수 있습니다. 또 기존 앱에 사용한 것과 동일한 환경에 이를 직접 불러올 수 있습니다. 개발 팀에게 이것은 IT 운영 팀이 지속적으로 새 애플리케이션을 관리할 수 있다는 의미입니다. 개발자는 새로운 코드 개발 및 배치에 관심을 기울이지, 애플리케이션 유지관리, 시스템 운영, 기반 인프라에는 관심이 없습니다. IT가 클라우드에서 실행되는 앱을 지원하지 못할 경우, 개발자가 운영을 책임져야 합니다. 이는 개발자의 강점이 아닙니다. IaC는 데브옵스 팀에 필요한 지속적인 개발 프로세스를 지원하고, IT가 애플리케이션을 계속 지원할 수 있는 방법을 제공합니다.

- 배포 주기를 단축합니다. 데브옵스 부서는 애플리케이션의 리소스 요구사항을 특정해 신속하게 인프라를 할당할 수 있는 실용적인 인터페이스로 앱을 더 빨리 개발해 배치할 수 있습니다.

- 일상적인 관리 및 업데이트 작업을 단순화합니다. 컴포저블 인프라와 IaC를 이용하면 펌웨어 업데이트, 스토리지 추가, 네트워크 연결 수정 작업 등 일상 작업을 자동화할 수 있습니다. 소프트웨어 개발 프로젝트의 경우, 리소스 요구사항이 바뀔 때 일상적인 구현 작업을 단축할 수 있습니다. 하드웨어 구성을 애플리케이션 코드와 동일한 저장소에 저장하는 소프트웨어 탬플릿으로 유지됩니다.

데브옵스 팀은 데이터센터에서 실행되는 인프라를 신경 쓰지 않습니다. 이들의 목표는 앱을 더 효율적으로 개발하고 실행해 비즈니스가 경쟁에서 앞서 나가도록 지원하는 것입니다. IaC는 데브옵스 팀이 필요한 인프라에 즉시 액세스할 수 있도록 합니다. 이를 통해 애플리케이션 개발을 앞당기고, 더 나은 사용자 경험을 전달하고, 더 빨리 시장에 시장에 진출할 수 있습니다.

*이 글은 TechBeacon에 게시된 글입니다.


2016.11.01

데브옵스 구현 파트너 IaC를 구성하는 3가지 요소

BrandPost Sponsored by HPE
Gary Thome | HPE

사진: Flickr

배치 사이클을 자동화하는 통합 API, 소프트웨어 정의 인텔리전스, 리소스 풀이 있어야만 IaC는 '마법'을 부릴 수 있습니다.

데브옵스(DevOps)는 하드웨어 중심의 수작업 프로세스가 아닌 코드를 통해 자동으로 물리 인프라를 프로비저닝하고 관리는 데 목적이 있습니다. 실제로 IaC 역량을 구현하기까지 많은 도전 과제에 직면할 수 있습니다.

개발 주기 단축 및 단순화, 그리고 아주 최근까지 불가능했던 방식으로 기업의 비즈니스를 가속화할 수 있는 3가지 원칙을 소개합니다.

IaC가 필요한 이유
IaC가 데브옵스의 중요한 아젠다로 급부상한 이유는 명확합니다. 그동안 개발자들은 소프트웨어 제품을 만든 후, 이를 IT 운영 팀에 인계하고, IT 운영팀이 이를 운영할 인프라를 구축하는 방식을 따랐습니다. 그런데 하드웨어가 개발자 팀이 이용한 인프라와 크게 다른 경우도 있었고, 기대한 성과를 전달하지 못하는 경우도 있었습니다.

또 인프라를 신속하게 프로비저닝하는 것도 어려웠습니다. 비즈니스 케이스를 수립한 후 승인을 받고, 하드웨어를 선정해 조달해야 했는데, 최소 몇 주, 심지어는 몇 달이 소요될 수도 있는 프로세스였습니다.

소프트웨어 팀이 자동화된 개발 및 테스트 프로세스를 더 많이 구현하기 시작한 이유가 여기에 있습니다. 자동화된 개발 및 테스트 프로세스는 개별적인 코드 모듈을 따로 실행한 후, 더 큰 코드 기반에서 시스템 전반에 걸쳐 테스트를 할 수 있습니다.

개발자의 관점에서 시스템 테스트에서 프로덕션 환경으로의 이동은 제품 릴리즈 프로세스 사슬의 다음 단계에 불과합니다. 코드에 대한 신뢰도가 높아지면, 다음 단계로 이동한 후 최종적으로 프로덕션 단계로 옮길 수 있습니다. 이는 하나의 연속된 프로세스이므로, 인프라를 할당하는 시점에 문제가 발생하지 않아야 합니다.

데브옵스 팀 담당자는 인프라의 작동 방식에 대해 개발자보다 더 많은 지식을 갖고 있습니다. 최소한 더 많은 지식을 갖추고자 합니다. 데브옵스 조직의 개발 부문은 인프라의 출처를 신경 쓰지 않고, 필요할 때 이용할 수 있으면 됩니다. 또한, 개발자는 유연해서 변경하기 쉬운 인프라를 원합니다. 간단히 말해, 자신들이 개발한 애플리케이션 소프트웨어와 비슷한 방식으로 배포, 구성, 관리할 수 있는 인프라 계층을 원하는 것입니다.

클라우드를 이용하면 안되는 이유
많은 개발자가 퍼블릭 클라우드를 선호합니다. 아주 빨리, 그리고 실용적으로 인프라에 액세스할 수 있기 때문입니다. 글로벌 고객들이 액세스할 맞춤형 온라인 애플리케이션을 구축한다면, 클라우드 기반 IaaS를 선택하는 것이 당연한 선택입니다. 테스트와 변경도 쉽고, 이후 자동으로 배포할 수도 있습니다.

그러나 단점도 있습니다. 클라우드가 새로운 사일로가 된다는 점입니다. 사용하는 클라우드가 증가할 수록 생성되는 사일로도 증가합니다. 이렇게 각기 다른 클라우드에 적용된 애플리케이션은 엔터프라이즈 데이터센터에서 실행되는 앱과 달리 고유한 방식으로 관리해야 합니다. 이런 여러 갈래의 접근 방법은 조직 내부에 마찰을 불러올 수 있습니다. 새로운 클라우드 기반 앱을 지원하는 팀과 기존 인프라와 애플리케이션을 중시하는 팀을 갈라놓기 때문입니다.

개발(Dev) 팀과 운영(Ops) 팀에는 두 IT 모두를 포괄하고, 동일한 방식으로 관리할 수 있는 단일 인프라가 필요합니다. 동일한 팀과 동일한 도구를 사용하면, 새로운 사일로 생성과 관리를 걱정할 필요가 없습니다. IaC에는 프로그래밍 용이성과 클라우드의 속도 모두를 지원하는 온프레미스 인프라가 필요합니다.

IaC의 3대 구성요소
IaC에는 데이터센터 시스템을 애플리케이션을 실행할 수 있는 더 큰 시스템으로 탈바꿈하는 여러 기능이 통합되어 있습니다. IaC의 3대 구성요소는 컴포저블 인프라(Composable Infrastructure)로 불리는 새로운 IT 카테고리를 정의합니다.

1. 컴퓨팅, 스토리지, 네트워크 패브릭의 유동적인 리소스 풀
개발 환경에서는 인프라가 소프트웨어 관점에서 필요한 것과 일치하는지 알아야 합니다. 얼마나 많은 컴퓨팅과 스토리지가 필요한지, 어떤 네트워크를 연결해야 할지 등의 요소들이 구현되어 있고 준비된 인프라가 필요합니다. 서버 한 대를 프로비저닝하기 위해 수만 줄의 코드를 작성해야 하거나 환경 설정 때문에 골치를 앓아서는 곤란합니다.

인프라는 워크로드의 요구사항이 바뀔 때마다 조립하고 또 재조립할 수 있는 유연한 빌딩 블록이 되어야 합니다. 물리 서버와 가상 서버, 그리고 컨테이너 기반 워크로드의 용량은 특정 애플리케이션과 서비스의 요구사항을 지원하기 위해 지속적으로 통합, 해체, 재통합할 수 있어야 합니다. 데이터 스토리지 자원은 애플리케이션 요구사항을 기준으로 블록과 파일, 객체 수준에서 정의할 수 있어야 하고, 여러 프로토콜에 대해 동적으로 대역폭을 할당할 수 있어야 합니다.
이런 접근 방식의 이점 중 하나는 컴퓨팅과 스토리지, 네트워킹을 유동적이고 해체된 리소스 풀로 취급해 오버프로비저닝과 사용 불가 용량을 줄일 수 있다는 것입니다. 물론 자본 비용도 절감할 수 있습니다. 리소스가 더 이상 필요없게 되면, 리소스 풀로 반환해 다른 애플리케이션에 할당할 수 있습니다.

2. 소프트웨어 정의 인텔리전스
인프라 내의 네이티브 소프트웨어 정의 인텔리전스는 리소스를 구성하고 재구성해 애플리케이션 요구사항을 만족시킵니다. 반복해 사용할 수 있는 템플릿으로 리소스를 상태 정보(BIOS 설정, 펌웨어, 프로토콜 등), 운영체제 이미지와 함께 프로비저닝해 즉각적으로 논리 인프라를 생성합니다.

개발 팀과 운영 팀은 적절한 템플릿을 개발하기 위해 서로 협력합니다. IT 운영 팀은 물리 인프라의 작동 방식을 자세히 이해하고 있습니다. 탬플릿은 운영 팀이 지식을 추출하도록 도와 주며, 개발자가 할 일은 애플리케이션에 리소스를 프로비저닝할 수 있는 탬플릿을 선택하는 것뿐입니다.

개발자는 시스템 연결을 걱정하지 않고, 원하는 펌웨어 버전, 앱을 연결할 네트워크, 로드할 운영체제를 지정할 수 있습니다. 구성 변경 작업은 극히 단순화되어 수작업과 인적 오류를 줄여줍니다. 또 단일화된 관리 인터페이스를 제공하기 때문에 여러 가지 툴이 필요하지 않습니다.

3. 자동화된 인프라 배포를 지원하는 단일화된 통합 API
유동적인 리소스가 IaaS와 유사한 기능을 제공하기 때문에, 필요한 작업은 프로덕션 환경에서 워크로드를 실행하는 데 필요한 컴퓨팅 용량과 네트워크 연결, 스토리지 리소스를 요청하는 코드 한 줄을 작성하는 것뿐입니다. 그러면 이 지원은 런타임에 동적으로 할당됩니다. 이런 통합 API는 개발자들이 저수준 툴이나 인터페이스와 관련된 스크립트를 작성하는 데 시간을 낭비하지 않도록 해주며, 이를 관리할 수 있도록 만들어 줍니다. 인텔리전스 소프트웨어가 세부 작업을 처리해 애플리케이션에 필요한 컴퓨팅과 스토리지, 네트워킹 용량을 정확하게 전달합니다.

API는 가상 리소스 및 컨테이너 기반 리소스와 동일한 방식으로 물리 리소스를 처리합니다. 따라서 개발자는 기반 인프라에 대해 세부적으로 알 필요가 없습니다. 컴포저블 인프라의 API는 REST 기반이며, 자바와 파이썬 등 많이 사용되는 언어를 지원해 개발자가 이들 언어를 이용해 직접 액세스를 할 수 있습니다. 또 API를 Chef 및 Ansible 같은 도구와 쉽게 통합할 수 있어 개발자는 이미 애플리케이션을 배치하고 이를 인프라와 연계하는 방법을 알고 있는 익숙한 데브옵스 툴을 계속 사용할 수 있습니다.

IaC로 할 수 있는 일
IaC의 컴포저블 방식은 데브옵스 팀이 더 많은 일을 효율적으로 처리할 수 있도록 도와 줍니다. 대표적인 역할은 다음과 같습니다.

- 2개의 환경이 필요 없습니다. 데브옵스 방법론을 활용, 새로운 IT 스타일의 모바일과 클라우드 네이티브 애플리케이션을 생성할 수 있습니다. 또 기존 앱에 사용한 것과 동일한 환경에 이를 직접 불러올 수 있습니다. 개발 팀에게 이것은 IT 운영 팀이 지속적으로 새 애플리케이션을 관리할 수 있다는 의미입니다. 개발자는 새로운 코드 개발 및 배치에 관심을 기울이지, 애플리케이션 유지관리, 시스템 운영, 기반 인프라에는 관심이 없습니다. IT가 클라우드에서 실행되는 앱을 지원하지 못할 경우, 개발자가 운영을 책임져야 합니다. 이는 개발자의 강점이 아닙니다. IaC는 데브옵스 팀에 필요한 지속적인 개발 프로세스를 지원하고, IT가 애플리케이션을 계속 지원할 수 있는 방법을 제공합니다.

- 배포 주기를 단축합니다. 데브옵스 부서는 애플리케이션의 리소스 요구사항을 특정해 신속하게 인프라를 할당할 수 있는 실용적인 인터페이스로 앱을 더 빨리 개발해 배치할 수 있습니다.

- 일상적인 관리 및 업데이트 작업을 단순화합니다. 컴포저블 인프라와 IaC를 이용하면 펌웨어 업데이트, 스토리지 추가, 네트워크 연결 수정 작업 등 일상 작업을 자동화할 수 있습니다. 소프트웨어 개발 프로젝트의 경우, 리소스 요구사항이 바뀔 때 일상적인 구현 작업을 단축할 수 있습니다. 하드웨어 구성을 애플리케이션 코드와 동일한 저장소에 저장하는 소프트웨어 탬플릿으로 유지됩니다.

데브옵스 팀은 데이터센터에서 실행되는 인프라를 신경 쓰지 않습니다. 이들의 목표는 앱을 더 효율적으로 개발하고 실행해 비즈니스가 경쟁에서 앞서 나가도록 지원하는 것입니다. IaC는 데브옵스 팀이 필요한 인프라에 즉시 액세스할 수 있도록 합니다. 이를 통해 애플리케이션 개발을 앞당기고, 더 나은 사용자 경험을 전달하고, 더 빨리 시장에 시장에 진출할 수 있습니다.

*이 글은 TechBeacon에 게시된 글입니다.


X