1 KINTO テクノロジーズでの DBRE 活動のご紹介 DBRE Summit 2023 KINTO テクノロジーズ 廣瀬 真輝

名前： 廣瀬 真輝 (Masaki Hirose) 略歴： ファッション EC サイト運営会社で約 10 年勤務 昨年 11 ⽉に KINTO テクノロジーズ⼊社 DBRE チーム Twitter： @_p2sk_ 趣味： ゲーム（スプラトゥーン３） 2 ⾃⼰紹介

⾒出し 0x 会社・サービス紹介 01

4 KINTO テクノロジーズ株式会社について 2021年4⽉設⽴ トヨタ⾃動⾞株式会社 トヨタファイナンシャルサービス株式会社（TFS） 海外販売⾦融会社 世界40以上の国と地域で サービスを展開 トヨタファイナンス 株式会社 KINTOテクノロジーズ 株式会社 株式会社KINTO 販売⾦融・クレジットカード など 2019年1⽉設⽴

5 KINTO テクノロジーズ (通称: KTC) MISSION トヨタグループの Webサービスの先駆者として、 モビリティサービスを⽀える プロダクトを次々と作り、育て、 世界のお客様にご利⽤いただくことを ⽬指しています。 Mobility Product Technology Creative

6 KTC の⼿がけるプロダクト 任意保険や⾃動⾞税など、クルマにかかる諸経費がコミコミ⽉々定 額のクルマのサブスクリプションサービスです。WEBでも簡単にお 申込みから契約まででき、気軽にカーライフを始めることができま す。 KINTOで⼿軽にマイカーを。 ⾞のサブスクリプションサービス https://kinto-jp.com/ トヨタ・レクサス既販⾞のソフトウェア・ハードウェアの機能やア イテムを最新の状態に「進化」させるサービスです。購⼊時設定が 無かったオプションの後付けや、経年劣化した内外装の交換などを 正規品質でご提供します。 クルマのオーナーに向けた 愛⾞のカスタム・機能向上サービス https://factory.kinto-jp.com/ クルマのサブスク「KINTO」をはじめとして様々なモビリティサービスを展開

7 KTC の⼿がけるプロダクト クルマのサブスク「KINTO」をはじめとして様々なモビリティサービスを展開 KINTO ONEのリースアップ⾞を中⼼とした状態の良い修復なし⾞両 を厳選したトヨタの中古⾞サブスクサービスです。マイカーにかか るさまざまな費⽤が、毎⽉コミコミの定額のサービスでご利⽤いた だけます。 KINTO ONE クルマの持ち⽅がまた広がる。 https://up.kinto-jp.com/ Prism Japanは、あなた⾃⾝も気づいていないお出かけの好みやいま の気分を、独⾃のAIが分析。あなたにぴったりの場所を⾒つけ出す 、 お出かけ先インスピレーションAIアプリです。 「ここに⾏きたかったんだ」を、⾒つけよう。

8 KTC の⼿がけるプロダクト クルマのサブスク「KINTO」をはじめとして様々なモビリティサービスを展開 クルマライフの楽しさを広げるサービス「モビリティマー ケット」。ドライブしたいと思い⽴ったときにぴったりなお 出かけ先はもちろん、愛⾞のお⼿⼊れに役⽴つサービスなど、 多彩なプログラムをWEBサイトでご紹介しています。 モビリティマーケット 2019年に誕⽣したKINTOブランドのサービスは全世界で展開 されています。KINTOテクノロジーズ株式会社は、別々のID 管理システムをつなげ、全世界のKINTOのお客様をグローバ ルで⼀意に管理するためのプラットフォーム、Global KINTO ID Platformを開発し、2021年にリリースしました。 グローバルIDプラットフォーム Woven Cityは、未来の当たり前を発明するモビリティのテス トコースです。価値の交換、移動にかかわる決済プラット フォームを作り、発明家と住⺠の皆さんに提供し、この街で ⾏われる新たな価値の発明をサポートします。※Woven City は2024年〜2025年に⼀部実証を開始予定 WOVEN CITY 移動⼿段の検索・予約・決済まで、移動に関する⼀連の機能 をひとつのアプリ内で完結でき、街中における円滑な移動の サポートをするマルチモーダルモビリティサービスです。 my route トヨタのキャッシュレス決済アプリ「TOYOTA Wallet」のア プリケーション開発およびテスト⾃動化環境構築の⽀援を ⾏っています。 TOYOTA wallet

⾒出し 0x KTC における DBRE の⽴ち位置 02

10 KTC における DBRE の⽴ち位置 エンジニア組織 : 16 グループ 社内のエンジニアの数 : 約 300 名 横断組織 • SysAd (クラウドインフラ構築) • DevOps (DevOps 推進) • SRE (Embedded SRE) • DBRE (DBRE 推進) • MSP (24*365 保守運⽤対応) • CCoE (クラウド利活⽤推進) アプリケーション開発組織 • サービス開発 • モバイルアプリ開発 • 共通プラットフォーム開発, etc. 全てのサービスが クラウド上で稼働 組織1 組織2 組織3 … 組織N

2 つに⼤別される • Database Business Office • 開発組織や各ステークホルダー（セキュリティ・法務等）からの要求に基づいて 課題解決を⾏なったり、DBRE が提供する Platform の活⽤を推進する役割 • Cloud Platform Engineering • ガバナンスに準拠しながらクラウドの効果的な利活⽤を促進するために、 DB に関連する標準や Platform を提供する役割 11 KTC における DBRE チームの Role DBRE Team Cloud Platform Engineering Database Business Office

12 DBRE 活動内容の決め⽅ Security ＆ Governance 脅威についての定義が されている 脅威検知の仕組みがあ る 脅威に対する対応 がスムーズに⾏わ れる 脅威に対する対応 が横展開されてい る 脅威にさらされない設定 が全社的になされている 組織の DB レイヤのリスク を最⼩化し続けている Cost Optimization コストの現状を把握できる リソースの状態が把握できる リソースの状態から 適切な状態を定義できる コストが最適化されている 事業に対するコストを 最適化し続けている Quality Improvement 企業として最低限守るべき SLO がある SLO の継続的なモニタリングがされている SLO/SLI によって アクションを決めることができる 企業としての SLO を 保証し続けている Delivery Efficiency 機能開発に向かっている時間が⻑い状態を作 る DB に関する技術情報が集約されている DB に対する課題解決を伴⾛する 組織の開発効率を 最⼤化し続けている • 理想的な DBRE の組織貢献を 4 本柱で定義 • 組織の現状を踏まえてドリルダウンし、具体的な活動内容を決定

⾒出し 0x 実際の活動内容のご紹介 03

14 DBRE チームの技術スタック • AWS Service • Amazon API Gateway • Amazon Aurora for MySQL • Amazon DynamoDB • Amazon CloudWatch • Amazon EC2 • AWS Lambda • AWS Secrets Manager • Amazon IAM • AWS Step Functions • Amazon Event Bridge • Amazon ECR • Amazon S3 • Amazon CloudFront • Amazon VPC • 開発⼿法 • Scrum • 開発⾔語 • Golang • Shell Script • Monorepo 管理 • Nx • CICD • Github Actions • IaC • Terraform • Packer • ChatOps • SlackApp

15 事例 1 : DB クラスタの情報を収集する仕組み

• 様々なモビリティサービスを提供しているため、DB クラスタ数も多め • Production 環境で約 50 個の Aurora MySQL クラスタが稼働中 • 各 DB ごとに問い合わせベースで情報を収集していたのでは時間がかかる • DB クラスタの情報を収集する仕組みを作りたい • 収集した情報は社員が閲覧できる状態にしたい • ドキュメントは最新の状態を保ち続けたい 16 背景

• 各 DB・テーブル単位での容量 • ER 図 • DB クラスタに対応した設定をローカルの MySQL に適⽤するための my.cnf • Aurora 3 系へのアップデートのブロッカーとなるスキーマ構成の検出 • MySQL Shell upgrade checker utility のチェック内容＋α • インスタントな踏み台サーバーを提供する基盤の要件準拠チェック • 命名規則に則った Secret/IAM の存在チェック、Aurora インスタンスへの接続チェック 17 各 DB クラスタごとに以下の情報を収集したい https://speakerdeck.com/_awache/cus-11-aws-summit-2023-dbre-practice

• 各 DB・テーブル単位での容量 • ER 図 • DB クラスタに対応した設定をローカルの MySQL に適⽤するための my.cnf • Aurora 3 系へのアップデートのブロッカーとなるスキーマ構成の検出 • MySQL Shell upgrade checker utility のチェック内容＋α • インスタントな踏み台サーバーを提供する基盤の要件準拠チェック • 命名規則に則った Secret/IAM の存在チェック、Aurora インスタンスへの接続チェック 18 各 DB クラスタごとに以下の情報を収集したい https://speakerdeck.com/_awache/cus-11-aws-summit-2023-dbre-practice ⼊社前に実装済み NEW

19 Phase 1 のアーキテクチャ

20 EC2 インスタンスを起動している理由 • 「インスタントな踏み台サーバーの提供基盤の要件準拠チェック」 • 命名規則に則った Secret/IAM の存在チェック • Aurora インスタンスへの接続チェック • （結果的に）コードが流⽤できたというメリットも 踏み台サーバーの提供基盤

• lambda の最⼤ 15 分という実⾏時間の制約に引っかかる可能性 • DB の様々な情報を収集する処理が増えるため（特に SchemaSpy） • Step Functions と lambda の組み合わせで対応 • EC2 インスタンス内の処理時間が DB クラスタごとに⼤きく異なる • ⼤きな DB の⽅が SchemaSpy 等の処理に時間がかかる • 処理を終えたインスタンスから terminate することでコストを最適化したい • Step Functions の map で並列実⾏することで対応 21 収集情報が増えることによる課題と解決策 出典：https://docs.aws.amazon.com/ja_jp/step-functions/latest/dg/welcome.html

22 Phase 2 のアーキテクチャ ※ 実装済みのものを使⽤ https://speakerdeck.com/_awache/dbre-huo-dong-to-information-schema

• 全環境(dev/stg/prod）の全 DB クラスタの情報を⾼い鮮度（⽇次）で社員が 誰でも閲覧できる状態になった • 各 DB・テーブル単位での容量 • ER 図 • DB クラスタに対応した設定をローカルの MySQL に適⽤するための my.cnf • Aurora 3 系へのアップデートのブロッカーとなるスキーマ構成の検出 • MySQL Shell upgrade checker utility のチェック内容＋α • 問い合わせ時に都度 DB に接続する機会が減り、対応速度向上 • Aurora 3 Version Up に関連した担当者との MTG 準備⼯数の削減 • 合計で数⼗回実施することになるので⼤幅な削減に 23 結果

• 各 State の⼊出⼒の挙動がわからない • データフローシミュレーターで動作を確認しながら理解 • map の実⾏権限不⾜でエラー • map 実⾏ には SFn ⾃⾝に [Action = states:StartExecution] を設定する必要 24 ハマった点：Step Functions まわり

• Step Functions で map を使⽤してDB クラスタ数分並列で処理 • API Quota の limit に引っかかりエラーに • 特に RunInstances API が 5 call/sec なので厳しい • かといって map の同時実⾏数で制御すると全体の処理速度が⼤きく落ちる • 同⼀ AWS アカウントで別サービスも稼働中のためリトライだけは NG • 解決策 • リトライは⼊れた上で • 案1 : ⾮同期処理なので SQS でコントロール • 案2 : API call までランダムに sleep させる簡易的な対応 • 実装完了までにかかる時間を優先して案 2 で対応 25 ハマった点：AWS API Quota

26 事例 2 : 進⾏中 - DB シークレットローテーション

• 社内セキュリティ規定：定期的なパスワードローテーションが必要 • Aurora MySQL の DB ユーザーも対象（Secrets Manager から取得） • 個⼈ユーザー：承認制で期間限定の user/password を都度払い出しする仕組み有 • アプリケーションユーザー：今回のスコープ 27 背景

• どのシークレットがローテーション対象か管理できる • シークレットごとにローテーションスケジュールと履歴を管理できる • シークレットローテーションは⾃動で実⾏される • Secrets Manager のシークレットを変更できる • シークレットローテーション実施時に担当者へ（slack等で）通知できる 28 要求・シナリオ

• 2 つのローテーション戦略から選択 • シングルユーザーローテーション • 1 シークレットあたり 1 ユーザー • パスワード変更時に⼀時的なエラーが発⽣する可能性 -> アプリ側のリトライで対処 • 交代ユーザーローテーション • 1 シークレットあたり 2 ユーザー • [user1] / [user1_clone]（DB にも⾃動で作成される） • ローテーションは Lambda が実施する • AWS コンソールから設定すると⾃動で Lambda も作成 • 関数のテンプレートコードが公開されており、カスタマイズも可能 29 Secrets Manager のパスワードローテーション機能 出典：https://dev.classmethod.jp/articles/password-management-with-aws-secrets-manager/

• ローテーション実施前 • ローテーション実施後 30 交代ユーザー

• シングルユーザーローテーション + Dual Password の併⽤ • Dual Password : MySQL 8.0 系から提供される機能 • ALTER USER '${user_name}'@'${host}' IDENTIFIED BY ${new_passowrd} RETAIN CURRENT PASSWORD; • 変更前と変更後のパスワード両⽅で接続できる • これを使うとダウンタイムなしでローテーションできるのでは？ • 交代ユーザーローテーションと⽐較を実施 31 最初の案

32 [シングルユーザー + Dual Password] vs [交代ユーザー] メリット デメリット シングルユーザー + Dual Password • 交代ユーザーより DB ユーザー管理が単純 • Aurora 3 系以降の MySQL でしか使えない • Lambda の実装を修正する必要 交代ユーザー • lambda のコードは AWS 提供のものを そのまま使える • MySQL の機能を使っていないため 別の DB でも同じ戦略をとることが可能 • 権限を編集した場合、clone 側のユーザーの 権限も ALTER する必要

33 [シングルユーザー + Dual Password] vs [交代ユーザー] メリット デメリット シングルユーザー + Dual Password • 交代ユーザーより DB ユーザー管理が単純 • Aurora 3 系以降の MySQL でしか使えない • Lambda の実装を修正する必要 交代ユーザー • lambda のコードは AWS 提供のものを そのまま使える • MySQL の機能を使っていないため 別の DB でも同じ戦略をとることが可能 • 権限を編集した場合、clone 側のユーザーの 権限も ALTER する必要 交代ユーザー戦略を採⽤

34 アーキテクチャ • Secrets Manager への疎通は Nat Gateway 経由で • VPC ごとに 1 つ Lambda を配置 • Lambda からのアクセスを許可するように VPC 内の DB の SG を修正

• 通知周りの設計と実装 • 新規作成シークレットへの対応 • DB ユーザー作成＋ローテーションが設定されたシークレット作成を ⾃動実⾏するコマンドラインツールの提供 • 既存シークレットへの対応 • ローテーション設定の実施 35 今後の予定

36 DBRE Platform Tools • How の部分をモダンに楽しく開発 • 実現していることは枯れたことかもしれない • DBRE としてのナレッジと AWS の技術を組み込んで実現 組織横断的に利⽤できる Tool の開発 スローガン

37 事例 3 : 検証中 - Aurora zero-ETL integrations with Redshift (preview)

• DB 間のデータ同期に関するパフォーマンス問題 • 複雑な View を介した低速・⾼負荷なデータ同期処理が存在 • スケールアップでも解決できなかった • ちょうど Redshift へのデータ連携が楽になる zero-ETL が Public Preview に → 検証 38 背景

39 Aurora MySQL -> Redshift へのデータ同期の歴史 出典：https://www.youtube.com/watch?v=5bKysXZC3Ao バッチ処理から Federated Query へ

40 Federated Query から Zero-ETL へ 出典： https://aws.amazon.com/jp/blogs/news/getting-started-guide-for-near-real-time-operational-analytics-using-amazon-aurora-zero-etl-integration-with-amazon-redshift/ • Redshift 側に DB (箱) を作れば Aurora クラスタ内のデータ変更を ⾃動で Redshift 側に反映

• Redshift 側で Materialized View を構築し、データ同期時に参照する 41 構想 As Is To Be

• Zero-ETL の設定 • 単純なテーブルを参照した Materialized View の構築 • 今後 • 実際のテーブルとデータサイズ、View 定義を⽤いてパフォーマンス検証 42 進捗

• Backtrack と併⽤できない • Zero-ETL 有効化に必要な Enhanced-Binlog が Backtrack と併⽤できないため • Backtrack を有効化していた DB を Backtrack 無効化で PITR しても NG ... • Zero-ETL と Materialized View の併⽤が⼤変 • Zero-ETL の DB に Materialized View 作成不可 • Redshift に別 DB を作成し、cross database query として Zero-ETL の DB を 参照する Materialized View なら作成可能 • Materialized View の Refresh 時に毎回 Recompute (全件更新）になる • 軽量な増分更新もあるが、Zero-ETL と Materialized View の併⽤だと NG • ここの実⾏時間が読めない • Materialized View の Refresh と SELECT ⽂にロック互換性がない • Recompute の Refresh と SELECT は⽚⽅がブロックされる 43 懸念点

⾒出し 0x まとめ 04

2 つに⼤別される • Database Business Office • 開発組織や各ステークホルダー（セキュリティ・法務等）からの要求に基づいて 課題解決を⾏なったり、DBRE が提供する Platform の活⽤を推進する役割 • Cloud Platform Engineering • ガバナンスに準拠しながらクラウドの効果的な利活⽤を促進するために、 DB に関連する標準や Platform を提供する役割 45 KTC における DBRE チームの Role DBRE Team Cloud Platform Engineering Database Business Office

46 DBRE 活動内容の決め⽅ Security ＆ Governance 脅威についての定義が されている 脅威検知の仕組みがあ る 脅威に対する対応 がスムーズに⾏わ れる 脅威に対する対応 が横展開されてい る 脅威にさらされない設定 が全社的になされている 組織の DB レイヤのリスク を最⼩化し続けている Cost Optimization コストの現状を把握できる リソースの状態が把握できる リソースの状態から 適切な状態を定義できる コストが最適化されている 事業に対するコストを 最適化し続けている Quality Improvement 企業として最低限守るべき SLO がある SLO の継続的なモニタリングがされている SLO/SLI によって アクションを決めることができる 企業としての SLO を 保証し続けている Delivery Efficiency 機能開発に向かっている時間が⻑い状態を作 る DB に関する技術情報が集約されている DB に対する課題解決を伴⾛する 組織の開発効率を 最⼤化し続けている • 理想的な DBRE の組織貢献を 4 本柱で定義 • 組織の現状を踏まえてドリルダウンし、具体的な活動内容を決定

• DB クラスタの情報を収集する仕組み • DB シークレットローテーション • 検証：Aurora zero-ETL integrations with Redshift (preview) 47 KTC における DBRE 活動を 3 つご紹介

48 KTC DBRE のアウトプット Database の Reliability を向上させるためのプラットフォーム構築 • Database の知識を還元して KTC 全体の Reliability を守る • その⼿段として Engineering で解決する道を選択 • Cloud を適切に活⽤し Agility を確保しつつ Database の Security と Governance を守る • Platform へと昇華させ企業全体に展開することでビジネスに良い影響を与え続ける Database Reliability Engineering というアプローチ

No content