こんにちは。サーバレスアーキテクチャにハマっている高橋です。

以前にご紹介したとおり、Amazon S3にクロスリージョンレプリカ機能が追加されました。

このブログを読んで頂ければ分かるのですが、クロスリージョンレプリカは2つのバケットでしかレプリケーションができず、Zabbixおじさんの夢であった全世界ファイルサーバはできませんでした。

そこで今回 AWS Lambdaを利用し、全世界ファイルサーバを構築して、Zabbixおじさんの夢を叶えてみました。

おじさんの構想~なにができたか、できなかったか~

そもそもZabbixおじさんは何をやりたかったのでしょうか。下の図をご覧ください。

3つのリージョンにバケットを作成し、全世界でクロスリージョンレプリケーションのリングを組んで、全世界で同じファイルが見える低レイテンシーのファイルサーバを作成しようとしました。

上記の図で言いますと、Tokyoリージョンにファイルをアップロードすると、自動でTokyoからOregonへ、OregonからIrelandリージョンにコピーされるという仕組みです。

現実は厳しかった

残念ながらクロスリージョンレプリケーションの機能ではコピーされたファイルはコピー対象外になり、TokyoリージョンにアップロードされたファイルはIrelandにいくことはなかったのでした。

なんとか全世界にコピーしたいなーなんて思っていたら思い浮かびました。そうだAWS Lambdaを使えばいいじゃないかと！

AWS Lambdaで実装してみました。どこかのバケットにファイルがPUTされると、それを検知して次のバケットにファイルをコピーする仕組みです。

AWS Lambda functionは同じリージョンのS3イベントしかとれないので、リージョン毎にfunctionを用意しました。

やったこれで全世界ファイルサーバができた！ところが。。。

恐れていたことが起こりました。PUTされたら別のバケットにコピーするという単純な仕組みにしていたため、コピーされたファイルに対してもPUTトリガーが発動され、ファイルは3リージョンをぐるぐると無限にコピーされてしまったのです！

そこでファイルがPUTされfunctionが発動した時に、同じ名前のファイルがコピー先のバケットに存在するときは、functionを停止するようにしました。これがうまくいき、無限ループを抜け出すことができました！

ただしこの実装の場合、ファイル名は同じでも中身の異なるファイルがアップロードされた場合は別リージョンにコピーされなくなってしまうので、厳密にチェックを行う場合はETag(MD5)の値をチェックすることをオススメします。

ちなみにファイルの削除も同じ要領で実装しました。特定のバケットでファイルが削除されると、別のバケットに同じファイル名があるかを確認し、あった場合は削除、ない場合は何もしないという仕組みです。

S3を使って、全世界から使える低レイテンシーファイルサーバができました。

グローバルに活動を行う事業者様にとっては、各拠点から一番近いファイルサーバにデータをアップロード,ダウンロードできるので便利なのではないでしょうか。

EC2やオンプレミスでこのようなシステムを構築する場合、サーバの設定や冗長化やら何やらで相当な工数がかかると思うのですが、本システムはS3とAWS Lambdaを利用して2~3時間で構築ができました。サーバレスアーキテクチャというものでシステムを作成できたというわけであります。

AWS Lambdaであれやこれやできて、夢が広がりんぐです。