適切な DB インスタンスクラスの選択

適切なインスタンスクラスは、外部テーブルクエリがメモリ、ストレージ、CPU をどのように使用するかによって異なります。これらの各リソースの詳細については、「リソース管理」を参照してください。

• メモリ: 外部テーブルクエリは、動作データ (ソート、集計、および結合用のハッシュテーブル) をメモリに保持し、aurora_analytics.query_mem 設定 (略称: query_mem) によって制限されます。query_mem のデフォルト値はインスタンスサイズに応じてスケールされるため、インスタンスが大きくなると、各クエリに割り当てられるメモリも自動的に増加します。クエリが query_mem を超えると、より低速なローカルストレージにスピルされます。詳細については、「ワークロードに合わせた query_mem の調整」を参照してください。

• 同時実行: 外部テーブルの同時クエリごとに最大 query_mem のメモリが割り当てられますが、実際の使用量はクエリによって異なり、単純なクエリの使用量ははるかに少なくなる場合があります。同時実行のサイズを設定する場合は、すべてのクエリが query_mem の上限までメモリを使用すると仮定するのではなく、ピークメモリを考慮してください。詳細については、「同時実行数のサイジング」を参照してください。

• キャッシュとスピル: Amazon S3 データのディスク上のキャッシュと、クエリがスピルした際に使用する一時ファイルは、どちらもインスタンスのローカルストレージを使用します。ローカル NVMe (db.r8gd などの d タイプのインスタンスで使用可能) は、どちらも Amazon EBS よりも高速であるため、外部テーブルをクエリする本稼働ワークロードには、ローカル NVMe ストレージを備えたクラスを選択します。

• ワークロードの分離: 外部テーブルクエリは、インスタンス内の他のトラフィックと CPU およびメモリを奪い合います。外部テーブルを頻繁にクエリするワークロードの場合は、代わりに専用のリーダーで実行します。詳細については、「分析に専用のリーダーインスタンスを使用する」を参照してください。

これらのシグナルを使用して、ワークロードに適したクラスから開始し、そこから調整します。

• AuroraAnalyticsMemoryUsage の上昇は、全体的なメモリ負荷が増加していることを意味します。より大きなインスタンスクラスにスケールアップするか、query_mem を引き下げて同時実行のための余地を確保します。

• query_mem が上昇しているということは、個々のクエリが AuroraAnalyticsDiskSpillSize の制限を超え、ローカルストレージへのスピルが発生していることを意味します。スケールアップを行うか、query_mem を引き上げて、各クエリにより多くの余裕をもたせます。

• AuroraAnalyticsCacheHitRatio の低下は、より多くの作業データが Amazon S3 から再読み込みされていることを意味します。より大きなインスタンスクラスは、より多くのデータをローカルにキャッシュします。

• 外部テーブルのクエリ中に CPU が高い場合は、クエリにより多くの vCPU が必要であることを意味します。

より多くの同時クエリを処理するには、より多くのメモリヘッドルームをスケールアップするか、リーダーを追加して負荷を分散します。

これらのメトリクスとそのモニタリング方法については、「モニタリングとトラブルシューティング」を参照してください。

EBS 専用インスタンスを使用するタイミング

ローカル NVMe ストレージを備えていないインスタンス (db.r8g や db.r8i など) では、キャッシュに Amazon EBS を使用します。これらを以下の用途に使用します。

• パフォーマンスよりもコストを重視するワークロード。

• 軽量な、あるいはアドホックな外部テーブルクエリ。

• 開発環境とテスト環境。