1 横断組織による企業の開発⽣産性と ⾮機能要件強化のための実践的ガイド 2024-03-22: より早く、より楽しく。組織が協働するための開発⽣産性 https://developer-productivity-engineering.connpass.com/event/312056/

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. 横断組織 (プラットフォーム G) • クラウドインフラ • Platform Engineering • SRE (Embedded SRE) • DBRE • MSP (24*365 保守運⽤) • CCoE (クラウド利活⽤推進) プラットフォームグループ クラウド インフラ Platform Engineering SRE DBRE MSP CCoE アプリケーション 開発組織 アプリケーション 開発組織 アプリケーション 開発組織 アプリケーション 開発組織 アプリケーション 開発組織 ・・・

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

8 Application Engineer と Database Administrator の関係性

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

10 Cloud 時代の DBRE の役割

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

KINTO テクノロジーズ DBRE による 開発生産性との関わり方 02

KTC DBRE は開発⽣産性と直接関係ない？ 13 開発⽣産性と KTC DBRE n 横断組織は直接売り上げに貢献する組織ではない n レベル１⽣産性とレベル２⽣産性にどのようにアプローチするかがポイント 参照: 開発⽣産性について議論する前に知っておきたいこと https://qiita.com/hirokidaichi/items/53f0865398829bdebef1

14 Database に関するオペレーションはちょっとした⼿間で補完できることが多い n 「ちょっとした⼿間」もエンジニア全体の⼯数で⾒ると⼤きくなる n ちょっとした⼿間を簡略化、標準化することは全体の Agility に貢献できる n Database Document の⾃動⽣成 n 企業のガイドラインに適⽤した Platform の提供, etc. n 必ず⾏うべき設定や各サービスのお困りごとを解決する n スキーマレビュー、設計サポート n SlowQuery の対応サポート n トラブル対応サポート, etc. 現場のエンジニアの⽣産性を⾼める

15 Database に関するオペレーションはちょっとした⼿間で補完できることが多い n 「ちょっとした⼿間」もエンジニア全体の⼯数で⾒ると⼤きくなる n ちょっとした⼿間を簡略化、標準化することは全体の Agility に貢献できる n Database Document の⾃動⽣成 n 企業のガイドラインに適⽤した Platform の提供, etc. n 必ず⾏うべき設定や各サービスのお困りごとを解決する n スキーマレビュー、設計サポート n SlowQuery の対応サポート n トラブル対応サポート, etc. 現場のエンジニアの⽣産性を⾼める

認知しないといけない重要なポイント 16 Database は動的に変化する n Database のデータは常に変化している n アプリケーションのリクエストに応じたデータ更新 n データ量は常に変化している n Database のテーブル定義やパラメータは Dynamic に変更可能なものも多い n デプロイに対応したスキーマ変更 n リクエストに増加に応じた max_connections の変更などのパラメータチューニング n Dynamic でないものもありますがここでは割愛します

最低限必要な Database ドキュメント 17 開発時に必要な Database ドキュメント n ER図 n データベースの構造を視覚化し、データ間の関係を理解しやすくする n テーブルの設計やデータの流れを把握しやすくする n DB パラメータ⼀覧 n Database に設定されているパラメータの⼀覧 n max_connections や sql_mode などアプリケーションの動作に影響を与えるものも多い 参照: 9.3.5 Documenting the sakila Database https://docs.oracle.com/cd/E17952_01/workbench-en/wb-documenting-sakila.html mysql> SHOW VARIABLES; +--------------------------------------------------------+---------------------------+ | Variable_name | Value | +--------------------------------------------------------+---------------------------+ | activate_all_roles_on_login | OFF | | auto_generate_certs | ON | | auto_increment_increment | 1 | | auto_increment_offset | 1 | | autocommit | ON | | automatic_sp_privileges | ON | | avoid_temporal_upgrade | OFF | | back_log | 151 | … | wait_timeout | 28800 | | warning_count | 0 | | windowing_use_high_precision | ON | +--------------------------------------------------------+---------------------------+

現場のエンジニアの⽣産性を⾼める 18 KTC DBRE が実践する現場の開発⽣産性との向き合い⽅ n KTC には 5リージョンに 200+ の Aurora Cluster が存在している (* dev/stg など開発環境を含む) n Database は⽣モノ n ドキュメントには正確性が求められるがその運⽤に対する⾟みも。。 n データベースの設定は動的に変更が加えられる n ドキュメントの更新は⾯倒な作業で後回しになりがち n コードの様に変更履歴をもれなく保存しているパターンは少ない n 数が多くなってくるとミスも発⽣しやすい n 変更し忘れたことに気づけない罠も割と多い n 何よりモチベーションが保てない

Database ドキュメントの⾃動⽣成 19 KTC DBRE が実践する現場の開発⽣産性との向き合い⽅ n 稼働している全ての Database から動的にデータを取得し、ドキュメントを⾃動⽣成 n ER 図 n Database パラメータ⼀覧 n 設定ファイル n DDL (markdown) n データサイズ n S3 に PUT することで誰でも最新情報を確認可能な状態に

Demo

21 Database に関するオペレーションはちょっとした⼿間で補完できることが多い n 「ちょっとした⼿間」もエンジニア全体の⼯数で⾒ると⼤きくなる n ちょっとした⼿間を簡略化、標準化することは全体の Agility に貢献できる n Database Document の⾃動⽣成 n 企業のガイドラインに適⽤した Platform の提供, etc. n 必ず⾏うべき設定や各サービスのお困りごとを解決する n スキーマレビュー、設計サポート n SlowQuery の対応サポート n トラブル対応サポート, etc. 現場のエンジニアの⽣産性を⾼める

22 Database 運⽤に求められることは年々厳しくなっている n データはその重要性から外部要因の変化による影響も受けやすい n 政治、法律、世論 などの変化 n 個⼈情報保護法は定期的に改定されており改定の度に罰則が厳しくなる傾向にある n GDPR などグローバル標準への追従 内的要因、外的要因から Database を守る

23 Database 運⽤に必要とされる要件 KTC の Database 運⽤ガイドライン (⼀部抜粋) カテゴリ 概要 ログ • ログの改竄ができないこと • ⾏われたオペレーションが全て記載されていること • オペレーションを⾏なった個⼈を特定することが容易であること ユーザー/パスワード管理 • オペレーションに応じた権限が都度付与されること • 共通ユーザーを使⽤しないこと • パスワードには⼗分な⻑さと複雑さがあること • 定期的にパスワードが更新されること アクセス管理 • いつ、誰が該当作業を承認したのかがわかること • 作業完了後そのアクセスはできなくなること 脆弱性対応 • 脆弱性への対応が速やかに展開されること

24 DB に関連するオペレーションのために専⽤の EC2 インスタンスを構築 KTC では踏み台サーバを利⽤している AWS Cloud Amazon EC2 for Bastion Aurora MySQL Amazon CloudWatch AWS Secrets Manager SAML 認証 DB 接続に必要な password 共通ユーザー / password Audit Log

25 KTC ガイドラインに則るためには課題が多い 踏み台サーバを運⽤していく上での課題 AWS Cloud Amazon EC2 for Bastion Aurora MySQL Amazon CloudWatch AWS Secrets Manager SAML 認証 DB 接続に必要な password 共通ユーザー / password Audit Log 常時稼働しており、セキュリティパッチの 適⽤などの運⽤が発⽣ 踏み台にログインできれば誰でも強権限 でオペレーション可能 共通ユーザーを利⽤されると 誰が、いつ、何をしたのかを確認することが困難になる

Governance を適⽤するために Agility を犠牲にしてしまう 26 ガイドラインに愚直に準拠する n 仮に対応するとしたならば。。 n Jira チケットなどでワークフローを作成 n マネージャー承認をもらう n 承認を確認した上で踏み台サーバを構築する n Database に接続するユーザーやそのパスワードを都度作成 n 作業が終わったらその踏み台サーバと Database に登録したユーザーを削除する 予定作業ならもしかしたらできるかもしれないが、リソースも膨⼤になり トラブル対応など1分1秒を争うことが発⽣した場合に 都度このフローを回すことは現実的に不可能

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

Demo

29 全体像: Architecture Operator Approver リクエスト⽤ Public チャンネル API Gateway Request 処理⽤ Lambda Function 承認者⽤ Private チャンネル 承認処理⽤ Lambda Function API Gateway 承認 or 否認 AWS Cloud AWS Step Functions workflow 承認 否認 承認 EC2 構築 Setup ⽤ Lambda Function 専⽤ EC2 Instance 稼働中の Aurora CREATE USER 終了 10 分前通知⽤ Lambda Function Slack DM Wait 終了処理⽤ Lambda Function Wait Create EC2 Instance Terminate EC2 Instance DROP USER CloudWatch Logs CloudWatch Logs Security Team EC2 構築⽤ Lambda Function DynamoDB (作業承認ログ / SFn ステータス管理) Secrets Manager (DB ワンタイムパスワード管理)

30 Database 運⽤に必要とされる要件を Engineering で解決 DBRE Platform によるガイドライン準拠 カテゴリ Before After ログ • ログの改竄ができないこと • ⾏われたオペレーションが全て記載されていること • オペレーションを⾏なった個⼈を特定することが容易であること • Audit Log / SSM Log の適切な利⽤ • DB のユーザー名をSlack のメールアドレスの @ より前を使⽤することで個⼈の特定が容易 ユーザー/パスワード管理 • オペレーションに応じた権限が都度付与されること • 共通ユーザーを使⽤しないこと • パスワードには⼗分な⻑さと複雑さがあること • 定期的にパスワードが更新されること • オペレーションリクエスト時に必要な権限を申請 • 都度 DB にユーザー登録を⾏う • パスワードは要件を満たすためのプログラムで 毎回ランダムで作成 アクセス管理 • いつ、誰が該当作業を承認したのかがわかること • 作業完了後そのアクセスはできなくなること • 全てのプロセスを DynamoDB に登録 • 作業完了後そのリクエストで作成した DB ユーザーや EC2 インスタンスを削除 脆弱性対応 • 脆弱性への対応が速やかに展開されること • 踏み台を起動するタイミングで yum update を実施

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

32 n AWS n Amazon API Gateway n Amazon Aurora for MySQL n Amazon CloudWatch n Amazon DynamoDB n Amazon EC2 n AWS Lambda n AWS Secrets Manager n AWS Step Functions DBRE を⽀える技術 n 開発⼿法 n Scrum n 開発⾔語 n Golang n Monorepo 管理 n Nx n CICD n GitHub Actions n Infrastructure as Code n terraform n 特にこだわったポイント n Slack App n 承認者には都度確認を強いるため負荷を減らす必要があった n 平均構築時間 n 1分40秒程度

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

KINTO テクノロジーズ DBRE の今後の活動 03

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

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

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

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

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

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

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

まとめ 04

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

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

レベル１⽣産性とレベル２⽣産性に対して⾃分たちの知⾒・経験を提供 45 開発⽣産性と KTC DBRE n ⼈がやるには煩わしいこと、ミスが起こりやすいポイントにアプローチ n これらを通じて間接的にレベル３⽣産性へ関与していく 参照: 開発⽣産性について議論する前に知っておきたいこと https://qiita.com/hirokidaichi/items/53f0865398829bdebef1

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 の⼒を借りることが重要

50 2024-03-29 19:00 ~【KURAND社 協賛】仕事とお酒を愛でる「ソースコード」レビューまつり！ n ⼀緒にソースコードレビューの世界を深掘りしませんか？ n ソースコードレビューに対する熱い想いを語る LT 祭りが開催されます！ n まだ空きがあるので是⾮ご参加ください！ お知らせ https://kinto-technologies.connpass.com/event/310504/

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

52 mysql > SELECT ‘Questions’ FROM you;

53 mysql > SELECT ‘Thank you’ FROM me;

THANK YOU!

No content