Repository navigation
Experiments KO
Swarm 배포와 Agent 용량 설정 이후의 절차입니다. 저장 시나리오는 재사용할 입력, run은 한 번의 실행, batch는 반복 회차의 묶음, retry는 미완료 회차의 새 시도입니다.
- 대시보드의 Run experiment를 엽니다. 저장 시나리오를 불러오거나 YAML을 입력합니다. 필드는 시나리오 참조가 정의합니다.
-
Validate를 누르고 Agent 가용 상태를 확인합니다. 검증은 입력을 검사하며 실행 용량·연결까지 확인하지 않습니다. 작은 첫 실험은
examples/monitoring.yaml을 사용할 수 있습니다. - Runs를 지정하고 Run을 누릅니다. Experiment progress에서 진행을 확인하고 기록은 Saved results에서 확인합니다.
다른 실험이 실행 중이어도 Run experiment → Run을 여러 번 제출할 수 있습니다. 접수한 순서대로 Controller 대기열에 들어가며, 한 제출의 반복 회차가 모두 끝난 다음 제출을 실행합니다. 재시도·이어하기·Add runs도 같은 대기열을 사용합니다. YAML·seed·상속한 결과 그룹은 접수 시 확정합니다. 브라우저를 닫아도 접수한 작업은 유지됩니다.
Experiment progress에서 대기 중인 배치 앞에 몇 개의 제출이 있는지 표시합니다. 해당 항목의 중지 버튼은 그 제출과 반복 회차만 취소합니다. 실행 중인 배치를 중지하거나 실행이 실패하면 그 배치의 남은 회차만 취소하고, Peer 정리와 최종 telemetry 수집 후 다음 제출로 넘어갑니다. 성공한 단일 Run이 유지한 Peer도 다음 제출 시작 전에 제거합니다. 정리를 확인하지 못하면 다음 제출은 Waiting for previous Peer cleanup으로 대기하며, 정리 시도가 실패할 때마다 3초 후 재시도합니다. 그 대기 항목을 취소해도 이후 제출이 정리를 건너뛰지는 않습니다.
예약 대기 시간은 Run 시작 시각·phase timeout·schedule 시계에 포함하지 않습니다. Controller 재시작 시 예약한 결과는 interrupted로 남으며 Retry experiment / Retry from run으로 수동 복구합니다. 재시작 후 대기열을 자동 재실행하지 않습니다.
실험 네트워크 준비 API는 반복 회차·재시도·이어하기·추가 Run을 포함하여 매 Run 전에 새 Peer overlay를 준비합니다. Peer 정리 확인을 기다리고 모든 Agent가 새 네트워크를 수락한 뒤 실험 시계를 시작합니다. Preparing network 시간은 시나리오 phase와 schedule 시간에 포함하지 않습니다. 초기화 실패 시 첫 phase를 시작하지 않고 기존 실패·예약 규칙을 따릅니다. 제공되는 Swarm stack에서는 초기화를 활성화합니다. 기존 배포에는 갱신한 이미지와 stack이 필요합니다. 자동 네트워크 초기화를 참고하십시오.
Run experiment에서 YAML을 입력하고 Run 옆의 Runs를 1~100 정수로 지정하십시오. Controller가 모든 회차를 대기열에 등록한 뒤 순서대로 실행하므로 브라우저를 닫아도 계속됩니다. 회차마다 고유 run ID, 별도 결과 디렉터리, 메타데이터의 batchId, iteration, repetitions가 부여됩니다.
2회 이상이면 각 회차의 종료 정책에 따라 백그라운드 작업을 취소하거나 완료까지 기다리고, 해당 회차의 Peer 생성을 차단하고 제거한 뒤 Agent 상태를 갱신해야 다음 회차가 시작됩니다. 실행·정리 실패는 해당 배치의 남은 회차를 취소합니다. 실행 중이거나 대기 중인 항목의 Stop batch는 그 제출의 현재 회차와 나머지 반복만 취소합니다. 다른 제출의 대기 순서는 유지합니다.
모든 회차의 YAML은 동일합니다. 명시한 0이 아닌 seed는 재사용하고, 0이거나 생략되면 회차별로 새 seed를 생성해 기록합니다. 동일 seed는 표본 추출 입력을 반복하지만 Docker 타이밍, 후보 집합, 네트워크 실행 결과까지 동일하게 만들지는 않습니다. Controller 재시작 시 대기열을 자동으로 재개하지 않으며 남은 queued·running 기록은 interrupted로 표시합니다.
자동화는 실험 제출 API를 참고하십시오.
Saved results의 완료 그룹에서 Add runs를 누르고 Additional runs에 추가 수량을 입력한 뒤 총합을 확인하고 Add and start를 선택합니다. 10회 완료 그룹에 10회를 더하면 같은 배치 ID로 Run 11 of 20부터 Run 20 of 20까지 진행합니다. 저장된 YAML과 seed 정책을 재사용하고 기존 결과·개별 메모·Group 메모를 보존합니다. 완료된 단일 Run에도 추가하여 그룹으로 확장할 수 있습니다. 그룹 총합은 기존과 같이 최대 100회입니다.
현재 회차가 빠짐없이 완료된 그룹만 확장할 수 있습니다. 실행·종료 정리·다운로드·개별/배치 분석이 진행 중이면 추가를 막으며, 미완료 그룹은 기존 재시도·이어하기 기능으로 먼저 마무리하십시오. 새 회차 전에 이전 Peer를 정리하고 로컬 여유 공간 검사를 적용합니다. 중지·실패하면 새 대기 회차를 취소하며 Retry from run은 완료 회차를 반복하지 않고 미완료 추가분을 재시도합니다. 브라우저를 닫아도 접수된 실행은 계속됩니다.
추가 실행이 끝나면 Analyze batch mean으로 그룹 전체를 다시 분석합니다. 구성원이 바뀌면 기존 분석 캐시를 최신 결과로 재사용하지 않습니다. 10 + 10이면 20회 전체에서 정의된 지표의 기여 표본 수는 20이며 각 Run을 동일 가중치로 집계합니다. 이전 실패 시도는 계속 제외합니다. Completed 필터에서 추가했다면 그룹이 계속 보이도록 상태 필터를 All로 전환합니다.
최초 제출·재시도·이어하기·추가 접수는 모두 로컬 result-groups/<batch-id>/batch.json 기록으로 확정합니다. 확정 전 준비 중 중단된 예약은 롤백하고, 확정 후 재시작된 미완료 Run은 interrupted로 보존하여 재시도할 수 있습니다. 실패·시간 초과 요청은 결과를 새로고침한 뒤 재요청 여부를 판단하십시오. result-groups/도 백업에 포함해야 합니다. 기존 experiment.json과 과거 분석 스냅샷은 당시 총합을 유지하고 현재 목록·새 통합 분석은 확정된 그룹 총합을 사용합니다.
브라우저는 최초 제출 응답이 성공할 때까지 제출 키를 유지합니다. 응답이 유실된 뒤 같은 입력을 재전송하면 기존 그룹을 반환하여 중복 실행을 막습니다. 자동화에서는 API 가이드의 Idempotency-Key를 직접 지정하고 재사용하십시오.
최신 시도 정보는 개별 결과 삭제 후에도 유지됩니다. 최신 재시도를 삭제하면 해당 회차가 누락으로 남으며 이전 실패가 현재 회차로 되살아나지 않습니다. 그룹을 확장하려면 누락된 결과를 복구해야 합니다. 그룹 예약 기록이 손상되면 해당 그룹의 작업을 막고 Controller 로그에 남기며 다른 그룹은 사용할 수 있습니다.
진행 중 실험의 정지 버튼이나 반복 그룹의 Stop batch를 사용합니다. 취소가 접수되면 작업과 Peer를 정리하는 동안 **Stopping…**를 표시합니다. 반복해서 누를 필요 없이 상태가 확정될 때까지 기다립니다. 활성 배치를 정지하면 실행·대기 회차를 취소합니다. Controller 종료·비정상 종료의 정리 범위는 장애와 종료를 참고하십시오.
Peer 종료 시 HTTP 발행 요청에도 같은 취소 신호를 전달합니다. 발행 잠금이나 topic 준비를 기다리는 요청은 최종 telemetry drain 전에 신속히 종료됩니다.
접수된 실행 묶음마다 새 executionId를 부여하며 run ID를 재사용하는 이어하기도 마찬가지입니다. UI는 중지 요청에 이 값을 전달하고 대시보드를 새로고침해도 **Stopping…**를 유지합니다. 이전 실행의 지연된 중지 요청이 새 재시도·추가 실행을 취소할 수 없습니다. API 클라이언트도 X-KPL-Execution을 전달해야 합니다.
실행 상태, Peer 정리, 로그 수집 상태는 별개입니다. canceled만으로 정리 성공을 판단하지 마십시오. 저장 결과는 정리 실패와 불완전·미확인 로그를 함께 표시합니다. 자연 종료 후 Peer를 유지한 단일 실행은 cleanupState: retained, dataState: collecting이며 로그가 계속 바뀔 수 있습니다.
재시작 후 저장 상태가 running 또는 queued인 실험은 interrupted로 표시하며 ZIP 원본 메타데이터는 변경하지 않습니다. 이는 표시 상태이며 실제 Peer 종료를 증명하지 않습니다. 실시간 상태·카운터를 복원하거나 실행을 자동 재개하지 않지만 ZIP 지표는 보존된 로그에서 재계산합니다. 메타데이터를 읽을 수 없는 항목은 unreadable로 표시하므로 로그·저장 파일을 확인하십시오.
Runs 1–3 완료 후 Run 4 of 10이 실패했다면 목적에 맞게 선택합니다.
| 작업 | 다음 실행 | 이전 시도 |
|---|---|---|
| Continue remaining | 아직 시작하지 않은 Runs 5–10만 실행 | Run 4는 실패로 남으며 성공 10회를 채우는 대체 회차는 추가하지 않음 |
| Retry from run 4 | 미완료 Runs 4–10을 각각 첫 phase부터 실행 | 완료 회차는 보존하고 재시도 회차는 새 run ID를 사용하며 이전 로그를 유지 |
수동 복구 기능이며 phase 중간 지점 복원이나 자동 장애 전환은 아닙니다.
Saved results에서 중단된 시리즈의 **Continue remaining (N)**을 누르면 아직 시작하지 않은 회차만 재개합니다. 완료·실패한 회차와 그 밖의 이미 시작한 회차는 보존하고 다시 실행하지 않습니다. 원래 batch ID, run ID, 회차 번호, 전체 반복 수, 저장 YAML과 회차별 seed를 유지합니다. 예를 들어 Run 2 of 5에서 실패했다면 Runs 3–5를 실행하며, 성공 5회를 채우기 위한 대체 회차를 추가하지 않습니다. 배치 평균에는 계속 완료된 회차만 포함합니다.
Controller 재시작 후에도 저장 결과에서 재개할 수 있습니다. 실패 회차 또는 시작 후 interrupted가 된 회차가 있고 미시작 회차가 보존되어 있어야 합니다. Controller는 피어 생성 전에 기록한 소유 Agent에 정리를 재요청한 뒤 나머지를 시작합니다. Controller 재시작 후 Agent가 아직 재등록하지 않아도 저장된 소유 정보를 사용하며, 해당 Agent에 연결할 수 없으면 새 회차를 시작하지 않습니다. 소유 기록이 없는 과거 결과는 현재 등록된 Agent를 사용하므로 알려지지 않은 호스트의 정리까지 증명하지 못합니다. 정리가 실패하면 남은 회차는 시작하지 않고 오류를 표시하며 Continue remaining을 다시 시도할 수 있습니다. 이후 회차가 또 실패하면 나머지는 다시 중단됩니다. 중복 재개, 활성 배치, 다운로드와 진행 중인 분석 작업은 재개 접수를 막습니다. Stop batch로 재개 전 정리 단계도 취소할 수 있고, 브라우저를 닫아도 접수된 작업은 계속됩니다.
**Saved results → Retry from run N (수량)**으로 실패·중단된 회차를 포함한 미완료 회차부터 다시 실행할 수 있습니다. 완료된 회차의 결과는 유지합니다. 단일 실험 실패에는 Retry experiment를 사용합니다. Controller가 먼저 이전 Peer를 정리한 뒤 원래 시나리오·회차 번호·seed로 각 회차의 첫 phase부터 실행합니다. 정리가 실패하면 새 회차는 취소 상태로 남으며 원인을 해결한 뒤 다시 이어하기를 누를 수 있습니다. 이전 로그는 Previous attempts에 보존하고 배치 진행률·평균에서 제외합니다. 기존 Continue remaining은 시도했던 회차를 건너뛰고 미시작 잔여 회차만 실행합니다.
두 방식 모두 이전 Peer를 정리한 뒤 새 실행을 시작합니다. Agent 연결·정리 오류를 해결한 뒤 재시도하십시오. 활성 실행·종료 처리·다운로드·진행 중 run/batch 분석이 있으면 복구 접수가 거절될 수 있습니다. 접수 조건은 복구 API, 비교에 포함할 시도 이력 보고는 연구 원칙을 참고하십시오.
Experiment progress는 진행 중 → 제출 순서의 대기 항목 → 종료 순서로 표시합니다. 대기 중인 같은 제출의 반복은 회차 숫자 순서를 유지합니다. Saved results의 배치 내부는 Run n of M의 회차 숫자 순서를 유지하며 이전 시도는 별도로 표시합니다. 검색·내보내기·삭제는 결과 관리를 참고하십시오.
Experiment progress의 실행 중·대기 중인 각 Run에 Est. finish와 대략적인 남은 시간을 표시합니다. 카드 위 요약에는 진행 중인 반복 실행 그룹별 Group est. finish가 표시됩니다. 종료 시각은 브라우저의 현지 시간대이며, 남은 시간은 Controller가 같은 그룹에서 먼저 실행될 Run의 대기 시간까지 포함해 계산합니다. 앞선 배치나 이전 Peer 정리를 기다리는 제출은 시작 가능할 때까지 **Estimating…**으로 표시하며, 선행 작업이 해결되기 전에 확정적인 종료 시각을 제시하지 않습니다.
초기 Scenario estimate는 대기 시간, 반복 횟수와 샘플링한 interval을 계산하고 백그라운드 작업의 겹침, wait-jobs, stop-all, onExit을 반영합니다. 준비 배리어는 처음에 설정된 timeout을 시간 여유로 사용합니다. 요청 수는 설정된 최댓값을 사용하므로 실제 publish·leave 후보가 적으면 더 빨리 끝날 수 있습니다. 노드 기동, 용량 대기, 요청 처리와 정리 시간은 사전에 알 수 없습니다. 단계가 끝나면 실제 시작·종료 시각으로 예측을 갱신하고, 같은 진행 중 그룹에서 성공한 Run의 평균 단계 시간과 정리를 포함한 전체 소요 시간으로 이후 추정치를 보정합니다. 이때 Based on N completed runs로 보정 근거를 표시합니다.
예상치는 종료 기한이 아닙니다. 시간 정보가 부족하면 Estimating…, 예상을 초과하면 Taking longer than estimated를 표시하고 뒤의 대기 Run과 그룹의 예상 시각을 늦춥니다. Run 중지·종료 후에는 해당 예측을 제거합니다. 이 값으로 자동 중지하지 않으며 Saved results에 예측을 보존하지 않습니다.
Home · Documentation guide · kpl-v3 source
Commands run from the kpl-v3 source checkout.