ホストの交換と接続の停止を処理する

Neptune がホストを置き換えるとき (メンテナンスやフェイルオーバー中など）、そのホストへの既存の接続は無効になります。コンテナ化された環境では、クライアントが置き換えを適切に処理しない場合、コンテナ内のすべてのスレッドが停止する可能性があります。

現在のクライアントバージョンを使用する

Gremlin クエリ言語を使用する場合は、Neptune エンジンバージョンと互換性のある TinkerPop ドライバーバージョンを使用します (互換性表Gremlin を使用した Neptune グラフへのアクセスについては、「」を参照してください）。Java ドライバーを使用する場合は、neptune-gremlin-clientエンドポイントのヘルスチェックやフェイルオーバー処理などの接続管理機能を追加する TinkerPop Java ドライバーのラッパーを検討してください。これは、基盤となる TinkerPop ドライバーと同じバージョンの互換性ルールに従います。

Neptune neptune-gremlin-clientバージョンで許可されている内容に応じて、バージョン 3.x (または少なくともバージョン 2.0.7) を使用します。これらの新しいバージョンにより、耐障害性と接続処理が向上します。

Neo4j ドライバーを使用する openCypher ユーザーの場合、フェイルオーバー中に接続障害を検出したときに Driver オブジェクトを閉じて再作成します。Neptune は、Bolt プロトコルバージョン 1 から 4.0 をサポートしています。詳細については、「OpenCypher と Bolt を使用した Neptune のベストプラクティス」を参照してください。

クラスターまたはリーダーエンドポイントを使用する

インスタンスエンドポイントに直接接続しないでください。書き込みにはクラスターエンドポイントを使用し、読み取りにはリーダーエンドポイントを使用します。でインスタンスエンドポイントを使用する必要がある場合はneptune-gremlin-client、 /status API を使用してエンドポイントのヘルスチェックフィルタリングを有効にします。

許容範囲でライブネスプローブを設定する

Kubernetes ライブネスプローブfailureThresholdを 10 秒 (合計 300 秒) の期間で少なくとも 30 に設定します。これにより、Neptune がホストの交換を完了する約 5 分間の時間枠で Kubernetes がポッドを再起動できなくなります。

バックオフによる再試行の実装

ホスト交換中に 1 回失敗したリクエストは、コンテナをクラッシュさせないでください。接続障害時にエクスポネンシャルバックオフを使用して再試行ロジックを実装し、置き換え中の一時的なエラーが介入なしで解決されるようにします。再試行可能な例外のガイダンスについては、「Neptune トランザクション例外」を参照してください。