개선하려는 사항을 측정하라

서평: MVP 단계라 신규 기능 개발이 우선순위가 높고 유저가 없어서 시스템 모니터링을 미뤄놓고 있다. 정식으로 출시하기 전에 반드시 측정을 해야한다. 측정하지 않으면 개선할 수 없다. 시스템 모니터링을 미뤄놓고 있다. 지금은 sentry로 최소한의 에러 트래킹, slack으로 데이터 배치 모니터링 그리고 aws cloudwatch로 RDS, MQ 모니터링을 하고 있는데 많이 부족하다.

일반적인 지연 시간을 참고하면 어떤 병목을 해결해야 하는지 우선순위를 정할 수 있다.

메모리에서 1MB 데이터에 접근하는 것은 디스크에서 똑같은 데이터에 접근하는 것보다 120배 빠르고, 1Gbps 네트워크에서 읽는 것보다 40배 빠르다. 데이터를 어디서 접근해서 가져오는지를 개선하면 병목도 해결할 수 있는 실마리를 제공한다.

성과 측정에 신경쓰자. 자신의 효과성을 측정하기에 가장 좋은 도구다. 관리자가 신경 써줘야 하는게 아니라 본인이 입증해야 한다. 매일 시계부를 작성하고 회고하고 있지만 한가지 아쉬운 점은 내가 어디에 시간을 쓰고 있는지 세부적으로 관리하고 측정하지 못했다는 점이다. 일 단위로 어떤 업무를 했는지 관리하고, 퇴근 후 어떻게 시간을 보냈는지 적어두지만 일주일 단위, 월 단위 등으로 누적해서 어떻게 했는지 측정을 해보면 더 좋을 것 같다.

실천 사항

API에 대한 모니터링이 필요하다. 초당 요청 수, P95, P99 응답 시간을 모니터링하자.
매일 기록되고 접근되는 데이터양을 측정해보자. 데이터에 대한 인사이트를 얻을 수 있다. 유저 데이터 뿐만 아니라 주식 데이터나 비정형 데이터도 하루에 얼마나 생성되는지 확인하면 데이터 처리량을 예측할 수 있다.
aws cloudwatch에 부문별하게 쌓이는 로그를 살펴보자. 쓸모 없는 로그면 코드에서 삭제하고 유용한 로그면 로그를 통해 어떤 일이 일어나는지 파악하자.
데이터 무결성을 체크하는 스크립트나 쿼리를 작성하여 매일 실행 후 리포트하도록 자동화를 하자. 특정 테이블의 쓰레기 데이터가 있는지 등을 파악해 볼 수 있다. 정책상 정해지지 않은 부분도 발견할 수 있다. 삭제한 유저의 데이터 처리에 미흡한 부분을 발견한다거나, 데이터를 외부에서 받아서 저장할 때 깨끗하지 않은 데이터가 들어오는지 확인할 수 있다.

책 내용

지표를 활용해서 발전을 주도하라

진척 상황과 성과를 측정하는 건 관리자의 업무라고 생각하겠지만 사실은 자신의 효과성을 측정하고 업무의 우선순위를 매기는 강력한 도구다. 좋은 지표는 여러 면에서 도움이 된다.

올바른 대상에 집중하게 해준다.
좋은 지표를 시간 경과에 따라 시각화하면 향후 발생할 회귀 버그를 방지하는 데 도움이 된다.
좋은 지표는 발전을 주도한다.
시간이 흐르는 동안 효율성을 측정하고, 현재하는 활동과 그 대신 할 수 있었던 활동을 비교할 수 있게 해준다.

좋은 지표를 위해 다음과 같이 자문해 볼 가치가 있다.

현재 내가 하는 일의 진행 상황을 측정할 방법이 있을까?
만약 내가 하는 일이 핵심 지표에 영향을 미치지 못한다면 할 가치가 있을까? 또는 내가 놓치고 있는 핵심 지표가 있을까?

원하는 행동을 장려하려면 올바른 지표를 골라라

주당 근무 시간 vs 주당 생산성

주당 근무 시간이 늘어나면 추가 근무 시간당 한계 생산력이 급격하게 떨어진다. 시간당 평균 생산성이 감소하고 오류와 버그 비율이 높아지고 번아웃과 이직률이 늘어나면서 이에 따르는 측정하기 어려운 추가 비용이 발생한다.

클릭률 vs 롱 클릭률

구글의 검색 페이지 성과 측정에서 롱 클릭 지표를 사용했다. 롱 클릭이란 사용자가 검색 결과를 클릭한 뒤 다시 검색 페이지로 돌아오지 않거나 결과 페이지에 오래 머무는 것을 말한다. 단순히 클릭률이 높은건 검색 결과 측정에 도움이 되지 않는다.

평균 응답 시간 vs p95 p99 응답 시간

평균을 낮추려면 모든 요청의 응답 시간을 줄여야한다. 일반적인 인프라 개선에 더 집중하면 된다. p95, p99는 상위 5%, 1%의 응답 시간을 의미한다. 가장 나쁜 동작을 시스템에서 찾아내야 한다. 즉, 이 경우에는 가장 느린 응답에 집중해야 한다.

등록한 사용자 수 vs 등록한 사용자 수의 주간 성장률

제품의 사용자 기반을 키워나갈 때 전체 사용자의 수를 보고 우상향하는 것에 안주할 수 있다. 전체 사용자수는 미디어 노출이나 광고를 통해 일시적으로 늘 수 있다. 더 중요한 것은 주간 성장률이다. 성장 속도가 둔화되고 있는지 여부를 알 수 있다.

주간 활성 사용자 vs 가입 기간별 주간 활성 사용자

사용자 참여를 추적할 때 주간 활성 사용자 수는 전체 그림을 보여주지 못한다. 가입 후 n주차에도 여전히 활성화된 사용자를 주 단위로 측정하는 것이다. 이 지표는 제품의 변화가 기존 사용자 집단에 비해 새로운 사용자 집단의 참여에 어떤 영향을 미쳤는지, 보다 실행 가능한 통찰을 제공한다.

유용한 수치를 체득하라

연산명	시간
L1 캐시 참조	0.5 ns
분기 예측 오류 (branch mispredict)	5 ns
L2 캐시 참조	7 ns
뮤텍스 락/언락	100 ns
주 메모리 참조	100 ns
Zippy로 1 KB 압축	10 μs
1 Gbps 네트워크로 2 KB 전송	20 μs
메모리에서 1 MB 순차적으로 read	250 μs
같은 데이터 센터 내 메시지 왕복 지연시간	500 μs
디스크 탐색 (seek)	10 ms
네트워크에서 1 MB 순차적으로 read	10 ms
디스크에서 1 MB 순차적으로 read	30 ms
한 패킷의 CA(캘리포니아)에서 네덜란드까지의 왕복 지연시간	150 ms

일반적인 지연 시간

L1 캐시 참조 (0.5 ns)

CPU의 가장 가까운 캐시 메모리(L1 캐시)에서 데이터를 읽거나 쓰는 데 걸리는 시간입니다. 매우 빠르며, 주로 자주 사용되는 데이터가 저장됩니다.

분기 예측 오류 (branch mispredict) (5 ns)

CPU가 조건문 처리에서 잘못된 경로를 예측해 불필요한 계산이 이루어진 후 올바른 경로로 되돌아가는데 걸리는 시간입니다.

L2 캐시 참조 (7 ns)

L2 캐시는 L1 캐시보다 크지만 느립니다. L1 캐시에서 데이터를 찾지 못했을 때 L2 캐시에서 검색이 이루어집니다.

뮤텍스 락/언락 (100 ns)

멀티스레드 환경에서 공유 리소스 접근을 동기화하기 위해 사용되는 뮤텍스(Mutex)를 락(Lock)하거나 언락(Unlock)하는 데 걸리는 시간입니다.

주 메모리 참조 (100 ns)

캐시에 없는 데이터를 DRAM 기반의 메인 메모리에서 읽거나 쓰는 데 걸리는 시간입니다.

Zippy로 1 KB 압축 (10 μs)

Zippy 압축 알고리즘을 사용해 1KB의 데이터를 압축하는 데 걸리는 시간입니다. Zippy는 빠른 속도를 중시한 알고리즘입니다.

1 Gbps 네트워크로 2 KB 전송 (20 μs)

1Gbps의 네트워크 대역폭에서 2KB 데이터를 전송하는 데 소요되는 시간입니다.

메모리에서 1 MB 순차적으로 read (250 μs)

메모리에서 1MB 데이터를 순차적으로 읽는 데 걸리는 시간입니다.

같은 데이터 센터 내 메시지 왕복 지연시간 (500 μs)

같은 데이터 센터에 있는 두 서버 간에 메시지를 주고받는 데 걸리는 시간입니다.

디스크 탐색 (seek) (10 ms)

하드 디스크 드라이브에서 특정 데이터 블록을 찾기 위해 디스크 헤드를 이동시키는 데 걸리는 시간입니다.

네트워크에서 1 MB 순차적으로 read (10 ms)

네트워크를 통해 1MB 데이터를 순차적으로 읽는 데 걸리는 시간입니다.

디스크에서 1 MB 순차적으로 read (30 ms)

디스크에서 1MB 데이터를 순차적으로 읽는 데 걸리는 시간입니다.

한 패킷의 CA(캘리포니아)에서 네덜란드까지의 왕복 지연시간 (150 ms)

미국 캘리포니아에서 네덜란드까지 패킷을 전송하고 응답을 받을 때까지의 왕복 지연시간입니다. 물리적 거리와 네트워크 경로의 복잡성이 반영됩니다.

채득하거나 쉽게 접근할 수 있게 해두면 좋은 그 외의 수치들

등록된 사용자 수, 주간 활성 사용자 수, 월간 사용자 수
초당 요청 수
저장된 데이터의 양과 수용 가능한 총 용량
매일 기록되고 접근되는 데이터양
해당 서비스를 지원하는 데 필요한 서버 개수
다른 서비스나 종단점의 처리량
트래픽 증가율
평균 페이지 로딩 시간
제품 여러 부분에 걸친 트래픽 분포
웹 브라우저, 모바일 기기, 운영 체제 버전별 트래픽 분포

데이터 무결성을 의심하라

데이터가 뒷받침되는 주장은 강력하다. 하지만 어떤 데이터든 오용될 수 있다. 사람들은 데이터를 해석하고 싶은대로 해석한다.

데이터 무결성에 대한 신뢰도를 높이는 데 쓸 수 있는 몇 가지 전략

나중에 유용하게 쓰일 수 있으니 데이터를 자유롭게 기록하라.
데이터 정확성을 곧장 확이할 수 있는 도구를 만들라.
end-to-end 통합 테스트를 작성해 전체 분석 파이프라인을 검증하라.
수집한 데이터는 곧바로 검사하라
한 지표를 여러 방법으로 연산하여 데이터 정확성을 교차 검증하라.
이상해 보이는 수치가 있으면 빨리 조사하라.

핵심 요약

진행 상황을 측정하라.

측정하지 않은 것은 개선하기 어렵다. 측정하지 않으면 어떤 노력이 가치가 있었는지 어떻게 알겠는가?

최고 수준의 지표를 신중하게 선택하라.

측정 지표가 달라지면 가치 있는 행동도 달라진다. 어떤 행동을 해야 할지 신중히 파악하라.

시스템을 계측하라.

시스템이 복잡할수록 더 많이 계측해야 아무 정보 없이 장님처럼 비행하지 않을 수 있다. 더 많은 지표를 더 쉽게 계측하게 만들면 더 자주 계측할 수 있다.

유용한 수치를 익혀라.

진행 상황의 기준으로 삼거나 간단한 계산에 도움이 되는 수치를 외우거나 쉽게 확인할 수 있게 하라.

데이터 무결성을 우선시하라.

나쁜 데이터는 데이터가 없는 것보다 더 나쁘다. 자신이 옳다고 생각하며 잘못된 결정을 내리기 때문이다.