GTMアーキテクチャでは、ヘルスチェック状態の変化がDNS応答を変えることがあります — しかし運用はDNS応答だけにとどまることはほとんどありません。データセンターがオフラインになると、アラームシステム、チケッティングシステム、DR自動化、監査パイプライン、アプリケーションチーム全員が知る必要があります。その接続なしでは、GTMが判断を行う一方で、組織の残りの運用チェーンはそれを遅すぎて知ることになります。
これを別のオーケストレーションレイヤーで解決することは可能ですが、それは新しいサービス、新しい認証情報、新しい監視、新しい障害ポイントを意味します。ヘルスチェックはすでにGTM内で実行されており、状態変化を外部システムに伝搬することは同じプラットフォームから管理されるべきです。
DNS転送側でも問題は同様です。一部のドメインは内部DNSに、一部は外部リゾルバーに、一部はTR7自身の権威ゾーンに属します。単純なフォワーダーがすべてを単一の宛先に送ると、スプリットDNS、内部ゾーン、パートナードメイン、ジオルーティング動作が衝突します。
ECS情報が失われると問題は深まります。ジオおよびトポロジーベースの判断はクライアントネットワークコンテキストに依存します。フォワーダーがそのコンテキストをドロップすると、上流の地理ルーティングが間違ったロケーションに対して行われる可能性があります。フォワーダーは単にクエリを運ぶだけでなく、判断コンテキストも保持すべきです。
TR7 GTMトリガーとフォワーダーは、ヘルスチェック状態変化をHTTP/HTTPSまたはOracle DBアクションチェーンにバインドし、選択的ドメイン転送、localhostゾーン転送、ECSパススルーを通じてDNS転送を運用可能にします。
TR7はGTMを単にクエリに応答するDNSエンジンとしてではなく、ヘルス状態に反応してコンテキストに従ってDNSクエリを転送するアクティブな運用レイヤーとして設計します。
HCシナリオのベース状態が変化すると、turnまたはreturnアクションが実行できます。シナリオが有効化されるとtriggerTurnActionsが順番に実行され、通常に戻るとtriggerReturnActionsが順番に実行されます。
HTTP/HTTPSトリガーはメソッド、URI、ヘッダー、ボディ、想定ステータスコード、タイムアウトで定義されます。応答ボディはJSONataまたは基本コンテンツチェックで検証して、アクションが成功したかを判断できます。
Oracleトリガーは接続文字列とシナリオステップ配列で動作します。waitおよびexecuteCmdステップがデータベースに対してチェックまたはアクションを実行でき、想定行数または想定テキスト値を検証できます。
フォワーダーは特定のドメインを特定のDNSターゲットに送信でき、ルートドメインにデフォルトターゲットを定義できます。ECSパススルーがクライアントサブネットコンテキストを保持するため、ジオルーティング判断が壊れません。
GTMトリガーとフォワーダーは、ヘルスチェックアクション、HTTP/HTTPSおよびOracle検証、チェーン化されたトリガーフロー、選択的DNS転送を単一の管理モデルに統合します。
HTTPトリガーは宛先アドレス、ポート、リクエストメソッド、URI、ヘッダーリスト、リクエストボディで定義されます。想定ステータスコードのリストが呼び出しが成功したかを判断します。タイムアウトが長時間実行される外部システム呼び出しを制限します。DRランブック、監査エンドポイント、アラームシステムなどのHTTPベースターゲットはすべてこのモデルで発火できます。
HTTPSトリガーはHTTPと同じリクエストモデルをTLS上で適用します。verifyCertificateフラグがターゲット証明書が検証されるかを決定します。本番では証明書検証を有効に保つことが推奨されます。このパターンはGTMシナリオ変化を安全な外部アクションシステムに配信するために使用されます。
HTTP/HTTPSトリガー応答はJSONまたはXMLとして解析され、JSONata式で検証できます。式コンテキストにはbody、bodyRaw、headers、statusが含まれます。例えば、外部ランブックシステムが200を返しても、応答ボディ内のsuccess=trueフィールドを別途チェックできます。これにより、ステータスコードのみに依存しないより堅牢なトリガー検証が可能になります。
JSONataが不要な場合、基本コンテンツチェックを使用できます。応答ボディは.includes()セマンティクスを使用して特定の文字列の存在をテストされます。これは小さな統合、レガシーシステム、単純なヘルス応答を返すエンドポイントには十分です。運用者は複雑な式を書かずに迅速に検証できます。
Oracleトリガーはユーザー、パスワード、接続文字列でデータベースに接続します。シナリオステップにはwaitおよびexecuteCmd操作が含まれます。executeCmdからの想定行数または想定テキスト値を検証できます。このモデルはアプリケーションデータベース状態のクロス検証や、データベース側で制御されたアクションを実行するために使用されます。
triggerTurnActionsとtriggerReturnActions配列は複数のトリガーIDを順番に実行します。1つのアクションが失敗するとチェーンが切れ、後続のアクションは実行されません。これにより、依存するランブックステップが制御されずに進むことを防ぎます。最初に監査エンドポイントに書き込み、次にDRジョブを開始するようなフローをこの方法で構築できます。
turnはシナリオが有効化される瞬間を表し、returnは非有効化されて通常に戻る瞬間を表します。各方向に別々のトリガーリストと条件を定義できます。フェイルオーバー中と復旧中に異なるアクションを発火できます。この分離により運用フローのよりクリーンな設計が可能になります。
新しいグループキーが到着すると、古いトリガープロセスを停止できます。トリガーライフサイクルはstarted、succeeded、failedログエントリで追跡され、短い遅延後にactiveTriggerイベントがクリアされます。この動作により、ヘルス状態変化が急速に連続して発生したときに古いアクションが新しいフローと衝突する可能性が低減されます。メインサービスはトリガーフォークから隔離されます。
クラスタでは、トリガーはマスターノード上でのみ実行されます。同じヘルス状態変化を見る他のノードは外部アクションを再発火しません。これによりWebhookまたはDBアクションの二重発火を防ぎます。クラスタ動作はより決定論的になります。
フォワーダーレイヤーは別のRecursorプロセスとして位置付けられます。forwarderInnerPort範囲でDNSクエリを受信し、定義された上流ターゲットに転送します。権威DNSとRecursor転送動作は分離されます。この分離により、TR7は同じアーキテクチャ内で自身のゾーンと外部DNS解決を制御された方法で管理できます。
domainBasedForwardingリストにより、特定のドメインを特定のDNSアドレスに導けます。内部ドメインは企業DNSに行き、他のクエリはデフォルトの上流リゾルバーに行けます。この設計はスプリットDNSおよびハイブリッドDNSアーキテクチャに重要です。すべてのクエリを単一の宛先に送る粗いフォワーダーを超えます。
フォワーダーはECS情報を上流リゾルバーに渡し、クライアントサブネットコンテキストで判断できるようにします。ECS動作はecs-ipv4-bits、ecs-add-for、許可リスト設定で制御されます。このコンテキストはジオルーティングまたはトポロジーベースの上流判断に重要です。ECSがドロップされると、地理ルーティングが間違ったリゾルバーロケーションに対して行われる可能性があります。
GTMトリガーとフォワーダーは、タイムアウト動作、ライフサイクル追跡、子プロセス隔離、解析優先順位、転送ゾーン順序、メタデータラインと共に運用されます。
HTTPトリガーのデフォルトタイムアウトは120秒です。Oracleトリガーは自身の処理時間に応じてより長く実行されることがあります。全体的なトリガープロセスは24時間で上限を設定でき — 長いランブックやマルチステップデータベースシナリオに重要な上限です。
トリガーチェーンには自動再試行はありません。トリガーが失敗するとチェーンが切れ、後続のアクションは実行されません。したがってターゲットシステムは冪等で信頼性のあるものに設計されるべきです。
トリガーはstarted、succeeded、failed状態でログに記録されます。これらのレコードは、フェイルオーバーまたは復旧イベント中にどのアクションが実行されたかを示します。アクティブトリガー状態は短い遅延後にクリアされます。
トリガー実行は別の子プロセスとして実行できます。このモデルにより、メインGTMサービスが長時間実行される外部呼び出しやDB操作の影響を受けることを防ぎます。失敗するトリガーがメインサービスを停止させることはありません。
HTTP応答ボディはコンテンツタイプに基づいて、最初にJSONとして、次にXMLとして解析されます。いずれも成功しない場合、生の文字列フォールバックが使用されます。JSONata式はこのコンテキストに対して評価されます。
forward-zones-recurseラインは定義された順序で生成されます。最初のドメイン転送定義はプライマリラインとして書かれ、後続の定義は追加ラインとして書かれます。この順序は選択的転送動作のクリーンな適用に重要です。
forwarder.metaDataフィールドは追加のRecursor構成ラインを運びます。カスタムキャッシュ、ポリシー、運用設定のための拡張ポイントを提供します。使用中のメタデータラインは慎重に検証されるべきです。
ヘルスチェックシナリオが有効化されると、HTTP POSTトリガーが発火します。アラームまたはインシデント管理システムがデータセンターダウン通知を受け取ります。DNSフェイルオーバー判断は同じ瞬間に外部運用システムに見えるようになります。
DRシナリオが有効化されると、HTTPSトリガーが自動化プラットフォームでジョブを開始できます。最初のトリガーは監査レコードを作成し、2つ目のトリガーはDR起動ジョブを実行します。トリガーチェーンが失敗した場合、次のステップは制御されずに進むことはありません。
各turnおよびreturnイベントで、HTTPトリガーが監査エンドポイントにイベントレコードを送信できます。どのゾーン、どのシナリオ、いつ変化が発生したかの情報が外部ログシステムにプッシュされます。GTM判断は監査可能になります。
アプリケーションハートビートが失敗すると、Oracleトリガーが独立したDBチェックを実行できます。想定行数またはテキスト値が返されると、イベントはクロス検証されます。これによりHTTPヘルスチェック結果のみに依存しない、より強力な判断シグナルが生成されます。
internal.example.comのようなドメインは、domainBasedForwardingを介して企業DNSターゲットに転送できます。他のクエリはデフォルトの上流DNSに行きます。TR7自身の権威ゾーンはlocalhost経由でローカルDNSプロセスに転送できます。
内部クライアントは企業Recursorを介して内部アプリケーションドメインを解決でき、外部クライアントはTR7 GTM権威応答を受け取れます。選択的転送とECSパススルーを共に使用すると、内部と外部の解決動作が分離されます。DNSアーキテクチャは単一方向の転送に縛られません。
HTTP/HTTPSおよびOracle DBトリガーチェーン、選択的DNS転送、ECS認識Recursor。ご自身の環境でライブセットアップをご案内します。