Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
少なめの容量でEFSを使うときの速度の話
Search
hmatsu47
PRO
July 26, 2021
Technology
1
780
少なめの容量でEFSを使うときの速度の話
JAWS-UG 名古屋 Infrastructure as Code について学ぶ 2021/07/26 LT
hmatsu47
PRO
July 26, 2021
Tweet
Share
More Decks by hmatsu47
See All by hmatsu47
BuriKaigi2024 にボランティアスタッフとして参加した話
hmatsu47
PRO
0
47
Aurora MySQL と Redshift の zero-ETL 統合のフィルター機能を試してみた
hmatsu47
PRO
0
19
Aurora MySQL 3.06 の ML 機能で Bedrock アクセスを試してみた
hmatsu47
PRO
0
32
RDS Data API と Aurora zero-ETL 統合と BuriKaigi2024 の話
hmatsu47
PRO
0
15
RDS Data API のその後と Aurora zero-ETL 統合のデータ転送処理の話
hmatsu47
PRO
0
41
RDS_Aurora 関連アップデート 2023 版
hmatsu47
PRO
0
69
人工無能たいたん
hmatsu47
PRO
0
61
20 世紀末の地方税理士事務所で IT 導入の 1 → 10 を頑張った話
hmatsu47
PRO
0
37
パソコン通信むかしばなし
hmatsu47
PRO
0
200
Other Decks in Technology
See All in Technology
ServiceNow Knowledge Learning Rise up
manarobot
0
200
Cracking the KubeCon CfP
inductor
2
230
20分で完全に理解するGrafanaダッシュボード
hamadakoji
1
270
本当のAWS基礎
toru_kubota
0
500
Google Cloud Next '24でブログを10本書いた方法と勉強会を沸かせた方法
yasumuusan
0
290
AWSに詳しくない人でも始められるコスト最適化ガイド
yuhta28
0
150
レガシーをぶっ壊せ。AEONで始めるDevRelの話 / Qiita Night 2024-2-22
aeonpeople
3
1.3k
DevOpsメトリクスとアウトカムの接続にトライ!開発プロセスを通して計測できるメトリクスの活用方法
ham0215
2
230
家族アルバム みてねにおけるGrafana活用術 / Grafana Meetup Japan Vol.1 LT
isaoshimizu
1
430
ユーザーストーリーのレビューを自動化したみたの
bun913
1
410
継続的な改善 x ⾮連続的な進化
sansantech
PRO
3
150
「スニダン」開発組織の構造に込めた意図 ~組織作りはパッションや政治ではない!~
rinchsan
3
540
Featured
See All Featured
Rebuilding a faster, lazier Slack
samanthasiow
73
8.2k
YesSQL, Process and Tooling at Scale
rocio
164
13k
The Power of CSS Pseudo Elements
geoffreycrofte
60
5k
Code Reviewing Like a Champion
maltzj
514
39k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
30
6k
The Illustrated Children's Guide to Kubernetes
chrisshort
31
46k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
9
8.3k
Fashionably flexible responsive web design (full day workshop)
malarkey
398
65k
The MySQL Ecosystem @ GitHub 2015
samlambert
243
12k
Designing for Performance
lara
601
67k
How To Stay Up To Date on Web Technology
chriscoyier
782
250k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
7
1k
Transcript
少なめの容量で EFS を使うときの速度の話 JAWS-UG 名古屋 Infrastructure as Code について学ぶ 2021/07/26
まつひさ(hmatsu47)
自己紹介 松久裕保(@hmatsu47) https://qiita.com/hmatsu47 名古屋で Web インフラのお守り係をしています (ほかに書くことがなくなったので省略) 2
今日の内容(注 : ほぼ JAWS-UG 浜松の再演です) • EFS とは • EFS
の性能(ざっくり) ◦ AWS のストレージ特性→容量に比例してスループット UP ◦ 分散システム→ノード増・NW 遅延増で整合性確保に時間が必要 • 容量が少ない状況で高速化するには ◦ 並列処理をする ◦ 1AZ で良い場合は 1 ゾーンストレージクラスを使う 3
余談 : IaC についての私見 • まじめに運用するのはつらい ◦ コードと実体の差異を生じないように維持 ▪ つらい
◦ 組織内での技術の伝承 ▪ つらい ◦ 本番環境の変更のためにコード・テンプレート書き換え→反映 ▪ 怖い • イミュータブルでないインフラ要素が意外と多い 4
余談 : IaC についての私見 • 割り切る ◦ CFn : 環境の初期構築(VPC
など)用に特化 ▪ 例 : 実験環境を元にステージング構築用にテンプレート作成する • その後、本番環境・DR 環境の構築に利用する ▪ 作成対象を限定する(ほどほどに分割) ◦ 展開後の作業でテンプレートと実体の差異が生じても許容 ◦ CLI/SDK : 既成環境の起動停止に使う ▪ 定期実行(Lambda から)・DR 起動など 5
EFS とは • フルマネージドの分散・共有ファイルシステム ◦ https://aws.amazon.com/jp/efs/ • NFSv4 プロトコルでアクセス可能 ◦
NFS v4.0 および v4.1 をサポート • 高可用性・高耐久性 ◦ 1 ゾーンストレージクラスと標準ストレージクラス ▪ 1 ゾーン内または 1 リージョン内で冗長化 ◦ 耐久性は 99.999999999% 6
EFS の性能 • 設定 : パフォーマンスモードとスループットモード ◦ パフォーマンスモード : 汎用
/ 最大 I/O ▪ 通常は汎用モードを選択 ▪ 最大 I/O モードではメタデータ処理のレイテンシが若干増える ◦ スループットモード : バースト / プロビジョニング ▪ 今回はバーストモードを選択 • 今回の実験の範囲ではバーストモードのスループットを使い切るところまで行か ない 7
EFS の性能 • 汎用パフォーマンス&バーストスループットモードでは ◦ 容量が大きいほどスループットが高い ▪ クレジットが残っている範囲で ▪ AWS
のストレージサービス共通の特性 • 分散システムとしての特性 ◦ 書き込み処理 : 整合性確保に時間が掛かる ▪ ノードの数が増え、ネットワークのレイテンシが大きくなるほど ◦ 整合性確保の問題がなければ、並列処理は得意 8
小容量で使うときの 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
処理を並列化してみる • 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
補足と注意点 • 並列数をもっと増やすとさらに高速化する ◦ m5.large (2vCPU)のように vCPU 数の少ないインスタンスで も 10
~ 16 並列ぐらいは行ける ▪ /usr/ 直下のディレクトリの数が少なく中のファイル容量や数のバランスが 悪いので今回は 4 並列まで(バランスが良いと線形に性能向上する) • 一部の NFS クライアントでは並列化の効果が出ない ◦ RHEL 6 など ◦ 処理を直列化してしまうため 12
参考:読み取り(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
参考:読み取り(find)並列化 14
まとめ • 処理を並列化すると速くなる ◦ 1 インスタンスからのアクセスでも ◦ vCPU 数が少なくても •
1 ゾーンストレージクラスのほうが速い ◦ 要件を満たす場合は 1 ゾーンストレージクラスも選択肢に • 書き込みと読み取りでは少し傾向が違う ◦ EBS との差は読み取りのほうが小さい ◦ 読み取りでは 1 ゾーンと標準の性能差は(ほぼ)ない 15
おまけ : バッチ処理などを並列化する際の注意点 • レースコンディション(スレッド間競合)に注意 ◦ Web アプリケーションなどと同様、スレッド間の競合を起こさな いよう注意してプログラミングする ▪
非スレッドセーフな処理を書かない • ネットワークのコネクション数爆発に注意 ◦ バッチ処理内で EFS 以外(RDS など)に接続している場合 ◦ RDS コネクション数とは別に、TCP の TIME_WAIT 問題も ▪ (recycle ではなく)reuse であってもトラブルが生じるケースも 16