Amazon Aurora を使用する際のベストプラクティス
以下に、データを Amazon Aurora DB クラスターに使用または移行するための一般的なベストプラクティスとオプションに関する情報を示します。
Amazon Aurora のベストプラクティスのいくつかは、特定のデータベースエンジンに固有です。データベースエンジンに固有の Aurora のベストプラクティスの詳細については、以下を参照してください。
データベースエンジン | ベストプラクティス |
---|---|
Amazon Aurora MySQL |
「Amazon Aurora MySQL を使用する際のベストプラクティス」を参照してください。 |
Amazon Aurora PostgreSQL |
「Amazon Aurora PostgreSQL を使用する際のベストプラクティス」を参照してください。 |
注記
Aurora の一般的な推奨事項については、Amazon Aurora の推奨事項 を参照してください。
トピック
Amazon Aurora の基本的な操作のガイドライン
以下に示しているのは、基本的な操作のガイドラインであり、Amazon Aurora の使用時にすべてのユーザーが従う必要があります。Amazon RDS のサービスレベルアグリーメント (SLA) では、以下のガイドラインに従う必要があります。
-
メモリ、CPU、ストレージの使用状況をモニタリングする。Amazon CloudWatch は、使用パターンが変更されたり、デプロイメントの最大容量に近づいたりすると、通知するように設定できます。このようにして、システムのパフォーマンスと可用性を維持できます。
-
クライアントアプリケーションが DB インスタンスのドメインネームサービス (DNS) のデータをキャッシュしている場合には、有効期限 (TTL) の値を 30 秒未満に設定します。DB インスタンスの基になる IP アドレスは、フェイルオーバー後に変更されている可能性があります。したがって、長時間キャッシュされている DNS データがあると、使用されなくなった IP アドレスにアプリケーションが接続しようとして、接続に失敗することがあります。複数のリードレプリカがある Aurora DB クラスターでは、接続でリーダーエンドポイントを使用していて、いずれかのリードレプリカインスタンスがメンテナンスや削除された場合にも、接続エラーが発生する場合があります。
-
DB クラスターのフェイルオーバーをテストすることで、そのプロセスでユースケースにかかる時間を把握します。フェイルオーバーをテストすることで、DB クラスターにアクセスするアプリケーションがフェイルオーバー後に新しい DB クラスターに自動的に接続されることを確認できます。
DB インスタンスの RAM の推奨事項
パフォーマンスを最適化するために、作業セットをほぼすべてメモリに保持できるように十分な RAM を割り当てます。作業セットがほぼすべてメモリ内にあるかどうかを確認するには、Amazon CloudWatch の以下のメトリクスを調べます。
-
VolumeReadIOPS
– クラスターボリュームからの読み取り I/O オペレーションの平均回数を測定し、5 分間隔で報告します。VolumeReadIOPS
の値は小さく、安定している必要があります。場合によっては、読み取り I/O が急に増えたり、通常よりも増えたりすることがあります。その場合は、DB クラスターの DB インスタンスを調査して、I/O 増加の原因となっている DB インスタンスを特定してください。ヒント
Aurora MySQL クラスターが並列クエリを使用している場合、
VolumeReadIOPS
値が増加することがあります。パラレルクエリでは、バッファプールは使用されません。したがって、クエリは高速ですが、この最適化された処理により、読み取り操作とそれに関連する料金が増加する可能性があります。 -
BufferCacheHitRatio
– このメトリクスは、DB クラスター内の DB インスタンスのバッファキャッシュによって処理されるリクエストの割合を測定します。このメトリクスにより、メモリから提供されているデータの量についての洞察を得られます。ヒット率が高い場合、DB インスタンスで十分なメモリが使用可能であることを示します。ヒット率が低い場合、この DB インスタンスのクエリが、頻繁にディスクに書き込まれていることを示します。ワークロードを調査して、この動作の原因となっているクエリを特定します。
ワークロードを調査した後、より多くのメモリが必要であることがわかった場合は、DB インスタンスクラスをより多くの RAM を備えたクラスにスケールアップすることを検討してください。その後、上記のメトリクスを調査し、必要に応じてスケールアップを続けることができます。Aurora クラスターが 40 TB より大きい場合は、db.t2、db.t3、または db.t4g インスタンスクラスを使用しないでください。
詳細については、「Amazon Aurora の Amazon CloudWatch メトリクス」を参照してください。
AWS データベースドライバー
アプリケーション接続には、AWS のドライバースイートを推奨します。ドライバーは、スイッチオーバーとフェイルオーバーの時間の短縮のほか、AWS Secrets Manager、AWS Identity and Access Management (IAM)、フェデレーティッド ID での認証をサポートするように設計されています。AWS ドライバーは、DB クラスターステータスをモニタリングし、クラスタートポロジを認識して新しいライターを決定することを前提としています。このアプローチにより、スイッチオーバーとフェイルオーバーの時間が 1 桁秒に短縮されます (オープンソースドライバーの場合は数十秒)。
新しいサービス機能が導入されるにあたって、こうしたサービス機能を標準でサポートすることが AWS のドライバースイートの目標です。
詳細については、「AWS ドライバーを使用した Aurora DB クラスターへの接続」を参照してください。
Amazon Aurora のモニタリング
Amazon Aurora には、さまざまなメトリクスとインサイトが用意されており、Aurora DB クラスターの状態とパフォーマンスをモニタリングして判断することができます。Aurora メトリクスは、AWS Management Console、AWS CLI、CloudWatch API などのさまざまなツールを使用して表示できます。Performance Insights と CloudWatch メトリクスの組み合わせを Performance Insights ダッシュボードで表示し、DB インスタンスをモニタリングできます。このモニタリングビューを使用するには、DB インスタンスの Performance Insights がオンになっている必要があります。このモニタリングビューの詳細については、「Performance Insights ダッシュボードを使用して組み合わせたメトリクスを表示する」を参照してください。
特定の期間のパフォーマンス分析レポートを作成して、特定されたインサイトと問題を解決するための推奨事項を確認できます。詳細については、「Performance Insights でのパフォーマンス分析レポートの作成」を参照してください。
DB パラメータグループおよび DB クラスターパラメータグループを使用する
パラメータグループの変更を本稼働 DB クラスターに適用する前に、DB パラメータグループおよび DB クラスターパラメータグループの変更を、テスト DB クラスターで試すことをお勧めします。不適切な設定の DB エンジンパラメータがあると、パフォーマンスの低下やシステムの不安定化など、予期しない悪影響が生じることがあります。
DB エンジンパラメータの変更時には常に注意が必要です。DB パラメータグループを変更する前に必ず DB クラスターをバックアップしてください。DB クラスターのバックアップの詳細については、「Amazon Aurora DB クラスターのバックアップと復元」を参照してください。
Amazon Aurora のベストプラクティスビデオ
AWS Online Tech Talks チャネルでは、セキュリティと可用性のより高い Amazon Aurora DB クラスターを作成および設定するためのベストプラクティスに関するプレゼンテーションが行われました。