백업 파일 업로드 시 속도 제한 문제 / 속도 제한 비활성화 불가

기존 Discourse 인스턴스를 현재 위치에서 AWS EC2 VM으로 이전하고 있습니다.

사이트는 Amazon 로드 밸런서 뒤에 있습니다. 이미 app.yml을 적절히 수정하여 set_real_ip_from 지시문을 설정했고, NGINX가 로드 밸런서 IP를 인식하도록 했습니다. 사용자의 마지막 IP를 확인할 때 실제 IP가 표시되므로 이 설정이 정상적으로 작동하고 있음을 알고 있습니다.

하지만 기존 서버에서 375MB 백업 파일을 업로드하려고 하면, 파일이 약 35% 업로드되었을 때 새 사이트에서 429 에러가 발생하기 시작하고 업로드 프로세스가 실패합니다. 429 응답 헤더에는 "discourse-rate-limit-error-code: id_10_secs_limit"라고 표시되어 있습니다.

이것은 좀 의외였습니다. 브라우저의 Dev Tools 창을 “Network” 탭에 열어 두었는데, 작은 청크들(5MB라고 생각합니다)이 꽤 빠르게 업로드되는 것을 확인했습니다. 저는 빠른 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

이것들이 레이트 리미터 설정이라고 생각했는데, 레이트 리미터가 supposedly 비활성화되어 있음에도 불구하고 이 설정에 반응하는 것을 보는 것은 이상했습니다.

결론적으로, 다음 사항에 대한 조언을 듣고 싶습니다:

  1. 레이트 리미터가 이러한 백업 업로드를 차단해야 하는 것일까요?
  2. 해당 줄을 주석 처리하고 앱을 다시 빌드했는데도 왜 레이트 리미터가 비활성화되지 않았을까요?

감사합니다!

백업을 업로드하려는 경우 scp를 사용하거나 S3에 업로드하세요.

“scp 사용”이라고 하셨을 때, 파일을 VM으로 직접 전송한 뒤 Discourse가 인식할 수 있도록 특정 폴더에 배치하라는 뜻인가요? 아직 시도해 보지 않았지만, 해당 폴더가 /var/discourse/shared/standalone/backups/default인 것 같습니다.

그리고 S3를 사용하면 실제로 Amazon 로드 밸런서를 우회할 수 있을까요?

감사합니다!

해당 폴더가 존재한다면, 아마도 그곳이 맞을 것입니다.

그렇습니다.

기본 복원 가이드에는 default 폴더를 생성하도록 안내되어 있으므로, 해당 폴더가 존재하지 않더라도 수동으로 생성할 수 있습니다.

참고: Restore a backup from the command line