『データ分析基盤を作ってみよう　～性能設計編～』というタイトルで勉強会を開催しました

　こんにちは、佐々木です。NRIネットコムの社外向け勉強会で、「データ分析基盤を作ってみよう　～性能測定編～」というタイトルで登壇してきました。その前に設計編というテーマで開催しており、今回はその続きです。アーキテクチャ設計をする上でAWSのサービスをどういう観点で評価するのか、またその裏付けを取るためにどうしているのかというのを実際の測定例とともに話しました。

発表資料と当日の動画

　当日の発表資料と動画です。

speakerdeck.com

www.youtube.com

アーキテクチャの選定について

　アーキテクチャ選定の部分で取り上げたのが、BIツールでダッシュボードを作ってデータを可視化する例です。セッション中も話していたのですが、アーキテクチャの選択肢は沢山あります。そんな中でどうやって選ぶかなのですが、ここで取り上げた例はユーザーがどういう属性の人なのかということです。
　例えば、ダッシュボードを使う人が経営や営業のような属性の人であれば、じっくり見て分析というよりパッと見て瞬時に判断できるようにすることが求められるでしょう。そのためには、画面の表示も1秒でも早く見えるようにすべきです。これに対して、利用者が分析者などであれば、表示の速度が多少遅くても許してくれます。それよりも、柔軟な集計ができることや、より大規模なデータを分析できるというのが重視されるでしょう。
　また、そもそもの話で利用者数が数人～数十人なのか数百～数千人でも、全然サービス選定の基準が違ってきます。少人数の場合はリソースをAWSに管理してもらう従量課金制のマネージド・サービスの方が有利なケースが多いです。逆に大人数での利用の場合は、インスタンスなりを確保して作った方が割安になることが多いです。一方で大規模の場合は、ちゃんとスケールするのかなど考えるべきところが増えます。

性能測定について

S3標準エンジンでAthenaの性能測定

　まずはS3標準エンジンでAthenaの性能測定です。表を見ていただけると解るのですが、面白い特徴があります。1つあたりのファイルサイズが極端に大きい場合と、小さい場合に性能劣化が顕著です。これは、AthenaとS3のアーキテクチャに起因していると考えられます。
　まずファイルサイズが大きいケース（1ファイル10GB）です。Athenaの内部のエンジンは、Trino（旧Presto）とのことです。Trinoは分散型SQLクエリエンジンで、その名の通り分散して処理します。処理対象のファイルが少数の場合、そもそも分散して処理できないという問題があります。圧縮してあるCSV・GzipやParquetは、（内部構造は把握していませんが）大きなファイルになると解凍処理に非効率な部分がでているようです。
　逆に小さなファイル（1千万ファイル1KB）の場合はファイル転送のオーバーヘッドが大きいと推測できます。S3はオブジェクトストレージかつオンラインストレージです。1つのオブジェクトを取得するごとに、通信が発生します。データの実転送の部分は省いたとしても、1千万回の通信処理をするのと、数百回の通信処理をするのでは効率が全然違います。
　この事からも、適切なファイルサイズにまとめることの重要性が解ります。Athenaの用途として、ログファイルを手軽に分析をしたいというケースが多いです。CloudFrontのログのように、小さなファイルが大量に発生する場合は、実はAthenaは向いていないので、まとめた方がよいです。（S3のAPIリクエストコストも高く付きます）

S3 Express One Zone

　それでは、お待ちかねのS3 Express One Zoneです。こちらは、S3標準エンジンとS3 Express One Zoneそれぞれで、アップロード・ダウンロードの速度と、そのデータをAthenaで分析した場合の速度を比較しています。S3の性能自体は、Express One ZoneになるとAWSの発表通りに３～４倍の改善が見られます。1 Zoneの場合の方がアップロード時間が早いのは、おそらくアップロード後の複製がネットワーク的に近いためだと思います。逆にダウンロードの場合は内部的に１つの場所から取得するので、本来変わらないはずです。が、API的な工夫をしているのではないかなと想像できます。（内部的な実装は闇の中なので、理由は解りませんが）

　一方で上記のケースは、最初に評価したS3標準エンジン＋Athenaのケースで悪手とした小さい、かつ大量ファイルでの評価です。これを適正なファイルサイズ（100MB、100ファイル）で評価したらどうなるのでしょうか？下記の結果となり、性能差はかなり縮まっています。ダウンロードにいたっては、同じレベルです。APIリクエストの回数が少ないので無視できる範囲になっており、このことからもExpress One Zoneは同じAZに配置する点以外にも、APIリクエストの呼び出しが何らかの方法で早くなるように改善されていると推測できます。（あくまで推測で、かつ全体に適用できないのは何故だろうという疑問は残ります。）

CloudFrontにログのフォーマット指定とパーティション機能の追加

　勉強会実施時にはなかった機能なのですが、2024年11月21日に注目の機能が発表されました。CloudFrontにログのフォーマット指定とパーティション機能が追加されました。今回の検証でS3とAthenaの弱点は、アーキテクチャの特性として小さいファイルに弱いというのがあります。その解消策として、小さいファイルをまとめて圧縮するのが有効なのですが、これまではLambda等を使って自前で実装する必要がありました。
　今回の発表によりCloudFrontの機能として、ログファイルをParquet等にまとめた上で出力することが可能になったそうです。小さなファイルで大量に出力される形式のログファイルの課題が解決されますね。さすが、AWSさんです。利用者の困っている部分に、ちゃんと対応してくれていますね。ついでに、この機能をS3の機能の一つに取り込んでほしいものです。

aws.amazon.com

まとめ

　実はこの記事、随分前に書いて公開を忘れていました。最後のCloudFrontのアップデートのお陰で思い出すことができて、無事世の中にリリースできました。ありがたいかぎりです。
　性能測定というと、EC2やRDSに目が行きがちです。一方で、AWSが作成したサービスの性能特性をしっかりと把握することで、最適なアプリケーション設計が可能となります。性能測定自体も簡単にできるようになっているので、ぜひ気になったら自分で確かめてみる習慣をつくってみてください。その積み重ねが、エンジニアとしての自分の成長につながるはずです。
　なお、性能測定の実施方法の詳細は、下記のサイトに記載しています。あわせて参照して頂くと幸いです。

cloud.nri-net.com

執筆者 佐々木拓郎

Japan AWS Ambassadors
ワイン飲みながら技術書を書くのが趣味なおじさんです

Twitter：https://twitter.com/dkfj

Facebook：https://www.facebook.com/takuro.sasaki

個人ブログ：https://blog.takuros.net/

Amazon著者ページ：Amazon.co.jp：佐々木 拓郎:作品一覧、著者略歴

Booth：https://takuros.booth.pm/

コーポレートサイト：https://www.nri-net.com/

ソリューションサイト：https://cloud.nri-net.com/