AppSignal을 사용하는 앱을 실행하는 모든 서버는 30초마다 샘플 및 측정항목 모음을 Push API로 보냅니다.
각 요청에는 데이터가 어느 앱에서 왔는지 확인하는 데 사용하는 키가 있습니다. 그러기 위해서는 데이터베이스를 쿼리하여 들어오는 각 요청에 대한 앱을 찾아야 합니다. 매달 300억 건의 요청이 발생하는 우리는 AppSignal을 더 빠르게 만들기 위해 쿼리 수를 줄이는 방법을 끊임없이 찾고 있습니다.
데이터베이스 클러스터의 쿼리 수를 줄이기 위해 캐싱을 구현했습니다. 데이터베이스에서 앱을 가져올 때마다 Memcached에 1분 동안 저장합니다. 이 변경 사항을 프로덕션에 배포한 후 더 많은 작업을 수행하고 있음을 알게 되었습니다. 이전보다 쿼리가 더 많아졌습니다. 캐시가 너무 자주 무효화되는 것 같았습니다. 어디서 그런 일이 발생했는지 알아보기 위해 캐시가 부적절하게 무효화된 위치를 알아내는 몇 가지 맞춤 측정항목을 추가했습니다.
푸시 처리 시간이 업데이트되거나 새 네임스페이스가 감지되는 등 캐시를 무효화하는 경우가 몇 군데 있습니다.
이러한 캐시 무효화 중 어떤 것이 원인인지 확인하기 위해 여러 카운터를 추가했습니다. 이 예에서는 app.cache.invalidate를 증가시킵니다. 총 유효성 검사 횟수를 계산하고 app.cache.invalidate_push_time과 같은 특정 키를 사용하는 카운터 그리고 app.cache.invalidate_namespaces 특정 무효화의 경우.
위의 사용자 정의 측정항목을 추가하여 시간 경과에 따른 캐시 적중률을 그래프로 표시할 수 있었습니다. 어떤 캐시 키가 쿼리 증가를 유발했는지 즉시 알 수 있었습니다. app.cache.invalidate_namespaces 요청마다 키가 무효화되었습니다.
캐시 가능한 총 요청 수는 app.cache.maybe으로 계산됩니다. .
이 문제에 대한 수정 사항을 배포한 후 앱의 네임스페이스가 업데이트되지 않는 한 무효화 횟수가 0으로 떨어졌습니다.
사용자 정의 지표를 추가하면 무슨 일이 어디서, 언제, 얼마나 자주 발생하는지 더 쉽게 이해할 수 있습니다. 이 경우 캐시 무효화 횟수를 파악하고 이를 판독 가능한 그래프로 표시함으로써 문제를 빠르게 찾을 수 있었습니다. 특정 값을 증가시키고 대시보드를 생성하려면 코드 몇 줄만 있으면 됩니다.
사용자 정의 지표에 대해 질문이 있는 경우, 그리고 애플리케이션에서 해당 지표를 설정하는 데 도움을 받을 수 있는지 알려주십시오. 기꺼이 도와드리겠습니다!
로버트 비크먼
공동 창립자로서 Robert는 우리의 첫 번째 커밋을 작성했습니다. 그는 또한 우리의 지원 역할 모델이며 코드의 작은 세부 사항에 대해 모두 알고 있습니다. 여행과 사진(동시에).
모든 기사:Robert Beekman