DBOS는 Postgres 샤딩으로 초당 워크플로 100만 건을 처리했다

초당 2만 건에서 100만 건으로 뛴 내구성 워크플로(workflow) 처리량이 먼저 눈에 들어옵니다. DBOS는 16코어·메모리 64GB 서버 50대와 워커(worker) 2,400개를 쓴 벤치마크 결과로 이 수치를 제시했습니다. 저는 50배라는 크기만큼, 어떤 작업에서 나온 수치인지가 궁금했습니다.

DBOS가 Postgres 삭제 성능을 높였다는 사례와 이어집니다. 그때는 외래 키를 제거하고 테이블별 삭제와 VACUUM으로 데이터 정리 작업을 개선했고, 이번에는 샤딩으로 워크플로 처리량을 키웠습니다. 서로 다른 작업이지만 Postgres의 병목을 구조 변경으로 풀어 가는 시도가 이어집니다.

한 샤드(shard)의 지속 처리량을 초당 2만 건으로 두고, 워크플로 정보와 작업을 같은 샤드에 모았습니다. 한 곳을 더 밀어붙이는 대신 쿼리가 한 샤드 안에서 끝나도록 나눠 총량을 키운 점이 반갑습니다.

벤치마크는 단계가 없는 간단한 워크플로였고, 각 쿼리가 한 샤드에서 끝나야 선형 확장이 가능합니다. 초기에는 샤드가 8~16개이고 초당 20만 건을 넘을 때 작업을 가져오는 쿼리의 잠금 경쟁(lock contention)이 성능을 무너뜨렸습니다. DBOS는 워커가 잠금을 기다리지 않고 다음 샤드로 이동하게 해 이 문제를 완화했습니다. 단계가 있는 업무에서는 쿼리가 샤드 사이를 오가는지 살펴야 합니다. 그 이동이 잦으면 샤드 간 왕복 비용이 먼저 늘 수 있습니다.

자주 실행되는 단계가 있는 워크플로 하나를 골라 샤드 수를 바꾸며 처리량과 지연을 재 보십시오. 이어 한 샤드에 부하를 몰아 워커가 기다리지 않고 다른 샤드로 넘어가는지, 성능이 회복되는지 확인하십시오. 이 시험으로 100만 건이라는 수치가 내 업무의 처리량 목표와 얼마나 가까운지 가늠할 수 있습니다.

단계가 있는 실제 워크플로와 특정 샤드 과부하 뒤의 회복력 가운데 무엇을 먼저 확인하시겠습니까?