SDN: 네트워크를 코딩하고 민첩성을 깨우세요.

SDN: 네트워크를 코드로 제어하여 민첩성을 확보하세요

네트워크 제어의 재정의: SDN의 힘

빠르게 변화하는 최신 IT 인프라(IT infrastructure) 환경에서, 네트워크 민첩성(network agility)은 바람직한 특성(desirable trait)을 넘어선 필수적인 요소(absolute imperative)가 되었습니다. 고유 하드웨어(proprietary hardware)에 의존하고 수동으로 장치별(device-by-device)로 구성하는 기존 네트워킹 방식은 클라우드 네이티브 애플리케이션(cloud-native applications), 마이크로서비스(microservices), 그리고 지속적인 배포 파이프라인(continuous deployment pipelines)의 동적인 요구사항을 따라잡는 데 종종 어려움을 겪습니다. 이러한 배경 속에서 소프트웨어 정의 네트워킹(Software-Defined Networking, SDN)이 혁신적인 패러다임(transformative paradigm)으로 등장했습니다. SDN은 네트워크의 제어부(control plane)와 데이터부(data plane)를 분리하여, 네트워크 인프라(network infrastructure)를 다른 소프트웨어 구성 요소(software component)처럼 프로그래밍하고 관리할 수 있도록 하는 근본적인 변화를 의미합니다. 개발자와 데브옵스(DevOps) 엔지니어에게 SDN은 단순히 네트워킹 개념을 넘어섭니다. 이는 네트워크 인텔리전스(network intelligence)를 애플리케이션 배포 워크플로우(application deployment workflows)에 직접 통합하고, 복잡한 구성을 자동화하며, 진정으로 유연하고 반응적인 인프라(elastic and responsive infrastructure)를 구축할 기회를 제공합니다. 이 글에서는 SDN을 명확히 이해할 수 있도록 핵심 개념(core concepts), 실제 구현(practical implementation) 방식, 그리고 SDN이 개발자에게 전례 없는 네트워크 민첩성(network agility)을 어떻게 제공하여 네트워크 프로비저닝(provisioning) 및 관리(management)를 수동 작업이 아닌 프로그래밍 가능한 작업(programmatic exercise)으로 만드는지 안내할 것입니다.

Photo by Mehdi Mirzaie on Unsplash

SDN 이해하기: 프로그래밍 가능한 네트워크를 향한 첫걸음

기존 네트워킹(conventional networking) 방식에서 벗어난 SDN 여정을 시작하는 것이 다소 어렵게 느껴질 수 있지만, SDN의 핵심은 추상화(abstraction)와 프로그래밍 가능성(programmability)을 통해 네트워크 관리(network management)를 간소화하는 것입니다. SDN을 가장 잘 이해하는 방법은 기본 구성 요소(foundational components)를 파악한 다음, 간단한 설정(simple setup)을 직접 해보는 것입니다.

핵심 아이디어는 네트워크 인텔리전스(network intelligence)를 중앙 집중화하는 것입니다. 개별 라우터(router)와 스위치(switch)가 로컬 라우팅 테이블(local routing tables)에 기반하여 독립적인 포워딩 결정(forwarding decisions)을 내리는 대신, SDN 컨트롤러(SDN controller)가 전체 네트워크의 트래픽 흐름(traffic flows)을 지시하며 주도권을 잡습니다.

SDN의 핵심 요소 이해하기:

1. 제어부(Control Plane, SDN Controller):SDN 아키텍처(architecture)의 “두뇌” 역할을 합니다. 네트워크의 전역적인 시야(global view)를 유지하고 모든 포워딩 결정(forwarding decisions)을 내린 다음, 이 결정을 데이터부(data plane) 요소(elements)에 전달하는 중앙 집중식 소프트웨어 애플리케이션(software application)입니다. 컨트롤러(controller)는 애플리케이션(application) 및 오케스트레이터(orchestrator)가 네트워크를 프로그래밍할 수 있도록 API(Application Programming Interface, 종종 RESTful 방식)를 노출합니다.
2. 데이터부(Data Plane, Forwarding Devices):컨트롤러(controller)가 전달하는 규칙(flow tables)에 따라 패킷(packet)을 포워딩하는 네트워크 장치(스위치, 라우터)입니다. 대부분의 경우 포워딩 로직(forwarding logic)에 있어 "단순"하며, 단순히 지시를 실행합니다. OpenFlow는 컨트롤러와 데이터부 장치 간 통신에 사용되는 일반적인 프로토콜(protocol)입니다.
3. 애플리케이션부(Application Plane):이 계층(layer)은 SDN 컨트롤러의 API를 통해 통신하여 네트워크 서비스(network services)를 요청하고, 정책(policies)을 적용하며, 네트워크 인텔리전스(network intelligence)를 수집하는 애플리케이션으로 구성됩니다. 예시로는 로드 밸런서(load balancers), 방화벽(firewalls), 네트워크 모니터링 도구(network monitoring tools)가 있으며, 이들은 모두 컨트롤러와 상호작용하는 소프트웨어(software)로 구현됩니다.

시작하기: 간단한 가상 랩(Virtual Lab) 구축하기

SDN 탐색을 시작하려면 가상화된 환경(virtualized environment)을 설정하는 것이 중요합니다. Mininet은 이를 위한 훌륭한 도구로, 단일 머신(single machine)에서 가상 호스트(virtual hosts), 스위치(switches), 컨트롤러(controllers)로 구성된 네트워크를 생성할 수 있게 해줍니다. 물리적 하드웨어(physical hardware) 없이 SDN 개념을 프로토타이핑(prototyping)하고 테스트(testing)하기에 이상적입니다.

선행 조건:

• Linux 환경 (Ubuntu 권장) 또는 Linux VM (Virtual Machine).
• Linux 명령줄(command line)에 대한 기본적인 이해.

Mininet과 Ryu 컨트롤러(Controller)로 단계별 따라하기:

1. Mininet 설치:

   sudo apt update
   sudo apt install mininet
   

2. Ryu SDN 컨트롤러 설치:Ryu는 파이썬(Python) 기반의 SDN 프레임워크(framework)로, 네트워크 애플리케이션을 쉽게 작성할 수 있도록 합니다.

   sudo apt install python3-pip
   pip3 install ryu
   

3. 첫 번째 간단한 SDN 애플리케이션(Ryu Controller) 만들기: 기존 스위치(traditional switch)가 학습하는 방식과 유사하게 MAC 주소(MAC addresses)를 기반으로 패킷을 포워딩하는 기본적인 “학습 스위치(learning switch)” 애플리케이션을 만들어 봅시다.

   simple_switch_13.py라는 이름의 파일을 생성하세요:

   # simple_switch_13.py
   from ryu.base import app_manager
   from ryu.controller import ofp_event
   from ryu.controller.handler import CONFIG_DISPATCHER, MAIN_DISPATCHER
   from ryu.controller.handler import set_ev_cls
   from ryu.ofproto import ofproto_v1_3
   from ryu.lib.packet import packet, ethernet, ether_types class SimpleSwitch13(app_manager.RyuApp): OFP_VERSIONS = [ofproto_v1_3.OFP_VERSION] def __init__(self, args, kwargs): super(SimpleSwitch13, self).__init__(args, kwargs) self.mac_to_port = {} @set_ev_cls(ofp_event.EventOFPSwitchFeatures, CONFIG_DISPATCHER) def switch_features_handler(self, ev): datapath = ev.msg.datapath ofproto = datapath.ofproto parser = datapath.ofproto_parser # 테이블 미스(table-miss) 플로우 엔트리(flow entry) 설치 # 미스 엔트리(miss entry)에 대한 출력 포트(output port)를 지정합니다. 이 포트는 컨트롤러(CONTROLLER)입니다. # 이는 어떤 기존 플로우(flow)와도 일치하지 않는 패킷이 있을 경우, 컨트롤러로 전송된다는 의미입니다. match = parser.OFPMatch() actions = [parser.OFPActionOutput(ofproto.OFPP_CONTROLLER, ofproto.OFPCML_NO_BUFFER)] self.add_flow(datapath, 0, match, actions) def add_flow(self, datapath, priority, match, actions, buffer_id=None): ofproto = datapath.ofproto parser = datapath.ofproto_parser inst = [parser.OFPInstructionActions(ofproto.OFPIT_APPLY_ACTIONS, actions)] if buffer_id: mod = parser.OFPFlowMod(datapath=datapath, buffer_id=buffer_id, priority=priority, match=match, instructions=inst) else: mod = parser.OFPFlowMod(datapath=datapath, priority=priority, match=match, instructions=inst) datapath.send_msg(mod) @set_ev_cls(ofp_event.EventOFPPacketIn, MAIN_DISPATCHER) def _packet_in_handler(self, ev): # 패킷을 수신했는데 버퍼 ID(buffer ID)가 없으면 무시합니다 (이미 처리됨). if ev.msg.msg_len < ev.msg.total_len: self.logger.debug("packet truncated: only %s of %s bytes", ev.msg.msg_len, ev.msg.total_len) msg = ev.msg datapath = msg.datapath ofproto = datapath.ofproto parser = datapath.ofproto_parser in_port = msg.match['in_port'] pkt = packet.Packet(msg.data) eth = pkt.get_protocols(ethernet.ethernet)[0] if eth.ethertype == ether_types.ETH_TYPE_LLDP: # LLDP 패킷 무시 return dst = eth.dst src = eth.src dpid = datapath.id self.mac_to_port.setdefault(dpid, {}) self.logger.info("packet in %s %s %s %s", dpid, src, dst, in_port) # 나중에 플러딩(FLOODING)을 피하기 위해 MAC 주소를 학습합니다. self.mac_to_port[dpid][src] = in_port if dst in self.mac_to_port[dpid]: out_port = self.mac_to_port[dpid][dst] else: out_port = ofproto.OFPP_FLOOD actions = [parser.OFPActionOutput(out_port)] # 다음번에는 packet_in 이벤트를 피하기 위한 플로우를 설치합니다. if out_port != ofproto.OFPP_FLOOD: match = parser.OFPMatch(in_port=in_port, eth_dst=dst, eth_src=src) # 더 구체적인 매치(match) # 더 넓은 범위의 매치(match)를 가진 이전 플로우(flow)가 존재하는지 확인합니다. # 그렇지 않다면, 이 더 구체적인 플로우를 추가합니다. # 이는 기본적인 예시입니다. 실제 프로덕션 환경에서는 플로우 관리(flow management)가 더 복잡합니다. self.add_flow(datapath, 1, match, actions) # 학습된 플로우(flow)에 대한 우선순위 1 data = None if msg.buffer_id == ofproto.OFP_NO_BUFFER: data = msg.data out = parser.OFPPacketOut(datapath=datapath, buffer_id=msg.buffer_id, in_port=in_port, actions=actions, data=data) datapath.send_msg(out)
   

4. Ryu 컨트롤러 실행: 이렇게 하면 Ryu 컨트롤러가 시작되어 OpenFlow 스위치(switches)의 연결을 기다립니다.

   ryu-manager simple_switch_13.py
   

5. OpenFlow 지원 토폴로지(topology)로 Mininet 실행: 새 터미널을 열고 Mininet을 실행하여 Ryu 컨트롤러에 연결하도록 지시하세요. 이 명령은 두 개의 호스트(h1, h2)와 하나의 Open vSwitch(s1)를 가진 선형 토폴로지(linear topology)를 생성하며, 127.0.0.1:6653에 있는 원격 Ryu 컨트롤러에 연결합니다.

   sudo mn --controller=remote,ip=127.0.0.1,port=6653 --switch ovs,protocols=OpenFlow13 --topo linear,2
   

6. 네트워크 테스트: Mininet CLI(mininet>) 내부에서 한 호스트에서 다른 호스트로 핑(ping)을 시도해보세요:

   mininet> h1 ping h2
   

   성공적인 핑(ping)을 확인할 수 있을 것입니다. Ryu 컨트롤러의 출력을 살펴보면, MAC 주소를 학습하고 트래픽을 포워딩하면서 packet in 이벤트(event)를 보고하고 플로우 규칙(flow rules)을 설치하는 것을 볼 수 있습니다. 이는 컨트롤러가 스위치를 동적으로 프로그래밍하는 방식을 보여줍니다.

이 간단한 실습은 SDN 컨트롤러가 파이썬(Python)으로 작성된 애플리케이션(application)을 사용하여 데이터부(data plane, 가상 Open vSwitch)와 상호작용하며 트래픽 흐름(traffic flows)을 프로그래밍 방식으로 관리하는 방법을 보여줍니다. 이는 코드를 통해 네트워크 민첩성(network agility)을 구현하는 기본적인 단계입니다.

당신의 SDN 툴킷(Toolkit): 필수 플랫폼과 리소스(Resources)

워크플로우(workflows)에 SDN을 통합하고자 하는 개발자에게는 올바른 도구와 플랫폼을 갖추는 것이 가장 중요합니다. 이러한 도구들은 네트워크 인프라와 애플리케이션 중심 자동화(application-centric automation) 사이의 격차를 해소하여 진정으로 프로그래밍 가능한 환경을 조성합니다.

핵심 SDN 컨트롤러(Controllers) 및 프레임워크(Frameworks):

1. OpenDaylight (ODL):

   • 설명:강력한 오픈소스(open-source) 자바(Java) 기반 SDN 컨트롤러 프레임워크입니다. ODL은 기업 및 서비스 제공업체 환경(enterprise and service provider environments)을 위해 설계되었으며, 모듈형 아키텍처(modular architecture), 노스바운드 REST API(northbound REST APIs), 그리고 다양한 프로토콜(OpenFlow, NETCONF, OVSDB)을 위한 사우스바운드 플러그인(southbound plugins)을 포함한 풍부한 기능(features)을 제공합니다.
   • 개발자 초점:복잡한 네트워크 애플리케이션, 오케스트레이터, 서비스(services)를 구축하는 개발자에게 이상적입니다. API 기반 접근 방식은 다른 관리 시스템(management systems)과의 통합에 적합합니다.
   • 설치/사용법:사전에 빌드된 배포판(distributions)을 다운로드하거나 소스(source)에서 빌드할 수 있습니다. 주로 curl 또는 파이썬(Python)의 requests 라이브러리(library)와 같은 도구를 사용하여 REST API를 통해 상호작용합니다.

     # 예시: ODL 시작 (다운로드 및 압축 해제 가정)
     ./bin/karaf
     # Karaf 콘솔(console) 내부: feature:install odl-restconf odl-l2switch-switch
     # 그다음, 파이썬을 사용하여 상호작용합니다 (간소화된 의사 코드).
     # import requests
     # url = "http://localhost:8181/restconf/config/opendaylight-inventory:nodes/node/openflow:1/table/0"
     # headers = {'Content-Type': 'application/json', 'Authorization': 'Basic YWRtaW46YWRtaW4='}
     # data = { ... 플로우 규칙(flow rule) JSON ... }
     # response = requests.put(url, headers=headers, json=data, auth=('admin', 'admin'))
     

2. ONOS (Open Network Operating System):

   • 설명:자바(Java)로 작성되었으며 서비스 제공업체 네트워크(service provider networks)에서 고성능(high-performance) 및 고가용성(high-availability)을 위해 구축된 또 다른 강력한 오픈소스 SDN 컨트롤러입니다. ONOS는 프로덕션 네트워크(production networks) 제어를 강조하며, 캐리어급(carrier-grade) 기능을 제공합니다.
   • 개발자 초점:실시간 네트워크 상태(real-time network state), 내결함성(fault tolerance), 대규모 배포(large-scale deployments)가 필요한 애플리케이션에 적합합니다. 의도 기반 네트워킹(intent-based networking) 기능은 개발자가 낮은 수준의 구성(low-level configurations) 대신 원하는 네트워크 결과(desired network outcomes)를 표현할 수 있도록 합니다.
   • 설치/사용법:ODL과 유사하게 ONOS는 종종 클러스터(cluster)로 배포됩니다. 상호작용은 일반적으로 REST API 또는 명령줄 인터페이스(command-line interface, CLI)를 통해 이루어집니다.

3. Ryu:

   • 설명:앞서 시연했듯이, Ryu는 OpenFlow를 포함한 다양한 프로토콜을 지원하는 가벼운 파이썬(Python) 기반 SDN 프레임워크입니다. 확장성이 뛰어나며(highly extensible), 파이썬에 익숙한 개발자에게는 학습 곡선(learning curve)이 완만합니다.
   • 개발자 초점:빠른 프로토타이핑(rapid prototyping), 학술 연구, 그리고 파이썬 생태계(ecosystem)가 유리한 맞춤형 네트워크 애플리케이션 개발에 탁월합니다.
   • 설치/사용법:pip install ryu를 실행한 후 ryu-manager your_app.py를 실행합니다.

4. Floodlight:

   • 설명:OpenFlow를 특별히 대상으로 하는 오픈소스 자바(Java) 기반 SDN 컨트롤러입니다. 단순성과 우수한 성능으로 잘 알려져 있습니다.
   • 개발자 초점:ODL의 모든 복잡성 없이 OpenFlow 중심의 SDN을 깊이 탐구하려는 자바 개발자에게 좋은 시작점입니다.

네트워크 에뮬레이션(Emulation) 및 가상화(Virtualization):

• Mininet:(앞서 설명했듯이) 가상 네트워크(virtual networks)를 신속하게 생성하는 데 필수적입니다.
• GNS3/EVE-NG:다양한 벤더(vendor)의 가상화된 네트워크 장치(virtualized network devices)를 SDN 구성 요소와 함께 통합할 수 있게 해주는 더욱 진보된 네트워크 에뮬레이터(network emulators)로, 더 현실적인 랩(lab) 환경을 제공합니다.
• Open vSwitch (OVS):Apache 2.0 라이선스(license)를 따르는 프로덕션급(production-grade) 다계층(multilayer) 가상 스위치(virtual switch)입니다. 가상화 환경(virtualized environments) 및 클라우드 플랫폼(cloud platforms, OpenStack 등)에서 SDN 컨트롤러가 관리하는 데이터부(data plane) 요소로 흔히 사용됩니다.

자동화(Automation) 및 오케스트레이션(Orchestration) 도구:

• Ansible:물리 및 가상 네트워크 장치(physical and virtual network devices)를 프로비저닝(provisioning)하고 구성하는 데 사용됩니다. Ansible 플레이북(playbooks)은 SDN 컨트롤러 API와 상호작용하여 네트워크 정책(network policy) 배포를 자동화할 수 있습니다.
• Terraform:클라우드 리소스(cloud resources) 및 점차적으로 네트워크 인프라(network infrastructure)를 프로비저닝하고 관리하기 위한 인프라 자동화(Infrastructure as Code, IaC) 도구입니다. Terraform 프로바이더(providers)는 SDN 컨트롤러와 상호작용하여 네트워크 토폴로지(network topology) 및 서비스(services)를 정의할 수 있습니다.
• Python SDK/라이브러리(Libraries):대부분의 SDN 컨트롤러는 파이썬(Python) 클라이언트 라이브러리(client libraries)를 제공하거나, REST API(Application Programming Interface)와의 프로그래밍 방식 상호작용을 위해 표준 HTTP 클라이언트 라이브러리(requests)와 쉽게 통합됩니다.

코드 편집기(Code Editors) 및 확장 프로그램(Extensions):

• VS Code (Visual Studio Code):파이썬(Python), 자바(Java), REST 클라이언트(Client), Git 통합(integration)을 위한 확장 프로그램(extensions)을 통해 VS Code는 SDN 애플리케이션을 작성하고, 컨트롤러 API와 상호작용하며, 코드로 네트워크 정책(network policy as code)을 관리하기 위한 강력한 환경이 됩니다.
  • Python:Ryu, 컨트롤러 API 스크립팅(scripting)에 필수적입니다.
  • REST Client:편집기(editor) 내에서 SDN 컨트롤러 REST API를 직접 테스트하는 데 사용됩니다.
  • Git:SDN 애플리케이션 및 네트워크 정책의 버전 관리(version controlling)에 사용됩니다.

이러한 도구들을 사용하면 개발자들은 수동적인 CLI(Command Line Interface) 구성(configurations)을 넘어설 수 있으며, 현대 데브옵스(DevOps) 원칙과 완벽하게 일치하는 코드 기반의 네트워크 관리(network management) 접근 방식을 수용할 수 있습니다.

SDN 실제 적용: 실용적인 애플리케이션과 코드 패턴(Code Patterns)

SDN의 진정한 힘은 복잡한 네트워크 문제(network challenges)를 해결하고 운영 워크플로우(operational workflows)를 간소화하는 데 적용될 때 발휘됩니다. 네트워크를 프로그래밍 가능한 리소스(programmable resource)로 취급함으로써, 개발자들은 기존의 정적인 인프라(static infrastructure)로는 불가능했던 동적이고 지능적인 솔루션(solutions)을 구현할 수 있습니다.

Photo by note thanun on Unsplash

1. 동적 트래픽 엔지니어링(Traffic Engineering) 및 로드 밸런싱(Load Balancing)

문제:실시간 부하(real-time load), 애플리케이션 요구사항, 또는 네트워크 조건에 따라 여러 경로(paths)나 서버(servers)에 네트워크 트래픽(network traffic)을 효율적으로 분산하는 것. 기존 방식은 종종 적응 속도가 느린 정적 라우팅 프로토콜(static routing protocols)이나 하드웨어 로드 밸런서(hardware load balancers)에 의존합니다.

SDN 솔루션:SDN 컨트롤러는 네트워크 링크 활용도(network link utilization)와 서버 부하(server loads)를 모니터링할 수 있습니다. 전역적인 시야(global view)를 사용하여 스위치(switches)의 플로우 규칙(flow rules)을 동적으로 수정하여 트래픽을 유도할 수 있으며, 효과적으로 소프트웨어 정의 로드 밸런서(software-defined load balancer) 또는 트래픽 엔지니어(traffic engineer) 역할을 합니다.

실용적 사용 사례:데이터 센터(data center)에서 특정 링크(link)나 서버 랙(server rack)이 과부하될 경우, SDN 컨트롤러는 새로운 연결(connections)이나 심지어 활성 세션(active sessions, 플로우가 충분히 세분화되어 있다면)을 덜 혼잡한 경로로 자동으로 전환할 수 있습니다.

코드 패턴(Code Pattern) (REST API를 활용한 개념적인 파이썬(Python) 코드):

import requests
import json
import time SDN_CONTROLLER_IP = "192.168.1.100" # SDN 컨트롤러의 IP
SDN_CONTROLLER_PORT = 8181
USERNAME = "admin"
PASSWORD = "admin" def get_link_utilization(link_id): """ SDN 컨트롤러의 모니터링 API에서 링크 활용도를 가져오는 것을 시뮬레이션합니다. 실제 시나리오에서는 실제 API 엔드포인트(endpoint)에 쿼리(query)하는 것을 포함합니다. """ # Placeholder for actual API call # response = requests.get(f"http://{SDN_CONTROLLER_IP}:{SDN_CONTROLLER_PORT}/api/link_stats/{link_id}", auth=(USERNAME, PASSWORD)) # return response.json().get('utilization', 0.5) # 다양한 링크 부하 시뮬레이션 if link_id == "link-a": return 0.8 if time.time() % 20 < 10 else 0.2 # 10초간 높음, 그 후 낮음 elif link_id == "link-b": return 0.3 if time.time() % 20 < 10 else 0.9 # 10초간 낮음, 그 후 높음 return 0.5 def update_flow_rule(switch_id, flow_id, new_out_port, priority=100): """ 특정 스위치에 플로우 규칙(flow rule)을 업데이트하여 트래픽을 새로운 출력 포트(output port)로 보냅니다. 이것은 OpenDaylight와 같이 REST를 통해 플로우 규칙이 전달되는 컨트롤러를 가정합니다. """ url = f"http://{SDN_CONTROLLER_IP}:{SDN_CONTROLLER_PORT}/restconf/config/opendaylight-inventory:nodes/node/{switch_id}/table/0/flow/{flow_id}" headers = {'Content-Type': 'application/json'} auth = (USERNAME, PASSWORD) # 예시 플로우 규칙 구조 (컨트롤러/OpenFlow 버전에 따라 크게 다름) flow_data = { "flow": [ { "id": flow_id, "table_id": 0, "priority": priority, "match": { "ipv4-src": "10.0.0.1/32", # 예시: 특정 소스(source)에서의 트래픽 "eth-type": 2048 # IPv4 }, "instructions": { "instruction": [ { "order": 0, "apply-actions": { "action": [ { "order": 0, "output-action": { "output-node-connector": str(new_out_port) } } ] } } ] } } ] } try: response = requests.put(url, headers=headers, data=json.dumps(flow_data), auth=auth) response.raise_for_status() # HTTP 오류(error)에 대한 예외(exception) 발생 print(f"Successfully updated flow {flow_id} on {switch_id} to output port {new_out_port}") except requests.exceptions.RequestException as e: print(f"Error updating flow {flow_id} on {switch_id}: {e}") def main_traffic_engineer(): print("Starting SDN Traffic Engineer...") while True: link_a_util = get_link_utilization("link-a") link_b_util = get_link_utilization("link-b") print(f"Link A Utilization: {link_a_util:.2f}, Link B Utilization: {link_b_util:.2f}") if link_a_util > 0.7 and link_b_util < 0.7: print("Link A congested, diverting traffic to Link B...") # 'openflow:1'이 스위치 ID이고 'flow-101'이 특정 트래픽에 대한 플로우라고 가정합니다. # 그리고 '2'와 '3'은 각각 링크 A와 B에 대한 예시 출력 포트입니다. update_flow_rule("openflow:1", "flow-101", 3) # 플로우 101에 대한 트래픽을 포트 3 (링크 B)로 리디렉션(redirect)합니다. elif link_b_util > 0.7 and link_a_util < 0.7: print("Link B congested, diverting traffic to Link A...") update_flow_rule("openflow:1", "flow-101", 2) # 플로우 101에 대한 트래픽을 포트 2 (링크 A)로 리디렉션합니다. else: print("네트워크 링크가 균형을 이루거나 명확한 혼잡이 없습니다.") time.sleep(5) # 5초마다 확인 if __name__ == "__main__": main_traffic_engineer()

이 개념적인 코드는 SDN 애플리케이션(application)을 나타내는 파이썬(Python) 스크립트(script)가 어떻게 네트워크 상태(network state)를 모니터링하고 컨트롤러의 API(Application Programming Interface)를 통해 플로우 규칙(flow rules)을 동적으로 조정하여 트래픽(traffic) 균형을 맞출 수 있는지를 보여줍니다.

2. 자동화된 네트워크 세분화(Segmentation) 및 보안 정책(Security Policy) 적용

문제:네트워크 세분화를 위한 VLAN(Virtual Local Area Network), ACL(Access Control List), 방화벽 규칙(firewall rules)의 수동 구성(Manual configuration)은 오류 발생 가능성이 높고(prone to errors), 느리며, 동적인 환경(예: 마이크로서비스)에서 확장성이 좋지 않습니다.

SDN 솔루션:SDN은 물리적 위치(physical location)와 관계없이 개별 워크로드(workloads) 또는 특정 애플리케이션 플로우(application flows)에 세분화된 보안 정책(granular security policies)을 적용할 수 있는 "마이크로 세분화(micro-segmentation)"를 가능하게 합니다. 정책은 컨트롤러(controller)에 중앙 집중식으로 정의되고 데이터부(data plane)로 자동으로 전달됩니다.

실용적 사용 사례:물리적 방화벽(physical firewalls)이나 스위치(switches)를 재구성할 필요 없이 개발, 스테이징(staging), 프로덕션 환경(production environments)을 자동으로 격리하거나, 마이크로서비스(microservices) 간에 특정 방화벽 규칙을 적용하는 것. 새로운 VM(Virtual Machine) 또는 컨테이너(container)가 시작되면, 오케스트레이션 시스템(orchestration system)이 SDN 컨트롤러에 해당 보안 그룹(security group)을 알리고, 컨트롤러는 필요한 네트워크 정책을 프로비저닝(provisions)합니다.

3. 네트워크 기능 가상화(Network Function Virtualization, NFV) 오케스트레이션(Orchestration)

문제:기존의 하드웨어 기반 네트워크 기능(hardware-based network functions, 방화벽, NAT, 로드 밸런서)을 배포, 연결(chaining), 관리하는 것은 복잡하고 리소스 집약적이며(resource-intensive), 유연성(elasticity)이 부족합니다.

SDN 솔루션:SDN은 NFV와 결합하여 가상화된 네트워크 기능(Virtual Network Functions, VNFs)을 일반 서버(commodity servers)에 소프트웨어(software) 형태로 배포할 수 있게 합니다. SDN 컨트롤러는 이러한 VNF를 동적으로 "연결(chain)"하여 서비스 경로(service paths)를 생성할 수 있습니다 (예: 트래픽 -> 방화벽 -> IDS -> 로드 밸런서 -> 애플리케이션).

실용적 사용 사례:새로운 테넌트(tenant)를 위한 온디맨드(on-demand) 가상 방화벽(virtual firewall)을 즉시 가동하거나, 트래픽 급증(traffic spikes)에 따라 가상 로드 밸런서(virtual load balancers)를 확장하는 등, 이 모든 것이 SDN API를 통해 프로그래밍 방식으로 오케스트레이션(orchestrated)됩니다.

4. 제로 터치 프로비저닝(Zero-Touch Provisioning) 및 네트워크 애즈 코드(Network-as-Code)

문제:새로운 네트워크 장치(network devices)나 서비스(services)의 수동 구성(Manual configuration)은 시간이 많이 소요되고 오류 발생 가능성이 높으며(error-prone), 신속한 애플리케이션 배포(rapid application deployment)를 저해합니다.

SDN 솔루션:SDN을 사용하면 네트워크 구성(network configuration)을 코드로 정의할 수 있습니다. 새로운 장치가 추가되면 SDN 컨트롤러는 이를 자동으로 감지하고, 올바른 구성과 정책(policies)을 적용하며, 네트워크에 통합합니다. 이는 진정한 "네트워크 애즈 코드(network as code)"와 "제로 터치 프로비저닝(zero-touch provisioning)"을 가능하게 합니다.

실용적 사용 사례:스위치(switches)를 단순히 연결하기만 하면 새로운 지사(branch office) 네트워크를 배포할 수 있으며, 이 스위치들은 중앙 SDN 컨트롤러에 자동으로 연결되어 구성을 다운로드하고 기업 네트워크(corporate network)에 통합됩니다.

모범 사례(Best Practices) 및 일반적인 패턴(Common Patterns):

• API 우선 설계(API-First Design):SDN 컨트롤러 및 네트워크 요소(elements)와는 항상 잘 정의된 API(Application Programming Interface)를 통해 상호작용하세요. 이는 자동화(automation) 및 통합(integration)을 촉진합니다.
• 네트워크 정책 버전 관리(Version Control Network Policies):네트워크 구성(network configuration) 및 SDN 애플리케이션 코드를 다른 소프트웨어(software)와 마찬가지로 취급하세요. Git을 사용하여 버전 관리(version control)를 하면 네트워크 변경 사항에 대한 롤백(rollbacks), 협업(collaboration), 지속적인 통합/배포(continuous integration/delivery, CI/CD)가 가능해집니다.
• 모듈형 SDN 애플리케이션(Modular SDN Applications):복잡한 네트워크 로직(network logic)을 더 작고 테스트 가능한 모듈(modules)로 분리하세요 (예: 모니터링(monitoring)용 모듈, 트래픽 엔지니어링(traffic engineering)용 모듈, 보안(security)용 모듈).
• 지속적인 테스트(Continuous Testing):SDN 애플리케이션 및 네트워크 정책에 대한 자동화된 테스트(automated tests)를 구현하여 예상대로 작동하고 회귀(regressions)를 발생시키지 않도록 보장하세요.
• 의도 기반 네트워킹(Intent-Based Networking, IBN):네트워크가 “무엇을” 하기를 원하는지(의도, intent)를 정의하는 방향으로 나아가고, “어떻게” 해야 하는지(명시적인 낮은 수준의 구성, explicit low-level configurations)를 정의하는 것을 넘어섭니다. SDN 컨트롤러는 이러한 의도(intents)를 특정 플로우 규칙(flow rules)으로 해석하고 변환하도록 진화하고 있습니다.

이러한 패턴을 채택하고 SDN의 프로그래밍 가능성(programmability)을 활용함으로써, 개발자들은 네트워크 변경에 반응하는 것을 넘어 애플리케이션 요구사항(application needs)에 맞춰 네트워크를 주도적으로 구성하고 전례 없는 수준의 자동화(automation)와 민첩성(agility)을 달성할 수 있습니다.

네트워크 아키텍처 탐색: SDN 대 기존 방식

네트워크 개편(network overhaul) 또는 새로운 배포(new deployment)를 고려할 때, 소프트웨어 정의 네트워킹(Software-Defined Networking, SDN)과 기존 네트워크 아키텍처(traditional network architectures) 간의 근본적인 차이를 이해하는 것이 중요합니다. 개발자들에게 이 비교는 기술적인 차이점뿐만 아니라 워크플로우(workflow), 자동화(automation), 그리고 전반적인 개발 민첩성(development agility)에 대한 깊은 의미를 강조합니다.

기존 네트워킹: 하드웨어 중심 모델

기존 네트워크에서는 제어부(control plane, 트래픽을 어떻게 포워딩할지 결정하는 로직)와 데이터부(data plane, 실제 패킷 포워딩)가 개별 네트워크 장치(라우터, 스위치, 방화벽) 내에 긴밀하게 결합되어 있습니다. 각 장치는 주로 독립적으로 작동하며, 자체 로컬 라우팅 테이블(local routing tables), MAC 주소 테이블(MAC address tables), 그리고 접근 제어 목록(Access Control Lists, ACLs)을 기반으로 포워딩 결정(forwarding decisions)을 내립니다.

특성:

• 분산 제어(Distributed Control):각 장치가 자체 포워딩 로직(forwarding logic)을 관리합니다.
• 수동 구성(Manual Configuration):네트워크 변경은 CLI(Command Line Interface)를 통해 개별 장치에 로그인하는 것을 포함하며, 상당한 수동 작업(manual effort)과 깊이 있는 벤더(vendor)별 지식(knowledge)을 요구하고 잠재적인 인적 오류(human error)로 이어질 수 있습니다.
• 벤더 종속(Vendor Lock-in):특정 벤더의 독점 하드웨어(proprietary hardware) 및 운영 체제(operating systems)에 의존합니다.
• 정적 및 경직성(Static & Rigid):변화하는 애플리케이션 요구사항(application requirements)에 적응하는 속도가 느립니다. 확장(Scaling)은 일반적으로 더 많은 특수 하드웨어(specialized hardware)를 구매하는 것을 의미합니다.
• 문제 해결의 복잡성(Troubleshooting Complexity):문제(issues)를 디버깅(Debugging)하려면 종종 네트워크 전반에 걸쳐 개별 장치의 상태(device states)를 검사해야 합니다.

기존 방식이 충분한 경우:

• 소규모, 정적 네트워크(Small, Static Networks):예측 가능한 트래픽 패턴(traffic patterns)과 드문 변경이 있는 네트워크의 경우, SDN 컨트롤러의 오버헤드(overhead)가 불필요할 수 있습니다.
• 제한된 요구사항을 가진 지사(Branch Offices):복잡성과 민첩성(agility)이 주요 고려 사항이 아닌 경우.
• 특수 하드웨어 요구사항(Specialized Hardware Requirements):SDN 통합(integration)이 성숙하지 않거나 비용 효율적이지 않은 특정 레거시(legacy) 또는 고도로 전문화된 기능(highly specialized functions)의 경우.

소프트웨어 정의 네트워킹(Software-Defined Networking): 프로그래밍 가능한 패러다임(Paradigm)

SDN은 제어부(control plane)와 데이터부(data plane)를 근본적으로 분리하여, 네트워크 인텔리전스(network intelligence)를 소프트웨어 기반 컨트롤러(software-based controller)에 중앙 집중화합니다. 이러한 추상화(abstraction)를 통해 네트워크는 서버(servers)나 애플리케이션(applications)처럼 프로그래밍 방식으로(programmatically) 프로그래밍되고 관리될 수 있습니다.

특성:

• 중앙 집중식 제어(Centralized Control):단일 SDN 컨트롤러(또는 클러스터, cluster)가 전체 네트워크의 전역적인 시야(global view)를 가지며, 트래픽 흐름(traffic flow)과 정책 적용(policy enforcement)을 오케스트레이션(orchestrating)합니다.
• 프로그래밍 방식 구성(Programmatic Configuration):네트워크 서비스(network services)와 정책(policies)은 컨트롤러 내의 소프트웨어 로직(software logic)으로 또는 그 API(Application Programming Interface)를 통해 정의됩니다. 이는 자동화(automation), 템플릿화(templating), 버전 관리(version control)를 가능하게 합니다.
• 벤더 중립적(Vendor Agnostic):일반적인 하드웨어(commodity hardware, 예: OpenFlow 지원 스위치) 및 오픈소스(open-source) 컨트롤러 사용을 촉진하여 벤더 종속(vendor lock-in)을 줄입니다.
• 동적 및 민첩성(Dynamic & Agile):소프트웨어 로직(software logic)을 통해 네트워크는 실시간 변경, 트래픽 요구, 보안 위협에 동적으로 반응할 수 있습니다. 네트워크 서비스의 신속한 프로비저닝(provisioning) 및 디프로비저닝(de-provisioning)이 가능해집니다.
• 간소화된 문제 해결(Simplified Troubleshooting):중앙 집중식 가시성(visibility) 및 제어(control)는 모니터링(monitoring) 및 디버깅(debugging)을 더욱 효율적으로 만듭니다.

SDN을 도입해야 할 때:

• 클라우드 데이터 센터(Cloud Data Centers) 및 가상화 환경(Virtualized Environments):VM(Virtual Machines), 컨테이너(containers), 마이크로서비스(microservices)에 대한 네트워크 리소스(network resources)의 신속한 프로비저닝이 중요한 곳.
• 데브옵스(DevOps) 및 CI/CD 파이프라인(CI/CD Pipelines):애플리케이션 배포(application deployments)와 함께 네트워크 변경을 자동화하여 진정한 인프라 자동화(infrastructure-as-code)를 가능하게 합니다.
• 대규모 기업 네트워크(Large-Scale Enterprise Networks):복잡한 네트워크 토폴로지(network topologies)를 관리하고, 마이크로 세분화(micro-segmentation)로 보안 상태(security posture)를 개선하며, 리소스 활용(resource utilization)을 최적화하는 데 사용됩니다.
• 서비스 제공업체(Service Providers):유연한 온디맨드(on-demand) 네트워크 서비스(예: 네트워크 슬라이싱(network slicing), NFV 오케스트레이션(orchestration))를 생성하는 데 사용됩니다.
• 고급 트래픽 관리(Advanced Traffic Management):실시간 조건에 적응하는 정교한 라우팅(routing), 로드 밸런싱(load balancing), 서비스 품질(Quality-of-Service, QoS) 정책을 구현하는 것.
• 강화된 보안(Enhanced Security):보안 정책 적용(security policy enforcement), 위협 탐지(threat detection), 그리고 사건(incidents)에 대한 신속한 대응을 자동화하는 것.

개발자를 위한 실용적인 통찰(Insights):

SDN과 기존 네트워킹 사이의 선택은 조직의 민첩성(agility), 자동화(automation), 비용 효율성(cost efficiency), 확장성(scalability)에 대한 특정 요구사항으로 귀결됩니다. 개발자와 데브옵스(DevOps) 팀에게 SDN은 설득력 있는 이점(advantage)을 제공합니다:

• 더 빠른 개발 주기(Faster Development Cycles):애플리케이션 배포(application deployment)의 병목 현상(bottleneck)이 되는 네트워크 변경 사항을 자동화하고 CI/CD(Continuous Integration/Continuous Delivery)에 통합할 수 있습니다.
• 혁신(Innovation):하드웨어 업그레이드(hardware upgrades)나 수동 재구성(manual reconfigurations)에 의존하지 않고 새로운 네트워크 서비스(network services) 및 토폴로지(topologies)를 실험할 수 있습니다.
• 운영 오버헤드 감소(Reduced Operational Overhead):반복적인 네트워크 작업(network tasks)을 자동화하여 더 전략적인 개발에 시간을 할애할 수 있습니다.
• 일관성(Consistency):네트워크 구성(network configurations)을 코드로 정의하여 환경 전반에 걸쳐 일관된 배포(consistent deployments)를 보장하고 구성 편차(configuration drift)를 줄입니다.

전면적인 SDN 배포는 상당한 노력이 필요할 수 있지만, 특정 도메인(domains) (예: 프라이빗 클라우드(private cloud) 내 가상 네트워킹)에 SDN 원칙을 적용하는 것만으로도 상당한 이점을 얻을 수 있습니다. 항상 "양자택일"의 문제는 아닙니다. SDN이 네트워크의 한 부분을 관리하고 나머지 부분은 기존 방식이 처리하는 하이브리드 접근 방식(hybrid approaches)도 흔합니다. 그러나 진정한 인프라 민첩성(infrastructure agility)과 애플리케이션 개발(application development)과의 긴밀한 통합(tight integration)을 목표로 하는 조직에게 SDN은 명확한 발전 방향을 제시합니다.

소프트웨어 정의 미래를 향하여: 개발자의 비전(Vision)

소프트웨어 정의 네트워킹(Software-Defined Networking, SDN)은 단순한 기술 발전(technological advancement)을 넘어섭니다. 이는 개발자가 네트워크 인프라(network infrastructure)와 상호작용하고 활용하는 방식을 근본적으로 변화시키는 패러다임 전환(paradigm shift)을 의미합니다. 네트워크가 특정 팀에 의해 고립되어 관리되는 정적이고 불투명한 블랙박스(black box)였던 시대는 지났습니다. SDN을 통해 네트워크는 동적이고 프로그래밍 가능한 리소스(programmable resource), 애플리케이션 배포 파이프라인(application deployment pipeline)의 필수 구성 요소, 그리고 혁신적인 솔루션(solutions)을 위한 캔버스(canvas)가 됩니다.

개발자를 위한 핵심 가치 제안(value proposition)은 명확합니다: 전례 없는 민첩성(agility)과 제어(control)입니다. 복잡한 기반 하드웨어(underlying hardware)를 추상화하고 강력하며 접근 가능한 API(Application Programming Interface)를 노출함으로써, SDN은 네트워크 구성(network configuration)을 코드로 취급할 수 있도록 힘을 실어줍니다. 이는 프로비저닝(provisioning)을 자동화하고, 트래픽 흐름(traffic flows)을 동적으로 조정하며, 세분화된 보안 정책(granular security policies)을 적용하고, 애플리케이션과 동일한 속도와 유연성(flexibility)으로 새로운 네트워크 서비스(network services)를 배포할 수 있는 능력을 제공합니다. 이러한 변화는 현대 데브옵스(DevOps) 원칙과 완벽하게 일치하며, 네트워크 운영(network operations)을 지속적인 통합(continuous integration) 및 지속적인 전달(continuous delivery, CI/CD) 워크플로우(workflows)에 원활하게 통합합니다.

앞으로 SDN의 발전은 새로운 기술(emerging technologies)과의 더욱 깊은 통합을 약속합니다. 예를 들어, 의도 기반 네트워킹(Intent-Based Networking, IBN)은 개발자가 고수준의 비즈니스 목표(“의도”, intent)를 표현하고, 네트워크가 이를 구체적인 구성(concrete configurations)으로 번역하도록 함으로써 SDN 위에 구축됩니다. 더 나아가, SDN과 인공지능(Artificial Intelligence, AI) 및 머신러닝(Machine Learning, ML)의 융합은 자율 최적화(self-optimizing) 및 자가 치유 네트워크(self-healing networks)로 이어져 네트워크 자율성(network autonomy)의 한계를 확장할 것입니다. 개발자에게 이는 수동 개입(manual interventions) 감소, 더 안정적인 인프라(reliable infrastructure), 그리고 지능형 애플리케이션(intelligent applications) 구축에 대한 더욱 큰 집중을 의미합니다.

SDN으로의 여정은 미래 지향적인 인프라(future-proof infrastructure)에 대한 투자입니다. 이는 기존 개발 관행과 네트워킹 기본 지식을 융합하는 새로운 기술(skillset)을 요구하지만, 그 보상(payoff)은 엄청납니다. SDN을 수용함으로써 개발자들은 네트워크 제약 사항(network constraints)을 회피하는 작업을 멈추고, 애플리케이션 성능(application performance), 보안(security), 확장성(scalability)을 진정으로 극대화하는 네트워크를 코딩하기 시작할 수 있습니다. 네트워킹의 미래는 소프트웨어 정의(software-defined)이며, 이는 여러분과 같은 개발자들에 의해 구축되고, 테스트되며, 배포되고 있습니다.

SDN 탐색: 자주 묻는 질문(FAQs) 및 핵심 용어 정의

자주 묻는 질문 (FAQs):

1. SDN이 네트워크 엔지니어(network engineers)를 대체할까요? 전혀 그렇지 않습니다. SDN은 네트워크 엔지니어링(network engineering)의 본질을 변화시킵니다. 네트워크 엔지니어는 개별 장치를 수동으로 구성하는 대신, SDN 컨트롤러와 그 애플리케이션을 설계하고, 프로그래밍하며, 관리하는 방향으로 전환될 것입니다. 그들은 강력한 스크립팅(scripting), 자동화(automation), 소프트웨어 개발(software development) 기술을 필요로 하며, 효과적으로 프로그래밍 가능한 네트워크 인프라를 구축하고 유지보수하는 “넷데브옵스(NetDevOps)” 엔지니어(engineers)가 될 것입니다.

2. SDN과 가장 관련이 깊은 프로그래밍 언어(programming languages)는 무엇인가요? 파이썬(Python)은 사용 용이성(ease of use), 광범위한 라이브러리(libraries), 그리고 Ryu 및 Mininet과 같은 프레임워크(frameworks) 덕분에 단연 가장 인기 있는 언어입니다. 자바(Java) 또한 매우 중요하며, 특히 자바로 구축된 OpenDaylight 및 ONOS와 같은 엔터프라이즈급(enterprise-grade) 컨트롤러에 해당합니다. 구성(configuration) 및 상호작용을 위한 REST API, YAML(YAML Ain’t Markup Language), JSON(JavaScript Object Notation)에 대한 지식도 중요합니다.

3. SDN의 주요 보안 영향(security implications) 및 이점(benefits)은 무엇인가요? SDN은 중앙 집중식 제어점(centralized control point)을 도입하며, 이는 제대로 보안되지 않을 경우 단일 장애점(single point of failure) 또는 공격 지점(attack)이 될 수 있습니다. 하지만 SDN은 또한 상당한 보안 이점을 제공합니다. 마이크로 세분화(micro-segmentation)를 가능하게 하여 개별 워크로드(workloads)에 대한 세분화된 보안 정책(granular security policies)을 허용하고 위협(threats)을 더 효과적으로 격리합니다. 또한 전체 네트워크에 걸쳐 자동화된 위협 탐지(automated threat detection)와 신속한 정책 기반 대응(policy-based response)을 용이하게 합니다.

4. SDN은 주로 대규모 데이터 센터(large data centers)를 위한 것인가요, 아니면 소규모 기업(small businesses)도 이점을 얻을 수 있나요? SDN은 규모와 복잡성 때문에 대규모 데이터 센터(data centers)와 클라우드 환경(cloud environments)에 막대한 이점을 제공하지만, 소규모 기업(businesses)도 특히 가상화된 SDN 솔루션(virtualized SDN solutions)이나 SDN 원칙을 활용하는 클라우드 기반 네트워킹 서비스(cloud-based networking services)를 통해 이점을 얻을 수 있습니다. 간소화된 관리(simplified management), 자동화(automation), 향상된 민첩성(agility)과 같은 이점은 규모에 관계없이 중요합니다. 핵심은 특정 조직 규모와 기술 요구사항에 적합한 SDN 솔루션을 선택하는 것입니다.

5. SDN 구현에 대한 일반적인 비용 오버헤드(cost overhead)는 얼마인가요? 비용은 상당히 다양합니다. 오픈소스(open-source) SDN 컨트롤러(controllers)와 일반적인 하드웨어(commodity hardware)가 독점 솔루션(proprietary solutions)에 비해 자본 지출(Capital Expenditure, CapEx)을 줄일 수 있지만, 인력 교육, SDN 애플리케이션 개발, 그리고 기존 IT 생태계(IT ecosystems)에 통합하는 것과 관련된 운영 비용(Operating Expense, OpEx)이 발생합니다. 초기 투자(Initial investment)는 높을 수 있지만, 장기적인 절감 효과(long-term savings)는 종종 자동화(automation), 수동 노동 감소(reduced manual labor), 그리고 향상된 민첩성(increased agility)에서 비롯됩니다.

필수 기술 용어 정의:

1. 제어부(Control Plane):데이터 패킷(data packets)이 어떻게 포워딩(forwarded)되어야 하는지를 결정하는 네트워크의 논리적 구성 요소(logical component)입니다. SDN에서는 이 인텔리전스(intelligence)가 데이터부(data plane)와 분리된 SDN 컨트롤러(SDN controller)에 중앙 집중화됩니다.
2. 데이터부(Data Plane):제어부(control plane)에서 제공하는 규칙에 따라 데이터 패킷의 실제 포워딩을 담당하는 네트워크 구성 요소입니다. 일반적으로 네트워크 스위치(switches)와 라우터(routers)로 구성됩니다.
3. SDN 컨트롤러(SDN Controller):SDN 아키텍처(architecture)의 “두뇌” 역할을 하는 중앙 집중식 소프트웨어 애플리케이션(software application)입니다. 네트워크의 전역적인 시야(global view)를 유지하고, 최적의 경로를 계산하며, 포워딩 결정(forwarding decisions)을 내리고, 사우스바운드 API(southbound APIs, OpenFlow 등)를 통해 규칙을 데이터부 장치(data plane devices)로 전달합니다.
4. OpenFlow:SDN 컨트롤러(SDN controller)가 호환되는 네트워크 스위치(network switches, 데이터부 장치)의 포워딩 테이블(forwarding tables)을 직접 프로그래밍할 수 있도록 하는 기초적인 통신 프로토콜(communication protocol)입니다. 컨트롤러가 스위치와 통신하는 표준 방식(standard way)을 정의합니다.
5. 네트워크 기능 가상화(Network Function Virtualization, NFV):전체 클래스의 네트워크 노드 기능(network node functions, 예: 방화벽, 로드 밸런서, NAT)을 독점 하드웨어(proprietary hardware)가 아닌 표준 서버(standard servers)에서 실행될 수 있는 소프트웨어 구성 요소(Virtual Network Functions, VNFs)로 가상화하는 개념입니다. SDN은 종종 NFV를 보완하여 이러한 VNF를 연결하고 관리하기 위한 프로그래밍 가능한 인프라(programmable infrastructure)를 제공합니다.

Published on November 8, 2025