DBREチームのアクティビティ
Backup Platformの開発
現在私たちはBackup Platformの開発を行っています。ここでは、それがどのようなものか、を具体的に紹介させていただきます。
背景
ビズリーチはそのほとんどすべてをAWSやGCPなどのManagedサービスで運用しています。特に比率が高いのはRDSやAuroraなどのAWSで提供されているMySQL系Relational Databaseサービスです。
「え？ ここまで来て今更Backup？」と思った方もいらっしゃるかと思いますが、そのとおりで、DBAというRoleが存在する組織や会社であれば当たり前に行われていることでしょう。実際DBAが存在するビズリーチサービスではBackupに対する手段とその運用が確立されています。
しかしながら、規模の小さい事業や、新しくできた事業にはその知見やリソースがなく、RDSによる自動SnapShotしか取っていない事業も存在してしまっているのも現実としてあります。
現段階では最低限事業継続のために必要なこと（Point In Time RecoveryやMonitoringなど）はAWSの仕組みにお任せすることに振り切っています。とはいえ、おかげさまで事業が成長し続けているため、AWSの自動SnapShotだけでは事業を存続するための要件を満たせなくなりました。
具体的には個人情報や決算に関わる情報はレベル分けされ、それぞれX年保持する。という会社独自のポリシーです。皆様からお預かりしているデータなのでそれを安全に堅牢に保持し、不測の事態に備えるために重要なことです。
AWSでは保存できるSnapshotの数そのものに制限があったり、これからずっと（弊社が決めた長期的な保持期間）SnapShotがRestoreできるとは限りません。そのため、私たちはPITRなどのサービス継続に必要なbackupに関してはRDSの機能で、それ以外ではStatement Baseでファイルに保存するという方法を選択しました。
開発におけるスローガン
- 実現できることは枯れたコトかもしれない
- でもそれを新しい技術を使って実現できたら僕たちも面白い
この言葉のとおりですが、実際にBackup Platformとして開発してでき上がっていたものはものすごくレガシーなことです。業務要件や性能要件を無視すれば極端な話、
mysqldump --single-transaction --master-data=2 --all-databases --result-file=XXX
とcronに仕込めばいいかもしれません。とはいえBackupを取得することによって、Database Serverの負荷が上がって本番サービスに影響を与えてしまっては本末転倒ですよね。
幸いにも私たちの所属する部署には組織横断的にインフラ基盤を整備するグループが存在するので、その方々の力を借りてDatabase OperationをCloud Nativeならではの方法で実現させることを考えながら技術選定を行い、開発することができています。
その1番の理由は私たち自身がDatabaseだけでなく、インフラのトレンドを追い続けたい欲求があったからだと思います。
アーキテクチャ
前提として事業が使っているAWSアカウントとDBREチームで管理しているアカウントは別物です。それを踏まえてこの図をごく簡単に説明させていただきます。
- Initialize
-
Get SnapShot
事業内のRDSでSnapShotを作成、コピー、DBREチームアカウントに共有 -
Restore SnapShot
DBREチーム内のアカウントに共有されたスナップショットを展開 -
Create EC2
dump用のECSコンテナインスタンスを作成 -
Backup Exec and Out to EBS
テーブル単位でパラレルにバックアップしEBSに保存 -
Upload To S3
EBSからS3にPUT - Restore Test
- Cleanup
この仕組みはmysqldumpの部分を別の、例えばpg_dumpに変えればPostgreSQLに対応できたり、データマスキングの仕組みに組み替えればマスキングプラットフォームができたりと使い回しができるというメリットがあります。
本当は完全にServerlessで行いたかったのですが、これらの処理は時間がかかったり、ディスクI/Oを消費してしまったりするので、今回はDockerでEBSをマウントして解決をしています。この仕組みを入れるためにFargateでは実現できなかったため、一部でECS On EC2の環境を利用しています。
そしてこれらの処理に必要なリソースは使用中に立ち上げ、処理が完了したら綺麗に掃除しているので本当に必要な時間帯のみ起動するように設計しました。
また、Backupされたファイル自体はRestoreテストまで完了した時点で余程のことがない限り人が触れることがあってはならないため、独立したS3環境に配置するなど、セキュリティ的にも厳重に管理保管しています。
せっかくここまでコード化されているので、今後ナレッジを貯めることによって、例えば全体のディスクサイズや1テーブルあたりのディスクサイズを確認して、このDatabaseは処理に時間がかかりそうだからインスタンスサイズを上げる、それでもダメならディスクサイズに応じて例えばi3ストレージを使ってみるなど、アーキテクチャそのものも自動的に、柔軟に選択できるようにしたいと考えています。
