ABSTRACT
- microservice 새로운 패러다임, 온라인 서비스를 세분화된 SW 모듈로 분해하고 RPC 이용
- 네트워크 stack의 지속적인 발전으로 RPC 계층이 병목이고 전체 microservice 실행 시간의 4-90%
- 기존 가속기는 CPU 개입 있었고 NIC 가속기로 실행되어야 함을 보이며 Cerebros 제안 - 전용 RPC 프로세서
1. INTRODUCTION
- 확장성, 개발 속도, programability 등으로 오늘날 온라인 서비스는 microservice 기반
- microservice 아키텍처는 일반적인 distributed 시스템과 마찬가지로 통신 계층 의존하며 RPC 방식 사용
- Google의 gRPC, Meta의 Thrift 등 cloud 기업들은 custom RPC 계층 개발 중
- 네트워크(100Gbps NIC[16][49]), 전송 프로토콜[27,67], system software의 발전[9,15,23..]으로 RPC 계층이 못따라감. 원래의 비즈니스 로직이 아닌 통신 오버헤드에 소요된다는 뜻. microservice 성능 감소 중
- CPU 성능은 NIC line 속도에 비해 수 배 뒤처진다. application ↔ network format DT 변환에 비효율적인데, 이게 RPC 작업의 95% 이상
- 단순 DT 가속에는 CPU가 여전히 RPC의 critical path에 관여하는 co-processor 구조라서 한계 있음, RPC 요청마다 CPU가 개입해서 명령어 전달하는 offload overhead
- RPC 계층 전체를 NIC 전용 HW에 offload해야함
- insight1. 대부분 microservice가 사용하는 RPC 계층은 세 가지 핵심 모듈로 구성, 두 개는 DT 가속기 offload 가능
- insight2. dispatch 모듈은 전체 사이클의 5% 미만이지만 CPU에 남기면 bottle-neck 주범
- insight3. RPC 프로세서를 NIC 수준에 배치하면 cache locality 활용 가능하고 면적 줄어듦
- Apache Thrift와 같은 실제 RPC 계층을 하드웨어에서 처리하는 RPC 프로세서 Cerebros 제안
2. WHY HARDWARE FOR RPCS?
- 온라인 서비스는 단일 binary monolith 구조에서 세분화된 모듈의 조합인 microservice 구조로 변화 중
- microservice는 여러 서버에 배포되므로 inter-server communication이 필요하고 RPCs를 활용함
- 모놀리스를 microservice로 변환하면 모듈이 처리하는 연산량은 줄지만 RPC 빈도는 증가하고 전체 실행 시간에서 통신이 차지하는 비중도 커지게 된다.