既存の Discourse インスタンスを、現在の場所から AWS EC2 VM に移行しています。
サイトは Amazon ロードバランサーの後ろにあります。すでに適切な set_real_ip_from ディレクティブで app.yml を正常に調整しており、NGINX はロードバランサーの IP を認識しています。ユーザーの最後の IP を確認すると実際の IP が表示されるため、これが機能していることはわかっています。
しかし、375 MB のバックアップを古いサーバーからアップロードしようとすると、ファイルが約 35% アップロードされたときに新しいサイトが 429 エラーを出し始め、アップロードプロセスが失敗します。429 レスポンスのヘッダーには「discourse-rate-limit-error-code: id_10_secs_limit」と表示されます。
これは驚くべきことでした。ブラウザのデベロッパーツールウィンドウを「ネットワーク」タブで開いており、たくさんの小さなチャンクが比較的速くアップロードされているのを見ました（おそらく 5 MB だったと思います）。私は高速な 200mbps のインターネット接続を使用しているため、デフォルトのレートリミッター設定では速すぎるだけでしょうか？それとも、管理タスクは通常プライベートネットワークから実行されることが期待されていましたか（私の AWS セットアップでは不可能です）。
しかし、まだあります！ app.yml から「templates/web.ratelimited.template.yml」行をコメントアウトしてアプリを再構築することでレートリミッターを無効にしようとしましたが、うまくいきませんでした。ファイルが約 35% アップロードされたときに、まだ 429 エラーが発生しました。
そこで、すぐに以下の環境変数を app.yml ファイルに追加し、再構築したところ、ようやく復元するバックアップをアップロードできるようになりました。
DISCOURSE_MAX_REQS_PER_IP_MODE: none
DISCOURSE_MAX_REQS_PER_IP_PER_10_SECONDS: 1000
これらはレートリミッターの設定だと思いますので、レートリミッターが無効になっているはずなのに、これらの設定に応答するものがあるのは奇妙でした。
結論として、以下の点についてガイダンスをいただければ幸いです。
- レートリミッターは、このようなバックアップアップロードをブロックすべきでしょうか？
- その行をコメントアウトしてアプリを再構築したときに、レートリミッターが無効にならなかったのはなぜですか？
ありがとうございます！