지속적인 벤치마킹이란 무엇입니까?
연속 벤치마킹(Continuous Benchmarking)은 팀 멤버가 자주 작업을 벤치마킹하는 소프트웨어 개발 방식입니다. 보통 각 개인이 일일이 벤치마킹하게 되어 하루에 여러 번의 벤치마킹이 이루어집니다. 각 벤치마킹은 자동화 빌드에 의해 검증되며 성능 저하를 가능한 빨리 감지합니다. 많은 팀들이 이런 접근 방식이 성능 저하를 크게 줄이고 팀이 더 빠르게 성능이 좋은 소프트웨어를 개발할 수 있게 한다는 것을 알게 되었습니다.
이제 소프트웨어 업계의 모든 사람들은 지속적인 통합(Continuous Integration, CI)에 대해 알고 있습니다. 기본적으로 CI는 제품에 도달하기 전에 소프트웨어 기능 회귀를 감지하고 방지하기 위한 것입니다. 마찬가지로, 연속 벤치마킹(Continuous Benchmarking, CB)은 제품에 도달하기 전에 소프트웨어 성능 회귀를 감지하고 방지하기 위한 것입니다. 코드 변경마다 CI에서 단위 테스트를 실행하는 이유와 같은 이유로, 코드 변경마다 CB에서 성능 테스트를 실행해야 합니다. 사실, 이 유사성은 이 섹션의 첫 번째 문단이 Martin Fowler가 2006년에 Continuous Integration에 대해 서론을 작성한 것의 Mad Libs 버전인 만큼 적절합니다.
🐰 성능 버그는 버그입니다!
CI에서의 벤치마킹
신화: CI에서 벤치마킹을 실행할 수 없습니다
대부분의 벤치마킹 하네스는 대기 시간이나 처리량을 측정하기 위해 시스템 벽 시계를 사용합니다. 이는 개발자들이 가장 신경쓰는 정확한 지표이기 때문에 매우 유용합니다. 그러나 일반적인 용도의 CI 환경은 벽 시계 시간을 측정할 때 종종 시끄럽고 불규칙합니다. 연속 벤치마킹을 진행할 때, 이 변동성은 결과에 원치 않는 잡음을 추가합니다.
이를 처리하는 몇 가지 방법이 있습니다:
- 상대적 벤치마킹
- 전용 CI 실행기
- 벽 시간 대신 명령을 세는 벤치마킹 하네스로 전환
또는 그냥 혼돈을 받아들이세요! 연속 벤치마킹은 완벽할 필요가 없습니다. 네, 연속 벤치마킹 환경에서 변동성을 줄이고 따라서 잡음을 줄이는 것은 더 세밀한 성능 저하를 감지할 수 있게 해줄 것입니다. 그러나 여기서 완벽함이 선에 의해 적이 되지 않게 조심하세요!
이 그래프를 보고, “와, 정말 미친 것 같다!”라고 생각하실 수 있습니다. 하지만 자기 자신에게 물어보세요, 현재 개발 과정이 사용자에게 영향을 주기 전에 두 배 또는 심지어 열 배 성능 저하를 감지할 수 있을까요? 아마도 아니죠! 이것이야 말로 진짜로 미친 것입니다!
모든 CI 환경에서 나오는 소음에도 불구하고, 벽 시계 벤치마킹을 추적하는 것은 여전히 제품이 고객에게 도달하기 전에 성능 저하를 포착하는데 큰 이익을 가져다줄 수 있습니다. 시간이 지남에 따라, 소프트웨어 성능 관리가 성숙해짐에 따라 거기에서 발전시킬 수 있습니다. 그 사이에는 그냥 일반적인 CI를 사용하십시오.
성능의 중요성
신화: 당신은 100ms의 대기시간을 느낄 수 없습니다
사람들이 100ms의 대기시간을 인지할 수 없다고 주장하는 것은 흔한 일입니다. 이 주장을 위해 종종 Nielsen Group의 응답 시간에 관한 글이 인용됩니다.
0.1초는 사용자가 시스템이 즉시 반응하는 것처럼 느껴지는 한계이며, 결괏값을 표시하는 것 이외에는 특별한 피드백이 필요하지 않습니다.
- Jakob Nielsen, 1 Jan 1993
그러나 그것은 사실이 아닙니다.
어떤 작업에서는 사람들이 대기시간이 2ms 밖에 안 되는 것을 인지할 수 있습니다.
이를 증명하는 간단한 방법은 Dan Luu의 실험에서 볼 수 있습니다: 터미널을 열고 sleep 0; echo "ping"과 sleep 0.1; echo "pong"을 실행해 보세요. 차이를 인지했죠?
다른 주요 혼돈의 원인은 대기시간의 인지와 인간의 반응 시간 사이의 구분입니다. 비록 시각적 자극에 대한 반응이 약 200ms 정도 걸리지만, 그것은 이벤트 인식 자체와는 독립적입니다. 유사하게, 기차가 2분 늦게 도착한 것을 인지할 수 있습니다(인지된 대기시간) 비록 기차 여행이 2시간 걸린다 하더라도(반응 시간).
성능이 중요합니다! 성능은 특성입니다!
- 100ms 더 빠름 → 전환률 1% 상승 (Mobify, 연간 +$380,000 증가)
- 50% 더 빠름 → 판매량 12% 상승 (AutoAnything)
- 20% 더 빠름 → 전환률 10% 상승 (Furniture Village)
- 40% 더 빠름 → 가입자 15% 상승 (Pinterest)
- 850ms 더 빠름 → 전환률 7% 상승 (COOK)
- 1초 더 느림 → 사용자 10% 감소 (BBC)
무어의 법칙의 종말로, 병렬로 실행되는 작업들은 병렬화 될 필요가 있을 것입니다. 그러나 대부분의 작업들은 연속으로 실행되어야 하며, 문제에 단순히 더 많은 연산을 던지는 것은 금방 해결할 수 없고 비용이 많이 드는 해결책이 되고 있습니다.
이 변경으로 인해 성능이 우수한 현대 소프트웨어를 개발하고 유지하는 데 연속 벤치마킹은 핵심 요소입니다.
연속 벤치마킹 도구
Bencher를 만들기 전에, 우리는 다음과 같은 도구를 찾아보았습니다:
- 여러 언어 간의 벤치마킹을 추적할 수 있음
- 언어 표준 벤치마킹 하네스 출력을 원활하게 수집할 수 있음
- 사용자 정의 벤치마킹 하네스 출력에 대한 확장성
- 오픈 소스이며 자체 호스팅 가능
- 여러 CI 호스트와 작동 가능
- 사용자 인증 및 권한 부여 가능
불행히도 모든 이런 요구사항을 충족하는 것은 존재하지 않았습니다. 우리가 영감을 받은 기존 벤치마킹 도구의 종합적인 목록은 prior art에서 확인할 수 있습니다.
대기업에서의 연속 벤치마킹
Microsoft, Facebook (현재는 Meta), Apple, Amazon, Netflix, Google 등의 중소기업에서 Bencher 같은 도구들이 내부적으로 개발되었습니다. 이 업계의 거인들은 개발 중인 성능 모니터링의 중요성과 이러한 통찰력을 CB를 통해 개발 과정에 통합하는 것을 이해하고 있습니다. 우리는 Bencher를 만들어 대기업의 벽 뒤에서 연속 벤치마킹을 오픈 소스 커뮤니티에 가져왔습니다. 대기업에서의 연속 벤치마킹과 관련한 게시물 링크를 보려면 prior art를 참조하십시오.
Bencher: 지속적인 벤치마킹
Bencher는 지속적인 벤치마킹 도구 모음입니다. 성능 회귀가 사용자에게 영향을 미친 경험이 있나요? Bencher가 그런 일이 일어나는 것을 막을 수 있었습니다. Bencher를 이용하면 성능 회귀를 상용 환경으로 이동하기 전에 탐지하고 예방할 수 있습니다.
- 실행: 기존 벤치마킹 도구를 사용하여 로컬 또는 CI에서 벤치마크를 실행합니다.
bencherCLI는 기존 벤치마킹 하네스를 감싸고 결과를 저장합니다. - 추적: 벤치마크 결과를 시간이 지남에 따라 추적합니다. 소스 브랜치, 테스트 베드, 측정 기반의 Bencher 웹 콘솔을 사용하여 결과를 모니터링, 쿼리, 그래프로 만듭니다.
- 캐치: CI에서 성능 회귀를 잡아냅니다. Bencher는 최첨단, 사용자 정의 가능한 분석을 사용하여 상용 환경으로 가기 전에 성능 회귀를 탐지합니다.
단위 테스트가 CI에서 기능 회귀를 방지하기 위해 실행되는 것처럼, 벤치마크는 Bencher와 함께 CI에서 실행되어 성능 회귀를 방지해야 합니다. 성능 버그도 버그입니다!
CI에서 성능 회귀를 잡아내기 시작하세요 - Bencher Cloud를 무료로 시도해보세요.
지속적인 벤치마킹 vs 로컬 벤치마크 비교
여러 벤치마크 하네스들이 로컬에서 결과를 비교할 수 있게 해줍니다. 로컬 비교는 성능을 튜닝하면서 빠르게 반복할 때 매우 훌륭합니다. 그러나, 이는 지속적으로 성능 회귀를 찾아내는데 의존하는 것이 아니어야 합니다. 단위 테스트를 로컬에서 실행할 수 있다고 해서 CI가 필요 없는 것처럼, 벤치마크를 로컬에서 실행하고 비교할 수 있다고 해서 CB가 필요 없는 것은 아닙니다.
로컬 벤치마크 비교 도구들이 제공하지 못하는 여러 기능들이 Bencher에는 있습니다:
- 다른 테스트베드들 사이에서 같은 벤치마크 비교
- 언어와 하네스들을 걸쳐 벤치마크 비교
- 벤치마크 결과의 협업과 공유
- 노이즈를 최소화하기 위한 전용 테스트베드에서 벤치마크 실행
- 더 이상 복사 붙여넣기 없음
지속적인 벤치마킹 vs 애플리케이션 성능 관리 (APM)
애플리케이션 성능 관리(APM)은 현대 소프트웨어 서비스에 필수적인 도구입니다. 그러나, APM는 제품 환경에서 사용할 수 있게 설계되었습니다. 성능 회귀가 감지되는 시점에는 이미 고객에게 영향을 미치고 있습니다.
대부분의 결함은 그것들을 방지하는데 드는 비용보다 더 많은 비용을 청구하게 됩니다. 결함이 발생할 때 결함을 수정하는 직접적인 비용과 손상된 관계, 잃어버린 사업, 그리고 낭비된 개발 시간 때문에 발생하는 간접적인 비용들이 많습니다.
— 켄트 벡, 익스트림 프로그래밍 설명
APM 도구들이 제공하지 못하는 여러 기능들이 Bencher에는 있습니다:
- 성능 회귀를 생산환경으로 넘어가기 전에 탐지하고 방지
- 코드 리뷰에 포함된 성능 변화와 영향
- 생산 환경에서의 오버헤드 없음
- 온-프레미스 배포에 효과적
- 생산 소스 코드 변경 없음
지속적인 벤치마킹 vs 관측 가능성
다른 이름으로 불리는 장미라고 해도 그 향은 달라지지 않을 것입니다. 위의 지속적인 벤치마킹 vs 애플리케이션 성능 관리를 참고하세요.
지속적인 벤치마킹 vs 지속적인 통합 (CI)
지속적인 벤치마킹(CB)은 지속적인 통합(CI)과 보완적입니다. 모든 코드 변경에 대해 CI에서 단위 테스트를 실행하는 것처럼, 모든 코드 변경에 대해 CB에서 성능 테스트를 실행해야 합니다.
단위 테스트와 수용 테스트는 표준 개발 프렉티스로 널리 받아들여졌지만, 이 트렌드는 성능 테스팅 분야로는 이어지지 않았습니다. 현재 흔히 사용되는 도구들은 테스터들을 일회용 코드 작성과 클릭-스크립트 방식으로 유도합니다. 성능 테스팅을 일류 시민으로 대우함으로써 더 많은 기능을 커버하는 더 나은 테스팅의 제작이 가능해지게 하고, 성능 테스팅을 생성하고 실행하는 더 나은 도구를 만들게 하며, 유지보수 가능하고 테스트할 수 있는 테스트 세트를 만들게 합니다.
지속적인 벤치마킹 vs 지속적인 부하 테스팅
지속적인 벤치마킹과 지속적인 부하 테스팅 사이의 차이를 이해하려면, 벤치마킹과 부하 테스팅 사이의 차이를 이해해야 합니다.
| 테스트 종류 | 테스트 범위 | 테스트 사용자 |
|---|---|---|
| 벤치마킹 | 함수 - 서비스 | 하나 - 여러 개 |
| 부하 테스팅 | 서비스 | 많음 |
벤치마킹은 함수 수준(마이크로 벤치마크)부터 서비스 수준(매크로 벤치마크)까지 소프트웨어의 성능을 테스트할 수 있습니다. 벤치마크는 당신의 코드의 특정 부분의 성능을 고립시킨 상태에서 테스트하는 데 좋습니다. 부하 테스팅은 서비스 수준에서만 소프트웨어의 성능을 테스트하고 여러 동시 사용자를 모방합니다. 부하 테스팅은 특정 부하 하에서 전체 서비스의 성능을 테스트하는 데 좋습니다.
🍦 우리가 아이스크림 트럭의 성능을 추적하고 싶다고 가정해 보세요. 벤치마킹은 아이스크림 콘을 스쿱하는 데 걸리는 시간(마이크로 벤치마크), 그리고 한 고객이 주문하고, 아이스크림을 받고, 결제하는 데 걸리는 시간(매크로 벤치마크)을 측정하는 데 사용될 수 있습니다. 부하 테스팅은 더운 여름날에 100명의 고객을 어떻게 서비스하는지를 보는 데 사용될 수 있습니다.