읽기 복제본, 성능을 사면서 늘어나는 요금

읽기 비중을 먼저 숫자로 확인합니다

읽기 복제본을 붙이기 전에 확인할 값은 전체 질의 중 읽기가 차지하는 비중입니다. 이 값이 낮으면 복제본을 붙여도 주 인스턴스의 부하가 거의 줄지 않습니다. 학습용 가정으로 읽기 비중이 70퍼센트라고 두겠습니다. 전체 100 중 70이 읽기이므로, 읽기를 모두 복제본으로 보내면 주 인스턴스의 부하는 30 수준으로 내려갑니다. 반대로 읽기 비중이 20퍼센트인 환경이라면 복제본을 붙여도 주 인스턴스는 80 수준으로 남아 체감이 거의 없습니다. 그래서 1단계는 비중 측정이고, 2단계는 그 비중에서 기대되는 부하 감소를 적는 일입니다.

애플리케이션이 읽기를 분리할 수 있어야 합니다

복제본은 만드는 것보다 쓰는 것이 어렵습니다. 애플리케이션이 읽기 질의와 쓰기 질의를 구분해 다른 주소로 보낼 수 있어야 하기 때문입니다. 구분이 되지 않으면 복제본은 요금만 늘립니다. 그래서 점검 항목은 세 가지입니다. 첫째, 읽기 전용 연결을 따로 만들 수 있는가. 둘째, 쓰기 직후 바로 읽는 코드가 있는가. 복제 지연 때문에 방금 쓴 데이터가 보이지 않는 문제가 여기서 생깁니다. 셋째, 지연을 허용하지 못하는 화면이 어디인가. 그 화면만 주 인스턴스로 보내는 예외 경로를 두면 나머지를 복제본으로 돌릴 수 있습니다.

복제본과 캐시의 금액을 같이 놓습니다

학습용 가정으로 계산합니다. 가정값은 주 인스턴스가 월 300,000원이고 같은 크기의 복제본을 1대 추가한다고 두겠습니다. 합계는 600,000원이므로 추가 비용은 월 300,000원입니다. 대안으로 캐시 계층을 월 80,000원에 두고 반복 조회를 흡수하는 방법이 있습니다. 중간 계산값인 두 방법의 차액은 월 220,000원입니다. 최종 판단은 질의 성격으로 합니다. 같은 결과를 반복해서 읽는 질의가 많으면 캐시가 더 싸고 효과도 큽니다. 매번 조건이 다른 질의가 많으면 캐시 적중률이 낮아 복제본이 맞습니다. 그래서 질의 반복률을 측정해 두 방법 중 하나를 고릅니다.

복제본이 늘리는 부담도 있습니다

결론을 뒤집는 조건이 있습니다. 첫째, 쓰기 부하가 높은 환경에서는 복제본이 주 인스턴스의 부담을 오히려 늘립니다. 변경 내용을 복제본에 보내는 작업이 추가되기 때문입니다. 그래서 쓰기 비중이 높으면 복제본보다 쓰기 경로 자체를 손봐야 합니다. 둘째, 복제본은 데이터 손상에 대한 보호가 아닙니다. 잘못된 삭제는 복제본에도 반영되므로 백업이 따로 필요합니다. 셋째, 복제 지연은 부하에 따라 변합니다. 평시 1초 미만이어도 대량 작업 중에는 길어질 수 있으므로, 지연 지표에 경보를 걸고 허용 한도를 숫자로 적어 둡니다.

AWS 비용 실행 전 점검표

• 전체 질의 중 읽기 비중을 측정했다
• 읽기 전용 연결과 예외 경로를 설계했다
• 질의 반복률을 재서 캐시와 복제본을 비교했다
• 복제 지연 경보와 허용 한도를 설정했다