Syntheticsを活用して計画的なダウンタイムを適切に管理する方法

ブラウザ外形テストがもたらすのは確かさであるべきで、不確かさではありません。このシリーズをお読みいただいている方なら、本当に価値のあるテストをすでに実践していることでしょう。それらのテストでは実際のユーザー体験が反映され、結果が検証され、意味のあるアラートが発せられているはずです。

しかし、最高の外形テストでも、計画的な変更の際にノイズを発生させることがあります。

リリースの展開や定期メンテナンスの実施のたびに、外形テストによって、変更に伴う影響がすべて記録され始めます。キャッシュが温まるまでの間、ページの読み込みが遅くなるかもしれません。依存先が再起動することもあるでしょう。処理のフローが、その基盤となるインフラの切り替えに伴い、数分間不安定になることもあります。

しかし、これらは障害ではなく、単なる変更作業の影響に過ぎません。問題なのは、その過程で生じるノイズです。

そこで重要なのが、計画的なダウンタイムの管理です。リリースをマーキングし、想定される失敗を抑制し、メンテナンス期間を明確なビジネスコンテキストとともに明示しましょう。そうすることで、大きな環境変更の際にも、外形テストの品質を保ち、シグナルを有用に保つことができます。

この記事では、 「合成コンピューティングを正しく活用する」シリーズの次のベストプラクティスである「計画的なダウンタイムを正しく管理する方法」について解説します。このシリーズを初めてご覧になる方は、まず導入記事をご覧ください。これらのベストプラクティスがどのように組み合わさって、信頼性が高く実用的な合成ブラウザテストを実現するのかを学ぶことができます。

概要：外形テストのための計画的なダウンタイムの管理

計画的なダウンタイムの管理とは、予定されている変更に備えてブラウザ外形テストを事前に調整する手法です。これにより、テストで判断を誤らせるような失敗やパフォーマンスデータの歪みが生じるのを防ぎます。この手法では、オブザーバビリティプラットフォームに対し、次のように指示します。「これから通常とは異なる状況が発生します。結果の解釈はその文脈を踏まえて行うこと」。

Splunk Observability Cloudでは、ダウンタイム構成により以下のことが可能になります。

• 既知のメンテナンス中にテストを一時停止する
• または、テストを継続して実行し、結果を「メンテナンス中」としてタグ付けする

これにより、計画的な運用作業の前後や実施中においても、外形テストのシグナルを明確に保つことができます。たとえば、管理下でのデプロイ、アップグレード、パス変更といった作業です。

重要である理由

計画的なダウンタイムが重要な理由は、変更作業中にはノイズが生じやすく、ノイズによって本当に対応すべき問題が見えなくなってしまうためです(または、見えても確信が持てなくなります)。

リリース時やメンテナンス時には、合成テストはページの読み込み速度の低下、フローの不整合、一時的な障害などを検出することで、正しく動作します。問題は、これらの信号がメンテナンス期間中に発生することが予想される点です。それらを実際のインシデントのように扱うと、誤ったアラート、汚染されたダッシュボード、誤解を招くパフォーマンス傾向といった結果を招くことになる。

主なリスクを挙げてみましょう。

1. 計画工事中は嵐にご注意ください。導入作業では、しばしば短時間で予期される障害が発生する。ダウンタイムがなければ、あらゆる障害がアラートを発報する機会となる。
2. 歪んだベースライン。ウォームアップ時の動作や一時的な遅延の変化は、パフォーマンスや稼働時間の指標を歪める。
3. 変更が発生した時期の記録はありません。メンテナンス期間を明示しないと、不具合や改善点を実際の事象と関連付けることができません。文脈が非常に重要であることを忘れないでください。

計画的なダウンタイムでは、こうした問題を解決するために、想定される変更を明示し、不要なシグナルを抑制して、外形テストのデータの品質を保ちます。目標は、メンテナンス期間外に外形テストでアラートが発生した場合、それに何らかの意味があると確信できるようになることです。

実践：計画的なダウンタイムの管理方法

Splunk Observability Cloudで計画的なダウンタイムを効果的に管理する方法をご説明します。これにより、外形テストのデータの品質と精度を保ち、実際の運用上の変更との整合性を確保できます。

1. 適切なダウンタイムルールを選択する

Splunk Synthetic Monitoringでは、2種類のダウンタイムルールをサポートしています。それぞれメンテナンス中の外形テストのデータを収集したり解釈したりする方法が異なります。下の表に、ダウンタイムのオプションと使用例をまとめました。

ダウンタイムオプション

重要ポイント：メンテナンス中のデータを活用してインサイトを獲得

under_maintenance=true回の実行はSLAやSLOの対象外ですが、変更時の貴重な挙動を明らかにすることができます。

ダウンタイムの設定についてはこちらをご覧ください。

重要ポイント：メンテナンス状況をダッシュボードで視覚化して追跡

Splunkでは、ダウンタイムが外形テストのグラフ上に直接表示されるため、メンテナンスの実施時期や、実施に伴うパフォーマンスの変化をすばやく識別できます。

視覚的なインジケーターには以下が含まれます。

• ダウンタイムの開始と終了を示すマーカー
• テストの一時停止を示すグラフ上の空白
• 拡張データに対してunder_maintenance=trueとラベル付けされた実行

たとえば、以下のスクリーンショットをご覧ください。

ダウンタイムの記録は13か月間保持され、過去の正確な状況の確認に利用できます。

2. 合成ダウンタイムの設定

Splunk Observability Cloudで外形テスト向けにダウンタイムを設定する方法は2つあります。次のいずれかから選択します。

• UIで直接ダウンタイムの期間を設定する
• Observability Cloud APIを利用して自動で設定する

いずれのアプローチもテストデータの品質を保つために役立ちます。どちらを選ぶかは、チームの運営方法によります。

2.1 UIでダウンタイムを設定する

Splunk UIの利用が適しているのは、運用上必要なメンテナンス期間や定期リリース、そして明快な視覚化を自動化せずに実現したい場合です。以前はダウンタイム期間の設定が変更管理プロセスの一環として行われ、変更承認後に変更タスクとの関連付けを通じて実施されていました。

以下はUIでの設定が適しているケースです。

• 予測可能な、または計画されたメンテナンス
• 運用チームが主導するリリース
• CI/CDとの統合がないシンプルなワークフロー
• 目視で確認する必要がある場合

UIでできるダウンタイム関連のアクション

UIベースの管理はシンプルかつ予測可能で、チームを横断した運用も容易です。

2.2 APIを使用し、ダウンタイムをコードとして設定する

ダウンタイムは、ObservabilityクラウドAPIを通じてプログラム的に作成および管理することもできます。これは、デプロイメントワークフローを自動化するチームや、ダウンタイムをリリースパイプラインや変更管理ツールで直接制御したいチームにとって最適な選択肢です。

以下はAPIでの設定が適しているケースです。

• ダウンタイムの自動作成が必要なリリースパイプライン
• ブルー/グリーンデプロイまたはカナリアデプロイ
• 自動化された変更管理システム
• 高速または頻繁なデプロイサイクル
• ダウンタイムを動的に調整する必要がある場合

詳細はこちら： API を活用して合成ダウンタイム構成を管理する。

例：APIを使用したダウンタイム期間の作成

curl -X POST "https://api.us1.signalfx.com/v2/synthetics/downtime_configurations" 

  -H "Content-Type: application/json" 

  -H "X-SF-TOKEN: $TOKEN" 

  -d '{

        "downtimeConfiguration": {

          "name": "release-maintenance",

          "rule": "augment_data",

          "testIds": [12345],

          "startTime": "2025-05-01T02:00:00Z",

          "endTime": "2025-05-01T03:00:00Z",

          "timezone": "America/New_York"

        }

      }'

APIでダウンタイムを管理することで、オブザーバビリティにアプリケーションのデプロイや運用の状況が正しく反映されます。

3. メンテナンスの前後にバッファを追加する

メンテナンス期間の前後にはバッファ時間が必要です。デプロイ後にはシステムのウォームアップ、依存関係の初期化、キャッシュの再構築、トラフィックの安定化が行われるためです。

バッファ時間の役割には以下があります。

• 一時的なエラーがインシデントとして認識されるのを防ぐ
• システムのウォームアップ中の一時的な挙動を、SLAやベースライン指標の対象から除外する
• 合成監視を、デプロイメントの実際のライフサイクルに合わせる。

PythonでのAPI呼び出しの例

import requests
from datetime import datetime, timedelta

TOKEN = ""
REALM = "us1"
TEST_IDS = [12345]

start = datetime(2025, 5, 1, 2, 0)
end   = datetime(2025, 5, 1, 3, 0)
buffer = timedelta(minutes=15)

downtime_start = start - buffer
downtime_end   = end + buffer

payload = {
    "downtimeConfiguration": {
        "name": "release-maintenance",
        "rule": "augment_data",
        "testIds": TEST_IDS,
        "startTime": downtime_start.isoformat() + "Z",
        "endTime": downtime_end.isoformat() + "Z",
        "timezone": "America/New_York"
    }
}

resp = requests.post(
    url=f"https://api.{REALM}.signalfx.com/v2/synthetics/downtime_configurations",
    json=payload,
    headers={"Content-Type": "application/json", "X-SF-TOKEN": TOKEN},
)

print(resp.status_code, resp.text))

4. メンテナンス後に検証のためのrunを実行する

メンテナンスが完了したら、重要性の高いテストを直ちに実行し、主要なワークフローが正常に動作していることを確認します。これには、次のいずれかの方法を用います。

• UI経由
• try_now APIエンドポイントをプログラム的に使用する

これにより、リリースが正常に完了したことを直ちに確認できます。

詳細：

• テスト設定の確認にUIでTry Nowを利用する方法
• API経由でTry Nowを利用するためのAPI仕様

結論

計画的なダウンタイムの目的は、アラートを止めることだけではありません。それは、管理下での変更の間も外形テストのデータの品質とシグナルの信頼性を保つことでもあります。外形監視は、的確なダウンタイムルール、十分なバッファ、APIによる自動化、メンテナンス後の検証を活用し、補強されたテストrunを適切に利用することで、オブザーバビリティプラクティスの安定性と信頼性を支える要素となります。

適切に管理されたダウンタイムは強みになります。たとえば、メンテナンス期間外に外形テストでアラートが発生した場合、それが本物のアラートであることを確信できます。リリース中にアラートが発生しなければ、設定が正しく機能しているとわかります。また、補強されたrunを通じてドリフトや脆弱性が明らかになれば、それを早期警告のサインと捉えて、ユーザーに影響が及ぶ前に対処できます。

次に取るべき行動

現在のダウンタイム設定を見直し、重要なテストに適切なルールが設定されていることを確認しましょう。次回のリリース前後にはバッファ時間を設け、ダウンタイムAPIを使ってプロセスを自動化し、メンテナンス完了後に主要なワークフローを検証してみてください。

チームが信頼できる合成テストの構築を続けるには、このシリーズの続きをご覧ください。Splunk Observability Cloudの無料トライアルを利用して、合成データ、RUM、APMがどのように連携してエンドツーエンドの完全な可視性を提供するのかを体験することもできます。