「レイテンシって何？？？」から始めた調査が楽しかった話

はじめに

今朝CIの実行時間短縮タスクが終わり、「ふぅ。エンジニアの生産性向上に寄与したったわ」なんて思ってたら次のタスクはパフォーマンスチューニングと言い渡されました。
レイテンシーが高まっているAPIがあり、原因を調査してください。と課題を課せられました。

ぶっちゃけ画像がボトルネックだと聞いていたので(フォーム内に最大3つS3にアップロードする処理があり、、)、そうなんだぁと先入観はありつつ、「メモリプロファイラやパフォーマンス計測をして、どの処理がボトルネックかを調査する」というタスクだったので、ちゃんと調べました。

レイテンシーってアラートがslackに届いてるのは見てたけどなんなんやろ？って感じだったので、「私本当にわかんないですよ？？」って言った。笑
ぶっちゃけこういうのシニアエンジニアの仕事なんだけど、あかねさんならできると思うから頑張れと。はぁ〜い！！！！時間もらいま〜すってなりつつ着手！！！

確認したこと

ちょくちょくインフラのタスクを中心に入っている強強エンジニアがAWSのcloud watchにいい感じのダッシュボードを作ってくださっていて、そこをまず確認しました。
一旦私が確認したのは以下の3つです。

• ALB のレイテンシ

• ECS の CPU 使用率

• ECS のメモリ使用率

ALB のレイテンシ

まずこれが何？って感じだったんですがw
こういうのはAIの使いどきですよね！便利な時代だぁ〜！！！

「猿にもわかるように教えてくれん？」って教えてもらいました。

そして、レイテンシとはアプリケーション内の処理にかかった時間のこと

WAF通過してALB(ロードバランサー)がRails(ECS)にリクエストを送ってからRails(ECS)がレスポンスを返してALBがそれを受け取るまでの時間を計測しているとのこと。
そういってくれたらわかりますわ。
つまり、

ALB → Rails → ALB の往復時間

ってことです。OK、完全理解。

ちなみにALBもわかんなかったので教えてもらいました。

Application Load Balancer（ALB）＝ HTTP/HTTPS レイヤーのロードバランサー
クライアントからリクエストを受けて、「あぁ、それならECSにあるRailsのアプリケーションだね！お〜い！リクエストきたよ〜！！」とRailsを呼び出して、Railsからのレスポンスをクライアントに返してくれるレイヤーです。

ECS の CPU 使用率

CPUって聞くけどよくわからない。調べました。

CPUの使用率ではロジックの重さが測れます（計算処理の重さ）。
ループ処理などで計算が重いとここの数値が上がるようです。

CPUが上がる例

• 大量の配列を map / each

• JSON を組み立てる処理

• MiniMagick などの画像変換

• bcrypt など暗号化

• 大量の Ruby オブジェクト生成

• 計算系のアルゴリズム（ソート、重い数値処理）

確かに処理重そう！って内容で理解できました！！！

ECS のメモリ使用率

アプリケーションが一時的に抱えるデータの量（変数や定数で扱う時など）
大きすぎるとGC(ゴミ処理)が発生して処理が止まり、レイテンシが上がる。

メモリが増えやすいパターン

• 巨大JSON返してる

• ActiveRecord が大量に生成される（N+1の後遺症）

• 大量のファイル読み込み

• 10MB以上の画像読み込む

• バッチ処理が巨大

• ループで配列作りまくる

CPUは「アプリが処理してる時間」。メモリは「抱えてるデータ量」。全く別物ですね。

CTOは画像をフォームデータで送ってるからこのメモリが増えてて、レイテンシーが高まってるのでは？と想像していたようでした。

ただ見てみると、CPU使用率は高くない。メモリの使用率もそんなに高くない！でもレイテンシが高い！！！そんな状況でした。

わかったこと

今回のレイテンシ上昇の“真因”は、Rails が S3 アップロードを同期で待たされていたこと。

CPUが上がらないのにレイテンシが高い場合は、アプリ計算ではなく「外部I/O待ち（S3・DB・外部APIなど）」で止まっている可能性が高いようです。

→外部処理(外部I/O)の待機時間、つまり今回のパターンだとS3への画像アップロードを最大3回していることがレイテンシをあげている可能性大！！！
画像処理は同期的に最大3回しているので。

つまりアプリは重くなっていない。
待たされているだけだから遅く見えていた、というシンプルな話でした。

じゃあどうする？？

画像のアップロードをサイドキック(非同期処理)にする！！！
同期的にするから待機しているだけの時間がかかっちゃってるわけですもんね、待たなきゃいいってことですね。

あくまでレイテンシーはRailsのアプリケーション層内での実行時間なので、非同期処理にしてレスポンスだけ先に返しちゃう！って方針で改善することになりました！
失敗した時の処理とかトランザクション内での処理だったから考慮事項はありますが、パフォーマンスの改善には絶対なるのでサイドキックでOKってなりました。

次のタスク

画像のアップロードをサイドキックにする仕様変更の設計です！
サイドキック実装したことないし(話には聞いてるので使い時なのはわかった)設計も初めてなので頑張ります！！！

おわりに

新しいことができて楽しいです！！！
CIの時もそうだったんですが、パフォーマンスチューニングってめちゃ楽しい領域感を感じています🔥

CPUとかメモリの解像度も上がりました！！
見えんし。何言ってんのやらって思ってたんですが(ごめん)、やはり机上の空論感なく実務でイメージしやすい状況のことが大事かもです。(私学習を視覚で画像認識のようにするタイプです。)

早く実装できるように設計頑張ります！！！