Amazon Aurora を使用する際のベストプラクティス - Amazon Aurora

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 インスタンスクラスをより多くの RAM を備えたクラスにスケールアップすることを検討してください。その後、上記のメトリクスを調査し、必要に応じてスケールアップを続けることができます。Aurora クラスターが 40 TB より大きい場合は、db.t2 または db.t3 インスタンスクラスを使用しないでください。DB クラスターのモニタリングの詳細については、「Amazon RDS コンソールでのメトリクスの表示」を参照してください。

Amazon Aurora のモニタリング

Amazon Aurora には、さまざまな Amazon CloudWatch メトリクスが用意されており、Aurora DB クラスターの状態とパフォーマンスをモニタリングして判断することができます。Aurora メトリクスは、AWS Management Console、AWS CLI、CloudWatch API などのさまざまなツールを使用して表示できます。詳細については、「Amazon Aurora クラスターでのメトリクスのモニタリング」を参照してください。

DB パラメータグループおよび DB クラスターパラメータグループを使用する

パラメータグループの変更を本稼働 DB クラスターに適用する前に、DB パラメータグループおよび DB クラスターパラメータグループの変更を、テスト DB クラスターで試すことをお勧めします。不適切な設定の DB エンジンパラメータがあると、パフォーマンスの低下やシステムの不安定化など、予期しない悪影響が生じることがあります。

DB エンジンパラメータの変更時には常に注意が必要です。DB パラメータグループを変更する前に必ず DB クラスターをバックアップしてください。DB クラスターのバックアップの詳細については、「Amazon Aurora DB クラスターのバックアップと復元」を参照してください。

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

シカゴで開催された 2016 AWS Summit カンファレンスでは、セキュリティと可用性のより高い Amazon Aurora DB クラスターを作成および設定するためのベストプラクティスに関するプレゼンテーションが行われました。プレゼンテーションのビデオは以下のとおりです。