네트워크 문제의 논리적 추론

클래식 케이스 1

많은 소프트웨어 전문가들은 TCP/IP 논리 추론에 대한 심층적인 지식이 부족하여 종종 문제를 신비한 문제로 오인하는 경우가 있습니다. TCP/IP 네트워킹 문헌의 복잡성에 의해 낙담하는 사람도 있고, Wireshark의 혼란스러운 세부 사항에 속아 속일 수도 있습니다. 예를 들어, 성능 문제에 직면한 DBA는 Wireshark의 패킷 캡처 데이터를 잘못 해석하여 TCP 재전송이 원인이라고 잘못 결론을 내릴 수 있습니다.

재전송이 의심되는 경우, 그 성질을 이해하는 것이 중요합니다. 재전송은 기본적으로 타임아웃 재전송을 포함합니다. 재전송이 실제로 원인인지 확인하려면 타임 관련 정보가 필요한데, 이는 위의 스크린샷에서 제공되지 않습니다. DBA로부터 새로운 스크린샷을 요청한 후 타임스탬프 정보가 포함되었습니다.

네트워크 패킷을 분석할 때 타임스탬프 정보는 정확한 논리 추론을 위해 중요합니다. 두 복제 패킷 사이의 밀리초 범위의 시간 차이는 타임아웃 재전송이나 복제 패킷 캡처를 시사합니다. 전형적인 LAN 환경에서 라운드트립 타임(RTT)이 약 100 마이크로초인 경우, TCP 재전송은 적어도 하나의 RTT를 필요로 합니다. RTT의 1/100에서 발생하는 재전송은 실제 타임아웃 재전송이 아닌 복제 패킷 캡처를 나타낼 가능성이 높습니다.

클래식 케이스 2

네트워크 문제 분석에서 논리 추론의 중요성을 보여주는 또 다른 클래식 케이스입니다.

어느 날, 한 비즈니스 개발자가 다가와 예약된 MySQL 데이터베이스 미들웨어를 사용하는 스크립트가 새벽에 응답이 없이 실패했다고 말했습니다. 문제에 대해 듣자마자, 나는 MySQL 데이터베이스 미들웨어의 오류 로그를 확인했지만 가치 있는 단서를 찾지 못했습니다. 그래서 나는 개발자들에게 문제를 재현할 수 있는지 물었고, 한번 재현되면 문제 해결이 더 쉬워진다는 것을 알고 있었습니다.

개발자들은 여러 차례 시도했지만 문제를 재현하는 데 실패했습니다. 그러나 새로운 발견을 했습니다: 동일한 SQL 쿼리를 주간에 실행할 때 새벽과는 다른 응답 시간이 나타났습니다. SQL 응답이 느릴 때 MySQL 데이터베이스 미들웨어가 세션을 차단하고 클라이언트에 결과를 반환하지 않았을 것으로 의심했습니다.

이 통찰을 바탕으로 데이터베이스 운영팀은 스크립트의 SQL을 수정하여 느린 SQL 응답을 모방하도록 했습니다. 결과적으로 MySQL 데이터베이스 미들웨어는 새벽에 발생한 문제와 같은 중단 문제가 발생하지 않고 결과를 반환했습니다.

어느 정도의 시간이 지난 후에도 원인을 찾지 못했고, 개발자들은 MySQL 데이터베이스 미들웨어의 기능적 문제를 발견했습니다. 따라서 개발자들과 DBA 운영팀은 MySQL 데이터베이스 미들웨어가 응답을 지연시킨다는 것에 더 확신을 갖기 시작했습니다. 실제로 이러한 문제들은 MySQL 데이터베이스 미들웨어의 응답 시간과 관련이 없었습니다.

첫날의 사건으로부터 문제가 실제로 발생했습니다. 관련된 모든 사람들은 원인을 규명하려고 노력하며 다양한 추측을 했지만, 진짜 원인은 잡히지 않았습니다.

다음 날, 개발자들은 스크립트 문제가 이른 아침에 다시 발생했다고 보고했지만, 낮 동안에는 재현할 수 없었습니다. 스크립트가 곧 온라인에서 사용될 예정이었기 때문에 개발자들은 압박감을 느끼며 상황에 대해 불평했습니다. 제가 제안한 유일한 방법은 낮 시간 동안 스크립트를 사용하여 이른 아침의 문제를 피하는 것이었습니다. 모든 의심이 MySQL 데이터베이스 미들웨어에 집중되면서, 다른 관점에서 문제를 분석하기가 어려웠습니다.

MySQL 데이터베이스 미들웨어를 담당하는 개발자로서, 이러한 신비로운 문제는 쉽게 간과할 수 없습니다. 이를 무시하면 MySQL 데이터베이스 미들웨어의 후속 사용에 영향을 미칠 수 있으며, 문제를 신속하게 해결하라는 리더십의 압박도 있습니다. 결국, 저비용 패킷 캡처 분석 솔루션을 구현하기로 결정되었습니다: 이른 아침에 스크립트를 실행하는 동안 서버에서 패킷 캡처를 수행하여 그 당시 발생한 일을 분석하는 것입니다. 목표는 MySQL 데이터베이스 미들웨어가 응답을 전혀 보내지 않았는지, 아니면 클라이언트 스크립트가 수신하지 못한 응답을 보냈는지를 확인하는 것이었습니다. MySQL 데이터베이스 미들웨어가 응답을 보냈다는 것이 확인되면, 문제는 MySQL 데이터베이스 미들웨어 개발자에게 귀속되지 않을 것입니다.

세 번째 날 개발자들은 이른 아침 문제가 재발하지 않았고, 패킷 캡처 분석을 통해 문제가 발생하지 않았음이 확인되었습니다. 신중한 고려 끝에 MySQL 데이터베이스 미들웨어만 문제인 것은 아닌 것으로 보였습니다: 이른 아침에 빈번히 발생하고 낮에는 드물게 발생하는 것이 의아했습니다. 유일한 대책은 문제가 다시 발생할 때까지 기다리고 패킷 캡처를 기반으로 분석하는 것이었습니다.

네 번째 날, 문제는 다시 발생하지 않았습니다.

그러나 다섯 번째 날, 문제가 마침내 다시 나타나며 해결의 희망을 가져왔습니다.

패킷 캡처 파일이 많습니다. 먼저 개발자들에게 문제가 발생한 타임스탬프를 제공하도록 요청한 다음, 방대한 패킷 캡처 데이터를 검색하여 문제를 일으킨 SQL 쿼리를 식별합니다. 최종 결과는 다음과 같습니다:

위의 패킷 캡처 내용(서버에서 캡처)으로 보아 SQL 쿼리가 새벽 3시에 전송되었습니다. MySQL 데이터베이스 미들웨어는 SQL 응답을 클라이언트로 반환하는 데 630초 (03:10:30.899249-03:00:00.353157)가 걸렸으며, MySQL 데이터베이스 미들웨어가 실제로 SQL 쿼리에 응답했음을 나타냅니다. 그러나 단 238 마이크로초 후 (03:10:30.899487-03:10:30.899249), 서버의 TCP 계층이 의심스럽게 빠른 재설정 패킷을 수신했습니다. 이 재설정 패킷이 클라이언트로부터 즉시 유추될 수는 없다는 점이 중요합니다.

우선, 재설정 패킷을 보낸 사람이 누구인지 확인하는 것이 필요합니다. 이 패킷이 클라이언트에 의해 보내졌는지 또는 중간 장치를 통해 전송되었는지를 확인해야 합니다. 패킷 캡처는 서버 측에서만 수행되었으므로, 클라이언트의 패킷 상황에 대한 정보는 없습니다. 서버 측에서 패킷 캡처 파일을 분석하고 논리적 추론을 적용하여 문제의 근본 원인을 식별하는 것이 목표입니다.

만약 클라이언트가 재설정을 보냈다는 가정을 한다면, 이는 클라이언트의 TCP 레이어가 이 연결의 TCP 상태를 더 이상 인식하지 못한다는 것을 의미합니다. 이는 설정된 상태에서 존재하지 않는 상태로 전환됩니다. 이 TCP 상태 변화로 인해 클라이언트 응용 프로그램에 연결 문제가 통보되어 클라이언트 스크립트가 즉시 오류를 발생시킵니다. 그러나 실제로 클라이언트 스크립트는 여전히 응답이 돌아올 것을 기다리고 있습니다. 따라서 클라이언트가 재설정을 보냈다는 가정은 옳지 않습니다. 클라이언트의 연결은 여전히 활성 상태이지만, 서버 측에서 해당 연결은 재설정으로 종료되었습니다.

그렇다면 누가 재설정을 보냈을까요? 주요 용의자는 아마존의 클라우드 환경입니다. 이 패킷 캡처 분석을 바탕으로 DBA 운영팀은 아마존 고객 서비스에 문의하여 다음 정보를 받았습니다:

고객 서비스의 응답은 분석 결과와 일치하여, 아마존의 ELB(Elastic Load Balancer, LVS와 유사함)가 TCP 세션을 강제로 종료했다는 것을 나타냅니다. 그들의 피드백에 따르면, 응답 시간이 350초 임계값을 초과하면(패킷 캡처에서 630초로 확인됨), 아마존의 ELB 장치가 응답하는 쪽(이 경우 서버)에 재설정을 보냅니다. 개발자들이 배포한 클라이언트 스크립트는 재설정을 받지 않아 서버 연결이 여전히 활성화되어 있다고 잘못 가정했습니다. 이러한 문제에 대한 공식 권장 사항은 이러한 문제를 완화하기 위해 TCP keepalive 메커니즘을 사용하는 것을 포함합니다.

공식 응답을 받은 후 문제는 완전히 해결되었습니다.

이 구체적인 사례는 온라인 문제가 매우 복잡할 수 있으며, 상황을 이해하기 위해 중요한 정보(이 경우 패킷 캡처 데이터)를 포착해야 하는 것을 보여줍니다. 논리적 추론과 극단적 축소법의 적용을 통해 근본 원인이 확인되었습니다.