Amazon RDS のベストプラクティス - Amazon Relational Database Service

Amazon RDS のベストプラクティス

Amazon RDS を使用するためのベストプラクティスについて説明します。新しいベストプラクティスが確認されると、このセクションは更新されます。

注記

Amazon RDS の一般的な推奨事項については、Amazon RDS の推奨事項の表示 を参照してください。

Amazon RDS の基本的な操作のガイドライン

以下に示しているのは、基本的な運用についてのガイドラインであり、Amazon RDS の使用時にすべてのユーザーが従う必要があります。Amazon RDS のサービスレベルアグリーメントでは、次のガイドラインに従う必要があります。

  • メモリ、CPU、ストレージの使用状況をモニタリングする。使用パターンが変更されたり、デプロイの最大容量に近づいたりした際に通知を送信するように、Amazon CloudWatch を設定できます。この通知は、システムのパフォーマンスと可用性を維持するために役立ちます。

  • 最大ストレージ容量に近づいたら、DB インスタンスをスケールアップする。アプリケーションからのリクエストの予期しない増加に対応するために、ストレージとメモリにいくらかのバッファがあることが必要です。

  • 自動バックアップを有効にし、1 日のうちで書き込み IOPS が低くなる時間帯にバックアップが実行されるようにバックアップウィンドウを設定する。この場合、バックアップによるデータベース使用量は最も少なくなります。

  • データベースのワークロードでプロビジョニングした I/O がより多く必要になると、フェイルオーバーやデータベース障害後の復旧が遅くなります。DB インスタンスの I/O 処理能力を高めるには、以下のいずれかまたはすべての操作を実行します。

    • I/O 処理能力の高い別の DB インスタンスクラスに移行します。

    • 必要とする処理能力の向上に応じて、マグネティックストレージから汎用またはプロビジョンド IOPS ストレージに変換します。利用可能なストレージの種類の詳細については、「Amazon RDS ストレージタイプ」を参照してください。

      プロビジョンド IOPS ストレージに変換する場合には、プロビジョンド IOPS に合わせて最適化された DB インスタンスクラスも使用してください。プロビジョンド IOPS の詳細については、「プロビジョンド IOPS SSD ストレージ」を参照してください。

    • プロビジョンド IOPS ストレージをすでに使用している場合は、追加の処理能力をプロビジョニングする。

  • クライアントアプリケーションが DB インスタンスのドメインネームサービス (DNS) のデータをキャッシュしている場合には、有効期限 (TTL) の値を 30 秒未満に設定します。DB インスタンスの基になる IP アドレスがフェイルオーバー後に変更される可能性があるため、DNS データを長時間キャッシュに格納すると、使用されなくなった IP アドレスにアプリケーションが接続を試みて、接続に失敗することがあります。

  • DB インスタンスのフェイルオーバーをテストすることで、そのプロセスが特定のユースケースにかかる時間を把握し、DB インスタンスにアクセスするアプリケーションがフェイルオーバーの発生後に新しい DB インスタンスに自動的に接続できるようにします。

DB インスタンスの RAM の推奨事項

Amazon RDS のパフォーマンスのベストプラクティスは、作業セットをほぼ完全にメモリ内に保持できるように十分な RAM を割り当てることです。作業セットは、インスタンスで頻繁に使用されるデータとインデックスです。DB インスタンスを使用するほど、作業セットが増大します。

作業セットがほぼすべてメモリ内にあるかどうかを調べるには、DB インスタンスに負荷がかかっている状態で、(Amazon CloudWatchを使用して) ReadIOPS メトリクスを確認します。ReadIOPS の値は小さく、安定している必要があります。DB インスタンスクラスを、RAM の容量が大きいクラスにスケールアップして、ReadIOPS が劇的に低下する場合、作業セットのほぼすべてがメモリに存在している状態ではありません。スケーリングオペレーションを実行しても ReadIOPS が急激に低下しなくなるか、ReadIOPS が非常に小さい値になるまで、スケールアップを継続します。DB インスタンスのメトリクスのモニタリングについては、「DB インスタンスのメトリクスの表示」を参照してください。

拡張モニタリングを使用したオペレーティングシステムの問題の特定

拡張モニタリングが有効になっている場合、Amazon RDS は、DB インスタンスが実行されるオペレーティングシステム (OS) のメトリクスをリアルタイムで提供します。コンソールで DB インスタンスのメトリクスを表示したり、選択したモニタリングシステムで Amazon CloudWatch Logs からの拡張モニタリング JSON 出力を使用したりできます。拡張モニタリングの詳細については、拡張モニタリング を使用した OS のモニタリング を参照してください。

メトリクスを使用したパフォーマンスの問題の特定

リソース不足やその他の一般的なボトルネックによるパフォーマンスの問題を特定するには、Amazon RDS DB インスタンスに適用されるメトリクスを監視できます。

パフォーマンスメトリクスの表示

さまざまな時間範囲の平均値、最大値、最小値を表示するには、パフォーマンスメトリクスを定期的に監視する必要があります。そのように監視している場合、いつパフォーマンスが低下しているかを特定できます。また、特定のメトリクスしきい値に対して Amazon CloudWatch アラームを設定することにより、しきい値に達した場合に警告されるようにすることもできます。

パフォーマンスの問題を解決するために重要なのは、システムのベースラインパフォーマンスを理解することです。新しい DB インスタンスをセットアップし、一般的なワークロードで実行するときは、さまざまな間隔 (1 時間、24 時間、1 週間、2 週間など) でのすべてのパフォーマンスメトリクスの平均値、最大値、最小値を収集して、どういう状態が正常なのかを把握する必要があります。それにより、オペレーションのピークおよびオフピークの時間帯を比較して、得られた情報から、いつパフォーマンスが標準レベルを下回っているかを特定できます。

パフォーマンスメトリクスを表示するには

  1. AWS Management Console にサインインし、Amazon RDS コンソール (https://console.aws.amazon.com/rds/) を開きます。

  2. ナビゲーションペインで [データベース] を選択し、DB インスタンスを選択します。

  3. [モニタリング] を選択します。最初の 8 つのパフォーマンスメトリクスが表示されます。これらのメトリクスはデフォルトでは、現在の日付について情報を表示するように設定されています。

  4. 右上の数字のボタンを使用して別のメトリクスを表示するか、[adjust the settings (設定の調整)] を選択してすべてのメトリクスを表示します。

  5. 現在の日付以外のデータを表示するには、パフォーマンスメトリクスを選択して時間範囲を調整します。[Statistic]、[Time Range]、[Period] の値を変更して、表示される情報を調整できます。例えば、過去 2 週間の各日についてメトリクスの最大値を表示するには、[Statistic] を [Maximum] に、[Time Range] を [Last 2 Weeks] に、[Period] を [Day] に設定します。

    注記

    [Statistic]、[Time Range]、[Period] の値を変更すると、すべてのメトリクスの値が変更されます。現在のセッションが終わるまで、またはそれらの値を再び変更するまで、メトリクスの更新された値は保持されます。

CLI または API を使用しても、パフォーマンスメトリクスを表示できます。詳細については、「DB インスタンスのメトリクスの表示」を参照してください。

CloudWatch アラームを設定するには

  1. AWS Management Console にサインインし、Amazon RDS コンソール (https://console.aws.amazon.com/rds/) を開きます。

  2. ナビゲーションペインで [データベース] を選択し、DB インスタンスを選択します。

  3. [Logs & events] を選択します。

  4. [CloudWatch アラーム] セクションで [アラームの作成] を選択します。

    
                             [アラームの作成] ダイアログボックス
  5. [通知の送信] で、[はい] を選択し、[通知の送信先]で、[New email or SMS topic] を選択します。

  6. [Topic name (トピック名) ] に通知用のトピックの名前を入力し、[With these recipients (対象の受取人)] に E メールアドレスまたは電話番号をコンマで区切って入力します。

  7. [Metric (メトリクス) ] で、セットするアラーム統計とメトリクスを選択します。

  8. [Threshold (しきい値) ] で、メトリクスがしきい値より大きい、しきい値より小さい、またはしきい値に等しいかどうかを指定し、しきい値の数値を指定します。

  9. [Evaluation period (評価期間)] で、アラームに対する評価期間を選択し、[consecutive period(s) of (度次の間隔で発生)] で、アラートをトリガーするためにしきい値に達するまでの期間を選択します。

  10. [アラーム名] に、アラームの名前を入力します。

  11. [Create Alarm] を選択します。

[CloudWatch alarms (CloudWatch アラーム) ] セクションで アラームが表示されます。

パフォーマンスメトリクスの評価

DB インスタンスには多くのカテゴリのメトリクスがあり、許容値の決め方はメトリクスによって異なります。

CPU

  • CPU Utilization – 使用されているコンピューターの処理能力の割合。

Memory

  • Freeable Memory – DB インスタンスで使用可能な RAM の量 (メガバイト単位)。[モニタリング] タブのメトリクスの CPU、メモリ、ストレージメトリクスの 75% 地点に赤い線でマークされています。インスタンスメモリの消費量が頻繁にこの線を超える場合は、ワークロードの見直し、またはインスタンスのアップグレードが必要であることを表します。

  • Swap Usage – DB インスタンスによって使用されているスワップスペースの量 (メガバイト単位)。

ディスク容量

  • Free Storage Space – DB インスタンスによって現在使用されていないディスク領域の量 (メガバイト単位)。

入力/出力オペレーション

  • Read IOPS、Write IOPS – 1 秒あたりのディスク読み取りまたは書き込みオペレーションの平均数。

  • Read Latency、Write Latency – 読み取りまたは書き込みオペレーションの平均時間 (ミリ秒単位)。

  • Read Throughput、Write Throughput – 1 秒あたりのディスク読み取りまたは書き込みデータの平均量 (メガバイト単位)。

  • Queue Depth – ディスクに対する読み取りまたは書き込み待機中の I/O オペレーションの数。

ネットワークトラフィック

  • Network Receive Throughput、Network Transmit Throughput – 1 秒あたりの DB インスタンスに対する送信または受信ネットワークトラフィックのレート (バイト単位)。

データベース接続

  • DB Connections – DB インスタンスに接続されたクライアントセッションの数。

使用可能な各パフォーマンスメトリクスの詳細については、「Amazon CloudWatch を使用した Amazon RDS メトリクスのモニタリング」を参照してください。

一般的に、パフォーマンスメトリクスの許容値は、ベースラインがどのようになっているか、アプリケーションによって何が実行されているかによって異なります。ベースラインからの一貫した差異またはトレンドになっている差異を調べます。メトリクスのタイプごとのアドバイスは以下のとおりです。

  • CPU または RAM の高消費量 – CPU または RAM の消費量が大きい値になっていても、それは妥当である場合があります。ただし、アプリケーションの目標 (スループット、同時実行数など) に沿った想定値であることが前提です。

  • ディスクスペースの消費量 – 使用されているディスクスペースが一貫して合計ディスクスペースの 85% 以上である場合は、ディスクスペースの消費量を調べます。インスタンスからデータを削除するか、別のシステムにデータをアーカイブして、スペースを解放できるかどうかを確認します。

  • ネットワークトラフィック – ネットワークトラフィックについてシステム管理者に問い合わせて、ドメインネットワークとインターネット接続に対する想定スループットを把握します。スループットが一貫して想定よりも低い場合は、ネットワークトラフィックを調べます。

  • データベース接続数 – ユーザー接続数が多いことが、インスタンスのパフォーマンスが下がっていること、応答時間が長くなっていることに関連しているとわかった場合、データベース接続数を制限することを検討します。DB インスタンスの最適なユーザー接続数は、インスタンスのクラスと実行中のオペレーションの複雑さによって異なります。User Connections パラメータを 0 (無制限) 以外に設定したパラメータグループと DB インスタンスを関連付けることで、データベース接続数を決めることができます。既存のパラメータグループを使用するか、新しいパラメータグループを作成できます。詳細については、「DB パラメータグループを使用する」を参照してください。

  • IOPS メトリクス – IOPS メトリクスの想定値はディスクの仕様とサーバーの設定によって異なるため、ベースラインを使用して一般的な値を把握します。値とベースラインとの差が一貫しているかどうかを調べます。最適な IOPS パフォーマンスを得るには、読み取りおよび書き込みオペレーションが最小限になるように、一般的な作業セットがメモリに収まることを確認してください。

パフォーマンスメトリクスに問題がある場合、パフォーマンスを向上させるためにまず実行できることの 1 つは、使用頻度とコストの最も高いクエリをチューニングして、システムリソースへの負荷が下がるかどうかを確認することです。詳細については、「クエリのチューニング」を参照してください。

クエリをチューニングしても、問題が解決しない場合は、その問題に関連するリソース (CPU、RAM、ディスクスペース、ネットワーク帯域幅、I/O 容量) を増やした Amazon RDS にアップグレード (「 DB インスタンスクラス」を参照) することを検討します。

クエリのチューニング

DB インスタンスのパフォーマンスを向上させるには、大量のリソースを消費する使用頻度の最も高いクエリをチューニングして、実行コストを下げることをお勧めします。クエリの改善については、次のリソースを参照してください。

MySQL の使用のベストプラクティス

MySQL データベースのテーブルサイズとテーブル数の両方が、パフォーマンスに影響を与える可能性があります。

テーブルのサイズ

通常、ファイルサイズに対するオペレーティングシステムの制約によって、MySQL データベースの有効な最大テーブルサイズが決まります。したがって、制限は通常、内部の MySQL 制約によって決定されません。

MySQL DB インスタンスでは、データベース内のテーブルが過度に大きくならないようにしてください。一般的なストレージの制限は 64 TiB ですが、プロビジョンドストレージでは、MySQL テーブルファイルの最大サイズは 16 TB に制限されています。ファイルサイズが 16 TB の制限を十分に下回るように、大きなテーブルはパーティション化します。この方法により、パフォーマンスと復旧時間も向上します。詳細については、「Amazon RDS での MySQL のファイルサイズ制限」を参照してください。

非常に大きなテーブル (100 GB を超える) は、読み取りと書き込み (DML ステートメント、特に DDL ステートメントを含む) の両方のパフォーマンスに悪影響を与える可能性があります。ラージテーブルのインデックスは、選択パフォーマンスを大幅に向上させることができますが、DML ステートメントのパフォーマンスを低下させる可能性があります。ALTER TABLE などの DDL ステートメントは、ラージテーブルでは大幅に遅くなる可能性があります。これは、これらの操作によってテーブルが完全に再構築される場合があるためです。これらの DDL ステートメントは、操作の間、テーブルをロックする場合があります。

MySQL で読み取りと書き込みに必要なメモリの量は、操作に関係するテーブルによって異なります。アクティブに使用されているテーブルのインデックスを保持するのに十分な RAM を少なくとも確保しておくことがベストプラクティスです。データベース内の 10 個の最も大きいテーブルとインデックスを検索するには、次のクエリを使用します。

SELECT CONCAT(table_schema, '.', table_name), CONCAT(ROUND(table_rows / 1000000, 2), 'M') rows, CONCAT(ROUND(data_length / ( 1024 * 1024 * 1024 ), 2), 'G') DATA, CONCAT(ROUND(index_length / ( 1024 * 1024 * 1024 ), 2), 'G') idx, CONCAT(ROUND(( data_length + index_length ) / ( 1024 * 1024 * 1024 ), 2), 'G') total_size, ROUND(index_length / data_length, 2) idxfrac FROM information_schema.TABLES ORDER BY data_length + index_length DESC LIMIT 10;

テーブルの数

基になるファイルシステムにはテーブルを表すファイル数が制限されている場合がありますが、MySQL ではテーブルの数に制限はありません。ただし、MySQL InnoDB ストレージエンジンのテーブルの合計数は、これらのテーブルのサイズに関係なく、パフォーマンスの低下につながる可能性があります。オペレーティングシステムの影響を制限するために、同じ MySQL DB インスタンス内の複数のデータベース間でテーブルを分割できます。そうすると、ディレクトリ内のファイル数が制限される可能性がありますが、全体的な問題は解決されません。

多数のテーブル (1万以上) のためにパフォーマンスの低下がある場合、それは MySQL がストレージファイルのオープンとクローズを含む作業を行うことによって引き起こされるものです。この問題に対処するには、table_open_cache および table_definition_cache パラメータのサイズを大きくします。ただし、これらのパラメータの値を大きくすると、MySQL が使用するメモリの量が大幅に増加し、使用可能なメモリがすべて使用される場合もあります。詳細については、MySQL ドキュメントの「MySQL でのテーブルのオープンとクローズの方法」を参照してください。

さらに、テーブルが多すぎると、MySQL のスタートアップ時間に大きな影響を与える可能性があります。特に MySQL 8.0 より前のバージョンでは、クリーンシャットダウンと再起動およびクラッシュ復旧の両方が影響を受ける可能性があります。

DB インスタンス内のすべてのデータベースで、テーブル数合計を 1 万未満にすることをお勧めします。MySQL データベース内で多数のテーブルを使用するユースケースについては、「MySQL 8.0 の 100 万テーブル」を参照してください。

ストレージエンジン

Amazon RDS for MySQL の特定時点への復元およびスナップショット復元機能には、クラッシュから回復可能なストレージエンジンが必要で、InnoDB ストレージエンジンのみがサポートされています。MySQL は様々な機能を持つ複数のストレージエンジンをサポートしていますが、それらすべてがクラッシュの回復とデータ耐久性に最適化されているわけではありません。例えば、MyISAM ストレージエンジンで信頼性の高いクラッシュ回復機能がサポートされていないと、ポイントインタイム復元機能やスナップショット復元機能が意図したとおりに動作しない場合があります。その場合、MySQL がクラッシュ後に再起動されるときに、データの損失やクラッシュにつながることがあります。

InnoDB は、Amazon RDS での MySQL DB インスタンスについて推奨およびサポートされているストレージエンジンです。InnoDB のインスタンスは、Aurora に移行することも可能です。MyISAM のインスタンスは移行できません。ただし、強力な全文検索機能が必要な場合、MyISAM の方が InnoDB よりもパフォーマンスは高くなります。Amazon RDS で MyISAM を使用する場合は、「サポートされない MySQL ストレージエンジンを使用した自動バックアップ」で説明されている手順に従ってください。スナップショット復元機能の特定のシナリオに役立つことがあります。

既存の MyISAM テーブルを InnoDB テーブルに変換する場合は、MySQL のドキュメントで説明されているプロセスを使用できます。MyISAM と InnoDB にはそれぞれ長所と短所があるため、アプリケーションに対してこの切り替えを行う前に、影響の評価を十分に行ってください。

加えて、フェデレーティッドストレージエンジンは、現在 Amazon RDS for MySQL ではサポートされていません。

MariaDB の使用のベストプラクティス

MariaDB データベースのテーブルサイズとテーブル数の両方がパフォーマンスに影響を与える可能性があります。

テーブルのサイズ

通常、ファイルサイズに対するオペレーティングシステムの制約によって、MariaDB データベースの有効な最大テーブルサイズが決まります。したがって、制限は通常、内部 MariaDB 制約によって決定されません。

MariaDB DB インスタンスでは、データベース内のテーブルが過度に大きくならないようにしてください。一般的なストレージの制限は 64 TiB ですが、プロビジョニング済みストレージでは、MariaDB テーブルファイルの最大サイズは 16 TiB に制限されています。ファイルサイズが 16 TB の制限を十分に下回るように、大きなテーブルはパーティション化します。この方法により、パフォーマンスと復旧時間も向上します。

非常に大きなテーブル (100 GB を超える) は、読み取りと書き込み (DML ステートメント、特に DDL ステートメントを含む) の両方のパフォーマンスに悪影響を与える可能性があります。ラージテーブルのインデックスは、選択パフォーマンスを大幅に向上させることができますが、DML ステートメントのパフォーマンスを低下させる可能性があります。ALTER TABLE などの DDL ステートメントは、ラージテーブルでは大幅に遅くなる可能性があります。これは、これらの操作によってテーブルが完全に再構築される場合があるためです。これらの DDL ステートメントは、操作の間、テーブルをロックする場合があります。

MariaDB が読み取りと書き込みに必要なメモリの量は、操作に関係するテーブルによって異なります。アクティブに使用されているテーブルのインデックスを保持するのに十分な RAM を少なくとも確保しておくことがベストプラクティスです。データベース内の 10 個の最も大きいテーブルとインデックスを検索するには、次のクエリを使用します。

SELECT CONCAT(table_schema, '.', table_name), CONCAT(ROUND(table_rows / 1000000, 2), 'M') rows, CONCAT(ROUND(data_length / ( 1024 * 1024 * 1024 ), 2), 'G') DATA, CONCAT(ROUND(index_length / ( 1024 * 1024 * 1024 ), 2), 'G') idx, CONCAT(ROUND(( data_length + index_length ) / ( 1024 * 1024 * 1024 ), 2), 'G') total_size, ROUND(index_length / data_length, 2) idxfrac FROM information_schema.TABLES ORDER BY data_length + index_length DESC LIMIT 10;

テーブルの数

基盤となるファイルシステムは、テーブルを表すファイルの数に制限があるかもしれませんが、MariaDB にはテーブルの数に制限はありません。ただし、MariaDB InnoDB ストレージエンジンのテーブルの合計数は、これらのテーブルのサイズに関係なく、パフォーマンスの低下に寄与する可能性があります。オペレーティングシステムの影響を制限するために、同じ MariaDB DB インスタンス内の複数のデータベース間でテーブルを分割できます。そうすると、ディレクトリ内のファイル数が制限される可能性がありますが、全体的な問題は解決されません。

多数のテーブル (1万以上) のためにパフォーマンスの低下がある場合、MariaDB がストレージファイルをオープンとクローズを含む作業を行うことによって引き起こされます。この問題に対処するには、table_open_cache および table_definition_cache パラメータのサイズを大きくします。ただし、これらのパラメータの値を大きくすると、MariaDB が使用するメモリの量が大幅に増加し、使用可能なメモリがすべて使用される場合もあります。詳細については、MariaDB ドキュメントの「 table_open_cache の最適化 」を参照してください。

さらに、テーブルが多すぎると、MariaDB のスタートアップ時間に大きな影響を与える可能性があります。クリーンシャットダウンと再起動およびクラッシュ復旧の両方が影響を受ける可能性があります。DB インスタンス内のすべてのデータベースで、テーブル数合計を 1 万未満にすることをお勧めします。

ストレージエンジン

Amazon RDS for MariaDB のポイントインタイム復元とスナップショット復元の機能を利用するには、クラッシュからの回復が可能なストレージエンジンが必要です。MariaDB は様々な機能を持つ複数のストレージエンジンをサポートしていますが、それらすべてがクラッシュの回復とデータ耐久性に最適化されているわけではありません。例えば、Aria は耐クラッシュ性を備えていますが MyISAM の代わりに使用した場合、ポイントインタイム復元やスナップショット復元は意図したとおりに動作しないことがあります。その場合、MariaDB がクラッシュ後に再起動されるときに、データの損失やクラッシュにつながることがあります。InnoDB は、Amazon RDS での MariaDB DB インスタンスについて推奨およびサポートされているストレージエンジンです。Amazon RDS で Aria を使用する場合は、「サポートされない MariaDB ストレージエンジンを使用した自動バックアップ」で説明されている手順に従ってください。スナップショット復元機能の特定のシナリオに役立つことがあります。

既存の MyISAM テーブルを InnoDB テーブルに変換する場合は、MariaDB のドキュメントで説明されているプロセスを使用できます。MyISAM と InnoDB にはそれぞれ長所と短所があるため、アプリケーションに対してこの切り替えを行う前に、影響の評価を十分に行ってください。

Oracle を使用するためのベストプラクティス

Amazon RDS for Oracle を使用するためのベストプラクティスについては、Amazon Web Services で Oracle データベースを実行するためのベストプラクティスを参照してください。

2020 年の AWS 仮想ワークショップにおいて、本稼働用 Oracle データベースの、Amazon RDS 上での実行に関するプレゼンテーションが取り上げられています。プレゼンテーションビデオは、ここから視聴できます。

PostgreSQL を使用するためのベストプラクティス

Amazon RDS での PostgreSQL のパフォーマンスを改善できる 2 つの重要な領域として、DB インスタンスにデータをロードするときと、PostgreSQL の autovacuum 機能を使用するときがあります。以下のセクションでは、これらの領域で推奨する方法のいくつかを説明します。

Amazon RDS がその他の一般的な PostgreSQL DBA タスクを実装する方法については、PostgreSQL の一般的な DBA タスク を参照してください。

PostgreSQL DB インスタンスにデータをロードする

Amazon RDS PostgreSQL DB インスタンスにデータをロードする場合、DB インスタンスに最も効率的にデータをインポートできるように、DB インスタンスの設定や DB パラメータグループの値を変更する必要があります。

DB インスタンスの設定を次のように変更します。

  • DB インスタンスのバックアップを無効にする (backup_retention を 0 に設定する)

  • マルチ AZ を無効にする

次の設定を含むように DB パラメータグループを変更します。DB インスタンスの最も効率的な設定を見つけるために、パラメータ設定をテストする必要があります。

  • maintenance_work_mem パラメータの値を大きくします。PostgreSQL のリソース消費のパラメータの詳細については、PostgreSQL のドキュメントを参照してください。

  • WAL ログへの書き込みの数を減らすには、max_wal_size パラメータと checkpoint_timeout パラメータの値を大きくします。

  • synchronous_commit パラメータを無効にします。

  • PostgreSQL の autovacuum パラメータを無効にします。

  • インポートするいずれのテーブルもログの記録漏れがないことを確認します。ログの記録漏れのテーブルに保存されているデータはフェイルオーバー時に失われる可能性があります。詳細については、CREATE TABLE UNLOGGED を参照してください。

これらの設定で、pg_dump -Fc (圧縮) または pg_restore -j (並列) コマンドを使用します。

ロード操作が完了したら、DB インスタンスと DB パラメータを通常の設定に戻します。

PostgreSQL Autovacuum 機能の使用

PostgreSQL データベースの autovacuum 機能は、PostgreSQL DB インスタンスの状態を維持するために使用することを強くお勧めする機能です。autovacuum は、VACUUM および ANALYZE コマンドの実行を自動化します。autovacuum の使用は、PostgreSQL が必要とするもので、Amazon RDS では必須ではありませんが、良い性能を出すためには重要な要素です。この機能は、すべての新しい Amazon RDS PostgreSQL DB インスタンスで、デフォルトで有効になり、関連する設定パラメータがデフォルトで適切に設定されます。

データベース管理者は、このメンテナンスオペレーションを認識し、理解している必要があります。自動バキュームに関する PostgreSQL のドキュメントについては、The Autovacuum Daemon を参照してください。

自動バキュームは「リソースを使用しない」オペレーションではありませんが、バックグラウンドで動作し、可能な限りユーザーオペレーションを優先します。有効にした場合、autovacuum は、大量のタプルが更新または削除されたテーブルを確認します。また、トランザクション ID の循環のために非常に古いデータが失われることを防止します。詳細については、「Preventing Transaction ID Wraparound Failures」を参照してください。

autovacuum は、パフォーマンス向上のために削減できるオーバーヘッドの大きいオペレーションと考えられるものではありません。反対に、autovacuum が実行されていない場合、更新や削除が高速なテーブルのパフォーマンスが徐々に悪化します。

重要

autovacuum を実行しない場合、影響がさらに大きいバキュームオペレーションを実行するために、最終的には機能停止が必要になる可能性があります。autovacuum の使用が控えめすぎるために、Amazon RDS PostgreSQL DB インスタンスが利用できなくなった場合、PostgreSQL データベースは自身を保護するためにシャットダウンします。この時点で、Amazon RDS は DB インスタンスに対してシングルユーザーモードの完全バキュームを直接実行する必要があり、数時間の機能停止が発生する可能性があります。したがって、デフォルトで有効になっている、autovacuum を無効にしないことを強くお勧めします。

autovacuum パラメータは、いつ、どのように autovacuum を実行するかを決定します。autovacuum_vacuum_threshold および autovacuum_vacuum_scale_factor パラメータは、autovacuum がいつ実行されるかを決定します。autovacuum_max_workersautovacuum_nap_timeautovacuum_cost_limitautovacuum_cost_delay の各パラメータは、どのように autovacuum を実行するかを決定します。自動バキューム、その実行のタイミング、および必要なパラメータの詳細については、PostgreSQL のドキュメントの Routine Vacuuming を参照してください。

次のクエリは、table1 というテーブルの「dead」タプルの数を示します。

PROMPT> select relname, n_dead_tup, last_vacuum, last_autovacuum from pg_catalog.pg_stat_all_tables where n_dead_tup > 0 and relname = 'table1';

このクエリの結果は次のようになります。

relname | n_dead_tup | last_vacuum | last_autovacuum ---------+------------+-------------+----------------- tasks | 81430522 | | (1 row)

Amazon RDS for PostgreSQL のベストプラクティスの動画

2020 AWS re:Invent カンファレンスでは、Amazon RDS で PostgreSQL を使用する上での、新機能とベストプラクティスに関するプレゼンテーションが行われました。プレゼンテーションビデオは、ここから視聴できます。

SQL Server を使用するためのベストプラクティス

SQL Server DB インスタンスでのマルチ AZ 配置のベストプラクティスには、次のようなものがあります。

  • フェイルオーバーをモニタリングするために Amazon RDS DB イベントを使用します。例えば、DB インスタンスがフェイルオーバーしたときに、テキストメッセージまたはメールで通知できます。Amazon RDS イベントの詳細については、「Amazon RDS イベント通知の使用」を参照してください。

  • アプリケーションが DNS 値をキャッシュする場合は、有効期限 (TTL) を 30 秒未満に設定します。TTL をこのように設定することは、フェイルオーバーが発生した場合に備えるための適切な方法です。フェイルオーバーが発生すると、IP アドレスが変更される場合があり、キャッシュされた値がサービスで使用されなくなる場合があります。

  • マルチ AZ に必要なトランザクションのログ作成を無効にするため、以下モードを有効にしないことをお勧めします。

    • シンプル復旧モード

    • オフラインモード

    • 読み取り専用モード

  • DB インスタンスのフェイルオーバーにどのくらいの時間がかかるかを調べるためにテストします。フェイルオーバーの時間は、使用していたデータベース、インスタンスクラス、およびストレージタイプによって異なります。フェイルオーバーが発生した場合に、アプリケーションが機能し続けるかどうかもテストする必要があります。

  • フェイルオーバー時間を短縮するには、次の操作を行う必要があります。

    • ワークロードのために割り当てられた十分なプロビジョンド IOPS があることを確認します。不十分な I/O によってフェイルオーバー時間が長くなる可能性があります。データベースの復旧には I/O が必要です。

    • より小さいトランザクションを使用します。データベース復旧はトランザクションに依存するため、大きいトランザクションを複数の小さいトランザクションに分割できる場合、フェイルオーバー時間は短くなります。

  • フェイルオーバー中に、レイテンシーが高くなることを考慮します。フェイルオーバープロセスの一環として、Amazon RDS は新しいスタンバイ用のインスタンスに自動的にデータをレプリケートします。このレプリケーションは、新しいデータが 2 つの異なる DB インスタンスにコミットされることを意味するため、スタンバイ DB インスタンスが新しいプライマリ DB インスタンスに追いつくまでにレイテンシーが発生する場合があります。

  • アプリケーションをすべてのアベイラビリティーゾーンにデプロイします。1 つのアベイラビリティーゾーンが機能を停止しても、他のアベイラビリティーゾーンのアプリケーションは利用できます。

SQL Server のマルチ AZ 配置を使用すると、Amazon RDS はインスタンスのすべての SQL Server データベースのレプリカを作成します。特定のデータベースのセカンダリレプリカを作成しない場合は、これらのデータベースでマルチ AZ を使用しないように別の DB インスタンスをセットアップします。

Amazon RDS for SQL Server のベストプラクティスの動画

2019 AWS re:Invent カンファレンスでは、Amazon RDS で SQL Server を使用する上での、新機能とベストプラクティスに関するプレゼンテーションが行われました。プレゼンテーションビデオは、ここから視聴できます。

DB パラメータグループを使用する

DB パラメータグループを変更した場合は、その変更をテスト DB インスタンスで試してから本稼働 DB インスタンスに適用することをお勧めします。DB パラメータグループに不適切な設定の DB エンジンパラメータがあると、パフォーマンスの低下やシステムの不安定化など、予期しない悪影響が生じることがあります。DB エンジンパラメータの変更時には常に注意が必要です。DB パラメータグループを変更する前に必ず DB インスタンスをバックアップしてください。

DB インスタンスのバックアップの詳細については、「Amazon RDS DB インスタンスのバックアップと復元」を参照してください。

DB インスタンスの作成を自動化するためのベストプラクティス

Amazon RDS のベストプラクティスは、データベースエンジンの優先マイナーバージョンを使用して DB インスタンスを作成することです。AWS CLI、Amazon RDS API、または AWS CloudFormation を使用して DB インスタンスの作成を自動化できます。これらの方法を使用すると、メジャーバージョンのみを指定でき、Amazon RDS は優先マイナーバージョンを使用してインスタンスを自動的に作成します。例えば、PostgreSQL 12.5 が優先マイナーバージョンであり、create-db-instance でバージョン 12 を指定した場合、DB インスタンスのバージョンは 12.5 になります。

優先マイナーバージョンを確認するには、次の例に示すように、describe-db-engine-versions オプションを指定して --default-only コマンドを実行します。

aws rds describe-db-engine-versions --default-only --engine postgres { "DBEngineVersions": [ { "Engine": "postgres", "EngineVersion": "12.5", "DBParameterGroupFamily": "postgres12", "DBEngineDescription": "PostgreSQL", "DBEngineVersionDescription": "PostgreSQL 12.5-R1", ...some output truncated... } ] }

DB インスタンスをプログラムで作成する方法については、次のリソースを参照してください。

Amazon RDS の新機能とベストプラクティスに関するプレゼンテーション動画

2019 AWS re:Invent カンファレンスでは、Amazon RDS によりデータベースのパフォーマンスをモニタリング、分析、チューニングする上での、RDS の新しい機能とベストプラクティスに関するプレゼンテーションが行われました。プレゼンテーションビデオは、ここから視聴できます。