ファイルサイズは馬鹿にできない
Amazon S3
テーマはファイルサイズ
皆様、こんばんは。sanbongawa(Shu Kawanishi)です。
部分的に提案対応をしたことがありますが、自分の環境ではなかなかできない。（金銭的な意味で）
データレイクとして利用されるS3について記載していきたいと思いますが、テーマはファイルサイズです。
はじめに：Amazon S3のなにを深堀？
大量のログデータやIoTデータのように、数KB〜数MBの小さなファイルがS3に集められている。
そのS3に対するパフォーマンスやコストに関する「隠れたボトルネック」が今回の深堀テーマです。
隠れたボトルネック、「 "small file problem" 」ってなんだ？
そして、この問題を解決する魔法の「128MB」という数字を追ってみた！！
1.小さいファイル問題（Small File Problem）の被害
「小さいファイル問題（Small File Problem）」がいかに厄介なのか？
APIオーバーヘッドの増大と見えないコスト
S3にデータを保存、読み取り、表示をする操作は、すべてAPIコールとして実行されます。
これ、オブジェクトのサイズに関わらず、1回あたりの料金が発生するんです。
○○詰め放題。コスパを意識する人ならわかるはず。
バケツ一杯に1データ。
バケツ一杯に100データ。
同じバケツ一杯のデータでもAPIコール数は100倍！！！
つまり金額も100倍！！！
地味ですが、これが積もり積って無視できないコストになるんです。
メタデータ処理のボトルネックとクエリの遅延
S3に大量の小さなファイルがあると、S3内部のメタデータシステム（オブジェクトのインデックス情報など）に対するボトルネックになります。Amazon AthenaやApache Sparkのようなデータ分析ツールがS3上のデータを処理する際、どんな種類のデータが、どのようにパーティション分割されていて、どのファイルを利用するか決めてからこんな感じで処理しようという計画します。
多数の小さなファイルがある場合、このメタデータ処理のステップが長くなり、クエリの実行開始が遅れたり、全体の処理時間が伸びてしまうんです。
通信のオーバーヘッドが多くなる
各S3オブジェクトへのアクセスは、ネットワークを通じて行われます。ファイル一つ一つに対してネットワーク接続の確立、HTTPリクエスト/レスポンスのやり取り、データ転送という一連のプロセスが発生します。小さなファイルが大量にあると、この「やり取り」が多くなり、実データの転送量に比べて「通信のオーバーヘッド」が大きくなります。
並列処理の無駄遣い
データ分析ツールの分散処理エンジンは、複数のタスクを並列に実行することで、大規模データを高速に処理します。しかし、小さなファイルが多すぎると、以下の問題が発生します。
- タスク起動・管理のオーバーヘッド: 各ファイルに1つのタスクが割り当てられる場合、タスクの起動や管理にかかる時間が、実際のデータ処理時間よりも長くなる。
- リソースの非効率利用: 各タスクが処理するデータ量が少なすぎて、CPUやメモリといった計算リソースが十分に使われない。
これらの問題が小さいファイル問題（Small File Problem）によって作られる被害です。
2.「128MB」という数字
「128MB」という数字が、この小さいファイル問題を解決するポイントになります。
まずここでこのデータを大きさだったら良いかというとそうではない。
これが下限だと理解することで効率的になります！
HDFSから引き継いだ？？
ちなみにこの「128MB」という数字を調べていくと、オンプレミスよく利用されているHadoop Distributed File System (HDFS) にたどり着きます。HDFSでは、データを小さなブロックに分割し、複数のノード（サーバー）に分散して保存します。これにより、単一のサーバーでは処理しきれないような巨大なデータセットを扱うことができます。その時のデフォルトのブロックサイズが、128MBに設定されてきました。
Apache SparkといったHDFS上で動作する分散処理フレームワークは、このHDFSのブロックサイズをデータ処理の「単位」として見なすことが多いため、自然と「128MB程度のファイルサイズが効率的である」という考え方になったっぽいです。
HDFSの代わりにS3をストレージとして利用することが増えたこともあり、S3上のデータレイクにもこの考え方が引き継がれたんだろうなと想像します。
列指向フォーマット（Parquet/ORC）でさらなる効果が！
Apache ParquetやApache ORCといった「列指向フォーマット」も計算･データ容量を節約することができるポイントになるため、データのファイルサイズとは異なりますが、重要なファクターです。
今回はテーマと異なるためここの内容は割愛します。
3.「128MB」のメリット
メリットは、端的に話すと速度とコストの同時改善ができるところです！
クエリパフォーマンスの向上
最も分かりやすいメリットは、データ分析クエリの実行時間の短縮です。
Amazon AthenaやApache Sparkなど、S3上のデータを処理するクエリエンジンは、ファイルサイズが適切に最適化されていると、データスキャン量が削減され、並列処理が効率化されるため、クエリ処理が高速化します。
「Amazon Athena のパフォーマンスチューニング Tips トップ 10」でも、ファイルサイズ最適化がクエリ実行速度に直接影響すると記載があるので必須ですね。
Amazon Athena のパフォーマンスチューニング Tips トップ 10
S3コストの削減
見えないコストへの対応がポイントですね。
小さなファイルを大きなファイルに集約することでオペレーションの数を削減できるわけです。
あとファイルのサイズを変更することで副次的な効果が実はあります。
128KB未満のオブジェクトでも、128KB分のストレージとして課金ですね。
これは知らない人も多いでしょう。
小さなファイルが無駄に費用が掛かっていたがなくなるポイントですね。
4. 「128MB」を目指すにはどうしたら良いか
やはり、めんどくさがりの私としては自動化ですよね。
ただ自動化を進めるだけだと実際の運用には合わないのでここはこの観点で不要だろうというのはメモしてアーキテクトします。
アーキテクチャの全体像
結論としては、S3 Batch OperationsとLambdaでコンパクションを自動化するとしました。
登場人物
- Amazon S3 Batch Operations
- AWS Lambda
- Amazon S3 Bucket
- Gateway Server
Amazon S3 Batch Operationsは、S3バケット内のオブジェクトに対して、指定された操作を一括で実行できるサービスです。
他にもStep Functionを組み立てることで実施できる複雑な構成もありますが、ファイルサイズによるコストダウンなどもテーマに包括されているのであえてコスト増になるアーキテクトは今回は除外します。
アーキテクチャ
このような構成がGateway Serverを含めた汎用的な目的では良いと考えます。
各工場などからのログ情報を集めてアップロード分析するためのデータを収集するまでを目的とします。
動きのイメージとしては以下の流れです。
考察としてポイントを記載。
オンプレミスGatewayサーバ
↓ (ファイルアップロード)
S3バケット (Source)
↓ (S3イベント通知: ObjectCreated)
EventBridge
↓ (EventBridgeスケジュール実行: 定期実行)
Lambda関数 (Batch Job Creator)
↓ (S3 Batch Operationsジョブ作成APIコール)
S3 Batch Operations
↓ (マニフェストファイル参照)
S3バケット (Source) のオブジェクト群
↓ (Lambda Invokeオペレーション)
Lambda関数 (Compaction Logic)
↓ (圧縮済みファイルを書き込み)
S3バケット (Processed)
↓ (S3 Batch Operations 完了レポート)
S3バケット (Report)
重要ポイント
オンプレミスGatewayサーバ
- S3へのアップロード数を減らすことを考慮
- 一時的にここである程度のサイズになるまでログを保管（ログロジック）
- ログロジック保管とデータのアップロードコストからStorage Gateway採用
- ゲートウェイへのデータ書き込み量に応じた料金（$0.01/GB、ただし月額最大料金あり）と、S3のストレージ料金が発生します。データ転送INは無料
EventBridge
- コンパクション実施でのタスク重複はデメリットになるためイベントドリブンはしない
Lambda関数 (Batch Job Creator)
- マニフェストファイル作成はLambdaで実行する ファイルの全量は拠点が増えるとGatewayで把握できないため
S3 Batch Operations
- 運用時の問題解決をスムーズに進めるためエラー制御と運用レポートを利用する
まとめ
いかがでしたでしょうか？
データ分析という点でのAmazon S3でのデータレイク活用におけるファイルサイズの最適化
この内容だけだったのですが、すごい文字数になってしまったので読んでくれた方はありがとうございます。この内容に関しては時間があるときに検証してその結果を入れて更新しようと思います。
Gateway Serverはスタブ的にな準備になるとは思いますが。
では、またお会いしましょう。
以上です。
Discussion