Embed Size (px)
Citation preview
2016年11月25日
1
ヤフー株式会社 伊東 篤史
Kibanaによる
Oracleメトリクスの可視化
アジェンダ
2
• 自己紹介
• DB運用について
• 運用上の課題
• Kibanaによるメトリクス可視化
自己紹介
WHO AM I ?
名前：伊東 篤史
勤務先：ヤフー株式会社
経歴：新卒入社４年目
職種：DBA
業務：全社DB(Oracle/MySQL)の運用現在はOracleに注力
4
DB運用について
運用メンバー
Oracle• 主務： ７名• 業務委託: 3名
MySQL• 主務： ７名• 業務委託： ２名
6
X
サービスにDB環境を提供
7
全社Oracle 全社MySQL
インスタンス1 インスタンス2 インスタンス3
DB
サーバ１ サーバ２ サーバ３
Oracle Cluster
DB数： 約 230 DB
クラスタ数：約 40 クラスタサーバ数： 約 200 台
DB数： 約 640 DB
クラスタ数：約 30 クラスタサーバ数： 約 250 台
※数値はサービス提供している本番環境のみ
Oracle Cluster
マスター マスター マスター
スレーブ スレーブ
インスタンス
フェイルオーバー
レプリケーション
DBA業務
• DB構築• インフラ構築• サービス依頼対応（SQLチューニング等）• インシデント対応• DBリプレイス対応（11g➔12c）• ツール開発• キャパシティプランニング
8
運用上の課題
課題
1. DB数が多く、状況を確認しきれない
2. 独自ツールの改修が困難
10
DB数が多すぎる
11
直近３年で
Oracle 1.5倍MySQL 7.7倍の増加傾向
キャパシティプランニング
【Capacity Planning】情報システムを開発・改修する際に、機材の台数や処理性能、記憶容量、
回線容量などの計画を立てること。 [IT用語辞典]
チーム内でのキャパプラ実施方法• 各DB、サーバ、クラスタの状況確認
• DBに問題あり
→ DB担当者とサービス担当者で対応策を検討
• サーバ、クラスタに問題あり
→ リソース削減ができないか検討
→ 困難な場合は機材増設を検討
12
OEMでの確認は手間
13
DB横断で確認するには不向き
独自ツール
14
各DBのメトリクス情報をまとめてグラフで確認
ツール改修が困難
15
表示されるはずのグラフが出ない
• FE, BEとも改修が必要（運用コスト 高）
• ツール毎に改修できる人が偏る（属人化）
結果的に
• 定期的なキャパプラを実施しなくなった
• 弊害
16
①設備投資が遅れてサーバリソース不足
②DB障害による事故の増加
③再発防止策の増加
•DBの移設
•SQLチューニング
④人的リソース不足 負のスパイラル
課題に対する解決案
1. DB数が多く、状況を確認しきれない
2. 独自ツールの改修が困難
17
ターゲットを絞り込む（アドホック検索）➔
OSSの利用 & 作り込まない➔
Kibanaによる可視化
既存システム概要
独自ツールの構成
19
メトリクス管理DB（Oracle）
FE & BEサーバ
ツール用DB
（Oracle）
可視化
データ保存
データ収集（独自バッチ）
作り込み領域
ダッシュボード
Oracle Enterprise Manager (OEM)
新規システム概要
OSSを活用した構成
20
メトリクス管理DB（Oracle） データ保管・検索
サーバ
(Elasticsearch)
データ収集
（Embulk）
全てオープンソース
Oracle Enterprise Manager (OEM)
ダッシュボード(Kibana)
可視化
利用した要素技術
Embulk• バッチでデータ収集• I/Oプラグインが豊富
Elasticsearch• 全文検索エンジン• RESTfull API （データの保管＆検索）• クラスタ機能
Kibana• Elasticsearch内のデータを可視化• 手軽にグラフ作成＆アドホック検索
21
Embulk: http://www.embulk.org/docs/Elasticsearch, Kibana: https://www.elastic.co/jp/products
アドホック検索で絞り込み
22
CLUSTER_NAME: (cluster110.db.kks* cluster120.db.kks*) AND AVERAGE: >80
実用例
• レポート作成＆レビュー会（隔週で実施）
設備リソース確認結果
24
安全に使用可能な容量 90%以上
波形変動の大きいもの
対象 コメント 対応者 実施内容 ステータス
oradb6[1-3].db.bbt
DATAの安全に使用可能な領域が90%以上
Aさん DB1を年内に別環境へ移行
oradb2[1-3].db.ogk
DATAの安全に使用可能な領域が90%以上
Bさん DB2は不要なので削除
oradb1[1-3].hhdb.ssk
DATAの安全に使用可能な領域が90%間近
Cさん ストレージ１台増設
対応中
完了
対応中
まとめ
DB運用上の課題• DB数が多く、状況確認が困難• 独自ツールの改修が困難
• 開発コストが大きい
• ツール改修者の属人化
Kibanaを利用することで• 必要な情報のみをアドホックに検索 ➔ 運用コスト削減• オープンソース化 ➔ 属人化の軽減
25
エンジニア募集
弊社ではデータPFに興味・関心のある人材を随時募集してます
26
世界水準のデータPFを一緒に作りましょう！
ご清聴
ありがとうございました
