# 適切な DB インスタンスクラスの選択
適切なインスタンスクラスは、外部テーブルクエリがメモリ、ストレージ、CPU をどのように使用するかによって異なります。これらの各リソースの詳細については、「[リソース管理](aurora-analytics-resource-management.md)」を参照してください。
+ **メモリ**: 外部テーブルクエリは、動作データ (ソート、集計、および結合用のハッシュテーブル) をメモリに保持し、`aurora_analytics.query_mem` 設定 (略称: `query_mem`) によって制限されます。`query_mem` のデフォルト値はインスタンスサイズに応じてスケールされるため、インスタンスが大きくなると、各クエリに割り当てられるメモリも自動的に増加します。クエリが `query_mem` を超えると、より低速なローカルストレージにスピルされます。詳細については、「[ワークロードに合わせた query\_mem の調整](aurora-analytics-tuning-query-mem.md)」を参照してください。
+ **同時実行**: 外部テーブルの同時クエリごとに最大 `query_mem` のメモリが割り当てられますが、実際の使用量はクエリによって異なり、単純なクエリの使用量ははるかに少なくなる場合があります。同時実行のサイズを設定する場合は、すべてのクエリが `query_mem` の上限までメモリを使用すると仮定するのではなく、ピークメモリを考慮してください。詳細については、「[同時実行数のサイジング](aurora-analytics-concurrency-sizing.md)」を参照してください。
+ **キャッシュとスピル**: Amazon S3 データのディスク上のキャッシュと、クエリがスピルした際に使用する一時ファイルは、どちらもインスタンスのローカルストレージを使用します。ローカル NVMe (`db.r8gd` などの d タイプのインスタンスで使用可能) は、どちらも Amazon EBS よりも高速であるため、外部テーブルをクエリする本稼働ワークロードには、ローカル NVMe ストレージを備えたクラスを選択します。
+ **ワークロードの分離**: 外部テーブルクエリは、インスタンス内の他のトラフィックと CPU およびメモリを奪い合います。外部テーブルを頻繁にクエリするワークロードの場合は、代わりに専用のリーダーで実行します。詳細については、「[分析に専用のリーダーインスタンスを使用する](aurora-analytics-dedicated-reader.md)」を参照してください。
これらのシグナルを使用して、ワークロードに適したクラスから開始し、そこから調整します。
+ `AuroraAnalyticsMemoryUsage` の上昇は、全体的なメモリ負荷が増加していることを意味します。より大きなインスタンスクラスにスケールアップするか、`query_mem` を引き下げて同時実行のための余地を確保します。
+ `query_mem` が上昇しているということは、個々のクエリが `AuroraAnalyticsDiskSpillSize` の制限を超え、ローカルストレージへのスピルが発生していることを意味します。スケールアップを行うか、`query_mem` を引き上げて、各クエリにより多くの余裕をもたせます。
+ `AuroraAnalyticsCacheHitRatio` の低下は、より多くの作業データが Amazon S3 から再読み込みされていることを意味します。より大きなインスタンスクラスは、より多くのデータをローカルにキャッシュします。
+ 外部テーブルのクエリ中に CPU が高い場合は、クエリにより多くの vCPU が必要であることを意味します。
より多くの同時クエリを処理するには、より多くのメモリヘッドルームをスケールアップするか、リーダーを追加して負荷を分散します。
これらのメトリクスとそのモニタリング方法については、「[モニタリングとトラブルシューティング](aurora-analytics-monitoring-troubleshooting.md)」を参照してください。
## EBS 専用インスタンスを使用するタイミング
ローカル NVMe ストレージを備えていないインスタンス (`db.r8g` や `db.r8i` など) では、キャッシュに Amazon EBS を使用します。これらを以下の用途に使用します。
+ パフォーマンスよりもコストを重視するワークロード。
+ 軽量な、あるいはアドホックな外部テーブルクエリ。
+ 開発環境とテスト環境。