2016.05.26

기고 | 재해복구에서도 빛을 발하는 '데브옵스'

Jonathan Hassell | CIO
데브옵스 방법론을 적용한 기업이 이를 통해 실질적인 이익을 확인하는 것으로 조사됐다.


Credit: Getty Images Bank

퍼펫 랩스(Puppet Labs)와 공동으로 IT 레볼루션 프레스(IT Revolution Press)가 진행한 2015 설문조사에 따르면, 데브옵스(DevOps)를 이용하는 기업이 그렇지 않은 기업보다 30배나 빠르게 코드를 배치하고 하루에도 몇 번씩 배치하는 것으로 나타났다. 또 데브옵스를 이용하는 경우 변화 실패율이 절반으로 줄었으며 서비스는 데브옵스를 사용하지 않는 조직보다 최대 168배나 빠르게 복구되었다.

데브옵스: 고장도 빠르지만 복구도 빠르다
일단 마지막 두 가지 사항에 초점을 맞추도록 하자. 한 가지는 확실하다. 데브옵스를 도입하면 재해복구의 관점에서도 이익이다. 왜냐하면 애플리케이션을 개발 단계에서 시험과 생산 단계로 이행했다가 다시 개발 단계로 복귀하기 위해 사용하는 툴과 절차가 시스템 대체 작동과 재난 및 서비스 중단 복구에도 적용될 수 있기 때문이다. 데브옵스의 라이프 사이클 전체를 자동화하는 툴이 이미 보유하고 있는 자원을 재해복구를 위해 활용하는 데 도움이 될 수 있다.

실제로 새로운 가상 머신 인스턴스(Instance)를 자동화된 방식으로 생성, 실행, 배치하고 적절하게 구성하는 쉐프(Chef)와 퍼펫(Puppet) 등 자동화에 도움이 되는 많은 오픈소스 툴이 존재한다.

심지어 보안 영역 외에서도 동작하며 개인용 노트북, 자체 데이터센터, 퍼블릭 클라우드 등에도 배치할 수 있다. AWS(Amazon Web Services)와 마이크로소프트 애저(Microsoft Azure)는 쉐프와 퍼펫을 지원하는 주요 퍼블릭 클라우드 제공업체다.

이런 툴을 이용해 개발자들이 자신의 개발 기기 환경과 구성의 복사본을 이용해 작성하는 새 코드의 배치를 자동화할 수 있을 뿐 아니라 수분 안에 클라우드에서 백업 환경을 조율하고 실행할 수도 있다.

VM웨어와 KVM 가상 배치를 위해 오라클 라벨라(Oracle Ravello, 퍼블릭 클라우드가 AWS 또는 구글인 경우) 같은 툴과 함께 퍼펫과 쉐프를 조합하면 말 그대로 하이퍼바이저를 확보해 변경사항 없이 자동화된 방식으로 배치된 네트워킹과 주소 설정 등을 통해 가상 환경을 퍼블릭 클라우드에서 있는 그대로 운용할 수 있다.

이런 툴들은 데브옵스와 재해복구의 관점에서도 실제로 강력하다 할 수 있다. 이런 툴을 이용해 소프트웨어를 신속하게 개발하고 시험 및 배치하며 버그를 줄이고 탄탄한 시스템 대체 작동 및 재난 솔루션을 제공할 수 있다. 지속적인 배치는 지속적인 재해복구가 된다.

코드가 작동하게 될 생산 환경의 사본에서 개발자가 코드를 작성하고 앱을 시험하는 것이 데브옵스의 원칙이다. 가상 머신이나 개별 노트북 또는 데스크톱에서 구동하는 도커(Docker) 등의 컨테이너(Container) 솔루션을 이용해 거의 달성할 수 있는 경우가 많다.

물론, 아무것도 모른 채 엑스코드(Xcode)나 비주얼 스튜디오에서 코드를 작성한 후 패키지를 시스템 관리자에 전송하여 배치하는 것보다는 낫지만 앞의 문자에서 ‘거의’라고 말한 이유는 이런 종류의 가상화라도 실제 생산 환경의 용량 한계를 완전히 시뮬레이션할 수 없기 때문이다.

예를 들어, 애플 맥북에어에서 구동하는 컨테이너화된 마이크로서비스로 실제 부하를 시험하기 어렵지만 완전한 애저 스택(Azure Stack) 서비스 배치에 대해 좀 더 현실적이고 실행 가능한 방식으로 부하 테스트를 할 수 있다.

잠재적인 데브옵스 작업공간으로써의 재해복구 환경
일부 기업들은 데브옵스를 더욱 심오한 수준으로 도입하면서 개발자들이 "단일 노트북 또는 데스크톱"의 한계를 완화하기 위해 활성화된 여분의 재해복구 환경에 대한 접근을 지속적으로 요청하는 때도 있다.

일반적으로 중대형 조직은 중요 생산 작업 부하로 동작하며 서비스이나 또는 재난 발생 시에 이런 작업 부하를 포팅해야 할 때 대기하는 환경의 거의 같은 사본인 백업 인프라에 대대적으로 투자한다.

요즘은 매년 일부 재난 연습을 제외하고는 거의 휴지 상태다. 하지만 이렇게 생각해 보자. 1년에 단 몇 시간 발생할 수 있는 사고에 대비해 상당한 역량을 낭비하는 것으로 볼 수 있다. 가상화 기술, 스토리지 영역 네트워킹, 소프트웨어 정의 네트워킹을 활용해 활성화된 여분의 재해복구 역량을 시스템 대체 작동 작업 부하를 수용하기 위해 본래의 목적에 맞춰 사용할 수 있으면서도 시험과 계획을 위한 데브옵스 ‘작업공간’으로 활용할 수는 있을까?

할 수 있다. 하이퍼바이저와 가상 머신은 수초 만에 켰다가 끌 수 있으며 소프트웨어 정의 네트워크는 자동화된 방식의 스크립트(Script)를 통해 다른 연결 및 종점으로 경로를 재설정하고 이동할 수 있다.

사실 대부분은 해당 환경에서 이미 데이터에 접근할 수 있으므로 정기적인 애플리케이션 및 운영 시험을 긴 복사 시간 없이 실제 데이터로 실시할 수 있다. 기본적으로 생산 인프라의 사본으로 작업하는 대신 더 나은 실질적인 성능 시험 환경을 요구할 수 있지는 않을까?

시스템 대체 작동이 필요한 경우 모니터링 시스템으로 이런 스크립트를 실행하고 스토리지 종점을 변경하며 가상 머신을 정지할 수 있으며, 이때 활성화된 여분의 지원을 확보하게 된다. ‘재난’이 끝나면 자동화된 스크립트로 인한 모든 변경사항을 되돌려 서비스를 수동으로 복원할 수 있다.

파워쉘(PowerShell)은 윈도우, 하이퍼-V(Hyper-V), VM웨어 환경에서 이를 실행할 수 있는 좋은 방법이며, 배시(Bash) 스크립트는 젠(Xen)과 다른 하이퍼바이저에도 괜찮은 편이다. 물론, 퍼펫과 쉐프 및 라벨로는 이런 종류의 조율에도 도움이 될 수 있다.

여기에서 핵심은 사용하지 않는 역량을 유용하게 활용하면서 처음에 수립한 그 존재의 목적을 완전히 잃지 않는 것이다. 개발자들은 개발 기기가 단독으로 지원할 수 있는 것보다 더 높은 역량과 부하로 실제 시험하고 성능 문제를 점검하기 위해 이런 도구에 접근할 수 있어야 한다.

아무 기능도 없이 활성화되고 대기하는 대기 인프라를 보유하는 것은 데브옵스 도입과 정반대의 개념이라 할 수 있다. 이런 애플리케이션을 보유함으로써 원한다면 언제든지 활용하는 것도 가능하다.

재해복구 고려사항
지속적인 재해복구에 관해 생각할 때 팀과 함께 고려해야 할 사항이 있다.

- 재해복구 절차를 어떻게 ‘수립’하는가?
- 준수할 절차 목록은 누가 소유하는가?
- 누가 스크립트를 실행하거나 자동화를 담당하는가?
- 단일 애플리케이션, 실제 작업 부하, 인프라 자체의 고장을 어떻게 시뮬레이션하는가?
- 이런 각 핵심 요소에서 어떤 유형의 시나리오가 고장을 유발하는가?
- 재해복구를 중심으로 직원이 타고 난 어떤 강점에 역점을 둘 수 있는가?

데브옵스는 개발자와 운영 인력의 역할을 혼동하는 경향이 있지만 운영에서 더욱 강력한 역량과 경험을 보유한 직원이 있을 수밖에 없으며, 이들에게 시스템 대체 작동에 필요한 책무를 다할 수 있는 권한을 부여해야 한다.

개발 측면에서 코드 작성자는 코드로 인해 시스템 장애가 발생할 때에 책임을 져야 하며 디버깅(Debugging)만 하고 싶은 코드 작성자는 여기에서 태만해진 태도를 바로 잡을 수도 있다.

이미 비용을 지불한 재해복구 사이트와 기존 인프라를 어떻게 더 잘 활용할 수 있을까? 이 환경은 간편한 가상화 구축과 해체를 위한 것일까? 그렇지 않다면 대비하기 위해 무엇을 해야 할까?

*Jonathan Hassell은 노스캐롤라이나에 있는 컨설팅 기업인 82벤처스(82 Ventures)를 운영하고 있다. ciokr@idg.co.kr


2016.05.26

기고 | 재해복구에서도 빛을 발하는 '데브옵스'

Jonathan Hassell | CIO
데브옵스 방법론을 적용한 기업이 이를 통해 실질적인 이익을 확인하는 것으로 조사됐다.


Credit: Getty Images Bank

퍼펫 랩스(Puppet Labs)와 공동으로 IT 레볼루션 프레스(IT Revolution Press)가 진행한 2015 설문조사에 따르면, 데브옵스(DevOps)를 이용하는 기업이 그렇지 않은 기업보다 30배나 빠르게 코드를 배치하고 하루에도 몇 번씩 배치하는 것으로 나타났다. 또 데브옵스를 이용하는 경우 변화 실패율이 절반으로 줄었으며 서비스는 데브옵스를 사용하지 않는 조직보다 최대 168배나 빠르게 복구되었다.

데브옵스: 고장도 빠르지만 복구도 빠르다
일단 마지막 두 가지 사항에 초점을 맞추도록 하자. 한 가지는 확실하다. 데브옵스를 도입하면 재해복구의 관점에서도 이익이다. 왜냐하면 애플리케이션을 개발 단계에서 시험과 생산 단계로 이행했다가 다시 개발 단계로 복귀하기 위해 사용하는 툴과 절차가 시스템 대체 작동과 재난 및 서비스 중단 복구에도 적용될 수 있기 때문이다. 데브옵스의 라이프 사이클 전체를 자동화하는 툴이 이미 보유하고 있는 자원을 재해복구를 위해 활용하는 데 도움이 될 수 있다.

실제로 새로운 가상 머신 인스턴스(Instance)를 자동화된 방식으로 생성, 실행, 배치하고 적절하게 구성하는 쉐프(Chef)와 퍼펫(Puppet) 등 자동화에 도움이 되는 많은 오픈소스 툴이 존재한다.

심지어 보안 영역 외에서도 동작하며 개인용 노트북, 자체 데이터센터, 퍼블릭 클라우드 등에도 배치할 수 있다. AWS(Amazon Web Services)와 마이크로소프트 애저(Microsoft Azure)는 쉐프와 퍼펫을 지원하는 주요 퍼블릭 클라우드 제공업체다.

이런 툴을 이용해 개발자들이 자신의 개발 기기 환경과 구성의 복사본을 이용해 작성하는 새 코드의 배치를 자동화할 수 있을 뿐 아니라 수분 안에 클라우드에서 백업 환경을 조율하고 실행할 수도 있다.

VM웨어와 KVM 가상 배치를 위해 오라클 라벨라(Oracle Ravello, 퍼블릭 클라우드가 AWS 또는 구글인 경우) 같은 툴과 함께 퍼펫과 쉐프를 조합하면 말 그대로 하이퍼바이저를 확보해 변경사항 없이 자동화된 방식으로 배치된 네트워킹과 주소 설정 등을 통해 가상 환경을 퍼블릭 클라우드에서 있는 그대로 운용할 수 있다.

이런 툴들은 데브옵스와 재해복구의 관점에서도 실제로 강력하다 할 수 있다. 이런 툴을 이용해 소프트웨어를 신속하게 개발하고 시험 및 배치하며 버그를 줄이고 탄탄한 시스템 대체 작동 및 재난 솔루션을 제공할 수 있다. 지속적인 배치는 지속적인 재해복구가 된다.

코드가 작동하게 될 생산 환경의 사본에서 개발자가 코드를 작성하고 앱을 시험하는 것이 데브옵스의 원칙이다. 가상 머신이나 개별 노트북 또는 데스크톱에서 구동하는 도커(Docker) 등의 컨테이너(Container) 솔루션을 이용해 거의 달성할 수 있는 경우가 많다.

물론, 아무것도 모른 채 엑스코드(Xcode)나 비주얼 스튜디오에서 코드를 작성한 후 패키지를 시스템 관리자에 전송하여 배치하는 것보다는 낫지만 앞의 문자에서 ‘거의’라고 말한 이유는 이런 종류의 가상화라도 실제 생산 환경의 용량 한계를 완전히 시뮬레이션할 수 없기 때문이다.

예를 들어, 애플 맥북에어에서 구동하는 컨테이너화된 마이크로서비스로 실제 부하를 시험하기 어렵지만 완전한 애저 스택(Azure Stack) 서비스 배치에 대해 좀 더 현실적이고 실행 가능한 방식으로 부하 테스트를 할 수 있다.

잠재적인 데브옵스 작업공간으로써의 재해복구 환경
일부 기업들은 데브옵스를 더욱 심오한 수준으로 도입하면서 개발자들이 "단일 노트북 또는 데스크톱"의 한계를 완화하기 위해 활성화된 여분의 재해복구 환경에 대한 접근을 지속적으로 요청하는 때도 있다.

일반적으로 중대형 조직은 중요 생산 작업 부하로 동작하며 서비스이나 또는 재난 발생 시에 이런 작업 부하를 포팅해야 할 때 대기하는 환경의 거의 같은 사본인 백업 인프라에 대대적으로 투자한다.

요즘은 매년 일부 재난 연습을 제외하고는 거의 휴지 상태다. 하지만 이렇게 생각해 보자. 1년에 단 몇 시간 발생할 수 있는 사고에 대비해 상당한 역량을 낭비하는 것으로 볼 수 있다. 가상화 기술, 스토리지 영역 네트워킹, 소프트웨어 정의 네트워킹을 활용해 활성화된 여분의 재해복구 역량을 시스템 대체 작동 작업 부하를 수용하기 위해 본래의 목적에 맞춰 사용할 수 있으면서도 시험과 계획을 위한 데브옵스 ‘작업공간’으로 활용할 수는 있을까?

할 수 있다. 하이퍼바이저와 가상 머신은 수초 만에 켰다가 끌 수 있으며 소프트웨어 정의 네트워크는 자동화된 방식의 스크립트(Script)를 통해 다른 연결 및 종점으로 경로를 재설정하고 이동할 수 있다.

사실 대부분은 해당 환경에서 이미 데이터에 접근할 수 있으므로 정기적인 애플리케이션 및 운영 시험을 긴 복사 시간 없이 실제 데이터로 실시할 수 있다. 기본적으로 생산 인프라의 사본으로 작업하는 대신 더 나은 실질적인 성능 시험 환경을 요구할 수 있지는 않을까?

시스템 대체 작동이 필요한 경우 모니터링 시스템으로 이런 스크립트를 실행하고 스토리지 종점을 변경하며 가상 머신을 정지할 수 있으며, 이때 활성화된 여분의 지원을 확보하게 된다. ‘재난’이 끝나면 자동화된 스크립트로 인한 모든 변경사항을 되돌려 서비스를 수동으로 복원할 수 있다.

파워쉘(PowerShell)은 윈도우, 하이퍼-V(Hyper-V), VM웨어 환경에서 이를 실행할 수 있는 좋은 방법이며, 배시(Bash) 스크립트는 젠(Xen)과 다른 하이퍼바이저에도 괜찮은 편이다. 물론, 퍼펫과 쉐프 및 라벨로는 이런 종류의 조율에도 도움이 될 수 있다.

여기에서 핵심은 사용하지 않는 역량을 유용하게 활용하면서 처음에 수립한 그 존재의 목적을 완전히 잃지 않는 것이다. 개발자들은 개발 기기가 단독으로 지원할 수 있는 것보다 더 높은 역량과 부하로 실제 시험하고 성능 문제를 점검하기 위해 이런 도구에 접근할 수 있어야 한다.

아무 기능도 없이 활성화되고 대기하는 대기 인프라를 보유하는 것은 데브옵스 도입과 정반대의 개념이라 할 수 있다. 이런 애플리케이션을 보유함으로써 원한다면 언제든지 활용하는 것도 가능하다.

재해복구 고려사항
지속적인 재해복구에 관해 생각할 때 팀과 함께 고려해야 할 사항이 있다.

- 재해복구 절차를 어떻게 ‘수립’하는가?
- 준수할 절차 목록은 누가 소유하는가?
- 누가 스크립트를 실행하거나 자동화를 담당하는가?
- 단일 애플리케이션, 실제 작업 부하, 인프라 자체의 고장을 어떻게 시뮬레이션하는가?
- 이런 각 핵심 요소에서 어떤 유형의 시나리오가 고장을 유발하는가?
- 재해복구를 중심으로 직원이 타고 난 어떤 강점에 역점을 둘 수 있는가?

데브옵스는 개발자와 운영 인력의 역할을 혼동하는 경향이 있지만 운영에서 더욱 강력한 역량과 경험을 보유한 직원이 있을 수밖에 없으며, 이들에게 시스템 대체 작동에 필요한 책무를 다할 수 있는 권한을 부여해야 한다.

개발 측면에서 코드 작성자는 코드로 인해 시스템 장애가 발생할 때에 책임을 져야 하며 디버깅(Debugging)만 하고 싶은 코드 작성자는 여기에서 태만해진 태도를 바로 잡을 수도 있다.

이미 비용을 지불한 재해복구 사이트와 기존 인프라를 어떻게 더 잘 활용할 수 있을까? 이 환경은 간편한 가상화 구축과 해체를 위한 것일까? 그렇지 않다면 대비하기 위해 무엇을 해야 할까?

*Jonathan Hassell은 노스캐롤라이나에 있는 컨설팅 기업인 82벤처스(82 Ventures)를 운영하고 있다. ciokr@idg.co.kr


X