EFS導入で夢が広がると思ったら、現実を突き付けられた話

EFS導入で夢が広がると思ったら、現実を突き付けられた話(※小規模構成に限る？)

** やりたかったこと
-- 今の構成の問題点

1,コンテンツの更新がそこそこ頻繁なため過去のAMIが使えず、負荷が上昇してからAMIを取得しているとバーストに対応できない
2,WEBの台数が多いサービスのコンテンツ更新の度にリポジトリサーバが高負荷になり、サーバごとに遅延が発生する。

-- EFS導入で期待したこと

 1,上記問題点を解決できる。
 2,念願の簡単な手順でのオートスケーリングが実現する。

** できなかった理由
-- EFSが遅い

コンテンツの更新にものすごい時間がかかるため、突発的なメンテナンスやバグ対応に支障をきたす。
※下記結果参照

-- EBSの場合

 $ time svn st /ebs_content_dir
 ============================================
 real    0m0.331s
 user    0m0.207s
 sys     0m0.100s
 →はやい
 ============================================

-- EFSの場合

 $ time svn st /efs_content_dir
 ============================================
 real    2m59.950s
 user    0m0.902s
 sys     0m2.189s
 →えぇ……。
 フォーラムを確認してみたところ、fs-cacheをインストールしてマウントオプションに追加しろとの書き込みを発見
 ============================================

-- EFSの場合 with fs-cache有効化

 $ time svn st dev_gm_shq_geso
 ============================================
 real    1m38.342s
 user    0m0.584s
 sys     0m1.496s
 →すごい！二倍早くなった！ってなるかい
 ============================================

-- その他フォーラムで情報を漁るものの……(意訳)

Aさん -- Nginx+WordpressでドキュメントルートをEFSにしたけどEBSに比べて2-7秒遅延するのだが？
Bさん -- おれも1-2秒は遅延してるわ。この遅延は最も優先すべき課題なので解決しない限り使うべきではないな。
Cさん -- 容量によって書込速度が変わるから、1TBのダミーファイル置くといいよ。金かかるけど。
2016年の北アメリカリージョンのサービス開始時に建てられたフォーラムスレッドが今もやり取りを続けている模様

** まとめ

1, サービス紹介のような最小構成でEFSを利用する場合は、コンテンツ配布およびWEBアクセスで数秒以上の遅延は覚悟する必要があります。
2, 大容量のNFSを利用する大規模顧客で、EC2+NFSで冗長性が不安だと思っている人向けのサービスみたいです。
3, もしくはあまりコンテンツの更新がなく、アクセスが遅くとも問題の無いサービス向けかと。