게시일: 2023년 8월 15일
기고자: Michael Goodwin
지연 시간은 시스템의 지연을 측정한 값입니다. 네트워크 지연 시간이란 데이터가 네트워크를 통해 한 지점에서 다른 지점으로 이동하는 데 걸리는 시간을 말합니다. 지연 시간이 긴 네트워크는 응답 시간이 느리고, 지연 시간이 짧은 네트워크는 응답 시간이 빠릅니다.
원칙적으로 데이터는 빛의 속도에 가까운 속도로 인터넷을 통과해야 하지만 실제로는 거리, 인터넷 인프라 및 기타 변수로 인한 지연 때문에 데이터 패킷이 약간 느린 속도로 인터넷을 통과하게 됩니다.1 이러한 시간 지연을 합한 것이 네트워크 지연 시간입니다.
APM과 ARM이 더 빠른 의사 결정과 리소스 활용을 지원하는 방법을 알아보세요.
지능형 자동화 가이드 읽기
지연 시간은 생산성, 협업, 애플리케이션 성능 및 사용자 경험에 직접적인 영향을 미치기 때문에 지연 시간이 짧은 네트워크를 유지하는 것이 중요합니다. 지연 시간이 길수록(그리고 응답 시간이 느릴수록) 생산성, 협업, 애플리케이션 성능 및 사용자 경험에 더 많은 영향을 미치게 됩니다. 기업이 디지털 혁신을 추구하고 사물인터넷에서 클라우드 기반 애플리케이션과 서비스에 대한 의존도가 점점 더 높아지면서 짧은 지연 시간은 특히 중요해졌습니다.
확실한 예시부터 살펴보겠습니다. 네트워크 지연 시간이 길어 애플리케이션 성능이 저하되거나 로딩 시간이 느려지면 클라이언트는 대체 솔루션을 찾을 가능성이 높습니다. 오늘날 개인 사용자와 기업 사용자들은 모두 그 어느 때보다 빠른 성능을 기대하고 있습니다. 조직에서 리소스 추천을 위해 다양한 소스에서 가져온 실시간 데이터에 의존하는 엔터프라이즈 애플리케이션을 사용하고 있는 경우 지연 시간이 길어지면 비효율성이 초래될 수 있습니다. 이러한 비효율성은 애플리케이션의 성능과 가치에 부정적인 영향을 미칠 수 있습니다.
모든 기업은 짧은 지연 시간을 선호합니다. 그러나 자동화된 제조, 동영상 지원 원격 작업(수술에 사용되는 카메라 등), 라이브 스트리밍 또는 고빈도 거래와 같이 센서 데이터 또는 고성능 컴퓨팅에 의존하는 산업 및 사용 사례에서는 짧은 지연 시간은 성공에 있어 필수 요소입니다.
지연 시간이 길면 비용 낭비가 발생할 수도 있습니다. 컴퓨팅, 스토리지 및 네트워크 리소스 지출을 늘리거나 재할당하여 애플리케이션 및 네트워크 성능을 개선하고자 한다고 가정해 봅시다. 기존의 지연 시간 문제를 해결하지 못하면 성능, 생산성, 고객 만족도를 개선하지 못한 채 더 큰 비용만 지출하게 될 수 있습니다.
네트워크 지연 시간은 소스 시스템에서 전송 작업이 시작될 때와 대상 시스템에서 해당 수신 작업이 완료될 때까지의 시간 간격을 계산하여 밀리초 단위로 측정됩니다.2
지연 시간을 측정하는 간단한 방법 중 하나는 두 디바이스 또는 서버 간의 연결을 테스트하는 데 사용되는 네트워크 진단 툴인 'ping' 명령을 실행하는 것입니다. 이러한 속도 테스트에서 지연 시간을 흔히 핑 속도라고 합니다.
이 테스트에서는 ICMP(인터넷 제어 메시지 프로토콜) 에코 요청 패킷이 대상 서버로 전송되고 반환됩니다. 핑 명령은 패킷이 소스에서 대상으로 이동하고 다시 돌아오는 데 걸리는 시간을 계산합니다. 이 총 이동 시간을 RTT(왕복 시간)라고 하며, 데이터가 서버로 이동했다가 다시 돌아오는 시간이므로 지연 시간의 약 2배에 해당합니다. 핑은 지연 시간을 정확하게 측정하거나 방향성 네트워크 지연 시간 문제를 감지하는 데 이상적인 테스트는 아닙니다. 데이터가 여러 네트워크 경로를 통해 이동할 수 있으며 각 이동 구간에서 다양한 시나리오에 직면할 수 있기 때문입니다.
지연 시간과 대역폭 및 처리량은 서로 연관되어 있으며 때때로 동의어로 혼동되기도 합니다. 그러나 실제로는 서로 다른 네트워크 기능을 나타냅니다. 앞서 언급했듯이 지연 시간은 네트워크 연결을 통해 데이터 패킷이 두 지점 사이를 이동하는 데 걸리는 시간을 말합니다.
대역폭은 주어진 시간에 네트워크를 통과할 수 있는 데이터의 양을 측정하는 척도입니다. 초당 메가비트(mbps) 또는 초당 기가비트(gbps)와 같은 초당 데이터 단위로 측정됩니다. 이 측정값은 가정에서 연결 옵션을 선택할 때 서비스 제공업체로부터 익숙하게 들어왔던 수치입니다. 대역폭은 속도를 측정하는 것이 아니라 용량을 측정하는 것이기 때문에 큰 혼란의 원인이 될 수 있습니다. 대역폭이 높으면 인터넷 속도가 빨라질 수 있지만, 이러한 성능은 지연 시간 및 처리량 등의 요소에 따라 달라집니다.
처리량은 지연 시간의 영향을 고려하여 특정 시간대에 네트워크를 실제로 통과하는 데이터의 평균 양을 측정한 것입니다. 성공적으로 도착한 데이터 패킷 수와 데이터 패킷 손실량을 반영하며, 일반적으로 초당 비트 도는 초당 데이터로 측정됩니다.
네트워크 성능의 또 다른 요소는 지터입니다. 지터는 네트워크에서 패킷 흐름의 지연 시간 변화를 나타냅니다. 높은 지터보다는 일관된 지연 시간이 더 좋습니다. 지터가 높으면 전송 중에 데이터 패킷이 누락되어 목적지에 도착하지 못하는 패킷 손실을 초래할 수 있기 때문입니다.
지연 시간, 대역폭, 처리량 간의 관계를 기억하기 쉽도록 간결하게 정리하자면 대역폭은 네트워크를 통해 이동할 수 있는 데이터의 양, 처리량은 초당 실제로 전송되는 양, 지연 시간은 전송에 걸리는 시간이라고 할 수 있습니다.
데이터가 클라이언트에서 서버로 이동하는 과정을 시각화하면 지연 시간 및 이에 영향을 미치는 다양한 요인을 이해하는 데 도움이 됩니다. 네트워크 지연 시간에 영향을 미치는 일반적인 요인은 다음과 같습니다.
간단히 설명하자면, 요청을 시작하는 클라이언트와 응답하는 서버 사이의 거리가 멀수록 지연 시간이 길어집니다. 로스앤젤레스에 있는 사용자 요청에 응답하는 시카고 서버와 뉴욕 서버의 지연 시간은 불과 몇 밀리초밖에 차이가 나지 않을 수 있습니다. 그러나 이러한 밀리초의 지연 시간이 합산되어 큰 영향을 미칠 수 있습니다.
다음으로 데이터가 이동하는 매체를 고려하세요. 광섬유 케이블 네트워크(일반적으로 지연 시간이 짧음)인가요, 무선 네트워크(일반적으로 지연 시간이 김)인가요, 아니면 여러 매체가 있는 복잡한 네트워크 웹인가요?
데이터 이동에 사용되는 매체는 지연 시간에 영향을 미칩니다. 데이터가 목적지에 도달하기 전에 한 네트워크 세그먼트에서 다음 네트워크 세그먼트로 이동(즉, 네트워크 홉)하기 위해 라우터와 같은 네트워크 디바이스를 통과해야 하는 횟수도 마찬가지로 영향을 미칩니다. 홉 수가 많을수록 지연 시간이 길어집니다.
데이터 패킷의 크기와 네트워크의 전체 데이터 양은 모두 지연 시간에 영향을 미칩니다. 패킷이 클수록 전송하는 데 시간이 오래 걸리며, 데이터 양이 네트워크 인프라의 컴퓨팅 용량을 초과하면 병목 현상이 발생하고 지연 시간이 늘어날 수 있습니다.
오래되었거나 리소스가 부족한 서버, 라우터, 허브, 스위치 및 기타 네트워크 하드웨어로 인해 응답 시간이 느려질 수 있습니다. 예를 들어, 서버가 처리할 수 있는 것보다 많은 데이터를 수신하면 패킷이 지연되어 페이지 로딩 및 다운로드 속도가 느려지고 애플리케이션 성능이 저하될 수 있습니다.
파일 크기가 큰 이미지 및 동영상과 같은 페이지 자산, 렌더링을 방해하는 리소스, 소스 코드 내 불필요한 문자 등은 모두 지연 시간을 증가시키는 원인이 될 수 있습니다.
대역폭 부족, 인터넷 연결 상태 불량, 오래된 장비 등 사용자 측 요인으로 인해 지연 시간이 발생하는 경우도 있습니다.
네트워크 지연 시간을 줄이려면 다음과 같은 네트워크 평가부터 시작해보세요.
- 데이터가 가장 효율적인 경로를 따라 이동하고 있나요?
- 애플리케이션이 최적의 성능을 발휘하는 데 필요한 리소스를 확보하고 있나요?
- 네트워크 인프라가 최신 상태이며 업무에 적합한가요?
거리 관련 문제부터 다뤄보겠습니다. 사용자의 위치는 어디인가요? 그리고 이 사용자의 요청에 응답하는 서버는 어디에 있나요? 서버와 데이터베이스를 사용자와 지리적으로 가까운 곳에 분산 배치하면 데이터가 이동해야 하는 물리적 거리를 줄이고 비효율적인 라우팅과 네트워크 홉을 줄일 수 있습니다.
데이터를 전 세계에 배포하는 한 가지 방법은 콘텐츠 전송 네트워크(CDN)를 사용하는 것입니다. 분산 서버 네트워크를 사용하면 최종 사용자와 더 가까운 곳에 콘텐츠를 저장할 수 있어 데이터 패킷이 이동해야 하는 거리를 줄일 수 있습니다. 하지만 캐시된 콘텐츠를 제공하는 것 이상의 서비스를 제공하려면 어떻게 해야 할까요?
엣지 컴퓨팅은 조직이 클라우드 환경을 코어 데이터 센터에서 사용자 및 데이터와 더 가까운 물리적 위치로 확장할 수 있는 유용한 전략입니다. 조직은 엣지 컴퓨팅을 통해 최종 사용자와 더 가까운 곳에서 애플리케이션을 실행하고 지연 시간을 줄일 수 있습니다.
서브넷은 기본적으로 네트워크 내부의 더 작은 네트워크라고 할 수 있습니다. 서브넷은 서로 자주 통신하는 엔드포인트를 함께 그룹화하여 비효율적인 라우팅을 줄이고 지연 시간을 단축할 수 있습니다.
기존의 모니터링 툴은 오늘날의 복잡한 환경에서 성능 문제를 사전에 발견하고 맥락에 맞게 파악할 수 있을 만큼 빠르거나 꼼꼼하지 않습니다. 문제를 미리 파악하려면 실시간 엔드투엔드 관측성 및 종속성 매핑을 제공하는 InInstana Observability 플랫폼과 같은 솔루션을 사용할 수 있습니다. 팀은 이러한 기능을 통해 네트워크 지연을 유발하는 애플리케이션 성능 문제를 정확히 찾아내 상황을 파악하고 해결하여 미리 예방할 수 있습니다.
워크로드에 적절한 컴퓨팅, 스토리지 및 네트워크 리소스가 없는 경우 지연 시간이 증가하고 성능이 저하됩니다. 이 문제를 오버프로비저닝으로 해결하려는 시도는 비효율적이고 소모적입니다. 또한 복잡한 최신 인프라에서 동적 수요와 리소스를 수동으로 매칭하려는 시도는 사실상 불가능한 작업입니다.
리소스 사용률과 애플리케이션 및 인프라 구성 요소의 성능을 지속적으로 실시간 분석하는 IBM Turbonomic 플랫폼과 같은 애플리케이션 리소스 관리 솔루션은 리소스 문제를 해결하고 지연 시간을 줄이는 데 도움이 될 수 있습니다.
예를 들어, IBM Turbonomic 플랫폼이 서버에서 리소스 경합으로 인해 지연 시간이 긴 애플리케이션을 감지하면 지연 시간을 줄일 수 있습니다. IBM Turbonomic 플랫폼은 애플리케이션에 필요한 리소스를 자동으로 할당하거나 혼잡도가 낮은 서버로 이동하여 지연 시간을 줄입니다.
ping 명령과 같은 테스트는 네트워크 지연 시간을 간단하게 측정할 수 있지만 문제를 정확히 파악하고 해결하기에는 충분하지 않습니다. 팀이 네트워크 성능 문제를 발견, 해결, 예방하고 지연 시간을 줄이는 데 도움이 되는 통합 플랫폼을 제공하는 IBM SevOne NPM과 같은 네트워크 성능 관리 솔루션을 사용할 수 있습니다.
최신 하드웨어, 소프트웨어 및 네트워크 구성을 사용하고 있는지, 그리고 인프라가 요구 사항을 처리할 수 있는지 확인하세요. 네트워크에 대한 정기적인 점검과 유지보수를 수행하면 성능 문제를 줄이고 지연 시간을 단축하는 데 도움이 됩니다.
개발자는 동영상, 이미지 및 기타 페이지 자산을 최적화하여 로딩 속도를 높이고 코드를 최소화하는 등 페이지 구성이 지연 시간을 증가시키지 않도록 조치를 취할 수 있습니다.
IBM Instana Observability 플랫폼은 자동화된 풀 스택 가시성, 1초 단위의 세분성, 3초 내 알림 등 향상된 애플리케이션 성능 모니터링을 제공합니다.
Turbonomic 하이브리드 클라우드 비용 최적화 플랫폼을 사용하면 중요한 작업을 실시간으로, 지속적으로 자동화하여 스택의 모든 레이어에서 앱에 컴퓨팅, 스토리지 및 네트워크 리소스를 가장 효율적으로 사용할 수 있도록 선제적으로 제공할 수 있습니다.
최신 네트워크용으로 설계된 IBM SevOne Network Performance Management(NPM)는 하이브리드 클라우드 네트워크 관측성을 통해 네트워크 성능 문제를 조기에 발견, 해결 및 예방할 수 있도록 지원합니다.
역동적이고 유연하며 확장 가능한 최신 NPM 기능의 이점을 누려 보세요.
네트워크 및 애플리케이션 가시성, 인사이트 및 조치를 위한 고급 기능에 대해 알아보세요.
네트워크 운영자와 엔지니어가 최신 IT 환경에서 실제로 요구되는 것과 비교하여 네트워크 성능 관리 기능을 신속하게 측정할 수 있는 5가지 단계에 대해 알아보세요.
북유럽의 선도적인 신용 정보 제공업체가 버그를 신속하게 식별하고 기존의 지연을 줄이며 샘플링 없이 모든 서비스 요청을 실시간으로 파악하기 위해 Instana Observability를 어떻게 사용했는지 알아보세요.
Dealerware의 DevOps 팀이 폭발적인 성장 기간 동안 Instana Observability를 사용하여 전송 지연 시간을 98%까지 단축한 방법을 알아보세요.