캐시 도입 비용, 데이터베이스 요금과 바꿔 보기

캐시는 데이터베이스 증설의 대안입니다

데이터베이스가 느려질 때 선택지는 크기를 올리는 것과 반복 조회를 캐시로 받는 것입니다. 두 선택은 비용 구조가 다릅니다. 크기를 올리면 매달 요금이 그만큼 오르고 코드 변경은 없습니다. 캐시를 도입하면 캐시 요금이 추가되지만 데이터베이스는 그대로 두고, 대신 코드 변경 비용이 한 번 발생합니다. 그래서 비교는 월 요금만으로 하지 않고 일회성 개발 비용과 함께 봐야 합니다. 1단계는 반복 조회 비중 측정입니다. 같은 질의가 짧은 시간 안에 다시 들어오는 비율이 높아야 캐시가 효과를 냅니다.

무엇을 캐시할지는 무효화로 정해집니다

캐시 설계에서 어려운 부분은 저장이 아니라 지우는 시점입니다. 데이터가 바뀌었는데 캐시가 남아 있으면 사용자는 오래된 값을 봅니다. 그래서 대상을 고를 때 무효화 방법을 함께 적습니다. 가장 쉬운 대상은 변경이 드물고 조회가 많은 데이터입니다. 설정값, 분류 목록, 공개 게시물이 그렇습니다. 가장 어려운 대상은 사용자마다 다르고 자주 바뀌는 데이터입니다. 이 경우 보관 시간을 짧게 두거나 캐시 대상에서 제외합니다. 설계 문서에는 대상별로 보관 시간과 무효화 시점을 적고, 오래된 값이 보일 때 허용되는 시간 범위를 명시합니다.

회수 기간까지 계산합니다

학습용 가정으로 계산합니다. 가정값은 데이터베이스를 한 단계 올리면 월 400,000원이 추가되고, 캐시 계층은 월 150,000원이며 코드 변경에 16시간이 든다고 두겠습니다. 내부 시간 비용은 시간당 30,000원으로 가정합니다. 일회성 개발 비용은 480,000원입니다. 월 절감액은 400,000원에서 150,000원을 뺀 250,000원입니다. 이것이 중간 계산값입니다. 최종 판단인 회수 기간은 480,000원을 250,000원으로 나눈 약 1.92개월입니다. 2개월 안에 회수되므로 이 가정에서는 캐시가 유리합니다. 다만 캐시 적중률이 낮으면 절감액이 줄어 회수 기간이 길어집니다.

적중률이 낮으면 둘 다 필요해집니다

결론을 뒤집는 조건은 적중률입니다. 도입 후 적중률이 낮게 나오면 데이터베이스 부하가 기대만큼 줄지 않고, 결국 크기도 올려야 합니다. 그러면 두 비용을 모두 내게 되므로 위 계산이 성립하지 않습니다. 그래서 도입 순서를 바꿉니다. 먼저 작은 캐시로 1주일 돌려 적중률을 측정하고, 목표치를 넘을 때만 정식 도입합니다. 두 번째 조건은 장애 시 동작입니다. 캐시가 멈출 때 모든 요청이 데이터베이스로 몰리면 그 순간 장애가 커집니다. 그래서 캐시 실패 시 요청을 제한하는 장치를 함께 넣고, 그 동작을 시험으로 확인합니다.

AWS 비용 실행 전 점검표

• 반복 조회 비중을 측정했다
• 대상별 보관 시간과 무효화 시점을 적었다
• 일회성 개발 비용을 포함해 회수 기간을 계산했다
• 작은 캐시로 적중률을 먼저 측정했다