Monitor-as-Codeの手引き：Splunk Observability CloudをTerraformで使用する方法

現代の複雑なクラウドネイティブインフラを管理するために、オブザーバビリティ(可観測性)のニーズが高まっています。クラウドの導入は進み続けており、優れたカスタマーエクスペリエンスの提供や、効率的なスケーリング、イノベーション促進に対するニーズも、かつてないほど重要性を増しています。多くの組織がこれらの理想を実現しようとしていますが、その目的を迅速に達成するために役立つテクノロジーが2つあります。それがMonitoring-as-CodeとInfrastructure-as-Codeです。 

このブログ記事では、Monitoring-as-CodeとInfrastructure-as-Codeを組み合わせて活用する方法と、これらのテクノロジーがCI/CDの開発パイプラインにもたらす効率性について説明します。また、SplunkのTerraformプロバイダーの簡単なセットアップ手順も紹介します。これだけで、監視とオブザーバビリティをアプリケーションコードに含めることができます。

Infrastructure-as-Codeとは？ 

従来、ITインフラの導入は大仕事で、複数のチームが関与し、手動でプロビジョニングを行っていました。この時間のかかる複雑なプロセスで何か間違いが起きると、アプリケーション導入が失敗したり、パフォーマンスの問題が起きるなどして、カスタマーエクスペリエンスに影響を及ぼすこともあります。手動のプロビジョニングが抱える多くの問題への対策として誕生したのがInfrastructure-as-Codeです。その結果、大規模なシステムは設定ファイル内でコードとして宣言されるようになりました。Infrastructure-as-Codeのシステムでは、ユーザーはインフラ構成の最終的な理想の姿を指定します。あとはツールにバックエンドの作業を任せておけば、望みどおりの状態のインフラができあがります。Infrastructure-as-Codeプラットフォームの代表格は、HashiCorp社のTerraformです。変更が必要になったときは、Terraformの設定を簡単に編集するだけで、現在実行中のインフラに速やかに反映されます。

Monitoring-as-Codeはどこで使うのか？ 

インフラとアプリケーションの監視をセットアップする際には、インフラの手動プロビジョニングと共通する多くの課題が発生します。これらの課題に直面するのは一般的にインフラの初期導入後で、監視の導入が複雑化するにつれて顕著になります。Monitoring-as-Codeを使用すると、アプリケーションや開発のワークフローに近い方法で監視を設定できるようになります。同じワークフローとも言っていいでしょう。コードのデプロイの一部として、CI/CDシステムによりバージョン管理システムへのチェックインと変更を行います。クラウドとオンプレミスのいずれでも、インフラ環境を問わずアプリケーションを適切に観測するために必要な監視アセットをもらさず設定できます。

一方で、Monitoring-as-Codeを使用する場合と、監視ツールやオブザーバビリティツールを単独で使用する場合の違いを認識しておくことも重要です。Splunk Observability Cloudなどのオブザーバビリティツールは、インフラ、アプリケーション、ユーザーに対する完全忠実な監視とトラブルシューティングをリアルタイムで提供します。しかし、ビジネスロジックを決定する処理や、ビジネスメトリクスにとって重要なディテクターを特定する処理を自動化できません。Monitoring-as-Codeでは、データをアプリケーションから収集し、それを使用して問題を解決するまでのアプローチ全体を管理できます。その例を見てみましょう。

Monitoring-as-Codeの実装手順

HashiCorp Terraformは、インフラの構築、変更、バージョン管理を安全かつ効率的に行うためのツールです。Terraformはプロバイダーによって拡張できます。その1つがSplunkのTerraformプロバイダーであり、Splunk Observability Cloudのサポート対象リソースと連携して設定を作成できます。この設定は、HCL(Hashicorp Configuration Language)で記述したインフラ設定に含めることもできますし、APIトークンで認証する独立したTerraformデプロイメントにすることもできます。

今回の例では、Kubernetesを使用したマイクロサービスベースのアプリケーションがすでにデプロイされているものとします。このアプリケーションは4つのマイクロサービスを使用して構築されています。4つのうちいずれかがダウンするという重大な状況でアラートが通知されるよう、Terraformを使用してディテクターをデプロイします。 

はじめに、Splunk Observability Cloudで認証するためのAPI認証トークンが必要です。アカウント設定に移動し、[Access Tokens](アクセストークン)をクリックします。

[New Token](新規トークン)をクリックし、アクセストークンの名前を入力し、権限として[API Token](APIトークン)を選択します。
 

APIトークンが作成できたら、[Show Token](トークンを表示)リンクをクリックしてトークンを確認し、Terraformの使用時にコードの一部としてこれを使用します。
 

APIトークンを用意してTerraformをインストールしたら、Terraform CLIを使用して以下のコードをデプロイします。(注：SignalFxは、Splunk Observability Cloudのコンポーネントの旧称です。)
 

terraform {

 required_providers {

   signalfx = {

     source = "splunk-terraform/signalfx"

     version = "6.8.0"

   }

 }

}

provider "signalfx" {

  # シークレットの管理を行うVaultなどのTerraformプロバイダーの使用を強く推奨します。この例では、ここにトークンを記載しています。

  auth_token="API TOKEN HAS BEEN OMITTED"

  api_url = "https://api.us1.signalfx.com" # Splunk ObservabilityのカスタムレルムURLを使用してください。

}

resource "signalfx_detector" "movieappspods_notready" {

name        = "1つまたは複数のMovieマイクロサービスPodの準備ができていません"

description = "このアラートは、ムービーアプリケーションのマイクロサービスPodが準備未完了の状態だったときに通知されます。"

program_text = <<-EOF

      A = data('k8s.container.ready', filter=filter('metric_source', 'kubernetes') and filter('app', 'movies', 'actors', 'dashboard', 'directors'), rollup='count').count().publish(label='A')

      detect(when(A < threshold(${var.pod_amount}))).publish('Movies Application Microservices Pods') 

  EOF

rule {

  description   = "1つまたは複数のムービーアプリケーションのマイクロサービスPodの準備ができていません"

  severity      = "Critical"

  detect_label  = "Movies Application Microservices Pods"

  notifications = ["Email,you@example.com"]

}

}

コードを見ていくと、Splunk Observability Cloudでプロバイダーの認証を行うために必要なフィールド(auth_token、api_url)と、ディテクターを作成するために必要なリソース(signalfx_detector)を指定しているのがわかります。ディテクターは、program_textフィールドでSignalFlowを指定することにより宣言しています。正式なSignalFlowの構文については『Developer Guide for Splunk Observability Cloud』を参照するか、以下のようにSplunk Observability CloudのGUIで、既存のディテクターまたはグラフの[…]メニューから[Show SignalFlow](SignalFlowを表示)を選択してください。SignalFlowは、データの操作や集計などの処理のリアルタイム実行もサポートしています。そのため、Monitoring-as-Codeで実装した場合でも、GUIでセットアップしたディテクターと同様に、強力なリアルタイムのデータとアナリティクスを利用できます。
 

続いて、Terraformの実装が完了したら、Splunk Observability Cloud内でディテクターを表示します。すると、マイクロサービスの障害発生時にアラートを通知するディテクターができているのを確認できます。
 

まとめ

UIを使用すれば、新しい言語を習得することなく誰でも簡単にグラフやディテクターなどのオブザーバビリティリソースを作成できます。しかし、高度な組織では、監視の設定をアプリケーションコードとともに保存したいというニーズがあります。必要なデータをすべて単一の情報源(お使いのソースリポジトリ)に保存できれば、必須の監視機能をアプリケーションとともに簡単かつ確実に導入することができ、しかもそれを常に最新に保てます。 

加えて、Terraform CloudエージェントはOpenTelemetryフォーマットのデータ(メトリクスとトレース)を送信できるため、Splunk Observability Cloud内でパフォーマンス分析やトラブルシューティングを行うこともできます。もちろんTerraformを使用してOpenTelemetryコレクターをデプロイすることも可能で、これらすべてをひとまとめにして管理できます。 

SplunkでMonitoring-as-Codeを利用する

無料のトライアル版では、Infrastructure MonitoringからAPM、Real User Monitoring、Log Observerまで、スイートに含まれるすべての製品を試すことができます。Terraformについてはこちら、Splunk Terraformプロバイダーについてはこちらで詳細をご覧ください。今すぐMonitoring-as-Codeを使ってみましょう！

このブログはこちらの英語ブログの翻訳です。