Homa: AI 클러스터에서 TCP의 종말 [영상]

요약

스탠퍼드대 존 오스터하웃 교수가 AI 클러스터에서 TCP를 대신할 프로토콜로 Homa를 소개하는 강연입니다.

유튜브에 올라온 강연 영상입니다. 제목으로 보아 AI 클러스터 안의 통신을 TCP 대신 Homa라는 전송 프로토콜(컴퓨터끼리 데이터를 주고받는 규칙)로 처리하자는 내용으로 보입니다. 게시물에는 2021년 USENIX ATC 논문과 LWN, 더 레지스터 기사 링크가 함께 붙어 있습니다. 원문을 읽지 못했습니다.

HN 반응

Homa는 2018년 논문부터 나온 설계로, TCP와 달리 받는 쪽이 전송을 허가해 혼잡을 제어한다는 보충 설명이 이어졌습니다.
메시지 통째 유실을 감지하지 못하고 암호화도 없어 QUIC이 낫다는 비판에, 타임아웃으로 풀 수 있고 QUIC 성능은 검증이 필요하다는 반론이 맞섰습니다.

17개 표시 · 전체 17개

Animats5일 전 HN

Homa는 꽤 오래전부터 있었습니다. 2018년 논문은 여기 있습니다.[1]

핵심 아이디어는 이렇습니다. 메시지가 송신자의 전송 모듈에 도착하면 Homa는 메시지를 두 부분으로 나눕니다. 앞부분은 스케줄 없이 보내는 부분(처음 RTTbytes 바이트)이고, 그 뒤는 스케줄에 따라 보내는 부분입니다. 송신자는 스케줄 없는 바이트를 하나 이상의 DATA 패킷에 실어 즉시 전송합니다. 스케줄에 따라 보내는 바이트는 수신자가 GRANT 패킷으로 명시적으로 요청하기 전까지 전송하지 않습니다.

즉 짧은 요청은 일단 보내고 보되, 그 뒤부터는 수신자의 승인을 받아야 합니다. 주된 용도가 원격 프로시저 호출(RPC)이라면 합리적인 설계입니다. 단일 패킷 메시지로 요청/응답을 하면서도 임의의 긴 메시지까지 처리할 수 있다는 점에서 QNX의 네트워킹 프로토콜이 떠오릅니다.

요즘 이게 통하는 이유는 하드웨어 스위치에서 패킷당 처리 오버헤드가 바이트당 오버헤드에 비해 낮기 때문입니다. 초기의 소프트웨어 기반 스위치에서는 패킷당 오버헤드가 지배적이어서 작은 패킷을 보내는 것이 매우 비효율적이었습니다. FPGA가 처리를 맡는 최신 하드웨어 스위치에서는 패킷당 오버헤드가 충분히 낮아서 작은 패킷도 비효율적이지 않습니다.

웹이 요즘 너무 비대해져서 1MB 미만의 트랜잭션이 "작다"고 여겨진다는 점은 웃깁니다. 그러니 이 프로토콜은 개방된 웹에서 쓰기에는 적합하지 않습니다.

[1] https://people.csail.mit.edu/alizadeh/papers/homa-sigcomm18.pdf
wmf5일 전 HN

패킷 크기는 TCP든 Homa든 같아야 합니다. 차이는 혼잡 제어를 송신자 쪽에서 하느냐, 수신자 쪽에서 하느냐에 있습니다.
Procrastes5일 전 HN

QNX를 언급해 주셔서 추천 누르고 갑니다! 저는 실시간 제어 쪽 작업에 QNX를 써 보고 정말 좋아했거든요.

명쾌하게 요약하고 맥락까지 짚어 주셔서 감사합니다.
Veserv5일 전 HN
Homa는 좋은 설계가 아닙니다. [1]
1. RPC 전체가 유실되는 것을 감지할 방법이 없습니다. 바깥쪽 연결 상태가 없기 때문에, RPC의 송신 쪽 패킷이 전부 유실되면 서버는 재전송을 요청해야 한다는 사실조차 알 수 없습니다. 그 RPC는 그냥 허공으로 사라집니다. 송신 쪽 패킷 수가 적은 작은 메시지, 예컨대 패킷 하나에 들어가는 메시지일수록 영향이 더 큽니다.
2. 위와 관련해서, 암호화가 내장되어 있지 않습니다. 암호화를 쓰려면 위나 아래에 따로 계층을 얹어야 합니다.
3. 벤치마크 성능이 형편없습니다. [2]의 표 4에서 평균 60 kB 메시지의 경우, 평균 20 Gbit/s를 내는 데 하이퍼스레드가 5개(!)나 듭니다. 하이퍼스레드 하나당 겨우 4 Gbit/s입니다. 시스템 콜 한 번에 패킷 하나씩 보내는 아주 순진한 네트워크 프로토콜 설계와 구현으로도 하이퍼스레드당 8 Gbit/s는 나와야 합니다. 성능에 조금만 신경 쓰면 하이퍼스레드당 30 Gbit/s는 쉽게 나옵니다.
4. QUIC도 성능 설계에 문제가 많지만(그래도 Homa보다는 빠릅니다), Homa가 풀려는 문제는 사실상 전부 이미 훨씬 깔끔하게 풀어 놓았습니다. 스트림 ID는 RPC ID에 해당하고, 스트림 최대값(Stream Max)은 Grant에 해당합니다. 하나의 클라이언트 아래 스트림을 여러 개 두면 우선순위도 매길 수 있습니다.
게다가 QUIC에서는 메시지 전체가 제멋대로 유실되는 일이 없습니다. 작은 메시지를 한 패킷에 묶을 수 있고, RTT를 더 정밀하게 측정해서 페이싱과 혼잡 계산도 더 정확하게 할 수 있습니다. 암호화도 내장되어 있습니다. 경직화된 중간 장비(middlebox)도 통과합니다. ACK 프레임/패킷을 여러 개 담을 수 있어 ACK 오버헤드도 줄어듭니다.

진짜 차이는 Homa가 송신자의 암묵적 재전송 대신 수신자의 명시적 Resend를 쓴다는 것뿐입니다. 그런데 이건 손실이 만만치 않은 상황에서는 수신자 자원을 훨씬 많이 잡아먹습니다. 특히 Resend 패킷이 구간을 하나만 지원하기 때문입니다. 지연 시간도 더 길어지고, 잃어버리면 안 되는 데이터가 추가로 오가기 때문에 손실이 있는 네트워크 경로 전체에 요구하는 조건도 더 까다롭습니다.

이건 RFC를 머릿속에 다시 불러와서 바로 떠오르는 심각한 문제들일 뿐입니다. 필요하면 더 찾아낼 수 있습니다.

[1] https://github.com/johnousterhout/homa-rfc/blob/main/draft-ousterhout-tsvwg-homa-00.md

[2] https://www.usenix.org/system/files/atc21-ousterhout.pdf
wmf5일 전 HN
1. TCP에 SYN 타임아웃이 있는 것처럼 타임아웃을 쓰면 됩니다.
2. TCP도 암호화는 없습니다. 다만 DTLS가 동작하는 모습은 보여 주는 게 좋겠네요.
3. 테스트도 안 해 보고 QUIC이 더 빠르다고 단정할 수는 없습니다.
KerrAvon5일 전 HN

QUIC이 Homa보다 훨씬 널리 알려져 있잖아요. 이 용도에 QUIC을 쓰면 단점이 있나요?
Veserv5일 전 HN

프로토콜 설계 수준에서 TCP나 Homa와 비교한 거라면요? 딱히 없습니다.

다만 소프트웨어 QUIC 구현은 대체로 소프트웨어 TCP 구현보다 훨씬 느립니다. 프로토콜 설계상의 근본적인 한계 때문이 아니라, 거의 모든 QUIC 구현이 성능을 끌어올리는 쪽으로는 엉성하게 만들어졌기 때문입니다.

물론 성능에 맞게 더 잘 설계한 프로토콜이라면 QUIC이나 TCP보다 몇 배 많은 처리량을 낼 수 있지만, 질문하신 내용과는 아마 별개의 이야기일 겁니다.
giovannibonetti5일 전 HN

몇 달 전에 제인 스트리트의 론 민스키가 팟캐스트에서 이 이야기를 하는 걸 들은 기억이 납니다. AI 클러스터에서는 TCP가 병목이 된다는 내용이었습니다. 저는 전기공학을 전공했는데, 회선 교환이 패킷 교환에 자리를 내준 것은 많은 주체가 네트워크를 지나다닐 때 사용량이 매우 듬성듬성하기 때문이었다고 기억합니다. 효율적이지는 않지만, 트래픽이 워낙 다양해서 흐름 패턴이 너무 동적이라 최적화하기가 어렵습니다. 자동차 교통에 비유하면 좋습니다. 도심에는 아주 다양한 목적지로 가는 차가 너무 많아서, 신호등이 아무리 비효율적이어도 그런대로 쓸 만한 해법이 됩니다.

반대로 트래픽이 아주 예측 가능한 패턴을 따른다면 맞춤 구현이 훨씬 효율적일 수 있습니다. 특히 요즘은 머신러닝이 강화학습으로 훨씬 나은 해법을 찾아낼 수 있습니다. 그리고 AI 클러스터의 데이터 흐름은 인터넷 전체에서 오가는 트래픽보다 훨씬 예측 가능합니다.
throw0101c5일 전 HN
영상의 (약 6:01) "혼잡 제어는 송신자의 책임이다"와 "어떻게든 송신 노드가 그렇게 빨리 보내지 않게 해야 한다"는 대목 말인데요. 이더넷/RoCE에는 그런 게 이미 없나요?

링크 수준 흐름 제어: InfiniBand는 크레딧 기반 알고리즘으로 HCA 간 무손실 통신을 보장합니다. RoCE는 이더넷 위에서 동작합니다. InfiniBand와 비슷한 성능 특성을 얻으려면 구현에 따라 무손실 이더넷이 필요할 수 있습니다. 무손실 이더넷은 보통 이더넷 흐름 제어나 우선순위 흐름 제어(PFC)로 구성합니다. 데이터 센터 브리징(DCB) 이더넷 네트워크는 InfiniBand 네트워크보다 구성이 더 복잡할 수 있습니다.[19]
- https://en.wikipedia.org/wiki/RDMA_over_Converged_Ethernet
송신 장치(컴퓨터나 네트워크 스위치)가 링크 반대편이 받아들일 수 있는 속도보다 빠르게 데이터를 보내고 있을 수 있습니다. 흐름 제어를 쓰면 수신 장치가 송신자에게 신호를 보내, 수신 장치가 따라잡을 때까지 전송을 중단해 달라고 요청할 수 있습니다. 이더넷의 흐름 제어는 데이터 링크 계층에서 구현할 수 있습니다.
- https://en.wikipedia.org/wiki/Ethernet_flow_control
teraflop5일 전 HN
이더넷 흐름 제어는 아주 특수한 경우를 빼면 혼잡을 제대로 해결하지 못합니다.

아주 단순한 토폴로지를 생각해 봅시다.
```
    A         C
     \       /
      S1===S2
     /       \
    B         D
```
호스트 A와 B가 둘 다 스위치 S1과 S2(둘은 고속 링크로 연결되어 있습니다)를 거쳐 C로 최대한 빠르게 데이터를 보내고 있다고 합시다. 그리고 이 두 흐름을 합친 양이 C로 가는 링크의 용량보다 많다고 합시다.

S2는 C로 가는 패킷을 처리 속도보다 빠르게 받고 있지만, S2가 S1에 이더넷 일시 정지(pause) 프레임을 보내는 것은 상황을 풀기에 별로 도움이 되지 않습니다. D로 가야 할 트래픽까지 같이 막아 버리기 때문입니다. 병목을 다른 곳으로 옮기면서 애꿎은 피해만 낳을 뿐입니다.
lokar5일 전 HN

문제는 목적지에 있는 경우가 거의 없고, 대개 중간 경로의 어떤 링크나 스위치에 있습니다.

링크가 포화 상태가 되면 그걸 어떻게 관리할지가 어려운 문제입니다.

RoCE를 대규모로 써 본 건 딱 한 번인데, 정말 까다로웠습니다. 일시 정지 프레임이 파도처럼 밀려와서 전체가 멈춰 서곤 했습니다.
wmf5일 전 HN

흐름 제어는 아무것도 없는 것보다는 낫지만, 혼잡 확산과 버퍼블로트를 일으킬 수 있습니다. QCN, Falcon, Ultra Ethernet은 RoCE에 훨씬 나은 혼잡 제어를 제공하지만, Homa에 비해 더 새로운 하드웨어가 필요하다는 단점이 있습니다.
adastra225일 전 HN

제발 대표 링크를 영상으로 걸지 말아 주세요.
wmf5일 전 HN

Homa 이야기는 몇 년째 들어 왔는데, 뭐가 새로워졌는지 궁금했습니다. git 저장소의 readme에서 변경 이력을 찾았습니다: https://github.com/PlatformLab/HomaModule
jMyles5일 전 HN

기사에 나온 "가중치 그래디언트, 모델 가중치, KV 캐시 항목, 체크포인트 같은 잡일"에 LLM이 homa나 다른 최적화된 프로토콜을 쓰는 데 익숙해지면, 그들이 사후 학습(post-training) 단계에서 주고받는 상호작용에서도 같은 이유들로 TCP가 병목으로 보이기 시작할지 궁금합니다.
almost_usual5일 전 HN

https://lwn.net/Articles/1003059/

https://www.usenix.org/system/files/atc21-ousterhout.pdf
dang5일 전 HN

감사합니다, 둘 다 아주 좋은 자료네요! 본문 상단 설명에도 추가했습니다.

Hacker News에서 보기 ↗