Amazon Redshift クラスターで断続的な接続の問題が発生するのはなぜですか?

簡単な説明

Amazon Redshift クラスターでの断続的な接続の問題は、次が原因となって発生します。

• 特定の IP アドレスまたは CIDR ブロックへの制限付きアクセス
• メンテナンスウィンドウの更新
• ノード障害またはスケジュールされた管理タスク
• 暗号化キーのローテーション
• 多すぎるアクティブなネットワーク接続
• リーダーノードの高い CPU 使用率
• クライアント側の接続の問題

解決方法

特定の IP アドレスまたは CIDR ブロックへの制限付きアクセス

セキュリティグループ内の特定の IP アドレスまたは CIDR ブロックへのアクセスが制限されているかどうかを確認します。DHCP 設定が原因となって、クライアントの IP アドレスが変更され、接続の問題が発生する可能性があります。さらに、Amazon Redshift クラスターに伸縮自在な IP アドレスを使用していない場合、クラスターノードの AWS マネージド IP アドレスが変更される可能性があります。たとえば、クラスターを削除してスナップショットから再作成したり、一時停止したクラスターを再開したりすると、IP アドレスが変更される可能性があります。

注意: パブリック IP アドレスは、Amazon Redshift クラスターが削除されて再作成されるときにローテーションされます。プライベート IP アドレスは、ノードが置き換えられるたびに変更されます。

ネットワークの制限を解決するには、次のアプローチを検討してください。

• アプリケーションがクラスターエンドポイントの背後にパブリック IP アドレスをキャッシュしている場合は、必ずこのエンドポイントを Amazon Redshift 接続に使用してください。ネットワーク接続の安定性とセキュリティを確保するために、接続に DNS キャッシュを使用しないでください。
• Amazon Redshift クラスターに伸縮自在な IP アドレスを使用することがベストプラクティスです。伸縮自在な IP アドレスを使用すると、クライアントがクラスターへの接続に使用する IP アドレスに影響を与えることなく、基盤となる設定を変更できます。このアプローチは、障害後にクラスターを回復する場合に役立ちます。詳細については、VPC でのクラスターの管理を参照してください。
• プライベート IP アドレスを使用してリーダーノードまたは計算ノードに接続している場合は、必ず新しい IP アドレスを使用してください。たとえば、SSH 取り込みを実行した場合、または計算ノードを使用する Amazon EMR 設定がある場合は、新しい IP アドレスで設定を更新します。ノードの交換後、新しいプライベート IP アドレスが新しいノードに付与されます。

メンテナンスウィンドウの更新

Amazon Redshift クラスターのメンテナンスウィンドウを確認してください。メンテナンスウィンドウの間、Amazon Redshift クラスターは読み取りまたは書き込み操作を処理できません。メンテナンスイベントが特定の週にスケジュールされている場合、割り当てられた 30 分のメンテナンスウィンドウの間に開始されます。Amazon Redshift がメンテナンスを実行している間、進行中のクエリやその他の操作はすべてシャットダウンされます。Amazon Redshift コンソールからスケジュールされたメンテナンスウィンドウを変更できます。

ノード障害またはスケジュールされた管理タスク

Amazon Redshift コンソールから、[Events] (イベント) タブで、ノードの障害やスケジュールされた管理タスク (クラスターのサイズ変更や再起動など) を確認します。

ハードウェア障害が発生した場合、Amazon Redshift が短期間利用できなくなり、クエリが失敗する可能性があります。クエリが失敗すると、次のような [Events] (イベント) の説明が表示されます。

"A hardware issue was detected on Amazon Redshift cluster [cluster name]. A replacement request was initiated at [time]."

または、アカウント管理者が Amazon Redshift クラスターで再起動またはサイズ変更操作をスケジュールした場合、断続的な接続の問題が発生する可能性があります。[Events] (イベント) の説明には、次のことが示されています。

"Cluster [cluster name] began restart at [time]."
"Cluster [cluster name] completed restart at [time]."

詳細については、 Amazon Redshift のイベントカテゴリとイベントメッセージを参照してください。

暗号化キーのローテーション

Amazon Redshift クラスターのキー管理の設定を確認してください。AWS Key Management Service (AWS KMS) のキー暗号化とキー暗号化ローテーションを使用しているかどうかを確認します。

暗号化キーが有効になっていて、暗号化キーがローテーションされている場合、この間、Amazon Redshift クラスターは使用できません。その結果、次のエラーメッセージが表示されます。

"pg_query(): Query failed: SSL SYSCALL error: EOF detected"

キーローテーションの頻度は、データのセキュリティと標準に関する環境のポリシーによって異なります。必要に応じて、または暗号化されたキーが危険にさらされる可能性があるときはいつでも、キーをローテーションします。また、セキュリティとクラスターの可用性の両方のニーズをサポートするキー管理計画を必ず用意してください。

多すぎるアクティブな接続

Amazon Redshift では、クラスターへのすべての接続がリーダーノードに送信され、アクティブな接続には上限があります。Amazon Redshift クラスターがサポートできる上限は、(ノード数ではなく) ノードタイプによって決まります。

Amazon Redshift クラスターにアクティブな接続が多すぎると、次のエラーが発生します。

"[Amazon](500310) Invalid operation: connection limit "500" exceeded for non-bootstrap users"

Amazon Redshift クラスターへの接続中に 無効な操作エラーを受け取った場合は、接続制限に達したことを示しています。Amazon CloudWatch の DatabaseConnections メトリクスを確認することで、クラスターのアクティブな接続の数を確認できます。

データベース接続が急増している場合、Amazon Redshift クラスターに多数のアイドル接続がある可能性があります。アイドル状態の接続の数を確認するには、次の SQL クエリを実行します。

select trim(a.user_name) as user_name, a.usesysid, a.starttime, 
 datediff(s,a.starttime,sysdate) as session_dur, b.last_end, 
datediff(s,case when b.last_end is not null then b.last_end else 
a.starttime end,sysdate) idle_dur
 	FROM
	(select starttime,process,u.usesysid,user_name 
	from stv_sessions s, pg_user u 
	where 
	s.user_name = u.usename 
 	and u.usesysid>1
and process NOT IN (select pid from stv_inflight where userid>1 
union select pid from stv_recents where status != 'Done' and 
 userid>1)
	) a 
	LEFT OUTER JOIN (select 
userid,pid,max(endtime) as last_end from svl_statementtext where 
 userid>1 and sequence=0 group by 1,2) b ON a.usesysid = b.userid AND 
a.process = b.pid
	WHERE (b.last_end > a.starttime OR b.last_end is null)
	ORDER BY idle_dur;

出力は次の例のようになります。

process | user_name  | usesysid |      starttime      | session_dur | last_end | idle_dur
---------+------------+----------+---------------------+-------------+----------+----------
   14684 | myuser     |      100 | 2020-06-04 07:02:36 |           6 |          |        6
(1 row)

アイドル状態の接続が特定されると、次のコマンド構文を使用して接続をシャットダウンできます。

select pg_terminate_backend(process);

出力は次の例のようになります。

pg_terminate_backend 
----------------------
                    1
(1 row)

リーダーノードの高い CPU 使用率

すべてのクライアントは、リーダーノードを使用して Amazon Redshift クラスターに接続します。リーダーノードの CPU 使用率が高いと、断続的な接続の問題が発生する可能性があります。

Amazon Redshift クラスターに接続しようとしたときに、リーダーノードが高い CPU を消費している場合、次のエラーメッセージが表示されます。

"Error setting/closing connection"

リーダーノードが高い CPU 使用率に達しているかどうかを確認するには、Amazon CloudWatch の CPUUtilization メトリクスを確認します。詳細については、Amazon Redshift のメトリクスを参照してください。

クライアント側の接続の問題

クライアント (Workbench/J や PostgreSQL など) とサーバー (Amazon Redshift クラスター) 間の接続の問題を確認します。クライアントが解放されたポートからリクエストを送信しようとすると、クライアント側の接続がリセットされる可能性があります。その結果、接続のリセットにより、断続的な接続の問題が発生する可能性があります。

これらのクライアント側の接続の問題を防ぐには、次のアプローチを検討してください。

• Amazon Redshift のキープアライブ機能を使用して、クライアントとサーバー間の接続が正しく動作していることを確認します。キープアライブ機能は、接続リンクが切断されるのを防ぐのにも役立ちます。キープアライブの値を確認または設定するには、TCP/IP タイムアウト設定の変更および DSN タイムアウト設定の変更を参照してください。
• クエリが実行されているように見えても SQL クライアントツールでハングする場合は、最大遷移単位 (MTU) を確認してください。パケットドロップが原因で、クエリが Amazon Redshift に表示されない場合があります。パケットドロップは、2 つの IP ホスト間のネットワークパスに異なる MTU サイズがある場合に発生します。パケットドロップの問題を管理する方法の詳細については、クエリがハングしているように見え、クラスターに到達できない場合があるを参照してください。

</ul

---