Embed Size (px)
DESCRIPTION
splunklive 2014 Tokyo/Osaka での発表資料です。 楽天で展開しているSplunkの共通基盤である、Splunk as a Serviceのご紹介をします。 設計、構築時に考慮した点やSplunk APIを利用した運用改善、また、社内での活用事例についてもお話します。
Citation preview
楽天のSplunk as a Service
Vol.01 July/07/2014
Keisuke Noda / 野田 啓介
Data Store Platform Group, Rakuten, Inc.
http://www.rakuten.co.jp/
2
About Me
• Keisuke Noda
• 野田 啓介
• Company
• Rakuten, Inc.
• Data Store Platform
Group
• Background
• Application Engineer
• Database Engineer
• Like
• Massage
3
About Company
代表取締役会長兼社長 三木谷 浩史 従業員数 グループ 10,867人 （2013年12月） 設立日 1997年2月7日 IPO 2000年4月19日（ジャスダック） 資本金 109,530百万円（2013年12月末現在） 連結売上収益 5,186億円（2013年度） 連結営業利益 974億円（2013年度）
楽天市場（eコマース事業）を中核とした，
総合インターネットサービス企業
4
About Company
E-Commerce Portal and Media
Ｔｒａｖｅｌ
Telecommunications
Securities
Credit Card
Professional Sports
Banking
E-money
5
Go Global
6
Go Global
7
Agenda
• 楽天のSplunk as a Service
• サービス活用事例
8
楽天の Splunk as a Service
9
Rakuten Splunk as a Service
• はじめに
• 主に管理向けの技術的な内容を含みます
• 弊社で成功しているSplunk as a Serviceを通して
Splunkの旨い使い方をご紹介
10
Rakuten Splunk as a Service
• Why Splunk?
• Why as a Service?
• Service Overview
• Service Designs
• Service Operations
• Our Challenges
• Current Status
• What’s Next?
• Wrap up
11
Why Splunk?
• 見た目がクールでおもしろそうだったから
12
Why Splunk?
取り込みバッチ RDBMS Webアプリ
取得項目追加 改修 改修 カラム追加
• DB監視ログを表示するWebアプリ
• 運用が大変
13
Why Splunk?
Splunkのポテンシャルを体感し
様々な部署へ展開することに
• DB監視ログを表示するWebアプリ • 運用が大変
• Splunkにログを食わせたところ それぞれのサーバーが
不要に！！
14
Why as a Service?
様々な部署での利用が始まると
導入時のシステム構築、ライセンス管理やサーバー運用が各部署で発生
一つ大きなプラットフォームを作り
As a Service として全社に提供すれば解決できる
さらなる別の効果も期待
Splunk as a Service が誕生
15
Service Overview
• インフラ管理運用必要なし • サーバー構築運用
• ライセンス
• Splunkがすぐ使える 1. Splunk account作成
2. forwarderインストール
3. データの取り込み設定
• 料金は使った分だけ • サービス料（データインプット量）
• ストレージ料（データ保持サイズ）
• 高サービスレベル • SLA定義してそれ守ります
Rakuten
Splunk as a Service
詳細は後ほど！
16
Service Design
• 環境
• Private Cloud上に構築
• High Quality
• Low Cost
• Short Time Delivery
状況に合わせたスケールアップ
スケールアウトが容易
17
Service Design
• システム構成
• v6.0を利用
• Cluster
• コンポーネント
• Indexer
• Forwarder
• Deployment Server
• Cluster Master (Rep: 3, Search : 2)
• Search Head (Common/Private)
• HotdbとColddbでストレージを選択
18
Service Design
• セキュリティ
• 現在1ユーザー毎にSplunkアカウントを作成
（1ユーザー＝プロジェクト、グループ、サービス単位）
• ユーザーは自分の利用するサーバーから転送されたデータのみ利用可能
• データ保持期間
• 取り込み設定毎に1日～6年でユーザーが自由に選択可能
• その他
• 目標稼働率を定義
• その他詳細
19
Service Operation
• サービス運用 • アカウント作成
• ログ取り込み設定
• 詳細設定変更対応
• Appインストール
• ユーザーサポート
• 監視 • インプット量監視
• インプット量は有限
• システム監視
• SoS/Unix app
• Pandora FMS
20
Our Challenges
• ユーザーサイドでの取り込み設定を不要に
• データのアクセスコントロール運用を楽に
• 社内ツールとの連携
• API利用で運用改善
21
Challenge 1
• ユーザーサイドでの取り込み設定を不要に
• 課題
• すぐ使いたいけど、データの転送方法がわからないユーザー多数
• 対応
• クライアントフォワーダーにSplunk Universal Forwarderを標準で利用
• Deployment Server を利用
No Data Loss
No Need Setup
Universal Forwarderインストール後
ユーザーサイドでの設定、運用は必要なし
Syslog, fluentd 等もサポート （ユーザーが選択可能）
22
Challenge 2
あなたのネットワークのログ使って
私のsyslogと付け合せたいわ
• データへのアクセスコントロール運用を楽に
• 課題
• 取り込まれたデータをうまく共用したい
• 対応
• Tagを利用。基本的にはhost=<ユーザーの扱うホスト> にタグを設定
• ログを共用する場合には対象のデータのみWhitelist方式でTagに追加
Aさんのデータ
私のデータ 見せてあげる
ありがとう とても効率的だわ
Aさん Bさん tag=tagB tag=tagA
tag=tagA
+ tagB
Splunk
23
Challenge 3
• 社内ツールとの連携
• CMDBデータを自動取り込みし、サーバー情報や担当者情報等と連携可能
• 監視ツールとの連携でダイレクトコールの受信可能
• その他Splunk APIで検索結果を利用し、様々な用途で利用可能に
社内ツール
24
Challenge 4
• API利用で運用改善
• API使ってますか
• APIでいいこと
• 取得したデータを自由に加工できる
• スクリプト化して一括で処理できる（自動化できる）
• 新しいサービスが生まれる
• Splunk APIでできること
• サーチ結果取得、ユーザー作成、再起動
• … Splunk Webでできることは大体できる
25
Challenge 4
• API利用で運用改善
• アカウント作成
• Create app
• Create role
• Create user
• WebからGUIで作成するとクリック回数50回くらい
• API利用してスクリプトにまとめれば１回
定型運用がクリック1回で完了
26
Challenge 4
• ポータルサイト
• ユーザーサイド
• アカウント作成リクエスト
• ログの設定依頼
• 管理者サイド
• アカウント作成
• ログの設定
27
Trend of Number of Accounts
Mar-14 Apr-14 May-14 Jun-14
PROD
STG
DEV
アカウント数
28
Trend of Number of Forwarders
Mar-14 Apr-14 May-14 Jun-14
# ofForwarders
フォワーダー数
29
Trend of Input Size
Mar-14 Apr-14 May-14 Jun-14
InputSize
インプット量
30
What’s Next?
• ユーザー利用開始までをもっと簡単に
• 人の手を介さず全自動化
• 運用の効率化
• 頻度の高いオペレーションを自動化
• v6.1 アップグレード
• スクリプト、lookupcsv等のデータアップロード機能
• グループ会社とのコラボレーション
31
Wrap up - Splunk as a Service -
• 楽天はひとつの大きなSplunk Platformを利用している
• ユーザー視点でよかったこと
• インフラ管理必要なし
• すぐに利用でき、ログの取り込み設定なし
• 部署をまたいだデータの連携が可能
• 管理者視点でよかったこと
• 運用管理を集中させることで運用の効率化ができる
• ライセンスをうまく利用できる
• 効率よくノウハウを蓄積
• APIを利用して運用改善している
• CMDBや既存のツールと連携しユーザー満足度UP
32
サービス活用事例
33
Use Case
Application Real-time Monitor
Service KPI Management
Performance Management
Database
Real-time Monitor
Troubleshooting
Usage Report
Service KPI Management
Security
IDS Real-time Monitor
Illegal access Management
Storage
Real-time Monitor
Resource Management
Service KPI Management
Server
Real-time Monitor
Troubleshooting
Usage Report
Private Cloud (RIaaS) Real-time Monitor
Resource Management
More …
Network Real-time Monitor
Troubleshooting
Analyze trend
34
Use Case
Application Real-time Monitor
Service KPI Management
Performance Management
Database
Real-time Monitor
Troubleshooting
Usage Report
Service KPI Management
Security
IDS Real-time Monitor
Illegal access Management
Storage
Real-time Monitor
Resource Management
Service KPI Management
Server
Real-time Monitor
Troubleshooting
Usage Report
Private Cloud (RIaaS) Real-time Monitor
Resource Management
More …
Network Real-time Monitor
Troubleshooting
Analyze trend
35
Use Case 1
• Before
• アプライアンス製品を利用しているが最低限の監視しかついていない
Database
36
Use Case 1
Database
セッション数
CPU使用率
スロークエリログ
37
Use Case 1
Database
38
Use Case 1
• Before
• アプライアンス製品を利用しているが最低限の監視しかついていない
• After
• リアルタイムモニタリングができるようになった
• 致命的なエラーが出る前の、予備アラート検知ができるようになった
• サーバーにログインすることなく
• サーバー状況（スロークエリ、レスポンスタイム、負荷等）が一目で確認できるようになった
• ログの調査が可能になった
• 予め定めた稼働率やレスポンスタイム、スローログ数等のKPIを自動で追うことができるようになった
Database
39
Use Case 2
• Before
• 分析する気が起こらない
Network
40
Use Case 2
Network
41
Use Case 2
• Before
• 分析する気が起こらない
• After
• ACL/Flow logの可視化によりリアルタイムのトラフィック状況が一目瞭然
• ASのIncoming/Outgoingのトレンドが可視化
• 回線フィーのコントロールする上での判断材料に！
• Syslogの可視化が可能に
• VIPなどのリソースマネージメントができるようになった
Network
42
Use Case 3
• Before
• セキュリティインシデント対応は外部会社依存
• アタックの対応に時間がかかっていた
Security
43
Use Case 3
Security
44
Use Case 3
• Before
• セキュリティインシデント対応は外部会社依存
• アタックの対応に時間がかかっていた
• After
• IDSログ解析による内製化移行により大幅なコスト削減（現在移行準備中）
• CMDB取り込みによりインシデント検知から担当者への連絡が一気通貫に処理できるようになった
• アタックの対応が大幅（80%！）に短縮された
• 不正ログイン検知が手に取るようにわかるようになった
• 不正レビュー検知も取り組み中
Security
45
Use Case 4
Application
46
Use Case 4
• Before
• APMは導入しているができることが決まっており、調査に使いづらかったりサービス独自のログが解析できない等、かゆいところに手が届かない
• After
• 独自のログをリアルタイムで自由に解析可能になった
• エンドユーザーからよく見られているURIをレポート
• 外部連携している外注さんのログイン状況をレポート
Application
47
おわりに
48
Our Demands
• 目的別検索チュートリアルを充実させてほしい
• アラート時のAPIフック利用
• 各種設定ファイルの適用先をわかりやすく
• Source/Sourcetype/Host単位でのバックアップリストア
• ファイル編集時の反映を再起動不要に
• 全てのWeb機能をAPI提供
49
Wrap up - Good Point of Splunk -
• ログさえあれば、機器、ログのフォーマット問わず検索可能になる
• ユーザーの目的に合わせたサーチ、レポート、アラートが自由に作成可能
• 今まで無視していたログから新たな情報を取得できる
• KPI（稼働率等ユーザー独自の指標）を追うのに役立つ
• 調査時間が大幅短縮
• かゆいときに、かゆいところに手が届く
• ログ分析の楽しさを教えてくれる
柔軟性があり
サービスレベル向上し
コスト削減できる
50
Thank You!
Any Questions?
