楽天のSplunk as a service

5,054 views

Published on

splunklive 2014 Tokyo/Osaka での発表資料です。
楽天で展開しているSplunkの共通基盤である、Splunk as a Serviceのご紹介をします。
設計、構築時に考慮した点やSplunk APIを利用した運用改善、また、社内での活用事例についてもお話します。

Published in: Technology
0 Comments
20 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
5,054
On SlideShare
0
From Embeds
0
Number of Embeds
224
Actions
Shares
0
Downloads
99
Comments
0
Likes
20
Embeds 0
No embeds

No notes for slide

楽天のSplunk as a service

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

×