PERF04-BP02 사용 가능한 옵션 평가 - AWS Well-Architected Framework
구현 가이드구현 계획의 작업 수준: 리소스

PERF04-BP02 사용 가능한 옵션 평가

데이터 관리 솔루션을 선택하기 전에 사용 가능한 데이터베이스 옵션과 데이터베이스 옵션을 통해 성능을 최적화하는 방법을 이해해야 합니다. 로드 테스트를 통해 워크로드에 중요한 데이터베이스 지표를 식별하십시오. 데이터베이스 옵션을 탐색하면서 파라미터 그룹, 스토리지 옵션, 메모리, 컴퓨팅, 읽기 전용 복제본, 최종 일관성, 연결 풀링 및 캐싱 옵션과 같은 다양한 측면을 고려해야 합니다. 지표를 개선하려면 다음과 같은 다양한 구성 옵션을 사용해 보십시오.

원하는 결과: 워크로드에서 데이터 유형에 따라 하나 이상의 데이터베이스 솔루션을 사용할 수 있습니다. 데이터베이스 기능과 이점이 데이터 특성, 액세스 패턴 및 워크로드 요구 사항과 최적으로 맞아떨어집니다. 데이터베이스 성능과 비용을 최적화하려면 데이터 액세스 패턴을 평가하여 적절한 데이터베이스 옵션을 결정해야 합니다. 허용 가능한 쿼리 시간을 평가하여 선택한 데이터베이스 옵션이 요구 사항을 충족할 수 있는지 확인합니다.

일반적인 안티 패턴:

  • 데이터 액세스 패턴을 식별하지 않습니다.

  • 선택한 데이터 관리 솔루션의 구성 옵션을 알지 못합니다.

  • 다른 사용 가능한 구성 옵션을 고려하지 않고 인스턴스 크기만 늘립니다.

  • 선택한 솔루션의 확장 특성을 테스트하지 않습니다.

이 모범 사례 수립의 이점: 데이터베이스 옵션을 탐색하고 실험하여 인프라 비용을 절감하고, 성능 및 확장성을 향상하고, 워크로드를 유지하는 데 들여야 하는 수고를 줄일 수 있습니다.

이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준: 높음

  • 불필요하게 타협하며 모든 데이터베이스에 적합하게 하나로 최적화해야 할 필요는 없습니다.

  • 트래픽 패턴과 일치하도록 데이터베이스 솔루션을 구성하지 않으면 비용이 증가합니다.

  • 확장 문제로 인해 운영 문제가 발생할 수 있습니다.

  • 데이터가 필요한 수준으로 보호되지 않을 수 있습니다.

구현 가이드

데이터베이스 옵션을 구성할 수 있도록 워크로드 데이터 특성을 파악하십시오. 로드 테스트를 실행하면 주요 성능 지표와 병목 현상을 식별할 수 있습니다. 이러한 특성과 지표를 사용하여 데이터베이스 옵션을 평가하고 다른 구성을 실험합니다.

AWS 서비스 Amazon RDS, Amazon Aurora Amazon DynamoDB Amazon DocumentDB Amazon ElastiCache Amazon Neptune Amazon Timestream Amazon Keyspaces Amazon QLDB
컴퓨팅 규모 조정 인스턴스 크기 증가, 로드 변화에 따라 Aurora 서버리스 인스턴스 자동 확장 온디맨드 용량 모드로 자동 읽기/쓰기 확장 또는 프로비저닝된 용량 모드에서 프로비저닝된 읽기/쓰기 용량 자동 확장 인스턴스 크기 증가 인스턴스 크기 증가, 클러스터에 노드 추가 인스턴스 크기 증가 용량을 조정하기 위해 자동 확장 온디맨드 용량 모드로 자동 읽기/쓰기 확장 또는 프로비저닝된 용량 모드에서 프로비저닝된 읽기/쓰기 용량 자동 확장 용량을 조정하기 위해 자동 확장
읽기 스케일 아웃 모든 엔진에서 읽기 전용 복제본 지원, Aurora에서 읽기 전용 복제본 인스턴스의 자동 확장 지원 프로비저닝된 읽기 용량 단위 증대 읽기 전용 복제본 읽기 전용 복제본 읽기 전용 복제본, 읽기 전용 복제본 인스턴스의 자동 확장 지원 자동 확장 프로비저닝된 읽기 용량 단위 증대 문서화된 동시성 제한까지 자동 스케일 업
쓰기 스케일 아웃 인스턴스 크기 증가, 애플리케이션에서 쓰기를 일괄 처리하거나 데이터베이스 앞에 대기열 추가. 여러 인스턴스에 걸쳐 애플리케이션 수준 샤딩을 통한 수평 확장 프로비저닝된 쓰기 용량 단위 증대 파티션 수준 쓰기 제한을 방지하기 위해 최적의 파티션 키 보장 기본 인스턴스 크기 증가 클러스터 모드에서 Redis를 사용하여 쓰기를 여러 샤드로 분산 인스턴스 크기 증가 크기를 조정하는 동안 쓰기 요청이 제한될 수 있음. 제한 예외가 발생하는 경우 동일하거나 더 높은 처리량(throughput)으로 데이터를 계속 전송하여 자동 크기 조정 동시 쓰기 요청을 줄이기 위한 일괄 쓰기 프로비저닝된 쓰기 용량 단위 증대 파티션 수준 쓰기 제한을 방지하기 위해 최적의 파티션 키 보장 문서화된 동시성 제한까지 자동 스케일 업
엔진 구성 파라미터 그룹 해당 사항 없음 파라미터 그룹 파라미터 그룹 파라미터 그룹 해당 사항 없음 해당 사항 없음 해당 사항 없음
캐싱 인 메모리 캐싱, 파라미터 그룹을 통해 구성 가능. ElastiCache for Redis와 같은 전용 캐시와 결합하여 일반적으로 액세스하는 항목에 대한 요청 오프로드 DAX(DAX) 완전관리형 캐시 지원 인 메모리 캐싱. 필요에 따라 ElastiCache for Redis와 같은 전용 캐시와 결합하여 일반적으로 액세스하는 항목에 대한 요청 오프로드 기본 함수가 캐싱됨 쿼리 결과 캐시를 사용하여 읽기 전용 쿼리의 결과 캐시 Timestream에는 고성능 인 메모리 계층을 포함한 2개의 스토리지 계층 존재 ElastiCache for Redis와 같은 별도의 전용 캐시를 배포하여 일반적으로 액세스하는 항목에 대한 요청 오프로드 해당 사항 없음
고가용성/재해 복구 프로덕션 워크로드에 대한 권장 구성으로 두 번째 가용 영역에서 대기 인스턴스를 실행하여 리전 내에서 복원력 제공.  리전 간 복원력의 경우 Aurora 글로벌 데이터베이스 사용 가능 리전 내에서 고가용성 제공. DynanoDB 글로벌 테이블을 사용하여 리전에 걸쳐 테이블 복제 가능 가용성을 위해 여러 가용 영역에 걸쳐 다수의 인스턴스 생성.  스냅샷은 리전 간에 공유할 수 있으며 클러스터는 DMS를 통해 복제하여 크로스 리전 복제/재해 복구 제공 프로덕션 클러스터 구성의 경우 보조 가용 영역에 노드를 하나 이상 생성할 것을 권장.  ElastiCache 글로벌 데이터 스토어를 사용하여 여러 리전에서 클러스터 복제 가능 다른 가용 영역의 읽기 전용 복제본이 장애 조치 대상 역할을 함.  스냅샷은 리전 간에 공유할 수 있으며, Neptune 스트림으로 클러스터를 복제하여 2개의 서로 다른 리전에 있는 두 클러스터 간에 데이터 복제 가능 리전 내에서 고가용성 제공. 크로스 리전 복제를 수행하려면 Timestream SDK로 사용자 지정 애플리케이션을 개발해야 함 리전 내에서 고가용성 제공.  크로스 리전 복제에는 사용자 지정 애플리케이션 로직 또는 타사 도구 필요 리전 내에서 고가용성 제공.  리전 간에 복제하려면 Amazon QLDB 분개장의 콘텐츠를 S3 버킷으로 내보내고 크로스 리전 복제를 위한 버킷을 구성

구현 단계

  1. 선택한 데이터베이스에 사용할 수 있는 구성 옵션은 무엇입니까?

    1. Amazon RDS 및 Aurora용 파라미터 그룹을 사용하면 캐시에 할당된 메모리나 데이터베이스의 시간대를 조정하는 것처럼 일반적인 데이터베이스 엔진 수준 설정을 조정할 수 있습니다.

    2. Amazon RDS, Aurora, Neptune, Amazon DocumentDB 등의 프로비저닝된 데이터베이스 서비스와 Amazon EC2에 배포된 데이터베이스 서비스의 경우 인스턴스 유형과 프로비저닝된 스토리지를 변경하고 읽기 전용 복제본을 추가할 수 있습니다.

    3. DynamoDB를 사용하면 온디맨드 및 프로비저닝이라는 두 용량 모드를 지정할 수 있습니다. 다양한 워크로드를 고려하여 언제든지 모드를 전환하고 프로비저닝 모드에서 할당된 용량을 늘릴 수 있습니다.

  2. 워크로드에 읽기 또는 쓰기 작업이 많습니까? 

    1. 읽기 오프로드(읽기 전용 복제본, 캐싱 등)에 사용할 수 있는 솔루션은 무엇입니까? 

      1. DynamoDB 테이블의 경우 캐싱을 위해 DAX를 사용하여 읽기를 오프로드할 수 있습니다.

      2. 관계형 데이터베이스의 경우 ElastiCache for Redis 클러스터를 생성하고 캐시에서 먼저 읽으며 요청한 항목이 없으면 데이터베이스로 폴백하도록 애플리케이션을 구성할 수 있습니다.

      3. Amazon RDS, Aurora 등 관계형 데이터베이스와 Neptune, Amazon DocumentDB 등 프로비저닝된 NoSQL 데이터베이스는 모두 읽기 전용 복제본을 추가하여 워크로드의 읽기 부분을 오프로드할 수 있도록 지원합니다.

      4. DynamoDB와 같은 서버리스 데이터베이스는 자동으로 크기가 조정됩니다. 워크로드를 처리하기에 충분한 읽기 용량 단위(RCU)가 프로비저닝되었는지 확인합니다.

    2. 쓰기 확장(파티션 키 샤딩, 대기열 추가 등)에 사용할 수 있는 솔루션은 무엇입니까?

      1. 관계형 데이터베이스의 경우 인스턴스 크기를 늘려 확장된 워크로드를 수용하거나 프로비저닝된 IOPS를 늘려 기본 스토리지에 대한 처리량(throughput)을 증대할 수 있습니다.

        • 데이터베이스에 직접 쓰는 대신 데이터베이스 앞에 대기열을 적용할 수도 있습니다. 이 패턴을 사용하면 데이터베이스에서 수집 정보를 분리하고 흐름 속도를 제어하여 데이터베이스가 과부하되지 않도록 할 수 있습니다. 

        • 단기간 트랜잭션을 많이 만들지 않고 쓰기 요청을 일괄 처리하면 쓰기 볼륨이 많은 관계형 데이터베이스의 처리량(throughput)을 향상시킬 수 있습니다.

      2. DynamoDB와 같은 서버리스 데이터베이스는 자동으로 쓰기 처리량(throughput)을 확장하거나 용량 모드에 따라 프로비저닝된 쓰기 용량 단위(WCU)를 조정하여 확장할 수 있습니다. 

        • 그러나 지정된 파티션 키에 대한 처리량 한계에 도달한 경우에도 핫 파티션과 관련된 문제가 발생할 수 있습니다. 이 문제는 보다 고르게 분산된 파티션 키를 선택하거나 파티션 키를 쓰기 샤딩하여 해결할 수 있습니다. 

  3. 현재 또는 예상되는 초당 최대 트랜잭션(TPS)은 얼마입니까? 이 트래픽 볼륨과 이 볼륨 +X%를 통해 테스트하여 확장 특성을 이해합니다.

    1. PostgreSQL용 pg_bench와 같은 기본 도구를 사용하여 데이터베이스를 스트레스 테스트하고 병목 현상 및 확장 특성을 이해할 수 있습니다.

    2. 프로덕션과 유사한 트래픽을 캡처하여 실제 상황뿐만 아니라 합성 워크로드를 시뮬레이션할 수 있도록 반복해야 합니다.

  4. 서버리스 또는 탄력적으로 확장 가능한 컴퓨팅을 사용하는 경우 이 확장이 데이터베이스에 미치는 영향을 테스트합니다. 필요한 경우 연결 관리 또는 풀링을 도입하여 데이터베이스에 미치는 영향을 줄이십시오. 

    1. RDS 프록시는 Amazon RDS 및 Aurora와 함께 사용하여 데이터베이스에 대한 연결을 관리할 수 있습니다. 

    2. DynamoDB와 같은 서버리스 데이터베이스에는 연계된 연결이 없으니, 프로비저닝된 용량 및 자동 확장 정책을 고려하여 로드 급증을 처리합니다.

  5. 로드를 예측할 수 있습니까? 로드가 급증하는 경우가 있거나 비활성 기간이 있습니까?

    1. 비활성 기간이 있는 경우 해당 기간에 프로비저닝된 용량 또는 인스턴스 크기를 축소하는 것이 좋습니다. Aurora Serverless V2는 로드를 기반으로 자동 스케일 업 및 스케일 다운됩니다.

    2. 비 프로덕션 인스턴스의 경우 업무 시간 외에 이러한 인스턴스를 일시 중지하거나 정지하는 것을 고려합니다.

  6. 액세스 패턴과 데이터 특성에 따라 데이터 모델을 세분화하고 분리해야 합니까?

    1. AWS DMS 또는 AWS SCT를 사용하여 데이터를 다른 서비스로 옮기는 것을 고려합니다.

구현 계획의 작업 수준: 

이 모범 사례를 적용하려면 현재 데이터 특성과 지표를 알고 있어야 합니다. 이러한 지표를 수집하고 기준선을 설정한 다음 해당 지표를 사용하여 이상적인 데이터베이스 구성 옵션을 식별하는 작업에는 낮은 수준부터 중간 수준의 노력이 필요합니다. 이는 로드 테스트 및 실험을 통해 가장 효과적으로 검증됩니다.

리소스

관련 문서:

관련 동영상:

관련 예시: