CI/CD 성능 측정 & 모니터링
지속적인 개선은 DevOps 철학의 초석 중 하나입니다.
지속적인 개선은 개발 중인 제품 혹은 서비스에서부터 조직의 문화나 프로세스를 포함한 소프트웨어 개발의 모든 측면에 적용됩니다.
지속적 개선에는 어떤 부분의 성능이 좋고 어디에 개선이 필요한지 파악하기 위해 개발 중인 제품이나 작업 방식에 대한 피드백을 수집하고 분석하는 것을 포함합니다. 이런 인사이트를 적용한 이후 피드백을 추가적으로 수집하여 변경 사항이 올바른 결과를 도출하는지 보고 필요한 경우 조정할 수 있습니다.
CI/CD 파이프라인은 소프트웨어를 지속적으로 개선하는 데 있어 중추적인 역할을 합니다. 개발에서 배포까지 걸리는 시간을 단축함으로써 사용자에게 변경 사항을 더 자주 릴리스하고 프로덕션에서 사용하면서 발생한 피드백을 얻고 다음 우선순위를 결정하는 데 활용할 수 있습니다. 이와 마찬가지로 자동화된 테스팅의 각 단계에서 빠르게 제공되는 피드백으로 손쉽게 버그를 해결하고 소프트웨어 품질을 유지하는 데 도움을 받을 수 있습니다.
그러나 지속적 개선은 여기에서 멈추지 않습니다. CI/CD 파이프라인 자체에 동일한 기술을 적용하여 소프트웨어의 빌드, 테스팅 및 릴리스 프로세스를 다듬을 수 있으며, 이렇게 하면 제품을 개선할 때 사용하는 피드백 루프가 강화됩니다.
파이프라인 지표의 이해
"측정하지 않는 것을 관리할 수는 없다"는 말이 있습니다.
측정 지표는 시스템 성능을 개선하는 데 중요한 도구입니다. 가치를 더할 수 있는 곳은 어디인지 식별하고 개선 사항이 미치는 영향을 측정하여 비교할 때 사용할 비교 기준을 설정하는 데 도움을 줍니다.
CI/CD의 성능은 성능과 품질 모두를 포함합니다. 변경 사항을 빠르게 배포하는 것과 높은 신뢰도와 완성도의 제품을 전달하는 일 사이에 트레이드오프 관계가 있어서는 안 됩니다. 고성능 CI/CD 파이프라인은 둘 다 가능하게 합니다.
활동의 속도, 소프트웨어의 품질 및 자동화를 사용하는 정도를 측정하고 모니터링하면 개선할 수 있는 영역을 식별한 다음 변경 사항이 긍정적인 결과를 냈는지 확인할 수 있습니다.
고수준 성능 DevOps 측정 지표
다음의 네 가지 측정 지표는 DevOps 연구 평가(DORA)에서 조직이 소프트웨어 개발 환경에서 얼마나 잘 일을 하고 있는지를 정확하게 측정하는 고수준 측정 지표로 지목되었습니다.
You can learn more about the research that informed these choices in the book Accelerate.
리드 타임
전달 시간 혹은 시당 도달 시간으로도 알려진 리드 타임은 기능이 제안되고 실제 사용자에게 릴리스되기까지의 시간으로 정의됩니다. 그러나 관념화, 사용자연구 및 프로토타입에 소요되는 시간은 매우 유동적인 경우가 많습니다.
이러한 이유 때문에 DORA는 먼저 코드가 커밋되고 배포될 때까지 걸리는 시간을 측정하는 접근법을 택했습니다. 이 방법에서는 CI/CD 파이프라인 내의 단계에 집중할 수 있습니다.
리드 타임이 길면 코드 변경 사항이 사용자에게 정기적으로 전달되지 않기 때문에 피드백을 받아 빌드중인 소프트웨어를 다듬을 수 없습니다. 여기에는 여러 요소가 있을 수 있습니다.
다수의 수동 테스트, 리스트 평가 혹은 변경 사항 검토 위원회 등과 같은 수작업 절차를 포함한 릴리스 파이프라인은 프로세스에 수일 혹은 수주를 추가하며 빈번한 릴리스의 장점을 희석시킬 수 있습니다.
자동화 테스팅에 투자하면 전자의 문제를 해결할 수 있으나 후자의 문제는 당사자와 협의하여 어떻게 하면 당사자의 수요를 효율적으로 충족할 수 있는지 이해하는 과정이 필요합니다. 다른 대안으로 자동화 과정이 느리거나 신뢰할 수 없는 경우 빌드 시간 지표를 사용하여 가장 오랜 시간이 걸리는 단계를 식별할 수 있습니다.
배포 빈도
배포 빈도는 CI/CD 파이프라인을 사용하여 프로덕션으로 배포하는 회수를 기록합니다. 높은 배포 빈도는 매 배포마다 변경 사항이 적다는 의미이므로 DORA는 배포 빈도를 배치 크기의 프록시로 선택하였습니다.
적은 수의 변경사항을 자주 배포하면 결합하여 예상하지 못한 결과를 초래하는 변수가 줄어드므로 릴리스와 관련된 리스크를 줄일 수 있고 피드백을 더 빨리 받을 수 있습니다.
배포 빈도가 낮다는 것은 파이프라인에 정기적으로 커밋이 제출되지 않고 있다는 의미이며 이는 작업이 잘 나뉘지 않고 있거나 변경 사항이 큰 릴리스로 취합되고 있기 때문일 수 있습니다.
사용자 기대와 같은 사업적 이유로 변경 사항이 배치로 취합되어야 하는 경우 대신 스테이징 사이트로 배포하는 빈도를 측정하면 배치 사이즈를 모니터하고 작은 단위로 작업하는 것의 혜택을 보고 있는지 평가할 수 있습니다.
변경 실패율
변경 실패율은 프로덕션으로 배포되는 변경사항 중 중단 혹은 버그와 같이 롤백이나 핫픽스가 필요한 고장을 초래하는 변경 사항의 비율을 의미합니다. 이 지표의 장점은 전체 변경 사항에서 실패한 배포를 볼 수 있다는 것입니다.
낮은 변경 실패율은 파이프라인의 신뢰도를 높입니다. 이는 파이프라인의 초기 단계가 제역할을 하고 있고 코드가 프로덕션으로 배포되기 전에 대부분의 결함을 잡아낸다는 의미입니다.
평균 복구 시간
평균 복구 혹은 해결 시간(MTTR)은 프로덕션 오류를 해결하는 데 걸리는 시간을 측정합니다. MTTR은 다양한 변수의 복잡한 시스템의 경우 프로덕션에서 일부 오류는 불가피하다는 것을 고려합니다. 완벽함을 목표로 하며 릴리스 속도를 늦추고 빈번한 릴리스의 이점을 포기하기 보다는 이슈에 빠르게 대응하는 것이 더 중요합니다.
MTTR을 낮게 유지하려면 프로덕션의 시스템을 선제적으로 모니터링하여 문제가 발생하면 경고를 받도록 해야 하고 변경 사항을 롤백하거나 파이프라인을 통해 수정 사항을 빠르게 배포할 수 있어야 합니다.
이와 관련된 지표인 평균탐지시간(MTTD)는 변경사항이 배포된 후 모니터링 시스템이 해당 변경사항으로 인해 발생하는 이슈를 탐지할 때까지 걸리는 시간을 측정합니다. MTTD와 빌드 시간을 비교함으로써 각 영역에 투자를 하면 MTTR을 줄일 수 있을지 판단할 수 있습니다.
CI 및 운영 지표
이런 높은 수준의 방법 이외에도 파이프라인의 성능을 더 잘 이해하고 프로세스를 개선할 수 있는 영역을 식별하는 데 이용할 수 있는 다양한 부가 지표가 있습니다.
코드 커버리지
CI/CD 파이프라인에서 자동화 테스트는 테스트 범위의 대부분을 담당하며 QA 엔지니어의 부담을 줄여 실험적인 테스트나 새로운 테스트 케이스를 정의하는 데 집중할 수 있게 합니다. 수행되는 자동화 테스트의 첫 번째 레이어는 실행이 가장 빠르고 즉각적인 피드백을 주는 유닛 테스트여야 합니다.
코드 커버리지는 대부분의 CI 서버가 제공하는 지표로서 유닛 테스트가 수행되는 코드의 비율을 계산합니다. 이 지표를 모니터링하여 코드를 작성할 때 적절한 테스트 커버리지를 유지하고 있는지 확인하는 것이 좋습니다. 코드 커버리지가 하향세를 보이고 있다면 피드백의 이 첫 줄을 조금 작업해야 할 때입니다.
빌드 시간
빌드 시간은 자동화된 파이프라인의 다양한 단계를 완료하는 데 걸리는 시간을 측정합니다. 프로세스의 각 단계에 사용된 시간을 측정하는 것은 테스트에서 피드백을 받을 때까지 혹은 라이브 환경으로 배포할 때까지 걸리는 전체적인 시간을 지연시키는 문제점이나 병목 지점을 식별하는 데 유용합니다.
테스트 통과율
테스트 통과율은 빌드 내에서 테스트를 성공적으로 통화한 케이스의 비율입니다. 합리적인 수준의 자동화 테스트를 시행하는 한 이는 각 빌드의 품질을 측정하는 좋은 지표입니다. 이 지표를 사용하여 코드 변경 사항이 얼마나 자주 테스트 실패로 이어지는지 이해할 수 있습니다.
자동화 테스트로 오류를 식별하는 것이 수동 테스트나 프로덕션에서 이슈를 발견하는 것보다 이상적이지만 특정한 자동화 테스트 세트가 정기적으로 실패한다면 이러한 오류의 근본 원인을 살펴보는 것이 좋습니다.
테스트 수정 시간
테스트 수정 시간은 빌드에서 테스트 실패가 보고될 때부터 다음 빌드에서 해당 테스트가 통과할 때까지의 시간입니다. 이 지표를 활용하면 파이프라인에서 식별된 이슈에 얼마나 빠르게 대응할 수 있는지 알 수 있습니다.
이 시간이 짧으면 파이프라인을 최대한 효율적으로 활용하고 있다는 의미입니다. 이슈를 발견 즉시 해결함으로써 변경 사항이 아직 잘 기억날 때 효율적으로 작업할 수 있고 불안정한 코드에 기능을 추가하는 것을 방지할 수 있습니다.
배포 실패
배포 실패로 인해 의도하지 않은 중단 시간이 발생하는 경우 해당 배포를 롤백하거나 즉시 수정해서 릴리스해야 합니다. 실패한 배포의 수는 위에서 설명한 변경 실패율을 계산하는 데 사용됩니다.
전체 배포수에서 실패하는 비율을 모니터링하면 SLA 대비 성능을 측정하는 데 도움이 됩니다.
그러나 0 혹은 매우 적은 배포 실패를 목표로 삼는 것은 현실적이지 않으며, 팀이 확실성을 우선시하도록 장려하는 것일 수도 있습니다. 그러면 변경 사항이 배치로 취합되어 리드타임이 길어지고 배포가 커집니다. 이는 변수가 많아지므로 프로덕션에서에서 오류가 발생할 가능성을 높이며 처리해야 할 변경사항도 많아지므로 오류를 고치기도 어려워집니다.
결함 개수
오류와 달리 결함 개수는 백로그 상에서 버그로 분류된 열린 티켓의 수를 의미합니다. 이는 테스트 혹은 스테이징에서 발견된 이슈나 프로덕션에서 발견된 이슈로 추가 분류될 수 있습니다.
코드 커버리지와 같이 결함 개수를 모니터링하는 것은 버그가 통제불능이라는 것을 의미할 수도 있는 일반적인 상향 추세에 대한 경고를 받는 데 유용합니다. 그러나 이 지표를 목표로 삼으면 팀이 티켓을 해결하기 보다는 분류하는 것에 더 집중하게 만들 수도 있다는 것을 유념하세요.
배포 크기
위에서 설명된 배포 빈도와 직접적인 연관이 있는 배포 크기는 빌드나 릴리스에 포함된 스토리 포인트 개수로 측정되며 팀 내에서 배치 크기를 모니터링하는 데 사용될 수 있습니다.
팀 내에서 배포 크기를 작게 유지된다는 것은 정기적으로 커밋이 이뤄지고 그 이점이 잘 활용되고 있다는 의미입니다. 그러나 개발 팀 간에 스토리 예상 시간은 직접 비교할 수 없으므로 이 지표를 사용하여 전체 배포 크기를 비교하면 안 됩니다.
결론
이러한 지표들을 모니터링하면 CI/CD 파이프라인의 성능을 이해하고 현재 상향 혹은 하향 추세에 있는지 이해하는 데 도움이 됩니다.
이런 지표들을 사용하여 주의를 더 기울여야 하는 영역을 식별할 수 있습니다. 변경 사항을 만든 후에는 관련된 지표를 지속적으로 모니터링하여 의도된 효과를 냈는지 검증하는 것이 좋습니다.
그러나 이런 지표들이 성능을 보여주기 때문에 유용하긴 하지만 맥락을 이해하며 수치를 읽고 특정 지표에 집중하면 어떤 행동이 장려되는지 고려하는 것이 중요합니다. 목표는 수치 자체가 아니라는 것을 유념하되 파이프라인을 빠르고 안정적으로 유지하여 사용자들에게 가치를 지속적으로 전달해야 합니다.