Zettelkasten

RDS 메모리 다운사이징 가능 여부는 데이터가 커도 ReadIOPS가 낮은지로 판별한다

·수정 4

요약

  • 다운사이징 가능 상태의 결정적 신호는 "전체 데이터가 buffer pool보다 훨씬 큰데도 디스크 ReadIOPS가 낮은 것"이다. 핫 워킹셋이 pool보다 작다는 직접 증거다.
  • CPU 사용률·buffer pool 히트율·FreeableMemory 추이는 보조 신호이고, 핫셋 크기는 ReadIOPS가 가장 정확히 드러낸다.
  • 이 신호들은 "줄여도 되는지"를 1차 스크리닝할 뿐이고, 실제 안전성은 in-place로 pool을 낮춰 ReadIOPS가 평탄하게 유지되는지로 확정한다.

본문

다운사이징을 검토할 때 가장 흔한 착각은 buffer pool이 꽉 차 있는 걸 "메모리가 부족하다"로 읽는 것이다. InnoDB 버퍼 풀은 innodb_buffer_pool_size로 미리 잡는 고정 한도이고(RAM이 남아도 자동으로 안 커진다 — 그건 OS 페이지 캐시 동작이지 InnoDB가 아니다), RDS는 이 값을 RAM의 75%로 설정해 둔다. 버퍼 풀은 데이터가 한도보다 크면 그 한도까지 LRU로 거의 항상 꽉 채우므로, 데이터가 pool보다 훨씬 큰 환경에선 pool이 차 있는 건 한도까지 채워진 기본 상태지 수요 신호가 아니다. 진짜 봐야 할 건 그 pool로 디스크 읽기를 얼마나 막고 있는가다.

결정적 신호: 거대 데이터셋 + 낮은 ReadIOPS. 전체 데이터(data+index)가 buffer pool의 수십 배인데도 CloudWatch ReadIOPS가 평균 수십 수준으로 낮다면, 자주 읽히는 핫셋이 pool보다 훨씬 작다는 뜻이다. 데이터가 거대한데 디스크를 거의 안 읽는다 = 대부분 메모리에서 서빙 = pool에 여유가 많다. 이게 다운사이징 가능 상태의 핵심 증거다. 반대로 ReadIOPS가 이미 수백~수천이면 pool이 빠듯해 디스크로 떨어지는 중이라 줄이면 악화된다.

전체 데이터 크기 확인 (information_schema.tables의 data_length+index_length 합)으로 "데이터 ≫ pool"인지부터 본다. InnoDB에선 추정치라 컬럼 간 합이 안 맞을 수 있으나 자릿수 판단엔 충분하다.

보조 신호 (단독으론 불충분):

  • CPU 사용률 — 피크에도 낮으면(예: 15~19%) CPU는 제약이 아님을 시사. 단 메모리/IO 제약과는 별개라 이것만으로 다운사이징을 결론낼 수 없다.
  • buffer pool 히트율 (Innodb_buffer_pool_reads/read_requests) — 99.9%+면 현재 pool로 충분. 단 기동 후 누적값이라 "47GB로 충분"만 알려주고 "더 줄여도 되는지"는 못 알려준다.
  • FreeableMemory 추이 — 하락 추세나 스래싱 없이 안정적이면 메모리 압박 없음. 단 pool이 75%로 고정이라 평소 FreeableMemory는 비-pool 오버헤드 여유만 반영한다.
  • ReadLatency — 평탄하면 I/O 압박 없음.
  • Innodb_buffer_pool_pages_free — free 페이지가 많으면 과할당 확정. 단 데이터가 pool보다 크면 항상 ≈0이라 이 경우엔 무용. (데이터가 작을 때만 유효한 신호)

어느 노드를 보는지 주의 (read replica 분산). 읽기가 read replica로 라우팅돼 있으면 master의 ReadIOPS는 당연히 낮다 — 이때 master만 보고 "다운사이징 가능"이라 결론내면 안 된다. 실제 핫셋·캐시 압박은 읽기를 받는 노드에서 드러나므로, replica의 ReadIOPS를 따로 봐야 한다. (실측 예: 한 워크로드에서 master ReadIOPS ~48/s인데 read replica는 ~686/s였다 — 읽기가 거의 replica에서 처리됨. master는 더 줄일 여지가 크고, replica가 진짜 제약 노드일 수 있다.)

스크리닝 ≠ 확정. 위 신호들은 "줄여볼 가치가 있다"는 1차 판정이다. 누적 히트율·CPU는 현재 상태만 말하고 더 작은 pool에서의 거동은 예측하지 못한다. 그래서 확정은 같은 인스턴스에서 pool을 목표 수준으로 점진 축소하며 일배치 등 read 피크를 포함한 full 사이클 동안 ReadIOPS/ReadLatency가 평탄하게 유지되는지로 한다. 합격 기준 = 축소 후에도 ReadIOPS가 기준선 대비 안 튐. 자세한 절차는 관련 노트 참조.

관련 노트

참고