自分で運用しているアプリケーションのストレージサービスをS3に完全に移行しました。
S3を利用していたのはアプリケーションがもともとHerokuで運用していたからです。
アプリケーション自体は今はGoogle Cloud Platform上に構築していますが、もともとHerokuで運用してしていました。
なのでストレージサービスはGCSではなく、S3になっていました。
これをさすがGCSに移行することにしました。
移行の理由としては、完全にアプリケーションをGoogle Cloud Platform上に移行したかったからと、請求を一本化したかったからです。
移行方法の検討と実施
S3とGCSにファイルを出力しながら段階的に移行していこうかと考えたのですが、めんどくさかったので下記の手順で実施しました。
- アプリケーションのS3の処理をGCSに置き換える。
- Terraformで移行先のGCSバケット作成、CORSの設定を行う。
- StorageTransferServiceを利用して、S3のバケットのオブジェクトをGCSに転送する。
- アプリケーションをデプロイする。
- 正常に稼働しているかを確認する。
S3とGCSへのオブジェクト転送
StorageTransferServiceを利用したS3からGCSへ転送ですが、下記の方法で実行しました。 docs.cloud.google.com
SecretManagerに転送用のシークレットを作成する
{ "accessKeyId": "AWS_ACCESS_KEY_ID", "secretAccessKey": "AWS_SECRET_ACCESS_KEY" }転送元をAmazon S3のバケットにする、ここで作成したシークレットのアクセスキーを利用するようにする
- 転送先のGCSのバケットを選ぶ
ネットワークルーティングオプションでマネージドプライベートネットワークを選択する
ネットワークルーティングオプション ジョブを実行する
これで転送ジョブが開始されます。
転送結果
6,948ファイル、20GB近くのバケットから転送しましたが、一回では全て転送できませんでした。
2回手動で再実行しました。
今回は一回でやろうとしたので、手動で実行しましたが、本来は定期的に実行するようスケジュールリングして、転送するのだと思います。
結果は10分くらいで転送できました。
開始: 2025年11月29日 11:38:34
終了: 2025年11月29日 11:47:45
思いのほか短時間で終わってよかったです。
余談ですが、初回だけ権限エラーが発生してました。
project-[プロジェクト番号]で始まるサービスアカウントなので、GCP側で自動で作成されるサービスアカウントです。
project-[プロジェクト番号]@storage-transfer-service.iam.gserviceaccount.com does not have storage.objects.list access to the Google Cloud Storage bucket. Permission 'storage.objects.list' denied on resource (or it may not exist).
2回目以降はエラーが発生してないので、問題なと思います。
長期的に転送ジョブを利用する場合は、権限の管理を細かくできるサービスアカウントを自前で用意して、ジョブの設定で「ユーザー管理のサービス エージェント」を選択して割り当てる方がいいと思います。
