本記事は EFS使ってみた ~ EBSとEFSの読み込み速度を比較編 ~ の続きです。
つづき
上記の記事で一旦終了でいいかなと思いましたが、ユースケースを用いてまともに使うにはどうすればよいかを考察します。
AZを分ける
AZを同じでやってみましたが今度は分けてみましょう。
前回と同じようなグラフになりました。
AZが遠いと死期が早まるようです。
EBSかEFSかという観点ではやはりどちらも同じ感じです。
変更タイムラグ
追記されまくっているファイルにアクセスしたときなにが返るのか見てみます。
- unixtimeをいっぱいファイルに書く
- そのファイルを取得した時間とファイル内の時間を比較
マイナスになっている箇所があります。
読みとりに待ち時間が発生するのでしょう。
EBSでは数ミリ秒の差分ですがEFSは10ミリ秒前後誤差がある様子。
とにかくいっぱいやってみました。
これはなかなかおもしろい結果が得られました。
EBSは45301回でEFSは235721回と、同期間でサンプリングに差が出ました。
試行回数分線形に負荷が高くなっていく(14B)のですがある一定のラインを境にパフォーマンスが変化し、EBSとEFSで違いが見られるということです。
どちらもバーストクレジットが枯渇したというわけではないでようです。
グラフでは見にくいのでそれぞれ境界部分を見てみます。
まずEBSは2段階山があります。
18173,1289 18174,0 18175,0 18176,3272 18177,5355 18178,3248 |
18176回目を境に5～8秒のズレが生じ始めています。
サンプルが256KBを超え始めたからからかもしれません。
32148,5164 32149,6949 32150,10375 32151,9903 |
途中で持ち直すこともあり平均値が見えにくいのですが二段階目の山はこのあたりです。
32000前後で10秒超えるズレが見え始めます。
次にEFSはかなり長い時間パフォーマンスを維持し、ある一点で急激に劣化しています。
グラフでは試行回数が多すぎて見えないんですがこちらも実は段階が二つあります。
216010,5757 216011,8047 216012,8 216013,5513 216014,12192 |
だいたいこのへんです。このあたりでは3MB超をさばいています。
EBSが2万回弱だったところをみると驚異的なパフォーマンスなのではないでしょうか。
分散ストレージの強みといったところです。
劣化度は近似に見えます。
続いて、二段階目の山なのですが
234424,9199 234425,5808 234426,13172 234427,18762 ～～～ 234443,100344 234444,104858 234445,110148 234446,114670 ～～～ 235718,6438648 235719,6443140 235720,6447800 235721,6452540 |
なんと234424回目を境に線形に劣化していきます。
通常使っている分には気にならない誤差かもしれませんが、じわじわと遅くなっていく、みたいなことが発生するかもしれません。
衝突
同時に書き込みまくってみます。
上書きの場合
- 3つのサーバー(A,B,C)がEFSをマウントします
- AとBが同じファイルを上書きまくります
- Cからはなにが見えるのか
# cat col abcdefg # cat col # cat col # cat col # cat col # cat col # cat col # cat col qwertyu # cat col # cat col # cat col # cat col # cat col # cat col # cat col # cat col # cat col qwertyu # cat col # cat col abcdefg |
1秒間隔だとどちらかのファイルが見れますが、1ミリ秒間隔だと、0バイトファイルが見えるようです。
つまり、更新頻度の高いファイルにアクセスする際に空でないことは保証されないということでありなにか入っていることを前提にするとアプリが死んでしまう可能性があります。
参照一貫性オプションみたいなものはあるんでしょうか・・・
追記の場合
こんどは上書きではなく追記をしてみます。
qwertyu qwertyu qwertyu qwertyu qwertyu abcdefg abcdefg abcdefg qwertyu qwertyu qwertyu qwertyu qwertyu |
こんなようなファイルができました。
順番にある程度まとまって書き込みがされるようです。
が、若干気になる挙動を示しました。
63バイトの00ビットが挿入されています。これはあぶない。
これは前半のほうなのでコネクションの際の歪みなのでしょうか。
あんまり同時に追記するとファイルが壊れてしまう可能性がありそうです。
衝撃
読み込んでいる最中に破壊
大きめのファイルを読み込んでいる最中に削除してみます。
-rw-r--r-- 1 root root 67108864 Sep 10 06:40 34 -rw-r--r-- 1 root root 67108864 Sep 10 06:40 35 -rw-r--r-- 1 root root 67108864 Sep 10 06:41 36 -rw-r--r-- 1 root root 67108864 Sep 10 06:41 37 -rw-r--r-- 1 root root 0 Sep 10 06:41 38 |
こんな感じで削除される直前まではちゃんとファイルが取れるようです。
(0バイトファイルはwriteストリームを作成したあとにファイルが存在しなかったため)
EFSでデプロイしてみる
EFSにアプリを置いて、そのまま他のサーバーでマウントして使えるのかやってみます。
※注意！ 常にディスクI/Oが発生する実装系では利用してはいけません。ログなど置いたりもしてはダメです。
1.EFSにアプリを配置します
servershare]# mkdir efs servershare]# sudo mount -t efs fs-b1a55290:/ efs servershare]# cd efs/ efs]# mkdir servershare efs]# cd servershare servershare]# cp ../../*.coffee . servershare]# cp ../../*.json . servershare]# ls app.coffee efs helper.coffee helper_snipet.coffee package.json package-lock.json |
2.動かします
servershare]# npm i npm WARN resp@1.0.0 No description npm WARN resp@1.0.0 No repository field. added 103 packages from 130 contributors and audited 138 packages in 35.41s found 0 vulnerabilities servershare]# coffee app.coffee listen ^Z [1]+ Stopped coffee app.coffee servershare]# bg 1 [1]+ coffee app.coffee & servershare]# jobs 1 [1]+ Running coffee app.coffee & servershare]# disown %1 servershare]# servershare]# curl localhost done servershare]# |
うごきました。EFS上でnode_moduleを展開するのはリスキーな気がします。
3.別のサーバーで同じEFSをマウントします
servershare]# sudo mount -t efs fs-b1a55290:/ efs servershare]# cd efs/servershare/ servershare]# ls app.coffee helper.coffee helper_snipet.coffee node_modules package.json package-lock.json |
node_modulesの存在を確認します。
4.同様に動かします
servershare]# coffee app.coffee listen ^Z [1]+ Stopped coffee app.coffee servershare]# bg 1 [1]+ coffee app.coffee & servershare]# jobs 1 [1]+ Running coffee app.coffee & servershare]# disown %1 servershare]# curl localhost done servershare]# |
問題なくできました。
が、やはり現実的ではありません。(サービスに登録できない、次のデプロイの際に制御できない)
ゆるーいCDNとして使うか、アプリ内から参照する静的コンテンツだけを置くのであれば使えると思います。
おまけ
二重にマウント
# mkdir efs2 # sudo mount -t efs fs-b1a55290:/ efs2 # ls efs efs2 efscheck onegibi # ls efs efs fileb filek filem # ls efs2 efs fileb filek filem |
できるようです。
ひらがなディレクトリ
# mkdir ひらがな # ls ひらがな efs fileb filek file |
できるようです。
EFS内のディレクトリを指定して指定したディレクトリにマウント
# ls efs2 ひらがな efs fileb filek filem folder # mkdir sele # sudo mount -t efs fs-b1a55290:/folder sele # ls sele testest |
できました。セグメンター制度も安心。
EFSの中でEFSをマウントする
# sudo mount -t efs fs-b1a55290:/ efs # cd efs # sudo mount -t efs fs-b1a55290:/ efs # cd efs # sudo mount -t efs fs-b1a55290:/ efs # cd efs # sudo mount -t efs fs-b1a55290:/ efs # cd efs # sudo mount -t efs fs-b1a55290:/ efs # cd efs # pwd /root/efs/efs/efs/efs/efs/efs/efs/efs |
けっこう掘れるようです。
纏
・バーストクレジットを使い切ってはいけない
・ベースライン内で納めるように(S3やDynamoDBのようにスロットル調整が重要)
・Webサーバーから返却させるのは危険(かも。アンチパターンの薫りがする)
下
ストレージとしてのパフォーマンスはかなり高いと思われます。
ストレージとしてのお値段はかなり高いと思われます。
この記事を書いた人
- juke / footworker
- 和服とvapeとСистемаと醗酵とたまごふわふわとカッティングシェイプスとジャージークラブとjuke/fwkに傾倒する人です
最近書いた記事
2019.10.17ES2019で追加されたあれこれを使ってみる- 2019.09.20JavaScript で安全に扱える最大整数
- 2019.07.24Gitでハッシュ値指定が重複したらどうなるのか
- 2019.07.09ハッシュは何に使えるのか