12/16/2016

마이크로서비스 아키텍처(Microservices Architecture)의 장점과 단점


마이크로 서비스는 대규모 소프트웨어 프로젝트를 마이크로 단위의 모듈로 분리하여 loosely-coupled한 구조로 만들고 API를 통해 서로 통신합니다.
지난 몇 년동안 마이크로 서비스에 대해서 많은 이야기가 있었습니다. 모듈형 아키텍처 스타일은 클라우드 기반 환경에 적합하며 인기가 높아지고 있습니다.
마이크로 서비스는 대형 소프트웨어 프로젝트의 기능들을 작고 독립적이며 느슨하게 결합 된 모듈로 분해하여 서비스를 제공하는 아키텍처 입니다.
각 개별 모듈은 개별적인 작업을 담당하며 간단하고 보편적으로 엑세스 할 수 있는 API를 통해 다른 모듈과 통신 합니다.
마이크로 서비스는 웹 기반의 복잡한 응용 프로그램을 설계하기 위한 또 다른 아키텍처입니다. 일반적으로 SOA(Service Oriented Architecture)와 비슷하게 바라보는 시각도 존재합니다만 엄연히 다른 아키텍처입니다.
그렇다면 SOA와 같은 기존 아키텍처의 문제점은 무엇일까요?
Java를 사용하여 기존 웹 프로그램을 만든다고 가정합시다. 가장 먼저 해야 할 일은 presentation layer (사용자 인터페이스)를 디자인을 하고 Business logic을 처리하는 Application layer와 구성 요소 간의 느슨한 결합을 가능하게 하는 Integration layer 그리고 마지막으로 데이터에 접근이가능하도록 Persistence layer를 디자인 하고 구현해야 합니다.
어플리케이션을 구동하기 위해 war or ear 패키지를 생성하고 이를 Tomcat or JBoss와 같은 Application server에 배포합니다. 모든 모듈이 war or ear로 패키징 되었기에 우리는 이것을 Monolithic이라고 부릅니다. 다시 말해서 별도의 구현 가능한 구성 요소가 존재해도 모두 하나의 지붕 아래에 패키징되어 있습니다. 아래의 그림을 참조하세요.

Monolithic 아키텍처: challenges

  • 어플리케이션이 커질 수록 코드도 방대해지고 로드시에 IDE에 과부하가 걸릴 수 있습니다. 이런 부분은 개발자의 생산성을 저하시키는 요인이 됩니다.
  • 하나의 war or ear에 모든 것을 포함하였기에 어플리케이션의 기술 스택을 변경하는 것을 주저하게 됩니다. 예를 들어서 일부 컴포넌트는 JVM내에서 동작하는 Groovy나 Scala와 같은 다른 언어를 사용하여 처리하려고 할 경우 이런 종류의 아키텍처를 사용하면 어떤 side-effect가 발생 할지 예측이 어려우므로 리펙토링을 해야 하지만 코드가 너무 방대해서 리펙토링을 하기가 어렵습니다.
  • 어플리케이션내의 특정 기능이 실패하면 전체 어플리케이션에 영향을 미칩니다. 그리고 퍼포먼스가 나쁜 특정 함수/메소드의 영향이 전체 어플리케이션에 고통을 주게 됩니다.
  • 이런 아키텍처에서의 scaling은 서버마다 동일한 war or ear을 배포하여 수행해야 합니다. 각각 서버는 동일한 리소스를 사용하게 되므로 이 것은 효율적인 방법이 아닙니다.
  • 어플리케이션이 커질수록 개발자는 작은 단위로 작업을 축소할 수 있어야 합니다. Monolithic은 모든 것이 하나로 묶여 있기 때문에 개발자가 독립적으로 모듈을 개발하고 배포 할 수 없습니다. 그리고 개발은 협업으로 진행되므로 다른 개발자에 의존성때문에 개발 시간이 길어지게 됩니다.
위의 언급한 내용을 염두하고 마이크로 서비스에 대해서 알아보겠습니다.

마이크로 서비스

아키텍처의 중요한 포인트는 바로 확장성입니다. 많은 사람들이 확장성을 얘기 할 때는 The Art of Scalability라는 책을 인용합니다. 이 책에서는 Scaling을 세 가지로 정의합니다.
X 축은 horizontal(수평) application scaling (Monolithic 아키텍처에서도 가능)을 나타내며, Z축은 비슷한 것들을 분할하여 어플리케이션을 스케일링함을 의미합니다. (Z축은 데이터를 분할하여 사용자의 요청에 따라 해당 샤드에 redirect하는 샤딩 개념으로 이해하면 됩니다.)
Y축이 가장 중요하고 우리가 눈여겨 봐야할 대상입니다. 이 축은 기능적인 분해(해체)를 의미합니다. Monolithic에 포함되어 있는 다양한 기능을 독립적인 서비스로 바라보는 전략을 취합니다. 따라서 모든 기능을 전체 어플리케이션에 배포하지 않고 각각 서비스를 독립적으로 배포 할 수 있습니다.
이렇게 하면 개발자의 생산성이 향상되고 기능 변경시 side-effect 걱정 없이 변경하고 배포 할 수 있는 유연성을 제공합니다.
예전 Monolithic 방식과 비교해보세요.

마이크로 서비스의 장점

벤더사 중심의 SOA에 비해서 마이크로서비스는 Amazon, Netflix, eBay와 같은 글로벌 서비스 플레이어가 사용할 만큼 강력합니다.
  • Improves fault isolation : 단일 모듈의 장애에 대해 전체 어플리케이션은 크게 영향을 받지 않습니다.
  • Eliminates long-term commitment to a single technology stack : 각 개별 서비스에서 새로운 기술 스택을 시험하고자 한다면 바로 시작할 수 있습니다. 의존 관계가 기존 Monolithic 아키텍처보다 적고 유연합니다.
  • 기능 단위로 서비스가 되기에 새로 조인한 개발자가 기능을 더 쉽게 이해 할 수 있습니다.

마이크로 서비스의 배포 및 가상화

마이크로 서비스기반의 어플리케이션을 배포하는 가장 좋은 방법은 컨테이너 가상화를 이용하는 것입니다. (Docker)
AWS와 같은 IaaS업체의 VM을 이용하여 마이크로 서비스를 배포할 수 있지만 작은 단위의 마이크로 서비스는 VM의 리소스를 전부 활용 하지 못해 비용 효율성을 저하 시킬 수 있습니다. 따라서 컨테이너 기반으로 배포를 하는 것이 유리합니다.
OSGI(Open Service Gateway Initiative) 번들을 사용하여 코드를 배포 할 수도 있지만, 이 경우에는 management and isolation tradeoff와 관련된 단점이 존재합니다.

마이크로 서비스의 약점

아래는 마이크로 서비스 설계와 관련된 잠재적인 약점에 대한 부분입니다.
  • 분산 시스템 개발은 일반 개발보다 복잡합니다. 모든 것이 독립적인 서비스이기 때문에 각 모듈간의 인터페이스를 신중하게 처리 해야 합니다. 서비스중 하나가 응답하지 않게 될 경우에 대한 방어코드도 작성해야 합니다. 호출 대기 시간이 발생하게 되면 복잡한 상황이 발생할 수 있습니다.
  • Multiple Databases 및 트랜젝션 관리가 어려울 수 있습니다.
  • 마이크로 서비스 기반의 어플리케이션을 테스트하는 것은 번거로울 수 있습니다. 테스트를 시작하기 전에 의존성이 있는 서비스를 미리 확인해야 합니다.
  • 마이크로 서비스의 배포는 복잡 할 수 있습니다. 각 서비스 간의 조정이 필요 할 수 있습니다.
하지만, 이런 부분들은 자동화 도구를 사용하면 해결 할 수 있습니다.
끝으로, 마이크로 서비스는 벤더사 중심이 아닌 서비스사 중심의 아키텍처이고 이미 글로벌 플레이어에 의해 검증이 되어 있습니다.
하지만, 좋은 아키텍처도 상황과 사람에 의해 달라지게 됩니다.
마이크로 서비스 아키텍처를 경험했거나 경험할 계획이 있으신가요?

참조




Java class를 Python에서 사용하기

프로젝트내에서 만든 Java Util class를 Python에서 사용해야 하는 케이스가 발생했다. py4j, jnius, subprocess .., 등등의 방법이 있었다.
py4j
GatewayConnection 방식으로 진행하기에 내부적으로 socket을 사용함. Fault 발생 여지가 있어서 부적절하다고 판단
jnius
Java class를 수행전에 JVM을 start 해야하고 종료시 shutdown 해야 함. Fault 발생 여지가 있어서 부적절하다고 판단
subprocess
os command를 수행하는 방법, 별도의 package를 설치하지 않아도 되고, 위의 package에 비해 fault 발생 여지가 작다고 판단 아래는 샘플 코드 jar파일은 executable jar여야 한다.
#python 2.7

import subprocess def call(value):
cmd = ['java','-jar','{jar 파일 경로}','{arg}',value]
return subprocess.check_output(cmd,shell=False) def main():
result = call("test")
print "result if __name__ == "__main__":
main()
#python 2.7/2.6

import subprocess def call(value):
cmd = ['java','-jar','{jar 파일 경로}','{arg}',value]
fd_open = subprocess.Popen(cmd,stdout=subprocess.PIPE,shell=False).stdout
result = fd_open.read().strip()
fd_open.close()
return result def main():
result = call("test")
print result if __name__ == "__main__":
main()

12/15/2016

Spring-boot에 Swagger2 설정

RESTful API를 만들 경우에는 문서화가 중요하고, API문서와 코드와의 변경 사항을 반영하는 것은 지루한 일입니다.
일반적으로 Swagger를 사용할 경우에는 @Api, @ApiOperation과 같은 Annotation을 사용하여Swagger에 보여질 내용을 설정하게 됩니다.
Swagger2의 구현체인 Springfox를 사용할 경우에는 이런 부분들이 자동화되게 됩니다.

타겟 프로젝트

메이븐 의존성 추가

<!-- Swagger2 -->
<dependency>
<groupId>io.springfox</groupId>
<artifactId>springfox-swagger2</artifactId>
<version>2.4.0</version>
</dependency>
<!-- Swagger UI -->
<dependency>
<groupId>io.springfox</groupId>
<artifactId>springfox-swagger-ui</artifactId>
<version>2.4.0</version>
</dependency>

프로젝트에 설정하기

@Configuration @EnableSwagger2 public class SwaggerConfig { @Bean public Docket api() { return new Docket(DocumentationType.SWAGGER_2).select().apis(RequestHandlerSelectors.any()) .paths(PathSelectors.any()).build(); } }
위의 설정을 통해 스프링 부트에 Swagger2를 통합할 수 있습니다.

확인하기

JSON type의 response를 보게 되면 올바르게 설정이 된 겁니다. Swagger에서는 보다 편하게 확인하기 위해 Swagger-UI를 제공해줍니다.

Swagger-UI로 확인하기

기타 고급 설정에 대한 부분은 아래의 참조 URL을 확인하세요. 테스트에 사용된 Full-source는

참조

12/14/2016

Redis Java client -lettuce 소개

Lettuce는 synchronous, asynchronous, reactive usage를 지원하는 scalable thread-safe한 Redis Java client 입니다.
lettuce — IntroductionLettuce is a scalable thread-safe Redis client for synchronous, asynchronous and reactive usage. Multiple threads may…
redis.paluch.biz
Micro Service Architecture(MSA)를 적용하면서, 앞단의 Gateway의 Discovery영역에 redis로부터 active instance를 read하는 부분에서 Jedis를 사용하였지만 Jedis는 Multiple threads상에서 connection pool 성능이 생각보다 만족스럽지 않았고 차선책으로 Lettuce를 사용하였고 결과는 만족스럽습니다.

12/13/2016

개발 방법론 고찰

요즘 주위에 애자일(특히 스트럼)로 프로젝트를 진행하는 곳이 많아지고 있지만, 대부분은 실패로 마무리 됩니다. 이유는 무엇일까? 방법론을 올바르게 숙지하지 못해서? 아니면 팀 문화가 따라주지 않아서? 아래의 내용은 개인적인 생각임을 미리 밝혀둡니다. 저는 “사기(士氣)”의 문제라고 생각합니다. 스크럼을 이용할 경우 아래의 장점들을 취할 수 있습니다.
  • 진척 사항의 시각화
  • 관리자 측면에서는 일이 잘 진행되고 있다는 느낌을 받는다
  • 해야할 업무에 대해서 놓치지 않게된다
위의 장점들은 그냥 만들어지는 것이 아닙니다. 스크럼의 근본 취지는 work 시간에 제한을 두고 최대한 생산성을 끌어내는 것이 핵심입니다. 추정을 통해 작업 시간을 정하고 스프린트를 진행하게 됩니다. 만약, 추정이 틀렸다면 인공적으로 만들어진 스프린트를 완수하기 위해서 과부하가 걸리던지 프로세스를 속이는 플래닝을 해야 합니다. (스프린트의 변경은 수많은 미팅을 통해야 하지요)
틀린 추정이 빈번해지고 이런 상황들이 계속 발생하게 되면 사업쪽은 기술쪽이 목표를 놓치고 있다고 생각할 것이고 기술쪽은 사업쪽이 목표를 변경하고 있다라고 생각할 수 있습니다. 이렇게 되면 양쪽다 사기가 꺽이게 됩니다.
그리고, 진척 사항의 시각화로 인해 개발팀은 컨트롤을 받고 있다 혹은 도구가 된 것 같다라는 느낌을 받을 수 있고 이 또한 사기에 영향을 주게 됩니다. 그렇다고 여유로운 스프린트를 수행하게 되면 관리의 리스크에 직면하게 됩니다. 스크럼의 규약이 우리팀에는 적합하지 않다라는 판단이 들었습니다. 우리는 다시 생각할 필요가 있습니다. 애자일이 나오게 된 배경이 무엇이었는지에 대해서… 개인적으로 느낀 스크럼에 대한 대안으로 칸반을 고려하게 되었습니다.
  • 사업팀과 기술팀의 분리
  • 업무에 대한 연속적인 흐름
  • Work-In-Process(WIP)를 통한 생산성과 벨로시티를 제어
  • 도구로 느껴지지 않도록, 능동적으로 일 할 수 있도록
  • 프로젝트 관리 오버헤드 감소



칸반 프로세스는 스크럼에 비해 단촐합니다. 칸반을 이용하게 됨으로써 스프린트 플래닝이 사라지게 되었고 PO(사업팀)에서는 “To Do”만 관여하게 되고 나머지 보드는 기술팀이 관리를 하게 됩니다.
즉, “To Do”의 일거리가 개발팀으로 push 되는 것이 아닌 pull하는 당김 방식으로 업무가 흐르게 됩니다.
칸반으로 작업의 흐름을 보기 위해 Asana를 활용합니다. (얼마전에 Kanban view 기능이 추가됨) 팀간의 Communication은 Glip을 활용합니다.
회의를 최대한 줄이고 Online 커뮤니케이션을 통해 해결하려고 합니다. 칸반에서는 Work-In-Process (WIP)의 제약을 지키는 것이 핵심입니다.
스크럼의 경우에는 스프린트별 작업량을 제한하지만 칸반은 작업 구간별 작업량을 제한하게 됩니다. 능동적인 팀일 경우에는 이는 큰 생산성으로 다가 옵니다.
칸반은 스크럼에 비해 규칙이 작습니다. 그렇기 때문에 개선하는 노력이 필요합니다.

12/04/2016

Open Baton: a Framework for Virtual Network Function Management and Orchestrator (NFVO)

Open Baton은 OPNFV의 Orchestra 영역에 Integration되는 NFVO이고 ETSI NFV MANO specification에 대한 구현체입니다. 현재 release 3까지 런칭되었습니다.

위의 아키텍처에서 Open Baton은 크게 NFVO, VMFM, FM, AE를 제공하고 있습니다. 그리고 Open Baton은 plugin을 통하여 다른 VIM에 Integration을 할 수 있습니다.
현재는 Open Stack에 대한 plugin을 제공해주며 다른 VIM에 연동을 위해서는 plugin을 만들어야 하는데 이 부분에 대한 sdk를 제공해주고 있습니다.

9/26/2016

Serverless의 시대

Cloud Computing의 발전으로 인해 과거와는 달리 더 이상 많은 인력이 필요없게 되는 것 같다. 구글 트렌드에서 “programmer”와 “software engineer”의 검색량을 2004년 부터 현재까지 추출해보았다.


점점 검색량이 줄어들고 있다. 예전에는 리눅스 전문가, DB 전문가, Backend 전문가, Frontend 전문가 등등이 필요했지만, 이제는 적은 인력으로 충분히 해결 가능하다.

이런 현상이 발생한 이유중에 하나는 “Serverless” 일 것이다. (아직 초창기이긴 하지만…) Serverless는 서버가 없다라는 의미가 아니고, 관리해야 할 Server가 0으로 수렴한다는 의미이다.
즉, 서비스 단위의 코드를 개발하고 배포에 집중하겠다라는 기술이라고 볼 수 있다. 이런 점이 기존의 PaaS와 대비되는 특징이다.
다가올 Serverless의 시대에도 예전의 전문가라는 직종이 남아있을지 의문이다.
우리는 어떤 준비를 해야 할까?

Websocket Proxy

Websocket proxy가 필요한 케이스가 생겼다. 일반적으로는 독립된 proxy server를 통해 지원하면 되지만, Servlet단에서 지원을 해야 하는 상황이다. 아래의 그림처럼 제공되는 것이 중간의 Gateway를 통해 Communication이 되어야 하는 상황이다.


아래의 그림처럼 중간에 다른 서버를 거쳐야 한다.


가장 편하게 할 수 있는 방법은 jetty-proxy library를 이용하는 방법이다.

이미 구현체가 존재하기 때문에, 필요한 부분만 customizing하여 Servlet으로 등록하면 된다.

9/12/2016

MQTT Borker 선정 고려사항

MQTT Broker를 선정시 고려할 사항을 정리합니다. MQTT는 서비스 품질(QoS)에 대해서 3가지 레벨의 신뢰성을 제공합니다. 일반적으로는 QoS 0를 선택하고, Application Level에서 처리하고 있습니다.

MQTT 보안에는 크게 Authentication, Authorization 부분과 Network 그리고 Payload 검증 부분으로 나눠집니다.
위의 3가지 요소중에 Clustering 방식을 가장 선호하며 MQTT Cluster를 구성하는 목적은 아래와 같습니다. 
MQTT Broker를 사용하는 Subscriber의 Backend server가 같은 기능을 갖는 여러대로 구성되는 Case가 존재합니다. 이럴 경우 Subscriber Server 앞단에 HAProxy를 이용해서 한대의 서버만 message를 받도록 할 것인지, 아니면 Broker에서 제공하는 Exclusive 기능을 이용할 것인지 고려해야 합니다.
그 외에, Integration 부분도 고려해야 합니다.


9/04/2016

P-Value (유의확률)

P-value에 대해서 알기전에 귀무가설(Null Hypothesis: H0)과 대립가설(Alternative Hypothesis: H1)에 대해서 이해를 해야 합니다. 우리가 어떤 가설을 만들었을 때, 가설 검정 절차에서 선행되어야 할 부분이 귀무가설과 대립가설의 설정이고, 두 개의 가설이 정반대로 설정되어야 합니다. 귀무가설은 기존에 일반적으로 받아들여지고 있는 내용이며,아래와 같이 세 가지 유형이 있습니다.
~와 같다. (=), ~ 이상이다. (>=), ~ 이하이다. (=<)
그리고 대립가설은 귀무가설과 반대되는 새롭게 검정하고자 하는 주장입니다. 귀무가설과 정반대로 설정해야 하고 세 가지 유형이 있습니다.
~ 와 같지 않다. (!=), ~ 미만이다. (<), ~ 초과이다. (>)
가설 검정은 “같다”, “크다”, “작다”의 세 가지 내에서 이루어집니다. 이 상황을 벗어난 표현은 수학 특성상 처리하기가 어렵기 때문입니다. 이제 예제를 보면, 제품의 불량률이 5%이다. 하지만 제품에 대한 고객 Claim이 자주 일어나서 불량률이 5% 보다 클 수 도 있다는 주장이 나오고 있다. 이 부분을 검정 하기 위한 귀무가설과 대립가설을 설정하시오. 대립가설로 불량률이 5%보다 클 수 도 있다는 주장이 나왔으므로
H1: p > 0.05
로 설정합니다. 귀무가설은 대립가설과 정반대이므로 아래처럼 설정합니다.
H0: p <= 0.05
P-value는 귀무가설이 올바르다는 전제를 가지고 통계값이 실제로 관측된 값 이상일 확률을 의미합니다. 관찰된 데이터가 귀무가설을 지지하는 정도를 보여줍니다. (= 유의수준) P-value가 작을 수록 귀무가설을 지지하는 정도가 낮아지므로 귀무가설은 기각되게 됩니다. (=대립가설 채택) 즉, 귀무가설이 맞다고 가정함으로써 귀무가설을 기준으로 삼고 관찰된 검정 통계량이 얼마나 멀리 떨어져있는지 보는 것입니다.
위의 그래프처럼 P-value가 알려주는 것은 차이가 생겨나는 것이 우연한 것인지 변수에 따른 것인지에 대한 여부입니다. 일반적으로 95%의 신뢰구간이면 0.95의 신뢰수준으로 생각하시면 됩니다. 유의수준은 1에서 신뢰수준을 뺀 값입니다. (1– 0.95 = 0.05), P-value < 0.05 라고 하면 귀무가설이 일어날 확률이 5%이하인 것을 의미합니다. P-value를 가지고 모든 것을 판단 할 수는 없습니다. P-value는 관측되지 않은 사실들의 확률도 포함하고 있기 때문입니다.
유의확률은 가설이 옳다거나 차이에 대해서 알려주는 지표가 아니기 때문에 가설이 자료와 일치하는지 아닌지만 판별할 수 있습니다.

7/05/2016

Maven과 Ant

현재 진행중인 프로젝트는 폐쇄적이다. 다시말하면 폐쇄망 환경이다. Maven의 Central Repository는 꿈도 꾸지 못하는 환경이다. 내부 Nexus를 통해서 3rd party library를 지원해야 한다. 이런 환경에서 굳이 Maven을 사용해야 하는지에 대해서 의구심을 가지는 사람들이 있다. Ant와 Maven중 어느 것이 더 나은가?는 논쟁거리이지만, 본 글에서는 몇 가지의 차이점을 명확히 하고자 한다.


Ant는 고전이다. 빌드 프로세스로서는 훌륭하다.
Maven은 Apache Turbine 프로젝트의 빌드를 단순화하기 위해서 탄생했다.
Apache Turbine 프로젝트는 여러 프로젝트마다 Ant 빌드와 Jar파일들이 있었고 이런 환경들이 빌드를 복잡하게 만들었고 프로젝트가 점차 커져감에 따라 프로젝트를 관리하고 빌드하는 표준 방법이 필요하게 되었기 때문에 Maven이 세상에 나왔다.
끝으로, Ant는 오랫동안 자바 빌드의 최고 자리를 지켜왔고 여러 곳에서 현재도 널리 쓰이고 있다. 반면에 Maven은 프로젝트 관리 플랫폼 그 이상이다. 빌드 관리 작업을 간단하게 해주고 프로젝트 사이의 공통 인터페이스를 조성하는 것을 도와준다. Maven은 빌드 도구 그 이상의 것(a set of standards, 공통 인터페이스, Life cycle, standard repository, layout..,)을 포함하고 있다.
폐쇄망 환경에서 Library 등록이 귀찮다는 이유로 Maven을 사용하지 않는일이 없길 바란다.

비오는 날엔.,


7/01/2016

Apache Storm 테스트

저번에 설치한 Apache Storm을 가지고 몇 가지 테스트를 진행하였다. 굳이 테스트를 진행하지 않고도 결과는 예측이 가능했지만….,
#테스트 목적
  • Spout, Bolt가 Single node일 경우 Sequential이 보장되는가?
  • Spout, Bolt가 Parallel node일 경우 Sequential이 보장되는가?
우선, 테스트를 위해 JsonFormatterBolt, DataMapperBolt, ResultBolt와 SingleTopology, ParallelTopology 클래스를 만들었다.
결론은 생각한바와 같이 Single worker 작업시에만 Sequential을 보장한다.
소스는 이곳을 참조

6/29/2016

Command pattern (커맨드 패턴)

옆에 계신 정모 부장님이 요 근래에 Batch 관련 가이드를 준비하고 계신다. 모듈당 N개의 Batch 프로그램이 있다고 하면, 각각 Executable 형태로 제공하는 것이 좋을 것인가? 아니면 관리적 측면에서 Grouping 하여 제공하는 것이 좋을 것인가에 대한 의견이 분분하다.
이런 경우에는 각 모듈별로 하나의 Batch 프로젝트를 구성하고 수행해야 할 Job Method 호출을 캡슐화(Encapsulation) 하는 것에 대해서 공감대가 형성되었다.


DPDK (Data Plane Development Kit) 란?

오늘날 네트워크 기술은 널리 활용되고 있고, 전용 네트워크 어플라이언스 장비들을 가상화 네트워크에서 동작 시키기 위한 NFV(Network Function Virtualization) 기술이 각광을 받고 있습니다. NFV는 기존 장비들을 동일한 성능에서 지원한다라는 전제 조건이 있습니다. 일반적으로 우리가 Native환경에서 어떤 프로그램을 사용하는 것과 가상화 환경에서 사용할 경우에는 Performance의 Gap이 존재하게 됩니다.
DPDK는 Intel에서 개발한 고성능 패킷 처리 소프트웨어로 고속 패킷 처리를 위한 라이브러리와 드라이버를 제공하고 NFV의 네트워크 성능을 높이기 위한 핵심 기술입니다.
DPDK의 특징:
기존 Kernel에서 네트워크 패킷을 처리하는 방식과는 다르게 응용 어플리케이션이 User Space의 DPDK 라이브러리를 사용하여 직접 엑세스한다는 점이 특징입니다.
즉, 응용 어플리케이션을 특정 CPU core에 할당하여 가장 높은 우선 순위로 실행하고, Kernel을 거치지 않고 직접 네트워크 카드의 패킷을 처리하게 되면 네트워크 성능을 비약적으로 향상 시킬 수 있습니다.
이런 장점을 갖고 있는 DPDK도 단점은 존재합니다.
DPDK를 이용하는 응용 어플리케이션을 적용할 경우에는 아래의 사항을 고려해야 합니다.