NumaRing: Topology-Aware Routing for NUMA-Local MPMC Queues, and What Broke When We Optimized It

현대적인 컴퓨터는 여러 구역이 있고 각 구역마다 자체적인 처리 능력과 메모리를 보유하고 있는, 북적이는 도시처럼 구축되어 있습니다. 프로그램이 작업을 수행해야 할 때, 프로그램은 특정 구역에 요청을 보냅니다. 만약 필요한 데이터가 해당 구역의 로컬 메모리에 이미 있다면, 작업은 즉각적으로 이루어집니다. 하지만 요청이 정보를 가져오기 위해 다른 구역으로 이동해야 한다면, 그 여정은 훨씬 더 오래 걸립니다. 구역 사이의 물리적 거리로 인해 발생하는 이 지연은 이러한 기계가 만들어진 방식의 근본적인 한계입니다. 수십 년 동안 소프트웨어 엔지니어들은 데이터를 사용하는 작업자와 데이터를 같은 구역에 머물게 하여, 느린 장거리 이동을 피할 수 있도록 프로그램을 작성하려고 노력해 왔습니다. 문제는 많은 작업자가 동시에 공유된 작업 목록에 접근하려고 할 때, 그들이 만들어내는 교통 체증이 거리 그 자체만큼이나 해로울 수 있다는 점입니다.

한 연구자는 두 개의 뚜렷한 구역을 가진 컴퓨터를 위한 더 나은 방식의 공유 목록 관리법을 구축하기 위해 연구를 시작했습니다. 그는 가능한 한 작업자와 데이터를 각자의 구역에 국한시키도록 설계된 NumaRing라는 시스템을 만들었습니다. 아이디어는 간단했습니다. 만약 작업자가 첫 번째 구역에 있다면, 그는 첫 번째 구역에 있는 목록만을 보아야 한다는 것입니다. 만약 그 목록이 가득 차거나 비게 되면, 시스템은 작업을 하나씩 옮기는 대신 한 번에 묶음으로 다른 구역으로 이동할 것입니다. 이 접근 방식은 빠른 로컬 트래픽을 유지하면서도 느린 장거리 이동을 최소화하겠다는 약속을 담고 있었습니다. 그러나 연구자가 자신의 시스템을 테스트했을 때, 그의 선의가 숨겨진 함정을 가지고 있다는 것을 발견했습니다. 추측하는 대신 극도로 정밀하게 시스템을 측정함으로써, 그는 두 가지 특정한 실수가 하드웨어 자체보다 더 많은 속도를 늦추고 있다는 것과, 컴퓨터의 저하를 해결하기 위해 흔히 쓰이는 조언이 실제로는 상황을 악화시키고 있다는 것을 발견했습니다.

연구자는 두 개의 구역이 각각 16개의 가상 프로세서를 포함하고 있는 클라우드 컴퓨터 위에 시스템을 구축하며 연구를 시작했습니다. 그는 시스템에 꾸준한 작업 스트림을 채워 넣으며, 작업이 줄의 시작부터 끝까지 가는 데 시간이 얼마나 걸리는지 관찰했습니다. 초기에 시스템은 놀라울 정도로 느렸습니다. 연구자는 작업자가 작업을 추가하거나 제거하려고 시도할 때마다 소프트웨어가 "나는 지금 어느 구역에 있는가?"라는 질문을 던진다는 사실을 깨달았습니다. 이 질문은 무해해 보였지만, 답을 계산하는 데 오랜 시간이 걸렸습니다. 소프트웨어는 작업자의 위치가 거의 변하지 않음에도 불구하고 매번 처음부터 위치를 재계산하고 있었습니다. 이 반복적인 계산은 마치 운전자가 자신이 어디로 가는지 정확히 알고 있음에도 불구하고, 모든 교차로마다 멈춰 서서 길을 묻는 것과 같았습니다. 이 질문의 비용은 데이터를 이동시키는 실제 작업 노력보다 11배 이상 높았습니다.

연구자가 위치를 기억하고 필요할 때만 확인하도록 이 문제를 해결하자, 시스템은 급격히 빨라졌습니다. 초당 처리되는 작업 수는 6~7배 더 높게 뛰어올랐습니다. 하지만 이야기는 거기서 끝나지 않았습니다. 연구자가 기계에 더 많은 작업자를 추가하자, 시스템은 새로운 벽에 부딪혔습니다. 특히 시스템이 과부하 상태일 때 작업자들은 여전히 너무 오래 기다리고 있었습니다. 더 깊이 파고든 결과, 그들은 구역 간에 작업을 공유하는 방식에서 두 번째 문제를 발견했습니다. 작업자가 다른 구역에서 작업 묶음을 가져와야 할 때, 모든 작업자가 누가 다음에 갈지를 결정하기 위해 동일한 작은 카운터를 두고 서로 싸우고 있었습니다. 이는 입구에서 거대한 교통 체증을 만들어냈습니다. 각 작업자에게 사용할 수 있는 개인용 카운터를 부여함으로써, 연구자는 이 병목 현상을 제거했습니다. 이 변화는 더욱 극적이었으며, 작업자가 줄 중간에서 기다려야 하는 시간을 200배 이상 단축했습니다.

이 두 가지 주요 수정 사항을 적용한 후, 연구자는 자신의 시스템이 챔피언이 될 것이라고 기대했습니다. 그는 자신을 붙잡고 있던 소프트웨어 오류들을 제거했습니다. 그러나 연구자가 32명의 작업자로 기계를 극한까지 밀어붙였을 때, 시스템은 여전히 원래 설계 목표에 도한 속도에 도달할 수 없었습니다. 연구자는 이후 컴퓨터의 저하를 해결하기 위해 사용되는 표준 기술인 "백오프(backoff)"를 테스트했습니다. 백오프의 기본 아이디어는 작업자가 작업을 잡는 데 실패하면, 줄이 풀리기를 바라며 아주 잠시 기다렸다가 다시 시도하는 것입니다. 많은 상황에서 이 일시 정지는 도움이 됩니다. 하지만 이 특정한 고압 환경에서는 그 정지가 실수였습니다. 연구자는 기다리는 행위가 실제로 전체 속도의 15~30%를 낭비한다는 것을 측정했습니다. 가장 빠른 경로는 즉시 계속 시도하는 것이었는데, 왜냐하면 하드웨어가 이미 충돌을 효율적으로 처리하고 있었기에 기다리는 것이 오히려 시간을 낭비하는 일이었기 때문입니다.

최종적으로 나타난 모습은 성공과 한계가 공존하는 모습이었습니다. 연구자는 데이터를 로컬에 유지하는 시스템을 성공적으로 구축했고, 막대한 지연을 일으키던 두 가지 주요 소프트웨어 버그를 해결했습니다. 그는 특정 고속 시나리오에서 일반적인 최적화 전략이 해로울 수 있음을 증명했습니다. 그럼에도 불구하고, 이 승리들에도 불구하고 시스템은 원래의 설계 목표만큼 빠르게 작업을 처리할 수 없었습니다. 연구자는 남은 저하가 수정할 수 있는 소프트웨어 오류가 아니라, 기계 자체의 물리적 한계라는 결론을 내렸습니다. 두 구역 사이의 거리와 그들을 연결하는 도로의 대역폭이 어떤 영리한 코딩으로도 뚫을 수 없는 천장을 만들었다는 것입니다. 그는 자신의 연구 결과를 정직하게 보고하여, 시스템이 어디에서 성공했는지, 어디에서 실패했는지, 그리고 왜 하드웨어 자체가 최종 심판이었는지를 명확히 보여주었습니다. 그의 연구는 고속 컴퓨팅의 세계에서 물리적인 기계를 이해하는 것이 코드를 작성하는 것만큼이나 중요하다는 사실을 상기시켜 줍니다.