AWS CDN 및 S3 관련 문제

,

@Falco 이 내용도 여전히 유효합니까? AWS 사용 시 최근 문제가 있었다는 내용을 읽은 것 같은데, 해당 주제를 다시 찾지 못하고 있습니다.

AWS S3를 사용할 때 관련 주제들을 참고하여 설정했는데, 여러 문제가 발생하고 있습니다.

백업은 정상적으로 작동하지만, Cloudfront를 CDN으로 사용하거나 DISCOURSE_USE_S3와/또는 DISCOURSE_S3_BUCKET 주석 해제 시 영구적으로 로딩 화면(throbber)이 계속 나타납니다.

업로드 버킷과/또는 Cloudfront 배포 설정에 오류가 있는 것 같지만, 원인을 찾지 못하고 있습니다. 업로드 버킷과 백업 버킷 모두 해당 배포(Distribution) 뒤에 있으며 백업은 정상 작동하는데 왜 이런 현상이 발생하는 걸까요?

discourse-cdn.repealobbba.org CNAME —> amazonassigned.cloudfront.net

DISCOURSE_CDN_URL: https://discourse-cdn.repealobbba.org

## S3 storage config
#  DISCOURSE_USE_S3: true
  DISCOURSE_S3_REGION: us-east-1
  DISCOURSE_S3_ACCESS_KEY_ID: ACCESS_KEY_ID
  DISCOURSE_S3_SECRET_ACCESS_KEY: SECRET_ACCESS_KEY
  DISCOURSE_S3_CDN_URL: amazonassigned.cloudfront.net  or
#  DISCOURSE_S3_BUCKET: repeal-obbba-discuss-uploads
  DISCOURSE_S3_BACKUP_BUCKET: repeal-obbba-discuss-backups
  DISCOURSE_BACKUP_LOCATION: s3

추가로, 설정에 다음을 추가했을 때

    after_assets_precompile:
    - exec:
        cd: $home
        cmd:
          - sudo -E -u discourse bundle exec rake s3:upload_assets
          - sudo -E -u discourse bundle exec rake s3:expire_missing_assets

FAILED TO BOOTSTRAP 오류가 발생합니다.

FAILED
--------------------
Pups::ExecError: cd /var/www/discourse && sudo -E -u discourse bundle exec rake s3:upload_assets failed with return #<Process::Status: pid 8484 exit 1>
Location of failure: /usr/local/lib/ruby/gems/3.3.0/gems/pups-1.3.0/lib/pups/exec_command.rb:131:in `spawn'
exec failed with the params {"cd"=>"$home", "cmd"=>["sudo -E -u discourse bundle exec rake s3:upload_assets", "sudo -E -u discourse bundle exec rake s3:expire_missing_assets"]}
bootstrap failed with exit code 1
** FAILED TO BOOTSTRAP ** please scroll up and look for earlier error messages, there may be more than one.

항상 그렇듯… 생각이나 제안이 있으시면 감사하겠습니다.

S3에 자산을 업로드하는 스탠사를 추가해야 합니다.

아, 제가 잘못 알고 있었네요. 사용자가 직접 하고 계시군요.

이는 버킷 구성에 문제가 있음을 시사합니다.

버킷을 구성하기 위한 JSON을 생성해 주던 토픽이 있었던 것 같은데, 여전히 존재하는지 모르겠습니다.

동의합니다.
백업 버킷에는 버킷 정책이 사용되지 않았지만, 업로드 버킷에 정책을 추가하니 부트스트랩 실패가 해결되었습니다.

정책 JSON은 CloudFront > 배포 > 해당 배포 > 오리진 편집에서 확인할 수 있습니다.
Screenshot 2025-12-10 141220

불행히도 영구적인 로딩 스피너(회전 아이콘)는 계속 표시됩니다.

오브젝트 소유권과 ACL을 조정해도 결과가 변하지 않습니다.

현재 설정입니다. 이것이 권장 설정이라고 생각하지만, 혹시 제가 혼동하고 있는 것일 수도 있습니다.


설정을 변경한 후에는 rant 작업을 실행하여 에셋을 업로드해야 합니다.

또한, 개발자 콘솔을 열어 버킷에 존재하는지 파일이 액세스를 시도하고 있는지, 아니면 CDN에 문제가 있는지 확인할 수 있습니다.

계속해 주셔서 감사합니다.

네, rake 태스크는 실행되며, 차이가 없습니다.

./launcher enter app
rake posts:rebake
rake uploads:migrate_to_s3
rake posts:rebake_uncooked_posts

로딩 인디케이터(스피너)가 계속 표시됩니다.

rake uploads:migrate_to_s3 실행 시 오류가 발생합니다.

Migrating uploads to S3 for 'default'...
Some uploads were not migrated to the new scheme. Running the migration, this may take a while...
rake aborted!
FileStore::ToS3MigrationError: Some uploads could not be migrated to the new scheme. You need to fix this manually. (FileStore::ToS3MigrationError)
/var/www/discourse/lib/file_store/to_s3_migration.rb:156:in `migrate_to_s3'
/var/www/discourse/lib/file_store/to_s3_migration.rb:59:in `migrate'
/var/www/discourse/lib/tasks/uploads.rake:126:in `migrate_to_s3'
/var/www/discourse/lib/tasks/uploads.rake:106:in `block in migrate_to_s3_all_sites'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/rails_multisite-7.0.0/lib/rails_multisite/connection_management/null_instance.rb:49:in `with_connection'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/rails_multisite-7.0.0/lib/rails_multisite/connection_management/null_instance.rb:36:in `each_connection'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/rails_multisite-7.0.0/lib/rails_multisite/connection_management.rb:17:in `each_connection'
/var/www/discourse/lib/tasks/uploads.rake:104:in `migrate_to_s3_all_sites'
/var/www/discourse/lib/tasks/uploads.rake:100:in `block in <main>'
/usr/local/bin/bundle:25:in `load'
/usr/local/bin/bundle:25:in `<main>'
Tasks: TOP => uploads:migrate_to_s3

최소 하나의 CDN 체크어에서 discourse-cdn.repealobbba.org -->Amazon CloudFront로 표시되고 있습니다.

그리고 콘솔에서는 여전히 이미지와 JS 파일이 CDN에서 호출되고 있는 것으로 보입니다.

에셋은 CDN에서 호출되고 있지만, 실제로 존재합니까? 그렇지 않다면 버킷 안에 있나요? 버킷에서 접근 가능한 상태인가요?

대부분의 업로드가 다른 버킷에 있거나, 에셋이 예상된 위치에 존재하지 않도록 막는 어떤 요인이 있을 가능성이 큽니다. 그렇다면 해당 메시지에 명시된 대로 수동으로 수정해야 합니다. 콘솔에 접속하여 업로드 기록에서 에셋이 어디에 있는지 확인해야 합니다.

업로드 에셋 작업이 정상적으로 작동하는 것처럼 보입니까? 다른 에셋이 로드되지 않기 때문에 로딩 표시기가 계속 돌아가고 있습니다.

네, 파일은 버킷에 자산으로 존재합니다.
접근 가능: https://repeal-obbba-discuss-uploads.s3.us-east-1.amazonaws.com/assets/logo-815195ae.png

버킷은 uploads와 backups 두 개뿐입니다. 백업은 정상적으로 작동하고 있습니다.

rake s3:upload_assets를 실행했을 때 오류가 발생했습니다:
rake aborted!
Aws::S3::Errors::AccessControlListNotSupported: The bucket does not allow ACLs (Aws::S3::Errors::AccessControlListNotSupported)

ACL을 활성화로 변경하고 s3:upload_assets 수정: uploads:migrate_to_s3를 다시 실행했지만…
FileStore::ToS3MigrationError: Some uploads could not be migrated to the new scheme. You need to fix this manually. (FileStore::ToS3MigrationError)

??? 수동으로 수정해야 합니다. (FileStore::ToS3MigrationError)

버킷을 수정했고 이제 에셋 업로드가 가능한 것 같으니, 사이트가 정상 작동해야 합니다. 마이그레이션되지 않는 업로드 처리는 또 다른 (복잡한) 문제입니다.

서빙하려는 에셋 중 하나는 다음과 같습니다:

https://discourse-cdn.repealobbba.org/assets/start-discourse-6f03a463.br.js

인증서가 손상되어 있어 이것이 문제입니다. 인증서는 존재하지만 URL과 일치하지 않습니다.

앞서 제안했듯이, 브라우저의 개발자 도구에서 네트워크 탭을 확인해 보세요. 다음과 같은 내용이 표시됩니다:

위에서 수정
ACL을 활성화로 전환하고 s3:upload_assets 수정: uploads:migrate_to_s3를 다시 실행했습니다

s3:upload_assets는 이제 문제 없이 완료됩니다

네트워크 오류를 확인했습니다. 인증서가 AWS 문제인가요?

이 건에 대해 다시 한번 시간 내어 주셔서 감사합니다!!

네. 인증서가 호스트 이름과 일치하지 않습니다. *.cloudfront.net와 일치합니다.

이것은 작동합니다: https://repeal-obbba-discuss-uploads.s3.us-east-1.amazonaws.com/assets/logo-815195ae.png

이것은 작동하지 않습니다: https://discourse-cdn.repealobbba.org/assets/start-discourse-6f03a463.br.js

이것은 작동합니다: https://repeal-obbba-discuss-uploads.s3.us-east-1.amazonaws.com/assets/start-discourse-6f03a463.br.js

따라서 s3 CDN 주소를 https://repeal-obbba-discuss-uploads.s3.us-east-1.amazonaws.com으로 변경해야 합니다 – 아, 그게 버킷 주소네요. 그렇게 하는 것이 이상적은 아니지만, 작동은 할 것입니다.

"이상적은 아니지만"이라는 표현이 좀 마음에 안 듭니다 :wink:

가능한 해결책으로 AWS 대체 도메인 이름을 살펴보고 있습니다.

제 생각이 틀렸을 수도 있지만, @Discourse가 내부적으로 사용하는 CDN을 추가하는 것이 이토록 어렵고 @pfaffman 같은 분들의 도움을 받아야 하는 건 아닌 것 같습니다.

@Falco 또는 @sam, 그리고 @team (팀을 멘션할 수는 없네요)이 의견을 주실 수 있을까요??

네, 우리가 호스팅하는 모든 사이트는 S3와 CloudFront 조합을 사용합니다. 지금 보고 계신 이 사이트도 마찬가지입니다.

확인해 주셔서 감사합니다! 이 내용을 보고 DISCOURSE_S3_CDN_URL: 을 amazonassigned.cloudfront.net으로 되돌렸습니다. 이렇게 하면 인증서와 URL 문제가 해결될 것으로 기대합니다.

다시 빌드하고 문서에 언급된 모든 rake 작업을 실행했습니다.
rake posts:rebake
rake uploads:migrate_to_s3 여전히 FileStore::ToS3MigrationError가 발생합니다.
rake posts:rebake_uncooked_posts

rake s3:upload_assets
rake s3:expire_missing_assets

사이트 로딩이 여전히 되지 않습니다.

제안이 있으신가요?

결국 이 정보가 도움이 되었습니다.

@chapoi 이 스레드를 지원용으로 분리해 주실 수 있을까요?
아마도 @JammyDodger가 가시성을 높이기 위해 설치(Installation) 섹션으로 옮긴 것 같습니다. 다만 포럼은 몇 달 동안 문제없이 잘 돌아가고 있었죠.

어쨌든 관심 가져 주셔서 감사합니다!

설치는 포럼을 설정하는 것만을 의미하지 않습니다.

확인했습니다. 설명해 주셔서 감사합니다.

위에서 언급했듯이, 대체 도메인 도움말을 추가하세요.
사이트는 로드되지만 스타일시트 없이…에 표시됩니다.

버킷을 살펴봤는데 stylesheets/ 폴더를 찾을 수 없습니다.

s3:upload_assets가 불완전한 것 같습니다.

그리고 CORS 문제가 있는 것 같네요?

문서에서 몇 가지 오해의 소리가 있거나 혼란스럽거나, BBS(게시판 시스템)에 익숙한 사람에게는 과할 수 있는 부분을 파악한 뒤 진전이 있었어요. :distorted_face:

우리 BBS 사용자들에게는 "Cloudfront 배포 2개가 필요합니다"라는 점을 강조하기 위해 붉은색으로 깜빡이는 표시를 넣으면 도움이 될 것 같습니다.

그리고 다음에 대한 설명도 필요합니다.

S3 관련 주제의 업데이트와 통합이 이루어지면 정말 좋겠습니다. AWS S3 CDN과 백업에 대한 최신 정보를 담은 마스터 토픽 하나면 완벽할 것 같습니다.

계속해서…

이제 Cloudfront 배포 2개를 가지고 있지만:

모든 rake 태스크가 오류 없이 실행되고
이것은 더 이상 부트스트랩 실패를 일으키지 않습니다.

after_assets_precompile:
    - exec:
        cd: $home
        cmd:
          - sudo -E -u discourse bundle exec rake s3:upload_assets
          - sudo -E -u discourse bundle exec rake s3:expire_missing_assets

CDN 체크 결과는 더 바람직한 결과를 보여줍니다.

전체적으로 진전은 있지만, Discourse 인프라 팀의 몇 가지 팁이 매우 도움이 될 것입니다.

휴! 시간이 많이 걸렸고, 매우 친절했던 Amazon 엔지니어와 전화로 총 8시간(2회 통화)을 보냈지만, 이제 이 문제를 제대로 이해한 것 같습니다. RepealOBBBA 사이트에서는 모든 것이 잘 작동하고 있으며, 이 프로세스를 다른 사이트에도 재현할 수 있습니다.

나중에 자세히 정리해 볼 수도 있지만, 우선 몇 가지 참고 사항을 남깁니다:

  1. DISCOURSE_CDN_URL(AWS S3를 사용하는 경우)과 DISCOURSE_S3_CDN_URL은 각각 별도의 CloudFront 배포를 요구합니다.
  2. DISCOURSE_CDN_URL은 버킷을 사용하지 않습니다.
  3. DISCOURSE_CDN_URL은 AWS가 아닌 CDN을 사용할 수 있습니다. Bunny.net이 아주 잘 작동합니다. (Bunny Storage의 S3 지원이 2026년 1분기에 출시될 예정이라고 합니다.)
  4. DISCOURSE_CDN_URL과 DISCOURSE_S3_CDN_URL의 CDN은 적절한 DNS 구성을 통해 브랜딩된 URL을 사용할 수 있습니다.
  5. DISCOURSE_S3_CDN_URL에는 업로드 버킷이 필요합니다.
  6. 업로드 버킷에는 ACL이 활성화되어 있어야 하며, "모든 사용자(공개 액세스)"를 "읽기"로 설정하고 버킷에 대한 정책을 설정해야 합니다.
  7. 백업 버킷에는 ACL이나 정책이 필요하지 않습니다.

수정 사항

  1. S3에서 “모든 업로드에 CDN URL 사용” 상자를 선택하세요: 이미지뿐만 아니라 s3에 업로드된 모든 파일에 대해 CDN URL을 사용하도록 설정합니다. 이 옵션을 활성화하지 않으면 항상 실패하는 문제가 발생했습니다.

위 내용을 읽고 "필, 당연하지, 뭘