DevOps란?

DevOps는 더 빠르고 더 나은 애플리케이션을 개발하고 신규 또는 개정된 소프트웨어 기능이나 제품을 고객에게 더 빠르게 릴리즈하도록 지원하는 진보적 철학 및 프레임워크입니다.

DevOps 사례는 애플리케이션 개발 팀(Dev)과 해당 IT 운영 팀(Ops) 간의 원활하고 지속적인 커뮤니케이션, 협업, 통합, 가시성, 투명성을 지원합니다.

'Dev'와 'Ops' 간의 긴밀한 관계는 초기 소프트웨어 계획에서 코딩, 빌드, 테스트 및 릴리즈 단계와 배포, 운영, 지속적인 모니터링에 이르기까지 DevOps 라이프사이클의 모든 단계에 걸쳐 있습니다. 이러한 관계는 추가적으로 개선, 개발, 테스트, 배포할 수 있는 지속적인 고객 피드백 루프를 촉진합니다. 이러한 노력을 통해 필요한 기능을 변경 또는 추가하여 더욱 신속하고 지속적으로 릴리즈할 수 있게 되었습니다.

어떤 사람들은 DevOps 목표를 문화, 자동화, 측정 및 공유(CAMS)라는 4가지 범주로 그룹화하며, 이러한 영역에 DevOps 툴을 활용할 수 있습니다. 이러한 툴을 사용하면 개발 및 운영 워크플로를 더욱 간소화하고 보다 효율적으로 협업할 수 있으며 통합, 개발, 테스트, 배포 또는 모니터링 중에 시간이 많이 소요되는 작업, 수동 작업 또는 정적 작업을 자동화할 수 있습니다.

개발 팀과 IT 운영 팀 간의 커뮤니케이션 및 협업 중에 발생하는 장벽을 허물기 위한 노력과 더불어 DevOps가 핵심 가치로 추구하는 것은 고객 만족과 신속한 가치 제공입니다. 또한 DevOps는 비즈니스 혁신을 촉진하고 지속적으로 프로세스를 개선하도록 설계되었습니다.

DevOps 방식은 조직의 최종 고객에게 비즈니스 가치를 더 빠르고, 더 훌륭하고, 더 안전하게 제공하도록 지원합니다. 이 가치는 보다 빈번한 제품 릴리즈, 기능 또는 업데이트의 형태일 수 있습니다. 여기에는 적절한 수준의 품질과 보안성을 갖춘 제품 릴리즈 또는 새로운 기능을 고객이 얼마나 빠르게 만나볼 수 있는지가 포함될 수 있습니다. 또는 문제나 버그를 신속하게 파악하여 해결한 후에 다시 릴리즈하는 속도에 중점을 둘 수도 있습니다.

기본 인프라는 소프트웨어를 처음 개발하여 테스트한 후 운영 환경에 릴리즈하는 과정에서 소프트웨어의 원활한 성능, 가용성, 안정성을 제공함으로써 DevOps를 뒷받침합니다.

조직에서 개발 및 제품 릴리즈 속도를 높이고 개선하는 데 사용할 수 있는 몇 가지 일반적인 DevOps 방법이 있습니다. 이러한 방법은 소프트웨어 개발 방법론 및 사례의 형식을 취합니다. 그중 가장 널리 사용되는 것은 스크럼, 칸반, 애자일입니다.

• 스크럼: 스크럼은 개발 및 QA 프로젝트를 신속하게 수행하기 위해 팀 구성원이 어떻게 협력해야 하는지를 정의합니다. 스크럼 사례에는 주요 워크플로 및 특정 용어(스프린트, 시간 상자, 일일 스크럼[미팅]), 전담 역할(스크럼 마스터, 제품 소유자)이 포함됩니다.
• 칸반: 칸반은 Toyota 공장에서 효율성을 개선한 방식을 기반으로 시작되었습니다. 칸반은 소프트웨어 프로젝트의 작업 진행 상태(WIP)를 칸반 보드에서 추적하도록 권장합니다.
• 애자일: 초기의 애자일 소프트웨어 개발 방법은 여전히 DevOps 사례와 툴에 중대한 영향을 미치고 있습니다. 스크럼과 칸반을 비롯한 많은 DevOps 방법에는 애자일 프로그래밍 요소가 통합되어 있습니다. 일부 애자일 사례는 변화하는 니즈 및 요구 사항에 더욱 빠르게 응답하고, 요구 사항을 사용자 사례로 문서화하며, 일일 스탠드업 미팅을 진행하고, 지속적인 고객 피드백을 통합하는 등의 작업과 관련이 있습니다. 또한, 애자일은 오랜 시간이 걸리는 기존의 '워터폴(waterfall)' 개발 방법 대신 그보다 짧은 소프트웨어 개발 라이프사이클을 사용하는 것을 권장합니다.

DevOps 사례를 따르는 사람들은 DevOps '툴체인'의 일부로 DevOps 친화적인 특정 툴을 사용하는 경우가 많습니다. 이러한 툴은 소프트웨어 제공 워크플로(또는 '파이프라인')의 다양한 단계를 더욱 간소화하고 단축하며 자동화하는 것을 목표로 합니다. 또한 이러한 툴 중 다수는 개발 팀 과 운영 팀 간의 자동화, 협업 및 통합이라는 핵심 DevOps 원칙을 장려합니다. 다양한 DevOps 라이프사이클 단계에서 사용되는 툴의 예는 다음과 같습니다.

• 계획: 이 단계는 비즈니스 가치와 요구 사항을 정의하는 데 도움이 됩니다. 여기에서 사용되는 툴의 예로는 알려진 문제를 추적하고 프로젝트 관리를 수행하는 데 도움이 되는 Jira 또는 Git이 있습니다.
• 코딩: 이 단계에서는 소프트웨어를 설계하고 소프트웨어 코드를 생성합니다. 여기에서 사용되는 툴의 예로는 GitHub, GitLab, Bitbucket 또는 Stash가 있습니다.
• 빌드: 이 단계에서는 소프트웨어 빌드 및 버전을 관리하고, 자동화된 툴을 사용하여 향후 릴리즈에서 프로덕션까지 코드를 컴파일하고 패키징합니다. 사용자는 제품 릴리즈에 필요한 인프라도 '패키징'하는 소스코드 저장소 또는 패키지 저장소를 사용합니다. 여기에서 사용되는 툴의 예로는 Docker, Ansible, Puppet, Chef, Gradle, Maven 또는 JFrog Artifactory가 있습니다.
• 테스트: 이 단계에서는 최적의 코드 품질을 보장하기 위해 지속적으로 수동 또는 자동 테스트를 수행합니다. 여기에서 사용되는 툴의 예로는 JUnit, Codeception, Selenium, Vagrant, TestNG, 또는 BlazeMeter가 있습니다.
• 배포: 이 단계에서는 제품 릴리즈에서 프로덕션으로의 과정을 관리, 조정, 예약 및 자동화하기 위한 툴이 포함될 수 있습니다. 여기에서 사용되는 툴의 예로는 Puppet, Chef, Ansible, Jenkins, Kubernetes, OpenShift, OpenStack, Docker 또는 Jira가 있습니다.
• 운영: 이 단계에서는 프로덕션 상태의 소프트웨어를 관리합니다. 여기에서 사용되는 툴의 예로는 Ansible, Puppet, PowerShell, Chef, Salt 또는 Otter가 있습니다.
• 모니터링: 이 단계에서는 프로덕션 상태인 특정 소프트웨어 릴리즈의 문제에 대한 정보를 식별하고 수집합니다. 여기에서 사용되는 툴의 예로는 New Relic, Datadog, Grafana, Wireshark, Splunk, Nagios 또는 Slack이 있습니다.

DevOps 사례는 지속적인 개선 및 자동화의 개념을 반영합니다. 많은 사례가 하나 이상의 개발 주기 단계에 중점을 둡니다. 이러한 사례는 다음과 같습니다.

• 지속적인 개발: 이 사례는 DevOps 라이프사이클의 계획 단계와 코딩 단계에 걸쳐 적용됩니다. 버전 관리 메커니즘이 포함될 수 있습니다.
• 지속적인 테스트: 이 사례는 애플리케이션 코드를 작성하거나 업데이트할 때, 자동화되고 사전 예약된 지속적인 코드 테스트를 포함합니다. 이러한 테스트를 통해 코드를 더 빠르게 운영 환경에 제공할 수 있습니다.
• 지속적인 통합(CI): 이 사례는 구성 관리(CM) 툴을 다른 테스트 및 개발 툴과 함께 사용하여 개발 중인 코드의 운영이 준비된 정도를 추적합니다. 테스트 팀과 개발 팀 간에 신속한 피드백을 수행하여 코드 문제를 빠르게 파악하고 해결합니다.
• 지속적인 제공: 이 사례는 테스트 후 사전 운영 또는 스테이징 환경에 코드 변경 사항을 제공하는 작업을 자동화합니다. 그러면 직원은 이러한 코드 변경을 운영 단계로 승격시키도록 결정할 수 있습니다.
• 지속적인 배포(CD): 지속적 제공과 마찬가지로 이 사례는 새 코드 또는 변경된 코드를 운영 단계로 자동 릴리즈합니다. 지속적인 배포를 수행하는 회사에서는 코드 또는 기능 변경 사항을 하루에 여러 번 릴리즈할 수 있습니다. Docker, Kubernetes와 같은 컨테이너 기술을 사용하면 다양한 배포 플랫폼과 환경에서 코드를 일관성 있게 유지하여 지속적인 배포를 지원할 수 있습니다.
• 지속적인 모니터링: 이 사례는 작동 중인 코드와 이를 지원하는 기본 인프라 모두에 대한 지속적인 모니터링을 포함합니다. 버그 또는 문제가 보고될 경우 다시 개발 단계로 돌아가는 피드백 루프입니다.
• 코드형 인프라: 이 사례는 다양한 DevOps 단계에서 소프트웨어 릴리즈에 필요한 인프라 프로비저닝을 자동화하는 데 사용할 수 있습니다. 개발자는 기존 개발 툴 내에서 인프라 '코드'를 추가합니다. 예를 들어, 개발자가 필요에 따라 Docker, Kubernetes 또는 OpenShift에서 스토리지 볼륨을 생성할 수 있습니다. 또한 운영 팀은 이 사례를 통해 환경 구성을 모니터링하고 변경 사항을 추적하며 구성 롤백을 간소화할 수 있습니다.

DevOps 지지자들은 여러 비즈니스 및 기술적 이점이 존재하며, 이러한 이점을 통해 고객 만족도를 높일 수 있다고 설명합니다. DevOps의 몇 가지 이점은 다음과 같습니다.

• 더 우수한 제품을 더 빠르게 제공
• 신속한 문제 해결 및 복잡성 감소
• 확장성 및 가용성 향상
• 보다 안정적인 운영 환경
• 향상된 리소스 활용률
• 자동화 향상
• 시스템 결과에 대한 가시성 개선
• 더 나은 혁신

소프트웨어 개발 및 배포를 간소화하는 여러 DevOps 방법은 애자일 소프트웨어 개발 및 린 프로그래밍에 초기 기반을 두고 있습니다. 그러나 DevOps는 본래 개발자와 운영 팀 간의 활동을 조화롭게 만들기 위한 여러 활동에 그 뿌리를 두고 있습니다.

2000년대 초반, Google 및 Flickr와 같은 인기 웹 사이트는 엄청난 성공에 대비하여 가용성을 지속적으로 유지해야 할 필요가 있었습니다. 이러한 요구로 인해 운영 담당자인 SRE(Software Reliability Engineer)가 필요하게 되었고, SRE는 코드가 프로덕션으로 릴리즈된 후에도 사이트가 계속 실행되도록 보장하기 위해 개발자들과의 긴밀하게 협력했습니다.

2009년 Flickr의 엔지니어인 John Allspaw와 Paul Hammond는 컨퍼런스에서 DevOps와 유사한 방법론에 대해 발표했습니다. 이 프레젠테이션 제목은 '10+ Deploys per Day: Dev and Ops Cooperation at Flickr'(하루에 10개 이상 배포: Flickr에서의 개발 및 운영 협력)였습니다. 같은 해에 Patrick Debois는 벨기에에서 첫 번째 'DevOps Day'를 주최했습니다. 또한 #DevOps 해시태그도 더해지며 전 세계적으로 더 많은 DevOps Day가 생기면서 추진력을 얻었습니다.

이후 몇 년간 DevOps 목표가 한 단계 더 발전시키기 위해 업계 및 오픈 소스 툴과 프레임워크가 개발되고 제안되었습니다.

NetApp은 DevOps를 통해 보다 나은 비즈니스 성과를 이루도록 지원합니다. 운영 팀은 최소한의 엔지니어링으로 자동화된 인프라를 제공하며, 개발자는 안정적이고 예측 가능한 환경에서 마찰 없이 제품을 만들 수 있습니다. NetApp® 기술을 사용하면 온프레미스와 클라우드 환경 모두에서 개발자 생산성을 극대화하는 데 필요한 서비스와 기능을 자신 있게 제공할 수 있습니다.

NetApp은 개발자, 테스트, QA 및 운영 팀이 DevOps 파이프라인에 있는 익숙한 툴에서 인프라 리소스(예: 영구 스토리지 볼륨)를 코드로 손쉽게 사용할 수 있는 솔루션을 제공합니다. 예를 들어 NetApp 스토리지 API 및 IAC를 Puppet, Ansible, Docker, Kubernetes 및 OpenShift와 같은 툴과 통합할 수 있습니다.

하지만 NetApp은 개발자가 스토리지를 손쉽게 코드로 사용하는 기능만 제공하는 것은 아닙니다. NetApp 기술을 통해 운영 팀은 개발 및 테스트 담당자에게 리소스를 안정적으로 프로비저닝하여 제공할 수도 있습니다. 그러면 개발자 및 테스터가 스냅샷, 클론 등과 같이 시간을 절약할 수 있는 스토리지 기능을 자체 프로비저닝하여 코딩 시간과 테스트 주기를 단축할 수 있습니다. 이 기능을 활용하면 실시간 운영 데이터 또는 코드 세트의 사본을 단 몇 초 또는 몇 분 만에 코드로 프로비저닝하여 개발 및 QA 워크플로 속도를 높일 수 있습니다. NetApp이 DevOps에 적합한 이유에 대해 자세히 알아보십시오.

NetApp이 DevOps에 적합한 이유

커뮤니티에 대한 NetApp의 노력은 thePub으로 확대됩니다. 이 개발자 커뮤니티에서는 협업을 장려하고, 팁과 요령을 공유하며, 최신 DevOps 사례 및 프로토콜에 대한 아이디어를 논의합니다.