DynamoDB
キャパシティーユニットの調整は必須。
デフォルトだと16rps程度の負荷でErrorが多発するので実用に耐えるのは厳しい。
パフォーマンステスト中に見る項目としては以下のようにキャパシティユニットが設定値を超えていないか常に確認しておく必要がある。
以下のグラフはAWSのコンソールから確認が出来るので、試験を行っている最中は監視しておく事。
キャパシティーユニットの数字は高く設定すればそれに合わせて利用料金も上がる仕組み。
一応リリース後でも変更する事は可能なので、リリース後実測値に合わせて適切なパラメータに調整しておく事が必要。（ただしギリギリを狙いすぎるのは危険）
まず大前提としてホットパーティションというアンチパターンを避ける事。
※ 詳しくは コンセプトから学ぶAmazon DynamoDB【複合キーテーブル篇】 を参照。
ある程度のデータ量になってくると、特定のパーティションだけにアクセス集中した時、キャパシティの消費が早くなってしまうので設定した値より性能が出ない現象が発生してしまう。
範囲検索が必要なテーブルは慎重に設計する。
例え設計がまともでも性能試験の際に同じユーザーIDを使いまわして高負荷をかけるとホットパーティションが発生してしまうので、ユーザーID等は実際の同時接続数に近い分だけ用意しておく事。（JMeterの場合は CSV DATA Set Config とか Random Variable を使うと実現可能）
- DynamoDB のベストプラクティス テーブルのベストプラクティス
- DynamoDBの料金を最適化しよう【初級編】
- コンセプトから学ぶAmazon DynamoDB【複合キーテーブル篇】
- DynamoDB ベストプラクティス
試験はAPI GatewayからLambdaを実行しLambda関数の中でDynamoDBを呼び出した形で実装。（言語はNode.js 6.10のランタイムを使用）
HTTPリクエストを送る攻撃用クライアントはパブリックIPを持つEC2インスタンスを用意。
99%Lineでも119msとレイテンシは悪くない。
100までキャパシティユニットは100に設定したが若干の余裕があった。
同じくレイテンシは悪くない。
キャパシティユニットは120で耐えられたが、結構ギリギリなので実運用では余裕を持って設定したほうが良さそう。
実装方法や試験方法等は読み込み時の試験と同様。
試験用APIの内容はUUIDv4形式のデータを生成しDynamoDBのテーブルに1件書き込みを行う仕様。
レイテンシはそれほど悪くない。
しかし書き込みキャパシティはかなりギリギリのライン。
読み込み時と違ってキャパシティユニットの設定とスループットの値はほぼイコールになる模様。
レイテンシはそれほど悪くない。
書き込みキャパシティは200のラインで横ばい。
