View a markdown version of this page

PERF04-BP04 액세스 패턴을 기준으로 데이터 스토리지 선택 - AWS Well-Architected Framework

PERF04-BP04 액세스 패턴을 기준으로 데이터 스토리지 선택

워크로드의 액세스 패턴과 애플리케이션의 요구 사항을 바탕으로 사용할 최적의 데이터 서비스와 기술을 결정합니다.

원하는 결과: 식별되어 문서화된 데이터 액세스 패턴을 기반으로 데이터 스토리지를 선택했습니다. 여기에는 가장 일반적인 읽기, 쓰기 및 삭제 쿼리, 필요에 따른 계산 및 집계 필요성, 데이터 복잡성, 데이터 상호 종속성 및 필수 일관성 요구 사항이 포함될 수 있습니다.

일반적인 안티 패턴:

  • 운영 관리를 간소화하기 위해 데이터베이스 엔진을 하나만 선택합니다.

  • 시간이 지나면 데이터 액세스 패턴이 일관되게 유지될 것이라고 가정합니다.

  • 애플리케이션에 복잡한 트랜잭션, 롤백 및 일관성 로직을 구현합니다.

  • 데이터베이스가 높은 트래픽 버스트를 지원하도록 구성되어 있어 데이터베이스 리소스가 대부분의 시간 동안 유휴 상태로 유지됩니다.

  • 트랜잭션 및 분석 용도로 공유 데이터베이스를 사용합니다.

이 모범 사례 수립의 이점: 액세스 패턴을 기반으로 데이터 스토리지를 선택하고 최적화하면 개발 복잡성을 줄이고 성능 기회를 최적화하는 데 도움이 됩니다. 읽기 전용 복제본, 글로벌 테이블, 데이터 파티셔닝 및 캐싱을 사용해야 하는 시기를 파악하면 워크로드 요구 사항에 따라 운영 오버헤드를 줄이고 규모를 확장할 수 있습니다.

이 모범 사례를 따르지 않을 경우 노출되는 위험의 수준: 중간

구현 가이드

데이터 액세스 패턴을 식별하고 평가하여 올바른 스토리지 구성을 선택하세요. 각 데이터베이스 솔루션에는 스토리지 솔루션을 구성하고 최적화하는 데 사용하는 옵션이 있습니다. 수집된 지표와 로그로 옵션을 실험하여 최적의 구성을 찾을 수 있습니다. 다음 테이블에서 데이터베이스 서비스별 스토리지 옵션을 검토하세요.

AWS Services Amazon RDS Amazon Aurora Amazon DynamoDB Amazon DocumentDB Amazon ElastiCache Amazon Neptune Amazon Timestream Amazon Keyspaces Amazon QLDB
Scaling Storage Storage can be scaled up manually or configured to scale automatically to a maximum of 64 TiB based on engine types. Provisioned storage cannot be decreased. Storage scales automatically up to maximum of 128 TiB and decreases when data is removed. Maximum storage size also depends upon specific Aurora MySQL or Aurora Postgres engine versions. Storage automatically scales. Tables are unconstrained in terms of size. Storage scales automatically up to maximum of 64 TiB. Starting Amazon DocumentDB 4.0 storage can decrease by comparable amounts for data removal through dropping a collection or index. With Amazon DocumentDB 3.6 allocated space remains same and free space is reused when data volume increases. Storage is in-memory, tied to instance type or count. Storage scales automatically can grow up to 128 TiB (or 64 TiB in few Regions). Upon data removal from, total allocated space remains same and is reused in the future. Organizes your time series data to optimize query processing and reduce storage costs. Retention period can be configured through in-memory and magnetic tiers. Scales table storage up and down automatically as your application writes, updates, and deletes data. Storage automatically scales. Tables are unconstrained in terms of size.

구현 단계:

  1. 트랜잭션, 원자성, 일관성, 격리, 내구성(ACID) 규정 준수 및 일관된 읽기 요구 사항을 이해합니다. 모든 데이터베이스가 이를 지원하지는 않으며, 대부분의 NoSQL 데이터베이스는 최종 정합성 모델을 제공합니다.

  2. 최적의 스토리지 솔루션을 식별하려면 글로벌 분산 애플리케이션의 트래픽 패턴, 지연 시간 및 액세스 요구 사항을 고려해야 합니다.

  3. 쿼리 패턴, 무작위 액세스 패턴 및 일회성 쿼리를 분석합니다. 텍스트 및 자연어 처리, 시계열 및 그래프에 대한 고도로 전문화된 쿼리 기능을 중심으로 한 고려 사항도 염두에 두어야 합니다.

  4. 예상되는 데이터 및 트래픽 증가를 식별하고 문서화하세요.

    1. Amazon RDS 및 Aurora에서는 문서화된 한도까지 스토리지 자동 확장을 지원합니다. 이 한도를 넘어서는 경우 데이터를 아카이브하고, 분석을 위해 과거 데이터를 집계하거나, 샤딩을 통해 수평으로 확장할 수 있도록 오래된 데이터는 Amazon S3(으)로 이전하는 것을 고려하세요.

    2. DynamoDB 및 Amazon S3에서는 거의 무제한에 가까운 스토리지 볼륨으로 자동 확장됩니다.

    3. EC2에서 실행 중인 Amazon RDS 인스턴스와 데이터베이스의 크기는 수동으로 조정할 수 있으며, EC2 인스턴스에는 나중에 새 EBS 볼륨을 추가하여 추가 스토리지로 활용할 수 있습니다. 

    4. 인스턴스 유형은 활동 변화에 따라 변경될 수 있습니다. 예를 들어, 테스트 과정에서 더 작은 인스턴스로 시작했다가 서비스에 대한 프로덕션 트래픽을 수신하기 시작할 때 인스턴스를 확장하는 것도 가능합니다. Aurora Serverless V2는 로드 변화에 따라 자동으로 확장됩니다. 

  5. 정상 성능과 최고 성능(초당 트랜잭션(TPS) 및 초당 쿼리(QPS)), 일관성(ACID 및 최종 일관성)에 대한 요구 사항 기준치를 정합니다.

  6. 솔루션 배포 측면과 데이터베이스 액세스 요구 사항(글로벌 복제본, 다중 AZ, 읽기 전용 복제본, 다중 쓰기 노드 등)을 문서화합니다.

구현 계획의 작업 수준: 낮음. 데이터 관리 솔루션에 대한 로그나 지표가 없는 경우 데이터 액세스 패턴을 식별하고 문서화하기 전에 이를 생성해야 합니다. 데이터 액세스 패턴을 파악하면 큰 어려움 없이 데이터 스토리지를 선택하고 구성할 수 있습니다.

리소스

관련 문서:

관련 동영상:

관련 예시: