パフォーマンス

Amazon Aurora DB クラスターに、読み取りワークロードをサポートするリソースがあるかどうかを確認します。

c1qf5bt038

黄色:

データベース読み取りの増加: データベースの負荷が高く、データベースは行の書き込みや更新よりも多くの行を読み取っていました。

クエリを調整してデータベースの負荷を軽減するか、クラスター内のライター DB インスタンスと同じインスタンスクラスとサイズを持つリーダー DB インスタンスを DB クラスターに追加することをお勧めします。現在の設定では、読み取り操作が主な原因となり、データベースの負荷が継続的に高くなっている DB インスタンスが 1 つ以上あります。クラスターに別の DB インスタンスを追加し、読み取りワークロードを DB クラスターの読み取り専用エンドポイントに送信することで、これらの操作を分散します。

Aurora DB クラスターには、読み取り専用接続のためのリーダーエンドポイントが 1 つあります。このエンドポイントは、負荷分散を使用して DB クラスターでデータベースロードの最も大きな原因になっているクエリを管理します。リーダーエンドポイントは、これらのステートメントを Aurora リードレプリカに送信し、プライマリインスタンスの負荷を軽減します。リーダーエンドポイントは、クラスター内の Aurora リードレプリカの数で同時SELECTクエリを処理するように容量をスケーリングします。

詳細については、「DB クラスターに Aurora レプリカを追加する」および「Aurora DB クラスターのパフォーマンスとスケーリングの管理」を参照してください。

自動スケーリングまたはオンデマンドが Amazon DynamoDB テーブルおよびグローバルセカンダリインデックスで有効になっているかどうかを確認します。

Amazon DynamoDB Auto Scaling は Application Auto Scaling サービスを使用し、実際のトラフィックパターンに応じてプロビジョンドスループットキャパシティをユーザーに代わって動的に調節します。これにより、テーブルまたはグローバルセカンダリインデックスで、プロビジョンされた読み込みおよび書き込み容量が拡張され、トラフィックの急激な増加をスロットリングなしに処理できるようになります。ワークロードが減ると、Application Auto Scaling はスループットを低下させ、未使用のプロビジョンされた容量に料金が発生しないようにします。

AWS Config ルールのパラメータを使用してチェック設定を調整できます。

詳細については、「DynamoDB Auto Scaling によるスループットキャパシティの自動管理」を参照してください。

c18d2gz136

AWS Config マネージドルール： dynamodb-autoscaling-enabled

黄: 自動スケーリングまたはオンデマンドが DynamoDB テーブル、グローバルセカンダリインデックス、またはその両方で有効になっていません。

ワークロード要件に基づいて DynamoDB テーブルやグローバルセカンダリインデックスのプロビジョニングされたスループットを自動的にスケーリングするメカニズムがすでにある場合を除き、Amazon DynamoDB テーブルの自動スケーリングを有効にすることを検討してください。

詳細については、DynamoDB Auto Scaling での AWSマネジメントコンソールの使用」を参照してください。

DynamoDB Auto Scaling によるスループットキャパシティの自動管理

Amazon EC2インスタンスで Amazon EBS 最適化が有効になっているかどうかを確認します。

Amazon 最適化EBSインスタンスは、最適化された設定スタックを使用し、Amazon EBS I/O 用の追加の専用容量を提供します。 この最適化は、Amazon I/O とインスタンスからの他のトラフィックとの競合を最小限に抑えることで、Amazon EBS EBSボリュームの最高のパフォーマンスを提供します。

詳細については、「Amazon EBS最適化インスタンス」を参照してください。

c18d2gz142

AWS Config マネージドルール： ebs-optimized-instance

黄: Amazon EBS 最適化は、サポートされている Amazon EC2インスタンスでは有効になっていません。

サポートされているインスタンスで Amazon EBS 最適化を有効にします。

詳細については、「起動時にEBS最適化を有効にする」を参照してください。

Amazon EBS最適化インスタンス

最適化されていない Amazon EBS 最適化可能な Amazon Elastic Compute Cloud IOPS (Amazon SSD) インスタンスにアタッチされているプロビジョンド (EC2) ボリュームをチェックしますEBS。

Amazon Elastic Block Store IOPS (Amazon SSD) のプロビジョンド (EBS) ボリュームは、 EBSに最適化されたインスタンスにアタッチされている場合にのみ、期待されるパフォーマンスを実現するように設計されています。

PPkZrjsH2q

黄: 最適化できる Amazon EC2インスタンスEBSには、プロビジョンド IOPS (SSD) ボリュームがアタッチされていますが、インスタンスは EBS最適化されていません。

最適化した新しいインスタンスを作成しEBS、ボリュームをデタッチして、ボリュームを新しいインスタンスに再アタッチします。詳細については、「Amazon 最適化EBSインスタンス」および「Amazon EBSボリュームをインスタンスにアタッチする」を参照してください。

ルックバック期間中に実行されていた Amazon Elastic Block Store (Amazon EBS) ボリュームをチェックします。このチェックでは、ワークロード用にプロビジョニング不足のEBSボリュームがあると警告します。一貫した高い使用率は、パフォーマンスが最適化され安定していることを示しますが、アプリケーションに十分なリソースがない可能性も示唆しています。

COr6dfpM04

黄: ルックバック期間中にプロビジョニングが不足していたEBSボリューム。ボリュームのプロビジョニングが不足しているかどうかを判断するには、すべてのデフォルトの CloudWatch メトリクス ( IOPSおよび スループットを含む) を考慮します。プロビジョニング不足のEBSボリュームを識別するために使用されるアルゴリズムは、 AWS のベストプラクティスに従います。新しいパターンが特定されると、アルゴリズムが更新されます。

使用量の多いボリュームをアップサイジングすることを検討してください。

詳細については、「チェック AWS Compute Optimizer に Trusted Advisor オプトインする」を参照してください。

Amazon EC2 Auto Scaling グループが Amazon EC2起動テンプレートから作成されているかどうかを確認します。

起動テンプレートを使用して Amazon EC2 Auto Scaling グループを作成し、最新の Auto Scaling グループの機能と改善点へのアクセスを確保します。例えば、バージョニングや複数のインスタンスタイプなどです。

詳細については、「起動テンプレート」を参照してください。

c18d2gz102

AWS Config マネージドルール： autoscaling-launch-template

黄: Amazon EC2 Auto Scaling グループは有効な起動テンプレートに関連付けられていません。

Amazon Auto Scaling グループを作成するには、Amazon EC2 EC2起動テンプレートを使用します。

詳細については、「Auto Scaling グループの起動テンプレートを作成する」を参照してください。

アタッチされている Amazon EC2インスタンスの最大スループット機能によってパフォーマンスが影響を受ける可能性がある Amazon EBSボリュームをチェックします。

パフォーマンスを最適化するには、Amazon EC2インスタンスの最大スループットが、アタッチされたEBSボリュームの合計最大スループットよりも大きいことを確認する必要があります。このチェックでは、最適化インスタンスごとに前日の 5 分間の合計EBSボリュームスループット (協定世界時 (UTC) に基づく) EBSを計算し、それらの期間の半分以上の使用がEC2インスタンスの最大スループットの 95% を超えた場合に警告します。

Bh2xRR2FGH

黄: 前日 (UTC) に、EC2インスタンスにアタッチされたEBSボリュームの集約スループット (メガバイト/秒) が、インスタンスとEBSボリューム間の公開スループットの 95% を 50% を超える時間超えました。

Amazon EBSボリュームの最大スループット (「Amazon EBSボリュームタイプ」を参照) と、アタッチされている Amazon EC2インスタンスの最大スループットを比較します。EBS 「最適化をサポートするインスタンスタイプ」を参照してください。

最適なパフォーマンスを得るには、Amazon への高スループットをサポートするインスタンスにボリュームをアタッチEBSすることを検討してください。

Amazon EC2インスタンスの仮想化タイプが準仮想化かどうかを確認します。

可能な場合は、準仮想化インスタンスの代わりにハードウェア仮想マシン (HVM) インスタンスを使用するのがベストプラクティスです。これは、HVM仮想化の強化と の PV ドライバーの可用性によりAMIs、PV HVM とHVMゲストの間にこれまで存在していたパフォーマンスギャップが解消されたためです。現行世代のインスタンスタイプは PV をサポートしていないことに注意してくださいAMIs。したがって、HVMインスタンスタイプを選択すると、最新のハードウェアとの最高のパフォーマンスと互換性が得られます。

詳細については、「Linux AMI仮想化タイプ」を参照してください。

c18d2gz148

AWS Config マネージドルール: ec2-paravirtual-instance-check

黄: Amazon EC2インスタンスの仮想化タイプは準仮想化です。

Amazon EC2インスタンスにHVM仮想化を使用し、互換性のあるインスタンスタイプを使用します。

適切な仮想化タイプを選択する方法については、「インスタンスタイプ変更の互換性」を参照してください。

インスタンスタイプ変更の互換性

Amazon ECSタスク定義にコンテナ定義のメモリ制限が設定されているかどうかを確認します。タスク内のすべてのコンテナ用に予約されるメモリの合計量は、タスクのメモリー値より小さくする必要があります。

詳細については、「コンテナ定義」を参照してください。

c18d2gz176

AWS Config マネージドルール： ecs-task-definition-memory-hard-limit

黄: Amazon ECSメモリのハード制限が設定されていません。

Amazon ECSタスクのメモリを割り当てて、メモリ不足を回避します。コンテナが指定されたメモリを超えようとすると、コンテナは強制終了されます。

詳細については、「Amazon のタスクにメモリを割り当てるにはどうすればよいですかECS？」を参照してください。

クラスター予約

顧客の Amazon EFS ファイルシステムが現在、バーストスループットモードを使用するように設定されているかどうかを確認します。

EFSのバーストスループットモード [1] のファイルシステムは、一貫したベースラインレベルのスループット (EFS標準ストレージのデータ 1 GiB あたり 50 KiB / 秒) を提供し、「バーストクレジット」が利用可能な場合、クレジットモデルを使用してより高いレベルの「バーストスループット」パフォーマンスを提供します。バーストクレジットを使い果たすと、ファイルシステムのパフォーマンスがこの低いベースラインレベルに抑えられ、その結果、速度が低下したり、タイムアウトになったり、エンドユーザーやアプリケーションのパフォーマンスに影響を与えたりする可能性があります。

c1dfprch02

ユーザーとアプリケーションが希望するスループットを達成できるように、ファイルシステム設定をエラスティックスループットモード [2] に更新することをお勧めします。Elastic Throughput モードの場合、ファイルシステムは、AWSリージョン [3] に応じて最大 10 GiB / 秒の読み取りスループットまたは 3 GiB / 秒の書き込みスループットを達成でき、使用したスループットに対してのみ料金が発生します。ファイルシステムの設定を更新して、必要に応じてエラスティックスループットモードとバーストスループットモードを切り替えることができることと、エラスティックスループットモードのファイルシステムではデータ転送に追加料金が発生することに注意してください [4]。

DB インスタンスの自動バキュームパラメータは無効になっています。自動バキュームを無効にすると、テーブルとインデックスが肥大化し、パフォーマンスに影響します。

DB パラメータグループの自動バキュームを有効にすることをお勧めします。

c1qf5bt025

黄色: DB パラメータグループの自動バキュームは無効になっています。

DB パラメータグループの自動バキュームパラメータを有効にしてください。

PostgreSQL データベースには、バキュームと呼ばれる定期的なメンテナンスが必要です。PostgreSQL の Autovacuum は、 VACCUUMおよび ANALYZE コマンドの実行を自動化します。このプロセスはテーブル統計を収集し、デッド行を削除します。自動バキュームを無効にすると、テーブルの増加、インデックスの肥大化、古い統計がデータベースのパフォーマンスに影響します。

詳細については、「Amazon RDS for Postgre 環境での autovacuum についてSQL」を参照してください。

DB クラスターは最大 64 TiB のボリュームをサポートします。最新のエンジンバージョンは、最大 128 TiB のボリュームをサポートします。DB クラスターのエンジンバージョンを最新バージョンにアップグレードして、最大 128 TiB のボリュームをサポートすることをお勧めします。

c1qf5bt017

黄色: DB クラスターは最大 64 TiB のボリュームのみをサポートします。

DB クラスターのエンジンバージョンをアップグレードして、最大 128 TiB のボリュームをサポートするようにします。

単一の Amazon Aurora DB クラスターでアプリケーションをスケールアップする場合、ストレージ制限が 128 TiB の場合は制限に達しない可能性があります。ストレージ制限を増やすことで、データを削除したり、データベースを複数のインスタンスに分割したりするのを防ぐことができます。

詳細については、「Amazon Aurora size limits」を参照してください。

DB クラスター内のすべてのインスタンスに同じ DB インスタンスクラスとサイズを使用することをお勧めします。

c1qf5bt009

赤: DB クラスターには、異なるインスタンスクラスの DB インスタンスがあります。

DB クラスター内のすべての DB インスタンスに同じインスタンスクラスを使用します。

DB クラスター内の DB インスタンスが異なる DB インスタンスクラスまたはサイズを使用している場合、DB インスタンスのワークロードに不均衡が生じる可能性があります。フェイルオーバー中、リーダー DB インスタンスのいずれかがライター DB インスタンスに変わります。DB インスタンスが同じ DB インスタンスクラスとサイズを使用する場合は、DB クラスターの DB インスタンスでワークロードを分散できます。

詳細については、「Aurora レプリカ」を参照してください。

DB クラスター内のすべてのインスタンスに同じ DB インスタンスクラスとサイズを使用することをお勧めします。

c1qf5bt008

赤: DB クラスターには、さまざまなインスタンスサイズの DB インスタンスがあります。

DB クラスター内のすべての DB インスタンスに同じインスタンスクラスを使用します。

DB クラスター内の DB インスタンスが異なる DB インスタンスクラスまたはサイズを使用している場合、DB インスタンスのワークロードに不均衡が生じる可能性があります。フェイルオーバー中、リーダー DB インスタンスのいずれかがライター DB インスタンスに変わります。DB インスタンスが同じ DB インスタンスクラスとサイズを使用する場合は、DB クラスターの DB インスタンスでワークロードを分散できます。

詳細については、「Aurora レプリカ」を参照してください。

DB インスタンスのメモリパラメータがデフォルト値と大きく異なります。これらの設定はパフォーマンスに影響が及び、エラーの原因となる可能性があります。

DB インスタンスのカスタムメモリパラメータを、DB パラメータグループのデフォルト値に再設定することをお勧めします。

c1qf5bt020

黄色: DB パラメータグループには、デフォルト値とはかなり異なるメモリパラメータがあります。

メモリパラメータをデフォルト値にリセットします。

詳細については、「Amazon for My のパラメータを設定するためのベストプラクティスSQL、パート 1: パフォーマンスに関連するパラメータRDS」を参照してください。

クエリプランナーまたはオプティマイザーは、インデックスのみのスキャン計画タイプが無効になっている場合は使用できません。

enable_indexonlyscan パラメータの値を 1 に設定することをお勧めします。

c1qf5bt028

黄色: DB パラメータグループの enable_indexonlyscan パラメータは無効になっています。

enable_indexonlyscan パラメーターを 1 に設定します。

enable_indexonlyscan パラメーターを無効にすると、クエリプランナーは最適な実行プランを選択できなくなります。クエリプランナーは、インデックススキャンなどの別のプランタイプを使用するため、クエリのコストと実行時間が長くなる可能性があります。インデックスのみのスキャンプランタイプでは、テーブルデータにアクセスせずにデータを取得します。

詳細については、PostgreSQL ドキュメントウェブサイトの enable_indexonlyscan (ブール値） を参照してください。

クエリプランナーまたはオプティマイザーは、インデックスのみのスキャン計画タイプが無効になっている場合は使用できません。

enable_indexscan パラメータの値を １ に設定することをお勧めします。

c1qf5bt029

黄色: DB パラメータグループの enable_indexscan パラメータは無効になっています。

パラメータ enable_indexscan を 1 に設定します。

enable_indexscan パラメーターを無効にすると、クエリプランナーは最適な実行プランを選択できなくなります。クエリプランナーは、インデックススキャンなどの別のプランタイプを使用するため、クエリのコストと実行時間が長くなる可能性があります。

詳細については、PostgreSQL ドキュメントウェブサイトの enable_indexscan (ブール値） を参照してください。

DB インスタンスの一般ログ記録が有効になっています。この設定は、データベースの問題のトラブルシューティングに役立ちます。しかし、一般ログ記録を有効にすると、入出力操作の量と割り当てられるストレージ容量が増え、競合やパフォーマンスの低下につながる可能性があります。

一般ログ記録の使用状況の要件を確認してください。general_logging パラメーターの値を 0 に設定することをお勧めします。

c1qf5bt037

黄色: DB パラメータグループでは general_logging が有効になっています。

一般ログ記録の使用状況の要件を確認してください。必須ではない場合は、general_logging パラメーターの値を 0 に設定することをお勧めします。

general_logging パラメーター値が 1 の場合、一般クエリーログが有効になります。一般クエリログには、データベースサーバー操作の記録が含まれます。クライアントが接続または切断し、クライアントから受信した各SQLステートメントがログに含まれると、サーバーはこのログに情報を書き込みます。一般クエリログは、クライアントでエラーが発生した疑いがあり、クライアントがデータベースサーバーに送信した情報を検索したい場合に役立ちます。

詳細については、「データベースログの の概要RDSSQL」を参照してください。

変更バッファリングにより、My DB SQLインスタンスはセカンダリインデックスを維持するために必要ないくつかの書き込みを延期できます。この機能は、低速ディスクを使用する環境で有効でした。バッファリング設定を変更することで DB のパフォーマンスはわずかに向上しましたが、クラッシュリカバリの遅延やアップグレード中のシャットダウン時間の増加の原因となりました。

innodb_change_buffering パラメータの値を に設定することをお勧めしますNONE。

c1qf5bt021

黄色: DB パラメータグループの innodb_change_buffering パラメータは最適値が低く設定されています。

NONE DB パラメータグループの innodb_change_buffering パラメータ値を に設定します。

詳細については、「Amazon for My のパラメータを設定するためのベストプラクティスSQL、パート 1: パフォーマンスに関連するパラメータRDS」を参照してください。

innodb_open_files パラメータは、InnoDB が一度に開くことができるファイル数を制御します。InnoDB は、mysqld の実行時にすべてのログファイルとシステムテーブルスペースファイルを開きます。

お使いの DB インスタンスは、InnoDB が一度に開くことができる最大ファイル数の値が低くなっています。innodb_open_files パラメータ値を少なくとも 65 に設定することをお勧めします。

c1qf5bt033

黄色: DB パラメータグループの InnoDB オープンファイル設定に誤りがあります。

innodb_open_files パラメータ値を少なくとも 65 に設定します。

innodb_open_files パラメータは、InnoDB が一度に開くことができるファイル数を制御します。InnoDB は、mysqld の実行中、すべてのログファイルとシステムテーブルスペースファイルを開いたままにします。 file-per-table ストレージモデルを使用する場合は、InnoDB でいくつかの .ibd ファイルを開く必要もあります。innodb_open_files の設定が低いと、データベースのパフォーマンスに影響し、サーバーが起動しなくなる可能性があります。

詳細については、 MySql ドキュメントウェブサイトのInnoDB 起動オプション」および「システム変数 - innodb_open_files」を参照してください。

DB インスタンスは、InnoDB 統計をディスクに保持するように設定されていません。統計が保存されていない場合は、インスタンスが再起動してテーブルにアクセスするたびに再計算されます。これにより、クエリ実行プランにばらつきが生じます。このグローバルパラメータの値はテーブルレベルで変更できます。

innodb_stats_persistent パラメーター値を ON１ に設定することをお勧めします。

c1qf5bt032

黄色: DB パラメータグループには、ディスクに保持されないオプティマイザ統計があります。

innodb_stats_persistent パラメータ値を ON に設定します。

innodb_stats_persistent パラメーターが ON に設定されている場合、オプティマイザ統計はインスタンスの再起動時に保持されます。これにより、実行プランの安定性と一貫したクエリパフォーマンスが向上します。テーブルを作成または変更するときに STATS_PERSISTENT 句を使用して、テーブルレベルでグローバル統計の永続性を変更できます。

詳細については、「Amazon for My のパラメータを設定するためのベストプラクティスSQL、パート 1: パフォーマンスに関連するパラメータRDS」を参照してください。

Amazon RDSインスタンスまたは Amazon Aurora DB インスタンスの運用に必要なシステム容量があるかどうかを確認します。

c1qf5bt039

黄色:

Out-of-memory 強制終了: OS レベルでメモリが減少してデータベースホスト上のプロセスが停止すると、メモリ不足 (OOM) の強制終了カウンターが増加します。

過剰な数のスワップ: os.memory.swap.in および os.memory.swap.out のメトリクス値が高い場合。

メモリの使用量を減らすか、メモリの割り当て量の多い DB インスタンスタイプを使用するようにクエリを調整することをお勧めします。インスタンスのメモリが不足すると、データベースのパフォーマンスに影響を及ぼします。

O ut-of-memory キルが検出されました: Linux カーネルは、ホストで実行されているプロセスがオペレーティングシステムから物理的に利用可能なメモリよりも多くのメモリを必要とする場合に、メモリ不足 (OOM) キラーを呼び出します。この場合、OOMKiller は実行中のすべてのプロセスを確認し、システムメモリを解放してシステムを実行し続けるために 1 つ以上のプロセスを停止します。

スワップが検出されている: データベースホストのメモリが不足している場合、オペレーティングシステムはスワップスペース内のディスクに最も使用されていないページをいくつか送信します。このオフロードプロセスは、データベースのパフォーマンスに影響を及ぼします。

詳細については、「Amazon RDS インスタンスタイプ」および「インスタンスのスケーリング」を参照してください yourAmazon RDS。

DB インスタンスはマグネティックストレージを使用しています。ほとんどの DB インスタンスには、マグネティックストレージは推奨されません。汎用 (SSD) またはプロビジョンド の別のストレージタイプを選択しますIOPS。

c1qf5bt000

黄: Amazon RDSリソースはマグネティックストレージを使用しています。

汎用 (SSD) またはプロビジョンド の別のストレージタイプを選択しますIOPS。

マグネティックストレージは旧世代のストレージタイプです。新しいストレージ要件には、汎用 (SSD) またはプロビジョニング済み が推奨されるストレージタイプIOPSです。これらのストレージタイプは、より高い一貫したパフォーマンスを実現し、ストレージサイズの選択肢も広がります。

詳細については、「旧世代ボリューム」を参照してください。

Large pages はデータベースのスケーラビリティを高めることができますが、DB インスタンスは Large pages を使用していません。DB インスタンスの DB パラメータグループONLYで use_large_pages パラメータ値を に設定することをお勧めします。

c1qf5bt024

黄色: DB パラメータグループでは Large pages は使用されません。

DB パラメータグループの use_large_pages パラメータ値を ONLY に設定します。

詳細については、「 for Oracle インスタンス HugePages の を有効にするRDS」を参照してください。

変更によってクエリキャッシュの削除が必要になった場合、DB インスタンスは停止しているように見えます。通常ワークロードでは、クエリキャッシュのメリットは得られません。クエリキャッシュが MySQL バージョン 8.0 から削除されました。query_cache_type パラメータを 0 に設定することをお勧めします。

c1qf5bt022

黄色: DB パラメータグループではクエリキャッシュが有効になっています。

DB パラメータグループの query_cache_type パラメータ値を 0 に設定します。

詳細については、「Amazon for My のパラメータを設定するためのベストプラクティスSQL、パート 1: パフォーマンスに関連するパラメータRDS」を参照してください。

データベースは、旧世代の DB インスタンスクラスを実行しています。旧世代の DB インスタンスクラスは、コスト、パフォーマンス、またはその両方が向上した DB インスタンスクラスに置き換えられました。DB インスタンスには、新しい世代の DB インスタンスクラスを使用して実行することをお勧めします。

c1qf5bt015

赤: DB インスタンスはサポート終了の DB インスタンスクラスを使用しています。

最大インスタンスクラスにアップグレードします。

詳細については、「DB インスタンスクラスでサポートされている DB エンジン」を参照してください。

DB エンジンの、現行メジャーバージョンのデータベースはサポートされません。新しい機能や拡張機能を含む最新のメジャーバージョンにアップグレードすることをお勧めします。

c1qf5bt014

赤: RDSリソースはサポート終了メジャーバージョンを使用しています。

DB エンジンを最新のメジャーバージョンにアップグレードします。

Amazon は、サポートされているデータベースエンジンの新しいバージョンをRDSリリースして、データベースを最新バージョンに維持します。新しいバージョンには、データベースエンジンのバグ修正、セキュリティの強化、およびその他の改善が含まれる場合があります。ブルー/グリーンデプロイを使用することで、DB インスタンスのアップグレードに必要なダウンタイムを最小限に抑えることができます。

詳細については、以下のリソースを参照してください。

現在のライセンスサポートをRDS続行するには、メジャーバージョンを Amazon でサポートされている最新のエンジンバージョンにアップグレードすることをお勧めします。データベースのエンジンバージョンは、現在のライセンスではサポートされません。

c1qf5bt016

赤: Amazon RDSリソースは、ライセンス込みモデルでサポート終了エンジンエディションを使用しています。

ライセンスモデルを引き続き使用するには、データベースを Amazon RDS でサポートされている最新バージョンにアップグレードすることをお勧めします。

詳細については、[Oracle のメジャーバージョンのアップグレード]を参照してください。

パフォーマンスを向上させ、コストを節約するために、エイリアスリソースレコードセットに変更できるリソースレコードセットをチェックします。

エイリアスリソースレコードセットは、DNSクエリを AWS リソース (Elastic Load Balancing ロードバランサーや Amazon S3 バケットなど) または別の Route 53 リソースレコードセットにルーティングします。エイリアスリソースレコードセットを使用すると、Route 53 はDNSクエリを AWS リソースに無料でルーティングします。

AWS サービスによって作成されたホストゾーンは、チェック結果に表示されません。

B913Ef6fb4

リストされたCNAMEリソースレコードセットをエイリアスリソースレコードセットに置き換えます。「エイリアスと非エイリアスリソースレコードセットの選択」を参照してください。

また、 AWS リソースに応じてAAAA、レコードタイプを から CNAME A または に変更する必要があります。「Values that You Specify When You Create or Edit Amazon Route 53 Resource Record Sets」(Amazon Route 53 リソースレコードセットの作成または編集時に指定する値) を参照してください。

AWS リソースへのクエリのルーティング

ルックバック期間中に少なくとも 1 回呼び出された AWS Lambda 関数をチェックします。このチェックは、Lambda 関数がメモリサイズに関してプロビジョニング不足である場合に警告します。メモリサイズについてプロビジョニング不足である Lambda 関数がある場合、これらの関数の完了に時間がかかります。

COr6dfpM06

黄: ルックバック期間中にメモリサイズのプロビジョニングが不足していた Lambda 関数。Lambda 関数がプロビジョニング不足かどうかを判断するために、その関数のすべてのデフォルト CloudWatch メトリクスを考慮します。メモリサイズのプロビジョニング不足の Lambda 関数を識別するために使用されるアルゴリズムは、 AWS のベストプラクティスに従います。新しいパターンが特定されると、アルゴリズムが更新されます。

Lambda 関数のメモリサイズを大きくすることを検討してください。

詳細については、「チェック AWS Compute Optimizer に Trusted Advisor オプトインする」を参照してください。

AWS Lambda 関数が関数レベルの同時実行制限で設定されているかどうかを確認します。

同時実行数とは、AWSLambda 関数が同時に処理している処理中のリクエストの数です。Lambda は、同時実行リクエストごとに、実行環境の個別のインスタンスをプロビジョニングします。

ルールの および ConcurrencyLimitHighパラメータを使用して、予約済み同時実行数の AWS Config 最小制限concurrencyLimitLowと最大制限を指定できます。

詳細については、「Lambda 関数のスケーリング」を参照してください。

c18d2gz181

AWS Config マネージドルール： lambda-concurrency-check

黄: Lambda 関数に同時実行数の制限が設定されていません。

Lambda 関数に同時実行が設定されていることを確認します。Lambda 関数に同時実行数の制限を設けると、関数がリクエストを確実かつ予測どおりに処理できるようになります。同時実行数の制限を設けると、トラフィックの急増によって関数が処理しきれなくなるリスクを軽減できます。

詳細については、「予約済同時実行数の設定」を参照してください。

パフォーマンスの柱で、ワークロードの高リスクの問題 (HRIs) をチェックします。このチェックは、お客様の AWS-Well Architected レビューに基づきます。チェック結果は、AWS Well-Architected でワークロード評価を完了したかどうかによって異なります。

Wxdfp4B1L2

AWS Well-Architected は、ワークロードの評価中に高リスクの問題を検出しました。これらの問題は、リスクを軽減し、費用を節約する機会を提示します。AWS Well-Architected ツールにサインインして、回答を確認し、アクティブな問題を解決するためのアクションを実行します。

Amazon CloudFront ディストリビューションで、DNS設定が正しく設定されていない代替ドメイン名 (CNAMES) がないかをチェックします。

CloudFront ディストリビューションに代替ドメイン名が含まれている場合、ドメインDNSの設定はDNSクエリをそのディストリビューションにルーティングする必要があります。

N420c450f2

DNS クエリをディストリビューションに CloudFrontルーティングするようにDNS設定を更新します。「代替ドメイン名の使用 (CNAMEs）」を参照してください。

Amazon Route 53 をDNSサービスとして使用している場合は、「ドメイン名 を使用してトラフィックを Amazon CloudFront Web ディストリビューションにルーティングする」を参照してください。チェックがタイムアウトした場合は、チェックを更新してみてください。

Amazon CloudFront デベロッパーガイド

Amazon Simple Storage Service (Amazon S3) バケットからのデータ転送を CloudFront、 AWS グローバルコンテンツ配信サービスである Amazon を使用して高速化できるケースをチェックします。

コンテンツを配信 CloudFront するように を設定すると、コンテンツに対するリクエストは、コンテンツがキャッシュされている最も近いエッジロケーションに自動的にルーティングされます。このルーティングでは、可能な限り最高のパフォーマンスでコンテンツをユーザーに配信できます。バケットに保存されているデータと比較して転送されるデータの比率が高い場合は、Amazon を使用してデータを CloudFront 配信することでメリットが得られる可能性があります。

796d6f3D83

パフォーマンスを向上させる CloudFront には、 の使用を検討してください。「Amazon CloudFront 製品の詳細」を参照してください。

転送されるデータが 1 か月あたり 10 TB 以上の場合は、「Amazon の CloudFront 料金」を参照して、コスト削減の可能性を確認してください。

がクライアントから CloudFront 現在受信し、オリジンサーバーに転送するHTTPリクエストヘッダーをチェックします。

date や user-agent などの一部のヘッダーは、キャッシュヒット率 ( CloudFront エッジキャッシュから提供されるリクエストの割合) を大幅に削減します。これにより、 はオリジンに CloudFront より多くのリクエストを転送する必要があるため、オリジンの負荷が増加し、パフォーマンスが低下します。

N415c450f2

黄: がオリジン CloudFront に転送する 1 つ以上のリクエストヘッダーにより、キャッシュヒット率が大幅に低下する可能性があります。

リクエストヘッダーが、キャッシュヒット率への悪影響を正当化するのに十分なメリットを提供するかどうかを検討します。オリジンが特定のヘッダーの値に関係なく同じオブジェクトを返す場合は、そのヘッダーをオリジンに転送 CloudFront するように を設定しないことをお勧めします。詳細については、「リクエストヘッダーに基づいてオブジェクトをキャッシュ CloudFront するように を設定する」を参照してください。

過去 14 日間の任意の時点で実行されていた Amazon Elastic Compute Cloud (Amazon EC2) インスタンスをチェックします。4 日以上で 1 日のCPU使用率が 90% を超えると、アラートが送信されます。

使用率が一貫して高い場合は、パフォーマンスが最適化され、安定している場合があります。ただし、アプリケーションに十分なリソースがない可能性もあります。毎日のCPU使用率データを取得するには、このチェックのレポートをダウンロードします。

ZRxQlPsb6c

黄: インスタンスは、過去 14 日間のうち少なくとも 4 日間で 1 日の平均CPU使用率が 90% を超えました。

インスタンスをさらに追加することを検討してください。需要に基づいてインスタンス数をスケーリングする方法については、「What is Auto Scaling?」(Auto Scaling とは) を参照してください。