オリジナルの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バケットにコピーする、というものでした。

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

Node.js v8.10 EoL

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

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

docs.aws.amazon.com

dev.classmethod.jp

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

移行

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

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

終わり

AWSに限らず、パブリッククラウドではかゆいところに手が届く便利な機能が日々追加されています。 コスト削減にもつながるので、積極的に新しい機能を使っていきたいところです。