GN⁺: rqlite가 테스트하는 방법

• rqlite는 가벼운 오픈 소스 분산 관계형 데이터베이스로, Go로 작성되었으며, SQLite와 Raft를 기반으로 개발됨
• 2014년부터 개발이 시작되었으며, 신뢰성과 품질을 우선시하며, 10년 이상의 개발과 배포 후에도 프로덕션 환경에서 10건 미만의 패닉 사례만 보고됨
• 분산 시스템 테스트는 여러 레이어에서 세심한 고려가 필요하며, 단순함 속에서 품질을 유지하는 철학을 따름

테스트 피라미드: 효과적인 접근법

• rqlite 테스트는 "테스트 피라미드"를 준수함
  • 테스트 피라미드: 단위 테스트를 기반으로, 통합 테스트와 최소한의 엔드 투 엔드 테스트(E2E)를 포함하는 구조
• 효율적이고 디버깅이 용이하며, 목표 지향적인 테스트 스위트를 제공

단위 테스트: 품질의 핵심

• 단위 테스트는 독립적인 컴포넌트를 테스트하며, 속도와 정확성의 균형을 제공함
• SQLite와 "shared nothing" 아키텍처를 기반으로 대부분의 기능이 단위 테스트로 커버 가능
• 전체 rqlite 코드(약 75,000줄) 중 단위 테스트는 약 27,000줄로 구성됨
• 테스트는 몇 분 안에 완료되며, 개발 중 빈번한 테스트가 가능함

시스템 수준 테스트: 컨센서스 검증

• 시스템 수준 테스트는 Raft 컨센서스 모듈과 SQLite의 상호작용을 검증함
• 주요 테스트 항목:
  • SQLite 명령문의 노드 간 복제
  • 다양한 일관성 수준에서의 읽기 작업
  • 클러스터 장애 복구 및 리더 선출 검증
• 약 7000줄의 테스트 코드로 단일 노드 및 다중 노드 구성의 상호작용을 포괄적으로 커버

엔드 투 엔드 테스트: 최소한의 레이어

• 엔드 투 엔드 테스트는 시스템 시작, 클러스터링, 기본 동작을 확인하는 스모크 테스트 역할을 함
• Python으로 작성되었으며 실제 rqlite 클러스터를 실행하여 주요 기능을 검증함
• 예: AWS S3로의 백업 검증
• 테스트 코드 약 5000줄로 제한적인 접근법을 사용하여 디버깅 비용을 최소화

성능 테스트: 한계를 시험

• 성능 테스트는 다음과 같은 메트릭을 평가:
  • 최대 INSERT 속도
  • 동시 쿼리 처리
  • 메모리, CPU, 디스크 사용량 비교
• 2GB 이상의 SQLite 데이터베이스 테스트를 포함하여 메모리 관리와 디스크 쓰기 병목현상을 분석
• 성능 문제를 발견하고 최적화를 통해 안정성을 보장

배운 교훈

• 초기부터 테스트 시작
  • 단위 테스트는 시스템 신뢰를 구축하는 가장 효과적인 방법
  • 개발 중 단위 테스트 작성을 미루지 말아야 하며, 버그를 통합 테스트나 E2E 테스트보다 빠르게 발견 가능
• 테스트 코드를 단순하게 유지
  • 테스트 스위트는 복잡한 리팩토링이나 DRY(Don't Repeat Yourself) 원칙을 고집하는 장소가 아님
  • 이해하기 쉬운 코드를 작성하는 것이 중요하며, 추가적인 보일러플레이트 코드도 허용해야 함
• 테스트를 검증
  • 테스트 작성 시, 일시적으로 예상 결과를 반대로 설정하여 테스트를 다시 실행
  • 제대로 작성된 테스트는 이 경우 실패해야 하며, 이를 통해 테스트 코드의 오류를 사전에 방지 가능
• 테스트 실패를 무시하지 말기
  • 이해하기 어렵거나 드문 테스트 실패라도 소프트웨어에 대해 중요한 정보를 제공
  • 디버깅이 어려운 실패 사례는 종종 코드의 치명적인 결함을 발견할 기회가 될 수 있음
• 결정론 최대화
  • 시스템의 자동 프로세스를 수동으로 실행할 수 있는 메커니즘을 구축
  • 예: Raft 스냅샷 기능은 일반적으로 반자동으로 실행되지만, 테스트 중 명시적으로 트리거 가능하도록 설계
• 신중한 태도(Be Deliberate)
  • 상위 수준의 통합 테스트나 E2E 테스트는 필요성이 명확히 입증될 때만 추가
  • 과도한 테스트는 개발 및 디버깅 속도를 저하시킬 수 있음
• 적용 및 반복
  • 성능 테스트에서 fsync 호출이 주요 병목현상으로 확인되었으며, Raft 로그 엔트리를 디스크에 쓰기 전에 압축하여 디스크 사용 최적화
• 효율성 중시
  • 몇 분 안에 실행 가능한 테스트 스위트를 유지하여 빠른 반복 개발 가능
  • 이는 오픈 소스 프로젝트의 유지와 활성화에 필수적인 장점

품질 우선

• 테스트 피라미드를 준수하며, 각 테스트 레이어가 명확한 목적을 갖도록 설계
• 분산 시스템의 복잡성이 증가함에 따라 테스트의 단순성을 유지하는 것이 핵심
• 신뢰할 수 있고 운영이 용이한 데이터베이스를 구축하는 것이 목표

[neo]

Hacker News 의견

• 첫 번째 테스트는 가장 어렵지만 추가할 가치가 있음. 이후 테스트는 더 쉬워짐

  • 매개변수화된 테스트는 반복 코드를 줄이고 다양한 테스트를 가능하게 함
  • 제약 조건의 철저한 검증이 가능할 때 유용함
  • Prop 테스트는 일관성과 불변성을 검증하는 데 도움을 줌
  • 변이 테스트를 사용하여 실제로 테스트하고 있는지를 확인하는 것이 중요함

• 프로젝트에 대한 헌신이 인상적임

• 테스트 피라미드는 이해가 되지만, 모든 레벨이 없는 경우가 많아 이를 빠르게 개선해야 하는 상황임

  • 여러 팀과 협력하는 경우 e2e 레이어를 채우는 것이 아무도 맡지 않는 일이 됨
  • Auth0 같은 인증 메커니즘을 사용하는 경우 테스트가 어려움
  • e2e 테스트가 없으면 시스템이 쉽게 깨질 수 있음
  • 자동화된 e2e 테스트는 문제를 쉽게 식별하고 롤백할 수 있게 해줌

• FAQ에 복사 붙여넣기 오류가 있는 것 같음

• Jepsen 보고서를 기대하고 있음

• 비디오 형식으로도 즐겼음

• 성능 테스트 설정이 부러움

• rqlite를 사용해봤고, 단순함을 잘 전달함

• 결정론적 시뮬레이션 테스트에 대한 의견을 묻고 있음

• rqlite를 실제 환경에서 사용하는지 궁금해함

• rqlite는 독창적이고 천재적인 프로젝트임