標準的なGSLBパターンは次のように動作します。エンドポイントを監視し、異常になるとDNSレスポンスをバックアップに切り替え、正常になると元に戻します。主要なGSLBベンダーの実装は両方向の遷移を同一条件の反転として扱います。
本番環境の現実は対称ではありません。バックアップへのフェイルオーバーはプレッシャーの中で実行される防御的な動きであり、プライマリへの復帰は確信に基づく攻めの動きです。各方向で必要となる条件、待機時間、運用者の承認、発火すべきトリガーは異なります。
例: 素早く入って慎重に戻る — ユーザーを保護するために最初のエラー検出でフェイルオーバーし、フラッピングを避けるため復帰には15分間のクリーンな健全性を要求します。慎重に入って素早く戻る — フェイルオーバー前に3回連続の失敗を要求しますが、RPO/RTOコミットメントを満たすためプライマリ回復時にはすぐに戻します。自動で入って手動で戻る — フェイルオーバーは自動化されますが、復帰経路はランブックレビュー後のSRE承認を必要とします。
これらはいずれも一方向シナリオでは表現できません。運用者はどちらか一方の方向を選んで反対側のポリシーが誤ったまま運用するか、GSLBの真実の源から乖離しがちな脆弱なカスタムスクリプトを継ぎ合わせるしかありません。
TR7 GTMの双方向シナリオでは、アクティベーションと非アクティベーションがそれぞれ独立した条件、独立したゲーティングチェック、独立したトリガーアクションを持つことができます — インシデント対応ランブックがすでに前提としているポリシー構造です。
シナリオは2つの方向を持つ、名前付きで再利用可能なステートマシンです。各方向は組み合わせ条件式とトリガーセットによって定義され、2つの方向は互いの反転である必要はありません。
組み合わせ条件式が基礎となるヘルスチェックを評価します。trueを返すとシナリオが有効化されます。オプションのトリガーがアクション(HTTP/HTTPS Webhook、Oracleクエリ)を発火し、オプションのゲーティングチェックがトリガー実行の可否を確認します。
別の組み合わせ条件式が別のヘルスチェックセットを評価します。非アクティベーション経路はアクティベーションの反転にすることも、追加の安定性、追加のプローブ、まったく異なるトリガーを要求することも可能です。
条件は単一のブール値ではなく、グループ内でANDで結合し、グループ間でORで結合したヘルスチェック結果のグループであり、オプションで否定も可能です。ADC上のトラフィックルールロジックを駆動する同じDSLが、ここでもシナリオ評価を駆動します。
シナリオは一度定義され、DNSレコード、災害復旧構成、DC間フェイルオーバーポリシーから名前で参照されます。運用者は同じロジックを複数の場所で書き直す必要がありません。
双方向シナリオは、TR7 GTMのフェイルオーバーおよび復旧ポリシーの基礎です。
アクティベーション条件は、1つ以上のヘルスチェックプロファイルにわたるヘルスチェック結果から構築されます。グループはチェックをANDで結合し、複数のグループはORで結合します。各個別チェックは否定可能です。運用者はスクリプティングなしに「(APIがアップ AND データベースがアップ) OR (フェイルオーバー経路Aがアップ AND フェイルオーバー経路Bがアップ)」のような条件を表現できます。
非アクティベーション条件はアクティベーションから独立しています。アクティベーションが単に「プライマリがダウン」であったとしても、運用者は「プライマリが15分間健全であり、かつレイテンシが閾値以下」のような条件を表現できます。
アクティベーショントリガーと非アクティベーショントリガーは個別に選択可能なセットです。アクティベーションイベントではオンコールSREに通知し、非アクティベーションイベントではSREへの通知に加えて合成トランザクション実行とデプロイメントシステムへのWebhook発行を行う、といった構成が可能です。
オプションのゲーティング条件が、各方向のトリガー実行前に動作します。ゲーティングチェックがfalseを返した場合、状態遷移は発生しますがトリガーは発火しません。ユースケース: 状態は自動的に遷移するが、外部通知は営業時間内のみ発火する。
各方向は3つの運用者選択可能なモードをサポートします。autoは条件式に従います。onは条件にかかわらず方向を強制的に有効化します(手動オーバーライド)。offは方向を完全に無効化します(例: メンテナンス期間中のフェイルバック無効化)。
2つのデータセンターが定義されると、TR7 GTMはペアごとに4つのシナリオを自動生成します: from-active、to-active、from-backup、to-backup — それぞれWANアクセス、LANアクセス、インターネット到達性チェックに基づく適切な条件ロジックを持ちます。運用者は自動生成シナリオをそのまま使用するか、カスタマイズするか、ゼロから独自に作成できます。
DNSレコードの健全/異常状態は、静的なブール値や単一のヘルスチェックではなく、シナリオによって駆動されます。レコードごとの`cond`フィールドはシナリオ参照を受け付けます。シナリオが有効化されるとレコードはレスポンスから除外され、無効化されるとレコードは戻ります。
災害復旧レコードは`drCond`を指定できます — DRレコードセットがプライマリレコードセットをレスポンスで置き換えるタイミングを決定するシナリオです。DRシナリオ評価は双方向であり、制御されたフェイルオーバーと制御されたフェイルバックをサポートします。
トリガーはHTTP/HTTPS呼び出し(カスタムURI、メソッド、ヘッダー、ボディ、想定ステータスコード、コンテンツマッチクエリ)またはOracleデータベース呼び出し(設定されたSQL)として発火します。運用者はシナリオの有効化を既存のインシデント管理、デプロイメント、監査パイプラインに接続できます。
すべてのシナリオ状態変更が記録されます: どの方向が発火したか、どの条件がtrue/falseと評価されたか、どのトリガーが実行されたか、どのゲーティングチェックがパスしたか。インシデント事後レビューは、手動のログ調査なしに自動判断の正確な順序を再構築できます。
シナリオはヘルスチェック定義、トリガー設定、DNSレコードバインディング、災害復旧構成と共に運用されます。
条件グループ内では、リストされたすべてのチェックがtrueと評価される必要があります(AND)。グループ間では、1つのグループがtrueと評価されれば十分です(OR)。チェックIDの`!`接尾辞は否定を意味します。グルーピング構造はアクティベーションと非アクティベーションで対称的であり、各方向は独自のグループセットを持ちます。
条件はIDによってヘルスチェックを参照します。ユーザー定義のヘルスチェックプロファイルと自動生成のDCペアチェックは同じID空間を共有します。運用者は手動チェックと自動チェックを同じ条件グループ内で混在させます。
アクティベーションがonに強制された場合(手動オーバーライド)、非アクティベーション評価は通常継続されます — 運用者は手動でアクティベートし、その後に非アクティベーション条件が復元タイミングを判断します。両方向をonに強制するとスタック状態が発生し、設定警告として記録されます。
トリガーは、シナリオID、方向、評価タイムスタンプ、およびトリガー時の構成スナップショットを保持する構造化ペイロードと共に発火します。トリガー失敗(HTTP非2xx、Oracleエラー)はログに記録され、トリガープロファイルごとにオプションで再試行されます。
シナリオはポーリングタイマーではなく、ヘルスチェック状態の変化ごとに評価されます。アクティベーションまたは非アクティベーション閾値を超える最初の状態変化が遷移をトリガーします。条件は事前計算済みのヘルス状態を参照するため、評価コストは低く抑えられます。
運用者は、すべてのシナリオの現在の状態(有効/無効)、最後の遷移時刻、各条件グループの最後の評価結果、トリガー結果を確認できます。ダッシュボードはスタックした遷移や競合するオーバーライドを表示します。
ユーザーを保護するため最初のエラー検出でフェイルオーバーを有効化します。フラッピングを避けるためプライマリの健全性が15分間続いた後にのみ非アクティベートします。異なる条件、異なるタイミング — 同じシナリオオブジェクト。
フェイルオーバーは自動化されており、復帰経路はSREの承認を必要とします。非アクティベーション方向はoffに設定され、ランブックレビュー後に運用者が手動でonに切り替えます。アクティベーションは自動評価を継続します。
DC A → DC BフェイルオーバーはインシデントマネジメントシステムへのHTTP Webhookをトリガーします。DC B → DC Aフェイルバックは同じWebhookに加え、キャッシュをウォームアップするためのデプロイメントシステム呼び出しをトリガーします。各方向のトリガーは独立しています。
Oracleトリガーを使用してフェイルオーバー前にデータベースをクエリします — 例えば、ログシッピング経由でバックアップデータベースが追いついていることを確認します。トリガー結果が実際の状態遷移をゲートします。
ご自身のランブックに基づく双方向シナリオを体験してください: 素早く入って慎重に戻る、手動フェイルバック、非対称トリガーセット — プラットフォームのデフォルトではなく、お客様のポリシー。