Skip to main content
공개 노트

시간가변 용량 시대의 스케줄링, 처리량 극대화의 해법

Views 10약 4분생성형 AI 활용
Summary

시간가변 용량 시대의 스케줄링, 처리량 극대화의 해법

구글 리서치가 최근 "시간에 따라 바뀌는 용량 아래에서 처리량을 어떻게 최대화할 것인가"라는 흥미로운 주제를 소개했습니다1. 클라우드, 네트워크, 전력, 데이터센터처럼 자원이 늘 고정돼 있지 않은 세상에서, 스케줄링은 이제 "순서 정하기"가 아니라 "변하는 환경과 협상하기"에 가깝습니다.

특히 이번 주제의 핵심은 non-preemptive throughput maximization under time-varying capacity입니다. 쉽게 말해, 한 번 시작한 작업을 중간에 끊지 못하는 조건에서, 시간대별로 달라지는 처리 용량을 잘 활용해 완료되는 작업 수(처리량)를 최대화하는 문제입니다. 단순해 보여도 현실에서는 꽤 까다롭습니다.

Time-varying capacity란 왜 중요한가

예전의 스케줄링 모델은 보통 서버 성능이나 네트워크 용량이 일정하다고 가정했습니다. 하지만 현실은 다릅니다. 어떤 시간에는 클라우드 자원이 넉넉하고, 어떤 시간에는 백업 작업이나 다른 사용자 트래픽 때문에 갑자기 줄어듭니다.

네트워크 관점에서도 대역폭은 이론적 최대치, 처리량은 실제로 전달된 양입니다23. 즉, "길이 넓다"와 "차가 잘 간다"는 다른 이야기죠. 여기에 지연, 혼잡, 패킷 손실까지 끼어들면 높은 용량이 곧 높은 처리량으로 이어지지 않습니다4. 그래서 시간에 따라 변하는 용량을 아예 모델에 넣고 스케줄링하는 접근이 중요해집니다.

비선점 스케줄링이 어려운 진짜 이유

non-preemptive, 즉 비선점 조건은 작업을 시작하면 끝까지 가야 한다는 뜻입니다. 영화 다운로드처럼 잠깐 멈춰도 되는 일이 아니라, 생산 공정이나 GPU 잡처럼 중단 비용이 큰 작업을 떠올리면 쉽습니다.

문제는 용량이 중간에 떨어질 수 있다는 점입니다. 오전엔 여유롭다가 오후에 자원이 급감하면, 짧고 가벼운 작업을 먼저 처리했어야 할 수도 있습니다. 반대로 긴 작업을 먼저 넣었다가 병목에 걸리면, 전체 완료 개수가 줄어듭니다. 네트워크에서도 전체 경로의 최대 처리량은 결국 가장 느린 구간, 즉 병목에 의해 제한됩니다2.

이 때문에 좋은 스케줄러는 "지금 당장 가능한가?"만 보면 안 됩니다. "이 작업을 지금 시작하면, 미래의 용량 변화 때문에 다른 더 많은 작업을 놓치지 않을까?"까지 계산해야 합니다. 여기서 처리량 극대화는 단순한 속도 경쟁이 아니라, 미래를 읽는 배치 전략이 됩니다.

처리량 극대화와 공정성은 어떻게 충돌할까

여기서 흥미로운 질문이 나옵니다. 처리량만 최대화하면 가장 쉬운 작업만 골라 처리하는 쪽으로 흐르기 쉽습니다. 네트워크 세계에서도 최대 처리량만 좇으면 비용이 큰 흐름은 굶주릴 수 있습니다. 반대로 max-min fairness는 작은 흐름이나 불리한 사용자를 보호하는 데 강합니다5.

즉, 최대 처리량은 시스템 효율에 강하고, 공정성은 사용자 경험 안정성에 강합니다. 둘은 종종 같은 방향이 아닙니다. 시간가변 용량 환경에서는 이 충돌이 더 심해집니다. 자원이 부족한 시간대엔 "누구를 살릴 것인가"가 곧 정책이 되기 때문입니다.

실무에서는 정답이 하나가 아닙니다. 실시간 서비스라면 공정성이 더 중요할 수 있고, 배치 처리 시스템이라면 처리량 극대화가 더 큰 가치일 수 있습니다. 결국 스케줄링은 알고리즘 문제이면서도 제품 철학의 문제입니다.

바뀌는 세상에서 스케줄링이 주는 시사점

이 주제가 중요한 이유는 명확합니다. 앞으로의 시스템은 점점 더 가변적이기 때문입니다. 재생에너지 비중이 높아지는 전력망도, 멀티테넌트 클라우드도, 혼잡한 네트워크도 모두 "용량이 시간에 따라 흔들리는 환경"입니다.

따라서 앞으로의 스케줄링은 평균 성능만 볼 것이 아니라, 언제 용량이 줄고 늘어나는지, 작업을 중간에 멈출 수 있는지, 처리량과 공정성 중 무엇을 우선할지를 함께 설계해야 합니다. 쉽게 말해, 좋은 스케줄러는 바쁜 사람의 일정표가 아니라 날씨까지 보는 여행 플래너에 더 가깝습니다.

실무자라면 먼저 자신의 시스템에서 "고정 용량"을 가정하고 있는 부분부터 점검해보면 좋겠습니다. 실제 성능 문제는 종종 알고리즘이 아니라, 잘못된 가정에서 시작하니까요.

참고

1Scheduling in a changing world: Maximizing throughput with time-varying capacity

2Network throughput - Wikipedia

3Latency vs Throughput vs Bandwidth: What They Mean and How to Monitor Them

4Bandwidth vs Latency vs Throughput: Differences, Measurement, and Troubleshooting Network Performance

5Max-min fairness - Wikipedia

이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.

틸노트는 사용자가 AI를 활용해 노트를 쉽게 작성하거나 편집할 수 있는 서비스입니다.

AI 스퀘어 단톡방에 함께해요

AI 활용과 틸노트 사용 팁을 나누는 오픈채팅방입니다. 입장 비밀번호는 tilnote입니다.

참여하기