오늘날과 같은 파괴적인 비즈니스 환경에서 성공하기란 쉽지 않습니다. 하지만 데브옵스를 적절한 IT 인프라스트럭처와 함께 활용함으로써 아이디어를 신속하게 현실화하고 경쟁에서 앞서 나갈 수 있습니다. 이번 글에서는HPE 3PAR 스토어서브 플래시 스토리지가 어떻게 이런 일을 이루어 낼 수 있는지 소개합니다.

기술 중심의 세상에서 성공하기 위해서는 좋은 아이디어 이상의 것이 필요합니다. 예를 들어 우버(스마트폰 애플리케이션으로 승객과 차량을 이어주는 서비스)는 비즈니스 구축을 위해 신기술을 개발할 필요가 없습니다. 이 회사는 매력적인 고객경험과 비즈니스를 수행하기 위한 새로운 방식을 설계하기 위해 스마트폰과 모바일 애플리케이션의 폭발적인 성장을 이용했을 뿐입니다.

하지만 이는 단지 우버가 좋은 아이디어를 실행에 옮길 수 있었기 때문만은 아닙니다.이는 또한 택시 업계가 자신의 비즈니스 모델을 경쟁력 있도록 신속하게 변화시키지 못했기 때문이기도 합니다.우버가 대표하는 파괴적인 혁신에 대응할 시간이 택시 업계에게 있었을까요? 물론입니다. 하지만 이를 위해선 피할 수 없는 파괴적 혁신이 도래했을 때 피봇(Pivot:사업이나 서비스의 핵심요소를전환하는 일)을 하게끔 지원할 IT 인프라가 필요했고, 이들에게는 이것이 갖춰져 있지 않았습니다. 여기서 배워야 할 교훈은 비록 포춘 선정 50대 혹은 1,000대 기업이라 할지라도 시장의 기회를 잃어버릴 위험이 있다는 것입니다. 기업을 보전하지도 못하고 새로운 아이디어나 비즈니스 모델에 의해 밀려나면서 말입니다.

성공으로 가는 길이 항상 쉬운 일은 아닙니다. 이를 극복하기 위한 수많은 IT 도전과제들이 있는데 예를 들면 다음과 같습니다.

• 시간 소모적인 인프라스트럭처 프로비저닝 : 복잡한 IT 과정 때문에 개발자들은 종종 며칠 혹은 몇 주를 기다려서 수작업이 필요한 IT 인프라스트럭처에 접근하여 애플리케이션 개발 및 테스트를 하곤 합니다. 번거로운 절차를 생략하기 위해 개발자들은 단 몇 번의 클릭으로 수분 내에 원하는 인프라스트럭처로 접근할 수 있는 클라우드로 이동했습니다. 이 때문에 기업이 원하지 않는 그림자 IT(Shadow IT, IT 부서의 통제를 받지 않는 IT 자원)가 생겨나고 있습니다.

• 개발과 운영 환경간의 격차 : 여러 가지 이유로 개발(Dev)과생산(Ops) 환경은 종종 별개로 존재합니다. 따라서 이러한 환경간에 있는 상충요소들을 찾아내는 것은 드문 일은 아닙니다. 운영팀이 개발팀에게 프로덕션 환경에 접근할 수 있도록 하는 것이 항상 가능하지는 않습니다. 프로덕션 데이터셋을 개발환경으로 복사하는 것은 너무 시간 소모적이고, 개발자들은 장시간 복사하느라 이미 최신이 아닌데이터셋을 다시 테스트하게 됩니다.그러므로 개발 환경에서 문제없이 작동했던 애플리케이션이 운영환경에서는 작동하지 않을 수도 있습니다.이는 출시와 버그 수정 사이클을 더 길게 만들고, 고객 불만족과 수익 감소 그리고 궁극적으로 개발팀과 운영팀간에 책임을 떠넘기며 신뢰를 갉아먹는 결과로 이어질 수 있습니다.

• ‘무슨 수를 써서라도 안전성 확보’ 접근법 : 얼마나 자주운영체제나 데이터베이스의 최신 버전이 나올까요? 사실 드문 빈도입니다. 기업들은 프로덕션 환경의 실패를 피하기 위해서 드물더라도 안정적인 애플리케이션 출시를 원하기 때문입니다. 이는 더 느린 시장 출시 시기와 다른 신기술에 의해 사양길을 걷게 될 위험이 있음을 뜻합니다.

데브옵스, 문화적 변화

오늘날의 성공에 대한 정의는 얼마나 더 신속하게 아이디어를 경쟁자보다 가치화시키는 것은 물론 실험과 실패를 거쳐 빨리 배우고, 테스트하고, 조정작업을 거쳐 개선하는지에 달려있습니다. 개발자의 할일은 변화를 만들고 애플리케이션을 강화하여 지속적인 수익원을 만드는 것입니다. 반면 운영자의 할일은 비즈니스를 연중무휴 24시간 내내 안정적이고 신뢰성있게 운영하는 것입니다. 그럼 어떻게 하면 이 두 가지 모순되는 관점을 조화시키고 팀간의 마찰을 줄일 수 있을까요? 데브옵스를 시작하기 바랍니다.

데브옵스는 기술이 아니라 개발팀과 운영팀간의 협동을 촉진하기 위한 일련의 과정과 사고방식의 변화입니다. 퍼펫 랩의 연구에 의하면 데브옵스를 수용하고 있는 IT 조직들은 200배나 잦은 배포, 24배 빠른 복구 시간, 3배 낮은 실패율 그리고 계획되지 않은 업무나 재작업에 대해 22% 적은 시간을 소비합니다. 이것은 단순한 우연이 아닙니다. 이 조직들은 지속적인 통합과 배포(CI and CD : Continuous Integration and Continuous Deployment)의 과정을 실행해 왔기 때문입니다. 이 과정을 실행함으로써 애플리케이션 라이프사이클의 모든 단계는 지속적 개선을 위한 피드백으로 자동화 됩니다.

자동화 과정에 연관된 툴체인이 여럿 있습니다. 여기 개념을 보여주기 위한 단순한 샘플이 있습니다.개발자는 깃허브와 같은 저장소(repository)내로 들어가는 애플리케이션 코드를 확인합니다.코드가 커밋되면 젠킨스(Jenkins)와 같은 툴들이 설계와 테스트 과정을 자동화합니다. 성공적인 테스트 실행을 기반으로 애플리케이션은실제 운영으로 배포되기 전에 “스테이징(Staging)” 구역으로 이동합니다. 피드백이 애플리케이션 개발팀으로 모든 과정의 단계마다 제공됩니다. 이것이 지속적인 통합(CI : Continuous Integration) 과정입니다. 운영과정으로 도입된 개발은 자동화되어 애플리케이션이 운영팀에 의해 지속적으로 모니터링되고 확장되며 지원됩니다. 이 과정을 지속적인 배포(CD : Continuous Deployment)라고 합니다.

소프트웨어 개발과 배포 부분에서 주요한 자동화가 이뤄졌다 해도 인프라스트럭처 자동화가 없다면 데브옵스 과정은 여전히 부차적인 방법일 뿐입니다.

이제 견실한 IT 인프라스트럭처가 어떻게 앞서 언급한 장벽들을 없앨 수 있는지 살펴보겠습니다.

인프라스트럭처 자동화

오늘날 개발자들은 인프라스트럭처의 효율성, 접근의 용이성, 배포 등에 있어 하이퍼스케일(hyperscale) 클라우드 환경에 가까운 수준을 기대합니다. 그러므로 인프라스트럭처의 모든 부분은 코드줄(line of code)로써 구성하거나 접근이 가능해야 합니다. HPE 원뷰를 통해“코드로서의 인프라(Infrastructure-as-code)”전체를 자동화할 수 있으며, 이때 셰프(Chef), 퍼펫(Puppet)혹은 앤서블(Ansible)과 같이 가장 선호하는 구성관리 툴을 선택하여 사용할 수 있습니다. 이로 인해 이전에는 배포까지 며칠 혹은 몇 주가 소요되던 일을 수 분 이내로 쉽게 어떤 워크로드에든지 IT 자원을 배포할 수 있습니다. 컴포저블 인프라스트럭처의 대표적인 예는 HPE 시너지로, 여기에는 HPE 3PAR 스토어서브 플래시 스토리지 그리고 소프트웨어 정의 스토리지 스토어버츄얼 VSA가 스토리지 빌딩 블록으로써 포함되어 있습니다.스토리지 플랫폼의 RESTful API는 HPE 원뷰를 통해 자동화 툴로 노출되어 스토리지 프로비저닝 및관리를 할 수 있습니다.

컨테이너와 “애플리케이션 이식성”

제가 도커콘(DockerCon) 컨퍼런스에 참가했을 때근래에 발표된 기술 중 컨테이너와 도커만큼이나 저를 흥분시킨 것은 없었습니다. 컨테이너에 대해 흥분할 만한 이유는 많습니다. VM과는 달리 컨테이너는 무게가 가볍고, 서버당 배포할 수 있는 애플리케이션 집적도가 더 좋습니다.몇 초 내에 신속하게 시작하고 중단할 수 있으며, 동일한 OS 계층을 공유합니다.

컨테이너는 전체 애플리케이션과 연관된 종속성(dependencis)들을 모두 포괄하고 있으므로 워크로드 이식성(workload portability)을 가능하게 합니다. 즉, 개발자 컴퓨터 상의 컨테이너 내에서 작동하는 하나의 애플리케이션이 QA 혹은 실제 운영환경 그리고 클라우드에서 유연하게 작동할 수 있다는 뜻입니다. 애플리케이션 이식성은 데브옵스 환경에서 컨테이너를 사용하는 주요한 이유 중 하나입니다.

원래, 컨테이너는 대부분 스테이트리스(stateless) 애플리케이션에 사용됐습니다. 예를 들면 로드밸런서, 웹서버, 모니터링 애플리케이션 등과 같은 것들 말입니다. 그리고 데이터 지속성은 상관이 없었습니다. 하지만 데이터베이스와 같은 스테이트풀(stateful) 애플리케이션이 점차 컨테이너화 됨에 따라 데이터 지속성은 핵심 요건이 됐습니다. 컨테이너 데이터 지속성이 HPE 스토리지(3PAR와스토어버추얼)에서 가능하도록 우리는 컨테이너에 외장 볼륨으로 부착할 수 있는 네이티브 도커 볼륨 플러그인을 만들었습니다. 컨테이너가 오케스트레이션 툴을 이용해 다른 종류의 호스트로 마이그레이션될 때 볼륨은 자동적으로 컨테이너에 재부착되어 컨테이너를 따를 수 있는 영구적(persistent) 볼륨을 가능하게 합니다. 데이터는 컨테이너 자체의 라이프사이클을 넘어서 애플리케이션에서 이용할 수 있습니다.또한 3PAR와 같은 현대적인 스토리지 플랫폼에 컨테이너 볼륨을 탑재하면(예를 들어 99.9999%의 데이터 가용성, 데이터 정리 능력 및 데이터 서비스 등과 같이 실제 운영되는 컨테이너에서 기대할 수 있는 부분에서) 엔터프라이즈급의 성능을 얻게 됩니다.

VM처럼 컨테이너의 불규칙한 확장이 예상됩니다. 수천 수만의 상태를 유지하는 보존형 애플리케이션(stateful)이 급속히 돌아갈 때 스토리지 시스템상의 입출력(IO) 양은 엄청나게 많아집니다.희소식은 3PAR는 예측 불가능한 멀티테넌트 워크로드에 맞게 설계됐으며, 그 자체로 컨테이너화 된 워크로드를 운영하기 위한 훌륭한 플랫폼이라는 것입니다.

깃허브로부터 제공되는 HPE 스토리지를 위한 네이티브 도커 볼륨 플러그인을 다운로드 받아서 사용해 보세요.

우리는 리버티(Liberty)의 출시와 함께 ClusterHQ와 협력을 시작해플로커(Flocker) 플러그인을 HPE 스토리지 신더(HPE Storage Cinder) 드라이버와 통합했습니다. 이를 통해 3PAR와스토어버추얼이 오픈스택 환경에서 컨테이너를 위한 스토리지 지속성을 제공할 수 있도록 했습니다.

컨테이너를 위한 스토리지 지속성과 도커에 대한 더 자세한 정보를 알고 싶다면 HEP 스토리지 가이 캘빈 지토의 팟캐스트를 들어보세요.

데브옵스를 가능하게 만드는 올플래시 어레이

역사적으로 개발과 운영 환경이 별도로 분리된 이유 중 하나는 인프라스트럭처(특히 스토리지)가 동일한 플랫폼에서 이 두가지 환경을 모두 수용할 만큼의 강력함을 갖추지 못했기 때문입니다.이는 개발팀과 QA팀이 데이터셋을 과잉복제하는 결과로 이어졌습니다.10TB의 데이터베이스를 복제해야 한다고 생각해보세요. 그림이 그려지나요? 3PAR 올플래시 어레이를 사용하면 개발과 운영은 동일한 스토리지 플랫폼에 통합될 수 있습니다. 이러한 접근법의 혜택은 다음과 같습니다.

•스토리지 공간점유율 축소.실제 운영상에 있는 데이터셋에 대한 스냅샷/클론을 생성함으로써IT 팀은 개발과 QA를 위한 별도의 다중 데이터셋 복제본을 만들 필요가 없습니다.

•코드의 품질 개선과 신속한 문제 해결.애플리케이션 개발/QA는 실제 환경에 대한 테스트를 하기 위해새로운실제 운영상태의 데이터셋에 접근할 수 있습니다.

3PAR 스토어서브 올플래시 어레이상에서우선순위 최적화(Priority Optimization)와 같은 기능을 이용하여 QoS(Quality of Service) 컨트롤과 1ms 미만의 응답속도를 설정할 수 있습니다. 운영팀은 SLA을 조금이라도 희생하는 일 없이이른바 ‘시끄러운 이웃(noisy neighbor:여러 기업들이 클라우드 자원을 공유할 때 나타나는 예기치 않은 트래픽 증가로 온라인 시스템의 가용성을 떨어뜨리고 클라우드 컴퓨팅의 대역폭이 점유되는 현상)’ 문제를 제거하고 개발팀을 위한 대역폭/IOPS/레이턴시 목표를 설정할 수 있습니다.

데브옵스는 일반적으로 개별화된 개발과 운영팀간의 협동을 촉진하는 강력한 조력자이기도 하지만, 애플리케이션 혁신과 IT 서비스 전개의 속도와 보조를 맞추기 위해 꼭 필요한 자동화를 구현하는 올바른 인프라스트럭처를 만들기 위해서도 중요합니다.

연관된 블로그를 읽어보세요

• 디스커버 팟캐스트에서 블로거와 함께 도커를 말하다
• 컴포저블 데이터 패브릭에 대한 더미 가이드