AmazonRDS에 잠재되어 있는 StorageAutoScalling의 함정

이번에는 RDS Storage Auto Scoling을 실시했기 때문에 주의사항도 포함해서 기사화하려고 합니다.
https://aws.amazon.com/about-aws/whats-new/2019/06/rds-storage-auto-scaling/?nc1=h_ls:embed:cite
· 지금까지 RDS에 첨부된 EBS는 어느 정도의 중요한 예측과 IOPS를 고려하여 사이즈를 결정하는 시동식 규격이지만, 임의의 용량을 미리 설정하기만 하면 현지에서 자동으로 축소하는 서비스를 시작할 수 있다.비동기식으로 처리되더라도 입출력 중단이 발생하지 않으므로 효과적입니다.하지만 미리 알고 싶은 곳이 있다.

빅데이터를 한 번에 포획할 때 척도상 시간이 필요하기 때문에 기능이 떨어질 수 있다

눈금 이후 6시간 또는 DB 실례 상태가 [storage-optimization] 사이의 어느 쪽이든 긴 기간 동안 축소되지 않음

2017년 11월부터 스토리지 패브릭을 수정하지 않은 경우 DB 인스턴스를 편집하여 할당된 스토리지를 늘리는 데 몇 분 동안 중단

이 발생할 수 있음
• 1과 2는 검증이 필요하고 발생 확률이 낮아 커버를 활용할 수 있지만 3은 무서워요...이 말을 하자면 대상 RDS가 Elastic Volume이 아니면 입출력이 중단될 수도 있지 않을까요?그렇습니다.
또한 Elastic Volume이 아닌 경우에는 CLI 및 GUI를 참조할 수 없습니다.
따라서 2017년 11월 이전부터 시작된 RDS가 확인되지 않고 실행될 경우 입출력이 중단될 가능성이 있다.문서를 잘 읽어보지 않으면 손상을 입을 수 있다.
https://aws.amazon.com/jp/about-aws/whats-new/2017/11/amazon-rds-now-supports-database-storage-size-up-to-16tb-and-faster-scaling-for-mysql-mariadb-oracle-and-postgresql-engines/:embed:cite
• 이번 Created time는 Thu Jun02 2016 10:32:42 GMT+090(일본 표준시)의 RDS에 Starge Auto Scaling을 사용합니다.
결과적으로 I/O 중단은 발생하지 않았지만 확대/축소 시 볼륨 간 데이터 이동이 발생했고 Write IOPS와 ReadIOPS가 스매싱되었다.

· 이 RDS 실례이론상 기초선 성능은 1200IOPS(gp2의 돌발 최대 3000IOPS)로 신용이 소진돼도 서비스에 지장이 없으나 경보에 불이 날 수 있다는 정신적 부정적인 소식이다.그 결과 400GiB에서 Elastic Volume으로 이동하는 데 65분가량 걸렸다.
• 최신 업데이트는 과거의 여러 업데이트와 관련이 있기 때문에 다시 한 번 자세히 볼 필요가 있음을 깨달았다.나는 모닥불로 정신의 규모를 더 키우고 싶다...