sqlite3

Using Datadog APM to improve the performance of Homebrew (새 탭에서 열림)

이 글은 Datadog의 소프트웨어 엔지니어링 인턴인 Andrew Robert McBurney가 오픈 소스 프로젝트인 Homebrew의 `brew linkage` 명령어 성능을 개선한 과정을 다룹니다. Datadog의 APM 도구와 플레임 그래프를 활용해 병목 지점을 정확히 파악했으며, 캐싱 메커니즘을 도입하여 패키지 검사 속도를 획기적으로 향상시켰습니다. 결과적으로 106개 패키지 처리 시간을 11.5초에서 182밀리초로 단축하며 프로젝트의 요구 성능을 성공적으로 충족했습니다. ### APM을 활용한 성능 병목 지점 탐색 * Datadog의 `ddtrace` 젬(gem)을 사용해 Homebrew의 루비 코드를 인스트루먼테이션(instrumentation)하여 실행 데이터를 수집했습니다. * 수집된 데이터를 플레임 그래프로 시각화하여 분석한 결과, `LinkageChecker::check_dylibs` 함수가 전체 실행 시간의 대부분을 차지하는 병목 지점임을 확인했습니다. * 이 함수는 패키지의 동적 라이브러리 링크를 확인하고 이를 시스템 라이브러리, 깨진 링크, 선언되지 않은 의존성 등으로 분류하는 복잡한 작업을 수행합니다. ### 멀티스레딩의 한계와 캐싱 전략 도입 * 초기에는 루비의 `Thread` 프리미티티브를 이용한 멀티스레딩으로 성능 개선을 시도했으나, 루비의 **GIL(Global Interpreter Lock)** 제한으로 인해 기대했던 성능 향상을 얻지 못했습니다. * 대안으로 SQLite3를 이용한 온디스크(on-disk) 캐싱 메커니즘을 설계하여, 한 번 계산된 연결성 정보를 영구 저장하고 재사용하도록 했습니다. * SQLite3 기반 캐싱 도입 후, `boost` 라이브러리 검사 시간이 1.01초에서 1.38밀리초로 줄어드는 등 전체적인 명령 처리 속도가 비약적으로 개선되었습니다. ### 의존성을 고려한 PStore 기반 최종 최적화 * Homebrew 유지관리자의 피드백을 반영하여, 외부 의존성인 SQLite3 젬 대신 루비 표준 라이브러리인 **PStore**로 캐싱 구현을 교체했습니다. * PStore는 루비 객체를 파일에 영구적으로 저장하는 해시 기반의 메커니즘으로, 추가적인 외부 라이브러리 설치 없이도 SQLite3와 유사한 성능 이점을 제공합니다. * 이 과정을 통해 대규모 오픈 소스 프로젝트에서는 성능 최적화만큼이나 의존성 관리와 표준 라이브러리 활용이 중요하다는 점을 입증했습니다. ### 실용적인 결론 성능 최적화 시 직관에 의존하기보다 APM과 같은 도구를 사용하여 데이터 기반으로 병목을 찾는 것이 중요합니다. 특히 루비 환경에서는 GIL로 인해 병렬 처리가 제한적일 수 있으므로, 연산량이 많은 작업은 캐싱을 통해 중복 계산을 피하는 것이 가장 효과적인 전략이 될 수 있습니다. 또한, 오픈 소스 기여 시에는 프로젝트의 경량성을 유지하기 위해 가급적 표준 라이브러리(예: PStore)를 활용하는 것을 권장합니다.