연결 디버깅

MySQL   |  PostgreSQL   |  PostgreSQL to AlloyDB

연결 디버그

소스 데이터베이스와 대상 데이터베이스 간의 연결을 설정했지만 연결되었는지 어떻게 알 수 있나요? 두 시스템 간에 통신이 이루어지지 않으면 어디에서 어떤 문제가 발생했는지 어떻게 알 수 있나요?

가장 기본적인 도구는 ping과 traceroute입니다.

핑

Ping은 기본 테스트를 수행하여 소스에서 대상('원격 호스트')을 이용할 수 있는지 확인합니다. Ping은 ICMP Echo Request 패킷을 원격 호스트로 전송하고 반환으로 ICMP Echo Reply를 예상합니다. ping이 성공하지 못하면 소스에서 대상으로의 경로가 없는 것입니다. 그러나 성공했다고 해서 패킷을 전달할 수 있다는 의미는 아닙니다. 다만, 일반적으로 원격 호스트에 도달할 수 있다는 의미일 뿐입니다.

ping을 통해 호스트가 활성 상태이고 응답하는지 여부를 알 수 있지만 안정성이 보장되지 않습니다. 일부 네트워크 제공업체는 보안상의 이유로 ICMP를 차단하므로 연결 디버깅이 더 어려워질 수 있습니다.

Traceroute

Traceroute는 한 호스트에서 다른 호스트로 이어지는 전체 경로 네트워크 패킷을 테스트합니다. 패킷이 과정에서 거치는 모든 단계('홉')와 각 단계에 소요되는 시간이 표시됩니다. 패킷이 대상까지 완전하게 전송되지 않는 경우 traceroute는 완료되지 않지만 일련의 별표와 함께 종료됩니다. 이 경우에는 성공적으로 전송된 마지막 IP 주소를 찾으세요. 여기서 연결이 끊어진 것입니다.

Traceroute는 타임아웃될 수 있습니다. 또한 패킷을 다음 홉으로 전달하도록 게이트웨이가 올바르게 구성되지 않은 경우에도 완료하는 데 실패할 수 있습니다.

traceroute가 실패하면 중지된 위치를 확인할 수 있습니다. traceroute 출력에 나열된 마지막 IP 주소를 찾고 브라우저에서 who owns [IP_ADDRESS]를 검색합니다. 결과에 주소 소유자가 표시되지 않을 수 있지만 표시될 가능성도 있습니다.

mtr

mtr 도구는 라이브 상태를 유지하면서 지속적으로 업데이트되는 traceroute 유형으로 top 명령어가 로컬 프로세스에 작동하는 방식과 유사합니다.

로컬 IP 주소 찾기

호스트의 로컬 주소를 모르는 경우 ip -br address show 명령어를 실행합니다. Linux에서는 네트워크 인터페이스, 인터페이스 상태, 로컬 IP, MAC 주소가 표시됩니다. 예를 들면 eth0 UP 10.128.0.7/32 fe80::4001:aff:fe80:7/64입니다.

또는 ipconfig 또는 ifconfig를 실행하여 네트워크 인터페이스의 상태를 확인할 수 있습니다.

발신 IP 주소 찾기

소스 데이터베이스와 대상 데이터베이스가 서로 통신하는 데 사용하는 IP 주소 (발신 IP 주소)를 모르는 경우 다음 단계를 완료하세요.

1. Google Cloud 콘솔의 SQL 인스턴스 페이지로 이동합니다.

   Cloud SQL 인스턴스 페이지로 이동

2. 디버그 중인 이전 작업과 연결된 인스턴스의 이름을 클릭합니다.

3. 이 인스턴스에 연결 창이 표시될 때까지 아래로 스크롤합니다. 이 창에 발신 IP 주소가 표시됩니다.

로컬 포트 열기

호스트가 어떤 포트에서 리슨 중인지 확인하려면 ss -tunlp4 명령어를 실행합니다. 이렇게 하면 어떤 포트가 개방되어 리슨 중인지 확인할 수 있습니다. 예를 들어 PostgreSQL 데이터베이스가 실행 중이면 포트 5432에서 리슨해야 합니다. SSH의 경우 포트 22가 표시됩니다.

모든 로컬 포트 활동

netstat 명령어를 사용하여 모든 로컬 포트 활동을 확인합니다. 예를 들어 netstat -lt은 현재 활성 포트를 모두 표시합니다.

telnet을 사용하여 원격 호스트에 연결

TCP를 사용하여 원격 호스트에 연결할 수 있는지 확인하려면 telnet 명령어를 실행합니다. Telnet은 제공된 IP 주소와 포트로 연결을 시도합니다.

예를 들어 원격 호스트에서 PostgreSQL 데이터베이스를 실행하는 경우 포트 5432에서 telnet으로 연결할 수 있습니다(예시: telnet 35.193.198.159 5432).

성공하면 다음이 표시됩니다.

Trying 35.193.198.159...

Connected to 35.193.198.159. .

실패하면 연결 시도를 강제 종료할 때까지 telnet이 응답을 중지합니다.

Trying 35.193.198.159...

^C. .

클라이언트 인증

클라이언트 인증은 pg_hba.conf라는 구성 파일로 제어됩니다(HBA는 호스트 기반 인증(host-based authentication)을 의미함).

소스 데이터베이스에 있는 pg_hba.conf 파일의 복제 연결 섹션이 Cloud SQL VPC의 IP 주소 범위의 연결을 수락하도록 업데이트되었는지 확인하세요.

Cloud Logging

Database Migration Service 및 Cloud SQL은 Cloud Logging을 사용합니다. 자세한 내용은 Cloud Logging 문서를 참조하고 Cloud SQL 샘플 쿼리를 검토하세요.

로그 보기

Cloud SQL 인스턴스와 Cloud VPN 또는 Compute Engine 인스턴스와 같은 Google Cloud 기타 프로젝트의 로그를 볼 수 있습니다. Cloud SQL 인스턴스 로그 항목의 로그를 보려면 다음 안내를 따르세요.

콘솔

1. 로그 탐색기로 이동
2. 페이지 상단에서 기존 Cloud SQL 프로젝트를 선택합니다.
3. 쿼리 빌더에서 다음을 추가합니다.
• 리소스: Cloud SQL Database를 선택합니다. 대화상자에서 Cloud SQL 인스턴스를 선택합니다.
• 로그 이름: Cloud SQL 섹션으로 스크롤하고 인스턴스에 적합한 로그 파일을 선택합니다. 예를 들면 다음과 같습니다.
  • cloudsql.googleapis.com/postgres.log
• 심각도: 로그 수준을 선택합니다.
• 기간: 미리 설정을 선택하거나 커스텀 범위를 만듭니다.

gcloud

gcloud logging 명령어를 사용하여 로그 항목을 볼 수 있습니다. 아래 예시에서 PROJECT_ID를 바꿉니다. limit 플래그는 반환할 최대 항목 수를 나타내는 선택적 매개변수입니다.

gcloud logging read "projects/[PROJECT_ID]/logs/cloudsql.googleapis.com/postgres.log" --limit=10

비공개 IP 주소

비공개 IP 주소를 사용하는 Cloud SQL 인스턴스에 대한 연결은 RFC 1918 주소 범위에서 자동으로 승인됩니다. RFC 1918 이외의 주소 범위는 Cloud SQL에서 승인된 네트워크로 구성해야 합니다. 또한 RFC 1918 이외의 경로를 내보내려면 네트워크 피어링을 Cloud SQL로 업데이트해야 합니다. 예를 들면 gcloud compute networks peerings update cloudsql-postgres-googleapis-com --network=NETWORK --export-subnet-routes-with-public-ip --project=PROJECT입니다.

IP 범위 172.17.0.0/16은 Docker 브리지 네트워크에 예약되어 있습니다. 이 범위 내 IP 주소로 생성된 Cloud SQL 인스턴스에는 연결할 수 없습니다. 이 범위 내 IP 주소로부터 비공개 IP 주소를 사용하는 Cloud SQL 인스턴스로는 연결할 수 없습니다.

VPN 문제 해결

Google Cloud Cloud VPN 문제 해결 페이지를 참고하세요.

역방향 SSH 터널 문제 해결

SSH 터널링은 SSH 연결을 기반으로 일부 통신을 전달하는 방법입니다. 역방향 SSH 터널링을 사용하면 SSH 터널을 설정할 수 있지만 대상 네트워크가 터널 연결을 시작하는 네트워크로 유지됩니다. 이는 보안상의 이유로 자체 네트워크에서 포트를 열지 않으려는 경우에 유용합니다.

다음을 설정하는 것이 목표입니다. Cloud SQL DB ---> Compute Engine VM bastion ---> tunnel ---> source network bastion ---> source DB

Database Migration Service는 소스에서 대상으로 데이터를 마이그레이션하지만, 대상에서 소스로의 연결은 사용 설정해야 합니다.

다음 사항이 가정됩니다.

• Compute Engine VM bastion는 Cloud SQL DB에 액세스할 수 있습니다.

• source network bastion는 source DB에 액세스할 수 있습니다 (Cloud SQL 네트워크를 Compute Engine VM 네트워크에 피어링하여 실행).

그런 다음 source network bastion에서 Compute Engine VM bastion로 SSH 터널을 설정합니다. 그러면 수신 연결이 터널을 통해 Compute Engine VM bastion의 일부 포트에서 source DB로 라우팅됩니다.

위 시나리오의 각 링크가 잘못 설정되어 전체 흐름이 작동하지 않을 수 있습니다. 각 링크를 하나씩 문제 해결합니다.

source network bastion ---> source DB

1. SSH를 사용하여 source network bastion에 연결하거나 로컬 머신인 경우 터미널에서 연결합니다.
2. 다음 방법 중 하나를 사용하여 소스 DB에 대한 연결을 테스트합니다.
   • telnet [source_db_host_or_ip] [source_db_port] - Connected to x.x.x.x로 끝나는 telnet 연결 문자열이 표시됩니다.
   • [db_client] -h[source_db_host_or_ip] -P[source_db_port] - 액세스가 거부될 것으로 예상됨

실패하면 이 배스천에서 소스 DB에 대한 액세스를 사용 설정했는지 확인해야 합니다.

Compute Engine VM bastion ---> source DB

1. Compute Engine VM bastion에 SSH 연결 (gcloud compute ssh VM_INSTANCE_NAME 사용)
2. 다음 방법 중 하나를 사용하여 소스 DB에 대한 연결을 테스트합니다.
   • telnet 127.0.0.1 [tunnel_port] - Connected to x.x.x.x로 끝나는 telnet 연결 문자열이 표시됩니다.
   • [db_client] -h127.0.0.1 -P[tunnel_port] - 액세스가 거부될 것으로 예상됨

이 작업이 실패하면 터널이 제대로 작동하는지 확인해야 합니다. sudo netstat -tupln를 실행하면 이 VM의 모든 수신 대기 프로세스가 표시되고 sshd listening on the tunnel_port가 표시됩니다.

Cloud SQL DB ---> source DB

이는 Database Migration Service의 testing the migration job를 사용하여 테스트하는 것이 가장 좋습니다. 이 작업이 실패하면 Cloud SQL 네트워크와 Compute Engine VM bastion 네트워크 간에 VPC 피어링 또는 라우팅에 문제가 있는 것입니다.

Cloud SQL 대상 인스턴스가 ipConfiguration 설정의 privateNetwork 필드로 사용할 VPC 네트워크의 비공개 서비스 연결에 할당된 전체 내부 IP 범위를 허용하도록 소스 데이터베이스 서버의 방화벽을 구성해야 합니다.

콘솔에서 내부 IP 범위를 찾으려면 다음 안내를 따르세요.

1. Google Cloud 콘솔에서 VPC 네트워크 페이지로 이동합니다.

2. 사용할 VPC 네트워크를 선택합니다.

3. 비공개 서비스 연결 탭을 선택합니다.

Cloud VPN gateway 프로젝트의 Cloud Logging 콘솔에서 Cloud SQL 인스턴스와 Compute Engine VM 인스턴스 간의 트래픽을 볼 수도 있습니다. Compute Engine VM 로그에서 Cloud SQL 인스턴스에서 발생한 트래픽을 찾습니다. Cloud SQL 인스턴스의 로그에서 Compute Engine VM의 트래픽을 찾습니다.