AWS 기술 블로그
RDS 데이터베이스의 스토리지 볼륨을 축소하여 인프라 비용 최적화하기
이 글은 AWS Database Blog에 게시된 Shrink storage volumes for your RDS databases and optimize your infrastructure costs by Nitesh Gupta and Keyur Diwan을 한국어 번역 및 편집하였습니다.
Amazon Relational Database Service(Amazon RDS) 오픈 소스 엔진을 사용하면 인스턴스를 확장하거나 축소하는 작업은 비교적 간단합니다. 하지만, 스토리지 크기를 늘린 후 이를 줄이는 작업은 그리 쉽지 않았습니다. 예를 들어, 한 회사가 블랙 프라이데이 이벤트를 준비하기 위해 인프라를 일시적으로 확장해야 할 수 있습니다. 이벤트가 끝난 후에는 비용 절감을 위해 컴퓨팅 및 스토리지 리소스를 축소하고 싶을 것입니다. 블랙 프라이데이 이벤트는 한 가지 사례일 뿐이며, 다양한 다른 사례에서도 수요 변화에 맞춰 스토리지 볼륨을 확장하거나 축소하고 인프라 비용을 더 잘 관리해야 할 필요가 있을 수 있습니다.
이전에는 Amazon RDS 스토리지를 줄이기 위해 더 작은 스토리지 구성으로 새 데이터베이스 인스턴스로 데이터를 수동으로 마이그레이션해야 했습니다. 일반적인 마이그레이션 작업은 다음과 같습니다 :
- 논리적 백업 및 복원:
pg_dump
또는mysqldump
를 사용하여 논리적 백업을 생성한 후, 더 작은 스토리지 크기를 가진 새 인스턴스로 복원. - AWS Database Migration Service(AWS DMS): AWS DMS를 사용해 데이터를 더 작은 스토리지 크기를 가진 새 인스턴스로 복제한 후, 다운타임을 최소화하기 위해 수동으로 전환(cutover).
- 네이티브 데이터베이스 복제:네이티브 데이터베이스 복제 방법(PostgreSQL 논리적 복제 또는 MySQL 바이너리 로그 복제)을 사용해 운영에 최소한의 영향을 주며 데이터 전송.
이러한 방법들은 효과적일 수 있지만, 설정 및 관리가 수동으로 이루어져야 하고, 전환 절차를 조율하는 데 복잡성과 오류 가능성이 있었습니다. 또한, 이 과정은 종종 긴 다운타임을 초래하여 계획되지 않은 비즈니스 중단을 유발했습니다.
최근 Amazon RDS는 Amazon RDS Blue/Green Deployments를 사용하여 스토리지 볼륨을 축소할 수 있는 기능을 도입했습니다. 이는 Blue/Green Deployments가 지원하는 새로운 사용 사례 목록에 추가된 유용한 기능입니다. Blue/Green Deployments는 완전히 관리되는 스테이징 환경(Green 데이터베이스)을 생성하며, 지정된 스토리지 크기로 설정되고 Blue(현재 프로덕션)와 Green 데이터베이스 간 동기화를 유지합니다.
준비가 완료되면 Green 데이터베이스를 새로운 프로덕션 시스템으로 승격시킬 수 있으며, 이는 1분 이내에 이루어질 수 있고 데이터 손실 없이 애플리케이션 변경 없이도 데이터베이스 엔드포인트를 전환할 수 있습니다. 이 간소화된 접근 방식은 더 예측 가능한 다운타임을 제공하며 애플리케이션 요구 사항에 따라 스토리지 볼륨 크기를 증가시키거나 감소시킬 수 있도록 합니다. 또한, 증가된 스토리지 비용에 대한 우려를 해소해 줍니다.
Blue/Green Deployments를 이용한 스토리지 볼륨 축소 기능은 Amazon RDS for PostgreSQL 12 이상 버전, MySQL 5.7 이상 버전, MariaDB 10.4 이상 버전에서 지원합니다.
참고사항으로, 최근 출시되어 강조할 가치가 있는 또 다른 Blue/Green Deployments기능은 그린 데이터베이스를 새로운 프로덕션 시스템으로 승격하기 전에 이제 그린 데이터베이스 스토리지가 완전히 하이드레이션된다는 점입니다. 이전에는 Green 데이터베이스에서 ‘lazy loading of S3’로 인해 스토리지 볼륨을 수동으로 초기화하는 과정이 요구되었습니다.
하지만, 이 게시물에서는 스토리지 축소 기능에 중점을 두고 Amazon RDS 블루/그린 배포를 사용하여 RDS 인스턴스 스토리지를 줄이는 단계를 안내합니다.
Amazon RDS Blue/Green Deployments를 사용한 RDS 스토리지 볼륨 크기 축소
Amazon RDS Blue/Green Deployments를 생성할 때 이제 스토리지 크기를 증가시키거나 감소시킬 수 있으며, io2 또는 gp3와 같은 스토리지 유형 변경 및 스토리지 성능 설정 조정도 가능합니다. 이러한 변경 사항은 Blue/Green create API에서 허용되며 지정된 스토리지 설정에 따라 Green 데이터베이스가 생성됩니다.
Blue/Green 배포에서 스토리지 볼륨 축소 작업의 단계는 다음과 같습니다:
- Green 환경 생성: 새로운 RDS 인스턴스(Green 환경)가 생성되며, 이는 Blue 환경(현재 프로덕션 설정)의 구조를 복사한 것입니다.
- 스토리지 구성 변경: Green 환경에서 스토리지를 조정하고 스토리지 구성을 변경하며, 이 과정에서도 Blue 환경(프로덕션)은 계속 온라인 상태를 유지합니다.
- Blue/Green 동기화: RDS Blue/Green 배포는 현재(Blue) 환경과 새로운(Green) 환경을 동기화하여 데이터 일관성을 보장합니다.
- 관리형 전환(Switchover): Green 환경이 준비되면 전환 명령을 실행할 수 있습니다. Blue/Green 배포는 전환 작업을 수행하여 Green 환경을 새로운 프로덕션 시스템으로 승격하며, 이 과정은 1분 이내로 완료될 수 있습니다.
솔루션 개요
이 게시물에서는 PostgreSQL 엔진을 사용하는 Amazon RDS를 중심으로 설명하지만, 앞서 언급했듯이 이 기능은 MySQL 및 MariaDB에도 사용할 수 있습니다. 여기서는 최소한의 다운타임으로 Amazon RDS for PostgreSQL 데이터베이스 인스턴스의 스토리지를 줄이는 방법을 보여줍니다.
PostgreSQL 물리적 복제를 기본적으로 사용하여 Blue와 Green 환경 간 데이터를 동기화합니다. 그러나 Blue/Green 배포를 생성할 때 주요 버전 업그레이드를 요청하면 PostgreSQL 논리적 복제를 사용하게 됩니다.
높은 수준의 참조를 위해 PostgreSQL 물리적 스트리밍 복제는 정확한 디스크 블록 주소와 바이트 단위 복제를 사용합니다. 전체 클러스터가 동시에 복제됩니다. PostgreSQL 논리적 복제는 복제 ID를 기반으로 데이터 객체와 해당 변경 사항을 복제합니다.
RDS 블루/그린 배포를 위한 복제 방법 조정에 대한 모범 사례를 참조하세요.
사전 요구 사항
시작하기 전에 다음과 같은 사전 요구 사항을 확인하십시오 :
- AWS 계정
- Amazon RDS Blue/Green 배포를 지원하는 PostgreSQL 버전을 실행 중인 기존 RDS for PostgreSQL 인스턴스. 이 예제에서는 RDS PostgreSQL v16.5를 배포합니다.
- 데이터베이스 인스턴스에 최소 1일의 백업 보존 기간이 구성되어 있어야 합니다.
Amazon RDS Blue/Green 배포 생성
Amazon RDS Blue/Green 배포를 생성하기 위해 Amazon RDS 콘솔을 사용합니다. AWS CLI를 사용해서도 동일하게 수행할 수 있습니다.
- Amazon RDS의 AWS Management Console에서 탐색 창에서 데이터베이스를 선택합니다.
- 데이터베이스 인스턴스를 선택하고 작업에서 Blue/Green 배포 생성을 선택합니다.
- Blue/Green 배포 식별자의 이름으로 rpg-db1-bg를 입력하고 다음을 선택합니다.
- Blue/Green 배포 구성 페이지에서 녹색 데이터베이스에 대해 청색 데이터베이스와 동일한 엔진 버전을 선택합니다.
- 스토리지 섹션으로 스크롤을 내려 녹색 데이터베이스의 할당된 스토리지를 설정합니다. 이 게시물에서는 400GB 크기의 (청색) 데이터베이스가 있고, 200GB(50% 스토리지 크기 감소)의 새로운 (녹색) 데이터베이스를 생성합니다. RDS 데이터베이스 인스턴스의 스토리지 크기 조정을 위한 모범 사례를 참조하십시오. 다음을 선택합니다.
- 구성을 검토하고 생성을 선택하여 blue/green 배포를 생성합니다.
- 데이터베이스 크기, 스토리지 유형, 관리되는 초당 입출력 작업(IOPS) 등 다양한 요인에 따라 blue/green 배포를 생성하는 데 몇 시간 또는 며칠이 걸릴 수 있습니다. blue/green 배포의 진행 상황을 추적하려면 모니터링을 참조하십시오.
- 녹색 환경이 완전히 배포되고 사용 가능한 상태로 표시되면, 관리되는 전환을 조율하기 위한 모범 사례를 따를 수 있습니다.
- 전환 후에는 blue/green 배포를 삭제하고, 비용 절감을 위해 이전 청색 인스턴스를 삭제할 수 있습니다.
모니터링
스토리지 크기를 줄이기 위해, 인스턴스는 먼저 동일한 스토리지 크기로 생성된 다음, 자동화 과정에서 스토리지 크기를 줄이기 위한 스토리지 구성 업그레이드를 실행합니다. 스토리지 구성 업그레이드는 녹색 DB 인스턴스를 이전 파일 시스템 레이아웃에서 선호하는 시스템 레이아웃으로 마이그레이션합니다. 이 기간 동안에는 DB 인스턴스에서 엔진이 실행되지 않습니다. 스토리지 볼륨 축소는 시간이 많이 소요되는 작업으로, 몇 시간에서 며칠이 걸릴 수 있습니다. 스토리지 구성 업그레이드가 완료되면 엔진이 실행을 시작하고 blue/green 배포의 다른 단계들(읽기 전용 복제본 생성, 메이저 버전 업그레이드, 백업 구성 등)이 진행됩니다. 다음 섹션에서는 작업의 상태를 모니터링하고 진행 상황을 추적하는 방법을 보여줍니다.
RDS Blue/Green 배포 상태 모니터링
Amazon RDS 콘솔이나 AWS Command Line Interface(AWS CLI)를 사용하여 Blue/Green 배포의 상태 탭에서 배포 상태를 모니터링할 수 있습니다.
Amazon RDS 콘솔을 사용하여 상태를 모니터링하는 방법:
- Amazon RDS 콘솔에서 탐색 창의 데이터베이스를 선택하고 Blue/Green 배포 식별자를 선택합니다.
- 상태 섹션에서 환경의 진행 상황을 확인합니다.
AWS CLI를 이용하여 상태 모니터링 하기:
AWS CLI를 이용하여 상태 모니터링을 하려면, 다음 커맨드를 사용합니다:
스토리지 구성 업그레이드 진행 상황 모니터링
RDS 콘솔이나 AWS CLI를 사용하여 스토리지 구성 업그레이드의 진행 상황을 추적할 수 있습니다.
Amazon RDS 콘솔을 사용하여 업그레이드 진행 상황을 모니터링하는 방법:
- Amazon RDS 콘솔에서 탐색 창의 데이터베이스를 선택합니다.
- 상태 섹션에서 환경의 진행 상황을 확인합니다.
AWS CLI를 사용하여 업그레이드 진행 상황을 모니터링하는 방법:
AWS CLI에서는 describe-db-instances 명령을 사용하여 스토리지 구성 업그레이드를 모니터링할 수 있습니다. 응답의 PercentProgress 필드에서 스토리지 업그레이드 완료 비율을 확인할 수 있습니다.
RDS Blue/Green 배포 이벤트 모니터링
Blue/Green 배포 중에는 AWS 문서에 자세히 설명된 바와 같이 다양한 이벤트가 전송됩니다.
주목할 만한 이벤트는 RDS Blue/Green 배포에서 보내는 알림으로, 녹색 기본 인스턴스와 복제본 생성에 사용된 스토리지 매개 변수를 자세히 설명합니다.
예를 들어, 청색 인스턴스가 GP3 500GB, 12,000 IOPS이고 IO2 200GB로 전환하되 IOPS를 지정하지 않은 경우, 녹색 인스턴스는 IO2 200GB, 12,000 IOPS로 생성됩니다. 청색 복제본 크기와 관계없이 녹색 복제본은 녹색 기본 인스턴스의 스토리지 크기를 상속합니다.
대상 할당 스토리지에 잘못된 값이 제공되어 스토리지 축소가 실패한 경우, RDS Blue/Green 배포에서 알림을 보내 문제를 알려줍니다. 그러나 Blue/Green 배포는 계속 진행되며 청색 기본 인스턴스와 동일한 스토리지 크기의 녹색 인스턴스가 생성됩니다.
모범 사례
이 섹션에서는 RDS 스토리지 볼륨 크기 결정을 위한 적정 크기 조정, RDS 인스턴스 최적화를 통한 스토리지 사용량 감소, RDS 스토리지 볼륨 축소 작업의 성능 최적화에 대한 모범 사례를 논의합니다.
RDS 데이터베이스 인스턴스 스토리지 적정 크기 조정
RDS 데이터베이스 인스턴스는 다음과 같은 다양한 용도로 스토리지를 사용합니다:
- 데이터 파일: 실제 데이터베이스 콘텐츠를 저장하는 디스크 파일.
- 트랜잭션 로그: PostgreSQL Write-Ahead Logs(WAL) 또는 MySQL 바이너리 로그 등의 로그.
- 임시 파일: 메모리에 맞지 않는 작업을 위해 생성된 파일.
- 복제 디스크 사용량: 데이터베이스 복제에 사용되는 공간, 여기에는 PostgreSQL 복제 슬롯도 포함됩니다.
- 데이터베이스 로그: 데이터베이스 오류, 느린 쿼리, 기타 진단 정보에 대한 로그.
RDS 인스턴스의 스토리지 크기를 줄이기 전에 변경하기 전에 성능에 미칠 수 있는 잠재적인 영향을 평가해야 합니다. Amazon RDS 데이터베이스 인스턴스 스토리지를 적절한 크기로 조정할 때는 스토리지 공간과 IOPS, 처리량(초당 MB) 등의 성능 요구 사항을 모두 고려해야 합니다. 적절한 크기 조정에는 현재 스토리지 사용량, IOPS, 처리량 요구 사항을 평가하고 향후 성장을 위한 여유 공간을 허용하는 것이 포함됩니다. 최적의 성능을 보장하려면 유지 관리 기간이나 특별 이벤트와 같이 활동이 많은 기간 동안 데이터베이스 워크로드 지표를 주기적으로 검토해야 합니다. 이러한 지표는 Amazon CloudWatch를 사용하여 모니터링할 수 있습니다.
스토리지 크기
- FreeStorageSpace: 이 CloudWatch 지표는 사용 가능한 스토리지(MB)를 측정합니다. 데이터베이스의 스토리지 사용량을 계산하려면 다음 공식을 사용하십시오:
Database instance storage used = Allocated storage size – FreeStorageSpace
RDS 인스턴스는 삽입, 업데이트, 인덱스 생성 등의 일반적인 데이터베이스 작업을 위해 스토리지를 사용합니다. 성능에 영향을 미치지 않도록 충분한 여유 공간을 확보해야 합니다. - 모범 사례: 특히 트랜잭션이 많은 데이터베이스의 경우 최소 20%의 여유 공간을 유지하여 잦은 크기 조정을 방지합니다. 또한 대규모 테이블 재구축 등의 유지 관리 작업을 처리할 수 있는 충분한 여유 공간을 확보해야 합니다. 대상 할당 스토리지가 사용된 스토리지의 1.2배(사용 스토리지보다 20% 더) 미만인 경우 RDS Blue/Green 배포에서 스토리지 축소에 실패하지만, Blue/Green 배포는 계속 진행되며 청색 기본 인스턴스와 동일한 스토리지 크기의 녹색 인스턴스가 생성됩니다.
스토리지 IOPS 성능
- WriteIOPS: 초당 작업 수로 측정되는 이 CloudWatch 지표는 평균 디스크 쓰기 I/O 작업 수를 나타냅니다.
- ReadIOPS: 초당 작업 수로 측정되는 이 CloudWatch 지표는 평균 디스크 읽기 I/O 작업 수를 나타냅니다.
스토리지 처리량 성능
- WriteThroughput: 이 지표는 초당 디스크에 쓰이는 평균 바이트 수를 나타냅니다.
- ReadThroughput: 이 지표는 초당 디스크에서 읽히는 평균 바이트 수를 나타냅니다.
Amazon RDS는 범용 SSD(gp2, gp3)와 프로비저닝된 IOPS SSD(io1, io2) 등 다양한 유형의 스토리지 볼륨을 지원합니다. gp2 및 gp3 볼륨의 경우 할당된 스토리지 크기가 기준 IOPS와 처리량 성능을 직접 결정합니다. 프로비저닝된 IOPS(io1, io2)의 경우 성능이 명시적으로 설정됩니다.
모범 사례: 스토리지 볼륨 유형과 할당된 스토리지에 대한 기준 IOPS 및 처리량이 각각 피크 ReadIOPS 및 WriteIOPS, 피크 ReadThroughput 및 WriteThroughput 값보다 큰지 확인합니다.
RDS 인스턴스 최적화를 통한 스토리지 사용량 감소
Amazon RDS for PostgreSQL, MySQL 및 MariaDB는 동시 접근성 향상을 위해 다중 버전 동시성 제어(MVCC)를 사용합니다. MVCC를 통해 데이터의 여러 버전을 유지할 수 있어, 읽기와 쓰기 작업이 서로를 방해하지 않고 자신의 데이터 버전에 액세스할 수 있습니다. 데이터가 업데이트되면 원래 데이터 항목을 새 데이터로 덮어쓰지 않고 새 버전의 데이터 항목을 생성합니다.
MVCC는 오랜 시간에 걸쳐 데이터 팽창을 초래할 수 있습니다. 불필요한 데이터가 누적되면 스토리지 공간 사용량이 늘어나고 데이터 액세스가 비효율적이며 비용이 증가합니다. PostgreSQL은 백그라운드 프로세스인 vacuum을, MySQL은 purge 프로세스를 사용하여 더 이상 필요하지 않은 데이터를 제거합니다. RDS for PostgreSQL vacuum과 RDS for MySQL purge 프로세스 튜닝에 대한 모범 사례는 다음 게시물을 참조하십시오.
정기적인 vacuum 또는 purge는 불필요한 데이터가 차지하고 있는 공간을 정리하여 후속 작업에 사용할 수 있게 하므로 데이터 팽창을 최소화할 수 있습니다.
또한 Amazon Simple Storage Service(Amazon S3)에 데이터를 아카이브하고, 불필요한 데이터를 삭제하며, 운영 효율성을 높이는 등의 방법으로 스토리지 사용량을 추가로 최적화할 수 있습니다. 예를 들어 다음과 같은 방법으로 데이터베이스 인스턴스 스토리지 사용량을 줄일 수 있습니다:
- S3에 기록 데이터를 아카이빙하는 데이터 수명 주기 관리 구현
- WAL 압축 사용
- 사용되지 않는 인덱스 제거
- 불필요한 임시 테이블 삭제
- 디버그 기간이 아닌 경우 로깅 레벨 감소
PostgreSQL vacuum이나 MySQL purge를 수행해도 테이블이나 인덱스를 재구축하기 전에는 스토리지 공간이 해제되지 않습니다.
모범 사례: 데이터를 S3로 보관하는 등 대규모 업데이트나 삭제 작업 후에는 PostgreSQL pg_repack 또는 MySQL optimize table을 실행하여 관련 테이블과 인덱스를 재구축하고 스토리지 공간을 해제해야 합니다.
RDS 스토리지 볼륨 축소 성능 최적화
스토리지 볼륨 축소 작업 수행 시 성능과 작업 성공에 영향을 미치는 여러 요인이 있습니다. 이 섹션에서는 스토리지 볼륨 축소 작업을 효과적으로 관리하기 위한 주요 최적화 전략과 모범 사례를 설명합니다. io2 Block Express 스토리지를 활용하여 성능을 높이는 방법, 복제 스토리지 사용량 모니터링, 다양한 PostgreSQL 복제 방법이 미치는 영향 등을 살펴봅니다.
다음 섹션에서는 데이터베이스 가용성과 성능을 유지하면서 이러한 최적화를 구현하는 방법에 대한 자세한 지침을 제공합니다.
io2 Block Express로 성능 향상
RDS 스토리지 볼륨 축소는 I/O 집약적인 작업입니다. 이 작업은 물리적 데이터 블록 복사를 수행하여 녹색 인스턴스의 스토리지를 재구성합니다. 녹색 인스턴스의 기반 스토리지 성능은 작업 완료 시간에 중요한 역할을 합니다. 스토리지 볼륨 축소 작업의 성능을 향상시키려면 녹색 인스턴스 생성 시 최고의 성능을 제공하는 io2 Block Express 스토리지를 사용하는 것을 고려해 볼 수 있습니다. io2 Block Express는 최대 4,000MB/s의 처리량과 256,000개의 프로비저닝된 IOPS를 제공하면서도 io1과 동일한 비용을 유지합니다. 현재 프로비저닝된 IOPS(io1)를 사용하고 있다면 io2로 업그레이드하면 성능과 비용 효율성을 모두 높일 수 있습니다.
모범 사례: 스토리지 크기 축소 작업의 성능 향상과 비용 효율성을 위해 io2 Block Express로 업그레이드를 고려해 보세요. 그러나 프로덕션 볼륨을 전환하기 전에 사전 운영 환경에서 io2 볼륨을 테스트하는 것이 좋습니다.
복제 스토리지 사용량 모니터링
스토리지 볼륨 축소 작업은 녹색 스테이징 환경을 생성하고, 프로덕션 청색 환경을 온라인 상태로 유지하면서 스테이징 환경의 스토리지 볼륨 크기를 조정합니다. 스테이징 환경에서 할당된 스토리지 감소는 데이터베이스 크기, 스토리지 유형, 관리 IOPS 등 다양한 요인에 따라 며칠이 소요될 수 있는 스토리지 구성 업그레이드와 병행됩니다. 이 과정에서 프로덕션 청색 데이터베이스의 데이터베이스 트랜잭션 로그 및 복제 스토리지 사용량이 증가합니다. 다음 CloudWatch 지표를 사용하여 복제에 사용되는 스토리지를 모니터링할 수 있습니다.
- BinLogDiskUsage(MySQL, MariaDB): 바이너리 로그가 차지하는 디스크 공간 크기. MySQL과 MariaDB 인스턴스의 자동 백업(읽기 전용 복제본 포함)이 활성화되면 바이너리 로그가 생성됩니다.
- TransactionLogsDiskUsage(PostgreSQL): 트랜잭션 로그에 사용되는 디스크 공간.
- ReplicationSlotDiskUsage(PostgreSQL): 복제 슬롯 파일에 사용되는 디스크 공간.
모범 사례: 청색 인스턴스의 사용 가능한 스토리지와 스토리지 크기 관련 이벤트를 정기적으로 모니터링하십시오. 스토리지가 용량에 근접할 것으로 예상되는 경우 청색 인스턴스의 스토리지 크기를 조정하는 것을 고려해 보세요. 이 작업은 녹색 데이터베이스의 스토리지 크기에는 영향을 미치지 않습니다.
PostgreSQL 복제 방법 튜닝
RDS Blue/Green 배포는 녹색 환경의 사양에 따라 PostgreSQL 물리적 스트리밍 또는 논리적 복제 기술을 사용합니다. PostgreSQL 물리적 스트리밍 복제는 정확한 디스크 블록 주소와 바이트 단위 복제를 사용합니다. 대상은 소스의 복제본입니다. 복제 소스와 대상은 동일한 메이저 버전을 실행해야 합니다. PostgreSQL 논리적 복제는 복제 ID(예: 기본 키)를 기반으로 데이터 개체와 변경 사항을 복제합니다. 복제 소스와 대상은 다른 메이저 버전을 실행할 수 있습니다. 그러나 PostgreSQL 논리적 복제에는 데이터 정의 언어(DDL), 대용량 객체 등의 복제에 대한 제한 사항이 있습니다. 논리적 복제의 제한 사항에 대한 자세한 내용은 PostgreSQL 문서의 “31.6. 제한 사항“을 참조하십시오.
RDS Blue/Green 배포에서 사용되는 복제 방법 유형을 확인하려면 청색 데이터베이스에 로그인하고 “SELECT * FROM pg_replication_slots;”를 실행하십시오. 슬롯 유형 열의 값이 “physical”이면 물리적 스트리밍 복제, “logical”이면 논리적 복제를 나타냅니다.
녹색 DB 인스턴스가 물리적 복제본으로 생성된 경우 녹색 환경 생성 후에는 메이저 버전 업그레이드를 수동으로 수행할 수 없습니다.
![](https://d2908q01vomqb2.cloudfront.net/2a459380709e2fe4ac2dae5733c73225ff6cfee1/2025/01/17/DBBLOG-4410-img7.png)
모범 사례: PostgreSQL 논리적 복제의 제한 사항을 피하기 위해 스토리지 볼륨 축소와 DB 엔진 메이저 버전 업그레이드를 별도의 작업으로 수행하는 것이 좋습니다.
결론
이 게시물에서는 Amazon RDS Blue/Green 배포의 새로운 스토리지 볼륨 축소 기능을 사용하여 스토리지 크기 감소 작업에 필요한 중단 시간을 최소화하는 방법을 다루었습니다. 또한 스토리지 축소 진행 상황을 모니터링하고 축소 작업에 적합한 최적의 스토리지 크기를 결정하는 다양한 방법을 살펴보았습니다. 이제 연말 쇼핑 시즌이 다가오므로 걱정 없이 인프라를 확장할 수 있습니다. 필요하다면 휴일 이후에 스토리지를 축소할 수 있습니다.
피드백이나 질문이 있으시면 댓글 섹션에 남겨주시기 바랍니다.