Mission Control 2.5, Run:ai Kubernetes 작업으로 복구 기능 확대

NVIDIA는 10월 26일 Mission Control 2.5의 자율 복구 기능을 NVIDIA Run:ai가 관리하는 Kubernetes 작업으로 넓혔다고 설명했다. 이전 대상은 Slurm을 쓰는 고성능 계산 작업이었다. 이번 호는 10월 28일 발행이므로 원문 날짜와 혼동해서는 안 된다. 글에는 평균 복구 시간이나 가용성 향상을 측정한 수치, 수동 운영과의 통제 비교가 없다. 제품 이름만으로 모든 학습 작업을 손실 없이 즉시 재개할 수 있다고 단정할 수 없다.

구조에는 세 역할이 있다. Kubernetes 스케줄러는 사용 가능한 노드에 작업을 배치한다. 작업 복구 서비스는 실패 당시 맥락을 모아 재시도, 재배치, 담당자에게 전달할지를 판단한다. 하드웨어 복구 서비스는 의심 장치를 격리하고 진단한다. 작업을 건강한 장치로 옮기는 동안 고장 원인을 계속 조사할 수 있지만, 어느 시점부터 이어서 실행할 수 있는지는 각 작업의 체크포인트와 설정에도 달려 있다.

하드웨어 오류 예시에서는 GPU 오류, 멈춘 작업자, 통신 시간 초과가 단서가 된다. 작업 복구 쪽은 정보를 저장하고 스케줄러를 통해 작업을 다시 시작하거나 옮긴다. 하드웨어 쪽은 동시에 해당 노드를 배치 대상에서 빼고 사유를 기록하며 진단을 시작한다. 다음 작업이 고장난 노드에 놓이지 않도록 하려는 설계다. 원문의 그림은 의도된 절차를 보여 줄 뿐 실제 사고 건수나 성공률을 나타내지 않는다.

일시적인 소프트웨어 실패에는 다른 대응이 필요하다. 프로세스가 종료돼도 장치 자체는 건강할 수 있으므로 정책에 따라 재시도하고 불필요한 격리를 피한다. 반복되거나 재시도할 수 없는 실패는 조사로 넘긴다. 또 장치 상태가 서서히 나빠지는 신호를 미리 발견하면 새 작업을 배치하기 전에 노드를 제외하고 검사할 수 있다. 모든 실패를 같은 방식으로 처리하지 않는 것이 핵심이다.

도입을 판단하려는 운영팀은 자기 작업에서 통제된 오류를 주입하고 완료율, 체크포인트 이후 잃은 계산량, 격리된 용량과 복구 시간을 측정해야 한다. 건강한 노드를 잘못 격리하면 자원이 낭비되고, 고장 노드에 계속 재시도하면 장애가 길어진다. 이번 글로 확인할 수 있는 새 사실은 Run:ai 기반 Kubernetes로 지원 범위가 확대됐다는 점과 세 역할의 협업 방식이다. 비용이나 GPU 생산성이 개선됐다는 성과는 별도 자료가 필요하다.

다른 NVIDIA 글에서 설명한 원격 측정이나 GPU 이용률 수치를 이 복구 기능의 성과로 옮겨서는 안 된다. 문제를 알아채는 신호와 작업을 재개하는 판단은 연결되지만 동일한 기능이 아니다. 특정 프레임워크에서 체크포인트가 일관되게 복원되는지, 노드 격리가 실제 배치 결정에 반영되는지도 운영 환경에서 별도로 살펴야 한다.

작업 복구와 장치 복구를 서로 다른 서비스로 둔 이유는 하나의 오류 신호가 여러 원인을 가질 수 있기 때문이다. 예를 들어 통신 시간이 초과됐다고 해서 항상 네트워크 장치나 GPU가 고장난 것은 아니다. 작업의 실패 기록과 장치 상태를 함께 보아야 건강한 노드를 불필요하게 격리하지 않는다. 반대로 장치 경고가 반복되면 겉으로 아직 작동하는 노드를 새 작업에 배치하는 것이 위험할 수 있다. 원문은 두 경로가 병렬로 움직이는 예를 보여 주지만 각 판단의 정확도를 숫자로 평가하지는 않았다.

운영자가 실제로 검토할 항목에는 복구 중 접근 권한과 감사 기록도 있다. 어떤 서비스가 노드를 배치 대상에서 제외했는지, 어떤 이유로 다시 넣었는지, 재시도 횟수와 마지막 체크포인트가 무엇인지 남겨야 뒤늦게 오류를 분석할 수 있다. 이 항목들은 기사에 제시된 역할 분리를 바탕으로 한 운영 평가 제안이며, NVIDIA가 모든 환경에서 이 기록을 동일한 방식으로 구현했다고 주장하는 것은 아니다. 실패를 자동으로 처리하는 범위가 넓어질수록 사람에게 전달되는 예외와 수동 복구 절차도 명확해야 한다.

이번 기능 확장을 이미 발표된 모든 AI 공장 성과와 합쳐 쓰지 않는 것도 중요하다. 같은 회사의 다른 도구가 원격 측정과 작업을 연결한다는 사실은 Mission Control의 실제 복구 시간을 알려 주지 않는다. 업그레이드 전후에 동일한 오류 유형을 시험하고 작업 완료율과 낭비된 계산 자원을 비교해야 비로소 구체적인 개선을 주장할 수 있다. 그 전에는 Kubernetes와 Run:ai로 지원 범위가 넓어졌다는 사실, 작업·장치·스케줄러가 분리된 제어 경로만 확인된 결론으로 남는다.