メドピア開発者ブログ

集合知により医療を再発明しようと邁進しているヘルステックカンパニーのエンジニアブログです。読者に有用な情報発信ができるよう心がけたいので応援のほどよろしくお願いします。

YJIT有効化後にUnicornワーカーを増やした場合の各メトリクスの推移について

はじめに

こんにちは。サーバーサイドエンジニアの冨家(@asahi05020934)です。現在は、全国の医師が経験やナレッジを 「集合知」として共有し合う医師専用コミュニティサイト「MedPeer」の開発を行っています。

Ruby 3.2からYJITが実用段階になりました。「MedPeer」でもパフォーマンスを改善するためにYJITを有効化することになりました。

本番環境でYJITを有効化後、ECSサービスのMemory Utilizationに余裕があったので、ECSサービスのUnicornワーカー数を増やすことを検討しました。 しかし、YJIT有効化後のUnicornワーカー数とメトリクスに関してまとめられた記事が少なく、どのように推移していくのか予想を立てるのは簡単ではありませんでした。YJIT有効化後にUnicornワーカー数を増やすと各メトリクスはどのように増減していくのでしょうか。

そこで、今回は「MedPeer」の本番環境でYJIT有効化後にUnicornワーカー数を増やしていった場合の各メトリクスの増減を明らかにしていきます。

計測した環境

以下の環境をもとに計測を行いました。

  • ECSタスク数: 8
  • Rubyのバージョン: 3.3
  • Railsのバージョン: 7.0.8.4
  • ECSタスクが使用するメモリ量: 8192MiB
  • ECSタスクが使用するCPUユニット数: 4096

手順

以下の手順に沿って計測していきました。

  1. Unicornワーカー数が96の日の0時0分から23時59分までのメトリクスを計測する
  2. Unicornワーカー数を96から104に増やす
  3. Unicornワーカー数が104の日の0時0分から23時59分までのメトリクスを計測する
  4. Unicornワーカー数を104から112に増やす
  5. Unicornワーカー数が112の日の0時0分から23時59分までのメトリクスを計測する
  6. 1と3と5の計測した結果を比較する

それぞれの計測日を「MedPeer」のサービスの１つである「Web講演会」の全配信の日程に合わせることで、リクエスト数やリクエストの内容に大きな差異が起きないように工夫しました。

計測すると、Unicornワーカー数112の時点でECSサービスのMemory Utilization Maxの最大値が84.23%まで上昇しました。 これ以上Unicornワーカー数を増やすと本番環境がダウンする可能性を危惧し、Unicornワーカー数を112まで検証することにしました。

結果

表1は、Unicornワーカー数96、Unicornワーカー数104、Unicornワーカー数112の各メトリクスの平均値を表したものです。

Unicornワーカー数96 Unicornワーカー数104 Unicornワーカー数112
ECSサービスのCPU Utilization Avgの平均(%) 5.19 3.33 5.38
ECSサービスのMemory Utilization Avgの平均(%) 35.10 35.50 36.70
ALBのResponse Time p50の平均(ms) 50.00 51.00 48.00
ALBのResponse Time p90の平均(ms) 193.00 210.00 210.00
ALBのResponse Time p95の平均(ms) 317.00 380.00 327.00
ALBのResponse Time p99の平均(ms) 643.00 735.00 647.00
RDSのCPU Utilizationの平均(%) 5.32 4.15 5.87
レイテンシー p50の平均(ms) 　 41.10 40.80 39.90
レイテンシー p75の平均(ms) 　 68.40 68.00 68.50
レイテンシー p90の平均(ms) 　 150.30 159.00 154.00
レイテンシー p95の平均(ms) 　 255.50 289.30 253.10

表1 Unicornワーカー数96、Unicornワーカー数104、Unicornワーカー数112の各メトリクスの平均値

表2は、表1をもとに各メトリクスの変化率を計算したものです。

96から104の変化率(%) 104から112の変化率(%)
ECSサービスのCPU Utilization Avgの平均 -35.84 61.56
ECSサービスのMemory Utilization Avgの平均 1.14 3.38
ALBのResponse Time p50の平均 2.00 -5.88
ALBのResponse Time p90の平均 8.81 0.00
ALBのResponse Time p95の平均 19.87 -13.95
ALBのResponse Time p99の平均 14.31 -11.97
RDSのCPU Utilizationの平均 -21.99 41.45
レイテンシー p50の平均 　 -0.73 -2.21
レイテンシー p75の平均 　 -0.58 0.74
レイテンシー p90の平均 　 5.79 -3.14
レイテンシー p95の平均 　 13.23 -12.51

表2 Unicornワーカー数96、Unicornワーカー数104、Unicornワーカー数112の各メトリクスの変化率

考察

ECSサービスのCPU Utilization Avgの平均

計測結果

96から104の変化率は-35.84%であるのに対し、104から112の変化率は61.56%であることがわかりました。このことから、ワーカー数を上げることでECSサービスのCPU Utilization Avgは上がるとは限らないことがわかりました。

考察

直感に反する結果となりました。リクエストの負荷自体が少ない場合、ワーカーを増やしても処理するタスクが少ないため、CPU使用率はあまり上がらなかった可能性があると考えました。

ECSサービスのMemory Utilization Avgの平均

計測結果

ワーカー数を増やすたびに35.10%、35.50%、36.70%と増えています。このことから、ワーカー数を増やす程ECSサービスのメモリがより使われていくことがわかりました。

考察

直感通りの結果になりました。YJITはメタデータにもメモリを使用します。そのため、ワーカーを増やしてメタデータが増えたことで、メモリ使用量が増えることが考えられます。

ALBのResponse Time

計測結果

p50の平均はワーカー数を増やす度に50.00ms、51.00ms、48.00msとレスポンス速度が速くなっていることがわかりました。しかし、p90の平均、p95の平均、p99の平均はワーカー数を上げる度に速度が上がっていないことがわかりました。このことから、ワーカー数を上げることで、基本的なレスポンス速度は速くなるが、遅めのレスポンスは速度が速くなるとは限らないことがわかりました。

考察

p50の平均以外は、直感に反する結果となりました。p90以上ではネットワークの遅延が影響し、一部のリクエストが遅くなる可能性があると考えました。

RDSのCPU Utilizationの平均

計測結果

96から104の変化率は-21.99%であるのに対して、104から112の変化率は41.45%であることがわかりました。このことから、ワーカー数を上げることで、RDSのCPU Utilizationの平均は上がるとは限らないことがわかりました。

考察

直感に反する結果となりました。ワーカー数を増やしても、発行されるクエリがシンプルで、CPUを大量に使用しない場合、RDSのCPU利用率は上がらなかった可能性があると考えました。

レイテンシー

計測結果

p50の平均は、ワーカー数を上げるたびに41.10ms、40.80ms、39.90msと速くなっていることがわかりました。しかし、p75の平均、p90の平均、p95の平均はワーカー数を上げる度に速度が速くなっていないことがわかりました。このことから、ワーカー数を上げることで基本的なレイテンシーは速くなるが、遅めのレイテンシーは速くなるとは限らないことがわかりました。

考察

p50の平均以外は直感に反する結果となりました。高パーセンタイルのレイテンシーには、ネットワークの遅延や一時的な輻輳が影響することがあるので、順当に速くなっていかなかった可能性があると考えました。

結論

以上、「MedPeer」の本番環境でYJIT有効化後にUnicornワーカー数を増やした場合の各メトリクスの増減を明らかにしていきました。その結果、ワーカー数を増やすことで、「ECSサービスのMemory Utilization Avgの平均」は順当に増えていき、「ALBのResponse Time p50の平均」と「レイテンシー p50の平均」は順当に速くなることがわかりました。これは、Unicornワーカー数を増やすことでアプリケーションのメモリ使用量は増えていき、基本的な速度は改善していくということでしょう。

しかし、他のメトリクスはワーカーを増やすことによって順当に変化していきませんでした。より正確な原因については明らかになっていないので、今後の課題にしたいと思います。

最後に

今回の記事の他にもYJITに関連がある記事を執筆しているので、興味がある方はぜひ読んでみてください。

是非読者になってください

メドピアでは一緒に働く仲間を募集しています。 ご応募をお待ちしております！

■募集ポジションはこちら medpeer.co.jp

■エンジニア紹介ページはこちら engineer.medpeer.co.jp

■メドピア公式YouTube　 www.youtube.com

■メドピア公式note
style.medpeer.co.jp