20190805_DBRE_Night

Transcript

1. そーだいなる DBRE Night #1 ~ ぼっちにならない、横断的DBAの作り方 ~ https://www.bizreach.co.jp/ 
 プラットフォーム基盤推進室


   DBRE 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 という個人の独断と偏見により作成したものです。 ✅ 所属する組織の意見を代表するものではありません。 ✅ 合法性や安全性、情報の正確性についても保証できません。 カジュアルな会(のはず)なので内容もノリも軽めです。

   カシュっとしながら 楽しんでいただければと思いますｍｍ ✅ Theme by Template Park. ＞https://template-parks.com/

4. 1. 横断組織としてのDBA


5. 横断組織 誕生
 ◦ 2018年 8月 ➢ インフラ・SREメンバーが集まって構成 ▪ DB系は一人 ▪

   当時の MGR「あわっちをどうしたらいいか悩むわ」 • ならなぜ僕をここに呼んだ Σ(ﾟﾛﾟ;） ▪ 一人で組織横断DBAってどうなの？ • 最初は組織横断DBAとして何をしたらいいかが分からなかった • まずは何をしたいか、自分の目標設定からスタート

6. 自分の活動の軸を決める(1)
 ◦ 事業の成長を妨げる要因にならない ➢ 例えば 3年後に売り上げが 10倍 〜 となったとしても ▪

   成長についていける基盤を作る必要性 ▪ Database が要因となって事業戦略を諦めさせない ▪ 同時に事業の成長スピードを上げる手助けを行う

7. 自分の活動の軸を決める(2)
 ◦ 事業に対するリスクを最小化 ➢ 外部要因によるリスク ▪ 個人情報流出の危険性の排除 ➢ 流動的な人の移動を可能にさせる標準化 ▪

   個別最適の削減 • 標準 Backup/Restore の仕組み • 共通モニタリング

8. ビズリーチのDBA事情
 ◦ 専属のDBAがいる組織とそうでない組織 https://www.bizreach.co.jp/

9. DBAはいなくてもアプリは動く
 ◦ ちょっとぶっ飛びすぎ感はあるけれども ➢ 実際問題 DBA はエンジニア全体からするとかなり希少 ▪ 大抵は問題が起こった時 DBちょっとできる人が筋肉運用

   ▪ インフラエンジニア と呼ばれる人が兼任することが多い気が する ➢ アプリケーション設計や実際に流れるクエリの組み立ては アプリケーションエンジニアが行う ▪ DBA による Review がなくても自由に作ればいい • 最近は ORM も充実しているので。。。

10. なぜDBAが必要か
 ◦ アプリケーションの稼働率に直結するから(雑) ➢ 色々なタスクはあれど、基本的にはここに辿り着くのでは？ ▪ Provisioning ▪ Backup・Restore ▪

    セキュリティ ▪ パフォーマンス, etc.

11. ビズリーチの課題
 ◦ DBA そのもののリソース不足 ➢ DB運用に必要な最低限のモノゴトが無い ▪ DB にかける時間が考慮されていない ▪

    Monitoring/Backup/Restore など ➢ 各事業で同じものを別々の方法で作っている ▪ Monitoring/Backup/Restore など ➢ DB設計などの相談先の不在 ▪ アプリケーションのソースコードと密結合された DBスキーマ ▪ それまでの開発の文化が設計にそのまま反映されてしまう • 複数の意味を持つカラムの存在 • 先人のマジカルな仕様の聖域化 など

12. 割とある解決策
 ◦ 中央集権の組織を作ってそこで管理運用を行う ➢ Provisioning に必要な秘伝のタレができて ➢ スキーマやクエリ Review のフェーズができて

    ➢ 大量に来る依頼を無心に捌く

13. 自分が中央集権をしたら
 ◦ こんな 横断DBA になりそう ➢ ゲートキーパー ➢ サイロ化 ➢

    アプリケーションエンジニアとの無意味な壁、確執 ➢ アプリケーションの求めるスピードについていけない

14. やりたいことを整理していく中で
 ◦ とあるDBAからの一言 ➢ DBRE じゃん、それ ▪ なにそれ？！ ➢ O'REILLY

    本出てたので即購入 ▪ 英語版のみ ▪ パラパラとめくって惚れた

15. 2. ビズリーチ流の DBRE


16. DBRE が守るべきものを定義
 ◦ (仮置きで) 稼働率と置いた ➢ 稼働率って具体的には？ ▪ DB インスタンスとしての稼働率

    ▪ 企業としての稼働率 ▪ ヒトとしての稼働率

17. DBRE グループ 稼働率の定義
 ◦ DB インスタンスとしての稼働率 ➢ 直接的には 各プロダクトが守るべきもの ➢

    間接的に守る手段を DBRE としての稼働率として定義 ▪ Backup ▪ Monitoring ▪ Provisioning etc. 品質と信頼性を一本化するためのアクション 本質的には各プロダクトに存在する

18. 開発部署を雁字搦めにしない
 ◦ できる限りルールだけを持ち込まない ➢ ルールを取り入れたければ `Engineering` によって解決 ▪ Backup を必ず取得してください

    ↓↓ ▪ Backup の為の Platform を作ったので権限だけ 設定してもらえればこちらでやらせていただきます

19. DBRE グループ 稼働率の定義
 ◦ 企業としての稼働率 ➢ 各部署のサポート ▪ 現段階では ビズリーチ、キャリトレに対して実施

    • DBA が存在するところでまずは実施 • DBA がいることによる課題の吸い上げ、 アプローチ方法 などを一緒に実施できる ▪ このナレッジを横展開していく土台作りの段階

20. ナレッジの横展開
 ◦ DBAがいない部署に展開するために ➢ できる限り コード化する ▪ PITR が必要なら •

    画面からぽちぽちしていく作業をコマンドにする • 定期的にテスト実行することで信頼性も上げる ▪ 大量の Slow Query をなんとかしたい • Cloudwatch に Slow Query を吐いておいて • 時間指定で取得して pt-query-digest に喰わせる コマンドにしてみる • クエリチューニングの判断材料に

21. DBRE グループ 稼働率の定義
 ◦ ヒトとしての稼働率 ➢ 人材育成 ▪ 新卒研修、DB設計ハンズオン ▪

    DB設計相談 ▪ クエリチューニング ➢ 属人化排除 ▪ Platform 化

22. DBRE グループ の今後の理想像
 DBRE 推進していく中で新しい技術などを積極的に取り入れて • 社内のプラットフォームだからこそ、ある程度の自由が許される • 周りから見て DBRE

    って面白そうと思ってもらえるような技術の選定をしながら • 共通プラットフォームとしての機能を開発していき • 迷える若手がいた際には 「俺んとこ来ないか？」 • って自信を持って言える組織にしたい • いつでも SWE、QA、SRE などのロールに柔軟に Job Change できれば更によし

23. まとめ
 ◦ ぼっちにならない為に ➢ まずは周りを巻き込む基盤を作る ▪ ルールで雁字搦めにしない • 誰でも同じことができる仕組みを作って協業する ➢

    Database を聖域化しすぎない ▪ DBA は希少かもしれないが エンジニアはたくさんいる ▪ その人たちの強みを上手く活かしつつヒトのサイクルも考えながら組織づ くりを進める

24. 3. DBRE 本との歩き方


25. Database Reliability Engineering
 ◦ オライリー本 ➢ 英語版しかない ▪ Amazon で買うのが一番安い

    • 古巣の本屋さんとかあるけど ¥12,096- とか。。 • とりあえずイギリスから届く

26. DBRE本 輪読会
 ◦ 英語そんなに得意じゃない人材なので ➢ しっかり読むためにはまずは写経 ▪ 某翻訳さんと 某検索エンジンさんのコンボ •

    大枠をそのまま翻訳にかけて • 分からないところは句や節で ggrks すると スラングにも多少は対応できた • 社内の有志が巻き込まれてくれて輪読会実施中

27. 4. お知らせ


28. dbtech showcase 2019
 ◦ BizReach から 3名が登壇します ➢ 応援よろしくお願いしますｍｍ

29. Thanks!! @_awache Contact me!