애플리케이션 문제인가, 네트워크 문제인가? 성능 저하의 진짜 원인 찾기

월요일 오전 9시 02분입니다.
커피를 한 모금도 마시지 않은 순간 전화가 울립니다.

"응용 프로그램이 너무 느려서 아무것도 할 수가 없어요!"

당신은 행동에 뛰어든다. network 팀 대시보드를 확인합니다. 모두 녹색이고 패킷 손실이 없으며 지연 시간이 낮습니다. 애플리케이션 팀 코드가 꿈처럼 잘 실행되고 데이터베이스도 즐겁게 돌아가고 있다고 맹세합니다.

이제 고전적인 대립이 시작됩니다.
손가락질만 당하고, 회의 일정은 정해졌지만, 아무도 만족하지 않습니다.

IT 업계에서 일주일 이상 일해 보셨다면 아마 이런 상황을 겪어 보셨을 겁니다. 문제는 말하기는 간단하지만 해결하기는 어렵습니다.

애플리케이션 문제인가요, 아니면 다른 문제인가요? network?

이런 일이 왜 자주 일어나는가

모든 클라이언트-서버 애플리케이션은 두 가지가 조화롭게 작동하는 데 달려 있습니다.

1. 애플리케이션 자체 – 요청을 얼마나 빨리 처리하는지.
2. The network – 클라이언트와 서버 사이에서 데이터가 얼마나 효율적으로 전송되는지.

둘 중 하나라도 느려지면 사용자는 통증을 느낍니다. 하지만 겉으로 보기에는 둘 다 "건강해" 보일 수 있습니다. 더 깊이 파고들기 전까지는요.

애플리케이션의 오류인 경우

애플리케이션 측 병목 현상은 서버 내부 또는 서버 종속성에서 발생합니다. 이러한 병목 현상은 주로 다음과 같은 원인으로 인해 발생합니다.

• 비효율적인 코드(느린 쿼리, 차단된 I/O, 불량한 스레드 처리)
• 리소스 고갈(CPU, 메모리 또는 디스크가 최대치에 도달)
• 데이터베이스 잠금 경합(동일한 데이터를 놓고 너무 많은 프로세스가 경쟁)

발견 방법:

• 네트워크 지표가 괜찮아 보입니다. 패킷이 빠르게 도착합니다.
• 속도가 느려지는 것은 서버가 요청을 받고 첫 번째 바이트를 다시 보내기 전입니다.
• TCP 핸드셰이크는 빠르지만 애플리케이션 응답 시간(ART) 길다.

네트워크의 잘못일 때

네트워크 측 병목 현상은 클라이언트와 서버 간 연결 과정에서 발생합니다. 일반적인 원인은 다음과 같습니다.

• 높은 지연 시간(장거리 또는 너무 많은 홉)
• 혼잡(링크 용량에 비해 트래픽이 너무 많음)
• 패킷 손실/재전송(TCP 재전송 강제)
• 잘못된 구성(듀플렉스 불일치, 불량 QoS, 깨진 라우팅)

발견 방법:

• 서버는 빠르게 응답하지만, 데이터는 클라이언트로 크롤링됩니다.
• 패킷 캡처는 재전송, 순서가 잘못된 패킷 또는 긴 패킷을 보여줍니다. 첫 번째 바이트까지의 시간(TTFB).

실제 문제: 분산된 가시성

이런 전투가 계속되는 이유는 무엇일까?

• 애플리케이션 팀 APM 도구를 사용하세요. 서버를 들여다보기에는 좋지만, 네트워크에서 무슨 일이 일어나고 있는지는 알 수 없습니다.
• 네트워크 팀 SNMP와 대역폭 그래프를 사용하세요. 전반적인 상태 파악에는 좋지만 세션별 세부 정보 파악에는 쓸모가 없습니다.

마치 두 명의 형사가 같은 범죄를 해결하려고 하는 것과 같습니다. 각자가 단서의 절반만을 가지고 있는 셈이죠.

더 나은 방법: 모든 것을 보세요

교착 상태를 끝내려면 다음이 필요합니다. 전체 패킷 수준 가시성 모든 클라이언트-서버 대화에 포함됩니다.

그것이 바로 NEOX Networks 접근 들어 온다:

1. 충격 없이 캡처

• Network TAPs 모두 복사하려면 network 지연 시간을 추가하거나 패킷 손실을 발생시키지 않고 트래픽을 처리합니다.
• 부하가 걸리면 패킷을 놓칠 수 있고 잘못된 보안 인식을 줄 수 있는 SPAN 포트는 피하세요.

2. 올바른 데이터를 올바른 도구로 전송

• Network Packet Brokers 각 도구에 필요한 기능(성능 분석기, 보안 어플라이언스 등)을 제공하도록 트래픽을 필터링하고 직접 전달합니다.

3. 법의학적 기록을 보관하세요

• Packet Capture 가전​​ 제품 대량의 패킷을 저장하여 "시간을 되돌려" 속도 저하 중에 정확히 무슨 일이 일어났는지 확인할 수 있습니다. 추측이나 비난 없이요.

이러한 사항이 적용되면 다음을 확인할 수 있습니다.

• TCP 핸드셰이크가 발생한 정확한 시점입니다.
• 서버가 응답하는 데 걸리는 시간.
• 전송 중에 재전송이나 이상이 발생하는 경우.

비난 게임에서 문제 해결로

"적용 vs. network"논쟁은 시간을 낭비하고, 팀을 좌절시키며, 문제 해결을 지연시킨다."

양측이 모두 동일한 패킷 수준의 진실을 볼 수 있게 되면 대화가 달라집니다.
더 이상 그게 아니야 누구의 잘못인가 — 그것은에 관한 것입니다 진짜 무슨 일이 일어나고 있는 거야 그리고 이를 빠르게 해결하는 방법.

결국 사용자들은 앱인지 아닌지 신경 쓰지 않기 때문입니다. network — 그들은 그저 제대로 작동하기를 바랄 뿐입니다. 그리고 모든 상황을 투명하게 확인할 수 있다면, 제대로 작동하는지 확인할 수 있습니다.