# Amazon RDS のベストプラクティス
Amazon RDS を使用するためのベストプラクティスについて説明します。新しいベストプラクティスが確認されると、このセクションは更新されます。
**Topics**
+ [Amazon RDS の基本的な操作のガイドライン](#CHAP_BestPractices.DiskPerformance)
+ [DB インスタンスの RAM の推奨事項](#CHAP_BestPractices.Performance.RAM)
+ [データベースエンジンのバージョンを最新の状態に保つ](#CHAP_BestPractices.Upgrades)
+ [AWS データベースドライバー](#CHAP_BestPractices.Drivers)
+ [拡張モニタリングを使用したオペレーティングシステムの問題の特定](#CHAP_BestPractices.EnhancedMonitoring)
+ [メトリクスを使用したパフォーマンスの問題の特定](#CHAP_BestPractices.UsingMetrics)
+ [クエリのチューニング](#CHAP_BestPractices.TuningQueries)
+ [MySQL の使用のベストプラクティス](#CHAP_BestPractices.MySQLStorage)
+ [MariaDB の使用のベストプラクティス](#CHAP_BestPractices.MariaDB)
+ [Oracle を使用するためのベストプラクティス](#CHAP_BestPractices.Oracle)
+ [PostgreSQL を使用するためのベストプラクティス](#CHAP_BestPractices.PostgreSQL)
+ [SQL Server を使用するためのベストプラクティス](#CHAP_BestPractices.SQLServer)
+ [DB パラメータグループを使用する](#CHAP_BestPractices.DBParameterGroup)
+ [DB インスタンスの作成を自動化するためのベストプラクティス](#CHAP_BestPractices.AutoDBCreation)
+ [Amazon RDS の新機能の動画](#CHAP_BestPractices.Presentation)
**注記**
Amazon RDS の一般的な推奨事項については、[Amazon RDS の推奨事項](monitoring-recommendations.md) を参照してください。
## Amazon RDS の基本的な操作のガイドライン
以下に示しているのは、基本的な運用についてのガイドラインであり、Amazon RDS の使用時にすべてのユーザーが従う必要があります。Amazon RDS のサービスレベルアグリーメントでは、次のガイドラインに従う必要があります。
+ メトリクスを使用して、メモリ、CPU、レプリカの遅延、およびストレージの使用状況をモニタリングします。Amazon CloudWatch は、使用パターンが変更されたり、デプロイメントの最大容量に近づいたりすると、通知するように設定できます。このようにして、システムのパフォーマンスと可用性を維持できます。
+ 最大ストレージ容量に近づいたら、DB インスタンスをスケールアップする。アプリケーションからのリクエストの予期しない増加に対応するために、ストレージとメモリにいくらかのバッファがあることが必要です。
+ 自動バックアップを有効にし、1 日のうちで書き込み IOPS が低くなる時間帯にバックアップが実行されるようにバックアップウィンドウを設定する。この場合、バックアップによるデータベース使用量は最も少なくなります。
+ データベースのワークロードでプロビジョニングした I/O がより多く必要になると、フェイルオーバーやデータベース障害後の復旧が遅くなります。DB インスタンスの I/O 処理能力を高めるには、以下のいずれかまたはすべての操作を実行します。
+ I/O 処理能力の高い別の DB インスタンスクラスに移行します。
+ 必要とする処理能力の向上に応じて、マグネティックストレージから汎用またはプロビジョンド IOPS ストレージに変換します。利用可能なストレージの種類の詳細については、「[Amazon RDS ストレージタイプ](CHAP_Storage.md#Concepts.Storage)」を参照してください。
プロビジョンド IOPS ストレージに変換する場合には、プロビジョンド IOPS に合わせて最適化された DB インスタンスクラスも使用してください。プロビジョンド IOPS の詳細については、「[プロビジョンド IOPS SSD ストレージ](CHAP_Storage.md#USER_PIOPS)」を参照してください。
+ プロビジョンド 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 インスタンスのメトリクスのモニタリングについては、「[Amazon RDS コンソールでのメトリクスの表示](USER_Monitoring.md)」を参照してください。
## データベースエンジンのバージョンを最新の状態に保つ
セキュリティ、パフォーマンス、コンプライアンスを維持するために、データベースエンジンのバージョンを定期的にアップグレードします。Amazon RDS は、セキュリティパッチ、パフォーマンスの強化、新機能を含む新しいマイナーバージョンとメジャーバージョンをリリースします。古いデータベースエンジンを実行すると、ワークロードが既知の脆弱性、互換性の問題にさらされ、AWS およびデータベースベンダーからのサポートが低下する可能性があります。
中断を最小限に抑えるには、アップグレードを計画するときに次の点を考慮してください。
+ **ステージング環境でテストする** – 本番データベースをアップグレードする前に、ワークロードに対して新しいバージョンを検証します。
+ **Amazon RDS マネージドアップグレードの使用** – マイナーバージョンの自動アップグレードを有効にすると、パッチ適用が容易になります。
+ **メジャーバージョンアップグレードのスケジュール** – リリースノートを確認し、アプリケーションの互換性をテストし、制御されたアップグレードウィンドウを計画します。
定期的なアップグレードにより、データベースの安全性、最適化、AWS ベストプラクティスとの整合性が維持されます。
## AWS データベースドライバー
アプリケーション接続には、AWS のドライバースイートを推奨します。ドライバーは、スイッチオーバーとフェイルオーバーの時間の短縮のほか、AWS Secrets Manager、AWS Identity and Access Management (IAM)、フェデレーティッド ID での認証をサポートするように設計されています。AWS ドライバーは、DB インスタンスステータスをモニタリングし、インスタンストポロジを認識して新しいライターを決定することを前提としています。このアプローチにより、スイッチオーバーとフェイルオーバーの時間が 1 桁秒に短縮されます (オープンソースドライバーの場合は数十秒)。
新しいサービス機能が導入されるにあたって、こうしたサービス機能を標準でサポートすることが AWS のドライバースイートの目標です。
詳細については、「[AWS ドライバーを使用した DB インスタンスへの接続](CHAP_CommonTasks.Connect.md#RDS.Connecting.Drivers)」を参照してください。
## 拡張モニタリングを使用したオペレーティングシステムの問題の特定
拡張モニタリングが有効になっている場合、Amazon RDS は、DB インスタンスが実行されるオペレーティングシステム (OS) のメトリクスをリアルタイムで提供します。コンソールを使用して DB インスタンスのメトリクスを表示できます。また、選択したモニタリングシステムで Amazon CloudWatch Logs からの拡張モニタリング JSON 出力を使用できます。拡張モニタリングの詳細については、[拡張モニタリングを使用した OS メトリクスのモニタリング](USER_Monitoring.OS.md) を参照してください。
## メトリクスを使用したパフォーマンスの問題の特定
リソース不足やその他の一般的なボトルネックによるパフォーマンスの問題を特定するには、Amazon RDS DB インスタンスに適用されるメトリクスを監視できます。
### パフォーマンスメトリクスの表示
さまざまな時間範囲の平均値、最大値、最小値を表示するには、パフォーマンスメトリクスを定期的に監視する必要があります。そのように監視している場合、いつパフォーマンスが低下しているかを特定できます。また、特定のメトリクスしきい値に対して Amazon CloudWatch アラームを設定することにより、しきい値に達した場合に警告されるようにすることもできます。
パフォーマンスの問題を解決するために重要なのは、システムのベースラインパフォーマンスを理解することです。DB インスタンスをセットアップして一般的なワークロードで実行する場合は、すべてのパフォーマンスメトリクスの平均値、最大値、最小値をキャプチャします。さまざまな間隔 (例えば、1 時間、24 時間、1 週間、2 週間) で行います。これにより、正常な状態を把握することができます。それにより、オペレーションのピークおよびオフピークの時間帯を比較して、得られた情報から、いつパフォーマンスが標準レベルを下回っているかを特定できます。
マルチ AZ の DB クラスターを使用している場合、ライター DB インスタンスの最新のトランザクションと、リーダー DB インスタンスで最後に適用されたトランザクションとの時間の差をモニタリングできます。この差は、*レプリカ遅延*と呼ばれます。詳細については、「[レプリカの遅延とマルチ AZ DB クラスター](multi-az-db-clusters-concepts.md#multi-az-db-clusters-concepts-replica-lag)」を参照してください。
Performance Insights と CloudWatch メトリクスの組み合わせをPerformance Insights ダッシュボードで表示し、DB インスタンスをモニタリングできます。このモニタリングビューを使用するには、DB インスタンスの Performance Insights がオンになっている必要があります。このモニタリングビューの詳細については、「[Performance Insights ダッシュボードを使用して組み合わせたメトリクスを表示する](Viewing_Unifiedmetrics.md)」を参照してください。
特定の期間のパフォーマンス分析レポートを作成して、特定されたインサイトと問題を解決するための推奨事項を確認できます。詳細については、「[Performance Insights でのパフォーマンス分析レポートの作成](USER_PerfInsights.UsingDashboard.AnalyzePerformanceTimePeriod.md)」を参照してください。
**パフォーマンスメトリクスを表示するには**
1. AWS マネジメントコンソール にサインインし、Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。
1. ナビゲーションペインで [**データベース**] を選択し、DB インスタンスを選択します。
1. [**モニタリング**] を選択します。
ダッシュボードにはパフォーマンスメトリクスが表示されます。メトリクスはデフォルトで、過去 3 時間の情報が表示されます。
1. 右上の数字のボタンを使用して別のメトリクスを表示するか、設定を調整してさらにメトリクスを表示します。
1. 現在の日付以外のデータを表示するには、パフォーマンスメトリクスを選択して時間範囲を調整します。[**Statistic**]、[**Time Range**]、[**Period**] の値を変更して、表示される情報を調整できます。例えば、過去 2 週間の各日についてメトリクスの最大値を表示したい場合があります。その場合は、**[Statistic]** (統計) を **[Maximum]** (最大) に、**[Time Range]** (時間範囲) を **[Last 2 Weeks]** (過去 2 週間)、**[Period]** (期間) を **[Day]** (日) に設定します。
CLI または API を使用しても、パフォーマンスメトリクスを表示できます。詳細については、「[Amazon RDS コンソールでのメトリクスの表示](USER_Monitoring.md)」を参照してください。
****CloudWatch アラームを設定するには****
1. AWS マネジメントコンソール にサインインし、Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。
1. ナビゲーションペインで [**データベース**] を選択し、DB インスタンスを選択します。
1. [**Logs & events**] を選択します。
1. [**CloudWatch アラーム**] セクションで [**アラームの作成**] を選択します。
![\[[アラームの作成] ダイアログボックス\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/images/CreateAlarm.png)
1. [**通知の送信**] で、[**はい**] を選択し、[**通知の送信先**]で、[**New email or SMS topic**] を選択します。
1. [**Topic name (トピック名) **] に通知用のトピックの名前を入力し、[**With these recipients (対象の受取人)**] に E メールアドレスまたは電話番号をコンマで区切って入力します。
1. [**Metric (メトリクス) **] で、セットするアラーム統計とメトリクスを選択します。
1. [**Threshold (しきい値) **] で、メトリクスがしきい値より大きい、しきい値より小さい、またはしきい値に等しいかどうかを指定し、しきい値の数値を指定します。
1. **[Evaluation period]** (期間) で、アラームの評価期間を選択します。**[consecutive period(s) of]** (度次の間隔で発生) で、アラートをトリガーするためにしきい値に達するまでの期間を選択します。
1. [**アラーム名**] に、アラームの名前を入力します。
1. [**Create Alarm**] を選択します。
[**CloudWatch alarms (CloudWatch アラーム) **] セクションで アラームが表示されます。
### パフォーマンスメトリクスの評価
DB インスタンスには多くのカテゴリのメトリクスがあり、許容値の決め方はメトリクスによって異なります。
**CPU**
+ CPU Utilization – 使用されているコンピュータの処理能力の割合。
**メモリ**
+ 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 メトリクスのモニタリング](monitoring-cloudwatch.md)」を参照してください。
一般的に、パフォーマンスメトリクスの許容値は、ベースラインがどのようになっているか、アプリケーションによって何が実行されているかによって異なります。ベースラインからの一貫した差異またはトレンドになっている差異を調べます。メトリクスのタイプごとのアドバイスは以下のとおりです。
+ **CPU または RAM の高消費量 —** CPU または RAM の消費量が大きい値になっていても、それは妥当である場合があります。例えば、アプリケーションの目標 (スループット、同時実行数など) に沿った想定値であることが前提です。
+ **ディスクスペースの消費量 – ** 使用されているディスクスペースが一貫して合計ディスクスペースの 85% 以上である場合は、ディスクスペースの消費量を調べます。インスタンスからデータを削除するか、別のシステムにデータをアーカイブして、スペースを解放できるかどうかを確認します。
+ **ネットワークトラフィック** - ネットワークトラフィックについてシステム管理者に問い合わせて、ドメインネットワークとインターネット接続に対する想定スループットを把握します。スループットが一貫して想定よりも低い場合は、ネットワークトラフィックを調べます。
+ **データベース接続数 – ** ユーザー接続数が多いことが、インスタンスのパフォーマンスが下がっていること、応答時間が長くなっていることに関連しているとわかった場合、データベース接続数を制限することを検討します。DB インスタンスの最適なユーザー接続数は、インスタンスのクラスと実行中のオペレーションの複雑さによって異なります。データベース接続数を確認するには、DB インスタンスをパラメータグループに関連付けます。このグループでは、*ユーザー接続*パラメータを 0 (無制限) 以外に設定します。既存のパラメータグループを使用するか、新しいパラメータグループを作成できます。詳細については、「[Amazon RDS のパラメータグループ](USER_WorkingWithParamGroups.md)」を参照してください。
+ **IOPS メトリクス - ** IOPS メトリクスの想定値はディスクの仕様とサーバーの設定によって異なるため、ベースラインを使用して一般的な値を把握します。値とベースラインとの差が一貫しているかどうかを調べます。最適な IOPS パフォーマンスを得るには、読み取りおよび書き込みオペレーションが最小限になるように、一般的な作業セットがメモリに収まることを確認してください。
パフォーマンスメトリクスの問題については、パフォーマンスを向上させるための第一歩は、最も使用頻度が高く、最も tune コストのかかるクエリをチューニングすることです。チューニングして、システムリソースへの負荷が軽減されるかどうかを確認してください。詳細については、「[クエリのチューニング](#CHAP_BestPractices.TuningQueries)」を参照してください。
クエリが調整されていても問題が解決しない場合は、Amazon RDS [ DB インスタンスクラス](Concepts.DBInstanceClass.md) のアップグレードを検討してください。問題に関連するリソース (CPU、RAM、ディスク容量、ネットワーク帯域幅、I/O 容量) が多いものにアップグレードすることができます。
## クエリのチューニング
DB インスタンスのパフォーマンスを向上させるには、大量のリソースを消費する使用頻度の最も高いクエリをチューニングします。ここでは、それらを調整して実行コストを下げます。クエリの改善については、次のリソースを参照してください。
+ MySQL – MySQL ドキュメントの [Optimizing SELECT statements](https://dev.mysql.com/doc/refman/8.0/en/select-optimization.html) を参照してください。クエリチューニングリソースの詳細については、[MySQL performance tuning and optimization resources](http://www.mysql.com/why-mysql/performance/) を参照してください。
+ Oracle – Oracle Database ドキュメントの [Database SQL Tuning Guide](https://docs.oracle.com/database/121/TGSQL/toc.htm) を参照してください。
+ SQL Server – Microsoft のドキュメントの [Analyzing a query](http://technet.microsoft.com/en-us/library/ms191227.aspx) を参照してください。Microsoft ドキュメントの [System Dynamic Management Views](https://docs.microsoft.com/en-us/sql/relational-databases/system-dynamic-management-views/system-dynamic-management-views) に説明されているように、実行、インデックス、I/O 関連のデータ管理ビュー (DMV) を使用して、SQL Server クエリの問題をトラブルシューティングすることもできます。
クエリのチューニングの一般的な側面は、効果的なインデックスの作成です。DB インスタンスの潜在的なインデックスの改善については、Microsoft ドキュメントの [Database Engine Tuning Advisor](https://docs.microsoft.com/en-us/sql/relational-databases/performance/database-engine-tuning-advisor) を参照してください。RDS for SQL Server での Tuning Advisor の使用については、[Database Engine Tuning Advisor を使用して Amazon RDS for SQL Server DB インスタンスのデータベースワークロードを分析する](Appendix.SQLServer.CommonDBATasks.Workload.md) を参照してください。
+ PostgreSQL – クエリプランの分析方法については、PostgreSQL ドキュメントの [Using EXPLAIN](http://www.postgresql.org/docs/current/using-explain.html) を参照してください。この情報を使用してクエリまたは基礎となるテーブルを変更することで、クエリのパフォーマンスを向上させることができます。
最適なパフォーマンスを得るためにクエリで結合を指定する方法については、[Controlling the planner with explicit JOIN clauses](http://www.postgresql.org/docs/current/explicit-joins.html) を参照してください。
+ MariaDB – MariaDB ドキュメントの [Query optimizations](https://mariadb.com/kb/en/mariadb/query-optimizations/) を参照してください。
## MySQL の使用のベストプラクティス
MySQL データベースのテーブルサイズとテーブル数の両方が、パフォーマンスに影響を与える可能性があります。
### テーブルのサイズ
通常、ファイルサイズに対するオペレーティングシステムの制約によって、MySQL データベースの有効な最大テーブルサイズが決まります。したがって、制限は通常、内部の MySQL 制約によって決定されません。
MySQL DB インスタンスでは、データベース内のテーブルが過度に大きくならないようにしてください。一般的なストレージの制限は 64 TiB ですが、プロビジョンドストレージでは、MySQL テーブルファイルの最大サイズは 16 TB に制限されています。ファイルサイズが 16 TB の制限を十分に下回るように、大きなテーブルはパーティション化します。この方法により、パフォーマンスと復旧時間も向上します。詳細については、「[Amazon RDS での MySQL のファイルサイズ制限](MySQL.KnownIssuesAndLimitations.md#MySQL.Concepts.Limits.FileSize)」を参照してください。
非常に大きなテーブル (100 GB を超える) は、読み取りと書き込み (DML ステートメント、特に DDL ステートメントを含む) の両方のパフォーマンスに悪影響を与える可能性があります。ラージテーブルのインデックスは、選択パフォーマンスを大幅に向上させることができますが、DML ステートメントのパフォーマンスを低下させる可能性があります。`ALTER TABLE` などの DDL ステートメントは、ラージテーブルでは大幅に遅くなる可能性があります。これは、これらの操作によってテーブルが完全に再構築される場合があるためです。これらの DDL ステートメントは、操作の間、テーブルをロックする場合があります。
MySQL で読み取りと書き込みに必要なメモリの量は、操作に関係するテーブルによって異なります。*アクティブに*使用されているテーブルのインデックスを保持するのに十分な RAM を少なくとも確保しておくことがベストプラクティスです。データベース内の 10 個の最も大きいテーブルとインデックスを検索するには、次のクエリを使用します。
```
select table_schema, TABLE_NAME, dat, idx from
(SELECT table_schema, TABLE_NAME,
( data_length ) / 1024 / 1024 as dat,
( index_length ) / 1024 / 1024 as idx
FROM information_schema.TABLES
order by 3 desc ) a
order by 3 desc
limit 10;
```
### テーブルの数
基になるファイルシステムでは、テーブルを表すファイル数が制限されている場合があります。ただし、MySQL にはテーブルの数に制限はありません。これにもかかわらず、MySQL InnoDB ストレージエンジンのテーブルの合計数は、これらのテーブルのサイズに関係なく、パフォーマンスの低下につながる可能性があります。オペレーティングシステムの影響を制限するために、同じ MySQL DB インスタンス内の複数のデータベース間でテーブルを分割できます。そうすると、ディレクトリ内のファイル数が制限される可能性がありますが、全体的な問題は解決されません。
多数のテーブル (1 万以上) のためにパフォーマンスの低下がある場合、それは MySQL がストレージファイルのオープンとクローズを含む作業を行うことによって引き起こされるものです。この問題に対処するには、`table_open_cache` および`table_definition_cache` パラメータのサイズを大きくします。ただし、これらのパラメータの値を大きくすると、MySQL が使用するメモリの量が大幅に増加し、使用可能なメモリがすべて使用される場合もあります。詳細については、MySQL ドキュメントの「[MySQL でのテーブルのオープンとクローズの方法](https://dev.mysql.com/doc/refman/8.0/en/table-cache.html)」を参照してください。
さらに、テーブルが多すぎると、MySQL のスタートアップ時間に大きな影響を与える可能性があります。特に MySQL 8.0 より前のバージョンでは、クリーンシャットダウンと再起動およびクラッシュ復旧の両方が影響を受ける可能性があります。
DB インスタンス内のすべてのデータベースで、テーブル数合計を 1 万未満にすることをお勧めします。MySQL データベース内で多数のテーブルを使用するユースケースについては、「[MySQL 8.0 の 100 万テーブル](https://www.percona.com/blog/2017/10/01/one-million-tables-mysql-8-0/)」を参照してください。
### ストレージエンジン
Amazon RDS for MySQL のポイントインタイム復元とスナップショット復元の機能を利用するには、クラッシュからの回復が可能なストレージエンジンが必要です。これらの機能は、InnoDB ストレージエンジンでのみサポートされます。MySQL は様々な機能を持つ複数のストレージエンジンをサポートしていますが、それらすべてがクラッシュの回復とデータ耐久性に最適化されているわけではありません。例えば、MyISAM ストレージエンジンで信頼性の高いクラッシュ回復機能がサポートされていないと、ポイントインタイム復元機能やスナップショット復元機能が意図したとおりに動作しない場合があります。その場合、MySQL がクラッシュ後に再起動されるときに、データの損失やクラッシュにつながることがあります。
InnoDB は、Amazon RDS での MySQL DB インスタンスについて推奨およびサポートされているストレージエンジンです。InnoDB のインスタンスは、Aurora に移行することも可能です。MyISAM のインスタンスは移行できません。ただし、強力な全文検索機能が必要な場合、MyISAM の方が InnoDB よりもパフォーマンスは高くなります。Amazon RDS で MyISAM を使用する場合は、「[サポートされない MySQL ストレージエンジンを使用した自動バックアップ](Overview.BackupDeviceRestrictions.md)」で説明されている手順に従ってください。スナップショット復元機能の特定のシナリオに役立つことがあります。
既存の MyISAM テーブルを InnoDB テーブルに変換する場合は、MySQL ドキュメントの「[Converting Tables from MyISAM to InnoDB](http://dev.mysql.com/doc/refman/5.0/en/converting-tables-to-innodb.html)」で説明されているプロセスを使用できます。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 table_schema, TABLE_NAME, dat, idx from
(SELECT table_schema, TABLE_NAME,
( data_length ) / 1024 / 1024 as dat,
( index_length ) / 1024 / 1024 as idx
FROM information_schema.TABLES
order by 3 desc ) a
order by 3 desc
limit 10;
```
### テーブルの数
基になるファイルシステムでは、テーブルを表すファイル数が制限されている場合があります。ただし、MariaDB にはテーブルの数に制限はありません。これにもかかわらず、MariaDB InnoDB ストレージエンジンのテーブルの合計数は、これらのテーブルのサイズに関係なく、パフォーマンスの低下に寄与する可能性があります。オペレーティングシステムの影響を制限するために、同じ MariaDB DB インスタンス内の複数のデータベース間でテーブルを分割できます。そうすると、ディレクトリ内のファイル数が制限される可能性がありますが、全体的な問題は解決されません。
多数のテーブル (1 万以上) のためにパフォーマンスの低下がある場合、それは MariaDB が作業を行うことによって引き起こされるものです。この作業には、MariaDB のストレージファイルのオープンとクローズが含まれます。この問題に対処するには、`table_open_cache` および`table_definition_cache` パラメータのサイズを大きくします。ただし、これらのパラメータの値を大きくすると、MariaDB が使用するメモリの量が大幅に増加する場合もあります。使用可能なメモリをすべて消費することもあります。詳細については、MariaDB ドキュメントの「[ table\$1open\$1cache の最適化 ](https://mariadb.com/kb/en/optimizing-table_open_cache/)」を参照してください。
さらに、テーブルが多すぎると、MariaDB のスタートアップ時間に大きな影響を与える可能性があります。クリーンシャットダウンと再起動およびクラッシュ復旧の両方が影響を受ける可能性があります。DB インスタンス内のすべてのデータベースで、テーブル数合計を 1 万未満にすることをお勧めします。
### ストレージエンジン
Amazon RDS for MariaDB のポイントインタイム復元とスナップショット復元の機能を利用するには、クラッシュからの回復が可能なストレージエンジンが必要です。MariaDB は様々な機能を持つ複数のストレージエンジンをサポートしていますが、それらすべてがクラッシュの回復とデータ耐久性に最適化されているわけではありません。例えば、Aria は耐クラッシュ性を備えていますが MyISAM の代わりに使用した場合、ポイントインタイム復元やスナップショット復元は意図したとおりに動作しないことがあります。その場合、MariaDB がクラッシュ後に再起動されるときに、データの損失やクラッシュにつながることがあります。InnoDB は、Amazon RDS での MariaDB DB インスタンスについて推奨およびサポートされているストレージエンジンです。Amazon RDS で Aria を使用する場合は、「[サポートされない MariaDB ストレージエンジンを使用した自動バックアップ](Overview.BackupDeviceRestrictionsMariaDB.md)」で説明されている手順に従ってください。スナップショット復元機能の特定のシナリオに役立つことがあります。
既存の MyISAM テーブルを InnoDB テーブルに変換する場合は、MariaDB ドキュメントの「[Converting Tables from MyISAM to InnoDB](https://mariadb.com/kb/en/converting-tables-from-myisam-to-innodb/)」で説明されているプロセスを使用できます。MyISAM と InnoDB にはそれぞれ長所と短所があるため、アプリケーションに対してこの切り替えを行う前に、影響の評価を十分に行ってください。
## Oracle を使用するためのベストプラクティス
Amazon RDS for Oracle を使用するためのベストプラクティスについては、[Amazon Web Services で Oracle データベースを実行するためのベストプラクティス](https://docs.aws.amazon.com/aws-technical-content/latest/oracle-database-aws-best-practices/introduction.html)を参照してください。
2020 年の AWS 仮想ワークショップにおいて、本稼働用 Oracle データベースの、Amazon RDS 上での実行に関するプレゼンテーションが取り上げられています。プレゼンテーションビデオは、ここから視聴できます。
[](http://www.youtube.com/watch?v=https://www.youtube.com/embed/vpSWZx4-M-M)
## PostgreSQL を使用するためのベストプラクティス
RDS for PostgreSQL のパフォーマンスを改善できる 2 つの重要な領域のうち、1 つは、DB インスタンスにデータをロードするときです。もう 1 つは、PostgreSQL autovacuum 機能を使用するときです。以下のセクションでは、これらの領域で推奨する方法のいくつかを説明します。
Amazon RDS がその他の一般的な PostgreSQL DBA タスクを実装する方法については、[Amazon RDS for PostgreSQL の一般的な DBA タスク](Appendix.PostgreSQL.CommonDBATasks.md) を参照してください。
### PostgreSQL DB インスタンスにデータをロードする
Amazon RDS PostgreSQL DB インスタンスにデータをロードする場合は、DB インスタンスの設定や DB パラメータグループの値を変更してください。これらを設定すると、DB インスタンスにデータを最も効率的にインポートできます。
DB インスタンスの設定を次のように変更します。
+ DB インスタンスのバックアップを無効にする (backup\$1retention を 0 に設定する)
+ マルチ AZ を無効にする
次の設定を含むように DB パラメータグループを変更します。また、DB インスタンスの最も効率的な設定を見つけるために、パラメータ設定をテストしてください。
+ `maintenance_work_mem` パラメータの値を大きくします。PostgreSQL のリソース消費のパラメータの詳細については、[PostgreSQL のドキュメント](http://www.postgresql.org/docs/current/runtime-config-resource.html)を参照してください。
+ ログ先行書き込み (WAL) ログへの書き込みの数を減らすには、`max_wal_size` パラメータと `checkpoint_timeout` パラメータの値を大きくします。
+ `synchronous_commit` パラメータを無効にします。
+ PostgreSQL の autovacuum パラメータを無効にします。
+ インポートするいずれのテーブルもログの記録漏れがないことを確認します。ログの記録漏れのテーブルに保存されているデータはフェイルオーバー時に失われる可能性があります。詳細については、[CREATE TABLE UNLOGGED](https://www.postgresql.org/docs/current/sql-createtable.html) を参照してください。
これらの設定で、`pg_dump -Fc` (圧縮) または `pg_restore -j` (並列) コマンドを使用します。
ロード操作が完了したら、DB インスタンスと DB パラメータを通常の設定に戻します。
### PostgreSQL Autovacuum 機能の使用
PostgreSQL データベースの autovacuum 機能は、PostgreSQL DB インスタンスの状態を維持するために使用することを強くお勧めする機能です。autovacuum は、VACUUM および ANALYZE コマンドの実行を自動化します。autovacuum の使用は、PostgreSQL が必要とするもので、Amazon RDS では必須ではありませんが、良い性能を出すためには重要な要素です。この機能は、すべての新しい Amazon RDS for PostgreSQL DB インスタンスで、デフォルトで有効になり、関連する設定パラメータがデフォルトで適切に設定されます。
データベース管理者は、このメンテナンスオペレーションを認識し、理解している必要があります。自動バキュームに関する PostgreSQL のドキュメントについては、[The Autovacuum Daemon](http://www.postgresql.org/docs/current/routine-vacuuming.html#AUTOVACUUM) を参照してください。
自動バキュームは「リソースを使用しない」オペレーションではありませんが、バックグラウンドで動作し、可能な限りユーザーオペレーションを優先します。有効にした場合、autovacuum は、大量のタプルが更新または削除されたテーブルを確認します。また、トランザクション ID の循環のために非常に古いデータが失われることを防止します。詳細については、「[Preventing Transaction ID Wraparound Failures](https://www.postgresql.org/docs/current/routine-vacuuming.html#VACUUM-FOR-WRAPAROUND)」を参照してください。
autovacuum は、パフォーマンス向上のために削減できるオーバーヘッドの大きいオペレーションと考えられるものではありません。反対に、autovacuum が実行されていない場合、更新や削除が高速なテーブルのパフォーマンスが徐々に悪化します。
**重要**
autovacuum を実行しない場合、影響がさらに大きいバキュームオペレーションを実行するために、最終的には機能停止が必要になる可能性があります。場合によっては、autovacuum を過度に控えめに使用することで、RDS for PostgreSQL DB インスタンスが利用できなくなる場合があります。このような場合、PostgreSQL データベースはそれ自体を保護するためにシャットダウンします。この時点で、Amazon RDS は直接 DB インスタンスに対してシングルユーザーモードの完全バキュームを実行する必要があります。このように完全バキュームを行うと、数時間に及ぶ停止が発生する可能性があります。* *したがって、デフォルトで有効になっている、autovacuum を無効にしないことを強くお勧めします。
autovacuum パラメータは、いつ、どのように autovacuum を実行するかを決定します。`autovacuum_vacuum_threshold` および `autovacuum_vacuum_scale_factor` パラメータは、autovacuum がいつ実行されるかを決定します。`autovacuum_max_workers`、`autovacuum_nap_time`、`autovacuum_cost_limit`、`autovacuum_cost_delay` の各パラメータは、どのように autovacuum を実行するかを決定します。自動バキューム、その実行のタイミング、および必要なパラメータの詳細については、PostgreSQL のドキュメントの [Routine Vacuuming](https://www.postgresql.org/docs/current/routine-vacuuming.html) を参照してください。
次のクエリは、table1 というテーブルの「dead」タプルの数を示します。
```
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 を使用する上での、新機能とベストプラクティスに関するプレゼンテーションが行われました。プレゼンテーションビデオは、ここから視聴できます。
[](http://www.youtube.com/watch?v=https://www.youtube.com/embed/3JLPWOoiVB8)
## SQL Server を使用するためのベストプラクティス
SQL Server DB インスタンスでのマルチ AZ 配置のベストプラクティスには、次のようなものがあります。
+ フェイルオーバーをモニタリングするために Amazon RDS DB イベントを使用します。例えば、DB インスタンスがフェイルオーバーしたときに、テキストメッセージまたはメールで通知できます。Amazon RDS イベントの詳細については、「[Amazon RDS イベント通知の操作](USER_Events.md)」を参照してください。
+ アプリケーションが 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 を使用する上での、新機能とベストプラクティスに関するプレゼンテーションが行われました。プレゼンテーションビデオは、ここから視聴できます。
[](http://www.youtube.com/watch?v=https://www.youtube.com/embed/R4Vj88iqu5s)
## DB パラメータグループを使用する
DB パラメータグループを変更した場合は、その変更をテスト DB インスタンスで試してから本稼働 DB インスタンスに適用することをお勧めします。DB パラメータグループに不適切な設定の DB エンジンパラメータがあると、パフォーマンスの低下やシステムの不安定化など、予期しない悪影響が生じることがあります。DB エンジンパラメータの変更時には常に注意が必要です。DB パラメータグループを変更する前に必ず DB インスタンスをバックアップしてください。
DB インスタンスのバックアップの詳細については、「[データのバックアップ、復元、エクスポート](CHAP_CommonTasks.BackupRestore.md)」を参照してください。
## 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 インスタンスをプログラムで作成する方法については、次のリソースを参照してください。
+ AWS CLI の使用 – [create-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html)
+ Amazon RDS API – [CreateDBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBInstance.html) の使用
+ AWS CloudFormation の使用 – [AWS::RDS::DBInstance](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-rds-dbinstance.html)
## Amazon RDS の新機能の動画
2023 AWS re:Invent カンファレンスでは、Amazon RDS の新機能に関するプレゼンテーションがありました。プレゼンテーションビデオは、ここから視聴できます。
[](http://www.youtube.com/watch?v=https://www.youtube.com/embed/IFg8EZGtLsM?si=e7T7LzW616AMd3i3)