DevOps란?

DevOps란?

정의상으로, DevOps는 전통적으로 사일로에서 또는 서로 간에 개별적으로 업무를 보던 두 그룹인 개발 및 IT 운영 팀의 업무를 자동화하고 통합함으로써 고품질 소프트웨어의 딜리버리를 가속화하는 소프트웨어 개발 프로세스와 조직 문화 혁신을 개략적으로 설명합니다.

실제로, 최상의 DevOps 프로세스와 문화는 개발 및 운영을 넘어 플랫폼 및 인프라 엔지니어링, 보안, 규제 준수, 거버넌스, 리스크 관리, 비즈니스 라인 및 고객을 포함한 모든 애플리케이션 이해 당사자의 입력을 소프트웨어 개발 라이프사이클에 통합합니다.

DevOps는 수 개월 또는 수 년마다의 거대한 애플리케이션 전체 코드 릴리스에서부터 매일 또는 하루에 몇 번씩 빈번하게 릴리스되는 반복적인 작은 특성 또는 기능적 업데이트에 이르기까지 과거 20년이 넘는 동안의 소프트웨어 딜리버리 사이클의 진화의 현재 상태를 나타냅니다.

궁극적으로, DevOps는 빈번하고 혁신적인 새로운 기능과 중단 없는 성능 및 가용성에 대한 소프트웨어 사용자의 끊임없는 요구사항을 충족시키는 것입니다.

DevOps 접근 방법

2000년 이전까지만 해도, 대부분의 소프트웨어는 대규모 개발 프로젝트에 대한 선형 접근법인 폭포수 방법론을 사용하여 개발되고 업데이트되었습니다. 소프트웨어 개발 팀은 대부분의 또는 모든 애플리케이션에 영향을 주는 새 코드의 대형 본문을 개발하는 데 몇 달을 소요했습니다. 변경사항이 너무 광범위하기 때문에, 이들은 이러한 새 코드를 코드 베이스에 통합하는 데 몇 개월을 더 사용했습니다.

그 다음에는 품질 보증(QA), 보안 및 운영 팀이 여전히 코드를 테스트하는 데 수 개월을 소요했습니다. 결과적으로 소프트웨어 릴리스 사이에는 수 개월 또는 심지어는 몇 년이 걸렸으며, 종종 릴리스 간의 여러 중요 패치나 버그 수정사항의 경우도 이와 마찬가지였습니다. 그리고 기능 딜리버리에 대한 이 "빅뱅 접근법"은 종종 복잡하고 위험한 배치 계획, 업스트림 및 다운스트림 시스템과의 상호잠금을 스케줄하기가 어려움, 그리고 프로덕션 "활성화"로 이어지는 몇 달 동안 비즈니스 요구사항이 급격하게 변화되지 않는다는 IT의 "커다란 희망"을 특징으로 합니다.

개발 속도를 빠르게 하고 품질을 향상시키기 위해 개발 팀은 애자일 소프트웨어 개발 방법론을 채택하기 시작했으며, 이는 선형이 아니라 반복적이며 애플리케이션 코드 베이스에 대한 보다 작고 빈번한 업데이트에 집중합니다. 이들 방법 중 가장 중요한 것은 지속적 통합 및 지속적 딜리버리 또는 CI/CD입니다. CI/CD에서 새 코드의 소형 청크는 1주 또는 2주마다 코드 베이스에 병합된 후에, 프로덕션 환경으로의 배치를 위해 자동으로 통합, 테스트 및 준비됩니다. 애자일은 '빅뱅' 접근 방법을 역시 구획된 리스크인 일련의 '보다 작은 스냅'으로 진화시켰습니다.

더욱 효과적으로 이러한 민첩한 개발 사례가 소프트웨어 개발 및 딜리버리를 가속화할수록, 소프트웨어 딜리버리 라이프사이클의 차기 병목 현상으로 시스템 프로비저닝, 구성, 승인 테스트, 관리, 모니터링 등 여전히 사일로에 있는 IT 운영이 더 많이 노출되었습니다.

그래서 DevOps는 더 이상 애자일하지 않습니다. 이는 CI/CD의 지속적 반복과 자동화를 소프트웨어 딜리버리 라이프사이클의 나머지로 확장하는 새로운 프로세스와 툴을 추가했습니다. 그리고 이는 프로세스의 모든 단계에서 개발과 운영 사이의 긴밀한 협업을 구현했습니다.

DevOps 작동 방식: DevOps 라이프사이클

DevOps 라이프사이클

DevOps 라이프사이클(선형 방식으로 표현 시에, 종종 지속적 딜리버리 파이프라인이라고도 함)은 고품질 소프트웨어의 신속한 딜리버리를 최적화하도록 설계된 더 크고 자동화된 반복적 개발 라이프사이클 내에서 실행되는 일련의 반복적이고 자동화된 개발 프로세스 또는 워크플로우입니다. 워크플로우의 이름과 수는 누구에게 요청하느냐에 따라 다를 수 있지만, 이는 일반적으로 다음의 여섯 가지로 귀결됩니다.

• 계획(또는 아이디어). 이 워크플로우에서 팀들은 우선순위가 지정된 일반 사용자 피드백 및 사례 연구는 물론 모든 내부 이해 당사자의 입력에서 가져온 다음 릴리스의 새로운 특성과 기능을 자세히 살펴봅니다. 계획 단계의 목표는 전달 시에 가치가 있는 원하는 결과를 생성하는 기능의 백로그를 생성하여 제품의 비즈니스 가치를 극대화하는 것입니다.
• 개발. 이는 개발자가 백로그의 사용자 스토리 및 작업 항목을 기반으로 새롭고 향상된 기능을 테스트, 코딩 및 빌드하는 프로그래밍 단계입니다. 무엇보다도 테스트 기반 개발(TDD), 쌍 프로그래밍 및 피어 코드 검토 등의 사례들의 조합은 일반적입니다. 개발자는 종종 로컬 워크스테이션을 사용하여 지속적 딜리버리 파이프라인 아래로 전송하기 전에 코드 쓰기 및 테스트의 "내부 루프"를 수행합니다.
• 통합(또는 구축 또는 지속적 통합 및 지속적 딜리버리(CI/CD). 위에서 언급한 바와 같이, 이 워크플로우에서 새 코드는 기존 코드 베이스에 통합된 후 배치를 위해 테스트되고 실행 파일로 패키지화됩니다. 공통 자동화 활동에는 "마스터" 사본으로 코드 변경사항 병합, 소스 코드 저장소에서 해당 코드의 체크아웃 및 컴파일, 단위 테스트의 자동화 및 실행 파일로의 패키징이 포함됩니다. 우수 사례는 다음 단계를 위해 2진 저장소에 CI 단계의 출력을 저장하는 것입니다.
• 배치(일반적으로 지속적 배치라고 함). 여기서 런타임 빌드 출력(통합의)은 런타임 환경에 배치됩니다. 여기서, 런타임 환경은 일반적으로 품질, 규제 준수 및 보안을 위해 런타임 테스트가 실행되는 개발 환경입니다. 오류 또는 결함이 발견되면, 개발자는 일반 사용자가 발견하기 전에 문제점을 가로채고 수정할 수 있는 기회를 갖습니다. 일반적으로 개발, 테스트 및 프로덕션을 위한 환경이 있으며, 각 환경은 점진적으로 "보다 엄격한" 품질 게이트를 필요로 합니다. 프로덕션 환경에 배치하기 위한 좋은 방법은 일반적으로 일반 사용자의 서브세트에 먼저 배치한 후에, 일단 안정성이 설정되면 결국 모든 사용자에게 배치하는 것입니다.
• 운영. 프로덕션 환경으로 전달된 기능 받기가 "1일차"로 특성화된 경우, 일단 기능이 프로덕션에서 실행 중이면 "2일차" 운영이 발생합니다. 기능 성능, 작동 및 가용성을 모니터링하면 기능이 최종 사용자에게 부가 가치를 제공할 수 있도록 보장합니다. 운영은 네트워크, 스토리지, 플랫폼, 컴퓨팅 및 보안 상태가 모두 양호하다는 것을 확인함으로써 기능이 원활히 실행되고 서비스에 인터럽트가 없음을 보장합니다! 문제점이 발생하는 경우, 운영 팀은 인시던트가 식별되고, 해당 직원에게 경보가 전달되며, 문제점이 판별되고, 수정이 적용되도록 보장합니다.
• 학습(종종 지속적 피드백이라고도 함). 이는 특성, 기능, 성능 및 비즈니스 가치에 대한 최종 사용자와 고객의 피드백을 수집하여 다음 릴리스의 특성과 개선사항에 대한 계획으로 돌려보냅니다. 여기에는 또한 운영 활동의 모든 학습 및 백로그 항목이 포함되며, 이는 미래에 다시 발생할 수 있는 과거의 사건을 사전에 방지할 수 있도록 개발자의 역량을 강화합니다. 이것이 바로 계획 단계에 대한 "랩어라운드"가 발생하고 "지속적 개선"이 실행되는 지점입니다!

세 가지 중요한 연속 워크플로우가 이러한 워크플로우 사이에 발생합니다.

지속적 테스트: 전통적인 DevOps 라이프사이클에는 통합 및 배치 사이에 발생하는 개별 "테스트" 단계가 포함됩니다. 그러나, DevOps는 테스트의 특정 요소들이 계획(행동 기반 개발), 개발(단위 테스트, 계약 테스트), 통합(정적 코드 스캔, CVE 스캔, 린팅), 배치(스모크 테스트, 침투 테스트, 구성 테스트), 운영(혼돈 테스트, 규제 준수 테스트) 및 학습(A/B 테스트)에서 발생할 수 있도록 발전되었습니다. 테스트는 강력한 위험 및 취약성 식별 양식이며, IT가 위험을 수용, 완화 또는 개선할 수 있는 기회를 제공합니다.

보안: 폭포수 방법론과 애자일 구현이 딜리버리 또는 배치 후에 보안 워크플로우를 덧붙이는 한편, DevOps는 보안 문제가 처리하기에 가장 쉽고 비용이 최소일 때 시작(계획)부터 보안을 통합하려고 노력합니다. 그리고 이는 개발 주기의 나머지 전체에서 지속됩니다. 보안에 대한 이러한 접근 방식을 쉬프트 레프트(그림 1을 보면 이해가 용이함)라고 합니다. 일부 기업들의 쉬프트 레프트는 다른 기업들보다 성공적이지 않았으며, 이에 따라 DevSecOps(아래 참조)가 부상했습니다.

규제 준수. 규제 준수(거버넌스 및 리스크)는 개발 라이프사이클 전체에서 조기에 가장 잘 해결됩니다. 규제된 산업은 종종 런타임 운영 환경에서 기능이 전달되고 관리되는 방식에 대한 특정 수준의 관찰가능성, 추적성 및 액세스를 제공하도록 규정되어 있습니다. 이를 위해 지속적 딜리버리 파이프라인과 런타임 환경에서 정책의 계획, 개발, 테스트 및 실행이 필요합니다. 규제 준수 측정의 감사는 써드파티 감사자에 대해 규제 준수를 입증하기 위해 매우 중요합니다.

DevOps 문화

DevOps 방식은 DevOps 문화에 대한 헌신 없이는 작동할 수 없다는 것이 일반적으로 받아들여지며, 이는 이는 소프트웨어 개발에 대한 다른 조직 및 기술적 접근 방식으로 요약될 수 있습니다.

조직 수준에서, DevOps는 빠르고 지속적으로 혁신하고 시작부터 소프트웨어에 품질을 구축할 수 있도록 모든 소프트웨어 딜리버리 이해 당사자들(확실히 소프트웨어 개발 및 IT 운영 팀은 물론 보안, 규제 준수, 거버넌스, 리스크 및 비즈니스 라인 팀) 간의 지속적 커뮤니케이션, 협업 및 공유 책임을 요구합니다.

대부분의 경우, 이를 수행하는 가장 좋은 방법은 다른 팀에게 이를 미루거나 또는 다른 팀의 승인을 기다리지 않고 이러한 사일로를 타파하고 이를 시작부터 끝까지, 계획에서 피드백까지 코드 프로젝트에 대해 작업할 수 있는 교차 기능의 자율적인 DevOps 팀으로 재구성하는 것입니다. 애자일 개발의 컨텍스트에 놓이는 경우, 공유된 책임과 협업은 가치 있는 결과를 갖는 공유된 제품 초점 보유의 기반입니다.

기술 레벨에서, DevOps는 워크로드 내에서와 이들 간에 프로젝트를 지속적으로 이동시키는 자동화 및 팀들이 주기를 지속적으로 가속화하고 소프트웨어 품질과 성능을 향상시킬 수 있도록 하는 피드백 및 측정에 대한 헌신을 요구합니다.

DevOps 툴: DevOps 툴체인 빌드

DevOps 및 DevOps 문화의 요구사항은 비동기 협업을 지원하고, DevOps 워크플로우를 완벽하게 통합하며, 전체 DevOps 라이프사이클을 가능한 한 자동으로 자동화하는 툴링에 프리미엄을 부여합니다. DevOps 툴의 카테고리에는 다음이 포함됩니다.

• 프로젝트 관리 툴 - 팀들이 코딩 프로젝트를 형성하는 사용자 스토리(요구사항)의 백로그를 빌드하고, 이를 더 작은 태스크로 구분하며, 태스크를 완료까지 추적할 수 있도록 하는 툴입니다. 다수는 개발자가 DevOps에 제공하는 Scrum, Lean 및 Kanban 등의 애자일 프로젝트 관리 사례를 지원합니다. 유명한 오픈 소스 옵션에는 GitHub Issues 및 Jira 등이 있습니다.
• 협업 소스 코드 저장소 - 여러 개발자들이 동일한 코드 베이스에서 작업할 수 있도록 허용하는 버전 제어 코딩 환경입니다. 코드 저장소가 저장소로 커미트될 때 자동으로 다음 단계로 이동할 수 있도록, 코드 저장소는 CI/CD, 테스트 및 보안 툴과 통합되어야 합니다. 오픈 소스 코드 저장소에는 GiHub 및 GitLab이 포함됩니다.
• CI/CD 파이프라인 - 코드 체크아웃, 빌드, 테스트 및 배치를 자동화하는 툴입니다. Jenkins는 이 카테고리에서 가장 유명한 오픈 소스 툴입니다. CircleCI 등의 많은 이전의 오픈 소스 대안들은 현재 상용 버전에서만 제공됩니다. 지속적 배치(CD) 툴에 관한 한, Spinnaker는 애플리케이션과 IaC(Infrastructure as Code) 계층 간에 걸쳐 있습니다. ArgoCD는 Kubernetes 네이티브 CI/CD의 또 다른 유명한 오픈 소스 선택사항입니다.
• 테스트 자동화 프레임워크 - 이에는 유닛, 계약, 기능, 성능, 사용성, 침투 및 보안 테스트를 자동화하기 위한 소프트웨어 툴, 라이브러리 및 우수 사례가 포함됩니다. 이러한 툴 중 최고는 여러 언어를 지원하며, 일부는 인공지능(AI)을 사용하여 코드 변경사항에 대한 응답으로 테스트를 자동으로 재구성합니다. 테스트 툴과 프레임워크의 범위는 매우 넓고 광범위합니다! 유명한 오픈 소스 테스트 자동화 프레임워크에는 Selenium, Appium, Katalon, Robot Framework 및 Serenity(이전의 Thucydides)가 포함되어 있습니다.
• 구성 관리(IaC(Infrastructure as Code)) 툴 - 이를 사용하여 DevOps 엔지니어는 스크립트를 실행하여 완전 버전화되고 완전 문서화된 인프라를 구성 및 프로비저닝할 수 있습니다. 오픈 소스 옵션에는 Ansible(Red Hat), Chef, Puppet 및 Terraform이 포함됩니다. Kubernetes는 컨테이너화된 애플리케이션에 대해 동일 기능을 수행합니다(아래의 'DevOps 및 cloud-native development' 참조).
• 모니터링 툴 - 이는 DevOps팀이 시스템 문제를 식별하고 해결하는 데 도움이 됩니다. 이들은 또한 실시간으로 데이터를 수집하고 분석하여 코드 변경사항이 애플리케이션 성능에 어떤 영향을 주는지를 공개합니다. 개방형 소스 모니터링 툴에는 Datadog, Nagios, Prometheus 및 Splunk가 포함됩니다.
• 지속적인 피드백 툴 - 히트맵(화면에서 사용자의 조치를 기록함), 서베이 또는 셀프 서비스 문제 티켓팅을 통해 사용자의 피드백을 수집하는 툴입니다.

DevOps 및 클라우드 네이티브 개발

클라우드 네이티브는 기본 클라우드 컴퓨팅 기술을 활용하는 애플리케이션을 빌드하는 접근 방법입니다. 클라우드 네이티브의 목표는 퍼블릭, 프라이빗 및 멀티클라우드 환경에서 일관된 최적의 애플리케이션 개발, 배치, 관리 및 성능을 지원하는 것입니다.

오늘날 일반적으로 사용되는 클라우드 네이티브 애플리케이션

• 자체 포함된 스택을 보유하고 REST API, 이벤트 스트리밍 또는 메시지 브로커를 통해 서로 간에 통신하는 느슨하게 결합되고 독립적으로 배치 가능한 컴포넌트인 마이크로서비스를 사용하여 빌드됩니다.
• 애플케이션을 실행하는 데 필요한 모든 코드, 런타임 및 운영 체제 종속성을 포함하는 실행할 수 있는 코드 단위인 컨테이너에 배치됩니다. (대부분의 기업에서 '컨테이너'는 Docker 컨테이너와 동의어이지만, 다른 컨테이너 유형도 존재합니다.)
• 컨테이너화된 애플리케이션의 배치, 관리 및 확장을 스케줄링 및 자동화하기 위한 오픈 소스 컨테이너 오케스트레이션 플랫폼인 Kubernetes를 사용하여 (규모에 맞게) 운영됩니다.

다양한 방법으로, 클라우드 네이티브 개발과 DevOps는 서로를 위해 구축됩니다.

예를 들어, 마이크로서비스의 개발 및 업데이트는 작은 코드 단위를 작은 코드 베이스로 반복하여 전달하는데, 이는 DevOps 고속 릴리스 및 관리 사이클에 매우 적합합니다. 그리고 DevOps 배치와 운영이 없이는 마이크로서비스 아키텍처의 복잡성을 다루기가 매우 어렵습니다. 개발자 및 IT 임원에 대한 최근 IBM 설문조사에 따르면 현재 마이크로서비스 사용자의 78%가 아키텍처에 투자한 시간, 비용 및 노력을 늘릴 것으로 기대하며, 비사용자의 56%가 향후 2년 내에 마이크로서비스를 채택할 것으로 예상됩니다.

모든 통합, 테스트 및 배치가 동일 환경에서 발생하므로, 모든 OS 종속성을 패키징하고 영구 교정하여 컨테이너는 빠른 CI/CD 및 배치 사이클을 가능하게 합니다. 그리고 Kubernetes 오케스트레이션은 Ansible, Puppet 및 Chef가 비컨테이너화된 애플리케이션에 대해 수행하는 것과 동일한 지속적인 구성 태스크를 컨테이너화된 애플리케이션에 대해 수행합니다.

AWS, Google, Microsoft Azure 및 IBM Cloud를 포함한 대부분의 선도적인 클라우드 컴퓨팅 제공자들은 일종의 관리형 DevOps 파이프라인 솔루션을 제공합니다.

DevSecOps란?

DevSecOps는 시작부터 완료까지, 계획에서 피드백을 거쳐 다시 계획까지, DevOps 라이프사이클 전체에서 보안을 지속적으로 통합하고 자동화하는 DevOps입니다.

이를 다른 방식으로 설명하자면, DevSecOps는 DevOps가 처음부터 의도하고자 했던 모습입니다. 그러나 DevOps 채택의 두 가지 초기의 중요한(그리고 당분간은 극복할 수 없는) 과제는 보안 전문 지식을 교차 기능 팀에 통합(문화적 문제)하는 것과 보안 자동화를 DevOps 라이프사이클에 적용(기술적 문제)하는 것이었습니다. 보안은 "'아니요'의 팀"으로 간주되었으며, 다수의 DevOps 사례에서 비용이 많이 드는 병목 현상으로 인식되었습니다.

DevSecOps는 원래 의도한 대로 보안을 통합하고 자동화하기 위한 구체적인 노력으로 나타났습니다. DevSecOps에서 보안은 개발 및 운영과 함께 "1등급" 시민이자 이해 당사자이며, 제품 초점을 통해 개발 프로세스에 보안을 제공합니다.

DevOps 및 사이트 신뢰성 공학(SRE)

사이트 신뢰성 공학(SRE)은 소프트웨어 엔지니어링 기술을 사용하여 달리 시스템 관리자가 수동으로 수행했을 수 있는 프로덕션 시스템 관리, 변경 관리, 인시던트 대응, 심지어는 비상 대응 등의 IT 운영 태스크를 자동화합니다. SRE는 기존의 시스템 관리자를 엔지니어로 전환시키고자 노력합니다.

SRE의 궁극적인 목표는 DevOps의 목표와 유사하지만, 이보다 구체적입니다. SRE는 신속한 애플리케이션 개발에 대한 기업의 요구사항과 고객 및 최종 사용자와의 서비스 수준 계약(SLA)에 명시된 성능 및 가용성 수준을 충족시켜야 할 필요성 간에 균형을 유지하고자 합니다.

사이트 신뢰성 엔지니어는 "오차할당"이라고 하는 애플리케이션에 의해 야기된 운영 리스크의 허용 가능한 수준을 판별하여, 그리고 해당 수준을 충족시키기 위한 운영의 자동화를 통해 이러한 균형을 달성합니다.

교차 기능 DevOps팀에서 SRE는 개발과 운영 간의 가교 역할을 할 수 있으며, 기업 SLA의 이용약관을 위반하지 않고 가능한 한 신속하게 DevOps 파이프라인을 통해 코드 변경사항과 신규 기능을 푸시하기 위해 팀에 필요한 메트릭과 자동화를 제공합니다.

 

출처 : https://www.ibm.com/kr-ko/cloud/learn/devops-a-complete-guide