Zettelkasten

버퍼풀을 더 줄여도 되는지는 IOPS 천장 여유가 아니라 피크 ReadLatency로 판단한다

·수정 1회
rdsmysqlinnodbgp3capacity-planningcloudwatch

요약

  • buffer pool을 줄이면 캐시 미스가 늘어 ReadIOPS·ReadThroughput가 거의 비례해서 오른다. 반면 ReadLatency·WriteIOPS·CPU는 평탄해 "변하는 메트릭"과 "안 변하는 메트릭"이 갈린다.
  • gp3 프로비저닝 IOPS 천장(예: 12k)까지 여유가 많아도(피크 사용률 한 자릿수~10%대) 그건 추가 축소 가능의 근거가 아니다. 천장에 닿기 한참 전에 캐시 미스 쿼리 지연이 먼저 온다.
  • 진짜 한계 신호는 "IOPS가 천장에 근접"이 아니라 "낮 피크 시간대 ReadLatency가 평탄하던 값에서 꺾이는 시점"이다. ReadIOPS 증가가 선형이 아니라 가속(워킹셋 경계 진입)하므로 천장 여유로 안심하면 안 된다.

본문

innodb_buffer_pool_size를 하루 단위로 한 단계씩 내리며(예: ~8GB/일) CloudWatch를 관찰했을 때의 실측 패턴이다. 배경 방법론은 관련 노트 참조.

변하는 메트릭 vs 안 변하는 메트릭. pool 축소 단계마다(R0 기준 → R1 → R2 → R3):

메트릭 거동 의미
FreeableMemory 🔼 단계당 축소량만큼 계단식 증가 pool에서 반환된 RAM. 축소가 적용됐다는 1차 확인
ReadIOPS 🔺 단조 증가 (예: 48→86→122→255) 캐시 미스 → 디스크 물리 읽기 증가. 핵심 신호
ReadThroughput 🔺 ReadIOPS와 같은 배율로 증가 위와 동일 현상의 바이트 단위 표현
ReadLatency ➡️ 평탄 (0.6~0.7ms) 늘어난 읽기를 스토리지가 아직 손해 없이 흡수
DiskQueueDepth 🔼 소폭 상승, 여전히 <1 I/O 대기 거의 없음
WriteIOPS / CPU ➡️ 무변동 쓰기·연산은 buffer pool 읽기 캐싱과 무관

CloudWatch에는 buffer pool 히트율 직접 지표가 없으므로 ReadIOPS 상승이 히트율 하락의 대리지표다.

IOPS 천장 여유는 추가 축소의 근거가 아니다. gp3는 프로비저닝 IOPS(read+write 합산 한도) 안에서는 latency가 일정하다. 총 IOPS가 천장의 한 자릿수~10%대면(예: 피크 ~920 IOPS / 12k = ~8%) 산술적 여유는 압도적이지만, 이건 "더 내려도 안전"을 뜻하지 않는다. 천장에 닿기 한참 전에 한계가 오는 이유:

  1. ReadIOPS 증가가 선형이 아니라 가속한다. 핫 워킹셋이 줄어든 pool 경계에 가까워지면 미스율이 계단/지수로 튄다(실측에서 마지막 컷이 122→255로 거의 2배). 선형 연장으로 "천장까지 멀다"고 본 갭이 예상보다 빨리 좁혀진다.
  2. binding constraint는 IOPS 소진이 아니라 쿼리 지연이다. 미스가 누적되면 IOPS 천장보다 먼저 ReadLatency가 올라가 사용자 쿼리가 느려진다.

그래서 한계 판단 기준은 피크 ReadLatency다. 합격 = 축소 후에도 낮 피크 시간대 ReadLatency가 기준선(예: 0.65ms)에서 평탄 유지. ReadLatency가 꺾이기 시작하면 그게 floor 신호다. 관찰 창에 반드시 일배치·낮 피크 등 cold read가 몰리는 시간대를 포함해야 한다(저트래픽 새벽만 보면 미스 증가를 놓친다).

replica가 먼저 꺾인다. 읽기를 받는 read replica는 (1) 보통 master보다 RAM이 작아 같은 비율 공식이면 pool 절대값이 더 작고, (2) read IOPS 기준선이 master의 십수 배다. 실측에서 master는 ReadIOPS가 깨끗하게 단조 증가한 반면, replica는 원래부터 디스크 read 헤비라 축소 효과가 time-of-day 변동에 묻혀 잘 안 보였고 피크 IOPS는 워크로드 천장에 고정돼 있었다. 천장 사용률도 replica가 master의 약 2배. 따라서 추가 축소의 1차 한계 지표는 replica의 피크 ReadLatency·DiskQueueDepth이며, master만 보고 "여유 있다"고 판단하면 안 된다.

관련 노트

참고

함께 읽기 좋은 글