우선순위가 높은 작업이 계속 들어와 낮은 작업은 오래 기다립니다. 중요한 작업을 먼저 처리하면서도 기아를 막으려면 큐와 실행 자원을 어떻게 조정하나요?

우선순위 큐는 높은 중요도의 작업을 먼저 선택하지만, 높은 작업이 계속 유입되면 낮은 작업이 무기한 대기하는 starvation이 생길 수 있습니다. “낮은 우선순위”가 “언제 처리되지 않아도 된다”는 뜻은 아니므로, 높은 요청의 응답 목표와 낮은 요청의 최대 대기·폐기 조건을 함께 정하겠습니다.

해법으로 클래스별 최소 실행 예산, 가중 라운드 로빈, 일정 비율의 low-priority 슬롯, 대기 시간에 따라 우선순위를 올리는 aging을 사용할 수 있습니다. 다만 deadline을 이미 넘긴 작업을 무조건 승격하면 유용하지 않은 작업이 자원을 차지할 수 있어 만료·취소를 먼저 확인합니다. 요청 개수가 아니라 실행 시간·메모리·외부 연결 점유가 다른 경우 긴 작업을 별도 큐와 시간 예산으로 분리합니다.

비선점 작업이 길면 높은 우선순위도 현재 작업이 끝날 때까지 기다릴 수 있으므로 chunking·취소 지점·worker pool 격리를 검토합니다. 고우선순위 부하를 지속 주입해 저우선순위의 p99 대기(느린 대기의 99번째 백분위수), 완료율, 만료율과 핵심 요청의 SLO(사용자 지연·오류 목표)를 함께 측정합니다. 고우선순위만 정상이고 낮은 요청이 계속 만료되면 공정성 정책이 실패한 것입니다. 우선순위는 과부하에서 손실을 어디에 배분할지 정하는 정책이지 전체 용량을 늘리는 방법은 아닙니다.

공정성을 예산으로 보장합니다

고우선순위가 계속 들어와도 저우선순위에 최소 슬롯·가중 실행 예산을 남기고, 대기 시간이 임계값을 넘으면 aging으로 순위를 올릴 수 있습니다. 다만 deadline이 지나 유용하지 않은 작업을 무조건 승격하면 자원만 소비하므로 만료·취소를 먼저 판정합니다. 요청 수가 아니라 CPU 시간·메모리·외부 연결 점유를 비용으로 삼아, 긴 작업이 짧은 작업의 슬롯을 독점하지 않게 별도 큐나 실행 예산을 둡니다.

비선점과 역전도 관찰합니다

이미 실행 중인 긴 작업은 우선순위가 높아도 선점되지 않을 수 있습니다. 가능한 작업을 chunk로 나누고 취소 지점을 넣거나 핵심·배치 워커와 연결 풀을 분리합니다. 클래스별 대기 p99·완료율·만료율과 실행 시간, 핵심 요청 SLO를 함께 봅니다. 고우선순위만 정상이고 낮은 작업이 계속 만료되면 aging 폭·최소 슬롯·폐기 기준을 조정하고, 공유 자원을 오래 잡는 낮은 작업 때문에 높은 작업이 기다리는 우선순위 역전도 별도 지표로 구분하겠습니다.

구체적인 경계 사례

실행 시간 1ms 작업 9개와 1초 작업 1개를 번갈아 처리하면 건수상 9:1이어도 시간은 긴 작업이 거의 독점합니다. 가중 예산은 완료 건수가 아니라 실제 비용을 반영해야 하며, 예상 비용이 틀릴 수 있으면 다음 라운드의 예산에서 보정하거나 작업을 작은 단위로 나눕니다. 낮은 작업에 최소 슬롯을 줘도 각 실행 시간이 무한하면 대기 상한을 보장할 수 없으므로 개별 작업의 상한이 함께 필요합니다.

aging에 상한을 두어 낮은 작업이 영원히 고우선순위를 넘지 못하면 원래의 기아가 남을 수 있습니다. 승격 폭 조절만으로 진행을 보장한다고 하지 않고 예약 실행 예산을 별도로 둡니다. 전체 도착률이 처리 능력보다 크면 모든 클래스에 무제한 대기 없는 성공을 줄 수 없으므로 수락 제한·만료·사용자 안내를 정책에 포함하겠습니다.