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
1.2k
少なめの容量で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
PostgreSQL+pgvector で GraphRAG に挑戦 & pgvectorscale 0.7.x アップデート
hmatsu47
PRO
0
8
LlamaIndex の Property Graph Index を PostgreSQL 上に構築してデータ構造を見てみる
hmatsu47
PRO
0
10
PostgreSQL+pgvector で LlamaIndex の Property Graph Index を試す(序章)
hmatsu47
PRO
0
11
HeatWave on AWS という選択肢を検討してみる
hmatsu47
PRO
0
6
HeatWave on AWS のインバウンドレプリケーションで HeatWave エンジン有効時のレプリケーションラグを確認してみた!
hmatsu47
PRO
0
16
CloudWatch Database Insights 関連アップデート
hmatsu47
PRO
0
28
さいきんの MySQL との付き合い方 〜 MySQL 8.0 より後の世界へようこそ 〜
hmatsu47
PRO
0
29
ベクトルストア入門
hmatsu47
PRO
0
25
Aurora DSQL について
hmatsu47
PRO
0
27
Other Decks in Technology
See All in Technology
Delegating the chores of authenticating users to Keycloak
ahus1
0
120
AIの最新技術&テーマをつまんで紹介&フリートークするシリーズ #1 量子機械学習の入門
tkhresk
0
140
Amazon S3標準/ S3 Tables/S3 Express One Zoneを使ったログ分析
shigeruoda
4
540
セキュリティの民主化は何故必要なのか_AWS WAF 運用の 10 の苦悩から学ぶ
yoh
1
170
M3 Expressiveの思想に迫る
chnotchy
0
110
Liquid Glass革新とSwiftUI/UIKit進化
fumiyasac0921
0
230
データプラットフォーム技術におけるメダリオンアーキテクチャという考え方/DataPlatformWithMedallionArchitecture
smdmts
5
640
監視のこれまでとこれから/sakura monitoring seminar 2025
fujiwara3
11
3.9k
標準技術と独自システムで作る「つらくない」SaaS アカウント管理 / Effortless SaaS Account Management with Standard Technologies & Custom Systems
yuyatakeyama
3
1.3k
GitHub Copilot の概要
tomokusaba
1
130
OpenHands🤲にContributeしてみた
kotauchisunsun
1
460
本が全く読めなかった過去の自分へ
genshun9
0
550
Featured
See All Featured
It's Worth the Effort
3n
185
28k
Java REST API Framework Comparison - PWX 2021
mraible
31
8.6k
Measuring & Analyzing Core Web Vitals
bluesmoon
7
490
The Pragmatic Product Professional
lauravandoore
35
6.7k
Designing Experiences People Love
moore
142
24k
Rebuilding a faster, lazier Slack
samanthasiow
82
9.1k
Why You Should Never Use an ORM
jnunemaker
PRO
57
9.4k
Faster Mobile Websites
deanohume
307
31k
[RailsConf 2023] Rails as a piece of cake
palkan
55
5.6k
What's in a price? How to price your products and services
michaelherold
246
12k
The Cult of Friendly URLs
andyhume
79
6.5k
Unsuck your backbone
ammeep
671
58k
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