大きくはない値に思えますが、ベンチマーク結果をみるにそれでも十分な効果があります。次に可能な限り大きく確保しても良さそうな香りすらします。パラメータグループを編集するだけで即反映されるので、とりあえずデフォ値で運用を開始し、少しずつ増やしてみるのがよさげです。CPU利用率とIOPSの性質デフォルト設定+1GBのデータがオンメモリの状態で、接続数を変動させた結果です。参照クエリからわかることAuroraは並列性能を向上させるために、常に高いCPU利用率となるような特殊な仕組みになっている、という前情報があります。そのため、従来のMySQLのようにQPSに比例するようなCPU変動にならない可能性が高いです。検証結果としては見ての通り、CPU利用率が高めに推移し、レスポンスタイムが劣化しつつも、並列数に対応するようにQPSとしては向上しています。あたりがキャパシティ予測に関係しそうですが、従来の感覚で対処しようとすると時期尚早になる場合もありそうです。更新クエリからわかることCPU/QPS/ResTimeの性質は参照と同様ですので、ここではWriteIOPSに着目します。更新QPSが600~4600に変動しても、WriteIOPSは1770~2000という狭い範囲に留まっています。これはQPSの伸びからすると非常に不自然ですが、公式ページから何か仕込みが入っていることが伺えます。消費を節約しています。AuroraIOPSについては以降の検証でさらに明らかになるので、ここではIOPSがスループットに全く比例しないことがある、というように認識できればよいかと思います。sizeを最小限、QCacheをOFFにしてIOPSを発生しやすく演出し、接続数を固定にして、データ容量の増加による変化を確認します。容量が大きくなるほどQPSが劣化していくのですが、CPUとReadIOPSが一定を保っています。これだけで断定できるわけではないですが、ひとまず参照のReadIOPSがボトルネックとなっていると仮定しておいてよさそうです。waitによってQPSが劣化していくのは当然といえます。参照と同様、QPSの劣化に対してCPUとIOPSがほぼ横ばいです。あたりがボトルネックとなり、容量増加に必要なIOPSが足りずにQPSが劣化しているようです。WriteIOPSは単にQPSが落ちた分だけ減少しています。参照も更新もIOPSがボトルネックと仮定すると、参照と更新でIOPSの限界値が異なっている可能性があると推測できます。一般的には、ストレージ容量が大きくなるほどIOPSも性能向上する傾向にあるのですが、Auroraでは容量頼りのIOPSキャパシティではなく、意図的な制限がかけられている感触を得られました。64TBまで自動拡張なので、当然といえば当然でしょう。同上でIOPSを発生しやすく演出し、接続数と容量を固定にして、インスタンスタイプ変更による変化を確認します。ここまでIOPS周りでグッとくるものがなく、この検証はダメ押しにもう1本的な感じでやったのですが、いい感じに当たりました。上限が開放され、QPSとResTimeが向上しているのが見て取れます。今回は上位スペックでさらに流量を増やす検証はしなかったので、各スペックでのIOPS上限は不明なままですが、インスタンスタイプとIOPS上限が連動していることがわかりました。したらスペックを1つ上げる毎に倍々に上限が上がる可能性もあるでしょう。従来のMySQLならば、スペックを倍にしたらCPU利用率は1/2に近い値になるものでしたが、見ての通り、r3.largeから4倍・16倍と上げてもCPUはさほど下がりません。その背景にはQPSをより多く捌けるようになった部分もありますが、それを差っ引いてもまだ高めという印象の比率です。このことからも、やはりCPU利用率は高めに推移する、ということが確認できます。本番運用にてスペックを上げたあとのグラフ感覚で、変な悲観や謎解き検証に走らないよう、認識を改める必要がありそうです。Data+Indexが約1GBになるように作成しました。確認したのですが、この情報は統計情報チックで正確じゃないので、微調整に少し泣きました。一応、監視グラフには、費用となるデータ容量(GB)があるのですが、常に現時点のデータ総容量を表してくれるものではないので、そのグラフだけは欲しいかな、と思いました。再起動後にデータがオンメモリRDSとAuroraを同時に再起動して、それぞれテーブル全体をカウントする参照クエリを実行してみると、RDSでは一回目は5秒程度のものが、Auroraではコンマ秒でした。メモリ内ページキャッシュに保存された既知の一般的なクエリのページを使用してバッファープールを事前にロードします。する必要性をバイパスすることでパフォーマンスが向上します。Serviceあれ?俺的事前情報では、再起動してもバッファプールキャッシュが失われない、って感じだったんだけど、キャッシュを作りなおしてから使えるようにするイメージのようです。障害時は保てるわけないし、そりゃそうか。暖まってるのは確認できました。再起動時の鬼WriteIOPSこれは再起動した時のWriteIOPSのグラフです。フリーザ様の最終形態クラスの数値を叩き出しています。いったところでしょうか。データ容量やパラメータ値を変更しても、必ずこの値が記録されるので、何の処理かは謎です。実害はないのでいいのですが、少なくとも再起動後1時間は現実的な値の変化が見えない無意味なグラフになるので考えものかと思います(カーソルを合わせれば詳細数値は把握できるけども)。何がボトルネックになるかAWSの中の人とも少し話したのですが、ストレージ容量は64TBまで自動拡張されますし、64TBまでを想定した作りになっているため、基本的にはインスタンスタイプを上げたスケールアップだけで対応できるようになっており、さらに突き詰めると垂直・水平分割をすることになる、ということでした。今回の検証で、スケールアップする意味はCPU/メモリ/ネットワーク性能の向上だけではなく、(おそらく)IOPSにも関与していることが判明したので、提供側的にはインスタンスタイプ毎にサービス規模はこのくらいで、必要なリソースはこのくらいだろう、とある程度想定して作られていると見受けられます。その想定値は概ね十分であるという印象です。いつ、何を基準にスケールアップやスケールアウトの時期を見極めたらよいのか、という課題が残ります。CPU利用率を基準にすると、50%では実はまだまだ余力があって、80%を超えてからでも十分かもしれない。IOPS基準にすると、どうやらインスタンスタイプ毎に見えない上限があって認識しづらいし、さらにIOPSの変動がほとんどないのに、よりクエリ数を捌けてしまうという現象にも遭遇するでしょう。そこで、今回採取したデータから計画するならば、クエリの平均レスポンスタイム(または平均レイテンシ)が1つの指標にはなりそうです。CPU利用率は高いまま・IOPSは変わらない・でもQPSは伸び続ける、という状況において、おそらくレスポンスタイムが徐々に悪化するであろうことが予想できます。困ったことにレスポンスタイムはサービスごとに平均値・健全値が異なり、結局はどの数値を超えたらスケールアップすべきかの判断が難しいことになるでしょう。そのため、あくまで無いよりはマシ、程度の1つの指標となります。備え付けの監視項目には、各クエリ種ごとのLatencyもありますので、この値の特徴を掴み、ゆくゆくはそれを元にアラート設定することも効果的かもしれません。STATUS値の特徴の把握や、QueryCache周りを筆頭にパラメータの調整によるチューニングも控えています。上手に扱えれば、お値段以上の成果を優に発揮できるポテンシャルを秘めていますので、当分はインターネッツの皆でノウハウを集約していく日々が続くということになるのでしょう。私の分はこれにて以上ということで、相互扶助よろしくお願い申し上げます。VolumeBytesUsedから取得するのはどうでしょうか。コメントをキャンセルメールアドレスが公開されることはありません。data-url="">外道父ドリコムで主にインフラエンジニアをやっている何でも屋。WordPress.。