Capordia요청의 최소 계약 작성하기
실행 가능한 요청은 소유자, 프로젝트, 사용 가능한 입력, 식별된 명령 또는 절차, 기대 결과를 명시합니다. 동시 사용 GPU 수, GPU당 메모리, 예상 소요 시간, 출력 저장 위치를 밝힙니다. 마지막으로 마감 기한, 그 기한의 이유, 지연이나 범위 축소를 승인할 수 있는 담당자를 명시합니다.
이 정보가 없다는 사실을 높은 우선순위로 감춰서는 안 됩니다. 입력이 준비되지 않은 작업은 프로젝트가 중요하더라도 접수될 수 없습니다. 빠진 항목을 요청하고 재검토 시점을 정하세요. 그러면 큐는 의사 결정 도구가 됩니다. 아무도 시작할 수 없지만 누군가 자발적으로 처리해주기를 바라는 요청의 창고로 변하지 않습니다.
접수, 예약, 통행권 구분하기
접수는 작업을 검토할 수 있는지 확인합니다. 권한, 데이터, 호환성, 용량, 절차가 갖춰졌는지 봅니다. 그다음 예약은 정해진 시간대나 자원을 보호합니다. 우선순위는 사용 가능한 자원을 두고 경쟁하는 접수된 요청들 사이의 순서를 정합니다. 이 세 가지 결정은 서로 다른 사람이 내릴 수 있으니, 이러한 역할 분담을 명확히 하여 기술적 필요성에 대한 묵시적 승인이 생기지 않도록 하세요.
GPU가 비어 있다고 해서 모든 작업이 접수 가능해지는 것은 아닙니다. 필요한 디스크가 부족할 수도 있고, 라이선스가 동시 실행을 제한할 수도 있으며, 이전 결과가 필요할 수도 있습니다. 반대로 기술적으로 준비된 요청이 일정 결정을 기다릴 수도 있습니다. 아무도 해석할 수 없는 단순한 숫자 순위 대신, 이해할 수 있는 이유와 다음 조치를 표시하세요.
특권이 되지 않는 우선순위 정의하기
몇 가지 명확한 등급을 선택하세요. 예를 들어 확정된 외부 마감, 일상 업무, 확정된 날짜가 없는 탐색 등입니다. 누가 등급을 부여할 수 있고 어떤 근거 자료가 이를 뒷받침하는지 정하세요. 같은 등급 안에서는 선입선출이나 교대 규칙으로 선택을 예측 가능하게 만들 수 있습니다. 하나의 요청을 백 개의 작은 제출로 쪼갠다고 해서 다른 팀의 요청보다 기계적으로 백 배 더 많은 기회를 얻어서는 안 됩니다.
Slurm은 특히 접수 대기 경과 시간과 할당 및 소비된 자원에 기반한 공정 분배를 구분합니다. 이는 두 가지 다른 질문을 보여줍니다. 언제부터 기다렸는가, 그리고 이미 얼마나 사용했는가? 여러분의 규칙은 수동으로 남겨둬도 됩니다. 매개변수를 이해하지 못한 채 점수 공식을 그대로 가져오지 마세요. 특정 스케줄러의 가중치는 보편적인 공정성 기준이 아닙니다.
가상 예시: 다른 작업을 밀어내지 않고 긴급 작업 넣기
가상 팀 «설계도와 기준점»은 카드 한 장을 사용합니다. 9시에 설계도 프로젝트의 한 작업이 11시까지 확정된 시간 슬롯을 가지며 중단할 수 없습니다. 완전한 요청 두 건이 대기 중입니다. 기준점은 40분, 스케치는 80분입니다. 9시 30분에 기준점이 정오 리뷰를 위해 요청한 30분짜리 긴급 작업이 도착합니다. 이 모든 시간은 교육용 가정이며 측정값이 아닙니다.
현지 규칙은 승인된 긴급 작업이 이미 시작된 작업을 중단하지 않고 다음 해제 시점에 끼어들 수 있도록 허용합니다. 따라서 긴급 작업은 11시에 시작해 이론적으로 11시 30분에 끝납니다. 팀은 그다음 Esquisses에 통행권을 부여하여, 이미 긴급 작업으로 처리된 Repères가 큐를 독점하지 않도록 합니다. 이 예외와 Repères의 새로운 예상 시작 시점은 관련 책임자들에게 공지됩니다.
| 가정 시간대 | 프로젝트 | 통행 사유 |
|---|---|---|
| 9시–11시 | Plans | 이미 시작된 시간대, 중단 불가 |
| 11시–11시 30분 | Repères, 긴급 | 정오 이전으로 확정된 외부 마감 |
| 11시 30분–12시 50분 | Esquisses | Repères의 긴급 작업 처리 후 교대 |
| 12시 50분–13시 30분 | Repères, 일상 요청 | 다음 승인 가능한 요청 |
장시간 작업의 기아 방지
가장 짧은 요청을 항상 먼저 처리하면 대기열은 겉보기에 원활해 보이지만, 장시간 작업이 무한정 밀릴 수 있습니다. 예약된 시간 창이나 공지된 대기 기간을 기준으로 한 재검토를 마련하세요. 이 임계값은 내부적으로 정할 규칙이며, 보장된 서비스 기한이 아닙니다. 장시간 작업이 실제로 가용 기간을 초과한다면, 그 승인은 막다른 대기로 이어지기보다 새로운 일정으로 이어져야 합니다.
짧은 공백은 예약된 시작을 밀어내지 않는 작업을 수용할 수 있습니다. 이 결정에는 신뢰할 수 있는 추정, 실제로 호환되는 자원, 그리고 해당 시간 창 안에 완료할 수 있다는 가능성이 전제됩니다. 일정의 모든 여유를 새로운 약속으로 채우지 마세요. 편차를 흡수하기 위한 예비분은 공짜 슬롯이 아니며, 그 사용에는 담당자와 알려진 결과가 있어야 합니다.
범위가 명확한 취소를 마련하기
누가 자신의 요청을, 특정 프로젝트의 요청을, 또는 다른 작업에 위험해진 실행을 취소할 수 있는지 지정하세요. 아직 대기 중인 요청의 경우 순번에서 제외되었는지 확인하세요. 이미 시작된 작업의 경우, 무엇이 중단 가능한지, 무엇을 보존해야 하는지, 누가 그 출력을 기다리는지 먼저 확인하세요. "취소 요청됨" 메시지만으로는 자원이 아직 비었다는 것이 증명되지 않습니다.
실제 도구가 기술적 효과를 결정합니다. scancel 문서는 작업과 그 단계, 그리고 신호 전송과 작업 취소를 구분합니다. 동등한 도구를 사용하기 전에 관련 식별자와 범위를 확인하세요. 편의를 위해 전체를 선택하는 것은 피하세요. 그런 다음 프로세스 종료와 부분 출력의 목적지를 확인하세요. 데이터 복구 계획은 이 우선순위 규칙과 별도로 마이그레이션 문서에서 다룹니다.
재시도 횟수를 제한하고 결함 있는 작업을 격리하기
실행 전에 동일한 원인에 대해 허용되는 자동 재시도 횟수를 결정하세요. 유효하지 않은 입력은 다시 실행해도 올바르게 되지 않으며, 일시적으로 접근할 수 없는 의존성은 확인 후 재시도가 정당화될 수 있습니다. 규칙에는 최대 횟수, 가능한 지연 시간, 재검토 담당자를 명시해야 합니다. 새 제출마다 카운터를 초기화하면 이 보호 장치가 무효화됩니다. 연속된 요청을 동일한 문제에 연결하세요.
정한 한계에 도달하면 결함 있는 작업을 정상 경합에서 제외하고 읽을 수 있는 사유와 함께 논리적 격리 상태로 두세요. 나머지 승인 가능한 작업은 계속될 수 있습니다. 복귀에는 수정 또는 검증된 설명, 소규모의 표적 검사, 소유자의 결정이 필요합니다. 복귀는 예전 긴급성의 우선순위를 자동으로 회복하지 않습니다. 이 절차는 실패 후의 승인을 다룹니다. 출력 보존과 재개는 마이그레이션 문서에 남아 있으며, 여기서 새로운 상태 레지스트리를 만들어내지 않습니다.
네 가지 간단한 상황으로 정책 테스트하기
프로젝트 담당자들이 네 가지 사례로 이 규칙을 검토하게 하세요. 동일한 두 요청, 중단 불가능한 작업 중 발생한 긴급 상황, 짧은 요청들에 둘러싸인 장시간 작업, 그리고 긴급으로 분류된 불완전한 요청입니다. 각 사례마다 서로 다른 사람이 동일한 다음 시작 시점에 도달하거나 필요한 중재를 명시적으로 식별해야 합니다. 작성자만 이해하는 규칙은 적용할 준비가 되지 않은 것입니다.
또한 취소가 동일한 용량을 두 번 부여하지 않는지, 그리고 막힌 작업이 다른 승인 가능한 작업을 불필요하게 방해하지 않는지 확인하세요. 이러한 검증은 종이 위에서 시작할 수 있지만, 스케줄러의 구현을 증명하지는 않습니다. 이후 자동화한다면, 프로젝트 약속을 이에 의존시키기 전에 구성된 도구에서 동일한 시나리오를 재현하세요.
대기열이 제공하는 서비스 측정하기
클래스별, 프로젝트별로 접수 가능한 요청의 대기 상황과 차단 사유를 추적하세요. 대기, 점유, 그리고 수락된 결과까지의 지연을 분리하세요. 완료된 작업의 총합 하나만으로는 항상 밀려나는 팀이나 긴급 작업의 누적이 가려질 수 있습니다. 추정 점유와 실제 점유의 차이도 살펴보세요. 이는 향후 예약에 직접 영향을 줍니다.
팀과 정한 시점에 또는 누락된 규칙을 드러낸 사고 이후에 정책을 검토하세요. 한 번에 하나의 규칙만 바꾸고, 이미 존재하는 요청에 미칠 영향을 공지하세요. 기대되는 결과는 설명 가능한 처리 순서, 추적 가능한 예외, 일관된 일정입니다. 이는 Capordia 계정 인증이나 머신 권한을 대체하지 않으며, 어떠한 지원 보장도 만들지 않습니다.
결정을 위한 질문
긴급 작업을 항상 최우선으로 처리해야 하나요?
긴급 작업은 공통 규칙에 따라 접수 가능하고 정당하며 승인되어야 합니다. 긴급하다고 해서 진행 중인 작업을 중단할 수 있는 것은 아닙니다. 진입 지점, 밀려나는 요청, 그리고 그 마감일에 미치는 영향을 책임질 사람을 정하세요.
한 팀이 슬롯을 독점하지 않도록 하려면 어떻게 해야 하나요?
이미 확보한 리소스와 다른 프로젝트의 대기 상황을 살펴본 뒤, 순환 방식이나 명시적인 분배 규칙을 사용하세요. 요청의 원시 개수는 공정성의 척도가 아닙니다. 장시간 작업의 처리도 함께 마련하세요.
이 방법은 Slurm 설치를 요구하나요?
아니요. Slurm 문서는 몇 가지 구분에 도움을 주지만, 정책은 우선 팀의 조정 도구에서 적용할 수 있습니다. 향후 자동화가 필요하다면 그 자체의 구성과 검증이 필요하며, 어떤 스케줄러도 기본 제공된다고 가정하지 않습니다.