저장된 통계를 읽는 서비스 호출은 1밀리초도 걸리지 않았는데, 그 통계를 다시 만드는 작업은 몇 분째 돌고 있었다. 한 대시보드의 배포 후 관측에서 나온 두 결과다. 빠른 조회와 느린 갱신이 모순처럼 보이지만 두 작업은 같은 일을 하지 않았다.
저장된 스냅샷만 읽는 서비스 호출 여섯 번 가운데 첫 호출은 215.057ms, 나머지 다섯 번은 0.218~0.408ms였다. HTTP 인증과 브라우저 화면 그리기는 이 측정에 포함되지 않았다. 따라서 이 수치로 사용자가 페이지를 보는 데 걸린 시간을 말할 수는 없다. 기록된 것은 이미 만들어 둔 통계를 서비스가 꺼내는 시간이다.
읽는 쪽에서 빠진 계산
대시보드 통계 캐시를 읽는 응답은 저장된 집계 결과를 가져온다. 그 결과를 만드는 갱신 작업은 별도로 남는다. 이 사례에서도 캐시를 읽는 응답은 긴 집계를 피했지만 실제 정기 갱신에는 182~220초가 걸렸다. 관측 당시 스냅샷 다섯 개는 오래된 상태였다. 응답을 빨리 돌려주는 경로와 새 숫자를 계산하는 경로를 따로 봐야 하는 이유다.
캐시를 도입하면 사용자가 계산을 기다리는 대신 이전 숫자를 볼 수 있다. 이 사례의 기록도 표시된 수치가 몇 분 늦을 수 있다고 남겼다. 그렇다고 갱신 작업의 실행 시간을 그대로 데이터의 나이로 쓰면 안 된다. 언제 계산한 값인지와 언제 읽었는지를 알아야 읽는 순간 얼마나 오래된 값인지 판단할 수 있다.
두 초시계를 한 비율로 만들지 않기
215.057ms와 182~220초를 나란히 놓고 성능 향상 배수를 계산할 수도 있다. 그러나 앞의 호출은 저장된 결과를 읽었고 뒤의 작업은 결과를 만들었다. 이것은 같은 요청의 수정 전후 비교가 아니다. 합성 데이터에서 갱신이 2.5~3.5초 걸렸다는 별도 기록 역시 운영 갱신의 재현으로 취급하지 않았다. 짧은 숫자가 있다는 이유만으로 측정 대상의 차이가 사라지지는 않는다.
남은 갱신 작업에는 별도의 진단이 필요했다. 이후 자연 실행을 관측한 기록에서는 반복되는 전역 감사 순위 집계가 완료된 갱신 한 번의 최소 70.03%를 차지했다. 실제 전체 스캔 실행 계획과 저장장치 카운터를 함께 보고 저장장치 읽기 압력을 주된 병목으로 해석했다. 다만 관측 자체의 부하는 측정하지 않았고, 추적이 끝난 뒤 완료된 더 긴 작업은 두 번째로 완전히 관측한 실행이 아니었다. 이 결과를 모든 갱신의 고정 실행 시간이나 캐시 도입 효과로 확대할 근거는 없다.
저장된 결과를 꺼내는 호출이 이미 짧다면 그 호출을 더 줄이는 것만으로 오래된 수치는 새로워지지 않는다. 갱신 집계를 줄이는 일과 화면에서 얼마나 오래된 값을 허용할지 정하는 일은 따로 남는다. 운영 현황을 대략 보는 화면과 즉시 판단에 쓰는 화면은 허용할 수 있는 지연도 다를 수 있다.
이 사례에서 캐시는 긴 집계를 읽기 요청에서 떼어냈다. 빠른 응답을 확인한 뒤에도 숫자를 계산한 시점은 여전히 확인할 필요가 있다. 그 시점을 모른 채 응답 시간만 재면 오래된 숫자를 더 빨리 받는 데 성공했는지만 알게 된다.