이 논문에서는 AWS에서 general-purpose inference serving system인 MArk를 제안하고 이를 통해 SLO 준수 및 비용 효율성이라는 이중 과제를 해결하는 것을 다룬다.
ML에서 SLO가 필요한 이유?
ML을 학습하는 것은 많은 시간이 필요하고 offline에서 진행이 가능하지만, 실제 제공되는 서비스는 real-time으로 연산이 수행되는 inference 부분이다. 그래서 cost-effective하고 low-latency를 보장하기 위해 SLO를 준수하며 ML 모델에 맞는 provisioning이 필요하다.
MArk 설계 특징
(1) MArk는 동적인 request를 배치하고, 이들을 performance-cost ratio를 높이기 위해 기회주의적으로 비싼 하드웨어 accelerator를 사용하여 서비스를 제공한다.
(2) feedback control scaling 또는 동적인 워크로드에 대해 over-provisioning하는 것에 의존하기 보다는 낮은 비용을 지불하고 provisioning latency도 숨기기 위해 predictive autoscaling을 사용한다.
(3) MArk는 stateless nature of inference serving의 특성을 이용해서, 유연하지만 비용이 많이 드는 serverless instance를 활용하여 예측하기 어려운 가끔씩 발생하는 load spikes를 처리한다.(IaaS인 EC2는 확장성이 떨어지고, load spike에 취약함, 그래서 이런 요청에 대해서는 비용은 더 들지만 유연한 serverless instance를 활용해서 해결함, 이 논문에서는 IaaS를 다시 provisioning하고 over-provisioning을 하게 하는 것을 비효율적이라고 다루고 있음)
성능 평가
AWS의 SageMaker를 baseline으로 사용하여 MArk의 성능평가를 진행하였다. 그 결과 SLO 요구사항을 준수하며, 심지어 더 좋은 latency 성능을 보여주었고, Spot Instance와 interruption-tolerant mechanism을 통해 burstable instance를 활용한 경우, SageMaker보다 최대 7.8배 비용을 감소시켰다.
Critique
비용을 낮추기 위해 Spot Instance를 활용한다는 점은 쉽게 생각할 수 있는 부분이지만, 이때 발생하는 interruption 문제를 고려해서 비용을 낮추면서도 문제가 발생할 수 있는 부분에 대비하고 성능을 높이기까지 했다는 점이 가치있다고 생각한다.
- 정형검증의 구체적인 기법으로는 symbolic execution, program proof/verification, model checking, program synthesis 등이 있음
Symbolic execution
- 입력을 a와 같은 기호로 나타내고 프로그램의 수행 결과를 symbolic expression을 통해서 나타냄
- 한계 1 : index의 값이 변수로 표시된 경우나 포인터가 사용되면 어려움이 있음
- 한계 2 : 반복문이 몇 번 수행될지 결정할 수 없고, loop invariant를 알기 전에는 symbolic expression으로 표현할 수 없다.
- tools : KLEE, PathFinder, SAGE, CUTE
Program verification
- 프로그램 또는 특정 구문에 대해서 {P} C {Q}로 표시함 (P : precondition, Q : postcondion)
- 모든 입력에 대해서 제대로 작동한다는 것을 테스팅할 필요가 없다는 발상의 전환에서 시작된 기법
Theorem Prover
- tools : Coq. Isabelle, PVS
- 제약 1 : 사용법을 배우고 실제 현장에서 쓰기 위한 진입장벽이 높다
- 제약 2 : 정리증명기를 사용하는 개인의 능력과 경험에 따라서 증명의 성공과 실패 여부가 달라질 수 있다
- 장점 : 상태폭발(state explosion)의 문제에서 자유롭다
Model Checking
- 장점 1 : Theorem Prover과 달리 진입장벽이 낮다
- 장점 2 : 증명과정 전체가 자동화되어 있어서 증명에 성공하면 true를 아니면 반례를 출력해줌
- tools : SMV, SPIN, PathFinder, SLAM
- 제약 1 : 분석해야하는 상태가 급격하게 늘어나 상태폭발 문제로 검사가 불가능한 경우가 발생할 수 있음
A Candid Industrial Evaluation of Formal Software Verification using Model Checking - 리뷰
Introduction
Model checking의 장점은 이를 통해 주목할만한 특성들이 true인 것에 대한 확실한 증거를 제공해준다는 점에 있다. 하지만 Model checking은 (1)state explosion, (2)regulatory limitation, (3)lack of relevant skill, (4)inadequate model validation과 같은 한계를 가지고 있다. 이를 극복하기 위해서, 실제 시스템을 테스팅하거나 실제 모델과 실제 시스템을 비교하기 위한 추가적인 분석이 필수적이다.
safety-critical software industry의 21명의 엔지니어를 대상으로 다음과 같은 설문 조사를 진행하였다.
(1) Awareness of model checking
(2) Whether model checking should be used
(3) Why they thought that model checking was not used
(1), (2)를 통해 엔지니어들이 model checking을 잘 모르지만 좋은 아이디어라고는 생각하고 있음을 확인할 수 있다. 그리고 (3)을 통해 관리자로 부터의 지원 부족과 관련 지식 부족이 방해물이 되고 있음을 확인할 수 있다.
이 연구의 목적은 model checking 기법이 ‘standard industrial environment’에서 ‘usefully’하게 성능을 보이게 하는 것이다. 여기서 말하는 ‘usefully’는 더 싸고, 빠르고, conventional testing 또는 review보다 더 철저하고, subtle error를 찾는 것에 대해 더 철저한 것을 의미한다. 그리고 ‘standard industrial environment’는 엔지니어가 바로 액세스할 수 있는 툴을 사용하는 환경, 산업계에서 볼 수 있는 모델, 산업계에서 볼 수 있는 일반적인 오류를 포함하는 환경을 의미한다.
Case Study Data
gas tubine aero engine domain의 health monitoring system과 MATLAB과 Simulink로 실행되는 MERVE를 모델로 삼았다. Simulink는 산업계에서 널리 사용되는 툴이고, model checker SDV를 포함하고 있다.
Case Study Process
- Investigated Errors
산업계에서 일반적으로 존재하는 문제들의 카테고리를 결정하는 것이 이 차례의 목적이다. 전체 PR의 갯수는 1477개 이고, 우선 아래와 같은 다섯 가지의 타입으로 PR(Problem Reports)을 나눴다.
• PRs that have been cancelled;
• PRs relating to hardware;
• PRs that introduce new features;
• PRs that make general improvements;
• PRs for document-only updates.
possible 카테고리에 있는 모든 PR을 자세히 검사하지 않고, 많은 순서대로 정렬해서 매 열번째 PR을 골랐다. 그렇게 총 49개의 PR이 어떻게 model checking에 의해 탐지될 수 있었는지 자세하게 검사하고 다음과 같이 분류했다.
• Property violation: a specific requirement was violated by the underlying requirements or design;
• Emergent: no requirement was violated, but the actual behaviour did not meet the designer’s intent;
• Consistency: typographical and non-functional errors.
- Model Checking
각 오류는 MERVE 모델과 함께 model checker를 사용하여 감지 될 수있는 방법을 결정하기 위해 분석되었다.
MERVE는 70000개가 넘는 블록들과 수백개의 입력값과 출력값을 가지는 큰 모델이다. 이 연구에서는 다음과 같은 이유로 전체 모델에 대해 model check을 하지 않았다.
(1) 현재 도구로 분석하기에는 state space가 너무 클 수 있음
(2) Simulink 기능을 활용하여 작성되었고, SDV에서 모두 지원되는 것이 아님
(3) 이 모델은 SDV를 사용할 수 없는 MATLAB 2007 버전으로 작성되었음. 2010버전으로 실행해야 했으며, 전체가 호환되지 않았음
(4) 테스트할 속성과 관련없는 시스템의 부분들을 제거하면 학습이 더 빨라짐
문제와 관련된 부분을 분리하여 분석하는 방법이 있을 수 있지만, 이는 다른 부분과의 상호 작용이 누락될 수 있으며, 모델의 관련 부분을 제외시킬 위험이 커진다. 실제로 model checker는 전체 모델을 확인하는 수단으로 사용되지 않고 특정 기능을 목표로하고 테스트를 통해 기능을 보강한다.
49개의 PRs을 검사한 결과, 42개는 model checking에 익숙했고, case study에 사용된 모델에서는 9개만 나타났다.
- Top-Down Verification of Requirements
model checking을 사용하면 conventional reviewing보다 약 두배의 시간이 걸린다. 하지만 숙련된 SDV 사용자는 properties를 더 빨리 생성할 수 있고, properties가 생성되면 자동으로 결과 및 보고서를 생성하여 몇초 만에 다시 실행할 수 있다. 그리고 model checking을 이용하면 개발 프로세스 초기에 오류를 찾아서 시간을 절약할 수 있다.
- Certification using Model Checking
MERVE와 같이 모델이 자동으로 생성되는 경우, 모델과 실제 시스템 간의 차이가 줄어 보증 프로세스가 간소화된다. 그리고 소프트웨어 디자인이 모델과 일치함을 보이기 위해 수동으로 검토를 할 수도 있다.
Discussion and Observations
- Errors Found
model checking의 전제는 property의 증거를 제공해서 모델의 정확성에 대한 높은 신뢰도를 제공한다는 점이다. 그리고 model checking을 통해 기존의 많은 오류가 발견될 수 있었으며, 이는 개발 주기의 초기에 발견될 수 있다. 하지만 오류가 조기 발견된다는 사실은 알 수 있었으나, 기존 검증보다 더 많은 오류를 발견한다는 증거를 찾을 수 없었다.
- Certification
SDV는 독점적인 도구이고, certification은 독점적이므로 SDV가 실제로 자격이 있는지 또는 자격이 있는지 여부를 결정할 수 없다.
- Effort
conventional verification에 필요한 노력을 추정하고 이를 SDV를 사용하여 소비한 노력과 비교했다. SDV를 사용하면 빠르게 요구 사항을 처리할 수 있고, 이를 반복적으로 할 수 있다. 그리고 SDV의 이점은 작성된 결과 보고서를 자동으로 생성한다는 점이다.
- Simplicity
SDV는 모델링 환경에 직접 통합되고 대부분의 요구 사항은 단순한 'implies' 관계에 매핑되므로 high-level requirements를 공식적으로 모델링된 property로 간단하게 변환 할 수 있다.
- Modifications to the Model
경우에 따라 SDV와 호환되도록 원래 모델에서 블록을 제거해야했다. 그리고 수정된 모델에서 입증된 property가 코드가 생성되는 원래 모델에서는 적용되지 않을 수 있기 때문에 문제가 발생한다. 모델을 개발할 때 SDV가 지원하는 블록만 사용하여 이를 피할 수 있다.
Validity and Limitations
호환성 문제로 인해 더 다양한 모델을 평가하기 위해 추가적인 작업이 필요하다. 전통적인 방법으로 오류를 발견했었는지 여부가 병확한지 않을 수 있다. 명확하지 않은 model checking은 잠재적인 어려움이 있다.(ex. state exlosion) 실제 model checking을 통해 모든 부분이 모델링되기는 어렵기 때문에 전통적인 검증 기능을 유지할 필요가 있다. 그리고 모델을 얻는 것에서도 어려움이 있을 수 있다. model checking은 안전이 중요한 소프트웨어 표준에 언급되지 않았고, 이를 갖춘 model checker가 없다. 이 연구에서는 하나의 model checker를 사용했지만, 실제로는 여러 model checker를 사용하는 것이 좋다.
Conclusions
Moder checking은 다른 전통적인 검증 기법보다 더 많은 에러를 찾을 잠재력을 가지고 있고, 에러를 개발 사이클에서 일찍 발견할 수 있게 해준다. Model checker가 high-level requirement에 맞는 증거와 반례를 찾는데 빠르고 효과적이라는 것을 실험을 통해 보여주었다. 그리고 verification case를 다시 실행하는데 몇초밖에 걸리지 않으므로 수동으로 검토하는 것 보다 훨씬 빠르다.
이 연구를 통해서 model checking이 유용성을 손상시키는 몇 가지 요수가 있음을 보였다. 모델을 개발하고 검토하는 과정과, model checker와 호환되도록 테스트 중인 모델을 조정하는 것이 수동 테스트 및 검토를 수행하는데 걸리는 시간과 비슷하다. 그리고 SDV는 high-level requirement 모델링 오류, 도구의 제한으로 인해 결론에 도달하지 못하기도 했다. 그래서 기존의 검증이 여전히 필요하다.
이 연구는 산업에서 model checking이 유용하게 적용될 가능성은 있지만, 아직 해결해야하는 미해결 문제가 있음을 보여준다.
(1) 다른 도구의 산업적 사용에 대해서 추가로 조사되어야 한다.
(2) 이 연구에서 제시된 아이디어를 홍보하는 것이 어렵다.
(3) model checking을 통해 감지할 수 있는 문제의 수에 대한 결론을 내리려면 다양한 영역을 다루는 추가 사례 연구가 필요하다.
(4) 전통적인 검증과 model checking을 비교하기 위해 추가 작업이 필요하다.
(5) 특정 경우에 대해서는 SDV로 property를 입증할 수 없다.
(6) assurance argument가 수용가능한지에 대한 추가 작업이 필요하다.
공부한 점
사실 model checking이라는 개념이 너무 생소해서 논문을 읽고 이해하는 과정이 많이 힘들었다. 그래서 원리를 이해하기 보다는, 이를 통해 얻을 수 있는 이점과 한계를 위주로 이해하도록 노력했다. 현재 model checking 기법을 사용하면 반복적인 검증에 대해서는 효과를 볼 수 있겠지만, 전통적인 검증 기법과 비교할 때, 처음에 준비단계가 전통적인 검증 기법만큼 오래 걸린다는 점을 고려할 필요가 있다. 그리고 model checking을 통해서 전반적인 시스템을 모델로 검증하기에는 state explosion과 같은 문제 때문에 현실적으로 어렵고, 실제로 model checking은 부분적인 시스템에 대해서 검증할 때 활용되고 있다. 그래서 아직까지는 전통적인 검증 기법이 유효할 수 있으며, 아직 model checking에 대해 더 많은 연구와 개선이 필요함을 느낄 수 있었다.
출처
소프트웨어공학 개론, 차성덕
A Candid Industrial Evaluation of Formal Software Verification using Model Checking, Matthew Bennion, Ibrahim Habli
- Selection Service : keyword matching, esmantic similarity, past populariy와같은것들을통해서검색함
- Ranking Service : 사용자가더좋은검색결과를얻을수있도록관련된문서를예측해서더상단에서노출될수있게함
- Reranking Service : 이미지와같은추가적인 content types에대해추가하고랭킹을매김
insight
현대시스템은소프트웨어로직파라미터, 하드웨어 configuration, actions of an execution sequence, engine selection, hyper-parameters of ML/DL algorithms and model과같이컨트롤가능한시스템 knobs를함수로추상화할수있음
1) Source of System Complexity
- Heterogenous claasses of decision-makings
system operator가 knobs를제어하는것은가능하나, 모든조합에대해효과를고려하면서최적의 knobs를구성하는것은어려움
ex) prioritizing system exploration benchmarks based on how they are expected to help the predictive model accuracy, and scheduling jobs of heterogenous requirements for the resource pool
AutoSys를실제로사용하는내용이포함되어있지않아, 실제로각각의 Plane에서이뤄지는작업내용을파악하기힘들었음. 각각에대해무엇을해야한다와같은내용은서술되어있지만, 실제로어떤작업을파악하기힘들게작성이되어있어서아쉬움. 그리고 Web Search를베이스로얻은 insight만을활용해서서술되어있어다른시도도같이해봤으면좋았을것같다는생각이들었음
automatically generated test tool을이용해서 fault를탐지하는것이어려운일이라는것을이논문을통해서확인할수있었다. 그리고아직까지는하나의툴만이용하는것이아니라다양한툴을통해테스트하는것이더좋을것같고, tool의성능을향상시키기위해더많은노력이필요해보임을느꼈다. 그리고 test를자동으로만드는것의한계를느껴, test를기반으로코드를작성하는 TDD와같은기법을사용해서결함이없도록코드를작성해가는방향이지금으로써는최선이아닐까하는생각도들었다. 하지만, 프로젝트의규모가커질수록 test를관리하는것이어려워질것이고이를보조하기위한 automatically generated test tool의필요성은계속남아있을것같다.
Microsoft 개발자들은 코드 리뷰의 가치와 중요성을 인정하고 있고, 다음과 같은 life cycle을 공유하고 있다.
1. 리뷰할 코드를 준비한다.
2. 리뷰어를 선정한다.
3. 선정된 리뷰어와 stakeholder들에게 알림이 전달된다.
4. 리뷰어와 stakeholder들에게 피드백이 제공된다.
5. 추가 작업에 대해 소통이 반복된다.
6. 코드 변경이 체크인된다.
대부분의 Microsoft engineer은 CodeFlow를 사용한다. 하지만 face-to-face 토론, whiteboard 세션, videoconference와 같은 다른 채널을 통한 코드 리뷰가 논쟁의 여지가 있거나, 빠른 답변을 위해 사용된다. 그리고 사소한 코드 변화에 대해서는 체크인을 하지 않는 팀도 종종 있다.
Microsoft engineer는 코드 리뷰를 통해 코드의 성능을 높이기, 결함 찾기, 지식을 전달, 다른 솔루션 찾기, 개발 프로세스 향상, breaking build 피하기, 팀의 awareness 향상, 코드에 대한 ownership 공유, 팀을 평가하기 등을 얻고자 한다.
<Code-Reviewing Challenges>
For Authors
- 리뷰어들에게 리뷰를 요청해도 답변이 없어 결국 직접 방문해서 물어보는 경우가 있다.
- 리뷰어들이 큰 이슈 보다는 너무 사소한 문제에 집중하는 경우가 있다.
- 적절한 리뷰어를 찾는 것이 힘들다.
- 리뷰 요청을 위한 준비를 할 때, 어떻게 작성을 해야하는지 잘 모르겠다.
- rejection을 받을 때, 이유를 받으면 좋겠다.
- 여러 커뮤니케이션 채널을 관리하는 것이 어렵다.
- 툴을 사용하는 것이 오히려 코딩 속도를 느리게 만든다.
For Reviewers
- 코드의 목적, 변화를 주게된 동기, 변화된 부분이 어떻게 실행되는지 등을 파악하는 것이 어렵다. 그래서 이를 해결하기 위한 Authors의 자세한 문서 작업을 필요로 한다.
- history of comment를 이해하는 것도 하나의 이슈이다.
- 평가하는데 있어 어떻게 하는 것이 좋은 영향을 줄지에 대한 통찰력이 부족하다.
<Best Practices>
For Authors
code change for review 준비 단계
- 리뷰 요청을 준비하면서, 변경점에 대해서 자세하게 체크한다.
- 이해하기 쉽도록 작은 변경점을 다루도록 한다.
- 관련된 변경점을 clustering한다.
- change에 대해 자세하게 묘사하고, motivation을 첨부한다.
- 리뷰를 요청하기 전에 change에 대한 테스트 또는 분석을 한다.
- 리뷰가 정말 필요한 change인지 체크한다.
리뷰어를 선정하는 단계
- 얼마나 많은 리뷰어가 필요한지 결정
- 알맞은 경험 또는 해당 코드에 대한 기초가 있는 리뷰어를 선택한다.
- 가능하다면 리뷰어들의 self-select를 허용한다
- 리뷰어 외 다른 사람에게 알릴 사람이 누구인지 체크하고, 사람들에게 spam하지 말 것
- 리뷰어들에게 가능한 빨리 알리고 change에 대해 설명한다.
For Reviewers
- 리뷰 전용 시간을 따로 정해둘 것
- 자주 리뷰하여 적은 change에 대한 리뷰를 할 수 있도록 한다.
- 가능하면 빠른 피드백을 해라
- 핵심 이슈에 집중하고, 사소한 일에 구애받는 것을 피해라
- 필요하다면 리뷰 체크리스트를 만들거나 사용해라
For Organization
- 긍정적인 리뷰 문화를 만들고 유지해라
- 코드 리뷰 정책을 개발, 반영, 수정하라
- 리뷰에 사용되는 시간이 계산되고 예상되는지 확인하고, 부정적인 영향을 주는지 확인해라
- 적절한 도구를 사용하는지 확인해라
- 적절한 리뷰 체크리스트에 대한 개발을 장려해라
- 코드 리뷰 활동을 위한 충분한 교육을 실시해라
- 프로세스에서 병목현상을 감시할 수 있는 메커니즘을 개발해라
<Trade-off>
코드 리뷰어를 선정하는데 있어 전문가나 시니어에게만 요청하면 주니어 팀의 성장 기회를 주기 어려워진다. 그리고 너무 많은 리뷰 유청이 전문가에게 집중되면 리뷰에 시간이 너무 오래 걸리고, 리뷰어들이 너무 많은 리뷰를 하다보니 정신이 없을 수 있다. 그래서 경험이 많이 필요하지 않은 리뷰 요청에 대해서는 주니어 팀을 활용하는 것이 좋다.
툴을 사용하는 것을 통해 시간을 절약할 수도 있지만 오히려 시간을 낭비하게 될 수도 있다. 왜냐하면 툴에 친숙해지는데 시간이 걸리거나, 툴을 사용하면서 오히려 프로세스가 느려질 수 있기 때문이다.
Q. 코드 리뷰를 특정 시간안에 진행하도록 강제하는 것이 필요할까?
<개인적인 의견>
코드 리뷰를 요청하는 쪽에서 자신이 요청하는 코드 리뷰의 난이도와 중요도를 정확하게 파악하는 것이 선행되어야 할것 같다. 이러한 정보가 리뷰어에게 같이 전달이 된다면, 리뷰어는 자신에게 쏟아지는 여러 코드 리뷰 요청들의 난이도와 중요도를 파악하여 일정을 스케줄링하여 빠른 시간안에 이루어져야 하는 리뷰를 우선적으로 처리할 수 있을 것이다.
그리고 개발자들에게 있어 리뷰를 하는 것은 중요한 일이긴 하지만, 메인 업무는 아니다. 그래서 리뷰를 특정 시간안에 하도록 강제하는 것인 실질적으로 이행되기는 힘들 것이라고 생각한다. 그래서 정말 급한 리뷰라면, 리뷰를 요청하는 쪽에서 다른 행동을 취하는 것이 맞다고 생각한다.
Q. 코드 리뷰를 요청하는 양식을 견고하게 정하는 것이 필요할까?
<개인적인 의견>
양식을 정하고, 양식을 따르는 것을 강제하게 하면 코드 리뷰를 요청하는 쪽에서는 리뷰를 요청하는 작업이 번거로워질 수 있지만, 이를 통해서 리뷰를 하는 쪽에서는 시간을 단축시킬 수 있을 것이다. 그리고 오히려 이렇게 하면 리뷰 요청을 준비하는데 걸리는 시간이 늘어나는 것이 비해 코드 리뷰를 진행하는 시간이 더 많이 단축될 것이라 생각하여 꼭 들어가야 하는 내용을 정하고 강제하는 것이 도움이 될 것이라고 생각한다. 그리고 오히려 양식에 어떤 내용이 들어가야 할지에 대한 논의가 필요하다고 생각한다.
참고자료
Code Reviewing in the Trenches: Challenges and Best Practices, Laura MacLeod, Michaela Greiler, Margaret-Anne Storey, Christian Bird, Jacek Czerwonka, IEEE, 2017
GPU 클러스터에서 딥러닝 모델 학습의 대기 시간과 효율성을 향상시키기 위해 domain-specific knowledge를 활용하는 클러스터 스케줄링 프레임워크인 Gandiva를 소개한다.
Introduction
딥러닝의 해결 과제로는 best result를 얻기 위한 hyperparameters 튜닝을 위한 feedback-driven exploration과 이질적인 딥러닝 job에 대한 best-fit을 찾는 것이 있다. Gandiva는 mini-batch iterations의 predictability를 이용해서 profile-driven introspection을 수행하여 이를 해결한다. 실제로 프로토타입을 통해 Gandiva가 hyper-parameter search 시간을 단축시켰고, 더 좋은 효율적이고 명확하게 job을 마이그레이션과 시분할을 하여job-to-resource fit을 얻을 수 있음을 보였다.
Background
딥러닝은 모델의 가중치를 이용한 연산인 forward pass 과정과 gradient를 이용해 각각의 가중치를 학습을 하는 backward pass 과정으로 이루어져 있다. 그리고 각각의 과정은 mini-batch iteration이라고 불린다. 그리고 이러한 iteration을 수백만번 반복하여 높은 task accuracy를 얻는다. Feedback-driven exploration은 hyper-parameters를 자동화해서 찾는 방법으로 이를 위해 multiple DLT job을 수행해야 하고 early-feedback을 통해 빠르고 효율적으로 수행된다.
Method
Exclusive access to fixed set of GPUs는 HOL 블로킹을 발생시키고, 할당된 GPU를 전부 사용하지 못하기 때문에 낮은 GPU 사용률을 얻게 된다. 이를 해결하기 위해 Gandiva는 incoming job을 시분할 처리해서 waiting time을 줄이고 HOL 블로킹을 방지하였다. 그리고 다른 GPU로의 효율적인 migration을 지원하여 locality를 보장하며 GPU에 job을 할당시킬 수 있게 하였다. 그리고 GPU grow-shrink mechanism을 지원하여 idle GPU를 기회주의적으로 사용될 수 있게 했다. 그리고 스케줄링 정책에서 두가지 모드를 가지는데, 이벤트를 관리하는 Reactive Mode와 모니터링과 최적화를 진행하는 Introspective Mode를 가진다.
Contribution
딥러닝 workflow의 다양한 고유 특성을 설명하고 클러스터 스케줄링에 필요한 특정 요구 사항에 매핑였다.
DLT 작업 스케줄링 정책에서 사용할 수있는 일반적인 프리미티브를 식별하고 주기적으로 반복되는 작업의 딥러닝에 특화된 지식을 활용하여 시분할 및 마이그레이션과 같은 프리미티브를 훨씬 효율적이고 실용적으로 만드는 application-aware 기술을 제공하였다.
DLT 작업에 대한 도메인 별 지식을 활용하여 일정 결정을 지속적으로 세분화하여 early feedback 시간을 크게 개선하고 높은 클러스터 효율성을 제공하는 새로운 introspective 스케줄링 프레임워크를 제안하고 평가하였다.
참고문헌
Gandiva: Introspective Cluster Scheduling for Deep Learning - Wencong Xiao, 2018
