この記事は、Opt Technologies Advent Calendar 2017の13日目です。
はじめに
RDS(PostgreSQL)で、r3.xlarge を利用していましたが、
利用のされ方を見ているモニタリングしていると、m系の方が適していそうと漠然と感じたので、
比較検証をしてみましたので、その結果について書いてみようと思います。
書き込み速度
- Redshiftで集計したデータをdblinkでPostgreSQLで書き込んでいるので、この点について比較を実施します
- 対象とするテーブルは以下のような24テーブルです
- 2回実行した平均です
# | レコード数 | バイト数(MB) |
---|---|---|
1 | 24,689,290 | 17,445 |
2 | 26,807,199 | 18,616 |
3 | 26,658,915 | 18,523 |
4 | 27,216,467 | 18,872 |
5 | 21,746,356 | 16,140 |
6 | 22,243,298 | 16,363 |
7 | 23,346,676 | 16,938 |
8 | 25,408,481 | 17,982 |
9 | 23,021,530 | 16,816 |
10 | 20,564,258 | 15,685 |
11 | 21,436,185 | 16,586 |
12 | 20,653,664 | 16,234 |
13 | 18,860,732 | 15,382 |
14 | 20,036,435 | 16,007 |
15 | 18,819,465 | 15,541 |
16 | 20,192,921 | 16,392 |
17 | 16,203,493 | 14,202 |
18 | 16,200,846 | 14,318 |
19 | 15,585,507 | 14,049 |
20 | 14,966,510 | 13,805 |
21 | 13,120,155 | 12,818 |
22 | 12,692,634 | 15,954 |
23 | 6,199,836 | 13,115 |
24 | 9,846,026 | 11,264 |
検証結果
# | レコード数 | バイト数(MB) | PostgreSQL側のレコード数 | 処理時間(r3.xlarge) | 処理時間(m4.xlarge) | 処理時間が何%に短縮されたか? |
---|---|---|---|---|---|---|
1 | 24,689,290 | 17,445 | 9,191,484 | 0:03:42 | 0:02:40 | 72% |
2 | 26,807,199 | 18,616 | 9,705,530 | 0:03:59 | 0:02:59 | 75% |
3 | 26,658,915 | 18,523 | 9,714,430 | 0:04:03 | 0:02:59 | 74% |
4 | 27,216,467 | 18,872 | 9,879,839 | 0:04:03 | 0:03:03 | 75% |
5 | 21,746,356 | 16,140 | 7,769,635 | 0:03:17 | 0:02:25 | 74% |
6 | 22,243,298 | 16,363 | 7,782,167 | 0:03:11 | 0:02:24 | 75% |
7 | 23,346,676 | 16,938 | 7,928,929 | 0:03:21 | 0:02:26 | 73% |
8 | 25,408,481 | 17,982 | 8,494,064 | 0:03:35 | 0:02:28 | 69% |
9 | 23,021,530 | 16,816 | 7,515,539 | 0:03:07 | 0:02:23 | 76% |
10 | 20,564,258 | 15,685 | 6,426,314 | 0:02:39 | 0:01:58 | 74% |
11 | 21,436,185 | 16,586 | 6,466,979 | 0:02:37 | 0:02:00 | 76% |
12 | 20,653,664 | 16,234 | 6,183,918 | 0:02:25 | 0:01:52 | 77% |
13 | 18,860,732 | 15,382 | 5,370,144 | 0:02:06 | 0:01:41 | 80% |
14 | 20,036,435 | 16,007 | 5,751,794 | 0:02:17 | 0:01:45 | 77% |
15 | 18,819,465 | 15,541 | 5,233,820 | 0:02:04 | 0:01:36 | 77% |
16 | 20,192,921 | 16,392 | 5,596,285 | 0:02:09 | 0:01:44 | 81% |
17 | 16,203,493 | 14,202 | 4,367,008 | 0:01:39 | 0:01:21 | 82% |
18 | 16,200,846 | 14,318 | 4,365,299 | 0:01:49 | 0:01:19 | 72% |
19 | 15,585,507 | 14,049 | 4,098,571 | 0:01:36 | 0:01:16 | 79% |
20 | 14,966,510 | 13,805 | 3,822,217 | 0:01:32 | 0:01:08 | 74% |
21 | 13,120,155 | 12,818 | 3,443,428 | 0:01:17 | 0:01:02 | 81% |
22 | 12,692,634 | 15,954 | 3,321,944 | 0:01:19 | 0:00:58 | 73% |
23 | 6,199,836 | 13,115 | 3,103,642 | 0:01:11 | 0:00:55 | 77% |
24 | 9,846,026 | 11,264 | 3,043,508 | 0:01:05 | 0:00:49 | 75% |
結論
- 使用可能なメモリ量には余裕がある
- IOPSが頭打ち
以上のような状態であれば、間違いなくr系よりはm系の方が適しているかと思います。
前から使い続けているインスタンスタイプだからといってそのままにせず、利用状況をモニタリングしながら最適なインスタンスを選択する事でよりよい効果が得られるかと思います。
以上です。
読み込み側の検証は今回は記載しておりませんが、またの機会にまとめたいと思います。
それではより良いAWSライフを。