Yahoo! JAPANのOracle構成-2017年版

Copyright © 2017 Yahoo Japan Corporation. All Rights Reserved.1
db tech showcase 2017
佐藤誠
Yahoo! JAPANの
Oracle構成-2017年版
2017/09/06

Copyright © 2017 Yahoo Japan Corporation. All Rights Reserved.
このセッションは
このセッションは、
「Yahoo! JAPANのOracle構成-2017年版」
ということで、弊社のOracle運用について、ここ2年ほど
の取り組みを幅広く発表させて頂きます
※資料は slideshare に上げる予定です
2

自己紹介
3
佐藤誠
• ヤフー（株）
• D&S統括本部データプラットフォーム本部 Oracle
• 業務
• ヤフーで稼働するOracle全台の運用管理
• 社内のOracleコンサルタント

本日の内容
1. Yahoo! JAPAN概要
2. これまでのおさらい
3. 12cR2 MTA導入
4. HW構成
5. BCP
4
6. バックアップ
7. セキュリティ監査
8. 監視
9. 全体まとめ

本日の内容
3. 12cR2 MTA導入
4. HW構成
5. BCP
5
8. 監視
9. 全体まとめ

Yahoo! JAPAN 利用者数
6
9,000万1日
ユニーク
ブラウザ
※出所：Yahoo! JAPAN社内データ（2016年4月-6月の平均）

提供サービス
7
Media
US
Search Video Answer Mail
JP
US
JP
Membership C2C Payment C2C EC B2C EC Local

巨大なデータプラットフォーム
8
NoSQL
Object
Storage
DWH
Hadoop
RDB
6000 node
150PB
1200
DBs
300,000
Query/day
1500
nodes
1000+
nodes

巨大なデータプラットフォーム
9
NoSQL
Object
Storage
DWH
Hadoop
RDB
6000 node
150PB
300,000
Query/day
1500
nodes
1000+
nodes
230/1200
Oracle

本日の内容
3. 12cR2 MTA導入
4. HW構成
5. BCP
10
8. 監視
9. 全体まとめ

過去の発表資料
11
https://www.slideshare.net/techblogyahoo/exadata-oracle-db
2014年 db tech showcase
Exa並の性能を目指して手組みの
PCI-SSD x InfiniBand構成を組んだ話
＋
＋

12
https://www.slideshare.net/techblogyahoo/yahoo-japan-oracle
Oracle Database Connect 2016 LT
IBMのFlashSystemを採用、最大6nodeのRAC
構成を組んでいることや、運用管理ツール
の紹介

本日の内容
3. 12cR2 MTA導入
4. HW構成
5. BCP
13
8. 監視
9. 全体まとめ

稼働Oracleの内訳
14
• Version構成
11.2.0.2
30%
11.2.0.4
25%
12.1.0.2
44%
12.2
1%
12.1.0.2
95%
12.2
5%
年度内に12c移行完了予定
２０１７
Q2
２０１７
Q4

12cR2 MTA導入
• Oracle12cR2がリリース
• R1では見送っていたマルチテナントもやっと使えそう
• MTAを本番で使うかどうしようか・・・
15

DBサーバの統合方式の比較
①ハイパーバイザに
よるサーバ仮想化
(IaaS型資源共有)
• ハイパーバイザによって物理サーバ上に複数の仮想マ
シンを作り、その上で各DBごとにOSとDBMSを並行
実行する方式
物理サーバ
ハイバーバイザ
OS
DBMS
OS
DBMS
OS
DBMS
DB DB DB
③DBマルチテナント
(PaaS型資源共有)
• 1つのDBMS上で、複数のDB（テナント）を実行する
方式。各テナントには、隔離されたDBサーバ環境が仮
想的に割り当てられる
②DBインスタンス
分割
• 1つのOS上でDBごとのDBインスタンスを並行起動す
る方式
物理サーバ
OS
DBMS DBMS DBMS
DB DB DB
④DBスキーマ分割
• 1つのDBインスタンス上で業務DBごとのスキーマを並
行実行する方式
集約密度分離性
低
高
高
低
物理サーバ
OS
DBMS
物理サーバ
OS
DBMS
DB
スキーマスキーマスキーマ
DB DB DB
ヤフー株式会社／日本オラクル株式会社 Confidential 16

DBサーバの統合方式の比較
③DBマルチテナント②DBインスタンス分割
物理サーバ
OS
DBMS DBMS DBMS
DB DB DB
物理サーバ
OS
DBMS
DB DB DB
ヤフー株式会社／日本オラクル株式会社 Confidential 17
一つのコンテナDBで複数のプラガブルDBを動かす

12cR2 MTA導入
• MTAの魅力は、インスタンス用メモリを節約できて、集約度を
上げられる点
• ヤフーの本番想定で検証してみるしかない
18

12cR2 MTA導入
判定項目検証内容
DB構築
dbca silentによるPDB作成
PDBのリモート・クローン
初期化パラメータがこれまで同様のセッティング可能か
リソース制御
CPU, Memory, I/O,process数などリソース制御が想定レ
レベルで可能か
バックアップ・リカバリ
リ
PDB毎の完全リカバリと不完全リカバリ
異なる文字コードのPDBのバックアップ / リカバリ
BCP DataGuard/自動FailOverをPDB単位で組めるか
19
• 検証

12cR2 MTA導入
判定項目検証内容
○ DB構築
dbca silentによるPDB作成
PDBのリモート・クローン
初期化パラメータがこれまで同様のセッティング可能か
△ リソース制御
CPU, Memory, I/O,process数などリソース制御が想定レ
レベルで可能か
○
バックアップ・リカバリ
リ
PDB毎の完全リカバリと不完全リカバリ
異なる文字コードのPDBのバックアップ / リカバリ
× BCP DataGuard/自動FailOverをPDB単位で組めるか
20
• 検証

12cR2 MTA導入まとめ
• 結論
1. 本番でのマルチテナント稼働は見送り
• パラメータをPDBで個別に持てないものがある
• CDBのメンテナンスや障害時は全PDBに影響がある等、DBごとの独立性に難がある
• PDBレベルのDataGuard/自動FailOverは組めない
2. 開発環境には導入する
• 開発環境はメモリ節約のメリット
• PDBのクローンや引越しが容易
21

本日の内容
3. 12cR2 MTA導入
4. HW構成
5. BCP
22
7. セキュリティ・監査
8. 監視
9. 全体まとめ

HW構成（RAC）
手組み構成のおさらい（2013～第3世代
23
Infinibandスイッチ
IAサーバ
IAサーバ＋virident

HW構成（RAC）
24
Infinibandスイッチ• 凄く速いけどIBと、SSDが超不安
定・・・
• 値段はめちゃ安
IAサーバ
IAサーバ＋virident

HW構成（RAC）
25
FCスイッチ
IAサーバ
IBM FlashSystem

HW構成（RAC）
26
FCスイッチ
IAサーバ
IBM FlashSystem
• 第3世代と近い性能
• FCとIBM FlashSystemで高い安定
性
• 第3世代の不安定さに懲りて、安
定を取った！
• 値段は第3世代より高価

HW構成（RAC）
• RACは6ノード以上で構成し、追加リソースが必要な場合に備える
• 北九州の拠点は12ノードRAC構成
27
インスタンスA インスタンスB
インスタンス
C
インスタンス
D
Oracle RAC *12nodes

HW構成（RAC）
• RACは6ノード以上で構成し、追加リソースが必要な場合に備える
• 負荷やサービスリリースに合わせてインスタンスを増やすことが容易
28
インスタンスD
nodeを3つ追加
インスタンスA インスタンスB
インスタンス
C
Oracle RAC *12nodes

HW構成（Exa）
29
• Exadata 現在5台稼働中（下期に2台購入予定）
• サービス集約用途で計画に合わせ導入
サービス 2010 2014 2015 2016 2017上半期 2017下半期
YJ共通 X-6 half
×2
広告 X-2 Full X-4 Full
決済 X-6 half×2 X-6 half
ショッピン
グ
X-6 half
EOSL移行

HW構成（Exa）
30
• Exadata 現在5台稼働中（下期に2台購入予定）
• サービス集約用途で計画に合わせ導入
サービス 2010 2014 2015 2016 2017上半期 2017下半期
YJ共通 X-6 half
広告 X-2 Full X-4 Full
決済 X-6 half×2 X-6 half
ショッピン
グ
X-6 half
EOSL移行
X-2 はゴミだったが、選択肢がそれしかなかった
X-4 は安定性が向上し、落ちなくなったがまだお高
かった
X-6 で性能、価格、安定性のバランスが取れた

HW構成
31
性能可用性保守お値段
第三世代 ○ × × ◎
第四世代 ○ ○ △ ○
Exadata X-
6
half
○ ○ ○ ×⇒○

HW構成
32
性能可用性保守お値段
第三世代 ○ × × ◎
第四世代 ○ ○ △ ○
Exadata X-
6
○ ○ ○ ×⇒○
• Exadata X-6は、アプライアンス製品なので、保守が
○
• まるっと一括保守（ASR（Auto Service Request）
は本当にラクです
• 安定性、性能、価格も問題なし

HW構成まとめ
• 結論
1. 第3世代(PCI-virident)を年度内に捨てる
2. 第4世代(IBM FlashSystem)をニーズに応じて
配置していく
3. 新しくDBクラスタを作る場合は、Exadataを入れてし
まった方が、導入、構築、運用コストを下げることが
出来る
※注ヤフーで組んだ場合の価格です
Oracleはソフトウェアライセンスが高額で、とくにExaはストレージライセンスが追加で掛かります33

本日の内容
3. 12cR2 MTA導入
4. HW構成
5. BCP
34
8. 監視
9. 全体まとめ

BCP
35
• BCP
• Business continuity planning
• 地域災害によるサービス停止の対策
• Oracle DataGuard & FSFO(Fast-Start Failover)

36
https://www.slideshare.net/techblogyahoo/oracle-data-guard-
48172431
2015年 Meetup! JPOUGイベント
Yahoo! ニューストピックスで導入した
話
プライマリサイトが破壊されても、30
秒程度でBCPサイトを稼働できる

Data Guardとは
37
Primary
DB
Standby
DB
Standby
DB
Standby
DB
• Oracle Databaseのレプリケーション機能
• １つ以上のStandby DBを構成することが可能
• リアルタイムなデータ連携も可能
• データ保護、災害時のリカバリに適している

Standby DBPrimary DB
Data Guardによるデータ転送
38
Data Files
• Primary DBからRedoログが転送される
• Standby Redoログからデータファイルへのリカバリが行われる
Standby
Redo
Redo
Data Files
DB
Instance
DB
InstanceRedo転送
リカバリ
同じデータ

Standby DBPrimary DB
SwitchOver
39
Data Files
• Standby DBをPrimary DBへ変更して利用可能
• Standby Redoの更新ログは全てリカバリ可能
• 最大可用性モードであればデータロスト無し
Standby
Redo
Redo
Data Files
DB
Instance
DB
InstanceRedo転送
リカバリ
同じデータ
DOWN
全ての
Redoを適
用し
DB Open
SwitchOverは手動で行う
DGMGRL> switchover

FailOver
40
• Observerを導入する事で可能
• Primary DBを死活監視
• 障害検知時にStandby DBへフェイルオーバー命令
• Standby DBが自動でOpenされ、使用可能となる
Primary Site Standby Site
Standby
DB
Primary
DB
Observer
死活監視
FailOver
命令
DOWN
Up

FailOver運用で大事なこと
41
Standby
DB
Primary
DB
Observer
AP Primary AP Standby
理想 GSLB

42
Standby
DB
Primary
DB
Observer
理想 GSLB

43
Standby
DB
Primary
DB
Observer
理想 GSLB
DOWN
Up

44
Standby
DB
Primary
DB
Observer
理想 GSLB
DOWN
Up

45
Standby
DB
Primary
DB
Observer
AP Primary
現実

46
Standby
DB
Primary
DB
Observer
AP Primary
現実
DOWN
Up

47
Standby
DB
Primary
DB
Observer
AP Primary
現実
DOWN
Up

48
Standby
DB
Primary
DB
Observer
AP Primary
現実
DOWN
Up
• DBの障害には対応出来ているが、DR（Disaster
Recovery）になっていない
• 拠点を跨いでしまうため、レイテンシが上がる
• FOしちゃったけど性能が出ず、やっぱり戻す

49
Standby
DB
Primary
DB
Observer
理想 GSLB

50
Standby
DB
Primary
DB
Observer
理想 GSLB
DOWN
Up

51
Standby
DB
Primary
DB
Observer
理想 GSLB
DOWN
Up
• FOしてStandbyサイトに切り替わっても、
• 同等のサービスが提供出来ること

BCPまとめ
52
• Good
• 現在10DBほどFSFOを組んでいる
（ニュース、決済、ショッピング、Ymobileなど）
• FOのおかげで大事故にならなかったケースが年に2回くらいある
• Bad
• 自動で切り替える（FSFO）には、プライマリ、スタンバイ監視Observerを構築
する必要がある
• アプリケーションレイヤーがFOに追従できるように設計、運用しないと障害点
が増えるだけ
• Standbyサイトは寝かせておくので、設備投資が2倍
• たまに暴発する（拠点ネットワーク障害、単一ストレージ障害）

本日の内容
3. 12cR2 MTA導入
4. HW構成
5. BCP
53
8. 監視
9. 全体まとめ

バックアップ
• ここではバックアップ＝RMAN（Recovery manager）
の話をします
54

バックアップ
• 弊社のOracleバックアップに関するSLA
1. 毎日バックアップ（差分、フルどちらでも良い）
2. 1週間保持（WINDOW OF 7 DAYS）
3. 遠隔地に保存
55

バックアップ
1. 毎日バックアップ（差分、フルどちらでも良い）
56
DBによっては10Tを超えるバックアップを
毎日遠隔地に保存するのは大変

cluster3
cluster2
cluster1
バックアップ
57
Backup用cluster
Redo
• 遠隔地に過去7日分のデータを保存することが出来ず、
DataGuardで直近のデータのみ保全
Redo
RMAN
RMAN
RMAN
Redo

cluster3
cluster2
cluster1
バックアップ
58
Backup用cluster
Redo
• 遠隔地に過去7日分のデータを保存することが出来ず、
DataGuardで直近のデータのみ保全
Redo
RMAN
RMAN
RMAN
Redo
DataGuardの使い方としては邪道
NASをclusterごとに大量に買っていた
ClusterのVLAN内にNASを置かないと、バックアップが終わらな
い

バックアップ
• そこで「重複排除ストレージ」を導入する
59

バックアップ
• 重複排除(Dedupe)機能で実保存データ量が1/10～1/15
• VTL（仮想テープデバイス）を複数作成
• しかも、WAN越しにVTLに保存可能
• WAN越しでも重複排除が効くためネットワーク負荷が激
減
• 常にフルバックアップで保存（リストアが速くなる）
• 1日50T保存しても問題ナシ
60

バックアップ
• 弊社ではHPE StoreOnceを導入
• 必要な機能と価格のバランスが良かった
61

バックアップ
• 1日25Tのバックアップを7日間保存してみる
62

バックアップ
• 1日25Tのバックアップを7日間保存してみる
63
25.4T(RMAN) * 7(days) =178.4T
178.4T / 15.2(Dedupe率) = 11.7T
実際の保存容量は 11.7T

バックアップ
64
• バックアップストレージを集約
＝

cluster3
cluster2
cluster1
バックアップ
65
• 遠隔地にWAN越しで直接RMANバックアップ
• WAN越しでも、差分データのみ送る(RMAN Catalyst plugin)
RMAN
RMAN
RMAN

バックアップ
1. 毎日バックアップ（フル）
66
すべてを満たすことが出来
た

バックアップまとめ
• バックアップ専用の重複排除ストレージを使う事で
構成をシンプルに
• バックアップの運用で
• 時間（バックアップ／リカバリ）
• 容量
• ネットワーク
の問題を抱えている場合は、
重複排除ストレージを検討してみる
67

本日の内容
3. 12cR2 MTA導入
4. HW構成
5. BCP
68
8. 監視
9. 全体まとめ

セキュアなデータ
弊社ではYID、顧客データ、クレジットカード情報等々
セキュアなデータを多く扱っている
アクセス監査が必要
内部監査、PCI-DSS etc...
69

監査の要件
• ワークフローに対応している(アクセス申請・承認）
• 大量アクセスも捌ける(準リアルタイム監査)
• 社内のワークフローに対応させるには自社開発するしかない
• 大量の監査ログをどうやってサービス影響なく出力して回収するか?
70

統合監査モード
12cから統合監査モード(Unified Auditing)を選択できる
71
cd $ORACLE_HOME/rdbms/lib
make -f ins_rdbms.mk uniaud_on ioracle
SQL> SELECT VALUE FROM V$OPTION WHERE PARAMETER = 'Unified Auditing';
PARAMETER VALUE
---------------- ----------
Unified Auditing TRUE

統合監査モード
• 監査ログがunified_audit_trail表に集約される（SYSAUXに保存）
• キャッシュが効く(※UNIFIED_AUDIT_SGA_QUEUE_SIZE)
⇒AUDITレコードをSGAキューに溜めておいて、しきい値を超えたらSYSAUXにフラッシュする
秒間3000ログでもサービス影響なし
※12cR2から非推奨パラメータ（後方互換性は保持）
72

監査ログの退避
• システム側の監査ログ回収がボトルネック
→ unified_audit_trailが溢れるとサービス停止のリスク
5分おきにunified_audit_trailを回収用テーブルに退避&パージ
73
unified_audit_tral 回収用テーブル退避&パージ回収サーバー監査ログ回収

インシデント
• 各データベースの監査ログを監査マスターDBに集約
• バッチでホワイトリストと監査ログを突き合わせ
問題のあるアクセスについて、担当者にインシデントをあげる
74
回収サーバー監査マスターDB監査ログ集約バッチサーバー監査ログ精査

インシデント管理画面
75

インシデント詳細
76

インシデント詳細
77
許可されていないセキュアアクセス
・サーバ
・アクセス元
・OSユーザ
・DBユーザ
・コマンド
がインシデントとして上がってくる

セキュリティ監査まとめ
• セキュアなデータを運用する以上、アクセス監査の仕組みが
必ず必要になる
• Oracle12cから使える統合監査モードは、監査処理のボトル
ネックを解消しており、3000qpsでも処理可能
• 社内の要件を取込み、アクセス監査の仕組みを構築した
• アクセス申請・承認機能
• 大量アクセスをさばける
78

本日の内容
3. 12cR2 MTA導入
4. HW構成
5. BCP
79
8. 監視
9. 全体まとめ

Oracleの監視と言えば
• 代表的なものは
Enterprise Manager ですが・・・
80

Enterprise Manager
• ヒドすぎるUI
• 機能が多すぎて途方に暮れる
• 特に12c
81

Enterprise Manager13cR2
• 13cR2でUIがだいぶマシになった
• 実用に耐えうるレベル
• ExaのHW監視も出来るため、Exaを運用するにはほぼ必須
82

Enterprise Manager13cR2
• 13cR2でUIがだいぶマシになった
• 実用に耐えうるレベル
• ExaのHW監視も出来るため、Exaを運用するにはほぼ必須
83
EMだけなぜか13cにメジャーバー
ジョンアップしてしまった。不評す
ぎて12cを切り捨てたんじゃないか
説

DBの監視レイヤー
• DBの監視レイヤー
84
OS監視
OS up,/down/Local disk / Syslog / login/
process
インスタンス監視
インスタンスup,down / tablespace / ORA-
XXXX
ASM監視
ASM disk space / diskgroup /ocr
Storage監視
Storage 容量 / I/O / Network
※MRTGやHWベンダーの監視ツール

85
OS監視
process
XXXX
ASM監視
Storage監視
※MRTGやHWベンダーの監視ツール
自作ツールで
頑張っていた
←ASMだけはEM11gで監視していた

86
OS監視
process
XXXX
ASM監視
Storage監視
※ExaはEMでストレージ監視できる

87
OS監視
process
XXXX
ASM監視
Storage監視
※ExaはEMでストレージ監視できる
全レイヤーをEM1台で監視できる

パフォーマンス監視
• パフォーマンス監視をラクにしたい
• APやDBの性能が落ちたら、AWR（Automatic Workload
Repository）を取って改善箇所を見つけ、SQLチューニング、
アプリケーションの改修を行うのが一般的だが・・・
・DBA以外AWRを見る機会が無い
⇒AWRを誰でも見られるようにしたい
・AWRを必要に応じて取得
⇒定期的に自動作成し、レポーティングしたい
88

パフォーマンス監視
• パフォーマンス監視をラクにしたい
• APやDBの性能が落ちたら、AWR（Automatic Workload
Repository）を取って改善箇所を見つけ、SQLチューニング、
アプリケーションの改修を行うのが一般的だが・・・
・DBA以外AWRを見る機会が無い
⇒AWRを誰でも見られるようにしたい
・AWRを必要に応じて取得
⇒定期的に自動作成し、レポーティングしたい
89
AWR Warehouseを構築

AWR Warehouse とは
90
• AWRはDBの稼動統計からレポートを生成する機能
• AWR Warehouse は複数DBの稼動統計を収集し管理

AWR Warehouse 導入
91
• Oracle DBの稼働状況の見える化の強化
• 全社Oracleのセルフサービス化推進
※サービス側自身でDBの問題点に気がつけるようにする
DB EM DB
AWRデータ
自動レポート
(定型グラフ等)
DB
AWRデータ
DB
AWRデータ
EMサーバ
アプリ
チームA
メール
サーバ
全社DBA
メール配信
(自動)
BI Publisher
kibana
アプリ
チームB
必要に応じて分析
セルフサービス
で自己参照

監視まとめ
• DBは監視レイヤーが多く、個別にツールを運用するの
も大変。EMは多機能とはいえUIが残念だったが、
13cでマシになった
• EMに監視を寄せてシンプルな運用にする
• パフォーマンス監視をラクにするため、
AWR Warehouseを現在構築中
92

本日の内容
3. 12cR2 MTA導入
4. HW構成
5. BCP
93
8. 監視
9. 全体まとめ

全体まとめ
94
12cR2 MTA
クリティカルな要件がまだ解消出来ず、本番稼
働は見送り。開発やステージングには積極的に
利用する。改善要望はOracleに出して行く
HW構成
Exadata価格がこなれてきたため、手組みの価
格優位性が今時点では無く、安定性や保守の面
からExadataを導入
BCP
DataguardでFSFOを組むことで、停止時間を極
小にできるが、コストが非常に掛かる上、中途
半端なBCPになりがち。何を守りたいのか、ど
こまでやるべきなのかを明確にしてBCP設計す
るのがオススメ
バックアップ
重複排除ストレージはバックアップ専用に設計
されているだけあって、時間、容量、ネット
ワーク負荷の問題を一挙に解決してくれる
セキュリティ・監査
セキュアなデータを扱う場合、監査がボトル
ネック要因となりやすいが、12c～の統合監査を
使う事で、数千qpsの監査ログが出てもなんとか
なる
監視
これまでEnterpriseManagerを活用出来ていな
かったが、EM13cからUIが改善され使いやすく
なった。これを機に、DB監視の全レイヤーを
EMで監視することにした。さらにパフォーマン
ス監視をラクにするためAWRWarehouseを構築
中

EOP
95

Yahoo! JAPANのOracle構成-2017年版

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a Yahoo! JAPANのOracle構成-2017年版

Similar a Yahoo! JAPANのOracle構成-2017年版 (20)

Yahoo! JAPANのOracle構成-2017年版

Notas del editor