メニュー
Amazon Relational Database Service
ユーザーガイド (API Version 2014-10-31)

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 の詳細については、「Amazon RDS Provisioned IOPS ストレージによるパフォーマンスの向上」を参照してください。

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

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

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

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

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

Amazon RDS セキュリティのベストプラクティス

AWS IAM アカウントを使用して、Amazon RDS API アクションに対するアクセスを制御します。特に、DB インスタンス、セキュリティグループ、オプショングループ、パラメータグループなどの RDS リソースを作成、変更、削除するアクションが対象になります。DB インスタンスのバックアップや復元などの一般的な管理操作を実行するアクションや、プロビジョンド IOPS ストレージを設定するアクションも対象になります。

  • RDS リソースを管理する各ユーザーにそれぞれ IAM アカウントを割り当てます。AWS ルート認証情報を使用して Amazon RDS リソースを管理しないでください。自分を含めすべてのユーザー用に IAM ユーザーを作成する必要があります。

  • それぞれの職務の実行に最低限必要になる一連のアクセス許可を各ユーザーに付与します。

  • IAM グループを使用して、複数のユーザーのアクセス許可を効果的に管理します。

  • IAM 認証情報のローテーションを定期的に行います。

IAM の詳細については、AWS Identity and Access Management をご覧ください。IAM のベストプラクティスの詳細については、「IAM のベストプラクティス」を参照してください。

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

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

拡張モニタリングは、次のデータベースエンジンに使用できます。

  • Amazon Aurora

  • MariaDB

  • Microsoft SQL Server

  • MySQL (バージョン 5.5 以降)

  • Oracle

  • PostgreSQL

拡張モニタリングは、db.t1.microdb.m1.small を除くすべての DB インスタンスクラスに使用できます。拡張モニタリングは、AWS GovCloud (US) を除くすべてのリージョンで使用できます。

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

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

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

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

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

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

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

  2. 左側のナビゲーションペインで、[Instances] を選択してから、DB インスタンスを選択します。

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

  4. 右上の数字のボタンを使用して別のメトリクスを表示するか、[Show All] を選択してすべてのメトリクスを表示します。

  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 マネジメントコンソールにサインインし、Amazon RDS コンソール (https://console.aws.amazon.com/rds/) を開きます。

  2. 左側のナビゲーションペインで、[Instances] を選択してから、DB インスタンスを選択します。

  3. [Show Monitoring] を選択してから、パフォーマンスメトリクスを選択すると、展開されたビューが表示されます。

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

  5. [Create Alarm] ページで、[Send a notification to] ボックスで値を選択することにより、アラームを受け取る E メールアドレスを指定します。必要に応じて、そのボックスの右側にある [create topic] を選択して、新しいアラーム受取人を作成します。

  6. [Whenever] リストで、設定するアラーム統計を選択します。

  7. [of] ボックスで、アラームメトリクスを選択します。

  8. [Is] ボックスとその右側のボックス (ラベルなし) で、次に示すように、アラームしきい値を設定します。

     [Create Alarm ] ダイアログボックス
  9. [For at least] ボックスで、アラームをトリガーするために、指定したしきい値に達する必要のある回数を入力します。

  10. [consecutive period(s) of] ボックスで、アラームをトリガーするために、指定したしきい値に達する必要のある期間を選択します。

  11. [Name of alarm] ボックスで、アラームの名前を入力します。

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

パフォーマンスメトリクスのページが開き、[CloudWatch Alarms] ステータスバーに新しいアラームが表示されます。ステータスバーが表示されていない場合は、ページを更新します。

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

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

CPU

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

メモリ

  • Freeable Memory - DB インスタンスで使用可能な RAM の量 (メガバイト単位)。

  • 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 RDS のディメンションとメトリクス」を参照してください。

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

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

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

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

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

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

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

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

クエリのチューニング

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

MySQL クエリのチューニング

パフォーマンス向上のためのクエリの記述の詳細については、MySQL のドキュメントの「SELECT ステートメントの最適化」を参照してください。また、クエリのチューニングのその他のリソースについては、「MySQL パフォーマンスのチューニングと最適化のリソース」を参照してください。

Oracle クエリのチューニング

パフォーマンス向上のためのクエリの記述と分析の詳細については、Oracle のドキュメントの「データベース SQL チューニングガイド」を参照してください。

SQL Server クエリのチューニング

SQL Server DB インスタンスに対するクエリを改良するには、SQL Server のドキュメントの「クエリの分析」を参照してください。「動的管理ビューおよび関数」ドキュメントに説明されているように、実行、インデックス、I/O 関連のデータ管理ビュー (DMV) を使用して、SQL Server クエリの問題をトラブルシューティングすることもできます。

クエリのチューニングの一般的な側面は、効果的なインデックスの作成です。Database Engine Tuning Advisor を使用して、DB インスタンス用にインデックスを改良できる場合があります。詳細については、「SQL Server チューニングアドバイザーを使用して Amazon RDS DB インスタンスのデータベースワークロードを分析する」を参照してください。

PostgreSQL クエリのチューニング

クエリプランの分析方法については、PostgreSQL のドキュメントの「EXPLAIN の使用」を参照してください。この情報を使用してクエリまたは基礎となるテーブルを変更することで、クエリのパフォーマンスを向上させることができます。最適なパフォーマンスを得るためにクエリで結合を指定する方法に関するヒントについては、「明示的な JOIN 句でプランナを制御する」を参照してください。

MariaDB クエリの調整

クエリ記述のパフォーマンス向上の詳細については、MariaDB のドキュメントの「クエリの最適化」を参照してください。

MySQL ストレージエンジンを使用するためのベストプラクティス

MySQL の DB インスタンスでは、テーブル作成についての次の制限事項に注意してください。

  • プロビジョンド IOPS ストレージまたは汎用ストレージを使用し、インスタンスのサイズが 200 GB 以上の場合には、10,000 テーブルに制限されます。

  • スタンダードストレージまたは汎用ストレージを使用し、インスタンスのサイズが 200 GB 未満の場合には、1,000 テーブルに制限されます。

多数のテーブルを使用すると、フェイルオーバーまたはデータベースのクラッシュ時にデータベースの復元時間が非常に増加するため、これらの制限の順守をお勧めします。推奨値よりも多くのテーブルを作成する必要がある場合は、innodb_file_per_table パラメータを 0 に設定します。詳細については、「InnoDB テーブルスペースの操作によるクラッシュ回復時間の短縮」および「DB パラメータグループを使用する」を参照してください。

MySQL の DB インスタンスでバージョン 5.7 以降の場合には、InnoDB クラッシュ復元の改良により、これらのテーブル作成の制限を超過できます。ただし、非常に多数のテーブルを作成する場合のパフォーマンスへの潜在的な影響に注意することをお勧めします。

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

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

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

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

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

MariaDB ストレージエンジンを使用するためのベストプラクティス

Amazon RDS for MariaDB の「ポイントインタイム復元」と「スナップショット復元」の機能を利用するには、クラッシュからの回復が可能なストレージエンジンが必要であり、サポートされているのは XtraDB ストレージエンジンのみです。MariaDB は様々な機能を持つ複数のストレージエンジンをサポートしていますが、それらすべてがクラッシュの回復とデータ耐久性に最適化されているわけではありません。たとえば、Aria は耐クラッシュ性を備えた MyISAM の代替と考えることができますが、ポイントインタイム復元またはスナップショットからの復元は、意図したとおりに動作しない場合があります。その場合、MariaDB がクラッシュ後に再起動されるときに、データの損失やクラッシュにつながることがあります。

XtraDB は、Amazon RDS での MariaDB DB インスタンスについて推奨およびサポートされているストレージエンジンです。Amazon RDS で Aria を使用する場合は、「サポートされない MariaDB ストレージエンジンを使用した自動バックアップ」で説明されている手順に従ってください。スナップショット復元機能の特定のシナリオに役立つことがあります。

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

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

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

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

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

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

  • マルチ AZ を無効にする

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

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

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

  • synchronous_commit パラメータを無効にします (FSYNC を無効にしないでください)。

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

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

fsync および full_page_writes データベースパラメータの使用

Amazon RDS 上の PostgreSQL 9.4.1 では、fsync および full_page_writes のデータベースパラメータを変更できません。fsync および full_page_writes のデータベースパラメータを無効にするとデータの破損につながる可能性があるため、これらは有効になっています。これ以外の 9.3 DB エンジンバージョンの PostgreSQL をご使用のお客様は、fsync および full_page_writes のパラメータを無効にしないことを推奨します。

PostgreSQL Autovacuum 機能の使用

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

データベース管理者は、このメンテナンスオペレーションを認識し、理解している必要があります。autovacuum に関する PostgreSQL のドキュメントについては、http://www.postgresql.org/docs/current/static/routine-vacuuming.html#AUTOVACUUM を参照してください。

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

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 を実行するかを決定します。autovacuum の詳細、実行する時期、必要なパラメータについては、PostgreSQL のドキュメントを参照してください。

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

Copy
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' order by n_dead_tup desc;

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

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

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 インスタンスをセットアップします。

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

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

Amazon RDS のベストプラクティスについてのプレゼンテーションビデオ

シカゴで開催された 2016 AWS Summit カンファレンスでは、Amazon RDS を使用して安全で高い可用性を持つデータベースインスタンスの作成と設定を行うためのベストプラクティスに関するプレゼンテーションが行われました。プレゼンテーションビデオは、ここから視聴できます。