메뉴
Amazon Relational Database Service
사용 설명서 (API Version 2014-10-31)

Amazon RDS 모범 사례

Amazon RDS 작업 모범 사례에 대해서 알아봅니다. 새로운 모범 사례가 확인되는 대로 이 섹션을 업데이트할 예정입니다.

Amazon RDS 기본 운영 지침

다음은 Amazon RDS로 작업할 때 모든 사용자가 따라야 하는 기본 운영 지침입니다. Amazon RDS 서비스 수준 계약에 다음 지침을 따르도록 명시되어 있습니다.

  • 메모리, CPU 및 스토리지 사용을 모니터링합니다. Amazon CloudWatch에서 사용 패턴이 변경되거나 사용자가 배포 용량에 도달했을 때 알림을 받도록 설정할 수 있으므로 시스템 성능과 가용성을 유지할 수 있습니다.

  • 스토리지 용량 한도에 도달할 경우 DB 인스턴스를 확장합니다. 스토리지 및 메모리에 어느 정도 버퍼가 있어야만 애플리케이션에서 수요가 예기치 않게 늘어날 경우 이를 수용할 수 있습니다.

  • 자동 백업을 활성화하고 일일 쓰기 IOPS가 낮은 동안 백업 창이 열리도록 설정합니다.

  • 데이터베이스 작업량으로 인해 프로비저닝한 I/O보다 많이 필요할 경우 장애 조치 또는 데이터베이스 오류가 발생한 후에 복구 속도가 느려집니다. DB 인스턴스의 I/O 용량을 늘리려면 다음 중 일부 항목이나 모든 항목을 수행하십시오.

    • I/O 용량이 높은 DB 인스턴스 클래스로 마이그레이션합니다.

    • 필요한 증분 양에 따라 표준 스토리지를 범용 또는 프로비저닝된 IOPS 스토리지로 변환합니다. 사용 가능한 스토리지 유형에 대한 자세한 내용은 Amazon RDS 스토리지 유형 단원을 참조하십시오.

      프로비저닝된 IOPS 스토리지로 변환할 경우 프로비저닝된 IOPS에 최적화된 DB 인스턴스 클래스를 사용해야 합니다. 프로비저닝된 IOPS에 대한 자세한 내용은 성능 개선을 위한 Amazon RDS 프로비저닝된 IOPS 스토리지 단원을 참조하십시오.

    • 이미 프로비저닝된 IOPS 스토리지를 사용하고 있는 경우 추가 처리 용량을 프로비저닝합니다.

  • 클라이언트 애플리케이션이 DB 인스턴스의 DNS(Domain Name Service) 데이터를 캐시하는 경우 TTL(Time-to-Live) 값을 30초 미만으로 설정합니다. 장애 조치 이후에 DB 인스턴스의 기본 IP 주소가 변경될 수 있기 때문에 DNS 데이터를 오랜 시간 동안 캐시하면 애플리케이션이 더 이상 서비스되지 않는 IP 주소에 연결하려 할 경우 연결 오류로 이어질 수 있습니다.

  • 사용 사례에 대한 프로세스가 얼마나 오래 걸리는지 이해하고 DB 인스턴스에 액세스하는 애플리케이션이 장애 조치 이후에 새 DB 인스턴스에 자동으로 연결할 수 있는지 확인하려면 DB 인스턴스에 대한 장애 조치를 테스트합니다.

DB 인스턴스 RAM 권장 사항

작업 집합이 거의 완전히 메모리에 상주하도록 RAM을 충분히 할당하는 것이 Amazon RDS 성능 모범 사례에 따르는 길입니다. 작업 집합이 거의 전부 메모리에 있는지 확인하려면 (Amazon CloudWatch를 사용하여) DB 인스턴스에 작업 부하가 걸려 있는 동안 ReadIOPS 메트릭을 확인하십시오. ReadIOPS의 값은 작고 안정적이어야 합니다. DB 인스턴스 클래스를 RAM이 더 많은 클래스로 확장하여 ReadIOPS가 대폭 떨어질 경우, 작업 집합이 거의 완전히 메모리에 상주하지는 못합니다. 규모 조정 작업 후 ReadIOPS가 더 이상 대폭 떨어지지 않을 때까지 계속 확장합니다. 그렇지 않으면 ReadIOPS가 매우 작은 양으로 감소됩니다. DB 인스턴스의 측정치 모니터링에 대한 자세한 내용은 DB 인스턴스 측정치 보기 단원을 참조하십시오.

Amazon RDS 보안 모범 사례

AWS IAM 계정을 사용해 Amazon RDS API 작업 중에서도 DB 인스턴스, 보안 그룹, 옵션 그룹 또는 파라미터 그룹 같은 RDS 리소스를 만들거나 수정하거나 삭제하는 작업과 DB 인스턴스를 백업하고 복원하거나 프로비저닝된 IOPS 스토리지를 구성하는 등 일반적인 관리 작업을 수행하는 작업에 대한 액세스를 제어하십시오.

  • RDS 리소스를 관리하는 각 사용자에게 개별 IAM 계정을 할당합니다. AWS 루트 자격 증명을 사용해 Amazon RDS 리소스를 관리하지 마십시오. 자기 자신을 포함한 모두를 위해 IAM 사용자를 만들어야 합니다.

  • 각 사용자에게 각자의 임무를 수행하는 데 필요한 최소 권한 집합을 부여합니다.

  • IAM 그룹을 사용해 여러 사용자에 대한 권한을 효과적으로 관리합니다.

  • IAM 자격 증명을 정기적으로 순환합니다.

IAM에 대한 자세한 내용은 AWS Identity and Access Management를 참조하십시오. IAM 모범 사례에 대한 자세한 내용은 IAM Best Practices를 참조하십시오.

Enhanced Monitoring을 통한 운영 체제 문제 식별

Amazon RDS는 DB 인스턴스가 실행되는 운영 체제(OS)에 대한 측정치를 실시간으로 제공합니다. 콘솔을 사용하여 DB 인스턴스에 대한 측정치를 보거나, 선택한 모니터링 시스템의 Amazon CloudWatch Logs에서 Enhanced Monitoring JSON 출력을 사용할 수 있습니다. Enhanced Monitoring에 대한 자세한 내용은 Enhanced Monitoring 단원을 참조하십시오.

Enhanced Monitoring은 다음 데이터베이스 엔진에 사용할 수 있습니다.

  • Amazon Aurora

  • MariaDB

  • Microsoft SQL Server

  • MySQL 버전 5.5 이상

  • Oracle

  • PostgreSQL

Enhanced Monitoring은 db.t1.microdb.m1.small을 제외한 모든 DB 인스턴스 클래스에서 사용할 수 있습니다. Enhanced Monitoring은 AWS GovCloud (US)을 제외한 모든 리전에서 사용할 수 있습니다.

지표를 통해 성능 문제 식별

리소스 부족이나 기타 일반적인 병목으로 인해 발생하는 성능 문제를 식별하기 위해 Amazon RDS DB 인스턴스에서 사용할 수 있는 지표를 모니터링할 수 있습니다.

성능 지표 보기

다양한 기간 동안의 평균, 최대, 최소 측정값을 보려면 성능 지표를 정기적으로 모니터링해야 합니다. 이렇게 하면 성능이 저하된 시점을 식별할 수 있습니다. 또한 특정 지표 임계값에 대해 Amazon CloudWatch 경보를 설정하여 해당 임계값에 이를 경우 알리도록 할 수 있습니다.

성능 문제를 해결하기 위해서는 시스템의 기준 성능을 파악해야 합니다. 새로운 DB 인스턴스를 설정하여 일반적인 워크로드 실행할 경우 다양한 간격(예: 1시간, 24시간, 1주, 2주)으로 모든 성능 측정의 평균값, 최댓값, 최솟값을 수집하여 정상 상태를 파악해야 합니다. 이렇게 하면 작업의 최고 피크와 최저 피크 시간을 비교할 수 있습니다. 그런 다음 이 정보를 사용하여 성능이 표준 수준 이하로 떨어진 때를 식별할 수 있습니다.

성능 지표를 보려면

  1. AWS Management Console에 로그인한 다음 https://console.aws.amazon.com/rds/에서 Amazon RDS 콘솔을 엽니다.

  2. 왼쪽 탐색 창에서 [Instances]를 선택한 후 DB 인스턴스를 선택합니다.

  3. [Show Monitoring]을 선택합니다. 처음 8개의 성능 지표가 표시됩니다. 지표는 기본적으로 현재 날짜의 데이터가 표시됩니다.

  4. 상단 오른쪽의 번호 버튼을 사용하여 다른 페이지의 지표를 보거나, [Show All]을 선택하여 모든 지표를 봅니다.

  5. 다른 날짜의 데이터를 보려면 성능 지표의 시간 범위를 조정합니다. [Statistic], [Time Range] 및 [Period] 값을 변경하여 표시되는 정보를 조정할 수 있습니다. 예를 들어 지난 2주 동안 각 날짜의 지표에 대한 피크 값을 보려면 [Statistic]를 [Maximum]으로, [Time Range]를 [Last 2 Weeks]로, [Period]를 [Day]로 설정합니다.

    참고

    [Statistic], [Time Range], [Period] 값을 변경하면 모든 지표에 대해 변경됩니다. 업데이트된 값은 현재 세션 동안 또는 다시 값을 변경할 때까지 유지됩니다.

CLI 또는 API를 사용하여 성능 지표를 볼 수도 있습니다. 자세한 내용은 DB 인스턴스 측정치 보기 단원을 참조하십시오.

CloudWatch 경보를 설정하려면

  1. AWS Management Console에 로그인한 다음 https://console.aws.amazon.com/rds/에서 Amazon RDS 콘솔을 엽니다.

  2. 왼쪽 탐색 창에서 [Instances]를 선택한 후 DB 인스턴스를 선택합니다.

  3. [Show Monitoring]을 선택한 후 성능 지표를 선택하여 확장된 보기를 불러옵니다.

  4. [Create Alarm]을 선택합니다.

  5. [Create Alarm] 페이지에서 [Send a notification to] 상자의 값을 선택하여 알림을 받을 이메일 주소를 지정합니다. 필요할 경우 해당 상자 오른쪽에 있는 [create topic]을 선택하여 경보 수신자를 새로 만듭니다.

  6. [Whenever] 목록에서 설정할 경보 통계를 선택합니다.

  7. [of] 상자에서 경보 지표를 선택합니다.

  8. [Is] 상자와 그 오른쪽에 있는 상자에서 다음과 같이 경보 임계값을 설정합니다.

     Create Alarm 대화 상자
  9. [For at least] 상자에, 지정한 임계값에 몇 번 도달해야 경보를 발생할지 횟수를 입력합니다.

  10. [consecutive period(s) of] 상자에 임계값이 얼마나 유지되어야 경보를 발생할지 기간을 입력합니다.

  11. [Name of alarm] 상자에 경보 이름을 입력합니다.

  12. [Create Alarm]을 선택합니다.

성능 지표 페이지가 나타나고 CloudWatch Alarms 상태 표시줄에 새로운 경보가 나타납니다. 상태 표시줄이 보이지 않으면 페이지를 새로 고치십시오.

성능 지표 평가

한 개의 DB 인스턴스에는 서로 다른 많은 카테고리의 지표가 있으며, 허용되는 값을 결정하는 방법은 지표에 따라 다릅니다.

CPU

  • CPU 사용률 - 사용된 컴퓨터 처리 용량의 백분율입니다.

메모리

  • 여유 메모리 - DB 인스턴스에서 사용 가능한 RAM을 메가바이트 단위로 나타냅니다.

  • 스왑 사용량 - DB 인스턴스에서 스왑 공간을 얼마나 많이 사용했는지를 메가바이트 단위로 나타냅니다.

디스크 공간

  • 여유 스토리지 공간 - DB 인스턴스에서 현재 사용하지 않고 있는 디스크 공간의 크기(MB)

입력/출력 작업

  • IOPS 읽기, IOPS 쓰기 - 초당 디스크 읽기 또는 쓰기 작업의 평균 횟수입니다.

  • 읽기 지연 시간, 쓰기 지연 시간 - 읽기 또는 쓰기 작업의 평균 시간(밀리초)입니다.

  • 읽기 처리량, 쓰기 처리량 - 초당 디스크에서 읽거나 디스크에 쓴 평균 크기(메가바이트)입니다.

  • 대기열 길이 - 디스크에 쓰기 위해 또는 디스크에서 읽기 위해 대기 중인 I/O 작업의 수입니다.

네트워크 트래픽

  • 네트워크 수신 처리량, 네트워크 전송 처리량 - DB 인스턴스에 대한 수신 또는 전송 네트워크 트래픽 속도(초당 메가바이트)입니다.

데이터베이스 연결

  • DB 연결 - DB 인스턴스에 연결된 클라이언트 세션의 수입니다.

사용 가능한 각 성능 지표에 대한 자세한 내용은 Amazon RDS 차원 및 측정치를 참조하십시오.

일반적으로 성능 지표에 허용되는 값은 기준이 무엇인지 그리고 애플리케이션 무엇을 수행하는지에 따라 다릅니다. 기준과의 일관된 차이 또는 추세를 조사하십시오. 특정 지표 유형에 대한 참고 정보는 다음과 같습니다.

  • CPU 또는 RAM 사용량이 많음 - CPU 또는 RAM 사용량이 많을 경우 해당 애플리케이션의 목표와 일치하고 예상되는 결과라면 문제가 되지 않을 수 있습니다.

  • 디스크 공간 사용량 - 총 디스크 용량의 85퍼센트 이상이 계속 사용될 경우 디스크 공간 사용량을 검사합니다. 인스턴스에서 데이터를 삭제할 수 있는지 또는 다른 시스템에 데이터를 아카이브하여 공간을 확보할 수 있는지 확인합니다.

  • 네트워크 트래픽 - 네트워크 트래픽의 경우 시스템 관리자에게 문의하여 해당 도메인 네트워크 및 인터넷 연결의 기대 처리량을 확인합니다. 처리량이 기대값보다 항상 낮으면 네트워크 트래픽을 검사합니다.

  • 데이터베이스 연결 - 인스턴스 성능 저하 및 응답 시간 지연과 함께 사용자 연결 수가 많을 경우 데이터베이스 연결 제한을 고려해 봅니다. DB 인스턴스에 대한 최적의 사용자 연결 수는 해당 인스턴스 클래스와, 수행하는 작업의 복잡성에 따라 다릅니다. DB 인스턴스를 User Connections 파라미터가 0(무제한)이 아닌 다른 값으로 설정된 파라미터 그룹과 연결하여 데이터베이스 연결 수를 지정할 수 있습니다. 기존 파라미터 그룹을 사용하거나 새로 하나 만들 수 있습니다. 자세한 내용은 DB 파라미터 그룹 작업 단원을 참조하십시오.

  • IOPS 지표 - IOPS 지표의 기대값은 디스크 사양 및 서버 구성에 따라 다르므로 해당 기준에 일반적인 값을 파악합니다. 값이 기준과 계속 차이가 나는지 검사합니다. 최적의 IOPS 성능을 위해, 일반적인 작업 세트가 메모리에 적합하고 읽기 및 쓰기 작업을 최소화하는지 확인합니다.

성능 지표와 관련하여 문제가 있을 경우 성능을 향상하기 위해 제일 먼저 할 수 있는 것은, 가장 많이 사용되고 가장 비용이 높은 쿼리를 튜닝하여 시스템 리소스에 대한 부하를 줄일 수 있는지 확인하는 것입니다. 자세한 내용은 쿼리 튜닝 단원을 참조하십시오.

쿼리를 튜닝해도 문제가 지속된다면, 문제와 관련된 DB 인스턴스 클래스리소스(CPU, RAM, 디스크 공간, 네트워크 대역폭, I/O 용량)를 추가하여 Amazon RDS를 업그레이드하십시오.

쿼리 튜닝

DB 인스턴스 성능을 향상하는 제일 좋은 방법 중 하나는 일반적으로 가장 많이 사용하는 쿼리와 리소스를 가장 많이 사용하는 쿼리를 튜닝하여 실행 비용을 낮추는 것입니다.

MySQL 쿼리 튜닝

성능을 높이기 위한 쿼리 작성에 대한 자세한 내용은 MySQL 문서에서 Optimizing SELECT Statements를 참조하십시오. 다른 쿼리 튜닝 리소스에 대한 내용은 MySQL Performance Tuning and Optimization Resources를 참조하십시오.

Oracle 쿼리 튜닝

성능을 높이기 위한 쿼리 쓰기 및 분석에 대한 자세한 내용은 Oracle 문서에서 Database SQL Tuning Guide를 참조하십시오.

SQL Server 쿼리 튜닝

SQL Server DB 인스턴스의 쿼리를 향상시키려면 SQL Server 문서에서 Analyzing a Query를 참조하십시오. 또한 동적 관리 뷰 및 함수(Transact-SQL) 문서에서 설명한 실행 관련, 인덱스 관련 및 I/O 관련 데이터 관리 보기(DMV)를 사용하여 SQL Server 쿼리 문제를 해결할 수도 있습니다.

쿼리 튜닝의 공통적인 부분은 효율적인 인덱스를 만드는 것입니다. 데이터베이스 엔진 튜닝 관리자를 사용하여 DB 인스턴스에 대한 인덱스 성능을 높일 수 있습니다. 자세한 내용은 SQL Server 튜닝 어드바이저를 사용한 Amazon RDS DB 인스턴스의 데이터베이스 워크로드 분석 단원을 참조하십시오.

PostgreSQL 쿼리 튜닝

쿼리 계획을 분석하는 방법은 PostgreSQL 문서에서 Using EXPLAIN을 참조하십시오. 이 정보를 참조하여 쿼리 성능을 높이기 위해 쿼리나 기본 테이블을 수정할 수 있습니다. 또한 Controlling the Planner with Explicit JOIN Clauses에서 최적의 성능을 위해 쿼리에 조인을 지정하는 방법에 대한 도움말을 볼 수 있습니다.

MariaDB 쿼리 튜닝

성능을 높이기 위한 쿼리 쓰기에 대한 자세한 내용은 MariaDB 설명서에서 Query Optimizations를 참조하십시오.

Amazon Aurora 작업 모범 사례

Amazon Aurora의 성능 및 안정성은 Aurora DB 클러스터 및 DB 인스턴스에서 사용되는 데이터베이스 엔진에 따라 여러 가지 다른 옵션을 사용하여 높일 수 있습니다. Amazon Aurora 모범 사례에 대한 자세한 내용은 Amazon Aurora 모범 사례 단원을 참조하십시오.

MySQL 스토리지 엔진으로 작업하기 위한 모범 사례

MySQL DB 인스턴스에서 다음 테이블 생성 제한을 준수합니다.

  • 프로비저닝된 IOPS 스토리지를 사용하거나, 범용 스토리지를 사용하고 인스턴스가 200GB 이상인 경우 10,000개의 테이블로 제한됩니다.

  • 표준 스토리지를 사용하거나, 범용 스토리지를 사용하고 인스턴스가 200GB 미만인 경우 1,000개의 테이블로 제한됩니다.

테이블 수가 많을 경우 장애 조치 또는 데이터베이스 충돌 후 데이터베이스 복구 시간이 크게 증가되므로 이러한 제한을 사용하는 것이 좋습니다. 권장 개수보다 많은 테이블을 만들 필요가 있는 경우에는 innodb_file_per_table 파라미터를 0으로 설정합니다. 자세한 내용은 충돌 복구 시간 개선을 위한 InnoDB 테이블스페이스 작업 및 DB 파라미터 그룹 작업 단원을 참조하십시오.

버전 5.7 이상을 사용하는 MySQL DB 인스턴스의 경우 InnoDB 충돌 복구 기능의 향상으로 이러한 테이블 생성 제한을 초과할 수 있습니다. 하지만 매우 많은 테이블을 생성할 경우 성능에 영향을 줄 수 있으므로 주의해야 합니다.

MySQL DB 인스턴스에서 데이터베이스의 테이블이 너무 크게 늘어나지 않도록 합니다. 프로비저닝 스토리지 제한에 따라 MySQL 테이블 파일의 최대 크기를 6TB로 제한합니다. 대신 파일 크기가 6TB 제한을 넘지 않도록 라지 테이블을 분할합니다. 이 접근 방식을 수행하면 성능 및 복구 시간도 향상할 수 있습니다. 자세한 내용은 MySQL 파일 크기 제한 단원을 참조하십시오.

MySQL용 Amazon RDS의 특정 시점으로 복원 및 스냅샷 복원 기능을 사용하려면 중단 복구 가능 스토리지 엔진이 필요하며, 이러한 기능은 InnoDB 스토리지 엔진에서만 지원됩니다. MySQL은 다양한 기능을 가진 여러 스토리지 엔진을 지원하지만, 모든 엔진이 충돌 복구와 데이터 내구성에 최적화되어 있지는 않습니다. 예를 들어 MyISAM 스토리지 엔진은 안정적인 충돌 복구를 지원하지 않으며, 이로 인해 특정 시점으로 복원 또는 스냅샷 복원이 의도한 대로 작동하지 못할 수 있습니다. 그 결과 충돌 후 MySQL을 다시 시작하면 데이터가 손실되거나 손상될 수 있습니다.

InnoDB는 Amazon RDS에서 MySQL DB 인스턴스용으로 권장되고 지원되는 스토리지 엔진입니다. InnoDB 인스턴스는 Aurora로 마이그레이션할 수 있지만, MyISAM 인스턴스는 마이그레이션할 수 없습니다. 하지만 MyISAM은 강력한 전체 텍스트 검색 기능이 필요한 경우 InnoDB보다 나은 성능을 발휘합니다. 그래도 Amazon RDS와 함께 MyISAM을 사용하도록 선택할 경우 지원되지 않는 MySQL 스토리지 엔진에 대한 자동 백업에 개략적으로 설명되어 있는 단계를 따르면 특정한 시나리오에서 스냅샷 복원 기능에 유용할 수 있습니다.

기존 MyISAM 테이블을 InnoDB 테이블로 변환하려는 경우 MySQL 설명서에 나와 있는 프로세스를 사용하면 됩니다. MyISAM과 InnoDB는 각기 다른 장점과 단점을 갖고 있으므로 전환하기 전에 이 전환이 애플리케이션에 미치는 영향을 충분히 평가해야 합니다.

또한 MySQL을 위한 외부 스토리지 엔진은 현재 Amazon RDS에서 지원되지 않습니다.

MariaDB 스토리지 엔진으로 작업하기 위한 모범 사례

MariaDB용 Amazon RDS의 특정 시점으로 복원 및 스냅샷 복원 기능을 사용하려면 충돌 복구 가능 스토리지 엔진이 필요하며, XtraDB 스토리지 엔진에 대해서만 지원됩니다. MariaDB는 다양한 기능을 가진 여러 스토리지 엔진을 지원하지만, 모든 엔진이 충돌 복구와 데이터 내구성에 최적화되어 있지는 않습니다. 예를 들어, Aria가 충돌 안정성을 개선한 MyISAM 대체 스토리지 엔진이지만, 여전히 특정 시점으로 복원 또는 스냅샷 복원이 의도한 대로 작동하지 못할 수 있습니다. 그 결과 충돌 후 MariaDB를 다시 시작하면 데이터가 손실되거나 손상될 수 있습니다.

XtraDB는 Amazon RDS에서 MariaDB DB 인스턴스용으로 권장되고 지원되는 스토리지 엔진입니다. 그래도 Amazon RDS와 함께 Aria를 사용하도록 선택할 경우 지원되지 않는 MariaDB 스토리지 엔진에 대한 자동 백업에 개략적으로 설명되어 있는 단계를 따르면 특정한 시나리오에서 스냅샷 복원 기능에 유용할 수 있습니다.

PostgreSQL로 작업하기 위한 모범 사례

Amazon RDS에서 PostgreSQL로 성능을 향상시킬 수 있는 두 가지 중요한 영역은 DB 인스턴스로 데이터를 로드할 때와 PostgreSQL autovacuum 기능을 사용할 때입니다. 다음 섹션에서는 이런 영역에 대해 권장하는 모범 사례를 다룹니다.

PostgreSQL DB 인스턴스에 데이터 로드

Amazon RDS PostgreSQL DB 인스턴스로 데이터를 로드할 때, 데이터를 DB 인스턴스로 가장 효율적으로 가져올 수 있도록 DB 인스턴스 설정과 DB 파라미터 그룹 값을 수정해야 합니다.

DB 인스턴스 설정을 다음과 같이 수정합니다.

  • DB 인스턴스 백업 비활성화(backup_retention을 0으로 설정)

  • Multi-AZ 비활성화

다음 설정을 포함하도록 DB 파라미터 그룹을 수정합니다. 파라미터 설정을 테스트하여 DB 인스턴스에 가장 효율적인 설정을 찾아야 합니다.

  • maintenance_work_mem 파라미터의 값을 늘립니다. PostgreSQL 리소스 사용 파라미터에 대한 자세한 내용은 PostgreSQL 문서를 참조하십시오.

  • wal 로그에 대한 쓰기 수를 줄이도록 checkpoint_segmentscheckpoint_timeout 파라미터의 값을 늘립니다.

  • synchronous_commit 파라미터를 비활성화합니다(FSYNC를 해제하지는 말 것).

  • PostgreSQL autovacuum 파라미터를 비활성화합니다.

이런 설정과 함께 pg_dump -Fc(압축) 또는 pg_restore -j(병렬) 명령을 사용합니다.

fsync 및 full_page_writes 데이터베이스 파라미터 작업

Amazon RDS의 PostgreSQL 9.4.1에서는 fsync full_page_writes 데이터베이스 파라미터를 수정할 수 없습니다. fsync full_page_writes 데이터베이스 파라미터를 비활성화하면 데이터가 손상될 수 있으므로 사용자 파라미터가 자동으로 활성화되었습니다. PostgreSQL의 다른 9.3 DB 엔진 버전을 사용하는 고객은 fsync full_page_writes 파라미터를 비활성화하지 않는 것이 좋습니다.

PostgreSQL Autovacuum 기능 사용

PostgreSQL 데이터베이스용 autovacuum 기능은 PostgreSQL DB 인스턴스의 상태를 유지 관리하는 데 사용할 것을 강력히 권장하는 중요한 기능입니다. Autovacuum은 VACUUM 및 ANALYZE 명령의 실행을 자동화합니다. PostgreSQL에서는 autovacuum을 반드시 사용해야 하며 Amazon RDS에서는 필수 사항은 아니지만 훌륭한 성능을 달성하는 데 매우 중요한 기능입니다. 이 기능은 모든 새로운 Amazon RDS PostgreSQL DB 인스턴스에 대해 기본적으로 활성화되며, 관련 구성 파라미터는 적절히 기본적으로 설정됩니다.

데이터베이스 관리자는 이 유지 관리 작업을 파악하고 이해할 필요가 있습니다. Autovacuum에 관한 PostgreSQL 문서는 http://www.postgresql.org/docs/current/static/routine-vacuuming.html#AUTOVACUUM을 참조하십시오.

Autovacuum은 "리소스"를 일정 부분 사용하는 작업하지만, 백그라운드에서 작동하며 사용자 작업에 최대한 많은 리소스가 할당되도록 합니다. Autovacuum이 활성화되어 있을 때는 업데이트되거나 삭제된 튜플 수가 많은 테이블이 있는지 확인합니다. 또한, 이 기능은 트랜잭션 ID 랩어라운드로 인해 매우 오래된 데이터가 손실되지 않도록 보호합니다.

Autovacuum을 더 나은 성능을 위해 줄일 수 있는 높은 오버헤드 작업으로 생각하면 안 됩니다. 오히려, autovacuum을 실행하지 않으면 업데이트 및 삭제 속도가 빠른 테이블이 시간이 흐르면서 빠르게 성능이 저하됩니다.

중요

Autovacuum을 실행하지 않으면 훨씬 더 많은 주입식 vacuum 작업을 수행하기 위해 결국은 필연적으로 중단될 수 있습니다. Autovacuum을 지나치게 보수적으로 사용하는 바람에 Amazon RDS PostgreSQL DB 인스턴스를 사용할 수 없게 되면, PostgreSQL 데이터베이스는 스스로를 보호하기 위해 종료됩니다. 그 시점에서 Amazon RDS는 DB 인스턴스에서 직접 단일 사용자 모드 전체 vaccum을 수행해야 하며, 이때 여러 시간 동안 시스템이 중단될 수 있습니다. 따라서 기본적으로 활성화되는 autovaccum은 아예 해제하지 않는 것이 좋습니다.

Autovacuum 파라미터에 따라 autovacuum의 작동 시점과 정도가 결정됩니다. autovacuum_vacuum_thresholdautovacuum_vacuum_scale_factor 파라미터에 따라 autovacuum 실행 시점이 결정됩니다. autovacuum_max_workers, autovacuum_nap_time, autovacuum_cost_limitautovacuum_cost_delay 파라미터에 따라 autovacuum의 작동 정도가 결정됩니다. Autovacuum에 대한 자세한 정보, autovacuum의 작동 시점, 필요한 파라미터에 관해서는 PostgreSQL 문서를 참조하십시오.

다음 쿼리를 통해 table1로 명명된 테이블에 있는 "죽은" 튜플의 수를 알 수 있습니다.

Copy
PROMPT> select relname, n_dead_tup, last_vacuum, last_autovacuum from pg_catalog.pg_stat_all_tables where n_dead_tup > 0 and relname =  ’table1' order by n_dead_tup desc;

쿼리의 결과는 다음과 같은 내용일 것입니다.

Copy
relname | n_dead_tup | last_vacuum | last_autovacuum ---------+------------+-------------+----------------- tasks | 81430522 | | (1 row)

SQL Server로 작업하기 위한 모범 사례

SQL Server DB 인스턴스를 포함한 Multi-AZ 배포를 위한 모범 사례에는 다음이 포함됩니다.

  • Amazon RDS RDS DB 이벤트를 사용하여 장애 조치를 모니터링합니다. 예를 들어 DB 인스턴스가 장애 조치할 때 문자 메시지 또는 이메일로 알림 서비스를 받을 수 있습니다. Amazon RDS 이벤트에 대한 자세한 내용은 Amazon RDS 이벤트 알림 서비스 사용 단원을 참조하십시오.

  • 애플리케이션이 DNS 값을 캐시하는 경우 TTL(time to live)을 30초 미만으로 설정합니다. 장애 조치가 발생하여 IP 주소가 바뀔 수 있고 캐시된 값은 더 이상 사용하지 못할 수도 있는 경우에 TTL을 그렇게 설정하는 것이 좋습니다.

  • 다음 모드에서는 Multi-AZ에 필수적인 트랜잭션 로깅이 해제되므로, 이들 모드를 활성화하지 않는 것이 좋습니다.

    • 단순 복구 모드

    • 오프라인 모드

    • 읽기 전용 모드

  • 테스트를 통해 DB 인스턴스를 장애 조치하는 데 얼마나 오래 걸리는지 확인합니다. 장애 조치 시간은 데이터베이스의 유형, 인스턴스 클래스, 사용하는 스토리지 유형에 따라 변할 수 있습니다. 장애 조치가 발생할 경우 작업을 계속 수행할 수 있는 애플리케이션의 능력도 테스트해야 합니다.

  • 장애 조치 시간을 단축하려면 다음을 수행해야 합니다.

    • 워크로드에 대해 충분한 프로비저닝된 IOPS가 할당되어 있는지 확인하십시오. I/O가 부적합하면 장애 조치 시간이 길어질 수 있습니다. 데이터베이스 복구에 I/O가 필요합니다.

    • 더 작은 트랜잭션을 사용하십시오. 데이터베이스 복구는 트랜잭션에 의존하므로, 큰 트랜잭션을 여러 개의 작은 트랜잭션으로 나눌 수 있다면 장애 조치 시간이 단축될 것입니다.

  • 장애 조치 중에 지연 시간이 증가할 것이라는 점을 고려하십시오. 장애 조치 프로세스의 일부로서, Amazon RDS는 데이터를 새 대기 인스턴스로 자동으로 복제합니다. 이 복제는 새 데이터가 두 개의 서로 다른 DB 인스턴스로 커밋되는 중이라는 의미이므로, 대기 DB 인스턴스가 새 기본 DB 인스턴스를 따라잡을 때까지 약간의 지연 시간이 발생할 수 있습니다.

  • 모든 가용 영역에 애플리케이션을 배포합니다. 한 가용 영역이 다운되더라도 다른 가용 영역에 있는 애플리케이션을 계속 사용할 수 있습니다.

SQL Server의 Multi-AZ 배포를 사용하여 작업할 때, Amazon RDS가 인스턴스에 있는 모든 SQL Server 데이터베이스를 미러링합니다. 특정 데이터베이스가 미러링되지 않도록 하려면 해당 데이터베이스에 대해 Multi-AZ를 사용하지 않는 별개의 DB 인스턴스를 설정합니다.

DB 파라미터 그룹 작업

DB 파라미터 그룹 변경 내용을 프로덕션 DB 인스턴스에 적용하기 전에 테스트 DB 인스턴스에 적용해 보는 것이 좋습니다. DB 파라미터 그룹에 DB 엔진 파라미터를 잘못 설정하면 성능 저하나 시스템 불안정 등의 의도하지 않은 부작용이 있을 수 있습니다. DB 엔진 파라미터를 수정할 때 항상 주의를 기울이고 DB 파라미터 그룹을 수정하기 전에 DB 인스턴스를 백업하십시오. DB 인스턴스 백업에 대한 자세한 내용은 Amazon RDS DB 인스턴스 백업 및 복원 단원을 참조하십시오.

Amazon RDS 모범 사례 프레젠테이션 동영상

2016 AWS Summit 컨퍼런스(시카고)에는 Amazon RDS를 사용하여 안전하고 가용성이 높은 데이터베이스 인스턴스를 생성 및 구성하는 모범 사례에 대한 프레젠테이션이 포함되었습니다. 프레젠테이션 비디오는 여기에서 볼 수 있습니다: