こんにちは、佐々木です。
2023年10月30日のJAWS-UG東京 ランチタイムLT会 #4に登壇してきました。
テーマは、パフォーマンス測定とアーキテクチャ設計です。
発表資料と当日のアーカイブ動画
お伝えしたかった事
メインのテーマとしては、アーキテクチャ設計をする上で、実際にパフォーマンスを測定することの重要さです。経験が無い方も多いと思うので、あわせてパフォーマンス測定の仕方についても解説をしたかったです。こちらは時間の都合上、あまりできなかったです。どこかで、その手法に特化した発表をしてもよいかもですね。そして何より、パフォーマンス測定は、目的と条件設定次第ということも伝えたかったです。しかし、こちらは殆ど説明できなかったので、少し補足させて頂きます。
資料に対する補足
この資料だけ公開すると数字が独り歩きしそうなのでで、それぞれ補足です。なお、計測した条件および用いたプログラムについては、下記のサイトに掲載しています
検証レポート.：Athenaにおけるファイルサイズが性能に与える影響 | NRIネットコムのクラウドソリューション cloud.nri-net.com
Athenaの測定結果について
ファイルサイズによってパフォーマンスが大きく変わることを例示する目的で、極端な例でのサンプルデータを用意しています。通常の分析のケースだと1KBは不要だと思いますが、CloudFrontのログをそのまま分析したら、小規模サイトだったらありえるかなと思って用意しています。また、流しているクエリーのパターンやデータフォーマットも、パフォーマンス分析としては不十分です。ファイルサイズが与える影響が検証目的なので、そのあたりはご留意ください。
検証に掛かった費用について
S3に掛かったコストの大部分は、1KBのデータ測定のためです。感想の中で、パフォーマンス測定にはお金が掛るのだなと印象を持った方が多かったようですが、1KBを除くとおそらく数10ドルくらいで収まっていたはずです。EC2のコストについては、サイズが大きなものを立ち上げっぱなしにしていた影響です。これも1KBの検証をしなかったら、数ドルくらいで終わっていました。（10月末期限のクーポンが余っていたので、あまり気にせず使っていました）
ファイルサイズが小さい圧縮ファイルのパフォーマンスが悪い理由
1KBのパフォーマンスが極端に悪いです。これはAthenaの処理性能の問題というより、ファイルの転送待ちの時間とほぼほぼ断定できます。それに加えて、CSV（GZIP圧縮）やParquet（Snappy圧縮）のパフォーマンスが極端に悪いです。この理由は、解凍処理の時間影響です。本来であれば、この辺りを断定できるように、ファイル転送に対する計測も行うべきです。今回は時間の関係で省略していますが、後日S3の転送時間とファイルサイズの関係の計測も行う予定です。
※データを用意する段階で、ファイルサイズが小さくなると転送効率が悪化するのは確認できていますが、ちゃんとした計測ができていません。
性能測定の結果を公表する是非
頂いた感想の中で、こういった性能測定の結果を出してくれればというのもありました。その気持も解るのですが、なかなか難しいというのが現実です。性能測定については、前提条件や計測の目的・仕方によって、結果が全然違ってきます。AWSを始めとするクラウド事業者自身が、その条件をしっかり説明した上で、誤解のないように公開するのは至難の技だと思います。ましてや、比較という形は更に難しくなります。
一方で文章の情報で、Athenaを使う際は適切なサイズにファイルを分割して利用するのがベストプラクティスと定義していても、適切なサイズって一体どれくらいなんだとなります。今回のように極端な例で性能測定をすると解りやすいという反面、変に誤解される危険性も大きいです。そのため、細心の注意が必要との認識です。公開された性能情報については、参考情報くらいで捉えてくれると嬉しいというのが本音です。公開の仕方も含めて、もう少し模索していく予定です。
まとめ
最近、マネジメントや抽象的な話をすることが増えてきました。自分の手を動かして検証する機会も減ってきたので、敢えてひたすら検証する内容をテーマに選びました。自分で手を動かすと、やっぱり気づくことも多いです。AWSのアーキテクチャについては、鉄板の構成があるのも事実です。一方で、データや利用形態によって、別の構成を取ったほうがよいこともあります。そういった事を、半日くらい手を動かして検証するという習慣をつけると、実際の構築の時にハマることがグッと少なくなります。ぜひぜひ習慣化してください。
NRIネットコムのソリューションサイトでも、検証した結果は今後も随時掲載していく予定です。乞うご期待ください。
