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

簡単な説明

以下の問題により、Amazon Redshift クラスターでの接続の問題が断続的に発生する可能性があります。

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

解決策

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

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

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

ネットワークの制限を解決するには、次のいずれかの操作を行います。

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

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

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

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

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

ハードウェア障害が発生すると、Amazon Redshift を短期間使用できなくなり、クエリが失敗する可能性があります。クエリが失敗すると、イベントの説明が次のように表示されます。

「Amazon Redshift クラスター[クラスター名] でハードウェアの問題が検出されました。[時刻] に置き換えリクエストが開始されました。」

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

「クラスタ [クラスタ名] は [時間] に再起動を開始しました。」「クラスタ [クラスタ名] は[時刻] に再起動を完了しました。」

詳細については、「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 クラスターに接続したときに「Invalid operation」エラーを受け取った場合は、接続クォータに達していることになります。クラスターのアクティブな接続の数を確認するには、Amazon CloudWatch の DatabaseConnections メトリクスを確認します。

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

select process, 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 サイズがある場合に、パケットドロップが発生します。パケットドロップの問題を管理する方法の詳細については、「クエリがハングして、クラスターに達しない場合がある」を参照してください。