こんにちは、BizReachでDBREチームをやらせてもらっている あわっちです。

先日 孤高にきらめく執行役員 園田より、

DBRE(Database Reliability Engineering)チーム始めました

が掲載されましたが 結局具体的には何をしているの？ という声にお応えする為、私たちがどんな思想で活動を決めているのか、また具体的に何をどんな技術で何をやっているのか、をお伝えさせていただきます。

BizReachのDBRE / DBA Role

組織体制

BizReachには大小10以上のサービスが存在し、それらのサービスほぼ全てでMySQL、もしくはPostgreSQLのようなRelational Databaseを使用しています。

その中の代表的なサービスであるビズリーチやHRMOSといった事業体力があるサービスには専属のDBAが複数人存在しています。

(私自身、入社は2018年03月だったのですが、この時はビズリーチのDBAとして入社しています。)

逆にその他の事業ではDBAという明確なRoleが存在せず、事業のエンジニアが (良く言えば)フルスタックにDatabase関連の作業をする、という体制になっています。

そうなると必然的に専属のDBAがいる部署といない部署でDatabaseそのものの運用方法や、管理の質に差が出てきてしまいます。

また事業のエンジニアの中に存在する数少ないDatabaseに強い人材が異動や退職でいなくなった場合に、残されたエンジニアの心の平穏が保てなくなってしまい、健康的にアプリケーション運用をしていくことが難しくなる、なんてこともあるかもしれません。

これらのよくある解決策としてはDatabase Administrationを中央集権の形にし、管理運用をそこで行う、という方法です。

しかし (BizReachの場合) Database Administratorとしての作業はアプリケーションそのもののソースコードや仕様と密結合し過ぎてしまっているため現実的に難しい状況でした。

また、限られたリソースでは事業の実現したいスピードに合わせられないケースが発生し、中央にいるDBAとApplication Engineerの間に無意味な壁が出来てしまうかもしれません。

そこで私たちはDBREとして Engineering という側面から各事業のDatabase Operationに関する手助けを行う、といった方向に舵を切ることを決断しました。

DBREとは

Database Reliability Engineeringはあくまでも概念であり役割ではありません。 Database Reliability Engineering - O’Reilly Media にも書かれていますが

これからのDatabase ProfessionalはAdministratorではなくEngineerであるべきである、という思想が根底にあります。

各事業のエンジニアの自律性を尊重し、その方々の活動を最大化させるために、Databaseの管理運用に対するMonitoring Policyを決めたり、Database Operation Platformを開発し提供したり、

トラブルが発生した際などはトラブルシューティングを行い、現状復旧 -> 根本原因 -> Postmotemなどのプロセスを経て正常な状態を維持したりすることなどが挙げられます。

私たちの場合はまだこのチームが出来たばかりであり、 理想だけを求めてDBREを実践していくにはまだまだ時間もリソースも経験も知識も足りないものばかりです。

だからこそ、こうあるべき、ということに固執しすぎず、これから柔軟に BizReach 流の DBRE を進化させます。

DBREチームVision

私たちの全ての活動はこの２つの上に成り立っています。

チームを作る際に、「この部署はお金を生み出す部署ではない、事業に対してValueを提供できないとただの税金になってしまう」ということを何度も認識合わせを行いました。

その上で事業に対してどういったValueを提供したいか、を抽象化した言葉をVisionとして設定しました。

これらの言葉は、チームが新しいことをする。となった場合のやる、やらないの判断、自分たちのアウトプットの指標としてこの2つに落とせるか、をしっかりと見つめ直させてくれるもので、大変重要なものです。

DBREチームのアクティビティ

Backup Platformの開発

こちら にもある通り、現在私たちはBackup Platformの開発を行っています。

今回はこれがどんなものか、を具体的に紹介させていただきます。(今後Masking PlatformやMonitoring PlatformなどこのTechBlogで連載していければと思います。)

背景

BizReachはそのほとんど全てをAWSやGCPなどのManagedサービスで運用しています。特に比率が高いのはRDSやAuroraなどのAWSで提供されているMySQL系Relational Databaseサービスです。

「え？ ここまで来て今更Backup？」と思った方もいらっしゃるかと思いますが、その通りで、DBAというRoleが存在する組織や会社であれば当たり前に行われていることでしょう。

実際DBAが存在するビズリーチサービスではBackupに対する手段とその運用が確立されています。

しかしながら、規模の小さい事業や、新しく出来た事業にはその知見やリソースがなく、RDSによる 自動SnapShotしか取っていない事業も存在してしまっているのも現実としてあります。

現段階では最低限事業継続のために必要なこと(Point In Time RecoveryやMonitoringなど)はAWSの仕組みにお任せすることに振り切っています。

とはいえ、おかげさまでBizReachという会社も順調に育ってきている為、AWSの自動SnapShotだけでは会社を存続するための要件を満たせなくなりました。

具体的には個人情報や決算に関わる情報はレベル分けされ、それぞれX年保持する。という会社独自のポリシーです。

皆様からお預かりしているデータなのでそれを安全に堅牢に保持し、不測の事態に備えるために重要なことです。

AWSでは保存できるSnapshotの数そのものに 制限 があったり、これからずっと(弊社が決めた長期的な保持期間) SnapShotがRestoreできるとは限りません。

その為、私たちはPITRなどのサービス継続に必要なbackupに関してはRDSの機能で、それ以外ではStatement Baseでファイルに保存するという方法を選択しました。

開発におけるスローガン

この言葉の通りですが、実際にBackup Platformとして開発して出来上がってたものはものすごくレガシーなことです。

業務要件や性能要件を無視すれば極端な話

1

mysqldump --single-transaction --master-data=2 --all-databases --result-file=XXX

とcronに仕込めばいいかもしれません。

とはいえBackup取得することによって、Database Serverの負荷が上がって本番サービスに影響を与えてしまっては本末転倒ですよね。

幸いにも私たちの所属する部署には組織横断的にインフラ基盤を整備するグループが存在するので、その方々の力を借りてDatabase OperationをCloud Nativeならではの方法で実現させることを考えながら技術選定を行い、開発をしています。

その1番の理由は私たち自身がDatabaseだけでなく、インフラのトレンドを追い続けたい欲求があったからだと思います。

アーキテクチャ

system_design

前提として 事業が使っているAWSアカウントとDBREチームで管理しているアカウントは別物です。それを踏まえてこの図をごく簡単に説明させていただきます。

  1. Initialize
  2. Get SnapShot
    • 事業内のRDSでSnapShotを作成、コピー、DBREチームアカウントに共有
  3. Restore SnapShot
    • DBREチーム内のアカウントに共有されたスナップショットを展開
  4. Create EC2
    • dump用のECSコンテナインスタンスを作成
  5. Backup Exec and Out to EBS
    • テーブル単位でパラレルにバックアップしEBSに保存
  6. Upload To S3
    • EBSからS3にPUT
  7. Restore Test
  8. Cleanup

この仕組みはmysqldumpの部分を別の、例えばpg_dumpに変えればPostgreSQLに対応できたり、データマスキングの仕組みに組み替えればマスキングプラットフォームができたりと使い回しができることです。

本当は完全にServerlessで行いたかったのですが、これらの処理は時間がかかったり、ディスクI/Oを消費してしまうので今回はDockerでEBSをマウントして解決をしています。

この仕組みを入れるためにFargeteでは実現できなかったため、一部でECS On EC2の環境を利用しています。

そしてこれらの処理に必要なリソースは使用中に立ち上げ、処理が完了したら綺麗に掃除しているので本当に必要な時間帯のみ起動するように設計しました。

また、BackupされたFile自体はRestoreテストまで完了した時点で余程のことがない限り人が触れることがあってはならない為、独立したS3環境に配置するなど、セキュリティ的にも厳重に管理保管しています。

(この詳しい仕組みに関しては今後このBlogなどを通して発信したいと思います。)

せっかくここまでコード化されているので、今後ナレッジを貯めることによって、例えば 全体のディスクサイズや1テーブルあたりのディスクサイズを確認して、このDatabaseは処理に時間がかかりそうだからインスタンスサイズを上げる、それでもダメならディスクサイズに応じて例えばi3ストレージを使ってみる、などアーキテクチャそのものも自動的に、柔軟に選択できるようにしたいと考えています。

最後に

長くなりましたが、いかがでしたでしょうか？何となくでも私たちの考えているDBREについてイメージが持てましたでしょうか？

今回はBackup Platformに特化してお話させていただきましたが、今後も継続的に私たちのアクティビティを紹介していければと思います。

レッツジョイン

DBREチームを発足はしたのですが、とはいえやりたいことに対して仲間はまだまだ足りません、実はまだDBREチームの専任は２名です！

DBREに興味のある方、是非ご応募ください。いまDBAやってるよって方からソフトウエアエンジニアやSREだけどDBREに興味あるよって方もご応募お待ちしております。

採用情報のページはこちら DBRE

awache
awache

MySQL と 特攻の拓 が好きな DBRE、トラブル時には心の中で 不運(ハードラック)と踊(ダンス)っちまった と唱えてます