楽天のSplunk as a service

楽天の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?