Offcanvas

CIO / How To / 애플리케이션 / 클라우드

애플리케이션을 민첩하게! 클라우드 인프라에 필요한 5가지

2013.07.22 Bernard Golden   |  CIO


3. 공통 상용제품 : 한 주방에 요리사가 여럿

사일로 접근방식의 문제점 중 하나는 각 그룹이 저마다의 상용제품을 만들어 사용한다는 점이다. 개발자들은 아마존 웹 서비스(Amazon Web Services) 가상머신과 때로는 지텁 & 젠킨스(Github and Jenkins)를 사용한다. QA는 코드를 뽑아내고 자체적인 툴을 사용해 이를 다시 구성한다. 이것을 운영부에 넘기면 자동화된 사용설명서 툴에서 코드가 다시 정의된다. 애플리케이션이 생산 단계에 돌입하면 수동 추적 방식을 사용하는 변화관리 위원회를 통해 흐름을 바꾸고, 이런 추적방법은 직접적인 구성의 변화로 이어지는 문제로 귀결된다.

이런 다양한 상용제품이 존재할 때, IT 버전의 의원성(iatrogenesis)에서 모든 것을 영원히 끝낼 수 없으며 끊임없는 오류에 시달릴 것임은 의심의 여지가 없다. 모든 그룹이 일관되게 사용하는 한 버전의 코드가 존재하지 않는다면 혼란이 야기될 것이다.

4. 일관된 툴: 드라이버 하나로 충분

코드에 대한 수동 개입과 관련된 끊임없는 문제점은 각 그룹이 자체 툴을 사용할 때 더욱 악화될 뿐이다. 이렇게 각 그룹이 선택할 툴로 관리할 수 있도록 애플리케이션을 다시 변환하면 혼란과 오류가 야기될 수 밖에 없다. 더 나은 해결책: 복수의 작업그룹이 공유할 수 있는 단일한 툴 세트를 찾는다. 쉐프(Chef) 또는 퍼펫(Puppet)은 지트허브(GitHub)와 함께 애플리케이션의 생애주기 동안 사용할 수 있는 툴을 위한 좋은 선택이라 할 수 있다.

5. 제한적 실행을 통한 점진적 애플리케이션 변화

애플리케이션 배치 모델을 애자일 개발 모델, 즉, 적은 양의 점진적 기능을 자주 공개하는 모델과 일치시키는 것이 맞다. 많은 기업들은 코드를 생산단계로 돌입시키는 간접비가 너무 높기 때문에 많은 기능상 변화를 하나의 업데이트로 묶는다. 이 때문에 업데이트의 일부가 실패하는 문제가 발생했을 때 어떤 부분이 문제가 되는지 찾아내기가 어렵다.

더 나은 방법이 있다. 빈번한 공개로 인한 문제를 해결한 후에 소규모 업데이트를 진행하면 된다. 이것과 관련된 위험은 조건적 표현을 통해 기능적 코드를 노출함으로써 최소화할 수 있다. 즉, "DISPLAY NEW FEATURE A" 매크로가 환경 변수로 설정되어 있을 때 새로운 기능 A를 표시하면 된다. 이를 통해 해당 기능을 전체적인 컴퓨팅 풀의 하위 요소에서만 노출할 수 있으며, 기능에서 문제가 발견되면 해당 기능을 손쉽게 정지할 수 있다.

클라우드 컴퓨팅의 가능성을 완전히 실현하는 것은 인프라의 민첩성을 애플리케이션 민첩성과 연계했을 경우에만 가능하다. 애플리케이션 라이프사이클의 자동화된 최적화에 실패하면 시장에 더욱 빨리 진출하겠다는 IT부서의 꿈이 무산될 수 밖에 없다.

*Bernard Golden은 클라우드 관리 소프트웨어 기업이었던 엔스트라투스의 부사장이었다. 이 기업이 올해 5월 델에 인수되면서 그는 현재 델에서 클라우드 컴퓨팅 엔터프라이즈 솔루션 그룹에서 근무하고 있다. ciokr@idg.co.kr

CIO Korea 뉴스레터 및 IT 트랜드 보고서 무료 구독하기
Sponsored
추천 테크라이브러리

회사명:한국IDG 제호: CIO Korea 주소 : 서울시 중구 세종대로 23, 4층 우)04512
등록번호 : 서울 아01641 등록발행일자 : 2011년 05월 27일

발행인 : 박형미 편집인 : 천신응 청소년보호책임자 : 한정규
사업자 등록번호 : 214-87-22467 Tel : 02-558-6950

Copyright © 2024 International Data Group. All rights reserved.