DBRE(Database Reliability Engineering) 始めました ~ Make it visible / No Ops, More Code ~

2019-06-07 MySQL Casual Talks vol.11 のスライドです
https://mysql-casual.connpass.com/event/131551/

Transcript

1. Database Reliability Engineering 始めました ~ Make it visible / No Ops, More Code ~ http://www.bizreach.jp
 プラットフォーム基盤推進室
 Database Reliability Engineer Group

2. Hello!!
 *********** 1. row ********** name: 粟田 啓介 nickname: あわっち title: DBRE twitter: @_awache 1 rows in set (0.00 sec) mysql > SELECT * FROM me \G
3. README ✅ この資料は @_awache という個人の独断と偏見により作成したものです 。 ✅ 所属する組織の意見を代表するものではありません 。 ✅ 合法性や安全性、情報の正確性についても保証できません。 カジュアルな会(のはず)なので内容もノリも軽めです。 カシュっとしながら 楽しんでいただければと思いますｍｍ mysql-casual だけど MySQL のこと少なめです。 ✅ Theme by Template Park. ＞https://template-parks.com/
4. DBRE 始めました
5. Mission プラットフォームを通してエンジニアリングとプロ ダクトを成長させ続けられる会社を促進すること Vision Make it Visible 品質、生産性を見える化することで、 課題の発見と健全な成長を促す No Ops, More Code エンジニアに対して開発と事業成長に 注力できる環境を提供する 組織理念 エンジニアが成長でき、居続けたいと思う会社にする 優秀なエンジニアが集まり、育て、居続けられる環境を作ることで 世の中により多くの価値を提供できる プラットフォーム基盤推進室
6. (直近の) DBRE Group’s Value
 ◦ BizReach の DBRE の存在意義
 ➢ Platform を提供することで Mission/Vision を具現化 
 ▪ まずは3大非機能要件の共通化を行い各事業に提供 
 • Provisioning
 • Monitoring
 • Backup
 
 ▪ Platform 化の価値
 • 機能要件に注力できるリソース確保・生産性向上
 • ナレッジを使いまわせることによる社内の人材流動性向上

7. Provisioning Platform Backup/ Masking Platform Monitoring Platform BizReach として最低限必要なパッケージが揃った DBを素早く提供 MySQL パラメータセッティング 管理ユーザーとアプリケーションユーザー設定 … etc プロダクトから切り離された環境を構築 定期的なバックアップ データのマスクを行う 他部署はマスクされたデータを参照できる 定量モニタリングに必要なデータを Datadogに連携 人材の横断的な移動を可能にする まず Platform 化したかったこと

8. Platform Builders
 ◦ 事業に対して Database Platform の提供
 ➢ 個別最適を行わない 
 ▪ 個別機能を開発しないではない 
 ▪ 個別の機能をいかに Platform として昇華させるか 
 
 ➢ ただやるだけだとつまらない 
 ▪ やりたいことは既に枯れたこと 
 ▪ How の部分を今っぽく作れたら楽しくね？ 

9. Backup Platform
10. Backup Platform
 ◦ 雑なイメージ
 Product Account Platform Account 本番 Database ① Share ② Restore ③ mysqldump ④ S3 UPLOAD ⑤ Restore Test
11. セキュリティ関連①
 ◦ Restore をする時点で 監査 Log を全出力
 ➢ 同じ会社内とはいえ他事業のデータ 
 ▪ 自分たちの身を守るためにも、そして事業の方々に 
 安心して任せてもらえるようにするためにも 
 • Database に対する監査ログを出力
 • AWS アカウントそのものに対するログも全て保存
 • 誰からでもそのログはオープンに見えるような仕組みづくりに今後 取り掛かる

12. セキュリティ関連②
 ◦ Restore をする時点でランダムパスワード
 ➢ RestoreしたDatabaseにはヒトはアクセスしない 
 ▪ 毎回ランダムで生成されたパスワードで起動 
 • 必要な処理が完了すればいい
 • システム的にパスワードが保持されているだけでいい
 > response = client.modify_db_cluster( > DBClusterIdentifier='string', > MasterUserPassword='string', > ApplyImmediately=True, > )
13. セキュリティ関連③
 ◦ 必要な処理が終わったら全てお掃除
 ➢ DB Instance から作らせてもらったSnapshotまで 
 ▪ 不要に情報を保持しておかない 
 ▪ Snapshotの保持数に制限もあるので事業の運用に与える影 響を最小限に抑える 

14. Parallel に dump
 ◦ Backup にかかる時間を短縮
 ➢ アプリケーションからのアクセスない 
 ▪ つまり更新されないので 
 • information_schema からテーブルリスト引っ張って
 • その後、テーブル単位でパラレルに dump
 (うちでは TRIGGER や VIEW を基本的に使ってないのでシンプルに) 

15. Restore Test
 ◦ Backupしても戻せなければただのゴミ
 ➢ 同じ Instance 内に Restore して確認 
 ▪ 基本同じはず
 ▪ ここまで終わればあとはよほどのことがない限り 
 触る必要がないので S3に塩漬けておく 

16. Masking Platform
17. Masking Platform
 ◦ Platform として資産を使い回し
 Product Account Platform Account 本番 Database ① Share ② Restore ③ data masking ④ S3 UPLOAD 違うのは ここだけ
18. Masking の運用①
 ◦ Masking Data の使い方
 ➢ Masking されたデータはマーケティング用途で使用 
 ▪ tsv 形式でファイル出力してS3にPUT 
 ▪ そのファイルをマーケティングチームが取りに来て 
 ▪ マーケティング用の BigQuery に入れる 
 • 安心してください、個人情報はマスクしています
 • そして権限ある人しか見れないようにしています

19. Masking の運用②
 ◦ 僕たちの責任範囲
 ➢ 事業から指定されたようにMaskingをすること 
 ▪ Masking Rule 等は事業側で決める 
 • git 上に設定ファイルを commit してもらってそれを使用
 • 誰がいつ変更したのかの証跡を追えるように
 
 責任範囲を明確にすることで自分たちの身を守ることも忘れずに 

20. Masking の運用③
 ◦ (ごく近い) 将来的な展望
 ➢ Masking したデータを Restore した DB に反映 
 ➢ SnapShot を取得
 ➢ 各事業アカウントにShare 
 ➢ それを起動するだけで鮮度の高い検証環境を作れる 

21. Masking Platform
 ◦ 雑なイメージ
 Product Account Platform Account 本番 Database ① Share ② Restore ③ data masking ④ S3 UPLOAD ⑤ UPDATE ⑥ Create Snapshot ⑦ Share 検証用 Masking DB
22. Provisioning Platform
23. Provisioning Platform
 ◦ インスタンスの起動に関しては王道
 ➢ Terraform などで構築(割愛) 
 
 ◦ これからはローカル環境構築も重点的に
 ➢ 本番環境のパラメータグループから必要な情報を取得して 
 ▪ バージョンとか文字コードとか SQL モードとか
 検討中
 ➢ my.cnf を動的に作って 
 ➢ 前日と変わっていたら git に commit 
 ▪ docker-compose でサービス指定したらいい感じにあげれるようにしたい

24. Finally
25. DBRE の概念
 ◦ DBREとは
 ➢ Database に於けるモノゴトを ` Reliability Engineering ` という側面 から解決していく
 ▪ Databaseに対する専門知識 
 ▪ Database Professional としての判断 
 を用いて再帰性のあるプロセスや戦略決定に落とし込むこと 
 
 ➢ DBRE の概念を実行するヒト、役割は DBREs 

26. まだ僕たちの旅は始まったばかり
 ◦ DBREについても勉強中
 ➢ そもそも自分たちでもうまく消化できてない部分も多い 
 ▪ 社内の有志で DBRE 本輪読会をやってます 
 (スラング多すぎて翻訳辛い) 
 ▪ 100% これが正しいなんて定義するには時間がかかるし 会社 にフィットさせるにはもっと時間がかかる 
 • `こうあるべき` ということに固執しすぎず柔軟に 
 私達なりの DBRE を進化させます 

27. 僕たちの活動
 ◦ アプローチ
 ➢ 基本的な部分は今までと変わらない 
 ▪ 環境分離、Backup/Restore、Security、構成管理 , etc.
 
 ➢ 変わっているのはそれを取り巻く環境 
 ▪ DevOps思想の醸成、Cloud・コンテナ技術の爆発的な発展
 ▪ Application に求められるスピード
 ▪ ほとんどを自動化し Engineering によって解決できる土壌が揃ってきてい る

28. 僕たちだけやれるとは思えない
 ◦ なぜなら
 ➢ パラメーターは有限 
 ➢ 装備も有限
 
 もちろん全部できたら
 最強なんだろうけど。。
 
 ならどうする？

29. 1. 社内で仲間を集う
 ◦ 自分の足りないところを仲間で補い合う
 ➢ 各々得意な分野を伸ばしていきつつ 
 ➢ 周りの力を借りて同時に周辺の知識を少しづつ蓄えていく 

30. 2. 社外で仲間を集う①
 ◦ AWS の SA さんとか
 ➢ うちの担当は控えめに言って 最 ＆ 高
 ➢ 稚拙な状態での計画も一緒に叩き直してくれる 

31. 3. 社外で仲間を集う②
 ◦ MySQL 業界には 神 な方々がいっぱい
 ➢ Slack や Twitter で呟くといろんなAPIが反応してくれる 
 ➢ そして優しく送り出してくれる 
 ➢ つまり楽しい

32. 一緒に旅をしてくれる仲間を募集中
 ◦ DBRE グループはできてまだ4ヶ月
 ➢ やらなければいけないこと、やりたいことはたくさん 
 ➢ 今はまだこれまであるべきものを形にしているだけ 
 ➢ 新しいことも手をつけていきたい 
 ➢ 興味がある方はご連絡くださいｍｍ 

33. Thanks!! @_awache Contact me!