Jovan Stojkovic, UIUC
microservice 환경에서 peak 기준으로 VM 구성해서 대부분 CPU core가 idle임
core utilization과 throughput 개선 위해 core harvesting하는데 다른 VM의 유휴코어 훔쳐 쓰는 것
근데 VM간 코어 재할당은 hypervisor 호출, context switching, TLB 및 cache flush overhead 있음
이거 monolitic에선 수용가능한데 microservice에선 부담스러움 → software overhead 감소시킬 것
Cloud computing은 monolitic에서 microservice 조합 방식으로 paradigm shift for scalability. Amzon to Google 다양한 기업에서 채택함.
microservice instance는 VM이나 container 형태로 동작하며 request를 처리함 각 VM과 container는 정해진 수의 core와 memory 가짐
request 자체는 짧은데 instance는 수 일간 실행될 수 있는 장기 process이고 가끔 request는 bursty pattern을 보이기 때문에 여기 맞춰서 overprovisioning한다.
그래서 idle되는데 낭비 요인이라 많은 action있었음. 크게 두 그룹인데 primary VM (latency-critical application)과 Harvest VM (성능 좀 떨어지더라도 자원 변동 허용함. 더 쌈)
근데 (1) VM 코어 재할당하는 거는 Hypervisor가 detach와 attach 두 번 호출되고, (2) cross-VM context switch가 발생, (3) 또한 private cache와 TLB에 남은 정보 leakage (보안 문제) 막고자 flush 및 invalidate된다.
몇 ms 수준의 엄청난 overhead있는데 monolitic에선 참을만했는데 microservice에선 말도 안됨.
그래서 core 활용률 높이고 primary VM의 tail latency 안건드리고 harvest VM 개선하기가 목표
(1), (2)의 경우 microservice request 처리 용 hardware queue 추가. request 메세지의 payload는 LLC에 저장되고, 이 포인터를 HW queue에 기록한다. queue에서 왔다갔다 하면 hypervisor 없어도 되고 context switch 가속화됨.
(3)은 flush/invalidate 과정과 cold restart 문제인데, microserivce의 working set이 일반적으로 작다는 점에 주목하고 TLB와 private cache를 Harvesting 용도와 Non-harvest 용도로 이분하여, primary VM은 둘 다 쓰게하고, Harvest VM은 자기꺼만 쓰고, flushing도 harvest용만 하면 된다.
실험 결과 좋았고, HW 기반 core harvesting 제공할 수 있는 기회 요식 분석하고 아키텍처 제안했다.