# 데이터 플레인 가속화

: 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 메시지 구조



> Aegis, JAXB : 데이터바인딩 하는 친구들

: SOAP메시지가 들어오면 JAVA의 객체로 만들어지고 SOAP의 DATA부분의 내용을 또다른 자바객체로 바인딩하는 기술을 일컬음


> SDO, Service Data Objects





누가 추천해주신 wsgi(Web Server Gateway Interface)를 만들어보려구,

함께 추천해주신 파이썬책도 겸사겸사 주문했는데 아직두 발송전인듯..

인터파크는 평균 5일은 걸리는 것 같다는 ㅜㅜ


그래서 암튼 그전까지 퇴근 후 5일짜리 교육 신청함... 


주제 : 웹서비스 - WSDL & SOAP

목차 : 

1. 웹 서비스 개요

2. 웹 서비스 기반기술

3. 웹 서비스 프레임워크

4. 웹 서비스 구현

5. 웹 서비스 클라이언트 구현

6. 오픈 API와 매시업


포카칩뜯으면서 주저리 주저리 정리하고 자야지... 


------------------------------------------------------------------------------


1일차 - 웹 서비스 개요


# 웹서비스의 정의


> 웹서비스의 의미는 굉장히 다양함

> 전체 구성도


> Back-end, Front-end, Middle-ware(모바일환경에서의 push server, MQ ...)


> 정의

- 이종 시스템을 통합하고 HTTP를 통해 재사용 가능한 비즈니스 기능 공개 방법을 제공 - 서비스디자인패턴, 로버트다이뇨(2013)

- 네트워크 상에서 서로 다른 종류의 컴퓨터들 간에 상호작용을 하기 위한 소프트웨어 시스템 - 위키

- 기계 대 기계 상호작용을 지원하기 위해 설계된 소프트웨어 시스템 - W3C

=> 다 통합... 왠지 클라우드서비스가 생각난다..


> SOA vs ROA

- Service oriendted vs Resource Oriented

- OSGi, Open Service Gateway initiative


> SOAP/WSDL 기반에서 웹 서비스

- 클라이언트, 서비스 / 요청자, 제공자 / 서비스 컨슈머, 서비스 제공자


> 웹서비스 연관 용어

- 웹 2.0 

- Semantic Web, 웹 3.0

- Open API

- Mash-up


> 웹서비스의 등장배경

- 비지니스 관점 : 기업 내, 기업 간, 기업과 고객 간 통합된 서비스 증대 및 Time to Market

- 기술적 관점 : POP -> OOP -> COP: CBD -> SOP: SOA

                 절차지향 객체지향 컴포넌트지향 서비스지향

- 분산프로토콜 등장 : RMI(rmic.exe), RPC


> 웹서비스 사용 목적

- 웹서비스 레이어드 아키텍처


> 웹서비스 고려사항과 대안

- 마샬링, 언마샬링시 바이트스트림으로 직렬화하여 전송

- 네트워크 통신의 부분적 실패에 대비(여기서는 네트워크 통신의 장애를 말함)

- 웹서비스의 본질적인 위험요소 고려





> 웹서비스 API 스타일

- 엔터프라이즈 애플리케이션 아키텍처 패턴

- MVC Architexture

- 퍼사드(Facades[GoF]) 패턴

- RPC API(JAX-RPC) / 메세지 API(JAX-WS) / 리소스 API(JAX-RS)


> 웹서비스 API 설계 시 고려사항

- 캡슐화

- 서비스 계약 : 클라이언트와 서비스가 어떻게 상호작용 할 수 있는지 명시한 협약서

- 자율성 : 상호 결합성이 낮아야 함

- 지연시간

- 부분실패, RPC-API(proxy)

- 텍스트 기반 데이터의 바이너리 메시지 인코딩


> 테스트 개발환경 설정

- IDE 설치 및 Subversive, AnyEdit 플러그인 설치

- 빋드환경 배포, Maven

- WAS, Tomcat

- 개발 표준 설정 : 명명규칙, 소스코드 포맷, 파일 포맷 등








+ Recent posts