FPGA SmartNIC 로 가속한 Azure 네트워킹 (AccelNet, NSDI 2018)

출처

참고 이 페이지는 원문 번역이 아니라 한국어 해설이에요. 정확한 표현과 수치는 원문을 확인하세요.

한눈에

• VFP 로 대표되는 호스트 SDN 은 유연하지만, 패킷 처리에 호스트 CPU 를 쓰고 지연과 지연 편차를 키웁니다. 그 CPU 는 원래 고객에게 팔 수 있는 자원입니다.
• AccelNet 은 VFP 의 흐름 테이블을 FPGA 기반 Azure SmartNIC 에 일반 흐름 테이블(GFT) 형태로 내리고, VM 은 SR-IOV 로 NIC 를 직접 씁니다.
• 첫 패킷은 여전히 소프트웨어 VFP 가 처리해 규칙을 정하므로, 컨트롤러와 정책 모델은 바뀌지 않습니다.
• 2015년 말부터 새 Azure 서버에 들어갔습니다. 초록은 VM 간 TCP 지연 15마이크로초 미만과 32Gbps 처리량을 내세우고, 6장의 측정에서는 평균 지연 17마이크로초, 단일 연결 31Gbps 를 호스트 CPU 사용 없이 냈습니다.

왜 나왔나

2장은 배경을 정리합니다. 전통적인 가상화에서 모든 패킷은 하이퍼바이저의 가상 스위치를 거치므로 CPU 부하와 지연이 생깁니다. SR-IOV 를 쓰면 VM 이 NIC 의 가상 기능(VF)을 직접 쓰므로 빠르지만, 그러면 호스트의 VFP 를 건너뛰어 가상 네트워크, NAT, ACL 정책을 적용할 곳이 없어집니다(그림 1). 따라서 NIC 자체가 VFP 의 정책을 집행할 수 있어야 합니다. 이를 위해 VFP 의 통합 흐름 테이블처럼, 흐름마다 정확 일치로 찾아 헤더 변환을 적용하는 일반 흐름 테이블(GFT) 모델을 정의합니다. 처음 보는 흐름은 소프트웨어 VFP 로 올려 보내 규칙을 계산하게 합니다.

3장은 목표를 정합니다. 호스트 CPU 코어를 쓰지 않을 것(물리 코어 하나를 시간당 0.10~0.11달러, 5년 서버 수명 동안 약 4,500달러로 추산), VFP 의 프로그래밍 가능성을 유지해 컨트롤러가 오프로드를 몰라도 되게 할 것, SR-IOV 수준의 지연과 처리량, 새 기능을 계속 추가할 수 있을 것, 새 VM 유형 없이 기존 서버군에 배포할 것, 단일 연결 성능, 100GbE 이상으로 가는 길, 흐름 상태를 유지한 라이브 마이그레이션 같은 서비스 용이성입니다.

핵심 아이디어

왜 FPGA 인가

4.1절은 하드웨어 선택지를 비교합니다. ASIC 기반 NIC 는 가장 빠르지만 프로그래밍이 어렵고, 스펙을 약 7년 동안 바꾸지 않고 버텨야 합니다. 멀티코어 SoC 기반 SmartNIC 는 프로그래밍이 쉽지만 40GbE 이상에서 10마이크로초 이상의 지연과 편차가 생기고 단일 흐름 성능이 제한되며, 40GbE 는 10GbE 보다 코어가 거의 4배 필요했습니다. 호스트 코어를 계속 쓰는 것은 비용 때문에 탈락했습니다. 남은 것이 FPGA 로, 하드웨어에 가까운 성능과 깊은 파이프라인을 가지면서 다시 프로그래밍할 수 있습니다.

4.2절은 FPGA 에 대한 흔한 우려 다섯 가지에 답합니다. 이 작업에서 FPGA 면적은 ASIC 의 2~3배로 추정되고, 대규모 구매로 비용이 상쇄되며, 평균 5명 미만의 FPGA 개발자가 하드웨어와 소프트웨어를 함께 다루는 팀으로 충분했고, 앞선 Catapult 프로젝트의 인프라로 하이퍼스케일 배포가 가능했으며, HDL 이식성으로 특정 공급사에 묶이지 않는다는 것입니다.

시스템 구조

4.3절의 구조는 NIC 와 랙 스위치 사이에 FPGA 를 끼워 넣는 "bump-in-the-wire" 방식입니다(그림 2). 1세대(2015)는 40GbE NIC 와 Intel Stratix V D5 FPGA 를 따로 두었고, 2세대는 50GbE 로 SR-IOV NIC 와 Arria 10 FPGA 를 한 보드에 합쳐 케이블을 없애고 비용을 줄였습니다.

5장의 소프트웨어 쪽에서 VFP 는 여전히 제어 평면입니다. GFT 경량 필터가 NIC 와 FPGA 를 하나의 NIC 처럼 보이게 하고, 처리할 흐름이 없는 예외 패킷은 하이퍼바이저의 포트로 올려 VFP 가 규칙을 계산한 뒤 FPGA 테이블에 넣습니다. TCP 상태 추적을 위해 SYN, RST, FIN 패킷은 VFP 로 복사됩니다.

FPGA 파이프라인(그림 3, 그림 4)은 패킷 버퍼, 파서, 매치, 액션의 4단계를 가진 두 개의 처리 유닛입니다. 파서는 헤더 그룹 최대 3개(헤더 9개)를 읽고, 매치는 Toeplitz 해시로 2단 캐시를 찾습니다. 1단은 흐름 2,048개의 직접 사상 캐시, 2단은 DRAM 의 8-way 집합 연관 캐시로 약 100만 개 흐름을 담습니다. 액션은 마이크로코드로 구현해 대부분의 변경에 FPGA 재컴파일이 필요 없습니다. GFT 는 1세대 FPGA 로직의 약 3분의 1만 썼습니다. 흐름별 카운터와 TCP 상태는 주기적으로 VFP 로 보내 동기화합니다.

서비스 용이성

7장은 운영입니다. 핵심은 투명한 본딩(그림 7)입니다. Linux 의 NetVSC 드라이버가 SR-IOV VF 를 합성(synthetic) NIC 의 하위 장치로 묶어, TCP/IP 스택은 합성 NIC 하나만 봅니다. FPGA 나 드라이버를 업데이트하거나 VM 을 라이브 마이그레이션할 때는 VF 를 빼고 트래픽이 소프트웨어 경로로 넘어갔다가 돌아옵니다. DPDK 는 failsafe PMD 로 같은 일을 하며, 이 지원은 Linux 와 DPDK 업스트림에 들어갔습니다. 호스트마다 500개가 넘는 지표와 하드웨어 타임스탬프가 붙은 패킷 캡처도 갖췄습니다.

실험과 결과

6장의 결과(그림 5, 그림 6)는 다음과 같습니다.

• 지연: 4바이트 핑 100만 번 기준, AccelNet 없이 평균 50마이크로초, P99 약 100마이크로초, P99.9 약 300마이크로초였고, AccelNet 으로 평균 17마이크로초, P99 25마이크로초, P99.9 80마이크로초가 되었습니다.
• 처리량: 단일 연결로 약 31Gbps 를 호스트 CPU 0% 로 냈습니다. 이전에는 단일 연결 약 5Gbps 였고 라인 레이트를 내려면 여러 코어에서 연결 약 8개가 필요했습니다.
• 다른 클라우드와 비교(그림 6): 2017년 11월 Skylake 인스턴스로 AWS 와 GCP 의 같은 급 네트워킹과 비교해 가장 낮은 평균 지연과 꼬리 지연, 가장 높은 처리량을 보였고, Linux VM 사이 평균 약 10마이크로초, 사용자 공간 스택(VMA)으로는 약 5마이크로초를 얻었다고 적습니다.
• 실제 서비스: Azure SQL Database 의 평균 읽기 지연이 약 1ms 에서 약 300마이크로초로 줄고, P99 읽기와 쓰기 시간이 절반 이하로 줄었으며, 복제와 시딩이 2배 넘게 빨라졌습니다.
• 목표 점검(8장): 예외 처리를 위한 호스트 코어 사용률 1% 미만, SR-IOV 단독 대비 FPGA 추가 지연 1마이크로초 미만, 1세대 보드 전력 17~19W 로 PCIe 슬롯 한도 25W 이내였습니다.

8장은 교훈으로 처음부터 서비스 용이성을 설계할 것, 하드웨어와 소프트웨어를 한 팀으로 운영할 것, FPGA 에도 소프트웨어 릴리스 방식을 적용할 것, 상위 계층이 오프로드 여부를 모르게 할 것 등을 꼽습니다.

지금 Azure 에서는

이 논문의 기능은 Azure VM 의 가속 네트워킹(Accelerated Networking)이라는 이름으로 제공되며, 지원되는 VM 크기에서 네트워크 인터페이스별로 켜고 끕니다. 공식 문서가 설명하는 구조, 즉 VM 에 합성 NIC 와 함께 VF 가 나타나고 둘이 본딩되어 서비스 중에는 합성 경로로 넘어간다는 동작이 7장의 설계 그대로입니다. 같은 방향의 후속으로 Azure 는 네트워킹과 저장 처리를 전용 하드웨어로 내리는 Azure Boost 와 그 NIC(MANA)를 내놓았습니다.

함께 읽기

• Virtual Machines 와 VM Scale Sets: 이 사이트의 기능 문서
• VFP: 오프로드되는 흐름 테이블의 원래 설계
• Microsoft Research 논문 페이지
• The Morning Paper 의 요약 (영어)