요약

  • RFC 10054 사례에서 계산이 가장 빠른 사이트의 종단 간 지연은 22.4ms이고, 네트워크가 가장 빠른 사이트는 23.4ms다. 둘 다 예시의 20ms 목표를 넘는다.
  • 세 번째 사이트는 계산 5ms와 네트워크 5ms를 더해 문서상 총 19.4ms를 기록한다. 모두 시나리오 가정이며 현장 측정값이 아니다.

계산이 가장 빠른 엣지 사이트가 진다. RFC 10054의 클라우드 VR 사례에서 사이트 1은 세 곳 중 가장 짧은 4ms 만에 계산을 마친다. 그러나 혼잡한 네트워크 경로가 9ms를 더하고, RFC가 제시한 동작에서 화면 표시까지의 전체 지연은 22.4ms다. 예시의 서비스 예산은 20ms다. 계산 수치만 보면 승자지만 사용자가 받는 결과는 기준을 넘는다.

네트워크 지연만 보고 골라도 실패한다. 사이트 2의 네트워크 경로는 4ms로 가장 짧지만, 부하가 큰 상태에서 계산에 10ms가 걸린다. 문서가 제시한 전체 지연은 23.4ms다. 사이트 3은 어느 한쪽에서도 두드러지지 않는다. 계산 5ms, 네트워크 5ms를 합친 19.4ms가 유일하게 20ms 아래다. 이 예에서는 불과 3~4ms 차이가 애플리케이션의 요구를 만족하는지 가른다.

이것이 ‘Computing-Aware Traffic Steering’이 다루는 문제다. 서비스 인스턴스가 가깝거나 프로세서가 한가하다는 이유만으로 적합한 것은 아니다. 사용자가 겪는 것은 기기 처리, 전송, 서버 렌더링, 반환 경로가 이어진 전체 과정이다. RFC는 20ms를 센서 샘플링(1.5ms 미만), 디스플레이 갱신(7.9ms), 렌더링(5.5ms), 왕복 네트워크(5.1ms)로 나눈다. 계산과 네트워크가 각각 예산의 중요한 몫을 차지한다. 한쪽만 최적화하면 잘못된 사이트를 고를 수 있다.

RFC 10054는 문제와 요구사항을 설명하는 Informational 문서이며 단일 도메인 시나리오만 다룬다. 특정 배포 환경이 이 선택 로직을 실제 사용한다는 증거는 아니다. 실무상 핵심은 좁고 분명하다. 스케줄러는 대시보드에서 가장 좋아 보이는 한 항목이 아니라 서비스의 종단 간 목표를 기준으로 삼아야 한다.

Source: IETF RFC 10054.