DPDK (Data Plane Development Kit) 란?

오늘날 네트워크 기술은 널리 활용되고 있고, 전용 네트워크 어플라이언스 장비들을 가상화 네트워크에서 동작 시키기 위한 NFV(Network Function Virtualization) 기술이 각광을 받고 있습니다. NFV는 기존 장비들을 동일한 성능에서 지원한다라는 전제 조건이 있습니다. 일반적으로 우리가 Native환경에서 어떤 프로그램을 사용하는 것과 가상화 환경에서 사용할 경우에는 Performance의 Gap이 존재하게 됩니다.

DPDK는 Intel에서 개발한 고성능 패킷 처리 소프트웨어로 고속 패킷 처리를 위한 라이브러리와 드라이버를 제공하고 NFV의 네트워크 성능을 높이기 위한 핵심 기술입니다.

DPDK의 특징:

• 리눅스 or 윈도우의 Kernel 대신에 네트워크 패킷을 처리하는 응용 소프트웨어를 제공하고 전용 CPU core를 할당하여 네트워크 카드의 패킷을 Kernel을 거치지 않고 직접 처리
• 오픈 소스로 제공

기존 Kernel에서 네트워크 패킷을 처리하는 방식과는 다르게 응용 어플리케이션이 User Space의 DPDK 라이브러리를 사용하여 직접 엑세스한다는 점이 특징입니다.

즉, 응용 어플리케이션을 특정 CPU core에 할당하여 가장 높은 우선 순위로 실행하고, Kernel을 거치지 않고 직접 네트워크 카드의 패킷을 처리하게 되면 네트워크 성능을 비약적으로 향상 시킬 수 있습니다.

이런 장점을 갖고 있는 DPDK도 단점은 존재합니다.

• DPDK를 지원하는 네트워크 카드가 한정되어 있다라는 점 (http://dpdk.org 참조)
• 응용 어플리케이션에서 해야 할 부분이 많아지는 점
• 네트워크 패킷을 직접 처리
• 네트워크 패킷 헤더를 보고 TCP/IP와 같은 프로토콜 판별부터 동작하는 기능까지 구현해야 함

DPDK를 이용하는 응용 어플리케이션을 적용할 경우에는 아래의 사항을 고려해야 합니다.

• 응용 어플리케이션이 직접 가상 NIC에 접근
• Guest OS의 Kernel을 skip하고 응용 어플리케이션에서 직접 가상 NIC를 acess하여 개발 (가상 NIC와 물리 NIC 사이의 패킷처리는 Hyper 바이저가 제공하는 가상 스위치를 이용하게 됨으로 Over-head는 기존과 다르지 않음)
• 응용 어플리케이션이 가상 OS의 DPDK를 이용하여 가상 NIC에 접근
• Guest OS의 DPDK 지원 프로그램에서 물리 NIC를 직접 조작하는 방법이며, 이 경우 Hyper 바이저가 특정 물리 NIC를 가상 머신까지 통과시킵니다. Hyper 바이저가 제공하는 가상 스위치의 기능은 이용할 수 없기에 멀티플 가상 시스템에서 물리 NIC를 공유하고자 한다면 SR-IOV를 지원하는 물리 NIC가 필요하게 됩니다. (SR-IOV는 하나의 물리 NIC를 가상으로 여러개의 NIC로 보여주는 기능을 의미)
• Host의 가상 NIC를 DPDK가 사용
• vSwitch에 DPDK를 사용하여 vSwitch와 물리 NIC사이의 패킷 처리 속도를 향상

Read More

Command pattern (커맨드 패턴)

옆에 계신 정모 부장님이 요 근래에 Batch 관련 가이드를 준비하고 계신다. 모듈당 N개의 Batch 프로그램이 있다고 하면, 각각 Executable 형태로 제공하는 것이 좋을 것인가? 아니면 관리적 측면에서 Grouping 하여 제공하는 것이 좋을 것인가에 대한 의견이 분분하다.

이런 경우에는 각 모듈별로 하나의 Batch 프로젝트를 구성하고 수행해야 할 Job Method 호출을 캡슐화(Encapsulation) 하는 것에 대해서 공감대가 형성되었다.

http://kapilnevatia.blogspot.kr/2011/11/command-pattern.html

Read More

스몰월드 효과

지인의 지인이 지인일 확률이 높은 이유는 무엇일까? 한 사람이 일반적으로 몇 명이나 알고 있을까? 이 질문에 대해 미국인과 일본인을 대상으로 설문조사가 실시되었다고 한다. 그 결과 평균 지인 수는 미국인은 200–300명, 일본인은 150명 정도였다.

스몰 월드 효과란 모르는 사람을 최종 목표로 설정하고 지인만을 이용하여 연락을 취할경우 5–6명을 거치면 목표 인물에 도달할 수 있다는 실험 결과에서 나온 개념이다.

친구와 지인은 어떻게 정의할 수 있을까? 어떤 사람은 술잔을 주고 받으면 친구라 여길 것이고, 어떤 사람은 인사만 나누는 사이면 친구라 여길 것이다.

이처럼 관계에 대한 정의는 사람마다 주관적일 것이다. SNS는 이런 제약에서 자유롭다. 관계 형성 및 유지의 부담, 경제 합리성에서 자유롭기 때문이다.

• p = 무작위로 링크될 확률
• p = 0, 링크가 일정 패턴으로 이루어지는 경우
• p = 1, random

Clustering = a와 b와 지인, b와 c와 지인인데, a도 c를 안다면 클러스터링 규모가 커짐 클러스터링 규모가 클수록 몇개의 특이한 링크 지점간의 path길이가 단축되는 것을 스몰 월드 효과라고 정의함.

의외로 우리는 좁은 세상에 살고 있으므로, 서로서로 감기 조심 합시다.

Read More

베이커 넘버 (The Oracle of Bacon)

좀 오래된 얘기지만 버지니아 대학에서 만든 “The Oracle of Bacon(http://oracleofbacon.org)”사이트가 있다.

이 사이트는 일종의 영화배우에 대한 데이터베이스이다. 영화에 출연한 배우이름을 입력하면 Bacon Number를 알려준다.

Bacon Number의 의미는 영화배우 “케빈 베이컨”과 함께 영화에 출연했는지에 대한 여부와 출연 횟수를 기준으로 둘 사이의 거리를 측정하고 그 배우가 케빈 베이컨까지 몇 단계만에 연결이 되는지를 나타내는 수이다.

헝가리의 수학자 폴 에르되시(Paul Erdos)는 세계 각국의 수학자들과 공동 연구를 하였고 발표한 논문은 약 1500편이다.

이 정보를 기준으로 에르되시 제자들은 에르되시에게 0이라는 수를 공동 저자에겐 1, 공동 저자들과 함께 공동 연구한 저자들은 2 ….. 이렇게 수를 계속 지정해보았더니 유명한 수학자들 대부분은 2~5사이의 에르되시 넘버가 나왔다고 한다. 이 아이디어는 관계에 적용될 수 있고, 페이스북이 재밌게 이 문제를 풀어냈다. 일하는 곳에서도 이 아이디어는 적용된다.

니콜라스 크리스태키스, 제임스 파울러의 <행복은 전염된다="">의 책에서는 행복과 불행도 전염된다고 한다. 시뮬레이션을 해보면, 프로젝트 참여자가 하는 말과 행동은 관계를 통해 파도처럼 물결치며 나아간다. 그리고 대략 ½/3단계의 관계까지 영향을 미친다.

얼핏 보기에는 이런 효과들은 별로 중요하게 보이지 않을 수도 있다. 수학적으로 분석한 연구결과를 보면, 관계자의 행복이 나에게 영향을 미치는 정도가 ½/3단계(약15%/10%/6%), 불행은 약50%/25%/15%라고 언급하고 있다.

결국, 프로젝트 참여자들간에는 알게모르게 서로간에 주기적으로 자극을 주고 있다. 그것이 행복이든 불행이든…

-오늘 불행의 자극을 준 나…

Read More

나이팅게일 그래프

통계학개론 수업중에 “나이팅게일 그래프”에 대해서 교수님이 언급하셨다. 이제까지 나이팅게일을 백의의 천사, 사랑의 천사의 이미지로 기억하고 있었는데 사회 통계학의 개척자였다니…

크림전쟁시 부상병을 간호하던 나이팅게일은 전쟁터에서 전투로 인한 사망보다 열악한 치료 환경 및 위생탓에 사망하는 병사가 많다는 사실을 알게 되었고 이를 그래프로 나타내어 빅토리아 여왕에게 병원 시설과 환경을 개선할 것을 요청했고, 그 후 영국 정부는 위생 개혁을 하였고 사망자 수가 급격히 줄어들었다고 한다.

만약, 구두로 전달했거나? 글로 표현했다면? 지원을 받을 수 있었을까? 말 열 마디보다 숫자를 포함한 그래프가 더 큰 영향력을 미치는 경우가 많다.

Read More

IoT Applications

 

Smart cities

• Smart Parking
• Structural Health
• Noise Urban Maps
• Traffic Congestion
• Smart Lighting
• Waste Management
• Intelligent Transformation Systems

Smart Environment

• Forest Fire Detection
• Air Pollution
• Landside and Avanlanche Prevention
• Earthquake Early Detection

Smart Meter

• Water Quality
• Water Leakages
• River Floods

Smart Metering

• Smart Grid
• Tank Level
• Photovoltaic Installations
• Water Flow
• Silos Stock Calculation

Security & Emergencies

• Perimeter Access Central
• Liquid Presense
• Radiation Levels
• Explosive and Hazadous gases

Retail

• Supply Chain Control
• NFC Payment
• Intelligent Shopping Application
• Smart Product Management

Logistics

• Quality of Shipment Conditions
• Item Location
• Storage Incompatibility Detection
• Fleet Tracking

Industrial Control

• M2M Applications
• Indoor Air Quality
• Temperatuer Monitoring
• Ozone Presense
• Indoor Location
• Vehicle auto-diagnosis

Smart Agriculture

• Wine Quality Enhancing
• Green Houses
• Golf Courses
• Compost
• Meteorological Station Network
• Smart Animal Farming
• Offspring Care
• Animal Tracking
• Toxic Gas Levels

Domotic & Home Automation

• Energy and Water Use
• Remote Control Appliances
• Intrusion Detection Systems
• Art and Goods Preservation

eHealth

• Fall Detection
• Medical Fridges
• Sportsmen Care
• Patients Surveillance
• Ultraviolet Radiation

source: REDtone

Read More

무인 자동차의 고민

 요즘 자율주행차량이 많은 관심을 받고 있다. 회사내의 동료와 이 부분에 대한 얘기를 가볍게 하다가 “돌발 상황 발생시, 누구를 보호 할 것이냐?”에 대한 문제가 제기됐다. 상황에 따라 다르지 않나? 라고 생각을 했지만, 아래의 자료를 보니 흥미롭다.

Why Self-Driving Cars Must Be Programmed to Kill

MIT Technology Review Self-driving cars are already cruising the streets. But before they can become widespread, carmakers must solve an…www.technologyreview.com

 위의 그림과 같은 상황이 발생 했을때, 무인 자동차는 어떤 행위를 해야 할까?

1. 한사람을 다치게 한다. (다수가 다치는 상황을 피해야 하므로…)
2. 보행자를 보호해야 할까? 운전자를 보호해야 할까?
3. 여러 사람을 보호해야 할까? 운전자를 보호해야 할까?

위의 1, 2, 3은 사람이 판단하기에도 어려운 문제다. 이런 판단을 위해 MIT에서는 설문조사를 진행했다.

결과는 많은 사람들이 “희생자를 최소화”하는 쪽의 알고리즘에 동의 했다. 이 부분은 또다른 문제를 제기했다.

만약 내가 무인 자동차를 구매한다고 하면 “ Utilitarian을 우선시 하는 무인차”를 구매해야 하냐는 점이다.

돌발 상황 발생시 운전자를 희생시키기 때문에… 사람과 사람사이의 문제에 “기계”가 포함되었기에 이 부분은 당분간 풀리기는 어려워 보인다.

Read More

Kubernetes란 무엇인가?

 

Kubernetes는 구글에서 공개한 리눅스 컨테이너 관리 시스템입니다. 일반적으로 Docker Orchestrator라고 표현합니다. 얼마전 우리 회사에서 Kubernetes를 활용한 프로젝트가 있어서, 궁금하기에 조사해봤습니다. Docker를 이용하는 Machine이 Single일 경우에는 Orchestration에 대해서 고민할 필요가 없습니다. Docker client의 command를 사용하여 Single host에 대해서만 관리를 하면 되기 때문이죠. 저도 개인적으로는 이렇게 사용하고 있습니다.

하지만, 두대 이상의 Host상에서 Docker가 존재할 경우에는 얘기가 달라집니다. 사용자가 요청한 Docker 컨테이너를 어느 Host에 설치해야할까? 라는 고민이 시작됩니다. 결국, Manual하게 Resource에 여유가 있는 Host를 선택해서 컨테이너를 생성하게 됩니다.

만약에 Host가 50대 혹은 1000대라면 어떻게 해야 할까요? Manual하게 관리하기가 쉽지 않겠지요? 어느 Host에 어떤 Docker container가 있는지, LB는 어떻게 해야 할지, 이미지 동기화 처리는 어떻게 해야 하는지.., 등등의 고민을 해야 하고 이런 작업들이 Manual하게 이뤄지게 됩니다. 결국, 관리하는 사람은 단순 노동에 지쳐서… 이직을 결심할지도 모릅니다.

Kubernetes는 이런 힘든 작업을 누군가가 대신해주면 어떨까? 라는 고민에서 시작되었습니다. 물론 Kubernetes말고도 이런 프로젝트는 여러개가 존재합니다. (Swarm, Mesos ..,)

Kubernetes는 Multiple Host에서의 Docker Container를 관리하는 Container Orchestration이고 특징은 아래와 같습니다.

특징

• Multiple Docker Pool
  • 사용자는 Docker Daemon의 대수를 알 필요가 없고, “N개의 Container가 필요하니 A이미지로 생성해줄래?”라는 명령만 내리면 Kubernetes가 Multiple Docker Daemon에 알아서 Container를 생성해줍니다.
• 다른 서버 Container와의 Interface
  • Docker Container는 Docker Daemon이 있는 Host내의 Private IP를 가지고 있는데, A 호스트의 Container와 B 호스트의 Container가 서로 통신을 하기가 어렵습니다.
  • 위의 문제점을 Kube-proxy, flanneId의 sub tool로 가능하게 해줍니다.
• Container fail 처리
  • Container가 fail 상태일 경우, 동일한 Container를 생성해서 지속적인 서비스가 가능하게 합니다.
• Load Balance
  • Round-robin 형태의 로드밸런싱을 제공하여 Cluster로 묶인 Container에 접근이 가능하게 해줍니다.

주요 구성 요소

Cluster

• Application Container들이 배치되고 실행되는 컴퓨팅 자원

Pod

• Application 실행에 필요한 Container 집합
• Lifecycle이 같은 Container 그룹
• Deploy 및 실행의 최소단위

Replication Controller

• pod들의 Lifecycle 관리자
• pod들의 health status를 체크

Service

• pod 집합을 대표하는 이름 (e.g. IP address)
• 로드밸런서

Label

• pode들의 Grouping/조직화를 위해 관리하는 key-value 메타 데이터

보다, 자세한 사항은 아래를 참조

http://kubernetes.io

Read More