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

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

Hello!!  *********** 1. row ********** name: 粟田啓介 nickname: あわっち title: DBRE twitter: @_awache 1 rows in set (0.00 sec) mysql > SELECT * FROM me \G

Slide 3

Slide 3 text

README ✅ この資料は @_awache という個人の独断と偏見により作成したものです。 ✅ 所属する組織の意見を代表するものではありません。 ✅ 合法性や安全性、情報の正確性についても保証できません。カジュアルな会(のはず)なので内容もノリも軽めです。カシュっとしながら楽しんでいただければと思いますｍｍ mysql-casual だけど MySQL のこと少なめです。 ✅ Theme by Template Park. ＞https://template-parks.com/

Slide 4

Slide 4 text

DBRE 始めました

Slide 5

Slide 5 text

Mission プラットフォームを通してエンジニアリングとプロダクトを成長させ続けられる会社を促進すること Vision Make it Visible 品質、生産性を見える化することで、課題の発見と健全な成長を促す No Ops, More Code エンジニアに対して開発と事業成長に注力できる環境を提供する組織理念エンジニアが成長でき、居続けたいと思う会社にする優秀なエンジニアが集まり、育て、居続けられる環境を作ることで世の中により多くの価値を提供できるプラットフォーム基盤推進室

Slide 6

Slide 6 text

(直近の) DBRE Group’s Value  ○ BizReach の DBRE の存在意義  ➢ Platform を提供することで Mission/Vision を具現化   ■ まずは3大非機能要件の共通化を行い各事業に提供   ● Provisioning  ● Monitoring  ● Backup    ■ Platform 化の価値  ● 機能要件に注力できるリソース確保・生産性向上  ● ナレッジを使いまわせることによる社内の人材流動性向上 

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

Backup Platform

Slide 10

Slide 10 text

Backup Platform  ○ 雑なイメージ  Product Account Platform Account 本番 Database ① Share ② Restore ③ mysqldump ④ S3 UPLOAD ⑤ Restore Test

Slide 11

Slide 11 text

セキュリティ関連①  ○ Restore をする時点で監査 Log を全出力  ➢ 同じ会社内とはいえ他事業のデータ   ■ 自分たちの身を守るためにも、そして事業の方々に   安心して任せてもらえるようにするためにも   ● Database に対する監査ログを出力  ● AWS アカウントそのものに対するログも全て保存  ● 誰からでもそのログはオープンに見えるような仕組みづくりに今後取り掛かる 

Slide 12

Slide 12 text

セキュリティ関連②  ○ Restore をする時点でランダムパスワード  ➢ RestoreしたDatabaseにはヒトはアクセスしない   ■ 毎回ランダムで生成されたパスワードで起動   ● 必要な処理が完了すればいい  ● システム的にパスワードが保持されているだけでいい  > response = client.modify_db_cluster( > DBClusterIdentifier='string', > MasterUserPassword='string', > ApplyImmediately=True, > )

Slide 13

Slide 13 text

セキュリティ関連③  ○ 必要な処理が終わったら全てお掃除  ➢ DB Instance から作らせてもらったSnapshotまで   ■ 不要に情報を保持しておかない   ■ Snapshotの保持数に制限もあるので事業の運用に与える影響を最小限に抑える  

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

Masking Platform

Slide 17

Slide 17 text

Masking Platform  ○ Platform として資産を使い回し  Product Account Platform Account 本番 Database ① Share ② Restore ③ data masking ④ S3 UPLOAD 違うのはここだけ

Slide 18

Slide 18 text

Masking の運用①  ○ Masking Data の使い方  ➢ Masking されたデータはマーケティング用途で使用   ■ tsv 形式でファイル出力してS3にPUT   ■ そのファイルをマーケティングチームが取りに来て   ■ マーケティング用の BigQuery に入れる   ● 安心してください、個人情報はマスクしています  ● そして権限ある人しか見れないようにしています 

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

Masking Platform  ○ 雑なイメージ  Product Account Platform Account 本番 Database ① Share ② Restore ③ data masking ④ S3 UPLOAD ⑤ UPDATE ⑥ Create Snapshot ⑦ Share 検証用 Masking DB

Slide 22

Slide 22 text

Provisioning Platform

Slide 23

Slide 23 text

Provisioning Platform  ○ インスタンスの起動に関しては王道  ➢ Terraform などで構築(割愛)     ○ これからはローカル環境構築も重点的に  ➢ 本番環境のパラメータグループから必要な情報を取得して   ■ バージョンとか文字コードとか SQL モードとか  検討中  ➢ my.cnf を動的に作って   ➢ 前日と変わっていたら git に commit   ■ docker-compose でサービス指定したらいい感じにあげれるようにしたい 

Slide 24

Slide 24 text

Finally

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

Thanks!! @_awache Contact me!