MySQLデータベースの一部をAWSに移行しています。問題のデータは99%が書き込みで、各行には約1kのvarcharフィールド、日時、4つの整数があります。
ピーク時には1時間あたり20〜25,000件のレコードを挿入する必要があると思います。
現在のデータベースでiostat -hを実行したところ、約40 tpsでした。
どのようなタイプのIOPSが必要になるかをどのように判断しますか?
あなたはそれをテストする必要があります。
エンベロープ計算の裏側で、挿入ごとのI/O数を概算したり、1秒あたりのトランザクション数を掛けたり、バッファールームを追加したりすることもできますが、テストする方がはるかに簡単です。
最も簡単な方法は、最良の推測を割り当ててから、戻って実際のテストに合わせて増減することです。これはクラウドベースの環境を使用する贅沢の1つであり、ハードウェアの変更は資本コストが低く、そのような変更は通常、構成の更新のみを必要とします。 EBSボリュームでは、IOPSの数を増やすだけではなく、ボリュームのサイズも拡大する必要があります 1 。いつでも新しいボリュームを作成して、データをコピーできます。多少のダウンタイムはありますが、データがhugeでない場合は、生のコピーになるはずです。
必要なI/Oの数を推測します。繰り返しになりますが、詳細はインデックスの数と、トラフィックフローがスムーズかスパイキーかによって異なります。 25K tx /時間では、〜7 tx /秒になります。各行のサイズは、単一のI/O(4K)のサイズよりも小さいため、特に関係ありません。各トランザクションは1〜5 IOP(プライマリインサートとカップルインデックスツリーインサート)の間のどこかで行われるため、〜35/sとしましょう。
最初は最低100 IOPSから始め、必要に応じてスケールアップします。
基本的なiostat(iostat -h)ツールを使用して、現在使用しているiopsの数を把握しました。そのことから、その負荷の4倍を下回った場合に使用する量を推定し、その量を使用しました。私にとっては780 IOPSに達したため、800 IOPSを使用しました。
Iostatを使用して、アプリケーションが実行しているIOPSの量を判断します。 iostatはこれをtpsとして報告します。 KB/tは、転送量がチャンクサイズである256 KiBより小さいかどうかを判断するのに役立ちます。 1秒の待機時間でiostatを実行します。つまり、iostat -w 1です。