MBAAで覚えるDBREの大事なおしごと

Copyright © 2019 Yahoo Japan Corporation.AllRights Reserved.
2019/09/25
1
db tech showcase 2019
佐藤誠
MBAで覚える
DBREの大事なおしごと

自己紹介
2
佐藤誠
• ヤフー（株）
• システム統括本部
• サービスプラットフォーム本部
• 業務
• 社内のDB/DataStore全般の導入支援

本日の内容
今回は、ヤフーのデータベースシステムのうち、
Monitoring Backup アカウント管理監査
(audit）
といった非機能部分にフォーカスして、
ご紹介していきたいと思います
タイトルはそれぞれの頭文字を取って M B A です
3

本日の内容
1. Yahoo! JAPAN概
要
2. DBRE
3. M
4. B
5. A
4
6. おわりに

Yahoo! JAPAN 利用者数
5
9,300万1⽇
ユニーク
ブラウザ
※出所︓Yahoo! JAPAN社内データ（2017年）

巨大なデータプラットフォーム
6
NoSQL
Object
Storage
DWH
Hadoop
RDB
4200 node
500PB
1,000,000
Query/day
50bn
objects
6000+
nodes
2000
DBs

DBRE
7
Database Reliability Engineering
（DBRE）
• 日本ではビズリーチさんがDBRE
チームを発足
• ブログ記事で発信するなど認知度が
上がってきている
※まだ和訳本ナシ

DBRE
8
Laine Campbell & Charity Majors氏が提
唱
Percona live dublin 2017

DBREの役割
9
Educator and Mentor （教育）
Platform Builder （プラットフォーム構築）
Force multiplier （戦力倍増/自動化）
Operations Expert （運用エキスパート）
t-shaped （深い専門領域＋広い見識）

DBRE領域の業務（ヤフーの場
合）
1
0
データベースの非機能要件
システムの構築運用
Provisioning / Monitoring / Backup
セキュリティ Audit / Authentication / Encryption
アカウント管理
データベース予算管理 Counting
社内教育社内セミナー / 新卒・中途向け研修
データベース利用ガイドラインの作成

今RDB何台くらいあるの？
1
1
PF バージョンなど DB数ホスト数
Oracle（オンプレ）バージョン
11.2.0.4
12.1.0.2
12.2.0.1
260 1200台
（実機）
MySQL V1（オンプレ）バージョン
5.6
5.7
340 1000台
（実機）
MySQL DBaaS
（プライベートクラウド）
バージョン
5.7
1730 5200台
（仮想VM）

ミドルウェア
(MySQL)
DB Monitoring
1
2
OS監視
ミドルウェア
(Oracle)
ストレージ
ネットワーク
可視化(FE) リポジトリ(BE)
Kanseito（内製）
AWR Warehouse
Uchiwa

ミドルウェア
(MySQL)
DB Monitoring（3年前）
1
3
OS監視
ミドルウェア
(Oracle)
ストレージ
ネットワーク
＋内製ツール
Nagios
Nagios
Nagios
MRTG
MRTG

ミドルウェア
(MySQL)
DB Monitoring（3年前）
1
4
OS監視
ミドルウェア
(Oracle)
ストレージ
ネットワーク
＋内製ツール
Nagios
Nagios
Nagios
MRTG
MRTG
3年も立つと大分変わる
Nagios / Zabbix / MRTGは（弊社では）絶滅が近い・・・

ミドルウェア
(MySQL)
DB Monitoring
1
5
OS監視
ミドルウェア
(Oracle)
ストレージ
ネットワーク
AWR Warehouse

ミドルウェア
(MySQL)
DB Monitoring
1
6
OS監視
ミドルウェア
(Oracle)
ストレージ
ネットワーク
AWR Warehouse
• Enterprise manager：死活監視/リソース監視
• elasticsearch＋kibanaでEMのメトリックデータを吸い出し、
キャパシティプランニングに利用

ミドルウェア
(MySQL)
DB Monitoring
1
7
OS監視
ミドルウェア
(Oracle)
ストレージ
ネットワーク
AWR Warehouse
• OSのログ、DBのログをelasticsearchに流し込んでGrafanaで可視化
• Grafanaは全社に開放。DBAと開発者が同じ数値をみて目線を合わせる

ミドルウェア
(MySQL)
DB Monitoring
1
8
OS監視
ミドルウェア
(Oracle)
ストレージ
ネットワーク
AWR Warehouse• ストレージのモニタリングはGrafana＋influxdb
• ネットワークのモニタリングはGrafana＋Prometheus
• どちらも時系列DB

Oracle Enterprise Manager
1
9

Oracle Kibana+elasticsearch
2
0

Oracle Kibana+elasticsearch
2
1
• EMだと、メトリックを集約して表示、というのができないので、
• こちらをキャパシティープランニングに使う

Oracle
EM/Kibana/AWRWarehouse
2
2
• 見える化を強化、ただ、全体的に古くなってきた感
• EM13.3使ってみたい
• Grafana+Prometheus使ってみたい
DB EM DB
AWRデータ
⾃動レポート
(定型グラフ等)
DB
AWRデータ
DB
AWRデータ
EMサーバ
アプリ
チームA
メール
サーバ
全社DBA
メール配信
(自動)
BI Publisher
kibana
アプリ
チームB
必要に応じて分析
セルフサービス
で自己参照

MySQL Grafana
監視メトリックのデモ
2
3
• MetricViewer

MySQL Grafana
2
4
• slow-query-summary

MySQL
2
5
コンポーネント
sensu
rabbitmq
uchiwa
Redis
grafana
elasiticsearch

ストレージ Grafana+InfluxDB
2
6

ネットワーク
Grafana+Prometheus
2
7

ネットワーク
Grafana+Prometheus
2
8
ちなみにネットワークのPrometheus活用事例は
Slideshareにありますので興味ありましたら是非
https://www.slideshare.net/techblogyahoo/prometheus-148831678

DB Monitoring
OS/DBだけでなく、ストレージ、ネットワークの監視も
しっかり出来るようにしておく事が重要
DB寄りでない業務
• OSSの選定
• pluginの組み込みや開発
• 非DBコンポーネントの運用
は新しいスキルを身につける絶好の機会
なにより、楽しい
UIがかっこいいとやる気が出る
2
9

本日の内容
1. Yahoo! JAPAN概
要
2. DBRE
3. M
4. B
5. A
3
0
6. まとめ

Backup/BCP
Bの話、いうことでここではBackup/BCPをまとめて扱い
ます
• Backupは、「取れて当たり前」「誰にも褒められない」
• 「取れていない場合」凄く怒られる
• ポジティブに評価されない
• とにかくお金がかかる
3
1
このハードな業務に、
どう対処していけば良いのか

Backup/BCP
Backupの大事なポイント
• システムのRTO/RPOを設定しよう
• Buckup手段を知ろう
• Buckup製品を使おう（Oracleのみ）
• Backup/Recoveryトレーニングを定期的に実施し
よう
3
2

Backup/BCP
RTO/RPOをどこにするか、を意識してBackupの設計をする
• RTO（Recovery Time Objective）：目標復旧時間
• RPO（Recovery Point Objective）：目標復旧ポイント
3
3

Backup/BCP
例1）ショッピングの受注受付DB
• 30分止まると売上が○○億減る
• 停止時間はできるだけ短く
• 受注データの消失は許されない、ただ、受注ログは残ってい
るため、論理的にデータを戻すことは可能
RTO=30分以内／RPO=極力消失させたくないが、戻す事も可
30分以内に確実に復旧、かつ停止時間を極小化したい
DataGuardを自動FOかつ最大パフォーマンスモードで
運用3
4

Backup/BCP
例2）社内の購買データ管理システム
• 業務時間中に動いていれば問題なし
• 1日程度であれば停止OK
• 入力データが消えたとしても、最悪前日分に戻せれば問題な
し
RTO=1日／RPO=1日前に戻せればOK
デイリーのRMANで十分
3
5

RTOとRPO
3
6
目
標
復
旧
時
間
RPO：目標復旧ポイント
day min sec
day
min
sec
Oracle
RMAN/expdp
MySQL
Slave tar保存
Mysqldump
XtraBackup
Oracle
DataGuard 自動FO
Mysql
Master/Slave Replica
PXC MultiMaster

Backup手段(Oracle
費用リカバリ時間(RTO) データロス(RPO)
スタンバイ
機利用
世代/遠隔地
Zero Data Loss
Recovery
Appliance
数千万～
数億円
○
リカバリ（仮想Full
image）1h～数日
○
ほぼなし（リアルタイム
REDO転送
- 世代/遠隔地
DataGuard
（Replication)
数千万～
数億円
◎
切替（6秒～数分）
◎～○
なし(最大可用性
ほぼなし（最大パ
フォーマンス
○
（Active
DataGuard
遠隔地
RMAN+
アーカイブログ
￥0～1000万円台
nfsやNWスイッチ代
△
リカバリ（full+差分）
3h～数日
○
ほぼなし（アーカイブロ
グのあるところまで
- 世代
expdp / impdb
￥0～1000万円台
△ -△ - -
3
7

Backup手段(Oracle
費用リカバリ時間(RTO) データロス(RPO)
スタンバイ
機利用
世代/遠隔地
Zero Data Loss
Recovery
Appliance
数千万～
数億円
○
リカバリ（仮想Full
image）1h～数日
○
ほぼなし（リアルタイム
REDO転送
- 世代/遠隔地
DataGuard
（Replication)
数千万～
数億円
◎
切替（6秒～数分）
◎～○
なし(最大可用性
ほぼなし（最大パ
フォーマンス
○
（Active
DataGuard
遠隔地
RMAN+
アーカイブログ
￥0～1000万円台
△
リカバリ（full+差分）
3h～数日
○
ほぼなし（アーカイブロ
グのあるところまで
- 世代
expdp / impdb
￥0～1000万円台
△ -△ - -
3
8
• バックアップやDGだけCloudに組むという選択肢もある
• Database Cloud Service (DBCS)でDGを組む
• Oracle Database Backup Service でRMANをとる 1Tあたり 4,752円/月

Backup手段(MySQL
リカバリ時間(RTO) データロス(RPO)
スタンバ
イ機利用
世代/遠隔地
バックアッ
プ運用
Slave Replica
◎
切替（数分以内）
○～◎
ほぼなし
バイナリログが転送されていれ
ば
○ 遠隔地 -
Slaveを停止し
てtarで固める
○
リカバリ3h～数日
△
最新バックアップ以降はロスト
○ 世代/遠隔地フル
Xtrabuckup
○
リカバリ（full+差分）3h～数
日
Mysqldumpより高性能
○
ほぼなし
バイナリログがあれば
- 世代
フル/差分/
増分
mysqldump
△
日
○
ほぼなし
- 世代
フル/差分/
増分
3
9

Backup手段(MySQL
リカバリ時間(RTO) データロス(RPO)
スタンバ
イ機利用
世代/遠隔地
バックアッ
プ運用
Slave Replica
◎
切替（数分以内）
○～◎
ほぼなし
バイナリログが転送されていれ
ば
○ 遠隔地 -
Slaveを停止し
てtarで固める
○
リカバリ3h～数日
△
最新バックアップ以降はロスト
○ 世代/遠隔地フル
Xtrabuckup
○
日
Mysqldumpより高性能
○
ほぼなし
- 世代
フル/差分/
増分
mysqldump
△
日
○
ほぼなし
- 世代
フル/差分/
増分
4
0
• Mysqlはあまり選択肢がない
Replicaとフルバックアップ。差分バックアップは出来るが使われない
• 有償ツールなどの市場もない
• Yoku0825さんの資料が参考になる ↓
MySQLのバックアップ運用について色々
https://www.slideshare.net/yoku0825/mysql-45256389

Backup Appliance製品
（Oracleのみ
4
1
DataDomain
Zero Data Loss Recovery Appliance
StoreOnce
※シェアのある専用アプライアンスのみ
NetApp SnapManager for Oracle ／ Cohesity などもある

（Oracleのみ
4
2
DataDomain
Zero Data Loss Recovery Appliance
StoreOnce
※シェアのある専用アプライアンスのみ
NetApp SnapManager for Oracle ／ Cohesity などもある
• RMANとシームレスな連携
• データ圧縮
• 重複排除
• 差分があったところだけ転送する
• WAN越しで性能が出る
• 複数拠点、ネットワーク上にちらばるBackup機器統合に向く

（Oracleのみ
4
3
RMAN
RMAN
RMAN
RMAN RMAN
RMAN
Backup Applianceに統合

Backup/BCP の設計
4
4
• そのサービスにとって本当に必要なものは何かをしっかり議論す
る
• RTO/RPOを過剰に設定すると大幅なコスト増
• RTO/RPO要件を満たしていないBackupは無意味
• どんどん伸びるBackup時間への対策
• 手段や設定は適切か（フル、差分、パラレル時間帯
• Applianceの活用
• Backup先のストレージ性能は十分か
• Backup用ネットワークの性能は足りているか（共用、占有、1G/10G
（1Gでは足りない要件が増えている

Backup/Recoveryトレーニング
半期ごとにチーム全員が実施しています
4
5
Oracle

半期ごとにチーム全員が実施しています
4
6
MySQL

• 定期的なトレーニングは絶対に実施した方が良い
• 全員が対応出来る状態にしておく
• 手順書が有効であることをチェック
• 障害対応のスピードと品質を上げるために必要
4
7

• 定期的なトレーニングは絶対に実施した方が良い
• 全員が対応出来る状態にしておく
• 手順書が有効であることをチェック
• 障害対応のスピードと品質を上げるために必要
4
8
障害時の対応は、かなり精神を削られるため、
冷静かつ機械的に対処できるよう、常日頃から障害対応訓練を実施するこ
とが大切

B のまとめ
Backupの大事なポイント
• システムのRTO/RPOを設定しよう
• Buckup手段を知ろう
• Buckup製品を使おう（Oracleのみ）
• Backup/Recoveryトレーニングを定期的に実施し
よう
4
9
データロスト時のリスクをよく話し合った上で、
そのサービス要件に合ったBackupの仕組みを、過不足
ない形で提供する

A
ここでは A についての話となります
Authentication ・・・ユーザー認証について
Account management ・・・アカウント、権限管理
Audit ・・・監査
5
0

ユーザー認証のルール
5
1
No
ユーザー
ユーザー例用途備考
1 オブジェクト所持ユーザアプリケーション名_OBJ オブジェクトの所有者
Create session権限を
つけない
2 アプリケーションユーザアプリケーション名_USR 1のデータ操作ユーザー
オブジェクトを持たな
い。すべて1をGrant
3 サービス運用者
個人アカウント
社内アカウントと同じ名前にする
メンテナンスやデータ確認時な
どに使用するユーザー
DDLを実行できない
4 DBA作業者
SYS/SYSDBAなど
OS認証でDBサーバから作業する
DBA作業用 DDLの実行はこちらで
サービスでDDLを実行しない場合（デフォルト

ユーザー認証のルール
5
2
No
ユーザー
ユーザー例用途備考
1
アプリケーション＆
オブジェクト所持ユーザ
アプリケーション名_USR フルコントロール
個人アカウント
社内アカウントと同じ名前にする
メンテナンスやデータ確認時な
どに使用するユーザー
DDLを実行できる
3 DBA作業者
SYS/SYSDBAなど
OS認証でDBサーバから作業する
DBA作業用
サービスでDDLを実行する場合（希望者のみ

ユーザー管理が結構大変
ユーザーが増減するケース
5
3
No
ユーザー
増えるとき減るとき
1
機能追加や、分割機能の削除
2 アプリケーションユーザ同上
同上
別アプリケーションの利用を許可する
場合
サービス担当が変わるとき
社員、業務委託の入社／異動
社員、業務委託の退社／異動
4 DBA作業者なしなし

ユーザー管理が結構大変
ユーザーが増減するケース
5
4
No
ユーザー
増えるとき減るとき
1
機能追加や、分割機能の削除
2 アプリケーションユーザ同上
同上
別アプリケーションの利用を許可する
場合
社員、業務委託の入社／異動
社員、業務委託の退社／異動
4 DBA作業者なしなし
ヤフープロパー社員の異動が多く
業務委託の着任、離任も頻繁

アカウント管理ツール
内製のアカウント管理ツールで自動化を推進
5
5
アカウント/ロールの追加・変更・削除は画面から
登録でき、自動反映

5
6
アカウント作成時の付与ロールなども細かく指定できる

アカウント台帳機能
5
7
4半期ごとにアカウント、オブジェクトの追加削除をチェッ
クし、承認する仕組み

内製で機能を作り込み、アカウント申請/台帳管理と
いった、必要だが退屈な作業を自動化する
申請、承認が発生する部分なので、社内のワークフロー
システムと連携する必要がある
内製は、継続的な開発コストはかかるが、社内システム
連携や、こまかな自動化を実現するには都合が良い
5
8

監査
弊社ではYID、顧客データ、クレジットカード情報等々
セキュアなデータを多く扱っていて
以下のルールを満たす監査運用を行っている
• J-SOX内部監査
• PCI-DSS
• 社内のDB運用ルール
5
9

監査
• PCI-DSS
6
0
財務報告に係るITシステムが、ユーザーに不利益な変更がなされたり、
不正な処理が紛れ込んでいないか監視するためアクセス、データ更新、プ
ログラム変更の証跡をとる
システム例：財務システム、購買システム、売上管理システム等
弊社の場合だとYDNのシステムもJ-SOX対象

監査
• PCI-DSS
6
1
カードデータを保存してビジネスをしたい会社は、PCI-DSSの認証を取り、セ
キュアにカードデータを取り扱っていることを示す必要がある
DBでは、カードデータにアクセスする問い合わせを全て記録する

監査
• PCI-DSS
6
2
データベース運用管理細則／ログ管理細則なる
厳しいルールで運用

監査
6
3
2013年のデータ漏洩事件
この反省から、全社を挙げてセキュリティ対策を
実施

監査の要件
• 原則として、全てのアクセスログを記録すること
ただし、記録対象の機密の程度に応じ、ログの量、パフォーマンスを考慮して成功または失敗のどちらかのみ取得することを許
容
• ワークフローに対応している(アクセス申請・承認）
• 大量アクセスも捌ける(準リアルタイム監査)
社内のワークフローに対応させるため自社開
発
DB全てのアクセスログを取る！
6
4

統合監査モード
12cから統合監査モード(Unified Auditing)を選択できる
6
5
標準監査
監査ログがOSに、
ファイルで出力される
アクセス
監査ログ(file
アクセス
監査
unified_audit_trail
標準監査
監査ログがDB内、
SYSAUX.unified_audit_trail表に書き
込まれる

統合監査モード
12cから統合監査モード(Unified Auditing)を選択できる
6
6
標準監査
監査ログがOSに、
ファイルで出力される
アクセス
監査ログ(file
アクセス
監査
unified_audit_trail
標準監査
監査ログがDB内、
SYSAUX.unified_audit_trail表に書き
込まれる
秒間5000ログあたりで性能影響が出始める
（標準監査だと秒間1000ログが限界

監査の要件
しかし・・・・
原則として、全てのアクセスログ
を記録すること
6
7

監査の要件
6
8
高負荷で、監査ログ取るのが不可能なDBが存在する
その場合、セキュリティリスク受容をして監査ログ未取
得の状態で運用するが、対応期限がある

監査の要件
• ソフトウェアベンダーさんが監査ツールの営業に来たことがあった
が・・・
6
9
リアルタイム監査なんて聞いたことがない
アプリケーションアカウントの監査ログは出さない
出すのは管理者アカウントの監査ログだけ

監査の要件
• 懇意にしているコンサルさんにも聞いてみた
7
0
統合監査の場合、
5000qpsくらいが性能限界かと～

よく考えてみると
実は、DBと監査、相性が悪すぎる
• プーリングセッション無し
• プーリングあり、キャッシュシステムあり
(Redis/memcachedなど)
で見てみましょう
7
1

プーリングセッション無し
7
2
1.ログイン
監査log insert(login)
監査log insert(logoff)2.ログオフ
3.Select操作
監査log insert(select)
4.Update操作監査log insert(update)

プーリングセッション無し
7
3
1.ログイン
監査log insert(logoff)2.ログオフ
3.Select操作
監査log insert(select)
4.Update操作監査log insert(update)
えっ、監査って
select操作でinsertが発生するの？
キャッシュから結果返しても？？
DBの良いところが全部死ぬ・・・これでは性能も出ない

プーリング/キャッシュシステムあ
り
7
4
1.ログイン
2.ログオフ
3.1. Select操作
監査log insert(3.2. select)
4.Update操作
監査log insert(4. update)
connection
pooling
redis
キャッシュ
あり
3.2. Select操作キャッシュ
なし
監査log insert(logoff)
Pooling session開始/終了時のみ

プーリング/キャッシュシステムあ
り
7
5
1.ログイン
2.ログオフ
3.1. Select操作
監査log insert(3.2. select)
4.Update操作
監査log insert(4. update)
connection
pooling
redis
キャッシュ
あり
3.2. Select操作キャッシュ
なし
監査log insert(logoff)
Pooling session開始/終了時のみ
この場合、監査ログは、
• 3.2. select／4. updateの操作でしか出ない
• プーリングありだと、ログインログオフは正確に取れない
• キャッシュシステムだけで返した場合も
DBに到達してないため監査ログは出ない

監査の要件
DBの監査は正確性に欠くのはわかっ
た
ただし、記録対象の機密の程度に応じ、ログの量、パフォーマンスを考慮して成功または
失敗のどちらかのみ取得することを許容
7
6

監査の要件
ただし、記録対象の機密の程度に応じ、ログ
の量、パフォーマンスを考慮して成功または
失敗のどちらかのみ取得することを許容
7
7
操作の成功は取らなくていい・・・・
＝監査ログほぼ出なくなる
この要件を踏まえて監査仕様を整理しよう

監査ポリシーを刷新
DBのパフォーマンスを考慮して、一部取得しないこと
を許容
7
8
ユーザー
ログイン/ログオフ
成功
失敗 Select成功失敗
Insert/update
deleteほかの操作
失敗
アプリケーショ
ンユーザ
取得しないことを許
容
必須
取得しないことを
許容
必須
取得しないことを許容
必須
サービス運用
者
必須必須必須必須必須必須
DBA作業者必須必須必須必須必須必須

監査ポリシーを刷新
DBのパフォーマンスを考慮して、一部取得しないこと
を許容
7
9
ユーザー
ログイン/ログオフ
成功
失敗 Select成功失敗
Insert/update
deleteほかの操作
失敗
アプリケーショ
ンユーザ
取得しないことを許
容
必須
取得しないことを
許容
必須
取得しないことを許容
必須
サービス運用
者
必須必須必須必須必須必須
DBA作業者必須必須必須必須必須必須
• DBアクセスのほとんどを占めるであろう、
アプリケーションアカウントの正常なselect操作のみを除外した
DBの監査負荷を下げつつ、それ以外のアクセスは監査出来る

A のまとめ
ユーザー認証、アカウント管理、監査
それぞれ一筋縄ではいかない
• 社内のルール遵守
• 承認系システムへの連携
• セキュリティ組織との関わり、監査要件の理解と施行
ヤフーでも長い間苦労してきましたし、現状もベストとは
言いがたいです。セキュリティをしっかり担保しつつも、
常に使いやすくなるよう改善を続けていくことが大事8
0

おわりに
あらためて、
今回は、Monitoring Backup BCP アカウント管理監査
といった非機能部分について、DBREの業務領域と捉えヤフーの
ケースをご紹介しました。ご参考になれば幸いです
実際DBAではない、非機能部分の開発や運用の比重が上がってきて
おり
それは今後より強くなっていくように感じています
そこで「DBRE」という職域が認知され、興味をもつ人が増えてい
くといいなと思います
8
1

EOP
8
2

MBAAで覚えるDBREの大事なおしごと

More Related Content

What's hot

Similar to MBAAで覚えるDBREの大事なおしごと

More from Insight Technology, Inc.

MBAAで覚えるDBREの大事なおしごと