少なめの容量でEFSを使うときの速度の話

JAWS-UG 名古屋 Infrastructure as Code について学ぶ 2021/07/26 LT

Transcript

1. 少なめの容量で EFS を使うときの速度の話 JAWS-UG 名古屋 Infrastructure as Code について学ぶ　 2021/07/26 まつひさ（hmatsu47）
2. 自己紹介 松久裕保（@hmatsu47） https://qiita.com/hmatsu47 名古屋で Web インフラのお守り係をしています （ほかに書くことがなくなったので省略） 2
3. 今日の内容（注 : ほぼ JAWS-UG 浜松の再演です） • EFS とは • EFS の性能（ざっくり） ◦ AWS のストレージ特性→容量に比例してスループット UP ◦ 分散システム→ノード増・NW 遅延増で整合性確保に時間が必要 • 容量が少ない状況で高速化するには ◦ 並列処理をする ◦ 1AZ で良い場合は 1 ゾーンストレージクラスを使う 3
4. 余談 : IaC についての私見 • まじめに運用するのはつらい ◦ コードと実体の差異を生じないように維持 ▪ つらい ◦ 組織内での技術の伝承 ▪ つらい ◦ 本番環境の変更のためにコード・テンプレート書き換え→反映 ▪ 怖い • イミュータブルでないインフラ要素が意外と多い 4
5. 余談 : IaC についての私見 • 割り切る ◦ CFn : 環境の初期構築（VPC など）用に特化 ▪ 例 : 実験環境を元にステージング構築用にテンプレート作成する • その後、本番環境・DR 環境の構築に利用する ▪ 作成対象を限定する（ほどほどに分割） ◦ 展開後の作業でテンプレートと実体の差異が生じても許容 ◦ CLI/SDK : 既成環境の起動停止に使う ▪ 定期実行（Lambda から）・DR 起動など 5
6. EFS とは • フルマネージドの分散・共有ファイルシステム ◦ https://aws.amazon.com/jp/efs/ • NFSv4 プロトコルでアクセス可能 ◦ NFS v4.0 および v4.1 をサポート • 高可用性・高耐久性 ◦ 1 ゾーンストレージクラスと標準ストレージクラス ▪ 1 ゾーン内または 1 リージョン内で冗長化 ◦ 耐久性は 99.999999999% 6
7. EFS の性能 • 設定 : パフォーマンスモードとスループットモード ◦ パフォーマンスモード : 汎用 / 最大 I/O ▪ 通常は汎用モードを選択 ▪ 最大 I/O モードではメタデータ処理のレイテンシが若干増える ◦ スループットモード : バースト / プロビジョニング ▪ 今回はバーストモードを選択 • 今回の実験の範囲ではバーストモードのスループットを使い切るところまで行か ない 7
8. EFS の性能 • 汎用パフォーマンス＆バーストスループットモードでは ◦ 容量が大きいほどスループットが高い ▪ クレジットが残っている範囲で ▪ AWS のストレージサービス共通の特性 • 分散システムとしての特性 ◦ 書き込み処理 : 整合性確保に時間が掛かる ▪ ノードの数が増え、ネットワークのレイテンシが大きくなるほど ◦ 整合性確保の問題がなければ、並列処理は得意 8
9. 小容量で使うときの EFS の弱点 • とにかく書き込みが遅い ◦ 分散・共有ファイルシステムなので… • 例えば、Amazon Linux 2 で普通に rsync してみると ◦ m5.large で /usr/（1.1GB）から別のファイルシステムにコピー rsync -avz /usr/ /mnt/【コピー先】/usr/ ◦ 対 EBS（gp3 IOPS：3000） : 00 分 54 秒 ◦ 対 EFS（1 ゾーン・バースト） : 13 分 51 秒（15.4 倍遅い） ◦ 対 EFS（標準・同） : 25 分 58 秒（28.9 倍遅い） 9
10. 処理を並列化してみる • rsync を xargs と組み合わせる ls -1 /usr | xargs -I {arg} -P 【並列数】 -n 1 rsync -avz /usr/{arg} /mnt/【コピー先】/usr/ 10 コピー先 通常（1 並列） 2 並列 4 並列 EBS（gp3 IOPS：3000） 00:54 - 00:42 - 00:39 - EFS（1 ゾーン・バースト） 13:51 15.4 倍遅い 09:09 13.1 倍遅い 06:23 9.8 倍遅い EFS（標準・同） 25:58 28.9 倍遅い 16:35 23.7 倍遅い 11:28 17.6 倍遅い
11. 処理を並列化してみる 11
12. 補足と注意点 • 並列数をもっと増やすとさらに高速化する ◦ m5.large （2vCPU）のように vCPU 数の少ないインスタンスで も 10 ～ 16 並列ぐらいは行ける ▪ /usr/ 直下のディレクトリの数が少なく中のファイル容量や数のバランスが 悪いので今回は 4 並列まで（バランスが良いと線形に性能向上する） • 一部の NFS クライアントでは並列化の効果が出ない ◦ RHEL 6 など ◦ 処理を直列化してしまうため 12
13. 参考：読み取り（find）並列化 • 通常 : find -type f -exec cat {} \; • 並列 : find -type f -print0 | xargs -0 -I {arg} -P 【並列数】 -n 1 cat {arg} ※都度 OS を再起動し、OS のディスクキャッシュがクリアされた状態で計測 13 読み取り対象 通常 （1 並列） 2 並列 4 並列 8 並列 EBS（gp3 IOPS：3000） 00:46 00:24 00:17 00:16 EFS（1 ゾーン・バースト） 02:43 01:05 00:36 00:28 EFS（標準・同） 02:47 01:10 00:35 00:26
14. 参考：読み取り（find）並列化 14
15. まとめ • 処理を並列化すると速くなる ◦ 1 インスタンスからのアクセスでも ◦ vCPU 数が少なくても • 1 ゾーンストレージクラスのほうが速い ◦ 要件を満たす場合は 1 ゾーンストレージクラスも選択肢に • 書き込みと読み取りでは少し傾向が違う ◦ EBS との差は読み取りのほうが小さい ◦ 読み取りでは 1 ゾーンと標準の性能差は（ほぼ）ない 15
16. おまけ : バッチ処理などを並列化する際の注意点 • レースコンディション（スレッド間競合）に注意 ◦ Web アプリケーションなどと同様、スレッド間の競合を起こさな いよう注意してプログラミングする ▪ 非スレッドセーフな処理を書かない • ネットワークのコネクション数爆発に注意 ◦ バッチ処理内で EFS 以外（RDS など）に接続している場合 ◦ RDS コネクション数とは別に、TCP の TIME_WAIT 問題も ▪ （recycle ではなく）reuse であってもトラブルが生じるケースも 16