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. |
구현 단계:
-
트랜잭션, 원자성, 일관성, 격리, 내구성(ACID) 규정 준수 및 일관된 읽기 요구 사항을 이해합니다. 모든 데이터베이스가 이를 지원하지는 않으며, 대부분의 NoSQL 데이터베이스는 최종 정합성 모델을 제공합니다.
-
최적의 스토리지 솔루션을 식별하려면 글로벌 분산 애플리케이션의 트래픽 패턴, 지연 시간 및 액세스 요구 사항을 고려해야 합니다.
-
쿼리 패턴, 무작위 액세스 패턴 및 일회성 쿼리를 분석합니다. 텍스트 및 자연어 처리, 시계열 및 그래프에 대한 고도로 전문화된 쿼리 기능을 중심으로 한 고려 사항도 염두에 두어야 합니다.
-
예상되는 데이터 및 트래픽 증가를 식별하고 문서화하세요.
-
Amazon RDS 및 Aurora에서는 문서화된 한도까지 스토리지 자동 확장을 지원합니다. 이 한도를 넘어서는 경우 데이터를 아카이브하고, 분석을 위해 과거 데이터를 집계하거나, 샤딩을 통해 수평으로 확장할 수 있도록 오래된 데이터는 Amazon S3(으)로 이전하는 것을 고려하세요.
-
DynamoDB 및 Amazon S3에서는 거의 무제한에 가까운 스토리지 볼륨으로 자동 확장됩니다.
-
EC2에서 실행 중인 Amazon RDS 인스턴스와 데이터베이스의 크기는 수동으로 조정할 수 있으며, EC2 인스턴스에는 나중에 새 EBS 볼륨을 추가하여 추가 스토리지로 활용할 수 있습니다.
-
인스턴스 유형은 활동 변화에 따라 변경될 수 있습니다. 예를 들어, 테스트 과정에서 더 작은 인스턴스로 시작했다가 서비스에 대한 프로덕션 트래픽을 수신하기 시작할 때 인스턴스를 확장하는 것도 가능합니다. Aurora Serverless V2는 로드 변화에 따라 자동으로 확장됩니다.
-
-
정상 성능과 최고 성능(초당 트랜잭션(TPS) 및 초당 쿼리(QPS)), 일관성(ACID 및 최종 일관성)에 대한 요구 사항 기준치를 정합니다.
-
솔루션 배포 측면과 데이터베이스 액세스 요구 사항(글로벌 복제본, 다중 AZ, 읽기 전용 복제본, 다중 쓰기 노드 등)을 문서화합니다.
구현 계획의 작업 수준: 낮음. 데이터 관리 솔루션에 대한 로그나 지표가 없는 경우 데이터 액세스 패턴을 식별하고 문서화하기 전에 이를 생성해야 합니다. 데이터 액세스 패턴을 파악하면 큰 어려움 없이 데이터 스토리지를 선택하고 구성할 수 있습니다.
리소스
관련 문서:
관련 동영상:
관련 예시: