1 【関⻄DB勉強会】 ~ 全部⾒せます ~ KINTO テクノロジーズの DBRE とは 粟⽥ 啓介 2024-06-22: 第14回 関⻄DB勉強会 https://kansaidbstudy.connpass.com/event/316348/

Software Engineering と Database 管理の Best Practice を組み合わせたアプローチ 2 Database Reliability Engineering (DBRE) とは n 主な役割 n SLO/SLI を測定し、それに合わせた開発組織へのアプローチ n ⾃動化、⾃律化推進による⽣産性の向上 n Backup/Restore などサービス稼働率の向上 n Database セキュリティ & ガバナンスコントロール n 他分野のスペシャリストとの分野を超えたコラボレーション Database に対する専⾨知識と判断を⽤いてサービスの信頼性を担保すること

Public Cloud の台頭により Database Engineer の必要性が⼩さくなってきている 3 DBRE (DBA) は企業にとって必要か？ n Cloud によって誰でも⼀定のレベルで解決できる⼟壌が揃っている n Cloud 技術の爆発的な発展 n DevOps / SRE 思想の醸成 n AI 技術の進歩 n ⼀⽅で Database そのものに対する基本的なアプローチはこれまでと変わっていない n 環境分離 n 構成管理 n パフォーマンスチューニング n Backup/Restore n Security & Governance 変化しているのは Database を取り巻く周りの環境

4 ⾃⼰紹介 mysql > SELECT * FROM me ¥G ********* 1. row ********* name: 粟⽥ 啓介 nickname: あわっち X(twitter): @_awache role: DBRE(,CCoE) favorite: MySQL 1 rows in set (0.00 sec)

5 KINTO テクノロジーズ株式会社 (KTC) について 2021年04⽉設⽴ 2019年01⽉設⽴

6 KTC における DBRE の⽴ち位置 エンジニア組織： 24グループ 社内のエンジニアの数： 約 350名 アプリケーション開発組織 • KINTO サービス開発 • グローバル ID 基盤開発 • バックオフィスシステム開発 • モバイルアプリ開発, etc. 横断組織 (プラットフォーム 部) • クラウドインフラ • Platform Engineering • SRE (Embedded SRE) • DBRE • MSP (24*365 保守運⽤) • CCoE (クラウド利活⽤推進) プラットフォーム部 クラウド インフラ Platform Engineering SRE DBRE MSP CCoE アプリケーション 開発組織 アプリケーション 開発組織 アプリケーション 開発組織 アプリケーション 開発組織 アプリケーション 開発組織 ・・・

KTC の DBRE は 3名体制が⻑い (業務委託の⽅含む) 7 KTC DBRE のリソース状況 02 03 04 05 06 07 08 09 10 11 12 01 02 03 04 05 06 07 08 09 10 11 12 01 02 03 04 05 06 2024 2023 2022 社 員 1 1 1 1 1 1 2 2 2 3 3 2 2 2 2 2 2 2 3 3 3 3 3 3 3 3 3 3 3 業 委 0 0 1 1 2 2 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 計 1 1 2 2 3 3 3 3 3 4 4 3 3 3 3 3 3 2 3 3 3 3 3 3 3 3 3 3 3 n DBRE を専⾨の組織として⽴ち上げ n 組織化することでのメリットも多い n 今回は組織化したからこそ⾃分たちが出せているアウトプットをダイジェストでお届け n 時間があれば 1つ2つ demo をお⾒せできるかもしれません

なぜ KTC に DBRE が必要だったのか 01

9 Application Engineer と Database Administrator の関係性

10 Cloud によって変わった Database 運⽤の役割

11 Cloud 時代の DBRE の役割

12 KTC における DBRE は横断組織 n ⾃分たちのアウトプットがビジネスに反映されることによって価値提供される n 横断組織はそこにあるだけでは何に使われるか分からない税⾦と同じ n ビジネスに対して良い影響を与えることが重要 n 良い影響とは n サービスの失敗率を下げ、持続可能性を上げるための活動 n エンジニアの⽣産性の向上への寄与 など KTC DBRE の⽬指すべき姿

KTC DBRE の実際の業務 02

⽬標設定全体像 14 KTC DBRE の今年度の⽬標設定

15 KTC DBRE とソフトウェアエンジニアリング KTC の DBRE はソフトウェアエンジニアリングの時間も(意外と)多い (感覚的に6割程度) n リソースは 3⼈、開発以外のタスクもこなしつつ⾼いリードタイムスコア n アジャイル開発など開発⽣産性を上げるための活動を積極的に取り⼊れている n 1⽇1件以上のリリース n 変更のリードタイムは 7.1h 程度とそれなりに早いサイクルを保っている

16 組織横断的に利⽤できる Tool 開発 n スローガン n 個別最適を⾏わない n 個別機能を開発しないのではない n 個別の機能をいかに Platform として昇華させるかを考える n ただやるだけではつまらない n 実現していることは枯れたこと n How の部分をモダンに楽しく n 今回共有した内容は⼀⾔で⾔うとドキュメントを⾃動⽣成したり、踏み台サーバを使いたい時に構築しているだけ n そこに DBA としてのナレッジと AWS の技術を組み込んで実現することで楽しみながら開発 DBRE Platform Tools

17 n AWS n Amazon API Gateway n Amazon Athena n Amazon Aurora for MySQL n Amazon Bedrock n Amazon CloudWatch n Amazon DevOps Guru n Amazon DynamoDB n Amazon EC2 n AWS Lambda n AWS Secrets Manager n AWS Step Functions KTC DBRE を⽀える技術 n 開発⼿法 n Scrum n 開発⾔語 n Golang n Monorepo 管理 n Nx n CICD n GitHub Actions n Infrastructure as Code n Terraform KTC はたまたま AWS をメインクラウド、MySQL をメインの RDBMS として利⽤しているが、 基本的にインフラ基盤や RDBMS は何であっても代⽤可能 (と思っています。。)

18 Cloud の強みを活かしてある程度 Governance と Agility を両⽴させることができる n Governance を適⽤するためには Agility を犠牲にしてしまうこともある n Cloud を正しく活⽤することでそれぞれの効率を最⼤化する n どのレベルまで確保できるかが DBRE としての腕の⾒せ所 Governance vs Agility ?? Governance Agility

KTC DBRE のサービス・ツールカタログ 03

20 KTC DBRE のツール・サービスカタログ⼀覧 ツール・サービスカタログ 種別 できること どうゆう時に使う？ Aurora 3.0 移⾏ DBRE 提供サービス DBRE チームが Aurora 2 系から 3 系への DB 移⾏を実施。そ の他移⾏に伴う事前調査の実施など、⼿厚く伴⾛ Aurora クラスタを 3 系にバージョンアップしたい時 Aurora マイナーバージョンアップ通知 DBRE 提供サービス Aurora のバージョンアップが必要なタイミングで通知（現状は DBRE チームの⽅で⾃動検知後、slack で⼿動連絡） 必要なタイミングで通知されるので気にしなくてOK DBRESlackApps (SlowQueryDigest) Slack App 特定の期間内に発⾏された DB のスロークエリログを集計し、 解析しやすい形式でファイル出⼒できる スロークエリログを解析したい時 PowerPole Slack App ⼀定期間だけ有効な個⼈専⽤の踏み台サーバーの構築を Slack から実施できる 承認制で、申請から承認、結果の通知まで Slack で完結 承認制でセキュアな踏み台サーバー運⽤の仕組みを導⼊し たい時 PowerPole Tools コマンドラインツール PowerPole で⽴ち上げた踏み台サーバー上で、DB に関する各 種オペレーションを⾃動で実施 • DB ユーザー新規作成＆SecretsManager への登録 • DB のマイナーバージョンアップ実施 • DB ユーザーを新規作成したい時 • DB のマイナーバージョンアップを実施したい時 DB Catalog (shenron) DB 情報のカタログ ER 図やスキーマ定義の情報など、様々な情報を確認できる • ER 図を確認したい時 • スキーマを確認したい時 • DB のデータサイズを確認したい時 • DB に関する推奨の修正事項を確認したい時 DBStatsCollector モニタリングツール performance_schema などの DB 内部情報を定期的に S3 に収集し、Athena から SQL ベースで事後調査できる DB ロック競合起因のタイムアウトエラーの原因を調査した い時 Aurora DB PasswordRotation セキュリティソリューション DB ユーザーの定期的なパスワードローテーションを⾃動化できる GISS に記載されている、DB のシークレットローテーションの 要件に簡単に準拠したい時 Database に対するツール提供やオペレーションサポートなどを提供

2024年10⽉末で Aurora 2.0 は EOL が決まっている 21 Aurora 3.0 移⾏ n Aurora Version UP に障害となりうる項⽬をチェックし事前に修正 n 基本的には util.checkForServerUpgrade() の結果をベースに⼀部独⾃機能を追加 n 下記はチェック項⽬の⼀部 チェック項⽬ エラーレベル 概要 PK 存在チェック Warning PK のないテーブルがあった場合、そのテーブル⼀覧を抽出 空スキーマチェック Notice テーブルの存在しないスキーマがあった場合、そのスキーマ⼀覧を抽出 utf8mb4 チェック Warning utf8mb4 ではない DB オブジェクトの⼀覧を抽出 ROW_FORMAT チェック Warning テーブルの ROW_FORMAT が COMPACT か REDUNDANT の⼀覧を抽出 予約語チェック Error 予約語が使⽤されているスキーマの⼀覧を抽出 特殊⽂字使⽤チェック Warning 「- (ハイフン)」 が使⽤されている DB オブジェクトの⼀覧を抽出 カラム型チェック Warning 同じカラム名で別のカラム型を使⽤しているカラムの⼀覧を抽出

22 Aurora 3.0 移⾏ バージョンアップに必要なレポートを随時作成 n あくまでも主体はプロダクト n DBRE は移⾏がスムーズに⾏われるように裏側の サポートに徹している n 移⾏に関しては DBRE で開発した 移⾏ツールを利⽤して実施

23 Aurora マイナーバージョンアップ通知 Aurora 3.0 以降、KTC では⾃動マイナーバージョンアップを ON に設定している n この設定によりマイナーバージョンアップが予期せぬタイミングで発⽣する可能性がある n バージョンアップの発⽣⾃体は避けられないが、事前に把握できることが重要 n マイナーバージョンアップはフランクに⾏われることが多い印象 n 前⽇にこの通知を確認したものの、メールでの連絡は事後というケース n 前⽇にこの通知を確認したものの、当⽇になってキャンセルになったケース n 基本は ZDP (Zero Downtime Patch) を信頼 n 失敗する可能性もあるので⼼の準備として背後にあるトリガーを認識する

24 DBRESlackApps (SlowQueryDigest) 該当の DB Cluster で発⽣した SlowQuery を分析してファイル出⼒ n Slack APP として提供 n Aurora MySQL が発⾏する SlowQuery Log を集計した結果を解析しやすい形式でファイル出⼒ n SlowQuery Log の集計には 「pt-query-digest」 を利⽤

25 PowerPole ガイドラインに準拠したインスタントな踏み台サーバを構築する Platform AWS Cloud 稼働中 Aurora ① 作業リクエスト ② リクエストメッセージ ③ リクエスト承認 EC2 Instance with SSM Agent ④ 踏み台サーバ構築 ⑤ 認証情報 ⑥ Login ⑦ 実作業 ⑦ オペレーションログの保存 ⑧ 踏み台サーバの削除 セキュリティチーム 必要に応じて確認 RDS Audit Log SSM Agent Log ⑦ Audit Log の保存 承認者⽤ Private チャンネル 作業⽤ Public チャンネル

26 PowerPole Tools PowerPole で⽴ち上げた踏み台サーバにプリインストールされている DBRE 内製ツール n インフラでしかできなかった作業や⼿動で⾏うには煩雑な作業を誰でも簡単に実施可能 n DB ユーザーの新規作成 + Secrets Manager への Secrets 登録 n GRANT 後、Secrets の登録までを⾃動化 n DB のマイナーバージョンアップ実施 n Aurora のマイナーバージョンアップをプロダクトで実施可能

27 DB Catalog (shenron) information_schema からさまざまな情報を取得し、可視化 n Database の `今` の状態を `正しく知る` ことでプロダクトに対する⽣産性を向上 n ⾃動⽣成しているもの n ER 図 n ddl 情報 n データサイズ n my.cnf n DB 推奨設定/修正事項

28 DB Catalog (shenron) information_schema からさまざまな情報を取得し、可視化 n Database の `今` の状態を `正しく知る` ことでプロダクトに対する⽣産性を向上 n ⾃動⽣成しているもの n ER 図 n ddl 情報 n データサイズ n my.cnf n DB 推奨設定/修正事項

29 DB Catalog (shenron) information_schema からさまざまな情報を取得し、可視化 n Database の `今` の状態を `正しく知る` ことでプロダクトに対する⽣産性を向上 n ⾃動⽣成しているもの n ER 図 n ddl 情報 n データサイズ n my.cnf n DB 推奨設定/修正事項

30 DB Catalog (shenron) information_schema からさまざまな情報を取得し、可視化 n Database の `今` の状態を `正しく知る` ことでプロダクトに対する⽣産性を向上 n ⾃動⽣成しているもの n ER 図 n ddl 情報 n データサイズ n my.cnf n DB 推奨設定/修正事項

31 DB Catalog (shenron) information_schema からさまざまな情報を取得し、可視化 n Database の `今` の状態を `正しく知る` ことでプロダクトに対する⽣産性を向上 n ⾃動⽣成しているもの n ER 図 n ddl 情報 n データサイズ n my.cnf n DB 推奨設定/修正事項

32 DBStatsCollector データベースの内部情報を定期的に収集・保存するプラットフォーム n MySQL のロック競合の原因特定を事後調査するための仕組みが存在しなかった n performance_schema や information_schema を⾒ればわかるが、発⽣しているタイミングでしか確認 できない n 定期的にこれらの情報を取得して溜めておくことで事後調査可能な状態に

33 Aurora Password Rotation データベース接続のためのパスワードを⾃動で定期的にローテーションする n KTC では DB のパスワード変更を 90⽇以内で⾏うことが求められている n DB 接続情報を Secrets Manager から取得することを前提とすることで DB 側でパスワード変更されても 即時反映とはならないため次のローテーションまでにデプロイし直せば良い n AWS の交代ユーザー戦略を採⽤

DBサポートや新技術検証、企業価値向上施策など 34 その他 n DB サポート n DB 起因のトラブル対応 n DB 設計相談 n プロダクトと AWS のコミュニケーション Hub n 社内勉強会 n 新技術検証 n MySQL 8.0 パラメータ n Dual Password n Aurora ZeroETL n ⽣成 AI n 企業価値向上施策 n 外部イベント登壇 n イベント開催 n テックブログ執筆

KTC DBRE の今後の取り組み 04

⽬標設定全体像 36 KTC DBRE の今年度の⽬標設定

本⽇のお話 37 ⽣成系 AI を活⽤したスキーマレビューの提供

1. ⾃分たちのスキルの幅を広げること (≒⾯⽩そう) 38 なぜ⽣成系 AI を導⼊しようとしたのか n エンジニアである以上この⽣成系 AI の波に乗らない理由がない n エンジニアだけではなくさまざまな業種の⼈たちが活⽤している n 使わなくても仕事はできる、が Word や Excel と同じように様々な⼈・業種で⽣成系 AI を 使うことが当たり前になる時代になる (と個⼈的には思っている) n どうやって使うかによって今でも業務効率を⼤幅に改善可能 ⾃分たちの当たり前レベルを上げることで 今の市場価値を⾼める 将来的な市場価値を下げない

2. Database のスキーマは⼀度作成されると後戻りしづらい 39 なぜ⽣成系 AI を導⼊しようとしたのか n Database の影響範囲はそれを使⽤する全てのサービス n アプリケーションそのものに対する影響 n 外部連携しているサービスへの影響 n (割とある) 忘れ去られた管理システム n 影響範囲が広いため調査と調整コストが⼤きくなりがち n アプリケーションコードで何とかしようとするとマジカルな仕様ができてしまう n マジカルな仕様は調査・学習コストを上げ、属⼈化や開発⼯数の増加を引き起こす 早い段階でどれだけ適切に設計できるかは開発⽣産性に⼤きく影響してくる

3. 様々な意味で Review に対するハードルを下げる 40 なぜ⽣成系 AI を導⼊しようとしたのか n ⼈がやるか AI がやるか ≒そこにある感情や状況を評価するかどうか n ⼈は⾃分にできないことを聞きづらい n こんなこともできないのかと思われたくない n 何が分からないのか分からず、質問の仕⽅を考えることに時間がかかってしまう n 聞く⼈が忙しい、など状況を何となく察してしまう n 忙しそうだと聞けないなどが発⽣し時間をかけて⾃⼰解決するように振る舞ってしまう n 結局⽣産性という観点ではマイナスに働いてしまう AI なら感情や状況を気にせず質問できる

3. 様々な意味で Review に対するハードルを下げる 41 なぜ⽣成系 AI を導⼊しようとしたのか n ⼈に指摘されることと AI に指摘されることでは受け⽌め⽅が違う n サービスにはその歴史と携わった⼈たちの想いがある n Review で正論で指摘されると反論できない⼼理も働きやすい n バックグラウンドやドメイン知識を持たない横断組織が⾏ってしまうとハレーションが溜まりやすい n (特に Database 関連の Review になるとお作法に従っているかどうか、という観点で Review しがち) AI であれば、「機械だしまぁ⼀意⾒として聞いておくか」くらいの軽い気持ちで受け⽌められる 間違っていても、(今なら) AI だしな、という反応ができる 期待通りの結果が得られなければ素早く聞き直すことができる

42 DBRE が⾨番ではなくエンジニアと伴⾛できる存在になること n ルールや Review だけで対応できるほど事業の成⻑スピードは遅くない n ⼼理的ハードルが低く即時性の⾼い AI によるサポートを提供することで開発⽣産性に寄与する n DBRE が⾏うのは⽣成系 AI を活⽤したツールを開発して終わりではない n もちろん使われなければ意味がない n ⾃分たちの思いを仕組みに乗せ続けることで、(意識せずとも) DBRE が伴⾛している状態を形成することができる n (そして忘れてはいけないのは DBRE のやることはこのほかにもたくさんある) (今の) ⽣成系 AI の活⽤に期待していること

まとめ 05

44 Application Engineer と Amazon Web Service をつなぐ Hub としての活動 KTC の DBRE の役割 専⾨性 早 遅 低 ⾼ Application Engineer Amazon Web Service • サービスの稼働率を守る • サービスの成⻑を促進する • Database そのものの稼働率を守る Database Reliability Engineer • 現場のエンジニアが事業成⻑に注⼒できる環境を提供するための役割 • サービスの稼働率を守る • 現場のエンジニアの⽣産性を⾼める • 企業の継続的成⻑を促進する • 内的要因、外的要因から Database を守る レスポンス(*) (*) ここでのレスポンスとはサービスに対する適⽤速度、トラブルが発⽣した時の応答速度、必要なデータを抽出するなど通常オペレーションで必要な作業時間などが含まれる

45 Cloud の強みを活かしてある程度 Governance と Agility を両⽴させることができる n Governance を適⽤するためには Agility を犠牲にしてしまうこともある n Cloud を正しく活⽤することでそれぞれの効率を最⼤化する n どのレベルまで確保できるかが DBRE としての腕の⾒せ所 Governance vs Agility ?? Governance Agility

46 Database の Reliability を向上させるための役割として組成 n Database の知識を還元して KTC 全体の Reliability を守る n その⼿段として Engineering で解決する道を選択 n Cloud を適切に活⽤して Agility を確保しつつ Database の Security と Governance を守る n Platform へと昇華させ KTC 全体に展開することでビジネスに良い影響を与え続ける KTC における DBRE の役割 Database Reliability Engineering というアプローチ

⽬標設定全体像 47 KTC DBRE の今年度の⽬標設定

48 なぜなら個⼈が持てるパラメータや装備は有限だから DBRE だけで何かがやれるとは思えない やりたいことはたくさん⽣まれる もちろん全部できたら最強だがスキルもリソースも限られている プロダクトエンジニアの視点で考えないと 価値がわからない

49 ⾃分たちに⾜りないところを補っていただく n 得意な分野を伸ばしていきつつ n 周りの⼒を借りて、同時に周辺の知識を少しずつ蓄えていくことで n 少しずつでも価値を現場のエンジニアのみなさんに届ける 横断組織は⾨番ではなく伴⾛型になることで 現場のエンジニアの皆さんに価値を届ける だからこそ現場のエンジニアや AI の⼒を借りることが重要

Help Us Shape the Future ! KINTO テクノロジーズでは DBRE を始め、様々な職種で仲間を募集しています！ 少しでも興味がありましたらお気軽にご連絡ください

51 mysql > SELECT ‘Questions’ FROM you;

52 mysql > SELECT ‘Thank you’ FROM me;

THANK YOU!

No content