※この記事は自分が所属する組織で書いた以下の記事のコピーです。投稿した記事は個人の著作物として自ブログにコピーして良いルールとしています。

https://tech-blog.mitsucari.com/entry/2025/03/04/224422

---

こんにちは、ミツカリCTOの塚本こと、つかびー(@tsukaby0) です。

ミツカリはtoB向けのWebアプリケーションです。そのため、複数のユーザーが同時利用しますが、リクエスト数はtoCサービスやWeb広告、メディア、その他のtoB向けアプリケーションよりは非常に少ないです。

しかし、今回パフォーマンスをチューニング(レイテンシよりはスループット優先)する機会がありましたので、その取組について話します。

背景

ミツカリの利用者は主に企業に務める人事担当者や各部署のハイレイヤー、経営層などです。また、アプリケーション領域としてはHRです。そのため、常に利用されるようなサービスではなく、toCであったり、常に使われるCRMのようなtoBサービスとは異なり、HTTPリクエスト数は非常に少ないです。

私は前職はWeb広告のシステム開発だったので、データ量やリクエスト数は膨大でしたが、今はその頃に比べると大幅に少なくて少し物足りなく感じたりはしています。 ただし、パフォーマンスについて全く無関心で良いわけではなく、ある程度は考えることがあります。

最近とある開発によりbackend側にAPIが追加されましたが、このAPIは外部とのリクエストが必要であり、長いI/O waitが発生します。Ruby on RailsではWebサーバーにpumaがよく使われますが、これはマルチプロセスかつマルチスレッドのアーキテクチャになっています。pumaが同時に受け付けられるリクエスト数は worker数(プロセス数) * thread数 です。

もしそのI/O waitが長いAPIに複数のリクエストが同時に来た場合は、各スレッドが占有されてしまい、新しく来たリクエストは待たされます。新しく来たリクエストが軽いAPIだとしても待たされてしまう、ということが発生します。

対策

前述のような状況が発生した場合はサーバー全体のスループットが大幅に低下します。スループットとは単位時間当たりの処理能力であり、Web界隈では大抵は req/sec です。つまりは1秒あたりのリクエスト処理数です。

前述のような重いAPIだけが頻繁に使われるということはそうそう起きない想定ですが、pumaのスレッドを長く占有してしまうという状況は発生します。そこでサーバー全体のスループットを向上させる対策を施すことになりました。

ミツカリでは前述のようなビジネス・アプリケーション特性であるため、高いスループットは今まで必要とされておらず、パフォーマンスチューニングはされてきませんでした。今回はpumaを調整してスループットを上げます。

インフラリソース

ミツカリではECS Fargateを利用しておりbackendのRails docker containerには CPU 2048 が設定されています。これはvCPU 2個です。

pumaの設定は特に調整されてこなかったため、workerは1、threadは3です。これは調整の余地が大幅にありそうです。

※ worker数は未設定の場合はデフォルトではCPU数と同じ数になります。ただし、 WEB_CONCURRENCY 環境変数に設定がある場合はそれが使われます。ミツカリでは過去にHerokuからAWSに移行しましたが、そのときにこの設定が調整されなかったため、 WEB_CONCURRENCY は今まで1が設定されており、CPUリソースを無駄にしていたという状況になっていました(お恥ずかしながら)。

パフォーマンスチューニングの知識

まず、レイテンシとスループットの用語、意味について理解する必要があります。以下の資料が参考になります。

https://aws.amazon.com/jp/compare/the-difference-between-throughput-and-latency/

これはWebアプリケーションエンジニアにとっては基礎であるため是非覚えましょう。

私は昔はレイテンシとスループットをよく混同してしましました。latencyはlateだから遅さ・遅延、throughputはthroughだから通過数、みたいな感じで覚えました。レイテンシは高いか低いかで表し、低レイテンシであるほうが望ましいです。スループットも高いか低いかで表します。高スループットであるほうが望ましいです。

パフォーマンスチューニングという言葉は曖昧であるため、もし実施する場合は高スループットを目指すのか、低レイテンシを目指すのか、そのバランスを取るのかはよく考える必要があります。今回の私の場合はどちらかというと高スループットの比重が高いです。

また、Railsおよびpumaにおいて以下の資料もおすすめです。

https://railsguides.jp/tuning_performance_for_deployment.html

特にGILは重要です。 これはMRI(CRuby)において、Rubyインタプリタ内で同時に1つのスレッドだけがRubyのバイトコードを実行できる、という仕組みです。並列性やパフォーマンスチューニングする際には必ず知っておきたいことです。

これはつまりシステムに存在するendpointや負荷対象の処理のI/O waitの割合が多いならばうまく並列化されるが、I/O waitが少ないならば結局はほとんどの実行(Rubyコード)はシーケンシャルになってしまうということです。

上記の資料でも以下のように書かれていますね。

このため、アプリケーションがI/O操作に費やす時間が50%しかない場合、プロセスごとのスレッド数が2〜3個を超えるとレイテンシが大幅に悪化し、スループットが向上するメリットがたちまち目減りしてしまう可能性があります。

実際にはDBから単にシンプルなSQLを発行してデータを返す程度の処理であれば50%もI/O waitがないケースはあります。つまりスレッド数を増やしてもあまり意味がないケースがあります。これに対する対応も上記資料に書いてあります。素晴らしい解説ですね。

Rubyで真のパラレリズム（並列処理）を実現する方法は、複数のプロセスを利用することです。Rubyプロセスは、CPUコアが空いている限り、I/O操作の完了後に実行を再開する前に互いに待機する必要は生じません。 ただし、プロセスはコピーオンライトを介してメモリの一部のみを共有するため、プロセスが1個増えると、スレッドが1個増えるよりも多くのメモリが消費されます。

pumaではworkerとthreadをそれぞれ設定できます。つまり前述のような状況ではプロセスに相当するworkerを増やせばよいわけですね。

その他の注意事項

チューニングを行う前に他にもいくつか考えておくことがあります。

• そもそもI/O待ちが発生する外部接続の部分を高速化できないか
• N+1などのアプリケーションコード側の問題が起きていないか
• レイテンシ、スループット、CPU、Memoryなどはトレードオフなので、現状どこに余裕があって、何を優先するのか
• パフォーマンスチューニングの過程でサーバーに負荷をかけるが、負荷をかける側のマシンリソースに余裕はあるか。超大規模な負荷試験の場合はそもそも負荷をかける側にport数やCPU, Thread, 通信路などに制限があり1台では実現できない可能性があることを考慮する必要があるか
• 負荷をかける側とかけられる側の通信経路は十分に品質が高いか、また地理的、伝送経路的に近いか。意図的に遠くから実施する場合、遠さを考慮できているか
• CDNなどのキャッシュサーバーは存在しているか、それを考慮した負荷試験なのかどうか
• 対象の環境はロードバランスされているかどうか、またオートスケールの設定があるかどうか、それらの対象サーバーまでの間の要素が負荷試験に不要な影響を与えないかどうか。オートスケールを一時的に切る必要があるか
• 負荷をかけるシナリオをどの程度本番環境に近づけるか
• 負荷対象の処理のI/O waitはどの程度か
• DBのconnectionは足りているか、その他CPUなどDB側リソースがボトルネックになっていないか
• どのような負荷試験ツールを利用するか(e.g. wrk, vegeta, JMeter, ab)
• 試験中のリソース監視をどうやるか
• 負荷をかけるときに対象のプロセスが温まってるか考える。はじめの負荷試験の結果は捨てる

今回のミツカリでの負荷試験・事前準備

これらを検討また、ミツカリ社の環境などを鑑みて手順等を考えます。

まず、厳密なシナリオ検討はコストが大きくせいぜい半日でチューニングを終わらせたかったので、適当なシンプルなDBアクセスだけのWeb API(REST)を対象としました。

事前にそのAPIのI/O waitを調査します。これは弊社の場合はDatadog APMを入れているのでそちらで確認できます。

40ms程度のAPIですが、DBアクセス(SQL)は2回でせいぜい全体の10%です。その他は細かく見ていませんがRack等のMiddlewareの処理であったりControllerの処理であったりjson serializeの処理であったり、つまりはRubyコード(CPU)の処理でしょう。

基本的にはこのようなAPIが多いので、弊社の場合はスレッドを増やしてもあまり効果は無いと予想できます。ただし、冒頭に書いたとあるAPIについてはI/O waitが長いことが分かっているので、その場合はスレッドを増やすことで効果は得られそうです。

今回の場合大規模な負荷試験ではないですし、きっちりやろうとは思っていないので、負荷についてはlocalのmacbookで実行することにしました。

ツールについてはvegetaを利用することにしました。

https://github.com/tsenart/vegeta

社内で過去にインフラ担当者が利用した実績もありますし、それなりに有名なOSSでもあります。個人的には普段はwrkを使っていて、wrkの方が知名度もパフォーマンスも上なのですが、私の力が足りずにBasic認証を突破することができなかったので、今回は使わないことにしました。（ヘッダを設定できるはずなので、やれないことは無いと思うのですが、なぜか通らない・・・）

vegetaは上記のREADMEにも書いてありますが、brew等でインストールした後で以下のように使います。

$  echo "GET https://your_basic_auth_username:your_basic_auth_password@yourdomain/api/v1/foo" | vegeta attack -duration=60s -rate=200 | tee result.bin | vegeta report

Basic認証が不要な場合は your_basic_auth_username:your_basic_auth_password@ の部分は削除します。また、必要に応じてURLも変えてください。durationは負荷をかける時間でrateは1秒あたりのリクエスト数です。多すぎると捌ききれずにレイテンシが悪化したり5XXエラーになったりしますね。このあたりは実行時に上手く調整する必要があります。

対象環境は本番環境になるべく近づける必要があります。本番と異なるマシンサイズのもので負荷試験やパフォーマンスチューニングをしても意味がありません。 今回の場合はstg環境を利用することとしました。理由は他に環境を立ち上げるのが面倒だったのとprdと同じ性能であるためです。

手順

手順については以下の流れで実行することにしました(結構やってる最中に罠にハマったので、はじめから全部考えられていたわけではないです)。

1. 事前にAWSパラメータストア・環境変数等でworker数とthread数を動的に変更できるようにしておく
2. ECSのAuto scalingをOFFにする
3. ELBターゲットグループのヘルスチェックのタイムアウトを伸ばす
   1. 現状の設定ではタイムアウトは2秒になっており、負荷をかけている最中に応答が遅くなってタイムアウトにひっかかっていました。これによって対象のタスクが落とされては起動して・・・という感じで正確な計測を妨げる要因になっていました
4. 環境変数を設定する。ECS Serviceを強制デプロイでタスクを再起動して環境変数を反映し、workerとthreadを変える
5. vegetaで負荷をかける。初回のスコアは捨てて、２回目以降からスループットとレイテンシを計測する
6. DatadogやCloudwatchでCPUとMemoryを計測する
7. 結果を見て環境変数を変えて同じことを繰り返す。最適値を探っていく

計測結果

ECS Taskは1つとします。

1回目: worker 1, thread 1, -duration=60s -rate=100

まずは最小のリソースで実行します。以下はvegetaのレポートです。

Requests      [total, rate, throughput]         6000, 100.02, 20.14
Duration      [total, attack, wait]             1m30s, 59.989s, 30s
Latencies     [min, mean, 50, 90, 95, 99, max]  18.209ms, 14.255s, 10.018s, 30s, 30.001s, 30.001s, 30.029s
Bytes In      [total, mean]                     11556540, 1926.09
Bytes Out     [total, mean]                     0, 0.00
Success       [ratio]                           30.20%
Status Codes  [code:count]                      0:1926  200:1812  504:2262
Error Set:
504 Gateway Timeout

(当然ですが)これは酷いですね。結果については以下のように読み取ります。

• rate=100で秒間100リクエストの負荷をかけているが、実際にはthroughputは 20.14 しか出ていない
• Durationは -duration=60s としたため、本来は60sとなるのが正しいが、totalは 1m30s, waitが 30s となっている。つまり最後に送ったリクエストの応答が30秒も待たされているため、総合的なコマンド実行時間が 1m30s となっている
  • ※ waitがどうして10や20ではなく30なのかについてはCDNが30秒でタイムアウトする設定になっているためです
• Latencyのminは 18.209ms でこれは早いがレイテンシは最小を見ても意味がないので、P95やP99を見る。すると 30s なので応答できずにタイムアウトしていると考えられる。ちなみに95パーセンタイルは全リクエストを早い順にソートして上から95%の位置のものと理解すると簡単です。つまりP95が 30s なので、下位5%は30sより遅いという意味になります。P50は 10.018s なので下位50%は10sより遅いという意味になります。
• 2XX系で成功しているリクエストが 30.20% しかない

流石に1スレッドしか無いのにrate 100は厳しすぎたようです。

CPUとメモリもチェックしておきます。

CPUが25%、メモリが12%でまだまだ余裕はあるがリクエストを捌けていない状況ですね。

2回目: worker 1, thread 1, -duration=60s -rate=20

スループット20は出ているのでrate20に変えて実行してみます。

Requests      [total, rate, throughput]         1200, 20.02, 7.52
Duration      [total, attack, wait]             1m30s, 59.949s, 30.001s
Latencies     [min, mean, 50, 90, 95, 99, max]  26.97ms, 15.566s, 28.57s, 30.001s, 30.001s, 30.001s, 30.01s
Bytes In      [total, mean]                     4199988, 3499.99
Bytes Out     [total, mean]                     0, 0.00
Success       [ratio]                           56.33%
Status Codes  [code:count]                      0:524  200:676
Error Set:

成功率は増えましたがまだレイテンシが悪いですね。また、スループットもきっちり20出ていません。

3回目: worker 1, thread 1, -duration=60s -rate=5

Requests      [total, rate, throughput]         300, 5.02, 5.01
Duration      [total, attack, wait]             59.9s, 59.8s, 100.099ms
Latencies     [min, mean, 50, 90, 95, 99, max]  31.165ms, 58.66ms, 50.489ms, 100.943ms, 116.842ms, 160.547ms, 257.552ms
Bytes In      [total, mean]                     1863900, 6213.00
Bytes Out     [total, mean]                     0, 0.00
Success       [ratio]                           100.00%
Status Codes  [code:count]                      200:300
Error Set:

やっと安定しました。成功率100%でレイテンシはP95で 116.842ms ですね。悪くないです。ただし、スループットが5というのはあまりよろしくないです。

どうやら1スレッドではスループット5(rate5)程度が限界のようですね。

ただし、まだまだCPUもメモリもリソースに余裕はあります。次からはリソースを増やしてみます。

4回目: worker 1, thread 2, -duration=60s -rate=10

今度はスレッドを2に増やしてみます。単純に2倍なのでスループットは2倍になると予想できますが、GILのことを考えるとI/O waitが少ないのだからあまりスループットは高くならないとも思えます。実際はどうでしょうか。

Requests      [total, rate, throughput]         600, 10.02, 10.01
Duration      [total, attack, wait]             59.949s, 59.9s, 48.891ms
Latencies     [min, mean, 50, 90, 95, 99, max]  21.055ms, 34.137ms, 26.537ms, 48.15ms, 71.876ms, 156.854ms, 541.337ms
Bytes In      [total, mean]                     3727800, 6213.00
Bytes Out     [total, mean]                     0, 0.00
Success       [ratio]                           100.00%
Status Codes  [code:count]                      200:600
Error Set:

rate10でもP95のレイテンシが 71.876ms となかなか良いですね。スループットもrateの通り、しっかり10出ています。(あまり低レイヤは詳しくないですが、)当然ながらI/O waitはDBアクセスだけではありません。DB以外のネットワークI/OやディスクのI/OもI/O waitです。それらのお陰で上手く並列化できているわけですね。

なお、CPU使用率もメモリ使用率もほぼ変わりません。流石スレッドならメモリ消費を抑えられて良いですね。

また、rateを12や20にしても成功率は悪化するのでやはり1スレッドあたり5スループット程度という点は変わりません。

5回目: worker 1, thread 4, -duration=60s -rate=20

4スレッドだとどうでしょうか。

Requests      [total, rate, throughput]         1200, 20.02, 20.01
Duration      [total, attack, wait]             59.982s, 59.95s, 32.027ms
Latencies     [min, mean, 50, 90, 95, 99, max]  22.132ms, 37.205ms, 28.579ms, 54.218ms, 96.024ms, 178.459ms, 252.601ms
Bytes In      [total, mean]                     7455600, 6213.00
Bytes Out     [total, mean]                     0, 0.00
Success       [ratio]                           100.00%
Status Codes  [code:count]                      200:1200
Error Set:

まだ線形にスケールできていますね。スループットが20出ていますし、P95のレイテンシは 96.024ms です。

実際には1スレッドあたりスループット5ではなく、5.5ほどはありそうなので、そのあたりを考慮すると少し正確な計測ではないですが、一旦そこは目を瞑って次に行きます。

6回目: worker 1, thread 12, -duration=60s -rate=60

Requests      [total, rate, throughput]         3600, 60.02, 56.71
Duration      [total, attack, wait]             1m3s, 59.983s, 3.128s
Latencies     [min, mean, 50, 90, 95, 99, max]  29.244ms, 1.644s, 149.128ms, 838.605ms, 13.539s, 29.307s, 30.001s
Bytes In      [total, mean]                     22236327, 6176.76
Bytes Out     [total, mean]                     0, 0.00
Success       [ratio]                           99.42%
Status Codes  [code:count]                      0:21  200:3579
Error Set:

線形にスケールしなくなりました。成功率が100%ではないですし、P95のレイテンシが 13.539s とかなり酷いです。

流石に12スレッドもあるとGILによってRubyのバイトコードのシーケンシャル実行が増えて遅くなったのでしょう。

CPUとメモリについても見てみましょう。

CPUが使用率が上限100%に張り付いています。vCPUは2つあるので、最大は200%まで出ますが、workerは1つ(1 process)なので、100%が限度のようですね。 メモリについては12スレッドまで増やしても全然増えていません。スレッドのおかげですね。

7回目: worker 1, thread 8, -duration=60s -rate=40

一旦8スレッドまで下げてみます。

Requests      [total, rate, throughput]         2400, 40.02, 40.00
Duration      [total, attack, wait]             1m0s, 59.975s, 31.29ms
Latencies     [min, mean, 50, 90, 95, 99, max]  26.202ms, 174.883ms, 32.537ms, 108.147ms, 210.727ms, 4.936s, 7.338s
Bytes In      [total, mean]                     14911200, 6213.00
Bytes Out     [total, mean]                     0, 0.00
Success       [ratio]                           100.00%
Status Codes  [code:count]                      200:2400
Error Set:

12スレッドよりは良いです。スループットはrateと同じ40出ていますし、レイテンシはP95で 210.727ms です。遅いといえば遅いですが。ただ、P99は4秒超えなので悲惨な状況ですね。

どうやらスレッドとしては多くとも8程度が良さそうです。

では次にCPUを十分に使っておらずもったいないので、workerを増やします。

8回目: worker 2, thread 8, -duration=60s -rate=80

単純に空いているCPUを1つ使えるのでスループットは2倍は出そうです。

Requests      [total, rate, throughput]         4800, 80.02, 79.98
Duration      [total, attack, wait]             1m0s, 59.987s, 26.868ms
Latencies     [min, mean, 50, 90, 95, 99, max]  18.223ms, 27.829ms, 24.28ms, 32.18ms, 43.1ms, 111.211ms, 302.851ms
Bytes In      [total, mean]                     29822400, 6213.00
Bytes Out     [total, mean]                     0, 0.00
Success       [ratio]                           100.00%
Status Codes  [code:count]                      200:4800
Error Set:

予想通り2倍の80出ていますし、レイテンシもP95で 43.1ms なのでとても良いです。

ここで再度CPUとメモリを見てみます。

メモリはスレッドを増やすよりも増えていますね。1workerのときはせいぜい13%だったのが、2workerで26%程度まで増えました。メモリは4GBなので1workerあたり520MBくらいは使うようですね(もちろん処理の中でどの程度メモリを使うかによるが)。メモリ面ではthreadよりもだいぶ不利ですね。しかしthreadの方で頭打ちになっていたスループットを更に増やすことができました。

CPUは80%ほどですね。コンテナに入ってtopでも詳しく見てみます。

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND                                                                                        
   60 root      20   0 1002852 343192  14708 S  67.0   2.1   2:36.44 ruby                                                                                           
   54 root      20   0  997052 339352  14644 S   9.0   2.1   2:36.31 ruby                                                                                           
    7 root      20   0  943708 322332  30024 S   1.0   2.0   0:16.69 ruby   

PID 7はpuma clusterのmasterであるため別として、PID 54, 60がworkerです。しばらく観測してみましたが、片方しかCPU使用率が高くありません。CPUはまだまだ余裕がありそうです。つまりスループットはまだ上げられそうですね。

9回目: worker 2, thread 8, -duration=60s -rate=120

worker, threadは増やさずにrateを120(1.5倍)に増やします。これを捌き切れるでしょうか。

Requests      [total, rate, throughput]         7200, 120.02, 119.66
Duration      [total, attack, wait]             1m0s, 59.992s, 177.894ms
Latencies     [min, mean, 50, 90, 95, 99, max]  18.337ms, 59.373ms, 33.59ms, 127.55ms, 173.146ms, 320.585ms, 829.559ms
Bytes In      [total, mean]                     44733600, 6213.00
Bytes Out     [total, mean]                     0, 0.00
Success       [ratio]                           100.00%
Status Codes  [code:count]                      200:7200
Error Set:

良い感じです。この状態でCPUは120%ほどです。まだいけそうです。

10回目: worker 2, thread 8, -duration=60s -rate=200

Requests      [total, rate, throughput]         12000, 200.02, 118.84
Duration      [total, attack, wait]             1m19s, 59.995s, 18.952s
Latencies     [min, mean, 50, 90, 95, 99, max]  22.144ms, 7.422s, 139.376ms, 27.058s, 30s, 30.001s, 30.019s
Bytes In      [total, mean]                     58499718, 4874.98
Bytes Out     [total, mean]                     0, 0.00
Success       [ratio]                           78.18%
Status Codes  [code:count]                      0:1032  200:9382  504:1586
Error Set:

だめですね。スループットはrate200に対して120程度しか出ていませんし、P95のレイテンシは 30s です。これは厳しい。

CPU使用率は170%程度です。

ここでチューニングを終えてもよく、このサーバーのスループットは120と結論付けても良いのですが、もう少し試してみます。

11回目: worker 3, thread 8, -duration=60s -rate=180

workerを1つ増やします。worker2つでスループット120なので、1.5倍のrate180は捌き切れるでしょうか？とはいえvCPUは2つです。

Requests      [total, rate, throughput]         10800, 180.02, 126.64
Duration      [total, attack, wait]             1m13s, 59.994s, 13.022s
Latencies     [min, mean, 50, 90, 95, 99, max]  29.381ms, 6.675s, 186.03ms, 26.9s, 30s, 30.001s, 30.011s
Bytes In      [total, mean]                     57548895, 5328.60
Bytes Out     [total, mean]                     0, 0.00
Success       [ratio]                           85.62%
Status Codes  [code:count]                      0:816  200:9247  504:737
Error Set:

だめですね。スループットは増えていませんし、レイテンシが酷いです。 CPU使用率は180%ほどです。メモリは30%ほどです。やはりworkerを増やすと増えますね。

2回前のrate120ではどうなのでしょうか。

12回目: worker 3, thread 8, -duration=60s -rate=120

Requests      [total, rate, throughput]         7200, 120.02, 119.95
Duration      [total, attack, wait]             1m0s, 59.991s, 32.194ms
Latencies     [min, mean, 50, 90, 95, 99, max]  25.598ms, 59.969ms, 47.218ms, 92.397ms, 127.889ms, 276.961ms, 720.998ms
Bytes In      [total, mean]                     44733600, 6213.00
Bytes Out     [total, mean]                     0, 0.00
Success       [ratio]                           100.00%
Status Codes  [code:count]                      200:7200
Error Set:

誤差の範囲とも言えそうですが、2workerよりはレイテンシが改善しています。vCPUが2に対して3worker(3process)なので、その分コンテキストスイッチが発生してレイテンシは悪化しそうなものですが。どうしてこうなったかは詳しく考察できていません。

ただし、何度か測ると以下のようなスコアも出ます。

Requests      [total, rate, throughput]         7200, 120.02, 119.93
Duration      [total, attack, wait]             1m0s, 59.992s, 44.781ms
Latencies     [min, mean, 50, 90, 95, 99, max]  26.197ms, 352.23ms, 56.311ms, 167.694ms, 372.768ms, 11.355s, 14.252s
Bytes In      [total, mean]                     44733600, 6213.00
Bytes Out     [total, mean]                     0, 0.00
Success       [ratio]                           100.00%
Status Codes  [code:count]                      200:7200
Error Set:

P99が酷いですね。おそらくはGCでストップザ・ワールドしているのでしょう。

結論

9回目の

worker 2, thread 8, -duration=60s -rate=120

この設定が良さそうです。worker数は無難にvCPUと揃えつつ、thread数は8程度にすると1インスタンスで 120req/sec 程度のスループットを確保できることが分かりました。worker数も少ないのでメモリもだいぶ余裕があります。

まだ調整の余地はあるでしょうし、worker, threadの設定以外の調整も何かできるかもしれません。本番環境ではもっと多様なリクエスト・処理が発生するので、その状況を考えると最適でない設定という可能性や不安もあります。ただ、これ以上時間をかけたくないので、一旦はこの設定でやってみることにしました。

本番環境適用後のパフォーマンス

以下はパフォーマンスチューニングリリース前後の一部のメトリクスです。 Fri 21 を少し過ぎたあたりでリリースしています。

メモリ使用率が19%から32%ほどに増えていますが、これはworkerを1から2に変えたためですね。

P95レイテンシに関しては若干の改善がありそうです。これは今まではリクエストを受け付けられるスレッド数が足りていなかったため、ピーク時などは一部の処理が多少待たされていたのかもしれませんね。今回の対応で改善したのかもしれませんが、もうしばらく計測してみないとなんとも言えない部分はありそうです。

スループットについては、おそらく増えたはずですがそもそもprd環境に来るリクエストがそれほど多くないため、実際にどのような変化があったのかは計測できていないです。

本番環境適用後のパフォーマンス(その2)

リリース後しばらく経過したので再度パフォーマンス測定の結果を見てみました。

リリースした21日以降P95のレイテンシが改善しているように見えますね。まだまだピーク時間帯はレイテンシの悪化が見られますが。

今回はスループット目的の調整でしたが、レイテンシ面でも改善が見られて良かったです。

今回の負荷試験ではI/O waitが長いAPIを対象としていないので、そちらを対象とする場合はもっとスレッドを増やしたほうがパフォーマンスはでそうです。そのあたりのリアルなリクエスト状況に応じたパフォーマンスチューニングはより難易度が高いので次回の課題にしたいと思います。当面の間は今夏の設定で乗り切れそうです。

---

現在、ミツカリではITエンジニアを募集しています。興味のある方はぜひお気軽にご連絡ください！

https://herp.careers/v1/mitsucari