DBREから始めるデータベースプラットフォーム
•
0 gefällt mir•1,667 views
データベース非機能要件「Provisioning」,「Monitoring」,「Backup」,「Masking」などは、様々な人が様々な方法で実現してきた枯れたものです。 これらの非機能要件を「ただ動くだけでは面白くない」、「Howの部分を今っぽく」をテーマにしたAWSで実現するデータベースプラットフォームを紹介するセッションになります。 主に「クラウドで作成したデータベースプラットフォームの概要・メリット・デメリット」について 併せてプラットフォーム作成に使用したAWS製品（StepFunctions、ECS Task,Lambda...）の利用方法を解説します。
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie DBREから始めるデータベースプラットフォーム
Ähnlich wie DBREから始めるデータベースプラットフォーム (20)
Mehr von Insight Technology, Inc.
Mehr von Insight Technology, Inc. (20)
DBREから始めるデータベースプラットフォーム
- 1. Copyright (C) 2019 BizReach, Inc. DBREから始める データベースプラットフォーム 2019/9/25 株式会社ビズリーチ システム本部 プラットフォーム基盤推進室 ⼭我 晟潤
- 3. 創業 ︓2009年4⽉ 代表者 ︓南 壮⼀郎 従業員数︓1,326名（2019年8⽉現在） 拠点 ︓東京／⼤阪／名古屋／福岡／シンガポール 事業内容︓インターネットを活⽤したサービス事業 株式会社ビズリーチ / BizReach, Inc.
- 5. Services 4 課題解決 ビズリーチのサービス ⼈⼿不⾜ 即戦⼒⼈材 若⼿⼈材 全雇⽤形態 就職・キャリア教育 企業のIT化 戦略⼈事クラウド 戦略⼈事メディア 事業継承 事業継承 M&A 「⼈⼿不⾜」「企業のIT化」「事業承継」は、中⼩企業庁の平成30年度中⼩企業・⼩規模事業者政策の 重点項⽬として挙げられています。
- 6. Organization 5 QA Security ORE DBRE 事業横断組織 Platform Product GroupSupport エンジニア組織: 約15 社内のエンジニアの数: 約350名
- 8. はじめに 7 • DBREから考えたデータベースプラットフォームのお話 • AWSの話が多めです。 • なるべくAWSを知らない⼈でもわかるような⾔い回しは⼼がけます。
- 9. 8 DBREってなに？
- 10. • DBREとは？ • ビズリーチ流の DBRE 9 DBREってなに？
- 11. Database Reliability Engineering (DBRE): データベース信頼性エンジニアリング • Database におけるモノゴトを `Reliability Engineering` という側⾯から解決 主な役割 • 開発チームに対する教育 • プラットフォーム構築 • ⾃律化、⾃動化推進による⽣産性向上 • データストア運⽤のスペシャリスト • 他分野のスペシャリストと分野を超えてコラボレーション 10 DBREとは？
- 12. Database Reliability Engineering (DBRE): データベース信頼性エンジニアリング • Database におけるモノゴトを `Reliability Engineering` という側⾯から解決 主な役割 • 開発チームに対する教育 • プラットフォーム構築 • ⾃律化、⾃動化推進による⽣産性向上 • データストア運⽤のスペシャリスト • 他分野のスペシャリストと分野を超えてコラボレーション 11 DBREとは？ 権限を絞ったりするのではなく、 正しくデータベースを操作できるよう 開発チームに寄り添っていきましょう。
- 13. Database Reliability Engineering (DBRE): データベース信頼性エンジニアリング • Database におけるモノゴトを `Reliability Engineering` という側⾯から解決 主な役割 • 開発チームに対する教育 • プラットフォーム構築 • ⾃律化、⾃動化推進による⽣産性向上 • データストア運⽤のスペシャリスト • 他分野のスペシャリストと分野を超えてコラボレーション 12 DBREとは？ 基本は「データベース数 > DBA数」 本質的な作業に集中できるような 環境をつくりましょう。
- 14. Database Reliability Engineering (DBRE): データベース信頼性エンジニアリング • Database におけるモノゴトを `Reliability Engineering` という側⾯から解決 主な役割 • 開発チームに対する教育 • プラットフォーム構築 • ⾃律化、⾃動化推進による⽣産性向上 • データストア運⽤のスペシャリスト • 他分野のスペシャリストと分野を超えてコラボレーション 13 DBREとは？ DBREは設計段階からバリューを発揮し、 最適なセルフサービスプラットフォームを 提供しましょう。
- 15. 14 ビズリーチ流の Database Reliability Engineering プラットフォーム基盤推進室 組織理念 エンジニアが成⻑でき、居続けたいと思う会社にする 優秀なエンジニアが集まり、育て、居続けられる環境を作ることで世の中に多くの価値を提供できる Mission 全サイトの信頼性を担保することで、 自社のサービス価値を最大化する Vision Make it Visible 品質、生産性を可視化することで 課題発見と健全な成長を促す No Ops, More Code エンジニアに対して開発と事業成長に 注力できる環境を提供する
- 16. Platform を提供することで組織の Mission/Vision を具現化 • Database の 3⼤⾮機能要件の共通化を⾏い各事業に提供 (Cross-Functional Platform) • Backup • Provisioning • Monitoring • DBA としてのナレッジを Engineering でサポート (Operation Platform) • Masking Operation • Point In Time Recovery • 命名規則・設計ルールの共通化 • Release Operation 仕組み化 • Slow Query Analyze 15 ビズリーチ流の Database Reliability Engineering
- 17. 16 DBREから考えるビズリーチ流のDBREチームの役割とアクション DBREチーム DBRE 推進 ・ DBRE 認知 ・ 全社DBA DBRE化推進 Cross-FunctionalPlatforms ・ Backup ・ Provisioning ・ Monitoring , etc. 全社 SLA/SLO/SLI の策定 Database 知⾒共有、教育 Operation Platforms ・Masking Operation ・Point In Time Recovery ・ Release Operation 仕組み化 ・ 命名規則/設計ルール ・ Slow Query Analyze , etc. 各事業部 Database を安⼼安全に誰でも扱うことができる状態 属⼈化の排除 Toil の削減 事業部 SLA/SLO/SLI の策定
- 18. 17 DBREから考えるビズリーチ流のDBREチームの役割とアクション DBREチーム DBRE 推進 ・ DBRE 認知 ・ 全社DBA DBRE化推進 Cross-FunctionalPlatforms ・ Backup ・ Provisioning ・ Monitoring , etc. 全社 SLA/SLO/SLI の策定 Database 知⾒共有、教育 Operation Platforms ・Masking Operation ・Point In Time Recovery ・ Release Operation 仕組み化 ・ 命名規則/設計ルール ・ Slow Query Analyze , etc. 各事業部 Database を安⼼安全に誰でも扱うことができる状態 属⼈化の排除 Toil の削減 事業部 SLA/SLO/SLI の策定 開発チームに対する教育
- 19. DBREチーム DBRE 推進 ・ DBRE 認知 ・ 全社DBA DBRE化推進 Cross-FunctionalPlatforms ・ Backup ・ Provisioning ・ Monitoring , etc. 全社 SLA/SLO/SLI の策定 Database 知⾒共有、教育 Operation Platforms ・Masking Operation ・Point In Time Recovery ・ Release Operation 仕組み化 ・ 命名規則/設計ルール ・ Slow Query Analyze , etc. 各事業部 Database を安⼼安全に誰でも扱うことができる状態 属⼈化の排除 Toil の削減 事業部 SLA/SLO/SLI の策定 18 DBREから考えるビズリーチ流のDBREチームの役割とアクション プラットフォーム構築 ⾃律化、⾃動化推進による⽣産性向上
- 20. DBREチーム DBRE 推進 ・ DBRE 認知 ・ 全社DBA DBRE化推進 Cross-FunctionalPlatforms ・ Backup ・ Provisioning ・ Monitoring , etc. 全社 SLA/SLO/SLI の策定 Database 知⾒共有、教育 Operation Platforms ・Masking Operation ・Point In Time Recovery ・ Release Operation 仕組み化 ・ 命名規則/設計ルール ・ Slow Query Analyze , etc. 各事業部 Database を安⼼安全に誰でも扱うことができる状態 属⼈化の排除 Toil の削減 事業部 SLA/SLO/SLI の策定 19 DBREから考えるビズリーチ流のDBREチームの役割とアクション データストア運⽤のスペシャリ スト データストア運⽤のスペシャリ スト
- 21. 20 DBREから考えるビズリーチ流のDBREチームの役割とアクション 再帰性があり、信頼のできる ツール、仕組みを実現 同じ基準で判断をすることができるよ うな仕組みがあることでの流動的な⼈ 材サイクルを実現 DBREチーム DBRE 推進 ・ DBRE 認知 ・ 全社DBA DBRE化推進 Cross-FunctionalPlatforms ・ Backup ・ Provisioning ・ Monitoring , etc. 全社 SLA/SLO/SLI の策定 Database 知⾒共有、教育 Operation Platforms ・Masking Operation ・Point In Time Recovery ・ Release Operation 仕組み化 ・ 命名規則/設計ルール ・ Slow Query Analyze , etc. 各事業部 Database を安⼼安全に誰でも扱うことができる状態 属⼈化の排除 Toil の削減 事業部 SLA/SLO/SLI の策定
- 22. 21 DBREから考えるビズリーチ流のDBREチームの役割とアクション 再帰性があり、信頼のできる ツール、仕組みを実現 同じ基準で判断をすることができるよ うな仕組みがあることでの流動的な⼈ 材サイクルを実現 横展開できるナレッジを Platform へと昇華 DBREチーム DBRE 推進 ・ DBRE 認知 ・ 全社DBA DBRE化推進 Cross-FunctionalPlatforms ・ Backup ・ Provisioning ・ Monitoring , etc. 全社 SLA/SLO/SLI の策定 Database 知⾒共有、教育 Operation Platforms ・Masking Operation ・Point In Time Recovery ・ Release Operation 仕組み化 ・ 命名規則/設計ルール ・ Slow Query Analyze , etc. 各事業部 Database を安⼼安全に誰でも扱うことができる状態 属⼈化の排除 Toil の削減 事業部 SLA/SLO/SLI の策定
- 23. 22 DBREから考えるビズリーチ流のDBREチームの役割とアクション DBREチーム DBRE 推進 ・ DBRE 認知 ・ 全社DBA DBRE化推進 Cross-FunctionalPlatforms ・ Backup ・ Provisioning ・ Monitoring , etc. 全社 SLA/SLO/SLI の策定 Database 知⾒共有、教育 Operation Platforms ・Masking Operation ・Point In Time Recovery ・ Release Operation 仕組み化 ・ 命名規則/設計ルール ・ Slow Query Analyze , etc. 各事業部 Database を安⼼安全に誰でも扱うことができる状態 属⼈化の排除 Toil の削減 事業部 SLA/SLO/SLI の策定 ここについての お話
- 25. • プラットフォームの⽬的 • スローガン • データベースプラットフォームの前提条件 • データベースプラットフォームについて • 基本設計 • バックアッププラットフォーム • マスキングプラットフォーム（データ連携⽤） • 構築、運⽤していてのメリットデメリット 24 データベースプラットフォームについて
- 26. • プラットフォームの⽬的 • スローガン • データベースプラットフォームの前提条件 • データベースプラットフォームについて • 基本設計 • バックアッププラットフォーム • マスキングプラットフォーム（データ連携⽤） • 構築、運⽤していてのメリットデメリット 25 データベースプラットフォームについて
- 27. プラットフォームの⽬的 No Ops, More Code の実現 • プロダクトのエンジニアがより機能要件に注⼒できる環境を作る • ⾮機能要件に対する品質の担保 • 会社横断的なプラットフォームとして品質の⾼⽔準化を図る 26 データベースプラットフォームについて
- 28. • プラットフォームの⽬的 • スローガン • データベースプラットフォームの前提条件 • データベースプラットフォームについて • 基本設計 • バックアッププラットフォーム • マスキングプラットフォーム（データ連携⽤） • 構築、運⽤していてのメリットデメリット 27 データベースプラットフォームについて
- 30. • プラットフォームの⽬的 • スローガン • データベースプラットフォームの前提条件 • データベースプラットフォームについて • 基本設計 • バックアッププラットフォーム • マスキングプラットフォーム（データ連携⽤） • 構築、運⽤していてのメリットデメリット 29 データベースプラットフォームについて
- 31. データベースプラットフォームの前提条件 • プロダクト稼働率に影響を与えない • 処理によって本番稼働に影響を与えない仕組みの実装 • 設定にかけるプロダクトのエンジニアの⼯数を少なく抑える 30 データベースプラットフォームについて
- 32. データベースプラットフォームの前提条件 • 会社としての要件が担保できること • ⾃分たちのコントロールできない場所で変わることがある • 事件、世論、政治などでも変わるかもしれない • 要件変更に対しても適⽤し続けられる仕組みの実装 31 データベースプラットフォームについて
- 33. データベースプラットフォームの前提条件 • プラットフォームの透明性が担保できること • 事業のデータを取り扱うため、不要なことをしていない、できないこと を証明する必要性がある • 必要なログを全て保存 • ヒトがアクセスできない仕組み • 不要にデータを残しておかない 32 データベースプラットフォームについて
- 34. • プラットフォームの⽬的 • スローガン • データベースプラットフォームの前提条件 • データベースプラットフォームについて • 基本設計 • バックアッププラットフォーム • マスキングプラットフォーム（データ連携⽤） • 構築、運⽤していてのメリットデメリット 33 データベースプラットフォームについて
- 35. プラットフォームの基本設計 • 処理をしたい時にだけ動いているデータベースの構築 • 必要なCPUやメモリに応じた環境構築 • 柔軟な作成、削除が可能 • 本番環境に影響を与えない環境 • 制限をかけない作りを意識 • エンジン(製品)による制限をプラットフォーム側で吸収 • 拡張性のあるプラットフォーム • プログラムを処理パーツとして取り扱えるような設計 34 データベースプラットフォームについて
- 38. 37 データベースプラットフォームについて 事業部 DBREチーム 本番データベース 基本設計 Role プロダクトのエンジニアの⼯数を抑える 最初に設定をしてしまえば、様々なプラットフォームを使える
- 50. 使⽤している主なAWS製品 • Step Functions • CloudWatch Events, Lambda, ECS, EC2など様々な製品連携を可能にするため利⽤ • CloudWatch Events • 時間指定でStep Functionsを実⾏、⼊⼒値によって環境変更を可能にするため利⽤ • ECS(Fargate, EC2)/Lambda/EC2 • プログラム実⾏ • 必要に応じて適切な使い分けが可能 49 データベースプラットフォームについて
- 51. Security に対する取り組み 必要なログを保存 • 処理⽤データベースに対する監査ログ • AWS アカウントそのものに対する CloudTrail 50 データベースプラットフォームについて
- 52. Security に対する取り組み ヒト がアクセスする必要はない • Restore をしたタイミングで毎回ランダムパスワードを設定 • システム的にパスワードが保持されているだけでいい状態 51 データベースプラットフォームについて
- 53. Security に対する取り組み 必要な処理が完了したタイミングで全て掃除 • 処理⽤データベースはもちろん、Snapshotも含めて全て削除 • 不要にデータを保持しておかないことでリスクを最⼩限に抑える 52 データベースプラットフォームについて
- 54. • プラットフォームの⽬的 • スローガン • データベースプラットフォームの前提条件 • データベースプラットフォームについて • 基本設計 • バックアッププラットフォーム • マスキングプラットフォーム（データ連携⽤） • 構築、運⽤していてのメリットデメリット 53 データベースプラットフォームについて
- 55. バックアッププラットフォーム • ⽬的 • データの信頼性 • 要件 • 指定された過去の情報を閲覧可能な状態にする。 • 期間（1年半 ：daily, それ以降：Monthly ） • バックアップは各エンジンの標準バックアップ • 取得したバックアップは復元場所を意識しなくて良いようにするため • MySQL：mysqldump , PostgreSQL：pg_dump ※ サービス継続に必要なもの（PITR等）はマネージドサービスに任せる。 54 データベースプラットフォームについて
- 56. 55 データベースプラットフォームについて バックアッププラットフォーム Parallel 事業部 DBREチーム Lambda [initialize] AWS Step Functions workflow DynamoDB [Master table] [Step table] Fargate [GetSnapshot] Get Item Role AsuumeRole Sts credentials CreateSnapshot Policy -"rds:Describe*", -"rds:ModifyDBClusterSnapshotAttribute", -"rds:CreateDBClusterSnapshot", -"rds:DeleteDBClusterSnapshot", -"rds:CreateDBSnapshot", -"rds:ModifyDBSnapshotAttribute", -"rds:DeleteDBSnapshot" RDS RDS or Aurora SnapShot RDS SnapShot RDS or Aurora Fargate [RestoreSnapshot] SharedSnapshot Fargate [Database Backup] Restore SnapShot Backup for s3 S3 Fargate [CleanUp …] Delete SnapShot Delete RDS DynamoDB [Step table] Lambda [StepStatus…] Fargate [Restore Test] Resotre test Fargate [Store Info] Store Info Get Store Info
- 57. ワークフローの流れ 1. Initialize DynamoDBに格納している情報から実⾏に必要なパラメーターの読み込み・組み⽴て 2. Get SnapShot 事業内の RDS で SnapShot を作成、コピー、DBRE チームアカウントに共有 3. Restore SnapShot DBRE チーム内のアカウントに共有されたスナップショットを展開 4. Backup for s3 テーブル単位でパラレルにバックアップしS3に保存 4. Store Info テーブルの件数、チェックサムを取得 5. Restore Test Drop & Restore テーブルの件数、チェックサムを⽐較する。 6. Cleanup 後処理 56 データベースプラットフォームについて バックアッププラットフォーム
- 60. 59 データベースプラットフォームについて 事業部 DBREチーム 本番データベース 処理⽤ データベース リストアテスト バックアッププラットフォーム BackUp & CheckSum Upload BackUp & Check Sum Info S3 バックアップ ＆ アップロード チェックサム
- 61. 60 データベースプラットフォームについて 事業部 DBREチーム 本番データベース 処理⽤ データベース リストアテスト バックアッププラットフォーム Drop & Restore & CheckSum S3 DownLoad BackUP & CheckSum Info バックアップ ＆ アップロード チェックサム
- 62. バックアッププラットフォームの特徴 • 基本的な処理はサーバーレス • サーバー管理＆⼈のアクセスが発⽣しない • セキュリティ⾯、運⽤⾯の強化 • 多重実⾏になっても⼲渉し合わない • それぞれのワークフローごとに処理される必要なデータベース、コンテナが起動される 61 データベースプラットフォームについて
- 63. バックアッププラットフォームの特徴 • リストアテストの実装 • リストアのテストが⾏われたバックアップがある • 信頼性の向上 • バグ、不整合データの発⾒につながる • 実例：ユニークキーがあるにも関わらず、同じキーが２レコード存在するバグがあった • ⾦銭コストが⾼い 62 データベースプラットフォームについて
- 64. • プラットフォームの⽬的 • スローガン • データベースプラットフォームの前提条件 • データベースプラットフォームについて • 基本設計 • バックアッププラットフォーム • マスキングプラットフォーム（データ連携⽤） • 構築、運⽤していてのメリットデメリット 63 データベースプラットフォームについて
- 65. マスキングプラットフォーム（データ連携） • ⽬的 • データ連携の簡略化 • 要件 • TSVのマスキングファイルの作成 • 定義ファイルに指定された通りのマスキング • 全件抽出 • マスキングファイルとセットでDDLを⽤意 • DDLはInformation schemaからテーブル定義を参照し、MySQLとBigQuery⽤のDDLを⽣成 64 データベースプラットフォームについて
- 66. DBREチーム 65 データベースプラットフォームについて 事業部 Lambda [initialize] AWS Step Functions workflow DynamoDB [Master table] [Step table] Fargate [GetSnapshot] Get Item Role AsuumeRole Sts credentials CreateSnapshot Policy -"rds:Describe*", -"rds:ModifyDBClusterSnapshotAttribute", -"rds:CreateDBClusterSnapshot", -"rds:DeleteDBClusterSnapshot", -"rds:CreateDBSnapshot", -"rds:ModifyDBSnapshotAttribute", -"rds:DeleteDBSnapshot" RDS RDS or Aurora SnapShot RDS SnapShot RDS or Aurora Fargate [RestoreSnapshot] SharedSnapshot Restore SnapShot Masking Extraction S3 Fargate [CleanUp …] Delete SnapShot Delete RDS DynamoDB [Step table] Lambda [StepStatus…] File Upload マスキングプラットフォーム（データ連携）
- 67. ワークフローの流れ 1. Initialize DynamoDBに格納している情報から実⾏に必要なパラメーターの読み込み・組み⽴て 2. Get SnapShot 事業内の RDS で SnapShot を作成、コピー、DBRE チームアカウントに共有 3. Restore SnapShot DBRE チーム内のアカウントに共有されたスナップショットを展開 4. Masking Extraction 定義に基づいたマスキングファイルの抽出 5. File Upload 抽出されたマスキングファイルのアップロード 6. CleanUp 後処理 66 データベースプラットフォームについて マスキングプラットフォーム（データ連携）
- 72. マスキングプラットフォーム（データ連携）の特徴 • ECS on EC2を採⽤ • ⼤量のデータを処理す場合に必要なディスク性能を確保するため • マスキングは全てSQL構⽂で完結 • 差分更新に対応していない 71 データベースプラットフォームについて
- 73. • プラットフォームの⽬的 • スローガン • データベースプラットフォームの前提条件 • データベースプラットフォームについて • 基本設計 • バックアッププラットフォーム • マスキングプラットフォーム（データ連携⽤） • 構築、運⽤していてのメリットデメリット 72 データベースプラットフォームについて
- 74. 構築、運⽤していてのメリットデメリット メリット • 様々な RDBMS に対応可能なプラットフォームの構築が可能 • スナップショットの取得、展開、RDBMSの種類についてなどAPIで操作可能 • APIの情報を元にプログラムの切り替えができる。 • プラットフォームとして拡張性が⾼い • リソース（インスタンスサイズ）の調整が容易 • Step Functionsを利⽤してのプラグラムをパーツとして⾃由に扱える 73 データベースプラットフォームについて
- 75. 構築、運⽤していてのメリットデメリット メリット • ⼼理的安全性の確保 • コスト⾯でも処理時のみのリソースを⽴ち上げる • 本番環境とは別環境になるため、負荷を気にする必要がない • プラットフォーム全体がコード管理 • プログラムはもちろん、インフラ周りもコード化 • どこのアカウントでも環境が再現できるようになっている。 74 データベースプラットフォームについて
- 76. 構築、運⽤していてのメリットデメリット デメリット • コントロールできないことは許容すること • 時間の正確性がない • 各リソースの⽴ち上がりにがかかり、特にデータベースの⽴ち上がりは1h過ぎることも • AWS製品への寄り添ってあげること • バグだったり、仕様書に間違いはある 75 データベースプラットフォームについて
- 77. 76 さいごに
- 78. さいごに 77 アプリケーションの稼働率を守る • 存在する様々な武器をどの様に使うかが重要 • 武器を使う上で DBA としての 知⾒、経験はとても重要 • DBA としての専⾨的な知識、技術を誰でも使える形にすることでDatabase の信頼性 を担保するためのアクションが出来ることが⼤きな武器になる
- 79. thank you for listening 78 ご静聴ありがとうございました。