【AWS】RDS導入を検討してみた

この記事はブログとプログラミングで生計をたてている海外在住ウェブディベロッパーがわかりやすさにこだわって作成しました

AWSの公式ドキュメントからRDSベストプラクティスの記事を参考に資料をまとめました。間違いや漏れがあるかもしれませんがご容赦ください。

Amazon RDS のベストプラクティス - Amazon Relational Database Service
Amazon RDS を使用するためのベストプラクティスに従います。

AWSが提唱するメリット

主な導入メリットAmazon RDSのメリット詳細
管理負担を軽減使いやすい管理コンソール、ソフトウェアの自動パッチ適用など詳細 »
スケーラビリティ数回のマウスクリックまたは 1 回の API コールのみで、データベースのコンピューティング容量とストレージ容量をダウンタイムなしでスケールできます。Amazon RDS エンジンタイプの多くは、1 つ以上のリードレプリカを起動でき、プライマリデータベースインスタンスの読み取りトラフィックによる負荷を軽減できます。詳細 »
可用性と耐久性Amazon RDS は、高い信頼性を備えるアマゾン ウェブ サービスの他のサービスと同じインフラストラクチャを使用しています。マルチ AZ の DB インスタンスをプロビジョニングすると、Amazon RDS は異なるアベイラビリティーゾーン (AZ) のスタンバイインスタンスにデータを複製します。Amazon RDS は、重要な本稼働用データベースの信頼性を高めるために、自動バックアップ、データベーススナップショット、ホスト自動交換といったその他の特徴を多数備えています。詳細 »
セキュリティAmazon RDS なら、データベースへのネットワークアクセスの制御も簡単です。Amazon RDS では、データベースインスタンスを Amazon Virtual Private Cloud (Amazon VPC) で稼働させることもできます。これによってデータベースインスタンスを独立させ、業界標準の暗号化 IPsec VPN を介して既存の IT インフラストラクチャに接続することが可能になります。Amazon RDS エンジンのほとんどは、保管時の暗号化と転送時の暗号化をサポートしています。詳細 »
高速Amazon RDS では、最も要件の厳しいデータベースアプリケーションをサポートします。SSD ベースのストレージは、高性能 OLTP アプリケーション向けに最適化された SSD ストレージ、またはコスト効率の良い汎用 SSD ストレージのいずれかを選択できます。さらに、Amazon Aurora により、商用データベースと同等のパフォーマンスが 10 分の 1 のコストで提供されます。詳細 »
低コスト非常に低額の料金を、実際に利用したリソース分に対してのみ支払います。加えて、前払いや長期契約がないオンデマンド料金のオプションや、予約インスタンス料金による時間料金のさらなる割引といっ
たメリットをお客様にご提供します。
詳細 »

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

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

  1. メモリ、CPU、ストレージの使用状況をモニタリングする。使用パターンが変更されたり、デプロイの最大容量に近づいたりした際に通知を送信するように、Amazon CloudWatch を設定できます。この通知は、システムのパフォーマンスと可用性を維持するために役立ちます。
  2. 最大ストレージ容量に近づいたら、DB インスタンスをスケールアップする。アプリケーションからのリクエストの予期しない増加に対応するために、ストレージとメモリにいくらかのバッファがあることが必要です。
  3. 自動バックアップを有効にし、1 日のうちで書き込み IOPS が低くなる時間帯にバックアップが実行されるようにバックアップウィンドウを設定する。この場合、バックアップによるデータベース使用量は最も少なくなります。
  4. データベースのワークロードでプロビジョニングした I/O がより多く必要になると、フェイルオーバーやデータベース障害後の復旧が遅くなります。DB インスタンスの I/O 処理能力を高めるには、以下のいずれかまたはすべての操作を実行します。
    • I/O 処理能力の高い別の DB インスタンスクラスに移行します。
    • 必要とする処理能力の向上に応じて、マグネティックストレージから汎用またはプロビジョンド IOPS ストレージに変換します。利用可能なストレージの種類の詳細については、「Amazon RDS ストレージタイプ」を参照してください。 プロビジョンド IOPS ストレージに変換する場合には、プロビジョンド IOPS に合わせて最適化された DB インスタンスクラスも使用してください。プロビジョンド IOPS の詳細については、「プロビジョンド IOPS SSD ストレージ」を参照してください。
    • プロビジョンド IOPS ストレージをすでに使用している場合は、追加の処理能力をプロビジョニングする。
  5. クライアントアプリケーションが DB インスタンスのドメインネームサービス (DNS) のデータをキャッシュしている場合には、有効期限 (TTL) の値を 30 秒未満に設定します。DB インスタンスの基になる IP アドレスがフェイルオーバー後に変更される可能性があるため、DNS データを長時間キャッシュに格納すると、使用されなくなった IP アドレスにアプリケーションが接続を試みて、接続に失敗することがあります。
  6. DB インスタンスのフェイルオーバーをテストすることで、そのプロセスが特定のユースケースにかかる時間を把握し、DB インスタンスにアクセスするアプリケーションがフェイルオーバーの発生後に新しい DB インスタンスに自動的に接続できるようにします。

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

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

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

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

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

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

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

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

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

  1. AWS Management Console にサインインし、Amazon RDS コンソール (https://console.aws.amazon.com/rds/

) を開きます。

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

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

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

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

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

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

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

  1. AWS Management Console にサインインし、Amazon RDS コンソール (https://console.aws.amazon.com/rds/
  1. ) を開きます。
  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 インスタンスクラス」を参照) することを検討します。

PHP/Javascript/WORDPRESS案件全般承ります

オーストラリアで主に日系企業や個人のお客様からのご依頼でお仕事をしております。この記事についてのご質問またはお困りのことがございましたら、お気軽にお問い合わせください。

タイトルとURLをコピーしました