私は1日あたり15万ページビューを超える、比較的高負荷のサイトに取り組んでいます。主にメッセージバスで429エラーが発生しています。以前は set_real_ip_from の設定ミスにより問題が発生していましたが、これは解決済みです。また、レート制限テンプレートを（一時的かもしれませんが）削除しました。
それでも、1秒あたり約0.5件の429エラーが確認されています。
2コア/4スレッドのCPUを搭載し、16GBのRAMを持つ5つのUnicornワーカーを運用しています。Postgresは別のホストにあります。CPUの使用率は50%以上アイドル状態のままです。
レート制限テンプレートを削除し、Unicornワーカーを5に増やしたのは、約8時20分頃です。
それは完全に正常です。ユニコーンが過負荷状態で少しキューイングしているため、メッセージバスは 429 でバックオフします。
データベースを実行していないノードの場合、4 コアで 16GB RAM という比率は非常に不自然です。例えば、8/8 の方が良いでしょう。
素晴らしい！ありがとうございます。CPU は画像処理でまだ負荷がかかっていますが、2〜3 日以内には終わることを願っています。
その通りです。しかし、ベアメタルは 2 コア/4 スレッドです。RAM は増設しやすいですが、コア数は増やせません（自宅には 32GB のマシンがもう一台あります）。CPU を増やすために、データベースと Web を 2 台のマシンに分割しました。同じデータベースサーバーには、低トラフィックサイトの他のデータベースが半ダースほどあります（Web は別のホスト）。DB と Web を同じマシンで動かした方が良いと思いますか？CPU は少し減るかもしれませんが、レイテンシは改善されると思います。
もしここでロードバランサーの機能があれば、負荷の高いサイト向けにウェブワーカーを両方のマシンに配置してみる価値があるかもしれません。データベースがある方のマシンには少し少なめに、例えば 5+2 のように配分するのはどうでしょうか。
お金で解決できるなら、CPU と RAM の比率がより優れた別のホストを取得するのが良いでしょう。
まあ、無料で手に入れたこれらのマシンは、さすがに古くなってきましたね。その事実を受け入れつつありますが、単一 CPU のパフォーマンスは、DO の Droplet よりもまだ優れているようです。短期的にお金で問題を解決できるなら、企業レベルのパフォーマンスをビジネス価格で求めるこの特定のクライアントも、おそらく存在しなかったでしょうね。
それに、チェーンの別の場所にユニコーンの数をハードコードしていたことに気づきました。なので、まだ 3 個しか稼働していません。
残念ながら、現在の設定では 1 台のホスト上の Docker としか通信していません。もう少し時間をかけて、もう 1 台のマシンにもユニコーンをいくつか追加できないか検討すべきかもしれません。HAproxy をもう一度見直す時期かもしれませんね。ただ、まずどうしても立ち上げたい別のプロジェクトがあるので、そちらを優先しています。
貴重なご意見をありがとうございます。
追記：最終的にユニコーンを 3 個から 5 個に増やしたところ、パフォーマンスグラフはほぼ同じ（もしかしたら少し遅いかも？）でしたが、429 エラーは大幅に減少しました。画像処理が完了すれば、これで問題なく動作しそうです。
そして、わずか1日後、429エラーはほぼゼロにまで減少しました。ラファエルの「気にしないで」というアドバイスは本当に素晴らしかったです！カネとラファエル、ありがとうございました。皆さんのご支援に心から感謝しています。
