Amazon Redshift 연결 문제 해결 - Amazon Redshift

Amazon Redshift 연결 문제 해결

SQL 클라이언트 도구에서 클러스터에 연결하는 데 문제가 발생하면 문제의 원인을 좁힐 수 있는 몇 가지 검사 방법이 있습니다. SSL 또는 서버 인증서를 사용할 때는 먼저 연결 문제를 해결하면서 이러한 복잡성을 제거했다가 이후 해결책을 발견했을 때 다시 추가하면 됩니다. 자세한 내용은 연결을 위한 보안 옵션 구성 섹션을 참조하세요.

중요

Amazon Redshift는 SSL 인증서 관리 방법을 바꿨습니다. SSL을 사용하여 연결하는 데 문제가 있으면 현재 신뢰하는 루트 CA 인증서를 업데이트해야 할 수 있습니다. 자세한 내용은 SSL 연결을 위해 ACM 인증서로 이전 섹션을 참조하세요.

다음 섹션에서는 몇 가지 오류 메시지의 예와 가능한 연결 문제 해결책에 대해서 살펴보겠습니다. SQL 클라이언트 도구마다 오류 메시지가 다르기 때문에 아래와 같은 목록이 완벽할 수는 없지만 문제 해결을 위한 훌륭한 출발점이 될 것입니다.

Amazon EC2 외부에서 연결 및 방화벽 시간 제한 문제 발생

COPY 명령 같은 긴 쿼리를 실행할 때는 데이터베이스에 대한 클라이언트 연결이 멈추거나 제한 시간에 걸릴 수 있습니다. 이런 경우 Amazon Redshift 콘솔에서 쿼리의 완료 여부를 관찰할 수 있지만 클라이언트 도구에는 쿼리가 여전히 실행 중인 것으로 표시됩니다. 쿼리 결과는 연결 중단 시점에 따라 누락되거나 불완전할 수도 있습니다.

가능한 해결책

이 문제는 Amazon EC2 인스턴스가 아닌 다른 컴퓨터에서 Amazon Redshift에 연결할 때 발생합니다. 이 경우 유휴 연결은 일정 시간 동안 사용하지 않으면 방화벽과 같은 중간 네트워크 구성 요소에 의해 종료됩니다. 이 동작은 가상 사설 네트워크(VPN) 또는 로컬 네트워크에서 로그온할 때 일반적입니다.

제한 시간 문제를 방지하려면 다음과 같이 변경하는 것이 좋습니다.

  • TCP/IP 제한 시간을 처리하는 클라이언트 시스템 값을 높이세요. 단, 이러한 시스템 값은 클러스터에 연결할 때 사용하는 컴퓨터에서 변경해야 합니다. 또한 제한 시간은 클라이언트와 네트워크를 고려하여 조정해야 합니다. 자세한 내용은 TCP/IP 제한 시간 설정 변경 섹션을 참조하세요.

  • 그 밖의 옵션으로 keepalive 동작을 DSN 수준으로 설정합니다. 자세한 내용은 DSN 제한 시간 설정 변경 섹션을 참조하세요.

TCP/IP 제한 시간 설정 변경

TCP/IP 제한 시간 설정을 변경하려면 클러스터에 연결할 때 사용하는 운영 체제에 따라 제한 시간 설정을 구성합니다.

  • Linux - 클라이언트가 Linux에서 실행 중인 경우 루트 사용자로 다음 명령을 실행하여 현재 세션의 시간 제한 설정을 변경합니다.

    /sbin/sysctl -w net.ipv4.tcp_keepalive_time=200 net.ipv4.tcp_keepalive_intvl=200 net.ipv4.tcp_keepalive_probes=5

    설정을 계속해서 유지하려면 /etc/sysctl.conf 파일을 생성하거나 다음 값으로 수정한 후 시스템을 재부팅하세요.

    net.ipv4.tcp_keepalive_time=200 net.ipv4.tcp_keepalive_intvl=200 net.ipv4.tcp_keepalive_probes=5
  • Windows - 클라이언트가 Windows에서 실행되는 경우 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\에서 다음 레지스트리 설정 값을 편집합니다.

    • KeepAliveTime: 30000

    • KeepAliveInterval: 1000

    • TcpMaxDataRetransmissions: 10

    위 설정 값은 DWORD 데이터 형식을 사용합니다. 설정이 레지스트리 경로에 존재하지 않으면 설정을 직접 생성한 후 다음과 같은 권장 값을 지정할 수도 있습니다. Windows 레지스트리의 편집에 대한 자세한 내용은 Windows 설명서를 참조하세요.

    값을 설정한 후에는 컴퓨터를 다시 시작해야 변경 사항이 적용됩니다.

  • Mac - 클라이언트가 Mac에서 실행 중인 경우 다음 명령을 실행하여 현재 세션의 시간 제한 설정을 변경합니다.

    sudo sysctl net.inet.tcp.keepintvl=200000 sudo sysctl net.inet.tcp.keepidle=200000 sudo sysctl net.inet.tcp.keepinit=200000 sudo sysctl net.inet.tcp.always_keepalive=1

    설정을 계속해서 유지하려면 /etc/sysctl.conf 파일을 생성하거나 다음 값으로 수정합니다.

    net.inet.tcp.keepidle=200000 net.inet.tcp.keepintvl=200000 net.inet.tcp.keepinit=200000 net.inet.tcp.always_keepalive=1

    컴퓨터를 다시 시작한 후 다음 명령을 실행하여 값이 설정되었는지 확인합니다.

    sysctl net.inet.tcp.keepidle sysctl net.inet.tcp.keepintvl sysctl net.inet.tcp.keepinit sysctl net.inet.tcp.always_keepalive

DSN 제한 시간 설정 변경

원하는 경우 keepalive 동작을 DSN 수준으로 설정할 수 있습니다. odbc.ini 파일에서 다음 파라미터를 추가하거나 수정하면 가능합니다.

KeepAlivesCount

연결이 끊긴 것으로 간주할 때까지 손실될 수 있는 TCP keepalive 패킷의 수입니다.

KeepAlivesIdle

드라이버가 TCP keepalive 패킷을 전송할 때까지 아무런 작업 없이 대기하는 시간(초)입니다.

KeepAlivesInterval

TCP keepalive가 재전송되는 시간 간격(초)입니다.

이러한 파라미터가 존재하지 않거나 값이 0인 경우에는 시스템이 TCP/IP에 지정한 keepalive 파라미터를 사용하여 DSN keepalive 동작을 결정합니다. Windows에서는 레지스트리의 TCP/IP 파라미터를 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\에서 확인할 수 있습니다. 그리고 Linux 및 macOS에서는 TCP/IP 파라미터를 sysctl.conf 파일에서 찾아볼 수 있습니다.

연결 거부 또는 실패

연결이 거부되거나 실패하면 다음 중 하나와 유사한 오류가 발생할 수 있습니다.

  • "Failed to establish a connection to <endpoint>."

  • "Could not connect to server: Connection timed out. Is the server running on host '<endpoint>' and accepting TCP/IP connections on port '<port>'?"

  • "Connection refused. Check that the hostname and port are correct and that the postmaster is accepting TCP/IP connections."

가능한 해결책

일반적으로 연결 구성에 실패했다는 오류 메시지가 수신되면 클러스터에 대한 액세스 권한과 관련된 문제이거나 네트워크 트래픽이 클러스터에 도달하는 것과 관련된 문제입니다.

클러스터가 있는 네트워크 외부의 클라이언트 도구에서 클러스터에 연결하려면 클러스터의 보안 그룹에 인바운드 규칙을 추가합니다. 규칙 구성은 Amazon Redshift 클러스터가 Virtual Private Cloud(VPC)에 생성되었는는지에 따라 달라집니다.

  • Amazon VPC를 기반으로 Virtual Private Cloud(VPC)에서 Amazon Redshift 클러스터를 생성한 경우 Amazon VPC에서 클라이언트 CIDR/IP 주소를 지정하는 VPC 보안 그룹에 인바운드 규칙을 추가합니다. 클러스터의 VPC 보안 그룹 구성 및 퍼블릭 액세스 옵션에 대한 자세한 내용은 VPC의 Redshift 리소스 섹션을 참조하세요.

  • VPC 외부에 Amazon Redshift 클러스터를 생성한 경우에는 Amazon Redshift의 클러스터 보안 그룹에 클라이언트 CIDR/IP 주소를 추가합니다. 클러스터 보안 그룹 구성에 대한 자세한 내용은 Amazon Redshift 보안 그룹 섹션을 참조하세요.

Amazon EC2 인스턴스에서 실행되는 클라이언트 도구에서 클러스터에 연결하려면 인바운드 규칙도 추가합니다. 이 경우 클러스터 보안 그룹에 규칙을 추가하세요. 규칙은 클라이언트 도구의 Amazon EC2 인스턴스와 연결된 Amazon EC2 보안 그룹을 지정해야 합니다.

경우에 따라 방화벽과 같이 클라이언트와 서버 간에 계층이 있을 수 있습니다. 이러한 경우 클러스터에 대해 구성한 포트를 통한 인바운드 연결을 방화벽에서 허용하는지 확인합니다.

클라이언트와 드라이버가 호환되지 않습니다

클라이언트와 드라이버가 호환되지 않는 경우 “지정된 DSN에 드라이버와 애플리케이션 간의 아키텍처 불일치가 포함되어 있습니다”라는 오류가 표시될 수 있습니다.

가능한 해결책

연결을 시도하다 아키텍처 불일치 오류가 발생하기도 합니다. 이는 클라이언트 도구와 드라이버가 호환되지 않는다는 것을 의미합니다. 이 오류는 시스템 아키텍처가 일치하지 않기 때문에 발생합니다. 예를 들어 클라이언트 도구가 32비트이지만 설치되어 있는 드라이버가 64비트 버전이면 이러한 불일치가 발생할 수 있습니다. 간혹 64비트 클라이언트 도구가 32비트 드라이버를 사용하는 경우가 있지만 64비트 드라이버에 32비트 애플리케이션을 사용할 수는 없습니다. 따라서 드라이버와 클라이언트 도구가 동일한 버전의 시스템 아키텍처를 사용하고 있는지 확인해야 합니다.

쿼리가 중단되거나, 간혹 클러스터까지 전송되지 않습니다

쿼리가 실행 중인 것으로 보이지만 SQL 클라이언트 도구에서는 중단되는 증 쿼리 완료에 대한 문제가 발생합니다. 간혹 시스템 테이블이나 Amazon Redshift 콘솔과 같은 클러스터에 쿼리가 표시되지 않기도 합니다.

가능한 해결책

이 문제는 패킷이 소실되어 발생할 수 있습니다. 이 경우 두 IP(Internet Protocol) 호스트 간 네트워크 경로에서 최대 전송 단위(MTU)의 크기 차이가 있습니다. 단일 이더넷 프레임으로 네트워크 연결을 통해 전송할 수 있는 패킷의 최대 크기(바이트)는 MTU의 크기에 따라 결정됩니다. AWS에서는 일부 Amazon EC2 인스턴스 유형이 1500MTU(이더넷 v2 프레임)를 지원하고, 그 밖에 9001MTU(TCP/IP 점보 프레임)를 지원하는 인스턴스 유형도 있습니다.

MTU 크기 차이에서 발생할 수 있는 문제에 대한 해결책으로서 다음 중 한 가지를 권장합니다.

  • 클러스터가 EC2-VPC 플랫폼을 사용하는 경우에는 Destination Unreachable을 반환하는 사용자 정의 ICMP(Internet Control Message Protocol) 인바운드 규칙으로 Amazon VPC 보안 그룹을 구성합니다. 이 규칙은 전송 호스트에게 네트워크 경로를 따라 최저 MTU 크기를 사용하도록 지시합니다. 이러한 접근법에 대한 자세한 내용은 ICMP "destination unreachable"을 허용하도록 보안 그룹 구성하기 섹션을 참조하세요.

  • 클러스터가 EC2-Classic 플랫폼을 사용하거나 ICMP 인바운드 규칙을 허용할 수 없는 경우 TCP/IP 점보 프레임을 비활성화하여 이더넷 v2 프레임을 사용하세요. 이러한 접근법에 대한 자세한 내용은 인스턴스의 MTU 구성 섹션을 참조하세요.

ICMP "destination unreachable"을 허용하도록 보안 그룹 구성하기

두 호스트 사이의 네트워크에서 MTU 크기에 차이가 있다면 먼저 네트워크 설정이 PMTUD(path MTU discovery)를 차단하지 않는지 확인해야 합니다. 수신 호스트가 ICMP 메시지 Destination Unreachable: fragmentation needed and DF set (ICMP Type 3, Code 4)과 함께 전송 호스트에 응답하기 위해서는 PMTUD가 차단되어서는 안 됩니다. 이 메시지는 전송 호스트에게 네트워크 경로를 따라 요청을 재전송하려면 최저 MTU 크기를 사용하라는 의미입니다. 이러한 협상이 없으면 수신 호스트가 허용할 수 없을 만큼 요청이 너무 많아져서 패킷 손실이 발생할 수 있습니다. 이 ICMP 메시지에 대한 자세한 내용은 IETF(Internet Engineering Task Force) 웹 사이트의 RFC792 섹션을 참조하세요.

Amazon VPC 보안 그룹에 이 ICMP 인바운드 규칙을 명시적으로 구성하지 않으면 PMTUD가 차단됩니다. AWS에서는 보안 그룹이 인바운드 및 아웃바운드 트래픽에 대한 규칙을 인스턴스로 지정하는 가상 방화벽입니다. Amazon Redshift 클러스터 보안 그룹에 대한 자세한 내용은 Amazon Redshift 보안 그룹 섹션을 참조하세요. EC2-VPC 플랫폼을 사용하는 클러스터의 경우에는 Amazon Redshift가 VPC 보안 그룹을 사용하여 클러스터로 전송되는 트래픽을 허용하거나 거부합니다. 기본적으로 보안 그룹은 잠겨있기 때문에 인바운드 트래픽을 모두 거부합니다. EC2-Classic 또는 EC2-VPC 인스턴스에 대한 인바운드 및 아웃바운드 규칙을 설정하는 방법에 대한 자세한 내용은 Amazon EC2 사용 설명서의 EC2-Classic과 VPC의 인스턴스 간 차이점을 참조하세요.

VPC 보안 그룹에 규칙을 추가하는 방법에 대한 자세한 내용은 VPC 보안 그룹 섹션을 참조하세요. 이 규칙에 필요한 특정 PMTUD 설정에 대한 자세한 내용은 Amazon EC2 사용 설명서의 경로 MTU 검색을 참조하세요.

인스턴스의 MTU 구성

클러스터가 EC2-Classic 플랫폼을 사용하거나 인바운드 트래픽에 대한 사용자 지정 ICMP 규칙을 허용할 수 없는 경우가 있습니다. 이러한 경우 Amazon Redshift 클러스터에 연결하는 EC2 인스턴스의 네트워크 인터페이스(NIC)에서 MTU를 1500으로 조정하는 것이 좋습니다. 이렇게 조정하면 TCP/IP 점포 프레임을 비활성화하여 동일한 패킷 크기를 계속해서 사용할 수 있습니다. 하지만 Amazon Redshift 연결에 그치지 않고 인스턴스 전체의 최대 네트워크 처리 속도까지 떨어뜨리는 단점도 있습니다. 자세한 내용은 다음 절차를 참조하십시오.

Microsoft Windows 운영 체제에서 MTU를 설정하려면

클라이언트가 Microsoft Windows 운영 체제 기반인 경우에는 netsh 명령을 사용하여 이더넷 어댑터의 MTU 값을 살펴보거나 설정할 수 있습니다.

  1. 다음 명령을 실행하여 현재 MTU 값을 결정합니다.

    netsh interface ipv4 show subinterfaces
  2. 출력 화면에서 MTU 어댑터의 Ethernet 값을 살펴봅니다.

  3. 이 값이 1500이 아닌 경우에는 다음 명령을 실행하여 설정합니다.

    netsh interface ipv4 set subinterface "Ethernet" mtu=1500 store=persistent

    이 값을 설정한 후에는 컴퓨터를 다시 시작해야 변경 사항이 적용됩니다.

Linux 운영 체제에서 MTU를 설정하려면

클라이언트가 Linux 운영 체제에서 작동하는 경우 ip 명령을 사용하여 MTU 값을 검토하고 설정할 수 있습니다.

  1. 다음 명령을 실행하여 현재 MTU 값을 결정합니다.

    $ ip link show eth0
  2. 출력 결과에서 mtu 다음의 값을 검토합니다.

  3. 이 값이 1500이 아닌 경우에는 다음 명령을 실행하여 설정합니다.

    $ sudo ip link set dev eth0 mtu 1500
Mac 운영 체제에서 MTU를 설정하려면
  • How to change the MTU for troubleshooting purposes에 대한 MacOS 지원 사이트의 지침을 따릅니다. 자세한 내용은 지원 사이트를 참조하세요.

JDBC Fetch Size 파라미터 설정

기본적으로 JDBC 드라이버는 모든 쿼리 결과를 한 번에 수집합니다. 그 결과, JDBC 연결을 통해 대용량의 결과 집합을 가져오려고 하면 클라이언트 측 메모리 부족 오류가 발생할 수 있습니다. 단 한 번에 모두 가져오거나 아무것도 가져오지 않는 방식이 아닌 배치(batch) 방식으로 결과 집합을 가져오려면 클라이언트 애플리케이션에서 JDBC Fetch Size 파라미터를 설정하세요.

참고

ODBC는 Fetch Size 파라미터가 지원되지 않습니다.

성능을 최적화하려면 메모리 부족 오류가 일어나지 않는 범위 내에서 페치 크기 값을 가장 높게 설정하세요. 페치 크기 값이 더 낮아지면 서버 전송이 늘어나서 실행 시간이 장기화될 수 있습니다. 서버는 클라이언트가 전체 결과 집합을 가져오거나 쿼리가 취소될 때까지 WLM 쿼리 슬롯이나 연결 메모리를 비롯한 리소스를 예약합니다. 이때 Fetch Size 값을 적절히 조정하면 이러한 리소스가 더욱 빠르게 해제되어 다른 쿼리에서도 사용할 수 있게 됩니다.

참고

대용량 데이터 집합을 추출해야 하는 경우에는 UNLOAD 문을 사용하여 데이터를 Amazon S3로 전송하는 것이 좋습니다. UNLOAD를 사용하면 컴퓨팅 노드가 병렬로 실행되어 데이터 전송 속도가 빨라집니다.

JDBC Fetch Size 파라미터 설정에 대한 자세한 내용은 PostgreSQL 설명서의 Getting results based on a cursor에서 확인할 수 있습니다.