TL;DR

  • TCP가 AI 데이터센터 워크로드에 적합하지 않다는 John Ousterhout의 주장에 따라, Homa가 TCP와 함께 점진적으로 도입 가능한 대안으로 제시됨.
  • Homa는 스트림 기반 TCP와 달리 메시지 기반이며, 수신자가 혼잡 제어와 패킷 전송 시점을 관리함.
  • 최단 잔여 처리 시간(SRPT) 알고리즘을 적용해 짧은 메시지의 지연 시간이 약 10배 감소하며, 100Gbps 네트워크 사용률 80% 기준 p99 지연 시간이 TCP 1.2밀리초에서 Homa 92마이크로초로 13배 단축됨.
  • Homa는 긴 메시지에서도 TCP보다 약 2배 빠르며, 리눅스 커널에 설치해 TCP와 나란히 실행할 수 있고 재부팅도 필요하지 않음.
  • AI 작업의 짧은 제어 트래픽과 대용량 전송이 대역폭을 공유하면서 지연 시간에 민감해지는 가운데, 현재 TCP는 여전히 주류임.

Homa, TCP와 함께 도입 가능한 대안

  • 스탠퍼드대학교 명예 컴퓨터과학 교수 John Ousterhout는 웹과 클라우드 컴퓨팅의 기반인 TCP가 새롭게 등장하는 AI 워크로드에 적합하지 않다고 주장하며, Homa라는 새 프로토콜을 알리고 있음.
  • Ousterhout는 AI Engineer World’s Fair에서 데이터센터에는 TCP가 적합하지 않다고 밝힘.
  • TCP 의존도가 전 세계적으로 매우 높지만, Homa를 네트워크에 추가하는 절차는 비교적 단순함. GitHub 소스에서 Homa를 컴파일한 뒤 클라이언트와 서버의 리눅스 커널에 모듈을 설치하면 되며, 재부팅은 필요하지 않음.
  • Homa는 TCP와 나란히 작동하므로 애플리케이션을 TCP에서 Homa로 점진적으로 옮길 수 있으며, Homa 실행은 기존 TCP 애플리케이션의 속도도 높임.

새로운 방식의 네트워크 혼잡 관리

  • Ousterhout는 Homa가 네트워크 트래픽 혼잡 관리 방식을 처음부터 다시 설계한 프로토콜이라고 설명함.
  • 프로토콜 개발은 현재 Google의 스태프 엔지니어인 Behnam Montazeri가 2019년에 발표한 박사 학위 논문에서 시작됨. 교수직에서 은퇴한 Ousterhout는 Homa 보급을 자신의 “인생의 사명”으로 삼고 있음.
  • TCP가 스트림 기반인 반면 Homa는 메시지 기반임. 원격 프로시저 호출(RPC)과 마찬가지로 Homa 메시지의 길이는 명시적으로 정의됨.
  • TCP와 달리 Homa에서는 수신자가 혼잡 제어를 관리함. 수신자는 첫 패킷에서 들어올 데이터의 양을 파악한 뒤 패킷 전송 시점을 명시적으로 조정함.
  • 이 과정에서 최단 잔여 처리 시간(SRPT) 알고리즘을 사용해 긴 메시지보다 짧은 메시지에 우선순위를 부여함.
  • Ousterhout의 설명에 따르면 짧은 메시지의 지연 시간은 약 10배 감소함. 100Gbps 네트워크가 80% 사용률로 운용되는 조건에서 짧은 메시지의 99백분위수(p99) 지연 시간은 Homa가 92마이크로초, TCP가 1.2밀리초로 Homa가 13배 빠름.
  • 가장 긴 메시지에서도 Homa가 TCP보다 2배 빠름.

TCP의 한계를 둘러싼 논쟁과 다른 대안

  • Ousterhout는 현재 Homa의 IETF 표준화 문서를 작성하고 리눅스 커널에 코드를 반영하는 절차를 진행 중임. Homa는 3월에 Red Hat Enterprise Linux 8 및 9.5로 백포트됨.
  • 대형 기업들이 Homa의 적용 가능성을 검토하도록 돕고 있으며, 현재 대형 금융 서비스 회사 한 곳과 프로토타입을 작업 중임.
  • 네트워크 설계자 Ivan Pepelnjak는 2023년에 Homa에 대한 강한 비판을 담은 입장문을 발표함. Ousterhout의 TCP 성능 특성화에 의문을 제기하고, Homa가 실제 문제가 아닌 문제를 해결하려는 것이라고 비판함.
  • TCP의 지연 시간 문제에 불만을 가진 생태계는 AI 업계만이 아님.
  • 고성능 데이터베이스 업계에서는 더 빠른 쿼리를 위해 데이터 평면 개발 키트(DPDK)로 TCP 스택을 우회함.
  • 스토리지 영역 네트워크에서는 네트워크 패브릭을 통한 솔리드 스테이트 드라이브 접근 속도를 높이기 위해 NVMe over Fabrics(NVMe-oF)를 사용하며, 전송 방식에는 원격 직접 메모리 접근(RDMA), 파이버 채널, TCP가 포함됨.
  • 웹에서는 Google이 TCP의 헤드 오브 라인 블로킹을 우회하고 브라우저가 더 많은 자산을 동시에 내려받게 하려고 QUIC을 개발했으며, QUIC은 HTTP/3의 기반이 됨.
  • 고빈도 거래와 멀티플레이어 게임 업계도 TCP의 느린 속도로 인한 제약을 겪음.
  • 전용 RDMA 패브릭과 Amazon Web Services의 확장 가능 신뢰성 데이터그램(Scalable Reliable Datagram)도 TCP 지연 시간 문제를 다뤄 왔음.
  • 톱오브랙 스위치도 큐 임계값을 설정하고 조기 혼잡 알림을 패킷에 표시하는 등 혼잡 관리 기능이 향상됨.

TCP의 제어 지연 문제

  • Vint Cerf와 동료들은 네트워크에서 통제되지 않는 메시지 패킷 흐름을 정리하기 위해 TCP를 만들었으며, TCP는 흐름 제어, 전달 보장, 연결 핸드셰이크, 혼잡 제어를 제공함.
  • 혼잡 제어는 스위치와 라우터를 포함한 네트워크 경로의 과부하를 방지하고, 별도의 흐름 제어 메커니즘은 송신자가 수신자를 압도하지 않도록 함.
  • TCP의 데이터 모델은 연속적인 데이터 패킷 흐름인 바이트 스트림을 기반으로 하며, 패킷을 구분하거나 메시지별 우선순위를 두지 않음. 메시지는 하나의 바이트 스트림으로 직렬화되므로 수신자는 긴 바이트 스트림과 짧은 바이트 스트림을 구별하기 어려움.
  • 트래픽이 몰리는 서버는 송신자에게 입력을 늦추라는 알림을 보낼 수 있지만, 앞으로 얼마나 많은 트래픽이 더 들어올지는 제한적으로만 파악함. 수신자가 보낸 확인 응답의 도착 시점에 따라 출력량을 조절하는 송신자도 전송 속도를 얼마나 낮출지 추정해야 함.
  • 일반 인터넷 트래픽이나 데이터센터 내부의 대규모 전송에서는 약간의 지연 시간 증가를 감당할 수 있지만, 지연 시간에 민감한 AI 워크로드에서는 밀리초 단위 지연도 큰 부담이 됨.

GPU를 유휴 상태로 만드는 지연 시간

  • 대형 언어 모델(LLM)을 개발하는 프런티어 연구소는 그래디언트, 모델 가중치, KV 캐시 항목, 체크포인트 같은 작업에 높은 수준의 네트워크 성능을 요구해 왔음.
  • 대용량 데이터 전송은 에이전트 트래픽과 메타데이터 조정, 캐시 조회 같은 제어 작업에서 발생하는 짧은 트래픽과 점점 더 대역폭을 공유함.
  • Ousterhout는 이러한 워크로드에서 중요한 요소가 지연 시간이라고 설명함. 지연 시간이 1밀리초만 발생해도 비용이 높은 GPU가 유휴 상태가 됨.
  • Ousterhout는 기존 프로토콜이 이런 환경에 적합하지 않다고 밝힘.
  • Homa가 해결할 문제를 마침내 찾았는지, 아니면 애초에 시대를 앞선 프로토콜이었는지는 아직 열려 있으며, 현재까지는 TCP가 주류임.