TODO 및 연구 현황으로 보고 드립니다.
- 기존 가설 및 insight에 사용된 ‘Local DRAM’과 같은 device 중심 용어를 컴퓨터 구조적 측면에서 추상화된 계층 표현인 ‘fast tier’, ‘slow tier’ 로 수정하였습니다. 향후 용어 표현에도 같은 기준을 적용하겠습니다.
- 가설: In microservice environments that organize online services into fine-grained software modules distributed across multiple remote servers, the performance of tiered memory systems degrades in proportion to the number of memory pages allocated in the fast tier for remote communication.
- Evaluation에 앞서, microservice workload의 구조적 특성과 시스템 자원 소모의 패턴을 이해하기 위해 관련 배경을 다음과 같이 정리하였습니다. 이를 기반으로 하여 평가 methodology를 설계하고자 합니다.
[Microservice Workload Characteristics]
-
Microservice는 중첩된 (nested) 호출 구조를 가지며, 전체 서비스의 호출 경로는 graph 형태의 call tree로 표현된다. 이에 따라 microservice architecture의 성능 분석에는 전체 서비스의 call depth와 microservice간의 dependency가 반영되어야 한다.
-
하나의 사용자 요청은 수십 개의 microservice path를 포함할 수 있으며, 특정 software module에서 발생한 병목이 전체 요청에 대한 응답 지연을 유발할 수 있다. 따라서 전체 end-to-end 서비스의 tail-latency 및 Service Level Agreement (SLA) 만족 여부는 주요 평가 지표로 작용할 수 있다.
-
Microservice 구조에서 RPC 기반 통신은 송수신 queue, RPC 처리 stack, network stack 등 소프트웨어 계층의 추가적인 메모리 할당을 요구하므로 Request per Second (RPS) 증가와 메모리 할당에 대한 delayed reclaim은 fast tier 계층의 memory pressure를 증가시킬 수 있다.
Microservices [Gan et al., ASPLOS 2019]
[DeathStarBench suite]
-
DeathStarBench는 microservice workload 평가를 위한 대표적인 benchmark suite 중 하나로, 실제 cloud 서비스의 현실적인 호출 깊이를 반영한 총 5개의 end-to-end 서비스를 포함한다 [Gan et al., ASPLOS 2019].
- Social network, media streaming, E-commerce, banking, drone swarm (IoT) 등 실제 시나리오 기반 구성
- RPC framework (e.g. Apache Thrift, gRPC) 및 NGINX, Memcached, MongoDB 등 오픈 소스 소프트웨어 스택을 기반으로 구현
-
DeathStarBench는 다양한 microservice 연구에서 실증적 benchmark로 채택되어 왔으며, 신뢰성 있는 workload로서 선행 연구들과의 정합성을 확보할 수 있다 [Seemakhupt et al., SOSP’23], [Pourhabibi et al., MICRO’21], [Pourhabibi et al., ASPLOS’20].
-
개인 연구의 평가 환경은 Request generator와 CXL-based tiered memory system으로 구성하며, DeathStarBench를 기반으로 RPS 증가에 따른 memory tier별 page movability 변화, 각 microservice-level 및 전체 end-to-end level에서 성능에 미치는 영향을 관찰하고자 한다.
RPC components [Seemakhupt et al., SOSP’23]
회의록
DeathStarBench 좋은데 Methodology 설계는 실험에 필요한 모든 detail을 포함하여 최대한 상세해야함. 많이 누락되어있음. Request Generator는 어떻게 줄건데? Memory configuration 어떻게 할건데? 어떤 논문을 참고했는데? Linux perf argument는 어떻게 가져갈건데?나 평가 metric 포함해서 다 있어야 됨. 다른 학생들꺼 참고할 수 있음
→ 어떤 말씀이신지 이해했다. 잘 반영하겠다. 근데 이번 주는 methodology 설계 전에 background 조사 단계였다.
아 맞네 TODO 맞춰서 잘 하신 것 같긴한데. 원래 Workload 분석도 methodology에 포함시킬 수 있고 보통 가설 설정 바로 다음 주에 진행함. 일단 다음 주까지 하시면 됨. 실험 셋팅 쉽지 않을 것