OCI Health Checks

解決する課題

外部監視サービスを自前で立てずに、ユーザーから見た到達性と応答性能をマネージドで継続監視できます。

• アプリやサイトが外部から本当に応答しているかを確認したい
• 1か所からだけでなく世界中の複数地点からの見え方を知りたい
• 障害を検知したらDNS で自動的に別エンドポイントへ振り替えたい
• 応答時間（レイテンシ）や TTFB を継続的に記録し、劣化の兆候を捉えたい

主要概念と用語

• モニター（Monitor）: 監視対象と条件を定義した継続的なチェック。設定した間隔で繰り返し実行される
• HTTP モニター: HTTP/HTTPS エンドポイントを対象に、ステータスコード・応答時間・TTFB などを評価
• ping モニター: ICMP（ping）または TCP でホストの到達性を確認する L3/L4 寄りの監視
• 観測点（Vantage Point）: Oracle が世界各地に持つ、監視を実行する地理的なロケーション。複数の地点・プロバイダから見ることで局所障害と全体障害を切り分ける
• オンデマンド プローブ（On-demand Probe）: 継続監視とは別に、その場で1回だけ実行する診断用のチェック（REST API 経由）
• プレミアム / ベーシック: テスト間隔が短い高頻度監視（プレミアム）と、間隔が長い通常監視（ベーシック）の区分
• Traffic Management 連動: DNS のステアリングポリシーとモニターを結び付け、異常検知時に応答を切り替えるフェイルオーバーを駆動

仕様・制限・クォータ

• 監視プロトコルは HTTP / HTTPS と ping（ICMP / TCP） に対応
• 観測点は世界各地に多数用意され、監視ごとに複数を選択できる。地域的に分散した複数プロバイダの観測点を選ぶのが推奨
• 実行モードは継続モニターとオンデマンド プローブの2系統。プローブは API から実行する単発診断
• テスト間隔は短い高頻度（プレミアム相当）から長めの通常（ベーシック相当）まで設定可能
• 監視対象エンドポイント数にはアカウント単位の上限があり、サービス制限から引き上げを申請できる。コンパートメント単位のクォータも設定可能

内部の仕組み

OCI Health Checks は、Oracle が世界各地に展開する観測点から監視対象へリクエストを送り、応答の有無・ステータスコード・応答時間などを評価します。1か所ではなく複数の観測点から並行して確認するため、特定地域だけの経路障害と、対象そのもののダウンを区別できます。

HTTP モニターは接続・名前解決・TLS ハンドシェイク・最初のバイト到達（TTFB）・全体の応答時間といったフェーズごとの所要時間を記録します。ping モニターは ICMP もしくは TCP で到達性とラウンドトリップを測定します。これらの結果は履歴として保持され、コンソールや API から参照できます。

監視結果は Traffic Management のステアリングポリシーに反映できます。フェイルオーバー ポリシーにモニターを結び付けておくと、プライマリの異常を検知した時点で DNS 応答が自動的にセカンダリへ切り替わり、ユーザーを健全なエンドポイントへ誘導します。

設計パターン / ベストプラクティス

• Traffic Management のフェイルオーバー ポリシー＋ Health Checks で、リージョン障害時に DNS を自動切替（DR の基本形）
• 監視先はロードバランサや CDN の公開エンドポイントなど、ユーザーが実際に到達する入口に向ける
• ヘルスチェック用の**軽量な専用パス（例: /healthz）**を用意し、依存サービスまで含めるか入口だけにするかを目的に応じて設計
• 複数観測点・複数プロバイダを選び、過半数の観測点が異常を示したときに障害とみなす運用で誤検知を抑制
• 切替を速くしたい FQDN は DNS の TTL を短くしておき、フェイルオーバーの反映遅延を抑える

運用・監視

• モニターのステータスと応答時間をコンソール／ API で確認し、地点ごとの見え方の差を把握
• OCI Monitoring のメトリクスや Alarms と組み合わせ、ダウン検知や応答時間の劣化を通知
• 単発の切り分けにはオンデマンド プローブを使い、設定変更前後の挙動を確認
• アラートが頻発する場合は、観測点の選定・判定の閾値・対象パスの依存範囲を見直して誤検知を減らす

コスト

課金軸は概ね「監視対象エンドポイント数」と「監視頻度（高頻度ほど高い）」に分かれます。重要なエンドポイントに監視を絞り、間隔を要件に合わせて調整するのがコスト最適化の基本です。

セキュリティ

• 監視先には公開して差し支えないヘルスチェック用パスを用意し、機微な情報を返さない
• IAM ポリシー＋コンパートメントでモニターの作成・変更権限を最小化する
• 観測点からのアクセスを許可する際は、セキュリティリスト / NSG の受信ルールを必要最小限に保つ
• 監視結果やステアリングへの反映は Audit ログで追跡し、設定変更の履歴を可視化する

関連サービス・比較

OCI Health Checks は **OCI DNS（Traffic Management）**と組み合わせて DNS フェイルオーバーを構成します。役割の近い AWS サービスとの対応は次のとおりです。

ハンズオン / CLI例

# HTTP モニターを作成（複数の観測点を指定して継続監視）
oci health-checks http-monitor create \
  --compartment-id ocid1.compartment.oc1..xxxx \
  --display-name web-http-monitor \
  --protocol HTTPS \
  --targets '["www.example.com"]' \
  --path /healthz \
  --port 443 \
  --interval-in-seconds 30 \
  --vantage-point-names '["aws-iad","goog-scl","azr-sjc"]'

# HTTP モニターの一覧を確認
oci health-checks http-monitor list \
  --compartment-id ocid1.compartment.oc1..xxxx

# ping モニターを作成（TCP で到達性を確認）
oci health-checks ping-monitor create \
  --compartment-id ocid1.compartment.oc1..xxxx \
  --display-name host-ping-monitor \
  --protocol TCP \
  --targets '["203.0.113.10"]' \
  --port 443 \
  --interval-in-seconds 30 \
  --vantage-point-names '["aws-iad","goog-scl"]'

# オンデマンド プローブをその場で実行（単発の切り分け診断）
oci health-checks http-probe create \
  --compartment-id ocid1.compartment.oc1..xxxx \
  --protocol HTTPS \
  --targets '["www.example.com"]' \
  --path /healthz \
  --port 443 \
  --vantage-point-names '["aws-iad"]'