Amazon Timestream for LiveAnalytics に類似した機能をご希望の場合は Amazon Timestream for InfluxDB をご検討ください。リアルタイム分析に適した、シンプルなデータインジェストと 1 桁ミリ秒のクエリ応答時間を特徴としています。詳細については、[こちら](https://docs.aws.amazon.com//timestream/latest/developerguide/timestream-for-influxdb.html)を参照してください。
翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# クラスターエンドポイントの 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 NS
```
出力`AUTHORITY SECTION`の で、 の後にリストされているネームサーバーを書き留めます`IN SOA`。例: `ns-1458.awsdns-54.org`。
1. 信頼できるネームサーバーを直接クエリしてキャッシュをバイパスします。
```
dig @ns-1458.awsdns-54.org
```
これにより、エンドポイントの現在の IP アドレスが返され、実際の DNS ベースのトラフィック分散が反映されます。
1. 解決された 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 ベースのディストリビューションを使用するクラスターレベルのエンドポイント (書き込みと読み取り) を対象としています。個々のノードを直接ターゲットとするノード固有のエンドポイントでは、この設定は必要ありません。
+ **実装をテスト**する — アプリケーションが複数のノード間で接続を正しく分散し、シミュレートされたノード障害から回復することを確認します。