지속적인 업데이트 배포 모델
소프트웨어 전달 모델로서 “대규모 배포”의 여러 가지 단점에 대해 알아보았습니다. 하지만 제대로 작동하지 않는 기능이 무엇인지 아는 것이 유일한 문제입니다. 이 단원에서는 획일적인 방식에 대한 대안과 향상된 안정성 목표를 발전시키는 방법을 알아보겠습니다.
지속적인 업데이트란?
지속적인 업데이트는 소프트웨어 변경 사항을 스트레스 없이 더 빠르고, 덜 위험하고, 재현하기 쉬운 방식으로 사용할 수 있도록 하는 방법입니다. 각 소프트웨어 배포나 업데이트를 만들지 않고 대규모 이벤트인 지속적인 업데이트는 필요 시 발생하는 빠르고 일상적이며 예측 가능한 환경으로 전환합니다.
배포 빈도: 지속적인 업데이트 모델을 사용하면 배포가 자주 수행됩니다. 매월, 매주, 매일, 심지어 매시간 배포할 수 있습니다. 핵심은 더 작고 집중된 변경 사항을 더 자주 배포하는 것입니다.
코드 커밋으로 시작: 사전에 예약하는 대신, 코드가 커밋될 때 배포를 수행합니다. 이 코드는 소프트웨어나 인프라이거나, 소프트웨어 구성과 같은 것일 수 있습니다.
자동화된 테스트: 통합된 자동화된 테스트를 사용하여 코드를 테스트할 뿐만 아니라 테스트 결과에 대한 빠른 피드백을 제공할 수도 있습니다. 실패한 테스트를 신속하게 반복하고 복구할 수 있는 빠른 피드백입니다.
코드를 테스트한 후에는 테스트, QA 등과 같은 일련의 준비된 환경에서 종단 간에 배포를 테스트할 수 있습니다. 환경을 통해 배포를 롤링하면 배포 환경에 통합된 한 부분이 됩니다.
기록 레코드: 배포 작업에 대한 기록 레코드를 원하는 경우 뿐만 아니라 언제든지 프로덕션 환경을 조정할 수 있어야 할 때 수행합니다. 현재 프로덕션 환경을 만든 배포를 파악하려고 합니다. 이 정보를 사용하여 구성, 테스트 결과 및 코드 자체를 추적하여 배포를 트리거한 개별 끌어오기 요청으로 되돌릴 수 있습니다.
배포 목표
지속적인 업데이트의 작동 방식을 알고 있으므로 소프트웨어 솔루션 배포 경우처럼 DevOps 방법을 사용하여 달성할 수 있는 목표를 고려합니다.
목표 1: 서비스 배포와 관련된 스트레스를 줄이고 그러한 서비스의 안정성 높이기
이는 윈윈(win – win) 전략입니다. 소프트웨어 및 인프라 배포와 관련된 스트레스를 줄임으로써 작업 만족도를 높일 뿐만 아니라, 사용자의 시스템을 보다 안정적으로 만들어 작업 만족도와 최종 사용자 만족도를 모두 높일 수 있습니다. 이러한 긍정적인 영향을 사용자 환경에 제공하면 기술적인 면에서 윈윈윈(win – win – win)입니다.
목표 2: 변경이 필요한 시점과 변경 내용이 프로덕션 환경에 배포되는 시점 사이의 시간 줄이기
예를 들어 수익에 영향을 주는 코드 결함을 확인했다고 가정합니다. 문제가 무엇인지 정확하게 알고 해결 방법을 코딩하는 방법을 알고 있습니다. 해당 코드를 프로덕션 환경으로 가져오는 데 시간이 얼마나 소요됩니까? 얼마나 많은 줄을 끌어와야 하나요? 어떻게 테스트합니까? DevOps 방법을 사용하여 코딩 커밋을 수행하고, 점심 식사를 한 후에 자리에 돌아오기 전에 문제가 해결되었다는 알림을 받을 수 있습니다.
목표 3: 아이디어를 갖고 사용 가능한 소프트웨어를 제공하는 시간 단축
이 목표는 이전 목표와 매우 유사하지만, 변경 내용을 구현하는 대신 순수하게 혁신에 대해 이야기하겠습니다. 혁신적인 조치를 취하는 데 얼마나 걸립니까? 이 배포 모델을 사용하여 새로운 개념을 프로덕션 시스템에 통합할 수 있고, 추가된 혁신으로 인해 현재 시스템이 어떤 방식으로든 중단되지 않는다는 확신을 가질 수 있습니다. 이 확신을 통해 새 기능을 신속하게 제공할 수 있습니다.
배포 결과
이 단원에서 토론되는 목표는 단순한 이론적 바램이 아니라 달성 가능합니다. 다음은 DORA(DevOps Research and Assessment) 및 Google Cloud DevOps & SRE가 2019 Accelerate State of DevOps Report에서 발표한 몇 가지 통계입니다. 이들은 여기서 “높은 성과를 내는” DevOps 회사를 발견했습니다.
- 배포 수가 208배 이상입니다.
- 커밋에서 배포까지 106배 이상 빠릅니다.
- 변경 실패율이 7배의 이하입니다.
- 인시던트 복구 시간이 2,604배 이상 빠릅니다.
따라서 수익이 늘어나고 출시 기간이 빨라집니다.
이러한 숫자는 배포 방법이 문제가 되는 아이디어를 확인합니다.