【要約】LambdaからS3 Filesを使った時の読み書き速度を検証してみた [Qiita_Trend] | Summary by TechDistill
> Source: Qiita_Trend
Execute Primary Source
// Problem
Lambda開発者が、S3上のデータを扱う際に最適なアクセス手法を選択できず、実装コストと性能のバランスに苦慮していた。具体的には以下の課題が存在する。
- ・S3 SDKはシンプルだが、ファイルパスを要求する既存ライブラリを流用しにくい。
- ・Amazon EFSは高機能だが、構成の複雑さやコストのオーバーヘッドが大きい。
- ・新機能であるS3 Filesが、実際のワークロードでどの程度の性能差を生むかが不明確であった。
// Approach
筆者が、S3 Filesの性能特性を明らかにするため、S3 SDKを用いた従来方式との比較実験を行った。検証は以下のステップで実施された。
- ・「非VPC + S3 SDK」と「VPC + S3 Files」の2構成を用意した。
- ・64KiB（小）と16MiB（大）のファイルサイズで、読み書きの速度を測定した。
- ・「同一ファイルの連続読み込み」と「毎回異なるファイルの読み込み」の2条件で比較した。
- ・CloudWatch Logs Insightsを用いて、p50やp99などの統計値を算出した。
// Result
検証の結果、用途に応じて最適な構成が明確に分かれることが判明した。開発者は以下の指標に基づき、構成を選択できる。
- ・小ファイル（64KiB）の読み込み：S3 FilesがSDKに対し、p50で約12〜23倍高速である。
- ・大ファイル（16MiB）の逐次読み込み：S3 SDKの方が高速かつ、p99のレイテンシーが安定する。
- ・書き込み処理：小ファイルではS3 Filesが速いが、S3への同期タイミングが異なる点に注意が必要である。
Senior Engineer Insight
> 性能特性が極めて明確だ。小規模な設定ファイルや、AIエージェントの作業ディレクトリのような「小ファイルの頻繁な参照」にはS3 Filesが極めて強力な武器となる。一方で、大容量データのストリーミング処理にS3 Filesを導入するのは、性能面で逆効果となるリスクがある。また、S3 Filesの利用にはVPC構成が必須となるため、ネットワーク設計の複雑化とコスト増を許容できるかが判断基準だ。単なる「新機能だから」という理由での採用は避け、データサイズに基づいた合理的な選定を徹底すべきである。