最も一般的なGTMの間違いは、データセンターヘルスを単一のアップ/ダウンフラグで管理することです。実際にはデータセンターは到達可能でもアプリケーションがダウンしていることがあり、アプリケーションは応答しても データベースが機能していないことがあり、WANリンクは開いていてもLAN側アクセスが失敗していることがあります。単一フラグのヘルスモデルはこれらの区別を捉えられません。
多くの組織では、ヘルスチェックとDNS応答の間のリンクは手動または断片化されています。監視システムがアラートを発し、運用チームがスクリプトを実行し、DNSレコードが手動で更新されるか、別の自動化が引き継ぎます。このチェーンは反応が遅く、重要な瞬間に人的エラーに対して脆弱です。
複雑なシナリオはさらに困難です。「DC1がインターネットアクセスを持ち、かつメンテナンス中でない場合に有効化し、それ以外の場合にはDC2のアプリケーションヘルスまたはDC3アクセスが正常ならバックアップレコードを返す」のような条件は、通常YAMLファイル、スクリプト、手動依存関係で管理されます。これによりGTM判断は理解または監査が困難な運用迷路となります。
フラッピングは現実のリスクです。ヘルスチェックが瞬間的に失敗し、DNSがすぐに変更されると、ユーザートラフィックが不必要に別の地域に移動されます。同様に、短い成功で問題が完全に解決される前にトラフィックが戻されることもあります。連続成功と失敗の閾値、状態保持ロジックがそのために不可欠です。
TR7ヘルスチェックシナリオは、データセンター、アプリケーション、データベース、メンテナンスモード、カスタムチェックを単一のブール判断レイヤーに組み合わせ、DNS応答を実際のサービスヘルスに直接バインドします。
TR7は、自動データセンターチェック、手動ヘルスチェック、シナリオロジックを統一モデルで組み合わせてGTMヘルス判断を評価します。
データセンターごとの自動チェック、ユーザー定義のHTTP/HTTPS/Oracleチェック、ADCヘルス結果はすべて同じ判断構造内で使用できます。これにより、インフラとアプリケーションヘルスが単一のGTM判断にバインドされます。
シナリオはANDおよびORグループで構築されます。ヘルスチェック識別子に`!`を付加すると条件が否定され、メンテナンスモードのような状態を同じ判断内で否定条件として使用できます。
ヘルスチェック、シナリオ、DNSレコードの関係はグラフスタイルマップを通じて追跡されます。ヘルス状態が変化すると、影響を受けるシナリオとレコードのみが再評価されます。
HTTPおよびHTTPSヘルスチェックは、ポートが開いているかだけでなく、ステータスコードと応答コンテンツを検証できます。JSONata式または単純なコンテンツチェックがアプリケーションが本当に健全な応答を返していることを確認します。
TR7ヘルスチェックシナリオは、単純なアクセスチェックからマルチレイヤーアプリケーションおよびデータセンター判断まで、さまざまなGTMニーズをカバーします。
TR7はHTTPおよびHTTPSチェックに対してメソッド、URI、ボディ、ヘッダー、想定ステータスコード、証明書検証、タイムアウトなどのパラメータをサポートします。したがってチェックは接続が確立できるかだけを測定せず — アプリケーションが正しいエンドポイントから正しい応答を返していることも検証し、GTM判断を実際のアプリケーション動作に近づけます。
JSONを返すヘルスエンドポイントでは、JSONata式を使用して特定のフィールドを評価できます。`status = "ok"`のような式は、アプリケーションが応答しているだけでなく、期待されるヘルス状態を返していることを確認します。応答ボディは適切な構造に解析され、式はそれに対して評価されます。これにより現代的なJSON APIベースのアプリケーションに対するより信頼性の高いヘルス測定が得られます。
より単純なシナリオでは、応答ボディに特定の文字列の存在をチェックできます。このアプローチは、完全なJSONata式を必要としない単純なアプリケーションヘルスチェックに十分です。運用チームは既知の単語または固定状態がアプリケーション応答に現れることを確認することにDNS判断をバインドでき、チェックが迅速で理解しやすくなります。
Oracleチェックは接続の確立、待機、コマンドの実行のためのステップを含むシナリオを通じて構成されます。結果は想定行数または想定テキストに基づいて評価されます。これにより、DNS応答をアプリケーション層だけでなくデータベース到達性にも結びつけることができ、重要なビジネスアプリケーションで「アプリケーションはアップだがデータベースが機能していない」というブラインドスポットを低減します。
TR7はデータセンターごとに`wanAccess`、`lanAccess`、`access`、`internet`、`maintenanceMode`チェックを使用できます。これらのチェックは各データセンターの異なるアクセスおよび運用状態を独立して表します。メンテナンスモードのような状態は、肯定的なヘルスシグナルではなく、シナリオで否定条件として扱うことができ、DNS判断を運用現実により近いものにします。
シナリオは条件グループ構造で構築されます。グループ内の条件はAND論理に従い、グループ間関係はORまたはANDが可能です。ヘルスチェック識別子に`!`を付加すると条件が反転され、`dcAccess AND NOT maintenanceMode`のような構造が可能になります。複雑なGTM判断はスクリプトを書かずに設計できます。
ヘルスチェックには`requiredSuccess`と`requiredFailure`値を構成できます。デフォルトのアプローチでは、状態遷移が受け入れられる前に連続成功または失敗をカウントします。これにより、瞬間的なパケット損失、短いレイテンシスパイク、または一時的なサービス変動がDNS応答をすぐに変更することを防ぎ、GTM動作をより安定させます。
ヘルスチェック状態はローカルファイルに永続化でき、システム再起動時に復元されます。これにより、すべてのヘルス状態を再起動ごとにゼロから再学習する必要がなくなります。この継続性は、多くのシナリオとレコードを持つ大規模GTM環境で特に重要であり、運用チームに再起動後のより予測可能な動作を提供します。
TR7エコシステムではTCP、UDP、HTTP、HTTPS、PING、DNS、FTP、FTPS、LDAP、LDAPS、Oracleヘルスチェックが利用可能です。GTMとADCヘルス結果を調整することにより、DNS判断がサービスレイヤーの真の状態を反映できます。この広いタイプサポートにより、Webアプリケーションだけでなくマルチプロトコルエンタープライズサービスのヘルスモデルを構築できます。カスタムチェック要件のためのスクリプトライクなTCP送受信シナリオも利用可能です。
ヘルスチェックシナリオが信頼できる動作をするためには、識別子形式、状態永続化、トリガーシーケンス、マスターノード制御、変更伝搬がすべて明確に管理される必要があります。
シナリオエンジンはstatic、dcCheck、http、https、Oracleを含むヘルスチェックタイプを評価できます。より広いGTMとADCヘルスチェックファミリーと組み合わさり、マルチプロトコルサービス状態を判断構造に持ち込めます — 単一のHTTPチェックタイプに限定されないサービスアーキテクチャに重要です。
データセンターごとの自動ヘルスチェックは`auto|
ユーザー定義のヘルスチェックは一意の識別子で作成されます。これらの識別子はシナリオ条件で直接参照でき、同じHTTP、HTTPS、またはOracleチェックを複数のGTMシナリオで評価できることを意味します。
ヘルス状態が変化すると、関連するヘルスチェック状態が最初に更新されます。次にリンクされたシナリオが再評価され、必要に応じて動的構成が再生成されます。このフローにより、変更が制御された方法でDNS応答に伝搬します。
`ALWAYS`や`NEVER`のような組み込みシナリオが固定判断を生成するために利用可能です。`ALWAYS`では、レコードは常に適格とみなされます。`NEVER`では、無効化動作が達成されます。これはテスト、一時的な取り下げ、無条件ルーティングに有用です。
トリガーアクションはGTMマスターノードでのみ実行されます。これにより、クラスタ内の複数のノードが同じアクションを繰り返し実行することを防ぎます。DRトリガー、Webhook、通知などのアクションには、この制御が運用上の安全性を提供します。
マルチサイト組織では、単一のアクセス経路に基づいてデータセンターがアップとみなされることを望まないかもしれません。TR7は`wanAccess OR lanAccess`のようなシナリオを使用して、異なるアクセス経路を同じDNS判断に組み合わせます。
重要なビジネスアプリケーションでは、データセンター到達性だけでは不十分です。TR7は`dcAccess AND appHC AND dbHC`のようなシナリオを使用して、アプリケーションとOracleデータベースの両方が健全な場合にのみ関連IPをDNS応答に含めます。
運用チームは、技術的に到達可能であってもメンテナンス中のデータセンターがトラフィックを受け取ることを望まないかもしれません。TR7は`dcAccess AND NOT maintenanceMode`のようなシナリオを使用して、メンテナンスロケーションをDNS応答から削除できます。
現代的なアプリケーションはJSONエンドポイントを介してヘルス状態を公開できます。TR7は`status = "ok"`のようなJSONata式とHTTPSヘルスチェックを組み合わせて、DNS応答を実際のアプリケーションヘルスにバインドします。
HTTP、HTTPS、Oracle、データセンターチェックをブールシナリオに組み合わせます。ご自身の環境でライブセットアップをご案内します。