IPU는 마이크로서비스 기반 애플리케이션에서 네트워크 지연 시간을 개선합니다.

마이크로서비스란?

마이크로서비스는 대규모 애플리케이션을 더 작고 독립적이며 느슨하게 결합된 서비스로 분할하는 최신 소프트웨어 개발 접근 방식을 말합니다. Amazon, eBay, Netflix 및 Twitter와 같은 잘 알려진 회사를 포함한 클라우드 서비스 제공업체는 애플리케이션을 전통적인 모놀리식 소프트웨어 시스템으로 구현하는 대신 점점 더 전통적인 모놀리식 디자인이 아닌 마이크로서비스로 애플리케이션을 구현하고 있습니다.

마이크로서비스의 몇 가지 이점은 다음과 같습니다.

• 확장성: 마이크로 서비스는 개별 서비스를 서로 독립적으로 확장할 수 있으므로 더 나은 확장성을 제공합니다. 즉, 개발자는 애플리케이션의 나머지 부분에 영향을 주지 않고 필요한 서비스만 확장 또는 축소할 수 있습니다.

• 유연성: 마이크로서비스를 사용하면 전체 애플리케이션에 영향을 주지 않고 개별 서비스를 업데이트할 수 있으므로 시스템을 더 쉽게 변경할 수 있습니다. 이를 통해 새로운 기술을 채택하고, 다양한 프로그래밍 언어로 실험하고, 새로운 기능을 테스트할 수 있습니다.

• 오류 격리: 각 마이크로 서비스는 독립적인 구성 요소이므로 한 서비스가 실패해도 나머지 애플리케이션에 영향을 주지 않습니다. 즉, 개발자는 전체 시스템에 영향을 주지 않고 문제를 신속하게 식별하고 수정할 수 있습니다.

• 개발 속도 향상: 마이크로서비스를 통해 더 작고 집중적인 개발 팀이 특정 서비스에 대해 독립적으로 작업할 수 있습니다. 이를 통해 개발 프로세스의 속도가 빨라지고 크고 복잡한 시스템을 보다 쉽게 관리할 수 있습니다.

• 더 나은 내결함성: 마이크로 서비스를 사용하면 각 서비스가 독립적으로 오류를 처리하도록 설계될 수 있으므로 내결함성 시스템을 더 쉽게 구축할 수 있습니다. 이는 전체 시스템의 복원력이 향상되고 실패할 가능성이 적다는 것을 의미합니다.

• 향상된 테스트: 각 마이크로 서비스는 독립적이므로 개별 서비스를 더 쉽게 테스트할 수 있습니다. 즉, 개발자는 서비스를 개별적으로 테스트할 수 있으므로 버그를 더 쉽게 찾고 수정할 수 있습니다.

마이크로서비스 기반 소프트웨어 아키텍처는 중요한 이점을 제공하지만 상당한 네트워킹 오버헤드를 도입하므로 네트워크 대기 시간과 같은 매개변수가 전체 애플리케이션 성능 및 데이터 센터 비용에 큰 영향을 미칩니다. 서비스 프로바이더는 Napatech의 가상화 데이터 플레인 소프트웨어를 실행하는 인텔 FPGA 인프라 처리 장치(IPU)를 활용하여 네트워킹 인프라의 성능을 극대화함으로써 다른 방법으로는 달성할 수 없는 수준의 성능을 제공하는 동시에 전체 데이터 센터 CAPEX 및 OPEX를 최소화할 수 있습니다.

마이크로서비스의 네트워킹 과제

마이크로서비스 아키텍처에서 네트워크 대기 시간은 컨테이너 또는 가상 머신(VM)에 구현된 가상화된 서비스가 가상화된 네트워크를 통해 서로 통신하기 때문에 중요한 문제를 제시합니다. 예를 들어 마이크로 서비스는 서로 자주 통신하므로 많은 양의 네트워크 트래픽이 발생할 수 있습니다. 이렇게 증가된 네트워크 트래픽은 네트워크 정체 및 대기 시간 증가로 이어져 시스템 성능에 부정적인 영향을 미칠 수 있습니다. 마찬가지로 마이크로 서비스 아키텍처에서 서비스는 작업을 완료하기 위해 다른 서비스를 호출해야 하는 경우가 많으며 각 네트워크 호출은 시스템에 추가 대기 시간을 추가합니다. 서비스 수와 시스템의 복잡성이 증가함에 따라 네트워크 호출 수도 증가하여 상당한 대기 시간 문제가 발생할 수 있습니다. 마지막으로, 서로 다른 마이크로서비스는 통신을 위해 서로 다른 네트워크 프로토콜을 사용할 수 있습니다. 예를 들어 한 서비스는 REST(REpresentational State Transfer)를 사용하고 다른 서비스는 gRPC(Google 원격 프로시저 호출)를 사용할 수 있습니다. 서로 다른 네트워크 프로토콜 간에 변환하면 시스템 대기 시간이 늘어날 수 있습니다.

일반적으로 가상화된 데이터 플레인은 완전히 소프트웨어에서 구현되며, VM 간에 네트워크 트래픽을 라우팅하는 가상 스위치(vSwitch)를 실행하여 많은 컴퓨팅 주기가 사용됩니다. 각 vSwitch 작업에는 상당한 수의 CPU 주기가 필요하므로 이 아키텍처는 시스템에 허용할 수 없는 지연 시간을 도입할 수 있으며 시스템이 필요한 전체 성능 또는 처리량을 달성하지 못하게 할 수도 있습니다. 동시에 가상 데이터 플레인을 실행하는 데 많이 사용되는 CPU는 애플리케이션과 서비스를 실행하는 데 사용할 수 있는 코어가 줄어들어 데이터 센터 워크로드를 지원하는 데 필요한 서버 수가 증가하고 CAPEX와 OPEX가 모두 증가합니다. 그림 1을 참조하십시오.

인텔® FPGA IPU 기반 아키텍처 활용

보다 효율적이고 비용 효율적인 시스템 수준 아키텍처는 인텔 FPGA IPU 활용하여 서버 CPU에서 vSwitch를 오프로드하여 애플리케이션 및 서비스를 실행하기 위해 서버 CPU를 확보합니다.

데이터 센터 서버의 표준 네트워크 인터페이스 카드(NIC)를 대체하는 IPU는 프로그래밍 가능한 FPGA(Field Programmable Gate Array)를 사용하여 하드웨어에서 vSwitch를 구현하여 컨트롤 플레인을 실행하는 범용 CPU와 함께 데이터 플레인을 실행합니다. vSwitch는 VM에 업계 표준 API(Application Programming Interface)를 제공하여 이 아키텍처를 활용할 때 VM 자체를 변경할 필요가 없도록 합니다. 표 2를 참조하십시오.

IPU 기반 아키텍처는 마이크로서비스 기반 애플리케이션을 실행하는 데이터 센터에 다음과 같은 세 가지 주요 이점을 제공합니다.

• 마이크로 서비스 간의 지연 트래픽을 최소화하는 초저 대기 시간; Ultra-low latency, which minimize the delay traffic between the microservices;

• 시스템 및 응용 프로그램의 전체 처리량을 최대화하는 고성능;

• vSwitch 데이터 플레인에서 서버 CPU 코어를 사용하지 않는 최적의 서버 CPU 사용률로 전체 워크로드에 필요한 총 서버 수를 최소화하고 데이터 센터 CAPEX 및 OPEX도 최소화합니다.

MIT 분석

실제 시나리오에서 vSwitch 오프로드의 이점을 정량화하기 위해 MIT(Massachusetts Institute of Technology)는 두 가지 마이크로서비스 기반 사용 사례의 성능을 분석하여 기존 소프트웨어 기반 vSwitch를 사용한 결과와 SmartNIC 및 IPU 솔루션의 선두 공급업체인 Napatech의 인텔 IPU 실행 가상 데이터 플레인 소프트웨어를 사용하여 얻은 결과를 비교했습니다. 이 두 가지 사용 사례는 여러 계층 간 데이터 전송에 메시지 전달을 사용하는 게시-구독 "pub-sub" 애플리케이션과 웹 서버, 인메모리 캐시 및 백엔드 데이터베이스로 구성된 3계층 TCP 애플리케이션이었습니다. 이 벤치마킹 이니셔티브의 결과는 MIT에서 발행한"Napatech 소프트웨어를 실행하는 인텔 IPU에 대한 마이크로서비스 벤치마킹"

Pub-Sub 애플리케이션 성능 분석

"publish-subscribe application"의 줄임말인 pub-sub 애플리케이션은 서로 다른 컴포넌트 또는 서비스 간의 통신 및 조정을 용이하게 하기 위해 분산 시스템에서 일반적으로 사용되는 메시징 패턴입니다. pub-sub 패턴은 게시자라고 하는 메시지 발신자가 구독자라고 하는 특정 수신자를 알 필요가 없는 비동기 및 분리된 통신을 허용합니다. Pub-Sub 애플리케이션은 다음과 같은 사용 사례에 적용할 수 있습니다.

• 평면도를 만들고 좌석을 할당한 다음 라이브 좌석 예약 이벤트를 관리하는좌석 예약 시스템 고객이 티켓을 구매하면 pub-sub 시스템은 모든 곳에서 실시간으로 평면도를 업데이트하고 분산 캐시 시스템을 동기화 상태로 유지합니다. 고객은 아직 탐색/쇼핑 단계에 있는 동안 누군가가 좌석을 구매했다는 사실을 알기 위해 좌석을 요청하지 않습니다.

• 학생들이 웹 기반 앱을 통해 교실에 참여할 수 있도록 하는 교육 도구로, 클라이언트는 종종 신뢰할 수 없는 WiFi 또는 예측할 수 없는 셀룰러 네트워크와 같은 문제에 직면합니다. pub-sub 시스템은 네트워크에 다시 가입할 때 연결을 복구하고 온라인 참가자 수의 급격한 변화를 처리할 수 있습니다.

• 주가, 시장 지수, 거래 데이터 및 오더북 업데이트를 포함한 시장 데이터를 조직 내 구독자에게 배포하는 것과 같은 금융 응용 프로그램Financial applications such as distribution of market data including stock prices, market indices, trade data and order book updates to subscribers to organizations within the organization.

• 인터넷(IoT) 시스템- pub-sub는 수많은 IoT 장치 간의 통신을 용이하게 하고 효율적인 데이터 배포를 가능하게 합니다. 센서가 데이터를 게시하면 가입자가 해당 데이터를 실시간으로 수신하고 처리할 수 있습니다.

개발자가 다양한 언어와 개발자 프레임워크를 지원하면서 클라우드와 에지 모두에서 실행되는 복원력 있고 상태 비저장 및 상태 저장 애플리케이션을 빌드할 수 있도록 하는 이식 가능한 이벤트 기반 런타임인Dapr의 pub-sub 통신 모델로 개발된 5계층 체인 토폴로지를 평가 했습니다. 각 계층은 출력을 다운스트림 계층으로 브로드캐스트하기 전에 사용자가 지정한 시간 동안 CPU 집약적인 계산을 수행합니다. 그림 3을 참조하십시오.

5계층 pub-sub 애플리케이션 내에서 두 OVS 지원 서버에 서비스를 배치하면 종속 서비스가 서로 다른 물리적 시스템에서 실행되므로 계층 간의 모든 트래픽이 활성화된 경우 IPU를 통과합니다.

MIT는 IPU 기반 오프로드를 사용하거나 사용하지 않는 pub-sub 시스템의 성능을 분석하여 초당 수천 개의 쿼리(kQPS)로 표현되는 다양한 로드에서 메시징 대기 시간을 측정했습니다. 그림 4를 참조하십시오.

오프로드가 비활성화되고 꼬리(즉, 최악의) 지연 시간을 고려하면 애플리케이션은 그래프의 변곡점으로 표시된 대로 90kQPS에서 포화되기 시작합니다. 이 로드 수준을 넘어서면 시스템은 더 이상 요청을 효율적으로 따라갈 수 없으며, 이는 대부분 TCP 재전송을 초래하는 패킷 삭제로 인한 것입니다. 그러나 오프로드가 활성화된 경우 시스템은 이 테스트에 사용된 최대 속도인 140kQPS의 부하에서 요청을 계속 따라가고 있으며, 이는 IPU가 허용 가능한 테일 대기 시간을 유지하면서 처리량을 50% 증가시킬 수있음을 나타냅니다. 이는 시스템 용량이 크게 향상되어 총 서버 비용과 에너지 소비를 모두 30-40% 절감할 수 있음을 나타냅니다.

3계층 TCP 응용 프로그램 성능 분석

3계층 TCP(전송 제어 프로토콜) 응용 프로그램은 응용 프로그램을 각각 특정 기능을 담당하는 세 개의 논리 계층 또는 계층으로 나누는 소프트웨어 아키텍처 설계를 말합니다. 이러한 계층을 일반적으로 프레젠테이션 계층, 응용 프로그램 계층 및 데이터 계층이라고 합니다. TCP 프로토콜은 다음 계층 간의 통신에 사용됩니다.

• 프레젠테이션 계층: UI(사용자 인터페이스) 계층이라고도 하는 이 계층은 사용자에게 애플리케이션 정보를 제공하고 입력을 받는역할을 합니다. 웹 페이지, 양식 또는 데스크톱 인터페이스와 같은 GUI(그래픽 사용자 인터페이스) 구성 요소를 다룹니다. 프레젠테이션 계층은 응용 프로그램 계층과 통신하여 필요에 따라 데이터를 검색하거나 업데이트합니다.

• 응용 프로그램 계층: 응용 프로그램 계층에는 응용 프로그램의 비즈니스 논리 및 처리 논리가 포함됩니다. 핵심 기능을 처리하고 데이터 유효성 검사, 비즈니스 규칙 적용 및 응용 프로그램별 작업과 같은 작업을 수행합니다. 이 계층은 프레젠테이션 계층의 요청을 처리하고 데이터 계층과 통신하여 데이터를 검색하거나 저장합니다.

• 데이터 계층: 데이터 액세스 계층 또는 데이터베이스 계층이라고도 하는 데이터 계층은 데이터 저장 및 검색 관리를 담당합니다. 데이터 쿼리 및 업데이트와 같은 데이터베이스 시스템과의 상호 작용을 처리합니다. 데이터 계층은 응용 프로그램 계층에서 요청을 받고 요청된 데이터를 반환하거나 필요한 데이터 수정을 수행합니다.

3계층 TCP 응용 프로그램에서는 TCP 프로토콜을 사용하여 이러한 계층 간의 통신이 용이합니다. TCP는 계층 간에 안정적이고 순서가 있는 데이터 전달을 보장하여 연결 지향 및 스트림 기반 통신 메커니즘을 제공합니다. 3계층 TCP 아키텍처는 응용 프로그램을 이러한 세 가지 계층으로 분리하여 모듈화, 확장성 및 응용 프로그램의 손쉬운 유지 관리를 가능하게 합니다. 각 계층은 독립적으로 개발 및 확장이 가능하므로 구성 요소의 유연성과 재사용성이 촉진됩니다.

이 분석을 위해 MIT는 NGINX 를 프론트엔드 웹 서버로, Memcached 인메모리 캐싱 티어로 , MongoDB 영구 스토리지가 있는 백엔드 데이터베이스로 사용하는 3계층 애플리케이션을 평가했습니다. 클라이언트는 NGINX와 상호 작용하여 키-값 쌍이 Memcached에 캐시되었는지 확인하고, 캐시된 경우 클라이언트에 값을 반환합니다. 그렇지 않은 경우 NGINX는 MongoDB와 인터페이스하여 출력을 가져오고 Memcached에 추가로 캐시합니다. 그림 5를 참조하십시오.

MIT는 IPU 기반 오프로드가 있든 없든 3계층 TCP 애플리케이션의 성능을 분석했으며, 이전 예에서와 같이 초당 수천 개 쿼리(kQPS)로 표현되는 다양한 로드에서 메시징 대기 시간을 측정했습니다. 그림 6을 참조하세요.

오프로드가 비활성화되고 꼬리(즉, 최악의 경우) 대기 시간을 고려하면 애플리케이션은 그래프의 변곡점으로 표시된 대로 약 17kQPS에서 포화되기 시작합니다. 이 로드 수준을 넘어서면 시스템은 더 이상 요청을 효율적으로 따라갈 수 없으며, 이는 대부분 TCP 재전송을 초래하는 패킷 삭제로 인한 것입니다. 그러나 오프로드가 활성화되면 26kQPS의 부하가 될 때까지 포화 상태가 시작되지 않으며, 이는 IPU가 허용 가능한 테일 대기 시간을 유지하면서 처리량을 53% 증가시킬 수있음을 나타냅니다. 앞의 예와 마찬가지로 이는 시스템 용량이 크게 향상되어 총 서버 비용과 에너지 소비가 모두 30-40% 절감됨을 나타냅니다.

시스템 구성

MIT에서 마이크로서비스 벤치마킹에 사용한 시스템 구성은 다음과 같습니다.

• 2개의 Inspur 듀얼 소켓 서버는 각각 48MB 캐시의 인텔® 제온® Gold 6338 프로세서를 갖추고 있으며 2.0GHz에서 3.2GHz 터보 속도로 실행됩니다. 각 서버는 512GB 메모리, 480GB 부트 드라이브, 듀얼 1.6TB P6410 NVMe 스토리지 모듈 및 1개의 10G 인텔® 이더넷 컨트롤러 XL710 NIC로 구성되었습니다.

• 표준 NIC 외에도 각 서버는 인텔® Stratix® FPGA 및 인텔® 제온® D SoC(System-on-Chip)를 기반으로 하는 듀얼 10/25G SFP28 포트 및 PCIe 3.0 호스트 인터페이스를 갖춘 하나의 인텔 IPU C5000X 어댑터로 구성되었습니다. 그림 7을 참조하십시오.

• 각 IPU는 Napatech의 Link-Virtualization 4.3.3 소프트웨어를 실행하여 OVS(Open vSwitch), VirtIO 지원, 실시간 마이그레이션, VM-to-VM 미러링, VLAN/VxLAN 캡슐화/캡슐화 해제, Q-in-Q, RSS 로드 밸런싱, 링크 집계 및 QoS(서비스 품질)와 같은 기능을 포함하여 오프로드 및 가속화된 가상화 데이터 플레인을 제공했습니다.