クラスターエンドポイントの DNS 解決の管理 - Amazon Timestream
DNS キャッシュについて解決策 1: JVM DNS TTL を設定する (Java アプリケーション)解決策 2: 信頼できるネームサーバーによる直接解決ノード IP の変更の処理ベストプラクティス

Amazon Timestream for LiveAnalytics に類似した機能をご希望の場合は Amazon Timestream for InfluxDB をご検討ください。リアルタイム分析に適した、シンプルなデータインジェストと 1 桁ミリ秒のクエリ応答時間を特徴としています。詳細については、こちらを参照してください。

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

クラスターエンドポイントの DNS 解決の管理

InfluxDB for InfluxDB 3 マルチノードクラスターの Timestream InfluxDB は、DNS ベースのトラフィック分散を使用してノード間の接続のバランスを取ります。フェイルオーバーが発生した場合、またはノードが置き換えられると、DNS レコードは使用可能なインスタンスを指すように自動的に更新されます。アプリケーションがこれらの変更を検出し、最適なトラフィック分散を維持するためには、適切な DNS 解決設定が不可欠です。

DNS キャッシュについて

多くのプログラミング環境では、DNS ルックアップをキャッシュしてパフォーマンスを向上させます。ただし、このキャッシュにより、アプリケーションがフェイルオーバー後に更新された IP アドレスを検出したり、複数のクラスターノードに接続を分散したりできなくなる可能性があります。影響は言語とランタイムによって異なります。

  • Java/JVM ベースのアプリケーション — JVM は、設定可能なtime-to-live (TTL) の DNS ルックアップをキャッシュします。一部の設定は、JVM が再起動するまで無期限にキャッシュされます。

  • 他の言語 — Python、Go、Node.js、およびその他のランタイムは通常、オペレーティングシステムの DNS 解決に依存し、同じキャッシュ動作をしない場合があります。

解決策 1: JVM DNS TTL を設定する (Java アプリケーション)

InfluxDB for InfluxDB 3 クラスターエンドポイントの Timestream に接続する Java InfluxDB アプリケーションの場合、JVM DNS キャッシュ TTL をゼロに設定します。これにより、各接続が新しい DNS ルックアップをトリガーし、適切なトラフィック分散と即時のフェイルオーバー検出が可能になります。

現在の TTL 設定を確認します。

String ttl = java.security.Security.getProperty("networkaddress.cache.ttl");

次のいずれかの方法を使用して TTL を設定します。

  • グローバル設定 — networkaddress.cache.ttlで設定します$JAVA_HOME/jre/lib/security/java.security。

    networkaddress.cache.ttl=0

  • アプリケーション固有の設定 — ネットワーク接続を確立する前に、アプリケーションの初期化コードで プロパティを設定します。

    java.security.Security.setProperty("networkaddress.cache.ttl", "0");

  • JVM 引数 — アプリケーションを起動するときにシステムプロパティとして渡します。

    java -Dsun.net.inetaddr.ttl=0 -jar your-application.jar
注記

クラスター以外のエンドポイントまたは一般的な AWS リソースの場合、TTL は通常 60 秒で十分です。ゼロ TTL 推奨事項は、トラフィック分散と迅速なフェイルオーバー検出が重要な InfluxDB 3 クラスターエンドポイントに固有のものです。

解決策 2: 信頼できるネームサーバーによる直接解決

中間 OS レベルのキャッシュなど、TTL 設定が不十分な場合、またはプログラミング言語に DNS キャッシュの問題がない場合、信頼できるネームサーバーを直接クエリすることで、新しい DNS 解決を強制できます。このアプローチは、標準の TTL 設定で問題が解決しない場合にのみ使用します。

直接解決ワークフロー

  1. クラスターエンドポイントの権威ネームサーバーを特定します。

    dig <cluster-endpoint> NS

    出力AUTHORITY SECTIONの で、 の後にリストされているネームサーバーを書き留めますIN SOA。例: ns-1458.awsdns-54.org。

  2. 信頼できるネームサーバーを直接クエリしてキャッシュをバイパスします。

    dig @ns-1458.awsdns-54.org <cluster-endpoint>

    これにより、エンドポイントの現在の IP アドレスが返され、実際の DNS ベースのトラフィック分散が反映されます。

  3. 解決された IP アドレス (複数可) をアプリケーション接続に使用します。この解決を定期的に繰り返すか、接続エラーが発生したときにアドレスを更新します。

例:

# Find authoritative nameserver
dig my-cluster.timestream-influxdb.us-east-1.amazonaws.com NS

# Resolve using authoritative nameserver
dig @ns-1458.awsdns-54.org my-cluster.timestream-influxdb.us-east-1.amazonaws.com

# Use returned IP addresses in your application

ノード IP の変更の処理

重要

ノード IP アドレスは静的ではありません。フェイルオーバー、ノードの再起動、メンテナンスオペレーション、クラスタースケーリング中に変更されます。解決された IP アドレスを無期限にキャッシュしないでください。

IP の変更を処理するには、以下のプラクティスを実装します。

  • 定期的な再解決 — バックグラウンドタスクを使用して 30～60 秒ごとにエンドポイントを再解決します。新しい IP アドレスをキャッシュされた値と比較し、それに応じて接続プールを更新します。

  • エラー駆動型再解決 — 接続が失敗した場合 (タイムアウト、接続拒否、リセット）、エンドポイントをすぐに再解決し、更新された IP アドレスで再試行します。

  • 正常な接続ドレイニング — IP アドレスが DNS レコードセットに含まれなくなった場合、処理中のリクエストは完了できますが、その IP への新しい接続の作成は停止します。

  • 新しい接続の作成 — 再解決後、更新された IP アドレスを使用して新しい接続を作成します。古い IPsに固定された既存の接続は、再解決の恩恵を受けません。

ベストプラクティス

  • TTL 設定から始める — Java アプリケーションの場合は、常にnetworkaddress.cache.ttl=0最初に を設定してみてください。これは最もシンプルで効果的なソリューションです。

  • 直接解決を控えめに使用する — TTL 設定が不十分な場合、または永続的な中間キャッシュを処理する場合にのみ、信頼できるネームサーバークエリを使用します。

  • ネームサーバー検出の自動化 — ネームサーバーアドレスをハードコードしないでください。ネームサーバーの割り当てが変更される可能性があるため、動的に検出します。

  • クラスターエンドポイントにのみ適用されます — これらの手法は、DNS ベースのディストリビューションを使用するクラスターレベルのエンドポイント (書き込みと読み取り) を対象としています。個々のノードを直接ターゲットとするノード固有のエンドポイントでは、この設定は必要ありません。

  • 実装をテストする — アプリケーションが複数のノード間で接続を正しく分散し、シミュレートされたノード障害から回復することを確認します。