AWS RDS db.t2インスタンスのパフォーマンスしきい値とモニタリング

Question

Drupal＆WordPressのような主流のCMSソフトウェアの標準のWebサーバー構成を展開しています。EC2/ EBS上のサーバーとストレージ、およびRDS/MySQLのこれらのソフトウェアパッケージのデータベースを使用しています。

通常、t2.microCPUとdb.t2.microDBを使用して本番環境に移行します。＆AWSは、最初の1年間は無料枠にとどまることができるためです。 EC2のデフォルトの監視ツールは、CPU UtilizationであるWebホストの最も重要なリソースを超過する可能性がある場合を明確に示します。しきい値が10％に近づくか通過する場合、t2.smallインスタンスタイプに移行するときがきたことがわかります。

db.t2.microからdb.t2.smallにアップグレードする必要がある場合を判断する方法は、はるかに不確かです。＆多分それ以上。これらの要件にはマルチAZやリードレプリカは含まれません。CMSソフトウェアがピーク時にデータベースに大きく依存する可能性があり、グラフやアラームを介して特定する必要がある場合のみです。

EC2インスタンスのドキュメントは、それ自体の制限を明確に示しており、RDSインスタンスのそのような制限が私たちの単純なケースに推奨されるかどうか疑問に思っていました。 Amazon RDSのベストプラクティスの一般的な要件は役に立ちますが、私が設定できるしきい値を設定しようとしているだけなので、すべてのリンクをたどっていません技術者以外のクライアントが理解および監視できる方法で、DBインスタンスのアップグレードを明確に義務付けます。

私はDBAではありません。私の仕事の性質上、データベースアーキテクチャはCMSソフトウェアの設計者に任せています。 AWSプラットフォームでのこの構成に関連しているため、どこから始めればよいかを誰かが教えてくれれば、パフォーマンス評価の基本を学ぶことができます。たぶん、正しい公式のドキュメントやチュートリアルをまだ見つけていないのかもしれません。

または、CloudWatchでの表示に基づいてインスタンスサイズが小さすぎる（またはMySQLリソースパラメータの設定が小さすぎる）ことが原因でRDSインスタンスへのアクセスに遅延が生じた場合、定量的に測定する方法を知る必要があります。

簡単に言えば、CloudWatchメトリクスFreeable Memoryがゼロに近づいたかどうかがわかり、インスタンスのアップグレードが必要になります。また、EC2インスタンスと同様に、最大CPU Utilizationも必要です。これは、100％をはるかに下回ると思いますが、EC2の場合のようにこれが記載されているのを見たことはありません。 DB接続の実用的な最大値があると思います。最後に、誰かが書き込みIOPSと読み取りIOPSを解釈する方法、およびこれらが私たちのような小さな構成にパフォーマンスの制限を課すか、またはそれらが単にコストの計算に使用されるかを教えてくれると幸いです。

pS、これをAWSフォーラムに投稿しようとしました：AWSフォーラム：Amazon Relational Database Serviceが、Post New Threadリンクは現在「リダイレクトループ。" （申し訳ありませんが、これ以上URLを含めることはできませんが、許可されていません。）

[編集、コメントへの応答]@Rossに感謝、知らなかったCPUCreditBalanceも利用可能でしたRDS（EC2で見ました）。リストから17をすべて選択できる7つのメトリックが追加された2番目の画面があることはわかりませんでした。 RDSインスタンスのタイプに応じて、CPU以外の監視可能なリソース、特にI/Oアクティビティにどのような制限が課されるのか、まだ疑問に思っています。

p.p.s.、私はもう少し洗練された質問をし、AWSフォーラムに投稿しました（ RDS T2インスタンスがCloudWatch統計で適切なサイズであるかどうかを判断する方法？）

rphair · Accepted Answer

私は過去数か月の間にこれについていくつかの見解を持っていました、そして私はこれらの注意すべき項目が上記のすべての懸念に対処すると信じています：

1）元の投稿に対する@Rossからのコメントが重要です。 T2インスタンスは、規模に関係なく、EC2かRDSかに関係なく、ピークCPU需要が継続するためにCPUクレジットがなくなると実行を停止します。

2）最も頻繁に確認されているCMS Webサーバーの障害モードは、この条件によって正確に示されます。httpdプロセスで必要なCPUパーセンテージがそのインスタンスタイプに割り当てられたCPUパーセンテージを超えると、CloudWatchグラフはゼロに向かって急降下します（以下のドキュメントリンクを参照してください）。

3）CPUクレジットを使い果たしたT2インスタンスの迅速な解決策は、シャットダウンしてインスタンスタイプをアップグレードし、インスタンスを再度起動することです。これには約3〜4分かかります。さまざまなインスタンスタイプの容量の最も重要な説明は次のとおりです： http://docs.aws.Amazon.com/AWSEC2/latest/UserGuide/t2-instances.html

4）AWSのすべての本番ウェブサーバーには、この理由で事前にElastic IPアドレスが割り当てられている必要があります。そうでない場合、インスタンスが再スケーリングされると、IPアドレスが変更され、Webサーバーにアクセスできなくなります。 4分のダウンタイム。

5）CPUクレジットを増やす唯一の方法は、マシンタイプをアップグレードすることです。各T2インスタンスサイズが保持できるクレジットの量は、上記のドキュメントリンクで説明されています。これは、インスタンスタイプが24時間で実行するCPU作業に常に等しくなります。

6）ピークパフォーマンスの要求がなくなった後、予定された少しのダウンタイム（この場合も3〜4分）の間に、マシンを元のスケールに戻すことができます。

7）これまでのピーク期間では、I/OアクティビティによってWebサーバーのパフォーマンスが低下することはありません。 IOPSの量は、EBSボリュームサイズによって厳密に決定されます。 IOPSの正確な意味とその関係の両方について、ここで説明します。 http://docs.aws.Amazon.com/AWSEC2/latest/UserGuide/ebs-io-characteristics.html

8）Cloud WatchメトリックFreeable MemoryもDB接続もWebサーバーを多用する環境でのパフォーマンスの問題を予測または修正する用途。