@pnoeric サイトの稼働時間について懸念されているとのことですので、私がこれまで学んだことを共有させていただきます。
私が述べた通り、移行はライブで行いました。移行をレート制限しないと、ユーザー間のアクティビティを通知するなどの処理を行うキューが混雑し、サイトのユーザーエクスペリエンスが損なわれてしまいます。
動画を含む約500件の投稿と、画像を含む約3万件の投稿を移行しましたが、完了までに約2週間かかりました。
私が使用したコードを試してみたい場合は、現在以下の場所にあります。
これをダウンロードして、アプリ内の lib/tasks/uploads.rake の現在の内容を置き換えるようにコピーしてください。
このコードを使用すると、以下のような操作が可能です。
bin/rake uploads:batch_migrate_from_s3[100,1000]
これにより、アップロードを含む1000件の投稿のみを対象とし、最大100件のファイルから移行を行い、その後停止します。アップロードの移行後に投稿を実際に変更するたびに、次の処理を開始する前にキューが空になるまで待機します。
このファイルをコピーすると、変更を元に戻すまで今後のサイト更新が破損します。変更を元に戻す最も簡単な方法は、満足した後に ./launcher rebuild app を実行することです（ただし、開発者としては git checkout HEAD lib/tasks/uploads.rake を使用して変更を元に戻しています）。
少なくとも Digital Ocean Spaces の場合、移行が成功するまでに何度か再試行が必要なことがありました。現在のスクリプトでは、その場合の警告が表示されず、実行し続けて結果を待つしかありません。その際にエラーを出力するPRをレビュー待ちしていますので、何か問題が発生したことが少なくともわかるようになります。
…
簡単な短い再試行ループとエラーメッセージを追加しましたが、再試行ループによって問題が解決したようです。また、過去の投稿の生コンテンツに対して現在のルールに基づく検証が行われており、移行が破損したり、再焼成が必要な投稿が静かに残されたりする問題がありましたが、これも修正しました。少なくとも検証の修正が含まれていなければ、移行を行いたくないはずです。これは現在レビュー待ちの私のPRに含まれるコミットの1つです。
…
私の移行は、私の知る限り完了しました。私のPRには、移行を完了するために使用したコードがすべて含まれています。レビューは行われていません。もし関心がある場合は、Migrate_from_s3 problems をフォローすることをお勧めします。