オリジナルのS3バケットのバックアップシステムをCross Region Replicationに移行したはなし

SREチームの長田です。 Tech Kayac Advent Calendar Migration Trackの15日目です。

S3バケットのバックアップ

Lobiでは投稿された画像ファイルをS3に保存しています。 S3に保存しているだけでは、S3から誤って削除した場合に復元することができません。

主に読み書きするS3バケットとは別に、バックアップ用のS3バケットを用意し、そちらに画像ファイルのコピーを保存しています。バックアップの仕組みを用意した当時はAWS内にこれを実現する機能がなく、自前のLambda functionでコピーを行っていました。

f:id:handlename:20191213141850p:plain — Backup S3 objects with Lambda function

S3バケットに画像ファイルがPUTされたイベントをLambda functionに通知し、対象ファイルをダウンロードして別リージョンにあるバックアップ用のS3バケットにコピーする、というものでした。

機能としてはシンプルなので、実装当初からメンテナンスフリーで稼働していました。

追記: 2019-12-16

バックアップを取るきっかけになったのが、ライフサイクルイベントの誤設定でした。ログ保存用のS3バケットにライフサイクルイベントを設定したつもりが、対象を誤り画像保存用のS3バケットに設定してしまったため、ある日付以前の画像が跡形もなく消えるという事故でした。

当時のお知らせ記事。 web.lobi.co

ライフサイクルイベントによるオブジェクト削除はバージョニングでは救えないため、PUTイベントを拾って別のS3バケットにコピーする、という動作にしていました。

追記ここまで

Node.js v8.10 EoL

が、Node.js v8.10のEoLに伴い、Lambda functionのNode.js v8.10ランタイムも利用できなくなるというアナウンスがありました。同ランタイムで稼働していたこのバックアップの仕組みも対応が必要になりました。

一番シンプルな対応方法はランタイムのバージョンを上げることでしたが、ほぼ同等のシステムとしてCross Region Replication(CRR)という機能があります。 ~~実装当時とは異なり現在のAWSにはCross Region Replication(CRR)という機能があります。~~

追記: 2019-12-16

当時すでにCRRは存在していたのでは？という指摘をいただきました。調べてみるとたしかにCRRのほうがLambda functionでのバクアップを行っていた時点よりも早くリリースされていました。

当時選択肢として挙げられていなかったということですね。訂正いたします。

追記

docs.aws.amazon.com

dev.classmethod.jp

この機能を使えば自前のLambda functionを動かす必要はありません。

移行

元の仕組みでも特別なことは行っていなかったので、単にCRRの設定をするだけで済ました。 S3バケットのバージョニングを有効にする必要があるため、移行期間中のLambda functionとCRRが同時に稼働する期間については同じ画像が複数バージョンとして記録されることになりますが、バックアップ用途としては問題ありません。

CRRの設定をして、Lambda functionを削除して、さくっと移行が完了しました。