지연시간 (Latency)
요청이 처리되길 기다리는 시간
인용
From: 브라이언 커니핸
레이턴시latency 또는 지연delay은 일정한 단위의 정보가 시스템을 통과하는 데 걸리는 시간을 측정한 값이다. 레이턴시가 높다고 반드시 대역폭이 낮음을 의미하는 것은 아니다. 트럭에 디스크 드라이브를 가득 싣고 전국을 가로질러 운전한다고 하면 지연은 높아도 대역폭은 어마어마할 것이다. 1
From: 데이터 중심 애플리케이션 설계
지연 시간(latency)과 응답 시간(response time)
지연 시간과 응답 시간을 종종 같은 뜻으로 사용하지만 동일하지는 않다. 응답 시간은 클라이언트 관점에서 본 시간으로, 요청을 처리하는 실제 시간(서비스 시간) 외에도 네트워크 지연과 큐 지연도 포함한다. 지연 시간은 요청이 처리되길 기다리는 시간으로, 서비스를 기다리며 휴지(latent) 상태인 시간을 말한다. 2
From: 러닝 HTTP/2
지연 시간이란 IP 패킷이 한 지점에서 다른 지점으로 이동하는 데 걸리는 시간을 말한다. 이와 관련된 것으로 왕복 시간(Round-Trip Time, RTT)이라는 것이 있으며, 지연 시간의 2배를 의미한다. 지연 시간은 성능의 주요 병목점이며, 서버까지 많은 왕복이 이루어지는 HTTP와 같은 프로토콜에서 특히 더 그러하다. 3
지연 시간에 영향을 미치는 요인은 많지만, 그중 가장 큰 영향을 미치는 두 가지는 두 지점 사이의 거리와 사용하는 전송 매체의 속도다. 유선 네트워크는 보통 광섬유나 구리선으로 전송 매체를 만드는 반면에, 모바일/무선 네트워크는 무선 전파를 활용한다. 두 지점 사이의 이론적인 최소 지연 시간을 계산하려면, 해당 전송 매체에서의 빛의 속도와 두 지점 사이의 전송선의 길이를 고려해야 한다. 예를 들어, 광섬유에서의 빛의 속도는 진공에서의 약 2/3, 즉 초당 약 200,000,000m 다. 따라서 광섬유 케이블을 약 8,500km 거리인 샌프란시스코에서 런던까지 잇는다면, 최소 지연 시간은 약 43ms가 될 것이다. 지연 시간을 줄이는 유일한 방법은 양 끝점을 더 가까이 두는 것이다(또는 더 빠른 전송 매체를 개발해야 한다).
물론 실제로 지연 시간을 측정해보면 이렇게 낮은 지연 시간을 얻지 못할 것이다. 그 이유로, 첫째, 네트워크가 일직선으로 놓여 있지 않기 때문이다. 둘째, 데이터가 A에서 B로 가는 동안 통과해야 하는 여러 게이트웨이, 라우터, 스위치, 기지국 등이 지연을 유발하기 때문이다. 4
From: 시스템 성능 분석과 최적화
지연시간(latency)은 기다리느라 소모한 시간을 재는 척도로 널리 사용된다. 이 용어는 어떤 연산이 완료될 때까지 걸리는 시간을 의미할 수도 있다. 이런 연산으로는 애플리케이션 요청, 데이터베이스 질의, 파일 시스템 연산 등이 있다. 5
지연시간은 어떤 연산이 수행되기 전에 기다려야 하는 시간을 의미한다. 이 예제에서 연산은 데이터 전송을 위한 네트워크 서비스 요청이다. 이 연산이 일어나기 전에 시스템은 네트워크 연결이 만들어지기를 기다려야 한다. 이에 걸리는 시간이 바로 이 연산의 지연시간이다. 지연시간과 연산시간을 합친 시간이 응답시간이다.
지연시간은 서로 다른 부분에서 측정할 수 있기 때문에 어떤 요소에서 해당 지연이 발생했는지를 함께 표시하곤 한다. 예를 들어, 웹사이트를 로딩하는 데 걸리는 시간은 DNS 지연시간과 TCP 연결 지연시간, 그리고 TCP 데이터 전송 시간으로 이뤄질 것이다. DNS 지연시간은 전체 DNS 연산에 걸리는 시간을 말한다. TCP 연결 지연시간은 초기화(TCP 핸드세이크)에 걸리는 시간만을 의미한다.
더 높은 수준에서 볼 때 TCP 데이터 전송시간을 포함한 이 모든 시간을 다른 어떤 것의 지연시간으로 간주할 수도 있다. 예를 들어, 사용자가 웹사이트 링크를 클릭한 다음 결과 페이지가 모두 화면에 나타날 때까지 걸리는 시간을 지연시간으로 볼 수 있다. 이러한 경우, 지연시간에는 앞의 모든 시간과 브라우저가 웹 페이지를 렌더링하는 시간이 들어간다. 6
파일 시스템 지연시간은 파일 시스템 성능의 주요 지표다. 이는 논리적인 파일 시스템 요청이 완료될 때까지 걸리는 시간으로 측정할 수 있다. 이 시간에는 파일 시스템, 커널의 디스크 I/O 하위시스템, 그리고 디스크 서비스 대기 시간(즉, 물리적 I/O 시간) 등이 들어간다. 애플리케이션 스레드는 종종 파일 시스템 요청이 완료될 때까지 블록되곤 한다. 이러한 경우 파일 시스템 지연시간은 직접적으로, 그리고 비례적으로 애플리케이션 성능에 영향을 끼친다. 7
네트워크 지연시간은 어떤 메시지가 두 끝점 사이를 왕복하는 데 걸린 시간 또는 연결(connection)을 맺는 데 걸린 시간이다(예: TCP 핸드셰이크(handshake)). 연결 뒤에 오는 데이터 전송 시간은 포함하지 않는다. 8
From: TCP/IP 완벽 가이드
지연 시간(Latency)은 매우 중요하지만 종종 간과되는 용어로 통신 채널이나 네트워크에서 데이터 전송 시간을 의미한다. 지연 시간의 중요한 요소로 특정 데이터 요청 시간부터 응답 데이터 수신 시간까지의 간격을 들 수 있다. 또 다른 요소로 데이터를 언제 송신할지를 장비가 얼마나 제어할 수 있는지, 그리고 특정 기간 동안 데이터를 지속적으로 보낼 수 있도록 네트워크를 구성하는 것이 가능한지 등이 있다. 지연 시간이 짧은 것(Low latency)은 긴 것(High latency)보다 좋다. 9
일반적으로 속도(Speed), 대역폭(Bandwidth), 처리율(Throughput)은 많은 관심을 받지만 지연 시간은 별다른 주목을 받지 못한다. 하지만 지연 시간은 스트리밍 오디오나 비디오, 대화형 게임과 같은 여러 실시간 애플리케이션에서 매우 중요한 고려사항이다. 사실 그러한 애플리케이션에서는 지연 시간이 기본 대역폭보다 더 중요하다.
예를 들어 시골 별장에 놀러갔을 때 인터넷에 접근할 수 있는 수단은 28.8Kbps 모뎀 연결 또는 고급 위성 인터넷 정도가 될 것이다. 위성 인터넷 제공 회사는 자사의 네트워크가 '브로드밴드'이며 속도가 400Kbps 이상 나온다고 광고할 것이다. 그들은 "전화 접속보다 10배 이상 빠르다"는 것을 자랑하며 많은 비용을 청구할 것이다. 위성 인터넷은 과연 그렇게 멋진 기술일까?
아니다. 위성 인터넷 연결은 대역폭은 크지만 신호가 위성까지 오고 가는 데 걸리는 시간 때문에 지연 시간이 길다. 물론 마이크로소프트에서 제공한 150MB 패치를 다운로드할 때는 위성 인터넷이 모뎀보다 훨씬 편리할 것이다. 하지만 인터넷을 통해 친구와 최신 온라인 비디오 게임을 할 때는 위성 인터넷이 모뎀 연결보다 좋을 수가 없다. 왜냐하면 대기 시간이 길기 때문이다. 10
From: 엔터프라이즈 애플리케이션 아키텍처 패턴
응답 시간(response time)은 시스템이 외부에서 받은 요청을 처리하는 데 걸리는 전체 시간이다. 요청은 버튼 누르기와 같은 UI 동작일 수도 있고 서버 API 호출일 수도 있다.
응답성(responsiveness)은 시스템이 요청을 얼마나 신속하게 인식하느냐다. (중략) 파일을 복사하는 동안 사용자에게 상태 표시줄을 보여주면 응답 시간이 개선되지는 않지만 사용자 인터페이스의 응답성이 개선된다.
대기 시간(latency)은 수행할 작업의 존재 여부와 상관없이 모든 유형의 응답을 받는 데 걸리는 시간이다. 대기 시간은 일반적으로 원격 시스템과 관계가 깊다. 예를 들어, 필자의 노트북에서 실행 중인 프로그램에 대해 실제로는 아무 작업도 하지 않지만 언제 작업이 완료되는지를 보고하게 하면 당연히 거의 즉시 응답을 븓는다. 그런데 프로그램이 원격 컴퓨터에서 실행 중인 경우 요청과 응답이 네트워크를 통해 전달되는 시간 때문에 몇 초의 시간 지연이 발생할 수 있다. 애플리케이션 개발자가 대기 시간을 줄이기 위해 할 수 있는 일은 아무것도 없다. 지연 시간은 원격 호출을 최소화해야 하는 이유이기도 하다. 11
(책) HTTP/2 IN ACTION
현재 인터넷의 최대 문제 중 하나는 대역폭보다는 대기시간이다. 대기시간은 단일 메시지를 서버에 전송하는 데 걸리는 시간을 측정하는 반면, 대역폭은 사용자가 이 메시지에서 다운로드할 수 있는 양을 측정한다. 새로운 기술은 언제나 대역폭을 증가시키지만(웹 사이트 크기 증가를 다루는 데 도움이 됨), 대기시간은 개선되지 않는다(요청의 수가 증가되지 못하게 막음). 대기시간은 물리학에 의해 제약된다(광속). 광섬유 케이블을 통해 전송되는 데이터는 이미 거의 광속에 가깝게 이동한다. 기술이 얼마나 개선되든지 얻을 이익은 거의 없다.
구글의 마이크 벨쉬(Mike Belshe)는 대역폭 증가에 대한 수익 체감점(point of diminishing returns)에 이르렀음을 보이는 몇 가지 실험12을 했다. 이제 고화질 텔레비전을 스트리밍할 수 있지만 웹 서핑은 같은 비율로 빨라지지 않았으며, 웹 사이트는 종종 빠른 인터넷 연결에서조차 로드하는 데 몇 초가 걸린다. 인터넷은 HTTP/1.1의 근본적인 성능 문제에 대한 해결책 없이는 확장되던 속도 그대로 계속 확장될 수 없다. 작은 HTTP 메시지를 보내고 받는 데에도 너무 많은 시간이 낭비된다. 13
참고문헌
- 1일 1로그 100일 완성 IT 지식 / 브라이언 W. 커니핸 저/하성창 역 / 인사이트(insight) / 초판 1쇄 2021년 12월 31일 / 원제 : UNDERSTANDING THE DIGITAL WORLD (2nd Edition)
- HTTP/2 in Action / 배리 폴라드 저/임혜연 역 / 에이콘출판사 / 2020년 08월 31일 / 원서 : HTTP/2 in Action
- TCP/IP 완벽 가이드 / 찰스 M. 코지에록 저/강유, 김진혁, 민병호, 박선재 역 / 에이콘출판사 / 2007년 01월 25일 / 원제 : The TCP/IP Guide: A Comprehensive, Illustrated Internet Protocols Reference
- 데이터 중심 애플리케이션 설계 / 마틴 클레프만 저/정재부,김영준,이도경 역 / 위키북스 / 2018년 04월
- 러닝 HTTP/2 / 스티븐 루딘, 하비에르 가르사 저/강재준 역 / 한빛미디어 / 2018년 01월 22일
- 시스템 성능 분석과 최적화 / 브렌든 그레그 저 / 오현석, 서형국 공역 / 위키북스 / 2015년 12월 15일
- 엔터프라이즈 애플리케이션 아키텍처 패턴 / 마틴 파울러 저 / 최민석 역 / 위키북스 / 2쇄 2018년 10월 31일 / 원제 : Patterns of Enterprise Application Architecture
See Also
- [[bandwidth]]{대역폭(Bandwidth)}