개발-운영 생산성 모니터링하기 (with Devlake, Grafana)

개요

안녕하세요. 인프랩 데브옵스 인턴 구피입니다!

여러분들은 개발하시는 프로젝트에서 기능이 개발 후 배포되기까지 평균 얼마의 시간이 걸리는지 아시나요?
또는, 운영 중인 서비스에서 발생한 장애가 해결되기까지 평균적으로 몇 시간이 걸리는지 아시나요?

이러한 통계는 서비스가 얼마나 효율적으로 개발되고 배포되는지, 즉 데브옵스가 얼마나 잘 구축되어 있는지와 관련되어 있는데요. 데브옵스의 생산성 정도를 측정하기 위한 대표적인 지표로 DORA 메트릭이라는 개념이 있습니다.

이번 글에선 인턴 과제로 Devlake와 Grafana를 사용해 DORA 메트릭 대시보드를 구축했던 경험을 공유하고자 합니다!

DORA 메트릭이란?

Google Cloud에는 개발 및 운영 프로세스에서의 생산성을 측정하고 연구하는 DevOps Research and Assessment(DORA) 팀이 있습니다. DORA 팀은 매년 여러 기업의 전체 개발 생산성 현황을 총체적으로 분석한 보고서를 발표해오고 있습니다.

이 팀에서 개발팀의 생산성을 측정하는 주요 지표로 꼽은 4가지가 있는데요. 이를 DORA 메트릭이라고 부릅니다. 이 지표를 활용하면 데브옵스가 비즈니스 가치에 어떻게 기여하고 있는지, 개발팀의 생산성 추세가 어떠한지를 알 수 있습니다.

DORA 메트릭은 배포 생산성을 측정하는 지표 두 가지와 소프트웨어의 안정성을 측정하는 지표 두 가지로 나뉩니다.

각 메트릭의 자세한 의미는 아래와 같습니다.

생산성 지표 (Throughput Metrics)

• 배포 빈도 (Deployment frequency)

  • 배포 빈도는 운영 환경에 새 코드를 배포하는 빈도를 계산한 값입니다.
  • 개발한 기능을 고객에게 빠르게 전달하고 있는지를 직관적으로 확인할 수 있는 지표입니다.
  • 배포 빈도를 높이기 위해선 코드를 검증하고 배포하기 위한 절차를 자동화하거나 변경 사항을 작은 단위로 분할하는 방법을 사용할 수 있습니다.

• 변경에 걸리는 시간 (Lead time for changes)

  • 변경 리드 타임은 커밋이 프로덕션 환경에 배포될 때까지의 간격입니다. 개발자가 개발을 마친 후 코드 검토나 배포를 기다리는 동안 지연이 얼마나 발생하는지를 나타냅니다.
  • PR이 리뷰되는 데 걸리는 시간, PR 머지 후 배포까지의 시간 등 개발과 배포 사이의 단계를 상세하게 나누어 추적하면 더욱 유익한 분석을 얻을 수 있습니다.

안정성 지표 (Stability Metrics)

• 변경 실패율 (Change failure rate)

  • 운영 배포 이후에 버그가 발생한 비율을 나타냅니다.
  • 변경 실패율이 높다면 더 꼼꼼한 코드 리뷰나, 배포 과정에서 자동화된 테스트가 필요할 수 있습니다.

• 서비스 복원 시간 (Mean time to recovery)

  • 버그가 발생한 뒤 서비스가 완전히 복원될 때까지 걸린 평균 시간입니다.
  • 서비스 복원 시간을 줄이기 위해선 하나의 오류가 다른 기능에 주는 영향을 줄여야 하고, 코드를 작성한 사람이 아닌 다른 개발자도 버그를 복원할 수 있도록 상세한 문서화가 필요할 수 있습니다.
  • 또, 상세한 모니터링 정보를 남겨 버그가 어느 코드에서 일어났는지 빠르게 파악할 수 있어야 합니다.

DORA 메트릭의 목적

데브옵스의 목표는 높은 품질의 안정적인 제품을 신속하게 출시하는 것입니다.

이를 위해 애자일 등 방법론을 활용할 수도 있고, CI/CD 파이프라인이나 모니터링을 구축할 수 있지만 그러한 것들이 서비스 개발 과정을 얼마나 효율화 시켜주는지를 직관적으로 파악하기는 힘듭니다.

그렇기 때문에 DORA 메트릭을 수집하고 모니터링하는 것이 중요합니다. 이러한 메트릭이 변하는 추세를 모니터링한다면 데브옵스 구축이 개발 과정을 얼마나 효율화하는지 분석하고 개선할 부분이 무엇인지 상세하게 파악할 수 있습니다. 사용자가 만족할 만한 품질의 서비스를 제공하기 위해 개발, 배포 프로세스의 개선 방안을 고려할 때 이러한 지표를 참고하면 개발과 운영의 생산성을 더욱 향상시킬 수 있습니다.

사용 툴 선택

DORA 메트릭을 수집하고 모니터링하기 위한 방법을 선택하기 위해 몇 가지 툴을 조사하여 비교해보았습니다.

인프랩에서 사용하고 있는 Jira, Github, Jenkins에서 이슈와 배포 정보를 쉽게 연동할 수 있으면서 구축 비용이 부담스럽지 않은 툴을 선택하고자 했습니다. 또, DORA 메트릭 외 데브옵스 생산성을 추적하기 위한 다양한 지표를 모니터링할 수 있는지 여부도 함께 고려하였습니다.

compass

• Atlassian에서 개발한 Compass는 프로젝트 및 시스템의 상태를 편하게 관리하기 위한 서비스입니다. 각 프로젝트에서 일어난 이벤트를 볼 수 있고, DORA 메트릭을 수집하여 모니터링할 수 있습니다.

• Jira와 Github 정보를 연동하기 쉽고, 여러 프로젝트들을 체계적으로 관리할 수 있는 기능을 제공합니다.

• 하지만 배포 정보 연동시 API를 사용해야하기 때문에 번거롭고, 서비스상에서 기본적으로 연동해주는 메트릭이 다양하지 않다는 단점이 있었습니다.

Sleuth

• DORA 메트릭 통계를 추적하고 관련된 자동화를 구현할 수 있는 서비스입니다.

• 다양한 서비스와 연동하기 쉽고 PR 작업 사이클별 평균 소요시간 등 세부적인 데이터를 나누어 조회할 수 있습니다. 대시보드의 가독성이 좋아 DORA 메트릭 데이터를 한눈에 쉽게 파악할 수 있습니다.

• 하지만 도입 비용에 대한 부담이 있고 통계 메트릭이나 대시보드를 커스텀할 수 없다는 점이 아쉬웠습니다.

Apache Devlake

• DORA 메트릭 등 개발 프로세스 정보를 수집하여 모니터링할 수 있도록 하는 오픈소스 프로젝트입니다.

• JIRA 이슈 평균 해결기간, 커밋의 크기, PR별 코멘트 수 등 다양한 통계를 집계할 수 있습니다.

• Grafana를 대시보드로 사용하기에 DB에 저장된 정보를 바탕으로 자유롭게 커스텀할 수 있습니다.

세 가지 툴을 검토해본 결과, Devlake가 가장 적합한 툴이라고 판단하였습니다.
이유는 크게 두가지입니다.

1. 다양한 커스텀: Devlake를 사용하면 기본적인 DORA 메트릭 외에도 개발 생산성에 대한 다양한 데이터를 수집하여 통계를 낼 수 있습니다. 다른 서비스보다 목적에 맞게 자유롭게 커스텀할 수 있어 유연하게 활용할 수 있습니다.

2. 적은 비용: 다른 SaaS 서비스는 개발자 당 비용을 지불해야하는 방식이라 부담스러운 데 비해 Devlake는 오픈소스 기반이기 때문에 실행하는 리소스 외의 추가 비용이 들지 않습니다. DORA 메트릭 활용이 익숙하지 않은 상황에서 비용 부담 없이 비교적 가볍게 시도해볼 수 있습니다.

따라서 Devlake를 사용해 DORA 메트릭 대시보드를 구축하기로 결정하였습니다!

Devlake + Grafana 대시보드 구축

인프라 구성

Devlake는 외부 서비스의 API로부터 정보를 가져와 MySQL Database에 저장합니다. 그리고 이후 Grafana에서 MySQL 데이터를 조회하여 DORA 메트릭에 대한 대시보드를 볼 수 있습니다.

컨테이너를 실행할 EC2와 데이터베이스로 사용할 RDS를 Pulumi 코드로 선언하여 생성한 후
EC2에 접근해 Devlake와 Grafana 컨테이너를 실행하였습니다.

Devlake 설정

Devlake에서 메트릭을 수집하기 위한 설정 과정을 설명드리겠습니다.

1. Connection 설정

DORA 메트릭을 조회하기 위해선 배포와 풀 리퀘스트, 버그 발생을 추적하기 위한 이슈 정보가 필요합니다. 해당 정보는 다양한 데이터소스에서 가져올 수 있고, 각 정보를 가져올 수 있는 서비스를 적어도 하나는 연동해야 메트릭을 확인할 수 있습니다.

Devlake와 데이터를 가지고 있는 서비스를 연결하는 것을 Connection이라고 부릅니다. Devlake Config UI 컨테이너를 실행하여 접근하면 다른 서비스와의 Connection을 설정할 수 있는 화면이 먼저 보입니다.

사용할 서비스의 목록을 선택하여 Connection을 생성해줍니다. Connection을 생성하기 위해선 각각의 서비스에 알맞는 URL과 계정, 토큰 등을 설정해주어야 합니다.

이번 구축에서는 Github, Jira, Jenkins에 대한 Connection을 하나씩 생성하였습니다.

주의할 점
Devlake는 각 서비스의 API를 사용해 데이터를 가져오는데요. 호출해야하는 API의 수가 많다면 각 API에 걸려있는 Rate limit 제한을 간신히 넘지 않을 속도로 데이터를 불러옵니다. 따라서 다른 곳에서 Devlake에 등록한 것과 같은 계정으로 API를 호출한다면 요청 수 제한에 걸려 작동이 멈출 수 있습니다.

그러므로 Devlake에서는 다른 곳에서 사용하지 않는 별도의 계정 또는 Github Apps 기능을 사용하는 것이 좋습니다!

2. Data Scope 설정

Connection를 생성하면 아래와 같은 화면이 보입니다.

Add Data Scope 버튼을 눌러 연결할 범위를 지정합니다. Github에서는 어떤 레포지토리에 대해 수집할 지를 선택할 수 있고, Jira에서는 보드, Jenkins에서는 Job 단위로 범위를 정할 수 있습니다.

Data Scope 생성 후엔 Scope Config를 지정합니다.

생성 버튼을 눌러 이름과 정보를 알맞게 입력합니다.

Scope Config에는 Transform을 위한 설정 정보가 필요합니다. Devlake는 각 서비스에서 가져온 정보를 테이블에 저장한 후 통계 데이터를 미리 계산하여 별도 테이블에 저장하는데, 이 과정을 Transform이라고 부릅니다.

어떤 태그의 이슈를 버그로 분류할지, 또는 어떤 이름의 배포를 운영 배포로 인식할지 등을 입력하면 됩니다. DORA 태그가 있는 입력 필드는 DORA 메트릭을 수집하기 위해 꼭 정확하게 지정해줘야합니다.

DORA 메트릭 사용을 위해 배포 정보를 수집할 Jenkins에서는 배포 job 이름을, 이슈 정보를 수집한 Jira에서는 버그(Incident)로 인식할 이슈 타입을 별도로 지정해주었습니다.

3. 프로젝트 생성

Connection을 생성하였으니, 데이터를 가져오기 위한 프로젝트를 정의해보겠습니다.

프로젝트 탭에서 프로젝트를 생성할 수 있습니다.
Enable DORA Metric 옵션을 선택해야 프로젝트에 대한 DORA 메트릭 계산 기능이 활성화됩니다.

Add a Connection 버튼을 눌러 아까 생성했던 Connection들을 연결하고, 프로젝트에서 수집할 데이터의 범위를 지정합니다.

Devlake의 프로젝트에는 BluePrint라는 개념이 있습니다. 한 프로젝트는 하나의 BluePrint를 가집니다.

앞서 각 서비스에서 데이터를 불러온 후 통계 데이터를 미리 계산하여 저장하는 Transform 과정에 대해 언급했습니다. BluePrint는 이 Transform을 수행하는 과정에서 연결되는 서비스들을 묶은 단위입니다. Connection을 아래와 같이 추가하면 이 3개의 서비스가 프로젝트의 Blueprint에 연결되고, 이 Connection들 사이에서 서로 연관되는 데이터가 합쳐져 메트릭이 계산됩니다.

4. 데이터 불러오기

생성한 프로젝트로 데이터를 가져와보겠습니다.

Devlake에선 기본적으로 하루에 한 번 데이터를 불러옵니다. Sync Policy로 프로젝트에서 데이터를 불러오는 주기를 직접 설정할 수 있습니다. 매일, 매주, 매월 한 번씩 실행하는 옵션이 있고, Cron 표현식을 사용한 커스텀 설정도 가능합니다.

Collect Data 버튼을 누르면 데이터를 즉시 갱신할 수 있습니다. 화면에서 데이터를 잘 가져오고 있는지 상태를 즉시 확인할 수 있으며, 데이터를 불러왔던 히스토리도 확인할 수 있습니다.

초기 수집시에는 모든 데이터를 가져와야 하기 때문에 실행시간이 오래 걸릴 수 있습니다. 그러나 한 번 데이터를 수집해온 후에는 계정, 레포 정보 등의 메타데이터만 새로 조회하고, 대부분의 내역들은 증분 데이터 수집이 가능하여 더 짧은 시간이 소요됩니다. 데이터별 증분 수집 지원 여부는 공식 문서에서 확인할 수 있습니다!

Grafana 설정

Devlake에서 데이터를 가져오기 위한 설정을 완료하였으니, 데이터를 보기 위한 Grafana 대시보드를 세팅해보겠습니다.

1. 데이터소스 생성

우선 생성했던 RDS를 Grafana에 데이터소스로 등록해줍니다. UI에서 직접 설정하는 방법도 있지만, 설정 정보를 쉽게 옮기고 수정할 수 있도록 하기 위해 Grafana Provision 기능을 사용했습니다.

아래와 같이 yaml 파일로 생성할 데이터소스의 정보를 정의하였습니다.

Grafana를 재시작하면서 Provisioning 설정을 적용할 때 기존에 생성되었던 데이터소스가 중복으로 생성되는 오류를 피하기 위해 deleteDatasource를 사용하여 삭제 후 재생성하도록 했습니다.

apiVersion: 1

deleteDatasources:
  - name: mysql
    orgId: 1

datasources:
  - name: mysql
    type: mysql
    orgId: 1
    uid: mysql
    url: {MYSQL_HOST}:{MYSQL_PORT}
    user: {MYSQL_USER}
    database: {MYSQL_DB}
    secureJsonData:
      password: {MYSQL_PASSWORD}
    version: 1
    editable: false

Grafana 이미지에서 Provision datasource 정보를 정의하는 기본 경로는 /etc/grafana/provisioning/datasources 입니다. 컨테이너 내 해당 경로에 Provision 설정 파일을 추가해주었습니다.

Grafana를 재시작하면 Datasource가 추가된 모습을 볼 수 있습니다.

2. 대시보드 생성

Devlake에서 제공하는 Json파일을 사용해 Grafana에 대시보드를 등록하면 DORA 메트릭 등 여러 지표 통계를 볼 수 있습니다. 저는 해당 Json 파일을 다운로드 받아 다른 개발자분들이 대시보드를 보고 쉽게 이해하실 수 있도록 일부 매트릭 설명을 추가하고 내용을 번역하여 등록했습니다.
대시보드도 데이터소스와 마찬가지로 Provisioning 기능을 사용해 추가해주었습니다.

apiVersion: 1

providers:
- name: dashboards
  orgId: 1
  folder: 'dora'
  folderUid: 'dora'
  type: file
  disableDeletion: false
  editable: true
  updateIntervalSeconds: 10
  options:
    path: /etc/grafana/provisioning/dashboards

위와 같은식으로 설정한 뒤 /etc/grafana/provisioning/dashboards/dora 경로에 json 파일들을 추가해주면 각 json파일에 정의된 대시보드들이 모두 생성됩니다.

Grafana 웹에 접속하면 대시보드가 추가되어있는 것을 볼 수 있습니다!

대시보드에서 볼 수 있는 정보

Devlake에서 제공하는 대시보드들을 통해 다양한 메트릭을 볼 수 있습니다!
기본적으로 볼 수 있는 메트릭중 유익한 메트릭들을 소개해드리겠습니다.

예시 사진의 데이터는 실제 데이터가 아닌 임의의 값입니다 :)

DORA 메트릭

DORA 메트릭인 배포 빈도, 변경에 걸리는 시간, 변경 실패율, 서비스 복원 시간의 통계에 대한 대시보드입니다. 각 메트릭의 월별 추이를 확인할 수 있습니다.

DORA 보고서에서는 각 지표의 등급을 네 개로 분류하고 있는데요, 이 중 현재 지표가 어느 등급에 속하는 지도 함께 볼 수 있습니다. 이러한 데이터를 기준으로 현재 조직의 상황을 파악하면 개선을 위한 목표를 설정하는 데 도움이 될 수 있습니다.

개발 및 배포 통계

DORA 메트릭 외에도 연동하였던 Jenkins, Github, Jira 등 서비스의 데이터를 이용해 개발 과정 및 배포 실행에 대한 다양한 통계를 확인할 수 있습니다.

Jenkins Job 통계

배포 파이프라인 성공 비율, 실행 횟수, 평균 빌드 시간에 대한 대시보드입니다.
이 정보를 활용해 CI/CD 실행이 효율적으로 이뤄지고 있는지 평가할 수 있습니다.

커밋, PR 사이클 통계

PR이 리뷰를 받는 데 걸리는 시간, 병합 후 배포까지 걸리는 시간에 대한 PR 사이클을 볼 수 있는 대시보드입니다. 개발이 완료되기까지의 각 단계에 시간이 얼마나 걸리는지 추적하여 개발 및 리뷰 프로세스를 최적화할 수 있습니다.

PR의 크기, PR당 코멘트 개수에 대한 추이도 확인할 수 있습니다. PR의 크기가 너무 크거나, 평균 코멘트 개수가 많다면 코드 퀄리티나 동작을 자동으로 테스트하는 절차가 필요할 수 있습니다.

Jira 이슈 통계

Jira 이슈 개수 및 해결 기간을 통해 프로젝트의 진행 상태와 팀의 업무 효율성을 모니터링할 수 있습니다. 늦게 해결되는 이슈가 많다면 작업 프로세스를 개선하여 개발자들이 더 효과적으로 작업할 수 있도록 할 수 있습니다.

버그의 개수와 평균 해결 기간에 대한 통계 또한 따로 확인할 수 있습니다.

커스텀 지표

Grafana에서 Devlake 데이터베이스에 저장되어 있는 정보로 대시보드를 직접 구성하면 위에서 보여드렸던 기본 메트릭 외에도 다양한 지표를 확인할 수 있습니다. 개발팀에서 요청해주신 사항을 반영하여 추가한 그래프들을 두 가지 소개드리겠습니다!

PR 크기별 효율

풀 리퀘스트가 길면 코드에 대해 빠르게 피드백 받고 코드 리뷰의 효율을 높일 수 있는데요, 이와 관련하여 현재 개발 팀에서 어떤 크기의 PR을 많이 작성하고 있는지를 확인하기 위한 그래프를 제작하여 모니터링할 수 있도록 했습니다.

개발자별 대시보드

개발자별로 자신의 개발 주기나 생산성을 파악할 수 있도록 구성한 대시보드입니다. 자신의 이슈, 커밋, PR에 대한 지표를 모아서 확인할 수 있습니다.

Github OAuth를 사용하여 Grafana에 로그인하면, 로그인한 이메일을 기준으로 Github, Jira 유저를 식별하여 데이터를 조회하도록 구현했습니다.

결론

Devlake와 Grafana를 간단하게 구성하여 개발 과정의 효율성을 측정하기 위한 다양한 데이터를 모니터링할 수 있었습니다! 개발 과정의 소요시간, 버그 발생, 복구 기간 추이를 살펴보고 데브옵스 프로세스가 효율적으로 이뤄지는지에 대해 관심을 가지고 개선하는 것은 모든 제품 개발팀에게 도움을 줄 수 있다고 생각합니다.

인턴 이전에 인프랩이 제품을 개발하고 일하는 방식에 대해 궁금증이 있었는데, 이번 대시보드를 구축하면서 인프랩의 개발 문화와 방식이 어떠한지 조금 더 이해할 수 있었습니다. 그리고 그 과정에서 데브옵스 팀은 어떤 식으로 기여할 수 있는지를 파악할 수 있어 좋았습니다. 인프랩의 데브옵스 팀은 단순히 인프라 구축뿐만 아니라 개발 효율화를 위해 여러 방면에서 노력하고 있다는 것을 알게 되었습니다.

여러분도 DORA 메트릭으로 데브옵스 생산성을 모니터링 해보는 건 어떠신가요?

이상으로 마치겠습니다. 감사합니다 :)

참고 자료

• 2014 DORA DevOps Report
• 꼭 알아야 할 4가지 주요 DevOps 메트릭
• Complete Guide to DORA Metrics | Sleuth
• How to Calculate DORA Metrics
• How Not to Use the DORA Metrics to Measure DevOps Perfoemance