1.7.2 소프트웨어 개발/전달 프로세스
폭포수(waterfall) 개발 프로세스16로 마이크로서비스 아키텍처를 구축하는 것은 말이 페라리를 끌고 가는 모양새입니다. 마이크로서비스의 편익을 대부분 날려 버리는 꼴이죠. 애자일 개발 프로세스를 도입하고 스크럼(scrum), 칸반(Kanban) 등을 실천해야 합니다. 데브옵스의 일부인 지속적 전달/배포를 실천하면 금상첨화입니다!
지속적 전달은 새 기능, 구성 변경, 버그 조치, 실험 등 갖가지 변경분을 프로덕션 또는 사용자에게 직접 안전하고 신속하게, 일정한 수준으로 계속 전달하는 능력이다.
제즈 험블(Jez Humble)17
지속적 전달의 핵심은 소프트웨어를 언제라도 릴리스(release, 출시, 발표, 공개)할 수 있는 능력입니다. 따라서 자동화 테스트 등 높은 수준의 자동화는 필수입니다. 지속적 배포는 이보다 한 발 더 나아가 릴리스 가능한 코드를 프로덕션에 자동 배포하는 것입니다. 지속적 배포를 실천하는 고성능 조직은 하루에 프로덕션 배포를 여러 차례 수행하면서도 프로덕션 중단 사고는 거의 없고, 설령 사고가 발생해도 신속하게 복구합니다.18 마이크로서비스 아키텍처는 지속적 전달/배포를 직접 지원합니다(1.5.1절).
Note≡ 중단 없이 재빠르게 움직여라
지속적 전달/배포(더 일반적으로는 데브옵스)의 목표는 신속하고 확실하게 소프트웨어를 전달하는 것입니다. 다음은 소프트웨어 개발 수준을 평가하는 네 가지 유용한 잣대입니다.
• 배포 빈도(deployment frequency): 소프트웨어를 얼마나 자주 프로덕션에 배포하는가?
• 리드 타임(lead time): 개발자가 변경분을 체크인할 때부터 프로덕션에 배포할 때까지 걸린 시간
• 평균 복구 시간(MTTR, Mean Time To Recover): 프로덕션 문제 복구에 소요된 시간
• 변경분 실패율: 프로덕션에 문제를 일으킨 변경분의 비율(%)
예전에는 배포는 가끔씩 하고 리드 타임은 긴 조직이 많았습니다. 보수 기간 동안 개발/운영자는 스트레스를 지독하게 받은 상태로 막바지 이슈를 조치하느라 밤도 곧잘 새곤 했죠. 데브옵스 조직은 하루에 여러 차례 소프트웨어를 릴리스하면서도 외려 프로덕션 이슈는 별로 없습니다. 2014년 자료19에 따르면 아마존은 11.6초당 한 번씩 프로덕션에 변경분을 배포하고, 넷플릭스는 소프트웨어 컴포넌트당 리드 타임이 16분에 불과합니다.20