지속적인 업데이트를 사용해 적은 비용과 위험으로 더 빠르게 릴리스하기
지속적인 업데이트는 DevOps 분류의 8가지 기능 중 하나입니다.
지속적인 업데이트가 필요한 이유 알아보기
2012년, 당시 미국 최대 증권 회사이던 Knight Capital Group이 소프트웨어 배포 오류로 인해 4억 6,000만 달러의 손실을 입었습니다.
시장이 열리자 손실이 시작되었습니다. 코드에는 버그가 없었지만 8대의 운영 서버 중 한 대에 수동 배포를 하는 동안 오류가 발생해 문제가 생겼습니다.
문제를 바로잡으려다가 8개 서버가 전부 불통이 되었고, 결국 더 많은 손실을 입었습니다. 모든 배포가 수동이어서 변경 사항을 자동으로 되돌릴 수 있는 방법이 없었습니다.
45분 동안 문제 해결을 시도하다가 결국 시스템 전체를 종료했습니다. 이미 4억 6,000만 달러의 손실을 입은 후였습니다.
실제로 있었던 일입니다. 여러분 조직에는 어떤 영향을 미칠까요? 수동 배포를 하고 계십니까?
조직의 업데이트 수행을 이해하는 데 도움이 되는 가장 중요한 질문은 이것일 겁니다.
중요
제품에 배포하는 게 얼마나 힘듭니까?
엔지니어와 기술진이 제품에 코드를 입력할 때 느끼는 두려움과 불안은 팀의 소프트웨어 업데이트 수행에 대해 많은 것을 말해 줍니다.
지속적인 업데이트란?
중요
지속적인 업데이트는 팀이 소프트웨어를 짧은 주기로 생산하는 소프트웨어 엔지니어링 기반 접근 방법으로, 다음과 같은 능력을 보장합니다.
- 언제든지 안정적으로 릴리스함
- 수동으로 릴리스함
지속적인 업데이트의 목적은 다음과 같습니다.
- 소프트웨어를 더 빠른 속도와 잦은 빈도로 빌드하고, 테스트하고, 릴리스함
- 제품의 애플리케이션에 증분 업데이트를 허용하여 발생하는 변경 사항에 대한 비용, 시간, 위험을 축소
다음과 같은 경우 지속적인 업데이트가 가능합니다.
- 소프트웨어를 수명 주기 내내 배포할 수 있음
- 업데이트 주기를 통틀어 어느 단계에서든 광범위한 업데이트뿐만 아니라 연속 통합까지 배포 파이프라인을 통해 가능함
- 언제든지 단추만 누르면 어떤 운영 환경이든 모든 버전의 소프트웨어 배포가 가능함
대규모 수동 배포는 릴리스되는 소프트웨어의 복잡성이 대폭 증가하고, 인적 오류 발생 가능성이 생기며, 배포 오류의 발견 및 수정이 어려워져 위험도가 높습니다. 배포 빈도가 드물고, 변경 사항의 리드 타임이 길고, 평균 복구 시간이 길어서 변경 실패율이 높습니다.
지정된 운영 팀은 업무 시간을 피해서 수동 배포를 시행합니다. 수동 배포 설명서와 시간이 있어야 기록된 단계를 수동으로 테스트할 수 있습니다. 대규모 배포는 실행하는 데 시간이 더 오래 걸리고, 실패할 경우 롤백하기가 더 어렵고, 배포 후 테스트 범위가 더 광범위합니다. 배포 당 변경 사항의 수가 더 많고 피드백을 반영하는 데 시간이 더 오래 걸립니다.
프로세스를 자동화하고 언제든지 제품에 릴리스할 수 있도록 하는 지속적인 업데이트의 이점이 크고 많습니다.
- 낭비 절감
- 신속한 투자 수익률
- 위험 감소
- 품질 향상
- 초기 피드백
- 더 나은 계획
- 신속한 협업
- 모든 사람의 참여
- 제품 문제 감소
- 신속한 보안 능력
- 훨씬 신속한 조정 및 대응
- 훨씬 예측 가능한 릴리스
- 업무 시간에 언제든지 배포
- 시장 변화에 신속하게 반응
- 큰 지연 없이 변경 사항 업데이트
- 팀원 누구나 배포 가능
- 빠르고, 반복 가능하며, 설정 가능한 배포
2019년도 DevOps 상태 보고서에 따르면 고성과 DevOps 조직은 저성과 조직과 비교해 다음을 달성합니다.
- 200배 이상 잦은 배포
- 100배 이상 빠른 변경 사항 리드 타임
- 2600배 이상 빠른 평균 복구 시간
- 7배 이상 낮은 변경 실패율
또한 CA 테크놀로지스의 글로벌 연구에 따르면, 조직은 출시 기간을 최대 20% 단축하고 수익 증대를 실현할 수 있습니다.
참고
지속적인 업데이트는 지속적인 배포와 혼동되는 경우도 있습니다. 지속적인 배포는 모든 변경 사항이 파이프라인을 통해 자동으로 제품에 적용되므로 매일 여러 차례 제품 배포가 이루어집니다. 지속적인 업데이트는 배포를 자주 할 수 있지만, 대개 기업이 배포를 더 천천히 하는 것을 선호하여 그렇게 하지 않을 수도 있습니다. 지속적인 배포를 하려면 지속적인 업데이트를 해야 합니다.
연속 통합은 지속적인 업데이트의 필수 조건입니다. 구현 과정을 통해 소스 제어에서 항상 고품질의 애플리케이션을 빌드하고 (안정적으로) 배포할 수 있습니다.