直近30日の成功率が高くても、最後のチェックが古ければ、今の状態は判断できません。HTTP 200が返っていても、期待した画面が返っているかは別の確認です。
KamuiDashでは、定期的な動作確認の結果をSLI（サービスの状態を表す指標）としてステータスページで公開しています。個人プランではSLAを定めていませんが、観測した実績と、その計測条件を確認できるようにしています。
この記事では、成功と数える条件、欠測の扱い、古い結果を「正常」と表示し続けないための設計を紹介します。
最初に、何を測った数字なのか
アプリの実績として公開しているのは、1台構成の参考アプリと、2台構成のダッシュボードのサインイン画面を観測した結果です。利用者のすべてのアプリやリクエストを集計した成功率ではありません。
ほかの機能も、監視用に決めた操作で確認しています。サーバーが起動していてもファイルを保存できなければ、ストレージを使える状態とはいえないためです。
| 対象 | 確認していること |
|---|---|
| アプリの公開画面 | HTTP応答と、期待する内容が返ること |
| ストレージ | ファイルの保存・取得・削除 |
| データベース | 接続・データの保存・取得・削除 |
| ダッシュボードAPI | プロジェクト情報の取得 |
こうした定期的な動作確認は合成監視と呼ばれます。アクセスが少ない時間帯にも、決めた条件でサービスの動作を確かめられます。
アプリの公開画面には1分ごとにアクセスし、10秒以内のHTTP 200と、期待する本文を成功の条件にしています。ステータスコードだけでは、想定と違う画面が返っていることを見落とす可能性があるためです。
キャッシュされたページが返るだけでは、その時点でアプリが応答できるかを確かめられません。監視リクエストにはキャッシュを避ける指定を付け、応答ヘッダーからキャッシュ済みと判定できた結果は、有効な計測から除外しています。
サインイン画面の確認にログイン操作は含まれません。また、1台構成と2台構成は異なるアプリを観測しているため、台数だけの効果を比較した実験ではありません。
同じ99.0%でも、計測できた範囲は違う
成功率は、有効なチェックのうち成功した割合です。
÷ 有効なチェック数 × 100
ここでは失敗と欠測を分けています。応答異常やタイムアウトを観測した場合は失敗です。一方、監視処理が動かなかった場合やキャッシュ応答を除外した場合など、判断に使える結果がなければ欠測です。
次の2つは、どちらも1,000回のチェックを予定した説明用の例です。例Aでは全回の結果があり、例Bでは100回の欠測があります。
| チェックの内訳 | 例A | 例B |
|---|---|---|
| 予定した回数 | 1,000回 | 1,000回 |
| 成功 | 990回 | 891回 |
| 失敗 | 10回 | 9回 |
| 欠測 | 0回 | 100回 |
| 有効な回数 | 1,000回 | 900回 |
| 成功率（SLI） | 99.0% | 99.0% |
欠測は分母にも分子にも含めないため、成功率は990 ÷ 1,000も、891 ÷ 900も99.0%です。ただし例Bでは、残り100回の状態は分かりません。そのため、日別の詳細では有効なチェック数と予定していたチェック数も確認できるようにしています。結果がない期間を、正常として埋めることはしていません。
複数の操作があるサービスでは、操作ごとの成功率のうち最も低い値を代表値にします。保存が99%、取得と削除が100%なら、表示は99%です。取得の成功回数が多いことで、保存の問題が平均に埋もれるのを避けています。
用語の補足：SLIは観測した実績、SLOは運用上の目標です。ステータスページに表示する実測値や目標値は、サービス品質保証であるSLAを示すものではありません。
「現在の正常」には、有効期限がある
過去の成功率と、現在使えるかどうかは別の情報です。最後に確認できた時刻が古ければ、過去の正常結果だけで現在の状態を判断できません。
アプリのHTTP監視では、最後の計測結果が3分より古くなると、現在の状態を「不明」にします。
取得できたか
3分以内か
表示用データの取得に失敗した場合にも、以前の正常表示を維持しません。「不明」は障害が起きたという断定ではなく、現在の状態を判断する材料が足りないことを表します。
この場合も、過去の成功率や最後に確認できた時刻は履歴として残します。現在状態と過去の実績を分けることで、確認できていることをそのまま表示します。
計測結果と障害報告を、別の役割で届ける
自動チェックで分かるのは、決めた条件で動作を確認できたかどうかです。原因や影響範囲、対応状況は運用者が記録し、数値と同じページで伝えます。
ページ数字と状況説明を確認
アプリ側に問題が起きたときにも状況を確認する場所を残すため、公開ページの配信はアプリの実行基盤と分けています。公開画面へのHTTPチェックに加え、DBではサービス側で操作を実行し、その結果を監視側へ送ります。
構成図の上段は、横にスクロールして確認できます。
HTTPチェック応答と内容を確認
成功率・日別履歴
ダッシュボードAPI機能ごとの動作を確認
接続・保存・取得・削除
計測は閲覧とは独立して定期実行します。アプリのHTTP監視では「監視対象と1分単位の計測枠」で記録を一意にし、処理が再実行されても二重に数えないようにしています。
ステータスページで確認してほしいこと
KamuiDashのステータスページでは、次の3つをあわせて確認できます。
- 成功率と対象期間
アプリは直近30日、その他のサービスは本日を含む30暦日の実績です。サービスに複数の操作がある場合は、そのうち最も低い成功率を表示します。
- 現在の状態と最終確認時刻
過去の成功率とは別に、どの時点の結果で現在状態を判断しているかを確認できます。
- 日別の履歴と障害報告
日別の詳細で有効回数と予定回数を確認できます。障害・メンテナンスの報告がある場合は、影響や対応の経過も参照してください。
1分間隔の観測では、チェックの間に起きた短い停止を見逃す場合があります。成功率は定期チェックの実績であり、実際の停止秒数を正確に示す値ではありません。
成功率だけでなく、何を測り、いつまで確認できているか。その条件を含めて、KamuiDashの稼働状況を確認できるページにしています。