지밍이 블로그

# intel DPDkP의 해결책

# Linaro ODP

: LNG에서 플랫폼에 상관없는 네트워킹 데이터 평면에 API를 제공하기 위해 오픈소스로 공개

- 사용자단에서 한개의 프로세서로 동작, 최소한의 API를 호출

- ODP API : 커널의오버헤드를 야기하지 않고, 가용한 하드웨어의 특성을 사용하여 DPA를 실현하고자 함

  (= SDK API)

- 하드웨어 의존적인 SDK API 호출을 배제하지 않음, 플랫폼에 상관없는 소스레벨의 호환성을 제공해주지 못할 수 있음

- 데이터 플레인 응용을 지원하는 플랫폼

- 리눅스 API를 사용하는 리눅스 사용자 평면제어 또는 관리평면 기능을 구현한 응용프로그램과 병렬처리 가능

# Linaro ODP 추상화된 논리적 패킷처리 구조

SW - 소프트웨어 블록

HW - 대부분 하드웨어 블록에 의해 수행되는 부분으록 간주하지만, 소프트웨어에서 수행될수도 있음

빗금 - 낮은 액세스 지연을 가지는 펌웨어와 같은 하드웨어에서 아주 가까운 소프트웨어에 의해 수행되는 기능

1. Packet Input 블럭 - 물리적 입력단의 패킷 포트를 추상화

2. Pre-Processing - 물리 인터페이스와 동일한 속도로 처리, 버퍼 풀의 선택 및 첫번째레벨의 congestion 제어를 위한 패킷분류 수행

3. Input Classification - 구별된 트래픽 플로우 분석 및 분류, 큐에 배정, 분석결과 메타데이터를 추가

4. Ingress Queuing - 실제 페이로드에 대한 메타에이터(descriptor)들의 큐를 제공, 큐에대한 descriptor들은 HW장비 또는 SW에서 도착

5. Delivery/Scheduling - 동기화된 SW/HW 인터페이스, 동작 스케줄링과 한일 수신점에 대한 다수개의 프로세서 코어에 대한 로드밸런싱 수행

* 스케줄러큐 - 우선순위 설정, 큐의 상태, CPU상태를 참조

6. Accelerator - 비동기적 큐기반의 인터페이스에 대해 암호화 또는 압축등 특수 목적 처리를 수행

7. Co-processors - Accelerator과 유사, SW에 대한 동기화된 인터페이스를 가지고 빠른 동작을 수행

8. Egress Queueing - 출력 포트를 향해 동기화된 인터페이스를 제공

* 각각의 큐는 논리적으로 매핑, 설정된 QoS기능을 선택적으로 수행

9. Post Processing - 패ㅣㅅ을 출력포트를 위해 스케줄링, 패킷이 나가면 패킷 버퍼를 해제, 패킷 checksum등 inline가속 기능 제공

10. Packet Output - 물리 출력 포트에대한 인터페이스 제공

# 데이터 플레인 가속화

: DPA, Data Plane Acceleration, 

: 고속 네트워크 패킷 처리를 위한 데이터 플레인 가속화

# 네트워크 패킷처리 소프트웨어

> 기존, 네트워크 패킷처리 구조를 분리

- 사용자단의 응용프로그램은 패킷전송을 위해 소켓을 생성하여 패킷 송신

- 커널단에서 프로토콜처리(TCP/UDP/IP)를 진행 후 사용자단으로 소켓을 통해 전달

> 현재, DPA 기술

- 기존서버의 고속 네트워크 패킷처리에 대한 문제를 해결하기 위함

- OpenOnLoad, Netmap, PF_RING, DPDK, ODP,..

- 네트워크 패킷을 커널영역을 통과하여 사용자단에서 직접 처리

- DpenOnLoad : NIC에서 응용네트워크 패킷의 헤더에 포함된 플로우 정보를 기반으로 사용자단으로 패킷을 직접 전달

- Netmap : 패킷 자원 사전할당, 다중패킷 처리기술, 커널과 사용자단 사이의 패킷에 대한 메타데이터 및 메모리 버퍼 공유 

- PF-RING : 고속 네트워크 패킷 캡처, 필터링 및 분석, DNA(Direct Nic Access)를 통한 고속네트워크패킷 처리

# Intel DPDK

: Data Plane Development Kit

- 사용자단의 (인텔 DPDK 라이버러리 API + EAL(Environment Abstraction Layer) ), 커널을 통과하여 NIC에 직접 액세스

- 최적화된 NIC 드라이버 제공

- Run-to-completion 모델(멀티프로세서 수와 데이터 플레인 성능 비례)

*주요기능

1. Memory Manager

: 메모리에서 객체들의 풀 할당

: huge 페이지 메모리 공간에 생성, ring 사용(사용가능 객체저장), DRAM채널에 균등 저장 

2. Buffer Manager

: 메모리 풀에 저장되는 고정 길이의 버퍼들을 사전 할당하여 관리 (액세스 시간 절약)

3. Queue Manager

: 기존의 spinlock대신 lockless 큐를 구현하여 사용

: 패킷을 병렬처리할 때 불필요한 대기시간을 절약

4. Flow Manager

: 인텔 스트리밍 SIMD 확장기술 이용, 네트워크 패킷 헤더에 대한 hash정보를 생성, 네트워크 패킷들이 동일 플로우에 할당

: 고속처리 가능

5. Poll Mode Driver

: 기존의 비동기식 인터럽트대신 최적화된 동기식 폴 모드 인터럽트 처리루틴 사용

# 인텔 DPDK 패킷처리 구조

1. Packet I/O Rx - NIC에서 전달된 패킷이 처리, NIC에 대한 폴 모드 드라이버를 포함

2. Packet Parser - 수신된 패킷에 대한 프로토콜 스택 식별, 유효성 검사

3. Packet Classification - 패킷을 트래픽 플로우 중 하나에 매핑, hash함수로 exact match테이블 lookup 수행, 

충돌방지를 위해 bucket로직을 사용하는 기능을 수행 

4. Policer - srTCM/trTCM 알고리즘사용, 패킷에대한 통계정보 수집

5. Load Balancer - 수신된 패킷을 응용프로그램에 분배, 각 응용 worker에 대한 트래픽 플로우의 친화도 유지, 플로우 내의 패킷순서 유지

6. Worker - 응용 프로그램 수행

7. Dropper - RED(Random Early Detection) 알고리즘 / Weighted RED 알고리즘 사용, congestion 관리 수행

현재 스케줄러의 큐로드 레벨, 패킷의 우선순위에 따라 패킷을 drop하는 기능 수행

8. Hierarchical Scheduler - 수천개의 leaf노드(큐)로 구성된 5개의 레벨에 대한 계층적 스케줄러 포함

a. 출력포트

b. 서브포트 - 트래픽 shapping

c. 파이프 - 트래픽 shapping

d. 트래픽 클래스 - 우선순위 적용

e. 각각의 파이프트래픽 클래스 내의 큐 - WRR(Weighted round Robin)알고리즘 적용

9. Packet I/O Tx - 다수의 NIC포트로 패킷을 송신

http://www.nextree.co.kr/p2010/

# 웹 서비스 시나리오

- UDDI : 웹 서비스 관련 정보의 공개와 탐색을 위한 표준

- 공공데이터 포털

- 서비스제공자 

- 서비스요청자 

# 웹서비스 3가지 기술요소

- WSDL : Web Service Description Language, 웹서비스를 표현 및 기술, XML

- SOAP : Simple Object Access Protocol, 메시지프로토콜

- UDDI : 기술의 탐색, 등록 ----> 국내에선 없음

*Jax-WS - java 메시지와 Soap메시지를 매칭,바인딩 해주는 객체

# 웹 서비스 아키텍처 모델

- framework ? 반 자동화 되어있는, 스스로 동장할 수 없음, 프로그램으로 동작 시켜줘야함

- Server ? 서비스를 제공할 수 있음, 자동화 되어있는,

> 웹서비스 핵심 기술 표준

- XML

- XML 스키마

- SOAP

- WSDL

- UDDI

> 웹 서비스 확장기술 표준 (wS-*) 

- 보안처리 WS-Security, WS-Trust, WS-SecureConversation

- 트랜잭션처리 WS-Coordination, WS=Transaction

- 신뢰성있는 메시지 WS-ReliableMessaging, WS-Addressing

- 기타(BPM-업무프로세스, RM-자원관리)

=> 실무에서 이런 확장기술을 적용하는 분위기는 아니지 ㅎㅎ

# XML[Extensible Markup Language]

- W3C에서 다른 특수 목적의 마크업 언어를 정의하기 위한 마크업 언어

- XML 활용도 높다면 데이터처리에 사용, 보통 요즘엔 환경설정에 사용

- XML은 문서로 구조화 할때, 많이 사용

- HTML의 단점이, 표현과 구현을 섞어놓아 디자이너와 개발자의 협업이 어려웠음

- XML은 HTML에서 데이터만 끄집어내자하여 떨어져 나옴

- Transformation, XSLT

- CSV

- X-Path, XML의 path를 처리하는 기술

- XHTML, HTML5

- RDF, ROA, 시맨틱 웹의 토대

- 라이센스 제약이 없고, 플랫폼이 독립적, 많은 지원이 있음

> XML의 구조

- 버전표기

- root 엘리먼트 1개만 반드시 포함

> XML의 특징

- 문서의 내용과 스타일을 분리하여 사용

- 표준 규약,ft 

- 문서(microso, 전송자료(ACORD, OFX, IFX...)

> Well-Formed 

> Valied

> Namespace

: 논리적 이름 구분을 위함

> XML스키마의 목적

- DTD와 같이 XML문서를 구조화하기 위해 W3C에서 표준화하여 제공

> XML스키마의 특성

- XML문법, XML 네임스페이스 지원, 루트요소를 반드시 가져야함, 

- <schema>, 다양한 데이터타입, 문서화 메커니즘 제공

> DTD와 XML스키마의 특징 비교

> XML 스키마 네임스페이스

- 스키마 네임스페이스를 지정하지 ㅇ낳으면 파서는 XML 스키마로 인식할 수 없음

- xs, xsd와 같은 접두사를 많이 사용

> 대상 네임스페이스(targetNamespace)

- 새로운걸 만들어서 참조를 하려면 그대로~ 붙여야함

- targetNamespace를 안붙이면 안되. namespace중복이 되버려. 선언은 할 수 있음

> elementFormDefault, attributeFormDefault

- "qualified", "unqualified"

- XML파서가 알아서 처리를 해줌

- full package를 주는게 좋음.. 결국 언젠간 확장하다보면 충돌 날 수 있으므로

# SOAP

: 개방형 프로토콜을 사용하여, XML기반의 SOAP 메시지를 네트워크 상에서 교환하는 프로토콜(HTTP, HTTPS, SMTP를 기저로 깔고)

: 구조, 전송, 상호 중립성의 개념을 도입

: 태생 자체가 상호독립/호환을 위해서 만들어짐

- SOAP 1.2 version

> 특징 (장점)

- SOAP을 기본적으로 HTTP기반 위에서 동작,

- HTTP와 같이 프록시와 박화벽에 구애받지 않고 쉽게 통신이 가능,

- 플랫폼 및 프로그래밍 언어에 독립적

- 간단하고 확장가능, 멀티파트 MIME구조를 사용, 첨부를 통합하는 SOAP XMl 메시지를 지원

- 페이로드

> 특징 (단점)

- 성능이슈, (실제 stress test시, 응답속도가 예전에 비하여, 몇배이상 빨랐음) 

   ==> 상대적으로 늦는다는 이야기지, 이제는 더이상 단순히 느리다라고 할 수 없음

# SOAP 메시지 구조

1.1 버전

1.2 버전

# WSDL

: 웹서비스가 어디에 존재하는지, 웹서비스로 무엇을 할 수 있는지, 또 어떻게 하는지, XML형식으로 기술하여 제공

: SOAP메시지에서 주곱다아야하는 데이터가 WSDL에 있음

> WSDL 네임스페이스 목록

> 문서구조

> 웹서비스 스택

# 웹스비스 프레임워크

- Aegis Databinding

- Spring

- JAX-WS지원

- 비동기방식의 호출 지원

- 바이너리와 기존 프로토콜 지원

- 기타.. (책참고)

> Apache CXF 도구

> Apache CXF 아키텍처

- CXF-API : Bus,

> SOAP 메시지 구조