SREKaigi.pdf

2025−01-26: SREKaigi「実践: Database Reliability Engineering ~ クラウド時代のデータベースエンジニアの役割 ~」の登壇資料です

Transcript

1. 1 【SREKaigi】 実践: Database Reliability Engineering ~クラウド時代のデータベースエンジニアの役割~ 粟田 啓介 2025-01-26: SREKaigi https://2025.srekaigi.net/
2. 2 自己紹介 mysql > SELECT * FROM me \G *************** 1. row *************** name: 粟田 啓介 nickname: あわっち X(twitter): @_awache company: KINTO テクノロジーズ株式会社 role: DBRE/SRE MGR favorite: MySQL 1 rows in set (0.00 sec)
3. 3 KINTO テクノロジーズ株式会社 (KTC) について 2021年04月設立 2019年01月設立
4. 4 KTC における DBRE / SRE の立ち位置 エンジニア組織： 約 30グループ 社内のエンジニアの数： 約 350名 アプリケーション開発組織 • KINTO サービス開発 • グローバル ID 基盤開発 • バックオフィスシステム開発 • モバイルアプリ開発, etc. 横断組織 (プラットフォーム開発部) • QA • クラウドインフラ • DBRE / SRE • Platform Engineering • MSP (24*365 保守運用) プラットフォーム開発部 QA クラウドインフラ DBRE / SRE MSP アプリケーション 開発組織 アプリケーション 開発組織 アプリケーション 開発組織 アプリケーション 開発組織 アプリケーション 開発組織 ・・・ Platform Engineering
5. Reliability Engineering と DevOps/Platform Engineering 01
6. 6 Reliability Engineering と DevOps/Platform Engineering はタスク注力の方向が違う 1. DevOps のストーリーは、開発者がラップトップにコードを打ち込むところから始まります。DevOps は(とりわけ)、顧客がそのコードから最大の価値を享受できるように、そのコード を本番環境に提供するためには何が必要かを考えます。注目の方向は、ラップトップから本番稼働に向かっています。継続的インテグレーションと継続的デリバリー(CI/CD) シ ステムが、DevOps の道具箱、スキルセット、そして採用広告でこれほど重要な位置を占めている理由の一つは、ここにあると推測できるかもしれません。 2. SRE は異なる場所から始まります。SRE は本番環境から始まります(実際、SRE の意識は本番環境にあります)。信頼できる本番環境を構築するために、SRE は何をしなけ ればならないのでしょうか。この問いに答えるには、本番環境から「後方」に目を向け、開発者のノートパソコンに辿り着くまで、この問いを一歩一歩問いかける視線が必要です。 3. 注目する方向が異なります。同じツール(例えば CI/CD パイプライン) を使うかもしれませんが、その理由は異なります。DevOps と SRE はどちらも監視システムの構築に大きく 関与するかもしれませんが、異なる理由で監視を行なっている可能性があります。 Reliability Engineering と DevOps/Platform Engineering 引用：SRE をはじめよう
7. 7 ◼ DevOps/Platform Engineering の注力点 • 開発者がラップトップ上で書いたコードを本番環境に届ける「生産ライン」の整備 • CI/CD パイプラインや開発環境の最適化を通じて、開発者体験の向上に焦点を当てる • 本番環境へ進む「流れ」を安全・高速にする「足場」の構築 ◼ SRE の注力点 • 本番環境の信頼性と安定性にフォーカス • 本番からラップトップへ「逆向き」に視線を遡り、問題を解決する • 信頼性を構築するための問いかけを繰り返す ◼ DBRE の注力点 • データを中心に据えた視点で、本番環境の「信頼性」「可用性」「継続的成長性」を確保 • データフローの歪みやリスクを分析・改善し、データの滞りなく活用できる状態を維持 • Platform Engineering や SRE のツールチェーンを活用しつつも、データベース特有の課題 （スケーラビリティ、整合性、セキュリティなど）に取り組む DBRE の本質を捉えるための注力点
8. 8 Public Cloud の台頭によりデータベースエンジニアの必要性が小さくなってきている ◼ Cloud によって誰でも一定のレベルで解決できる土壌が揃っている ◼ Cloud 技術の爆発的な発展 ◼ DevOps / SRE 思想の醸成 ◼ AI 技術の進歩 ◼ 一方でデータベースそのものに対する基本的なアプローチはこれまでと変わっていない ◼ 環境分離 ◼ 構成管理 ◼ パフォーマンスチューニング ◼ バックアップ・リストア ◼ セキュリティ・ガバナンス 変化しているのはデータベースを取り巻く周りの環境 DBRE (DBA) は企業にとって必要か？
9. 9 Application Engineer と Database Administrator の関係性
10. 10 Cloud によって変わったデータベース運用の役割
11. 11 Cloud 時代の DBRE の役割
12. 12 KTC における DBRE は横断組織 ◼ 自分たちのアウトプットがビジネスに反映されることによって価値提供される ◼ 横断組織はそこにあるだけでは何に使われるか分からない税金と同じ ◼ ビジネスに対して良い影響を与えることがもっとも重要 ◼ Reliability Engineering であるか DevOps/Platform Engineering であるかはそれほど重要ではない ◼ 良い影響とは ◼ サービスの失敗率を下げ、持続可能性を上げるための活動 ◼ エンジニアの生産性の向上への寄与 など KTC DBRE の目指すべき姿
13. KTC DBRE Platforms 02
14. 14 Database に対するツール提供やオペレーションサポートなどを提供 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 に関する推奨の修正事項を確認したい時 DBStatsCollector モニタリングツール performance_schema などの DB 内部情報を定期的に S3 に収集し、Athena から SQL ベースで事後調査できる DB ロック競合起因のタイムアウトエラーの原因を調査した い時 Aurora DB PasswordRotation セキュリティソリューション DB ユーザーの定期的なパスワードローテーションを自動化できる GISS に記載されている、DB のシークレットローテーションの 要件に簡単に準拠したい時 DBRE AI Schema Review スキーマレビュー PR 時に .sql が含まれていた場合、その DDL を CI によって 自動レビューを行うツール 新規でテーブルを構築する際に DBRE の設定したガイドラ インに沿った形で作成したい場合
15. 15 DB Catalog (shenron)
16. 16 データベースの「今」の情報を「正しく」知ること ◼ 知りたいことを知るということに対するハードルが高い ◼ プロダクトの「歴史」を知らない ◼ プロダクトにはプロダクトの歴史がある ◼ キーパーソンとのコネクションがない ◼ 自分の知りたい情報がどこにあるのかわからない ◼ パラメータ設定 ◼ スキーマ設計 ◼ 欲しい情報がないと動けない状態を解消する必要がある！ 一人目の DBRE として最初にやったこと
17. 17 information_schema からさまざまな情報を取得し、可視化 ◼ インセプションデッキ ◼ 我々はなぜここにいるのか ◼ DBRE 活動を円滑に進めるためデータベースの活きた情報を得る必要がある ◼ エレベーターピッチ ◼ 現場のサポートを的確に素早く行うために、データベースの活きた情報を適切に把握したい ◼ DBRE 向けの ◼ DB Catalog(shenron) は ◼ データベースドキュメントの自動生成ツールである ◼ これはデータベースのパラメータや ER図、DDL 情報などを自動生成することができ ◼ これまでマニュアルで作成していたドキュメントとは違い ◼ 実行したタイミングで稼働しているデータベースのメタ情報を取得することによって 正確なドキュメントを生成することができる機能が備わっている DB Catalog (shenron)
18. 18 information_schema からさまざまな情報を取得し、可視化 ◼ ER 図の自動生成 ◼ schemaspy というツールを活用 ◼ 稼働しているデータベースから ER 図を自動生成 ◼ テーブル情報 ◼ カラム情報 ◼ INDEX 情報 ◼ リレーションシップ, etc. DB Catalog (shenron)
19. 19 information_schema からさまざまな情報を取得し、可視化 ◼ DDL 情報の取得 ◼ information_schema を活用して完全内製 ◼ schemaspy では dump 情報を取得できない ◼ ローカル環境を素早く構築したい ◼ 変更の履歴も確認したい ◼ git に毎日 PUSH DB Catalog (shenron)
20. 20 information_schema からさまざまな情報を取得し、可視化 ◼ データベースパラメータ情報の取得 ◼ SHOW VARIABLES の結果をいい感じに出力 ◼ Aurora のパラメータは一部動的に指定できる ◼ 実際のパラメータを知るには計算するか SHOW VARIABLES をデータベースに対して実行するかのいずれか ◼ Git 上に Push していつでも確認できる状態に ◼ ついでに my.cnf も自動生成することで稼働環境により似た状態を docker でも構築可能 DB Catalog (shenron)
21. 21 information_schema からさまざまな情報を取得し、可視化 ◼ データベース推奨設定 ◼ メタデータ情報から直した方がいい設定をレコメンド ◼ いくつかのガイドラインに合わせて検知 ◼ mysqlsh の upgrade_checker を元にカスタマイズ ◼ DBRE がプロアクティブにプロダクトに関われるきっかけ作り DB Catalog (shenron)
22. 22 現在では KTC の管理する全てのデータベースで毎日実行されている ◼ 最初は自分が問い合わせを受けた時に使用するコマンドラインツールだった ◼ AWS 上で起動することで全ての DB 情報を定期的に取得できる状態に DB Catalog (shenron)
23. 23 PowerPole
24. 24 データベースに関連するオペレーションのために専用の EC2 インスタンスを構築 KTC ではデータベース接続のための踏み台サーバを提供 AWS Cloud Amazon EC2 for Bastion Aurora MySQL Amazon CloudWatch AWS Secrets Manager SAML 認証 DB 接続に必要な password 共通ユーザー / password Audit Log
25. 25 組織の成長と共にガイドラインも整備されてきた ◼ データベース運用に必要とされる要件 KTC の運用ガイドライン (一部抜粋) カテゴリ 概要 ログ • 行われたオペレーションが全て記載されていること • オペレーションを行なった個人を特定することが容易であること • ログの改竄ができないこと ユーザー/パスワード管理 • オペレーションに応じた権限が都度付与されること • 共通ユーザーを使用しないこと • パスワードには十分な長さと複雑さがあること • 定期的にパスワードが更新されること アクセス管理 • いつ、誰が該当作業を承認したのかがわかること • 作業完了後そのアクセスはできなくなること 脆弱性対応 • 脆弱性への対応が速やかに展開されること
26. 26 KTC ガイドラインに則ることが困難 踏み台サーバを運用していく上での課題 AWS Cloud Amazon EC2 for Bastion Aurora MySQL Amazon CloudWatch AWS Secrets Manager SAML 認証 DB 接続に必要な password 共通ユーザー / password Audit Log 常時稼働しており、セキュリティパッチの 適用などの運用が発生 踏み台にログインできれば誰でも 強権限でオペレーション可能 共通ユーザーを利用されると 誰が、いつ、 何をしたのかを確認することが困難になる
27. 27 ユーザーのリクエストに応じて一時的な踏み台サーバを払い出し ◼ インセプションデッキ ◼ 我々はなぜここにいるのか ◼ 会社のガイドラインに完全に則り、安全性を確保しつつ、誰もがSlackを通じて簡単に安全で効率的なデータベース アクセスを実現する ◼ エレベーターピッチ ◼ 現場の運用効率とセキュリティを最大限に高めるために、データベースアクセスの手間とリスクを軽減したい ◼ KTC のデータベース運用を行うプロダクトエンジニア向けの ◼ PowerPole は ◼ KTC のセキュリティガイドラインに完全準拠しながら、誰でも簡単にSlackを通じて必要な時に一時的な踏み台 サーバを構築できるツールであり ◼ 従来の煩雑なアクセス設定やセキュリティリスクを解消し ◼ 常に最新のセキュリティポリシーに則った安全かつ効率的な運用を可能にすることができるとともに 操作ログの自動取得やリソースの自動解放機能を備えており、コスト削減と監査業務の効率化も実現している PowerPole
28. 28 このプロダクトが達成したいサービスレベルを設定 ◼ プロジェクトを開始する時にインセプションデッキとともに最初にざっくりと決定 ◼ これがあるのとないのではアーキテクチャ設計、監視設計、作るもの、作らないものに大きな差が出てくる PowerPole 項目 達成したい状態 ⚫ 踏み台サーバが構築されるにあたって必要なプロセスの状態を監視する ⚫ リクエストの構築成功率が 99% であること ⚫ 踏み台サーバが構築されるまでの時間を監視する ⚫ リクエストに応じて踏み台サーバが構築されること ⚫ EC2 インスタンスは 10 分以内に構築される必要がある ⚫ PowerPole によって作成された踏み台サーバが残り続けていないかを 監視する ⚫ リクエストの時間が過ぎた EC2 インスタンスは必ず削除されること ⚫ 24時間を超えて稼働している状態にならない ⚫ DB 上のユーザーが残り続けていないかを監視する ⚫ DB 上のユーザーは不要に残しておかない ⚫ 24時間を超えて残っている状態にならない ⚫ 定期的に踏み台サーバに対するセキュリティチェックを行い脆弱性がな いかを監視する ⚫ 構築された踏み台サーバに対するセキュリティが機能している
29. 29 インスタントな踏み台サーバを構築するための Platform PowerPole AWS Cloud 作業者 稼働中 Aurora ① 作業リクエスト 承認者 ② リクエストメッセージ ③ リクエスト承認 EC2 Instance with SSM Agent ④ 踏み台サーバ構築 ⑤ 認証情報 ⑥ Login ⑦ 実作業 ⑦ オペレーションログの保存 ⑧ 踏み台サーバの削除 セキュリティチーム 必要に応じて確認 RDS Audit Log SSM Agent Log ⑦ Audit Log の保存 ④ CREATE USER ⑧ DROP USER
30. 30 PowerPole: 全体アーキテクチャ 作業者 承認者 リクエスト用 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 ワンタイムパスワード管理)
31. 31 データベース運用に必要とされる要件を Engineering で解決 PowerPole カテゴリ 要件 対応 ログ • 行われたオペレーションが全て記載されていること • オペレーションを行なった個人を特定することが容易であること • ログの改竄ができないこと • Audit Log / SSM Log の適切な利用 • DB のユーザー名をSlack のメールアドレスの @ より前を使用することで個人の特定が容易 ユーザー/パスワード管理 • オペレーションに応じた権限が都度付与されること • 共通ユーザーを使用しないこと • パスワードには十分な長さと複雑さがあること • 定期的にパスワードが更新されること • オペレーションリクエスト時に必要な権限を申請 • 都度 DB にユーザー登録を行う • パスワードは要件を満たすためのプログラムで 毎回ランダムで作成 アクセス管理 • いつ、誰が該当作業を承認したのかがわかること • 作業完了後そのアクセスはできなくなること • 全てのプロセスを DynamoDB に登録 • 作業完了後 DB からユーザーを削除 脆弱性対応 • 脆弱性への対応が速やかに展開されること • 踏み台を起動するタイミングで yum update を実施
32. 32 Aurora 3.0移行
33. 33 2024年10月末で Aurora 2.0 は EOL を迎えた (延長サポートあり) ◼ バージョンアップを行う上での障害となりうる可能性を低くする ◼ shenron の推奨設定をチェックしバージョンアップまでに事前対応 ◼ 具体的なチェック項目(一部抜粋) Aurora 3.0移行 チェック項目 エラーレベル 概要 空スキーマチェック Notice テーブルの存在しないスキーマがあった場合、そのスキーマ一覧を抽出 utf8mb4 チェック Warning utf8mb4 ではない DB オブジェクトの一覧を抽出 ROW_FORMAT チェック Warning テーブルの ROW_FORMAT が COMPACT か REDUNDANT の一覧を抽出 予約語チェック Error 予約語が使用されているスキーマの一覧を抽出 特殊文字使用チェック Warning 「- (ハイフン)」 が使用されている DB オブジェクトの一覧を抽出 カラム型チェック Warning 同じカラム名で別のカラム型を使用しているカラムの一覧を抽出
34. 34 バージョンアップに必要なレポートの作成 ◼ あくまでも主体はプロダクト ◼ DBRE は移行がスムーズに行われるように裏側の サポートに徹している ◼ 実際の移行に関しては DBRE で開発した 移行ツールを利用して実施 Aurora 3.0移行
35. 35 Insight SQL Testing の利用 ◼ Insight SQL Testing とは ◼ インサイトテクノロジーが提供している移行アセスメントツール ◼ Audit Log を吸い出しておくことでバージョンアップ前後で失敗するクエリや、パフォーマンス劣化が発生するクエリな ど様々な情報を可視化できるツール ◼ ライセンス料がそこそこかかるのでプロダクトの要望に応じて使用判断 Aurora 3.0移行
36. 36 Insight SQL Testing の利用 ◼ Insight SQL Testing によって得られた効果 ◼ およそ 3.3億行のクエリのリプレイを行いプロダクト側で対応しなければいけない観点を絞ることができた ◼ クエリ成功失敗だけでなくパフォーマンス劣化や結果の相違に関して知ることができた点は非常に助けられた ◼ 両DBで失敗したものを見ることで移行の漏れを知ることができた ◼ クエリのユニークの方法に関しては自分たちで実装したことで DBRE としての知見も向上 ◼ 参考: クエリのノーマライズ処理を実装してみた Aurora 3.0移行 Aurora3系で のみ失敗 両DBで失敗 結果が相違 性能劣化 成功 合計 全体件数 1,586,332 1,717,814 1,457,426 95,627 324,339,799 329,196,998 ユニーク 205 416 2,398 309 -- 3,328
37. 37 AI Schema Review
38. 38 なぜ DBRE に生成 AI を導入したのか AI Schema Review ◼ データベースのスキーマは一度作成されると後戻りしづらい ◼ データベースの影響範囲はそれを使用する全てのサービス ◼ アプリケーションそのものに対する影響 ◼ 外部連携しているサービスへの影響 ◼ (割とある) 忘れ去られた管理システム ◼ 影響範囲が広いため調査と調整コストが大きくなりがち ◼ アプリケーションコードでなんとかしようとするとマジカルな仕様ができてしまう ◼ マジカルな仕様は調査・学習コストを上げ、属人化や開発工数の増加を引き起こす 早い段階でどれだけ適切に設計できるかは開発生産性に大きく影響してくる
39. 39 スキーマレビューを AI によって実施 ◼ インセプションデッキ ◼ 我々はなぜここにいるのか ◼ プロダクトのデータベーススキーマの最適化と運用の改善をするためにここにいる ◼ エレベーターピッチ ◼ データベーススキーマがガイドラインに準拠しているかを効率よく発見したい ◼ プロダクト担当者向けの ◼ DBRE AI Tools というサービスは ◼ AI によるスキーマレビューを行うツールである ◼ これは自動でデータベーススキーマレビューを行い、KTC のガイドラインに準拠した最適化を提案することができ ◼ 独自でスキーマレビューを行うより信頼度が高く、人的工数も削減できる ◼ GitHub Actions を活用して誰でも利用できる特性を備えている AI Schema Review
40. 40 このプロダクトが達成したいサービスレベル AI Schema Review 項目 達成したい状態 ⚫ ガイドライン適用率 ⚫ DBRE の提供するガイドラインを準拠できる状態であること ⚫ ガイドライン追加に必要なタスクのドキュメント整理と自動化率 ⚫ ガイドラインを追加したい場合 10分以内に追加できること ⚫ 変更容易性を確保する ⚫ 生成系 AI によるスキーマレビューのレスポンスタイム ⚫ 一つのスキーマのチェックが 60秒以内に完了すること ⚫ 長くなればなるほどユーザーの待ち時間が長くなり、煩わしさを感じさせて しまう ⚫ スキーマレビューの誤検出（false positives）および見逃し（false negatives）の割合 ⚫ テスト時にスキーマレビューの際の誤検出（false positives）および見逃し （false negatives）を 95％以内に抑える
41. 41 アーキテクチャ AI Schema Review
42. 42 デモ AI Schema Review
43. 43 この仕組みの本当に素晴らしいところは AI による Review だけではない AI Schema Review ◼ AI によって評価されたことにも責任を持つ仕組みがある ◼ ただスキーマレビューに AI を活用しただけではなく AI のアウトプットを評価する仕組みも同時に開発 ◼ 生成 AI に品質を評価させる 「LLM-as-a-Judge」を採用 出典： Anthropic 社 - Create strong empirical evaluations
44. 44 続きは developers summit 2025 で！ AI Schema Review ◼ 生成 AI 評価の内容や実例を KTC DBRE メンバーがお話しします！
45. まとめ 03
46. 46 自分たちが何を作るのか、チーム全体で合意 ◼ 合意すること ◼ インセプションデッキ ◼ プロジェクト開始のタイミングでそのプロダクトがどのようなサービスレベルを達成したいの ◼ アーキテクチャ設計、監視項目、作るもの、作らないものを設定する上で重要な指標となる KTC DBRE の目標・ゴール設定
47. 47 Database に対するツール提供やオペレーションサポートなどを提供 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 に関する推奨の修正事項を確認したい時 DBStatsCollector モニタリングツール performance_schema などの DB 内部情報を定期的に S3 に収集し、Athena から SQL ベースで事後調査できる DB ロック競合起因のタイムアウトエラーの原因を調査した い時 Aurora DB PasswordRotation セキュリティソリューション DB ユーザーの定期的なパスワードローテーションを自動化できる GISS に記載されている、DB のシークレットローテーションの 要件に簡単に準拠したい時 DBRE AI Schema Review スキーマレビュー PR 時に .sql が含まれていた場合、その DDL を CI によって 自動レビューを行うツール 新規でテーブルを構築する際に DBRE の設定したガイドラ インに沿った形で作成したい場合
48. 48 KTC DBRE Platforms ◼ DB Catalog(shenron) • データベースの情報を取得し、活きた情報を元としたドキュメント自動生成を実現 • 運用効率化と正確な情報の提供 ◼ PowerPole • 一時的な踏み台サーバの構築 • セキュリティと運用効率の向上 ◼ DBRE AI Tools • 生成 AI を活用したスキーマレビューを実施 • 設計時の適切性を自動で評価 Reliability と Agility を実現する DBRE ツール
49. 49 組織横断的に利用できる Tool 開発 ◼ スローガン ◼ 個別最適を行わない ◼ 個別機能を開発しないのではない ◼ 個別の機能をいかに Platform として昇華させるかを考える ◼ ただやるだけではつまらない ◼ 実現していることは枯れたこと ◼ How の部分をモダンに楽しく ◼ 本日共有する内容は誰でもできる (やっている) ことを Platform 化した取り組みが多い ◼ そこに DBA としてのナレッジと AWS の技術を組み込んで実現することで楽しみながら開発 DBRE Platform Tools
50. 50 Aurora 3.0 移行サポート ◼ 移行を円滑に進めるための内製ツール ◼ データ移行ツール ◼ 不適切な設定の検知の仕組み ◼ プロダクトが移行しやすい形にするためのレポート作成 ◼ Insight SQL Testing を活用 ◼ ROI を考慮して効果が高いと判断できるものは外部ツールの使用も積極的に実施 ◼ 失敗クエリやパフォーマンス劣化、結果の相違など様々な観点で可視化 DBRE は裏方としてプロダクト移行を支援し、リスクを最小限に抑える取り組みを実践 プロダクトサポート
51. 51 KTC における DBRE は横断組織 ◼ 自分たちのアウトプットがビジネスに反映されることによって価値提供される ◼ 横断組織はそこにあるだけでは何に使われるか分からない税金と同じ ◼ ビジネスに対して良い影響を与えることがもっとも重要 ◼ Reliability Engineering であるか DevOps/Platform Engineering であるかはそれほど重要ではない ◼ 良い影響とは ◼ サービスの失敗率を下げ、持続可能性を上げるための活動 ◼ エンジニアの生産性の向上への寄与 など KTC DBRE の目指すべき姿
52. 52 ◼ AWS ◼ Amazon API Gateway ◼ Amazon Athena ◼ Amazon Aurora for MySQL ◼ Amazon Bedrock ◼ Amazon CloudWatch ◼ Amazon DevOps Guru ◼ Amazon DynamoDB ◼ Amazon EC2 ◼ AWS Lambda ◼ AWS Secrets Manager ◼ AWS Step Functions KTC DBRE を支える技術 ◼ 開発手法 ◼ Scrum ◼ 開発言語 ◼ Golang ◼ Python ◼ Monorepo 管理 ◼ Nx ◼ CICD ◼ GitHub Actions ◼ Infrastructure as Code ◼ Terraform KTC はたまたま AWS をメインクラウド、MySQL をメインの RDBMS として利用しているが、 基本的にインフラ基盤や RDBMS は何であっても代用可能 (と思っています。。)
53. Help Us Shape the Future ! KINTO テクノロジーズでは DBRE / SRE を始め、様々な職種で仲間を募集しています！ 少しでも興味がありましたらお気軽にご連絡ください
54. 54 mysql > SELECT ‘Questions’ FROM you;
55. 55 mysql > SELECT ‘Thank you’ FROM me;
56. THANK YOU!