페라리와 트럭

SMB 세계에서 일하다 보면 레이턴시에 대해 이야기해야 할 경우가 실제로 꽤 드뭅니다. SMB 세계는 거의 보편적으로 시스템 처리량에 집중하며 일반적으로 레이턴시를 필요로 인식하지 못합니다. 그러나 레이턴시가 중요해지는 순간이 있으며, 그럴 때 처리량과 레이턴시의 상호작용 및 우리에게 "속도"가 무엇을 의미하는지 이해하는 것이 중요합니다. 엔터프라이즈 영역으로 이동하기 시작하면 레이턴시는 더 자주 관심사로 부각되지만, 그곳에서도 처리량이 거의 항상 우위를 차지하며, 속도의 개념이 거의 보편적으로 처리량을 중심으로 전개되고 레이턴시의 개념은 종종 무시되거나 잊혀집니다.

시스템에서 레이턴시의 역할을 이해하는 것은 복잡할 수 있지만, 레이턴시 자체는 상대적으로 이해하기 쉽습니다.

제가 좋아하는 레이턴시와 처리량을 비교하는 훌륭한 비유는 페라리와 트럭(트레일러 트럭)의 개념입니다. 페라리는 전통적인 의미에서 "빠르며" 높은 "시속"을 자랑합니다. 속도를 위해 설계되었다고 할 수 있습니다. 하지만 정말 그럴까요?

우리는 일반적으로 트럭을 느리다고 생각합니다. 크고 둔한 기계로 최고 속도가 낮습니다. 하지만 한 번에 많은 물건을 운반합니다.

컴퓨터 용어로 우리는 보통 운반 용량처럼 속도를 생각합니다. 초당 "항목" 수로 생각합니다. 페라리가 시속 320km(200마일)로 달리는 것은 훌륭하지만, 한 번에 박스 하나 정도만 운반할 수 있습니다. 트럭은 시속 160km(100마일)밖에 안 나오지만 한 번에 박스 1,000개에 가까운 것을 운반할 수 있습니다. 컴퓨터나 네트워크의 처리량 또는 속도를 이야기할 때 우리가 생각하는 것은 바로 이것입니다. 네트워크 용어로는 초당 기가바이트를 생각하며 개별 패킷의 속도는 거의 신경 쓰지 않습니다. 단일 패킷이 중요한 경우는 거의 없기 때문입니다. 컴퓨팅 용어로는 초당 부동소수점 연산(FLOPS)과 같은 개념을 생각합니다. 아무도 단일 FLOP(부동소수점 연산)이 얼마나 걸리는지 신경 쓰지 않으며, 1초 또는 10초 안에 얼마나 많이 처리할 수 있는지만 관심을 둡니다.

따라서 페라리를 살펴보면 유용한 속도가 시간당 박스-마일 200이라고 할 수 있습니다. 즉, 한 시간의 운영으로 페라리는 박스 하나를 200마일까지 이동시킬 수 있습니다. 트럭의 유용한 속도는 시간당 박스-마일 10만입니다. 패키지를 이동시키는 측면에서 트럭의 처리량은 페라리보다 쉽게 500배 "빠릅니다".

따라서 우리가 보통 컴퓨터와 네트워크를 생각하는 방식으로는 트럭이 "빠르고" 페라리가 "느린" 것입니다.

하지만 레이턴시도 고려해야 합니다. 페이로드가 작다고 가정하면, 예를 들어 편지나 작은 박스 하나의 경우, 페라리는 그 박스 하나를 1,600km(1,000마일)에 걸쳐 단 5시간 만에 이동시킬 수 있습니다! 트럭은 같은 여정에 10시간이 걸립니다(하지만 많은 편지가 동시에 도착할 수 있습니다). 메시지나 소포를 어딘가에서 다른 곳으로 매우 빠르게 보내야 한다면 페라리가 더 나은 선택입니다. 배달을 시작하는 시점부터 첫 번째 패키지가 배달될 때까지의 레이턴시(지연)가 트럭보다 절반이기 때문입니다.

상상할 수 있듯이, 대부분의 경우 트럭이 훨씬 더 실용적입니다. 배달 속도가 훨씬 높기 때문입니다. 그리고 이런 이유로 실제로 대형 트럭이 고속도로에서 항상 보이는 반면 페라리의 발생 빈도는 매우 낮습니다. 각각의 구매 비용이 비슷함에도 불구하고(매우 대략적으로). 하지만 특수한 경우에는 페라리가 더 의미 있습니다. 단지 그런 경우가 자주 있지 않을 뿐입니다.

이것은 일반적인 개념으로 다양한 응용 분야에 적용될 수 있습니다. 캐싱 시스템, 메모리, CPU, 네트워킹, 운영체제 커널 및 스케줄러, 자동차 등에 적용됩니다. 레이턴시와 처리량은 일반적으로 반비례 관계입니다. 처리량을 얻기 위해 레이턴시를 희생합니다. 대부분의 작업에서는 이것이 가장 합리적입니다. 하지만 때로는 레이턴시에 맞게 튜닝하는 것이 더 합리적입니다.

스토리지는 실제로 컴퓨팅에서 특이한 경우입니다. 스토리지 성능에 대한 거의 모든 관심이 처리량을 측정하는 "초당 전송되는 데이터" 대신 레이턴시의 대리 측정값인 IOPS 중심으로 이루어집니다. 두 번째 수치가 스토리지 병목의 원인이 되는 경우가 거의 없기 때문에 드물게만 신경 씁니다. 하지만 이것은 예외이지 규칙이 아닙니다.

레이턴시와 처리량은 컴퓨팅 세계에서 놀라운 상호작용을 할 수 있습니다. 네트워크에 대해 이야기할 때, 예를 들어 일반적으로 처리량(Gb/s)만 측정하고 레이턴시(일반적으로 밀리초 단위로 측정)에는 별로 신경 쓰지 않습니다. 일반적으로 거의 모든 네트워킹 시스템이 비슷한 레이턴시 수치를 가지며 대부분의 애플리케이션은 레이턴시 지연에 거의 무관심하기 때문입니다. 국제 링크나 위성을 통한 VoIP처럼 레이턴시가 평균적인 사람에게 영향을 미치는 드문 애플리케이션이나, 장거리 WAN 연결을 통한 iSCSI처럼 일반적이지 않은 것을 시도할 때 갑자기 레이턴시가 예상치 못한 문제로 나타나 사람들을 놀라게 하는 경우에만 해당합니다.

레이턴시와 처리량의 상호작용이 놀랍고 흥미롭게 되기 시작하는 곳 중 하나는 전기적 또는 광학 데이터 네트워크에서 물리적 네트워크로 이동할 때입니다. 업계의 유명한 인용구가 있습니다:

고속도로를 질주하는 테이프 가득한 스테이션 왜건의 대역폭을 절대 과소평가하지 마라.

이것은 매우 높은 레이턴시를 가진 엄청난 대역폭의 훌륭한 시연입니다. 도심 80km(50마일)를 달리는 단일 스테이션 왜건이나 SUV는 수백 페타바이트의 데이터를 운반할 수 있어 10GB/s 광섬유가 결코 따라올 수 없는 데이터 속도에 달합니다. 하지만 첫 번째 데이터 패킷이 도착하는 시간은 약 한 시간입니다. 우리는 레이턴시가 약 500ms 이하로 제한되어야 한다고 가정하기 때문에 이런 종류의 네트워크를 종종 무시합니다. 하지만 항상 그런 것은 아닙니다.

호주에서 최근 SD 카드를 운반하는 비둘기가 네트워크 처리량 측면에서 해당 지역 ISP보다 빠를 수 있는지 테스트했을 때, 비둘기가 ISP보다 빠른 것으로 나타나 뉴스가 된 일이 있습니다!

컴퓨팅 성능 측면에서 우리는 종종 성능을 논의하는 맥락으로서 레이턴시를 인식하지 못할 정도로 무시합니다. 그러나 저레이턴시 컴퓨팅 분야에서는 매우 신중하게 고려됩니다. 시스템 처리량은 일반적으로 크게 감소합니다(더 전통적인 시스템이 90% 가까운 CPU 활용률을 목표로 할 때 10% CPU 활용률만 목표로 하는 것이 일반적이 됩니다). 실시간 커널, CPU 어피니티, 프로세서 피닝, 캐시 히트율 및 측정 낮추기와 같은 개념들이 시스템에서 최대한 많은 전체 처리량을 얻으려는 것이 아니라 최대한 즉각적인 응답을 얻는 데 초점을 맞추는 데 사용됩니다.

컴퓨팅 관점에서 저레이턴시가 요구되는 일반적인 장소는 중요 제어 시스템(예: 밀리초의 레이턴시도 공장 바닥에서 문제를 일으킬 수 있는 제조 컨트롤러)이나 몇 밀리초의 지연이 투자 가격 변동이나 제품이 이미 판매되어 더 이상 구매할 수 없게 만들 수 있는 금융 거래 시스템입니다. 레이턴시 측면의 속도는 종종 돈을 버느냐 잃느냐를 결정하는 요소가 됩니다. 단 1밀리초도 치명적일 수 있습니다.

기술적으로 오디오 및 비디오 처리 시스템도 레이턴시에 민감해야 하지만, 대부분의 현대 컴퓨팅 시스템은 여유 처리 오버헤드가 너무 많고 레이턴시가 일반적으로 충분히 낮아 VoIP PBX 및 회의 시스템을 포함한 대부분의 시스템이 오늘날 처리 측의 레이턴시 문제를 인식해야 하는 경우가 매우 드물게 작동할 수 있습니다(네트워킹 레이턴시도 점점 덜 일반적인 문제가 되고 있습니다). 일반 시스템 관리자나 엔지니어는 레이턴시에 민감하거나 레이턴시 민감도를 숨길 수 있는 충분한 여유 오버헤드가 없는 시스템에서 작업할 필요 없이 경력을 쉽게 마칠 수 있습니다.

속도를 정의하는 것, 즉 처리량, 레이턴시 또는 그 밖의 무언가 혹은 두 가지의 조합을 의미하든, IT의 모든 측면과 생활에서 매우 중요합니다. 이것들이 다양한 상황에서 우리에게 어떤 영향을 미치는지, 그리고 처리량의 개선이 레이턴시의 비용으로 오거나 그 반대로 일반적으로 간접적인 관계로 존재하는 이들이 서로 어떻게 반응하는지 이해하고, 우리가 작업하는 시스템을 개선하기 위해 필요에 따라 균형을 맞추는 방법을 배우는 것은 매우 가치 있는 일입니다.