オブザーバビリティのコストコントロール - 予期せぬ課金・請求に困らないように

オブザーバビリティソリューションと、コストコントロール

オブザーバビリティ（可観測性）という単語は、IT業界で広く知られるようになってきました。さまざまな企業やエンジニアの方々がオブザーバビリティに興味を持ち、実際に取り組んでみたという方も増えてきたように思われます。

昨今の潮流となっている急速なITシステムのクラウドシフトは、オブザーバビリティへの関心を高めるきっかけとなっています。クラウドサービスやクラウドネイティブなテクノロジーが提供する、オンデマンドでリソースを拡張・縮小できる弾力性やサービスを迅速に展開できる俊敏性は、企業がビジネスニーズに即応していく能力を高めることに寄与しています。一度クラウドサービスを活用したシステム開発やサービス提供を行ってみると、その手軽さや効率性の高さから、一挙にクラウドシフトが進んでいくようなケースも見受けられます。

一方、システムを安定的かつ信頼性の高い状態で運用していく上での困難も増えてきています。特に、コンテナベースのワークロードやマイクロサービス、サーバレスアーキテクチャでは、システムが動的に変化していくことが前提となっており、短命なインスタンスやワークロードも多数存在することになります。管理対象のワークロードが爆発的に増加することでシステムの監視やトラブルシューティングが長期化してしまうケースが増えていますし、予測不可能な事象の発生頻度も高くなっていきます。こうした課題を克服するために、オブザーバビリティソリューションに注目が集まっているわけです。

オブザーバビリティへの関心の高まりと呼応するように、オブザーバビリティにかかるコストに関する議論もまた話題になることがあります。コンテナベースのワークロードやサーバレス関数の急激な増加は、オブザーバビリティツールによるテレメトリーデータ収集量の増加を招きます。メトリクスのカーディナリティ（異なる種類のデータポイントの数）が爆発的に増加すると、自然とテレメトリーデータの保存や分析に関わるコンピュートリソースやストレージに影響が及び、これは商用のオブザーバビリティソリューションを利用する場合はライセンス費用に、OSSなどを活用し自社環境内にオブザーバビリティバックエンド（データの保存や分析を行う基盤）を持つ場合はリソース計画や拡張に関わる工数に影響します。

商用オブザーバビリティソリューションにおいては、ホスト台数やコンテナ数、あるいはメトリクス数やログ量などに基づいて利用料金が算出されることがありますが、クラウドネイティブなテクノロジーの採用、クラウドシフトの進展に伴い、予想だにしなかった課金が発生し、システム部門の予算超過を招くような事態が発生する懸念があります。いくらビジネスニーズに即応できるようなシステム環境を実現したとしても、これに伴ってコストが嵩み、利益を大幅に削ってしまうようでは本末転倒です。企業はオブザーバビリティソリューションの導入・活用に伴うコストを適切に管理する必要性に直面しています。

Splunkによるコストコントロールへのアプローチ

こういった課題に対して、Splunkがどのように向き合っているかをご紹介していきます。

Splunk Observability Cloudもまた、ライセンス体系の一つとしてホストやコンテナ台数、メトリクス数量に基づくライセンスを提供しています（「ホストベース」の課金モデルと呼びます）が、Splunkならではのポイントとしてコストコントロールに関する機能を提供している点を挙げることができます。

サブスクリプション使用状況の可視化と通知

コストコントロールをはじめるにあたって、まずは現状を把握できることが重要です。

Splunk Observability Cloudでは、利用開始直後から確認可能なダッシュボードで、ライセンス関連のメトリクス推移を確認いただくことができます。もちろん、サブスクリプション契約量と実際の利用状況をチェックしていただけますし、時系列での推移を追いかけるようなことも可能です。また、利用状況に関するより詳細なレポートを出力して、詳細にチェックを行うこともできます。

また、サブスクリプション契約量の上限に近づいた場合にアラートする設定もデフォルトで用意されています。デフォルトではサブスクリプション契約量の90%を使用した時点でアラートが発行されますが、これをカスタムしてご希望の閾値を設定したアラート定義を作成することも可能です。

サブスクリプション契約量を超過する前に気づくことができるような仕組みが整っていると言えるでしょう。

アクセストークン単位での利用上限設定

Splunk Observability Cloudへのテレメトリーデータ送信においては、必ずアクセストークンによる認証が前提となります。Splunk Observabilityでは、このアクセストークンに対してホスト数、コンテナ数、メトリクス数の上限を設定することができます。設定した上限を超えるホストやコンテナ、メトリクスは取得されません。そのため、例えば、意図せぬ操作によって誤ってコンテナを大量にデプロイしてしまった場合や、急激な負荷の上昇に伴うオートスケールによって大量のホストが生成されてしまったような場合でも、予期せぬコストが発生することを未然に防止することができるのです。

具体的に見てみましょう。Splunk Observability Cloud の Settings > Access Tokens の画面で、アクセストークンを管理することができます。

任意のアクセストークンの「…」（3点リーダー）には、”Manage Token Limit” というメニューが用意されています。これを開くと以下のような画面が表示されます。

画面中央の “Host Limit”, “Container Limit”, “Custom Metric Limit” に上限となる数量を設定することで、このアクセストークンを利用してデータ送信が可能なホスト数などを制限することができます。また、Alert Recipientsを指定すると、上限に抵触しそうになった場合にアラートを発生させることもできるようになります。

さて、例えば、あるアクセストークンに対してホスト数の上限を10に設定してみます。

Host Countの部分は「6/10」という表示になりました。上限が10台で、現状で6台のホストからのデータを取得しているということを意味します。一方で、Container CountやCustom Metricsは「0」という表示ですので、取得されているデータが存在せず、かつ、上限も設定されていないことを表しています。

さて、Splunk Observability Cloudにデータを送信するホストを増やしてみましょう。Splunk Observability CloudはOpenTelemetry Collectorによってテレメトリーデータ収集・加工・送信を行いますので、追加で数台のホストにエージェントを導入してみます。

導入を進めていくとHost Countの部分が「10/10」となり、Usage Statusも「Close to Limit」と表示されるようになりました。

こんな感じでアラートメールを受け取ることもできます（通知方法はメールだけでなく、チャットツールへの連絡やインシデント管理ツールへの連携などが可能です）

さらにもう1台エージェントを導入してみましょう。

エージェントの導入自体は問題なく実施できます。Access Tokensページでは、Usage Statusが「Above Limit」、Host Countも「11/10」となり、赤文字でアラート状態として表示されています。

導入対象のホストのInstance IDは「i-03f4*******」というものなのですが、InfrastructureのページにはこのIDは確認できません。このようにデータ取得は実施されていないことになります（※スクリーンショット上には今回のデモ用のインスタンス以外も含まれており、11台以上のインスタンスが表示されています）

もちろん、コンテナやカスタムメトリクスなどに関しても同様のアプローチが可能です。

このような形でオブザーバビリティのコストコントロールが実現できるようになっています。

アクセストークン管理のベストプラクティス

アクセストークンは複数作成することが可能で、アクセストークンごとに上限を設定できます。

そこで、どんなアクセストークンを用意し、どのように使い分けるかというのがポイントとなります。これに対する基本的な回答は「システム単位や組織単位でアクセストークンを分離する」というのが推奨です。

例えば、予算取得や課金対象となる部門単位でアクセストークンを分けておくと、各部門の持つ予算上限に抵触しないようにコストをコントロールすることができるようになるはずです。ある部門・組織において複数のシステムを管理しているような場合、あるいは組織を横断したプロジェクトにおいてSplunk Observability Cloudを利用する場合は、システム単位でアクセストークンを分けておいた方が、管理性やメンテナンス性、取り回しがよくなるかもしれません。

下の図はシンプルなアクセストークン管理のあり方を示していますが、皆様のチーム構成や社内ルールなどによってはより最適な形があるかもしれません。いずれにしても、アクセストークンに注目することで、オブザーバビリティの取り組みを管理していく必要があるという点を強調しておきたいと思います。

まとめ

オブザーバビリティソリューションは現代のクラウドネイティブ環境において不可欠であり、今後その活用はより進んでいくはずです。今はまだ顕在化していないかもしれませんが、活用が進めば進むほど「オブザーバビリティの取り組み自体をどのように管理していくか」というのが課題になっていきます。この時に今回ご紹介したような機能を活用していく必要が出てくるはずです。

コストというのは常に多くの方々にとっての関心事です。

もしかすると、例えば「ホスト台数・コンテナ台数などに基づく課金モデルを使うから、クラウドネイティブなアーキテクチャにおいて予算管理がしづらくなるのではないか」「利用ユーザー数に基づく課金モデルの方が管理がしやすくなるのではないか」といった意見や疑問も出てきたりするかもしれません（ちなみに、この指摘はある側面では正しいですが、大きな落とし穴が潜んでいます）。

今回のブログでは紹介していないような課金モデルやコストコントロール上の特長もありますので、まずはお気軽にSplunkまでお問い合わせいただければと思います。