第1章で触れたとおり、Splunkのコア製品にはオンプレミス版のSplunk Enterpriseと、SaaS版のSplunk Cloudがあります。 本章では、Splunk Cloudの特徴について、公式ドキュメントに明示されていることをベースに説明します。
本章は、サービス仕様やSLAなどに関する記載を含みます。 できる限り公開された仕様に基づいた説明をするよう心がけておりますが、記載に関する正当性や保証などはしておりませんので、確実な情報はSplunk公式サイトをご覧いただくか、Splunk社に直接お問い合わせください。
1. Splunk Cloudの特徴
Splunk Cloudは、SplunkをSaaS(Software as a Service)として提供するサービスです。 このため、Splunkを利用するために必要な設備やサーバー、Search HeadやIndexerのインストールや初期設定などの構築作業や、メンテナンスやバージョンアップなどの運用作業はSplunkが実施します。 内部のサーバー数、種類、リソースのサイジングなどもSplunkが決定します。
Splunkユーザーは、利用者自身がログデータを収集し、サーチして調査・分析を行うことに専念できるのが特徴です。
気を付けなければならないことは、ログデータを収集し、転送するためのForwarderの導入や運用、通信経路の確保などはSplunkユーザー側で行う必要がある点です。
以下に、Splunk Enterpriseを使う場合と、Splunk Cloudを使う場合で、誰がどのサーバーを管理するのかまとめました。 言い換えると、Splunk Cloudであれば、Splunkを構成するサーバーはSplunkが管理してくれるが、Splunkにデータを転送するForwarderおよびForwarderに設定を配布するAgent Managementサーバーはユーザーで管理する必要があるということになります。
| サーバー | Splunk Cloudの場合 | Splunk Enterpriseの場合 |
|---|---|---|
| Search Head | -:Splunk管理 | 〇:ユーザー管理 |
| Indexer | -:Splunk管理 | 〇:ユーザー管理 |
| Forwarder | 〇:ユーザー管理 | 〇:ユーザー管理 |
| Monitoring Console/Cloud Monitoring Console | -:Splunk管理 | 〇:ユーザー管理 |
| License Manager | -:Splunk管理 | 〇:ユーザー管理 |
| Search Head Cluster Deployer | -:Splunk管理 | 〇:ユーザー管理 |
| Indexer Cluster Manager | -:Splunk管理 | 〇:ユーザー管理 |
| Agent Management | 〇:ユーザー管理 | 〇:ユーザー管理 |
2. Splunk Cloudが内部で利用しているクラウドベンダー
Splunk Cloudは、その基盤として大手クラウドベンダーのインフラを利用していることを公言しています。 具体的には、AWS(Amazon Web Services)、Azure(Microsoft Azure)、GCP(Google Cloud Platform)の3つのクラウドベンダー上でSplunk Cloudは稼働しており、ユーザーはクラウドベンダーを選択することが可能です。 クラウドベンダーによって、利用可能なリージョンや若干の機能差があるようなので、契約時にクラウドベンダーを選択する際は気を付けたほうがいいかもしれません。 (一見したところでは、AWSが最も利用可能なリージョンが多く、利用可能な機能も最も多いようです)
3. Splunk CloudのSLA(Service Level Agreement)
SaaSを利用する上で、気になるのがSLAです。 Splunk Cloudでは、SLAは100%と宣言されています。
Splunk Cloudサービス サービスレベルスケジュール
https://www.splunk.com/ja_jp/legal/splunk-cloud-service-level-schedule.html
ただしこれは、100%の可用性を保証しているというよりは、100%の可用性を下回った場合はクレジット返金にて対応しますという会社の姿勢を表していると考えたほうがよいでしょう。 一切のインシデントや障害が発生しないことを想定しているわけではないと思われます。また、メンテナンス時間は対象外のようです。
加えて、上記のリンクに記載されていますが、「サービスが利用可能である」という条件の定義についてもよく確認しておく必要があると思われます。
4. Splunk Cloudのメンテナンススケジュール
Splunk Cloudでは、メンテナンスやバージョンアップはSplunk側で実施されます。 この際気になるのが、メンテナンス通知期間や頻度です。 こちらも、Splunk側で公開されている仕様があります。 (以下は更新される可能性があり、最新の記載はリンク先を直接確認するようにしてください)
Splunk Cloud Platformメンテナンスポリシー
https://www.splunk.com/ja_jp/legal/splunk-cloud-platform-maintenance-policy.html
執筆時点で上記のメンテナンスポリシーを引用すると以下となっています。 セキュリティや緊急度の高いメンテナンスの実施については制御不能だが、サービスアップデートであればある程度は交渉の余地があるようです。
| メンテナンスの種類 | 事前通知期間 | チェンジフリーズ(メンテナンス停止)の要望可否 |
|---|---|---|
| サービスアップデートメンテナンス | 14日前までに通知 | 可(最大3ヶ月間。また要望が常に確約されるとは限らない) |
| セキュリティ&プラットフォームメンテナンス | 7日前までに通知 | 不可 |
| 緊急メンテナンス | 商業的に合理的な範囲で通知 | 不可 |
| ゼロダウンタイムメンテナンス | 事前通知なし | 不可 |
5. まとめ
- Splunk Cloudは、SplunkをSaaS(Software as a Service)として提供する
- ログデータを収集し、転送するためのForwarderの導入や運用、通信経路の確保などはSplunkユーザー側で行う必要がある
- Splunk Cloudは、AWS、Azure、GCPなどのクラウドベンダー上で稼働している
- Splunk CloudのSLAは100%
- Splunk Cloudのメンテナンスポリシーも明文化されている