소프트웨어 정의 네트워킹(SDN): 역사, 아키텍처 및 활용 사례

인포매텍 디지털 » Recursos » 소프트웨어 정의 네트워킹(SDN): 역사, 아키텍처 및 활용 사례

소프트웨어 정의 네트워킹(SDN)은 통신 인프라 의 설계, 구축 및 관리 방식을 완전히 바꿔 놓았습니다 . 물리적 장비와 수동 구성에 기반한 경직된 프레임워크였던 것이 이제는 마치 코드로 관리하듯이 훨씬 빠른 속도, 유연성, 그리고 네트워크 곳곳에서 일어나는 일에 대한 가시성을 확보하며 관리될 수 있게 되었습니다.

이 새로운 접근 방식은 갑자기 등장한 것이 아닙니다. 90년대의 액티브 네트워크부터 OpenFlow 표준화, 그리고 컨트롤러, API, 애플리케이션으로 구성된 완벽한 생태계 구축에 이르기까지 수십 년간의 연구와 여러 기술적 이정표 의 결과물입니다 . 이제 SDN이 어떻게 여기까지 왔는지, 어떤 문제를 해결하는지, 내부적으로 어떻게 작동하는지, 그리고 오늘날 어떤 실제 시나리오에서 사용되고 있는지 단계별로 살펴보겠습니다.

소프트웨어 정의 네트워크(SDN)의 기원과 역사

SDN의 역사는 약 20년 전, 상용 인터넷이 막 태동하던 시기에 시작됩니다 . 글로벌 네트워크의 성공은 통신 인프라가 훨씬 더 쉽게 수정되고 진화할 수 있어야 한다는 점을 분명히 보여주었습니다. 그 이후로 오늘날 우리가 SDN이라고 부르는 개념의 토대를 마련한 세 가지 주요 단계를 구분할 수 있습니다.

첫 번째 단계는 액티브 네트워크 시대(대략 1995년~2000년) 에 해당합니다 . 이 시기의 아이디어는 PC를 프로그래밍하는 방식과 유사하게, 각 통신 노드에 프로그래밍 기능을 적용하여 네트워크를 프로그래밍에 개방하는 것이었습니다. 이를 위해 네트워크 장치에 API를 정의하여 컴퓨팅 성능, 저장 공간, 패킷 큐, 처리 기능 등의 리소스를 노출시키고, 특정 트래픽 흐름에 맞춤형 동작을 적용하는 코드를 로드할 수 있도록 했습니다.

이러한 접근 방식은 인터넷이 확장되고 기능을 유지하는 유일한 방법은 네트워크를 최대한 단순하게 유지하는 것이라고 주장하는 사람들의 견해와 충돌했습니다. 그럼에도 불구하고, 적극적인 네트워킹 프로그램은 중요한 발전을 촉진했습니다. 즉, 컴퓨팅 비용 절감, 프로그래밍 언어 개선, 가상 머신 의 등장 , 그리고 무엇보다 네트워크를 단순히 폐쇄된 장치들의 집합체가 아니라 프로그래밍 가능한 플랫폼으로 취급할 수 있다는 아이디어가 실현되었습니다.

그 시대의 중요한 촉매제 역할을 한 것은 DARPA와 같은 기관의 지원이었는데, DARPA는 90년대 중반부터 2000년대 초까지 활발하게 진행된 액티브 네트워크 프로그램(Active Networks Program)을 시작했습니다 . 액티브 네트워크는 대규모 배포에는 이르지 못했지만, 네트워크 내 프로그래밍 가능한 기능, 리소스 가상화, 다양한 장치(방화벽, IDS, NAT 등)에 대한 통합된 시각 등 훗날 SDN의 기반이 될 개념들을 심었습니다.

2000년대가 시작되고 트래픽이 폭발적으로 증가하면서 제어 평면과 데이터 평면의 분리에 초점을 맞춘 두 번째 단계(2001-2007)가 시작되었습니다 . 기존 라우터와 스위치는 제어 로직(경로 선택, 라우팅 프로토콜)과 데이터 평면(실제 패킷 포워딩)을 동일한 장치에 통합하여 오류 디버깅, 트래픽 엔지니어링 조정 또는 새로운 서비스 도입을 매우 어렵게 만들었습니다.

이러한 상황에 대처하기 위해 통신 사업자들은 특수 하드웨어에서 패킷 포워딩을 구현하기 시작했고 , 제어는 비교적 분리된 상태로 유지했습니다. 동시에 VPN과 같은 고급 기능을 통해 점점 더 크고 복잡해지는 네트워크를 관리하는 방법을 모색했습니다. 이러한 과정에서 두 가지 혁신 방향이 나타났습니다. 하나는 ForCES(IETF) 또는 Linux 기반 Netlink와 같이 제어와 포워딩 간의 개방형 인터페이스를 구축하는 것이었고, 다른 하나는 RCP, SoftRouter 또는 PCE 프로토콜과 같이 전체적인 관점에서 라우팅 결정을 내릴 수 있도록 중앙 집중식 논리 제어를 사용하는 아키텍처였습니다.

세 번째 단계는 프로젝트 4D와 그 후속 프로젝트인 Ethane을 통해 도래했으며 , 이는 데이터(규칙에 따른 패킷 처리), 검색(토폴로지 및 트래픽 정보 수집), 배포(처리 규칙 설치), 결정(전역 정책을 구체적인 규칙으로 변환)의 네 가지 명확하게 정의된 영역을 갖춘 중앙 논리 컨트롤러라는 아이디어를 구체화했습니다. 스탠포드 대학교와 같은 실제 환경에 배포된 Ethane은 오늘날 우리가 OpenFlow 라고 부르는 기술의 기반이 되는 매우 단순한 스위치 설계를 제공했습니다.

한편, 실험 생태계 또한 발전하고 있었습니다. PlanetLab과 Emulab 같은 인프라, GENI 및 유럽의 FIRE 프로그램과 같은 프로젝트, 그리고 스탠포드의 Clean Slate 프로그램은 대안적인 네트워크 아키텍처에 대한 대규모 테스트를 촉진했습니다. 이러한 환경에서 OpenFlow는 표준 API를 사용하여 스위치의 포워딩 기능을 외부 컨트롤러에 노출하는 실용적인 방법으로 등장했습니다.

업계의 중요한 이정표는 아바야가 2014년에 선보인 시연 이었는데 , 이는 최단 경로 브리징(Shortest Path Bridging)과 오픈스택(OpenStack)을 결합하여 최소한의 수동 설정만으로 소프트웨어 정의 네트워크를 구축하는 것을 보여주었습니다. 그리고 점차 간단한 펌웨어 업데이트 덕분에 많은 상용 스위치가 하드웨어 변경 없이 오픈플로우(OpenFlow)를 지원하기 시작했습니다.

SDN이 해결하는 기존 네트워크의 문제점

개별적으로 구성된 물리적 장비 에 거의 전적으로 의존하는 기존 네트워크는 기업, 서비스 제공업체 및 최종 사용자의 현재 요구 사항에 직면하여 한계에 도달하고 있습니다. 이러한 네트워크의 가장 큰 약점은 수년에 걸쳐 누적된 복잡성입니다.

업계는 발생 가능한 모든 시나리오를 포괄하기 위해 특정 문제(보안, 효율성, 이중화 등)를 해결하는 더욱 구체적인 네트워크 프로토콜을 추가해 왔지만 , 이러한 프로토콜들은 대개 독립적으로 설계됩니다. 그 결과, 전체를 단순화할 공통 추상화 계층 없이 수동으로 조정해야 하는 복잡하게 얽힌 메커니즘들이 생겨납니다.

조직에서 전체 네트워크에 걸쳐 일관된 정책을 시행하려는 경우(예: 누가 어떤 리소스에 접근할 수 있는지 결정) 관리자는 수백 또는 수천 대의 장치를 수정 해야 합니다. 새로운 가상 머신을 추가하는 것과 같은 간단한 작업조차도 환경 전체에 흩어져 있는 수많은 접근 제어 목록(ACL) 을 변경해야 할 수 있으며 , 이로 인해 인적 오류 발생 가능성과 몇 시간씩의 지연이 발생할 수 있습니다.

확장성 부족 또한 심각한 문제입니다. 데이터 센터의 증가, 사용자 수 증가, 트래픽 증가로 인해 점점 더 많은 장치를 추가해야 합니다. 장비가 추가될 때마다 구성, 관리, 그리고 잠재적인 오류 발생 지점이 늘어납니다. 이 모든 것을 비즈니스 요구 사항에 맞춰 유지하는 것은 매우 어려운 과제가 됩니다.

경제적인 관점에서 볼 때, 기업들은 제조업체의 제품 주기에 지나치게 의존하는 경향이 있습니다 . 새로운 네트워크 기능이 필요할 경우, 단순히 소프트웨어를 업데이트하는 것만으로는 부족한 경우가 많습니다. 기업들은 공급업체가 적절한 모델을 출시하고, 내부 인증을 완료하고, 장비를 구매하고, 배포가 이루어질 때까지 기다려야 하는데, 이러한 과정은 수년이 걸릴 수 있으며 혁신을 저해합니다.

설상가상으로 최근 추세는 상황을 더욱 복잡하게 만들고 있습니다. 기계 간 트래픽, 분산 데이터베이스, 마이크로서비스, 그리고 휴대폰, 태블릿, 노트북을 이용해 어디서든 접속하는 사용자들 등 훨씬 더 이질적인 트래픽 패턴이 나타나고 있습니다 . 관리자들은 기존의 네트워크 경계가 사실상 사라지는 가운데 민감한 데이터를 보호해야 하는 부담이 가중되고 있습니다.

여기에 더해 클라우드 서비스(SaaS, IaaS, PaaS) 의 성장은 빠른 프로비저닝, 컴퓨팅, 스토리지 및 네트워킹의 동적 확장, 그리고 더욱 정교한 보안 요구 사항을 필요로 합니다. 빅데이터의 증가는 수천 대의 서버에 걸쳐 막대한 대역폭과 전송 용량을 요구하지만, 기존 네트워크는 이를 항상 따라잡을 수 없습니다.

SDN이란 정확히 무엇이며, 어떻게 문제를 해결할까요?

SDN(소프트웨어 정의 네트워킹)은 네트워크에 유연성, 중앙 집중식 제어 및 프로그래밍 기능을 제공하도록 설계된 새로운 아키텍처 로 , 복잡성을 하드웨어에서 소프트웨어로 옮깁니다. 더 이상 각 장치를 개별적으로 관리하는 것이 아니라, 더 높은 논리 계층에서 원하는 네트워크 동작을 정의하는 것입니다.

핵심 원칙은 제어 평면과 데이터 평면의 분리 입니다 . 데이터 평면은 엔드포인트 간에 패킷을 고속으로 전송하는 역할을 담당하고, 제어 평면은 정책, 경로 및 규칙을 적용하여 패킷이 어디로 어떻게 이동해야 하는지 결정합니다. SDN에서는 이러한 평면이 분리되고 제어는 하나 이상의 논리적 컨트롤러에 집중됩니다.

컨트롤러와 스위치 사이에는 일반적으로 OpenFlow와 같은 표준 프로토콜을 통해 잘 정의된 인터페이스가 구축됩니다 . 이 인터페이스 덕분에 컨트롤러는 스위치와 라우터에 포워딩 규칙을 설치, 수정 또는 삭제할 수 있으며, 스위치와 라우터는 폐쇄형 시스템이 아닌 프로그래밍 가능한 장치처럼 동작하게 됩니다. OpenFlow는 유일한 프로토콜은 아니지만 가장 널리 사용되고 있으며 사실상의 표준으로 자리 잡았습니다.

컨트롤러 상위 계층에서 SDN 애플리케이션은 북쪽 API를 사용하여 네트워크에서 필요한 동작 (예: 특정 트래픽 우선순위 지정, 부서별 네트워크 분할, 로드 밸런싱, 서비스 품질 향상, 서비스 거부 공격 대응 등)을 표현합니다. 컨트롤러는 이러한 상위 수준 요청을 데이터 플레인에 적용되는 구체적인 포워딩 규칙으로 변환합니다.

다시 말해, SDN은 네트워크를 애플리케이션과 서비스를 마치 순수 소프트웨어처럼 개발할 수 있는 플랫폼으로 변환합니다 . 이를 통해 각 장비 모델이나 하위 수준 프로토콜의 세부 사항은 무시할 수 있습니다. 이러한 추상화는 자동화를 용이하게 하고 오류를 줄이며 수요 변화에 훨씬 빠르게 적응할 수 있도록 합니다.

SDN 아키텍처: 컨트롤러, API 및 주요 구성 요소

일반적인 SDN 네트워크는 여러 논리적 계층과 명확하게 구분된 구성 요소로 구성됩니다. 그 중심에는 네트워크의 두뇌 역할을 하는 SDN 컨트롤러가 있으며, 데이터 플레인에서 정보를 수집하고 애플리케이션 결정을 실행합니다.

컨트롤러는 네트워크의 토폴로지, 각 장치의 기능, 트래픽 통계, 링크 상태 등과 같은 추상적인 네트워크 정보를 유지합니다. 이러한 정보를 바탕으로 활성화 또는 비활성화 가능한 플러그인 모듈 (인벤토리 관리, 통계 수집, 보안 모듈, 로드 밸런싱 등)을 활용하여 결정을 내리고, 일반적으로 OpenFlow 또는 OVSDB나 Cisco OpFlex와 같은 다른 프로토콜을 사용하는 사우스바운드 API를 통해 장치에 전달합니다.

데이터 플레인 장치(물리적 스위치, 가상 스위치, 라우터)는 ONF에서 SDN 데이터패스 라고 부르는 것을 구현합니다 . SDN 데이터패스는 논리적으로 노출된 포워딩 엔진 및 트래픽 처리 기능 세트입니다. 각 데이터패스 내에는 컨트롤러로부터 명령을 받아 이를 플로우 테이블의 규칙이나 특정 하드웨어 동작으로 변환하는 CDPI(제어 인터페이스 처리 에이전트)가 있습니다.

아키텍처의 최상위에는 SDN 애플리케이션이 있습니다 . 이러한 애플리케이션은 북쪽 방향 API(NBI)를 통해 컨트롤러와 통신하며 IP 주소 관리(IPAM), 서비스 오케스트레이션, 서비스 품질(QoS) 제어, DoS 공격 방어 시스템, 고급 분석 도구 등과 같은 비즈니스 또는 기술적 요구 사항을 표현합니다. 각 애플리케이션은 자체 로직과 컨트롤러와 상호 작용하기 위한 하나 이상의 NBI를 포함합니다.

이러한 블록들 사이에는 CDPI(Control-to-Data Plane Interface) 가 있으며 , 이는 포워딩에 대한 프로그래밍 기능을 제공하고, 장치 기능을 알리고, 통계를 노출하고, 이벤트를 알리는 역할을 담당합니다. 컨트롤러는 이 인터페이스용 드라이버를 구현하고, 장치는 에이전트를 구현하므로 각 드라이버/에이전트 쌍은 물리적 인프라와 애플리케이션 간의 특정 관계를 설정합니다.

ONF는 이러한 세 가지 주요 계층 외에도 클라이언트에 대한 리소스 할당, 물리적 장비의 기본 구성, 자격 증명 관리, 논리적 엔티티와 물리적 엔티티 간의 연결과 같은 보다 정적인 작업을 다루는 관리 및 운영 계층을 정의합니다 . 이러한 작업은 일반적으로 동적 트래픽 제어 주기 외부에서 관리됩니다.

북쪽 및 남쪽 인터페이스, 그리고 흐름 프로그래밍 모델

남쪽 방향 API는 컨트롤러를 하드웨어 또는 데이터 경로에 연결합니다 . OpenFlow는 최초로 널리 채택된 인터페이스로, 컨트롤러가 스위치의 플로우 테이블에 항목을 추가하는 방법, 통계를 수집하는 방법, 패킷 불일치와 같은 이벤트를 보고하는 방법 등을 정의합니다. Cisco OpFlex와 같은 다른 대안들은 서로 다른 모델을 제시하지만, 중앙 집중식 요소가 장치 동작에 영향을 미칠 수 있도록 한다는 기본 아이디어는 동일합니다.

북쪽 API를 통해 애플리케이션은 컨트롤러와 통신 하고 네트워크에 대한 추상적인 뷰를 얻을 수 있습니다. 여기에는 OpenFlow처럼 확립된 표준은 없으며, 스택의 여러 계층(REST, gRPC, 특정 SDK, 의도 기반 모델 등)에 다양한 제안과 라이브러리가 존재합니다. 바로 이러한 다양성 때문에 ONF는 모범 사례를 정의하고 호환 가능한 접근 방식으로 수렴하는 데 큰 비중을 두고 있습니다.

운영 수준에서 컨트롤러는 장치에 흐름 규칙을 구현하기 위해 사전 예방적, 사후 대응적 또는 혼합 모델을 따를 수 있습니다 . 사후 대응적 접근 방식에서 스위치는 테이블의 항목과 일치하지 않는 패킷을 수신할 때 컨트롤러에 질의합니다. 컨트롤러는 지침을 제공하고 필요한 경우 향후 유사한 패킷에 대한 새 규칙을 생성합니다.

사전 예방적 모델에서는 컨트롤러가 기존 라우팅 테이블처럼 예상되는 트래픽 흐름에 대한 규칙을 미리 설치합니다 . 이를 통해 실시간 쿼리를 최소화하고 초기 통신 지연 시간을 줄일 수 있습니다. 실제 구축 환경에서는 두 모델을 모두 사용하는 경우가 많은데, 예측 불가능한 트래픽에는 반응적으로 대응하고 잘 알려진 흐름에 대해서는 사전 예방적으로 대응합니다.

SDN의 진정한 강점은 이러한 개방형 API가 제공하는 프로그래밍 가능성 에 있습니다 . 이를 통해 부하에 따라 경로를 동적으로 조정하고, 중요 트래픽의 우선순위를 지정하고, 장애 또는 보안 사고에 대한 대응을 자동화하고, 심지어 애플리케이션 자체가 네트워크와 필요한 조건(대역폭, 최대 지연 시간, 이중화 수준 등)을 협상할 수 있도록 할 수 있습니다.

SDN에서의 프로그래밍 가능성 활용 사례

네트워크 프로그래밍 가능성 개념을 설명하기 위해 SDN이 실제로 어떻게 활용되는지 보여주는 세 가지 주요 사용 사례가 자주 논의됩니다 . 첫 번째는 트래픽 흐름의 세밀한 조정입니다. OpenFlow와 같은 프로토콜을 사용하면 컨트롤러는 거의 실시간으로 특정 유형의 트래픽이 어떤 경로를 따라야 하는지 결정하여 링크 간 부하를 분산하고, 혼잡을 방지하거나, 필요한 경우 더 엄격한 보안 정책을 적용할 수 있습니다.

두 번째 주요 사례는 고급 애플리케이션 지원 에 있습니다 . 네트워크가 애플리케이션의 동작을 파악하지 못하는 대신, 애플리케이션은 요구 사항(예: 음성 또는 비디오 전송을 위한 낮은 지연 시간, 특정 데이터 전송을 위한 높은 대역폭, 클라이언트 간 엄격한 격리)을 네트워크로 전달할 수 있으며, 컨트롤러는 이러한 요구 사항을 충족하도록 구성을 조정합니다. 또한, 특히 클라우드 및 대규모 가상화 환경에서 자동화된 배포를 통해 관리자가 수동으로 매개변수를 변경할 필요 없이 새로운 서비스를 신속하게 배포할 수 있습니다.

세 번째 핵심 요소는 네트워크 운영 자동화 입니다 . 잘 설계된 SDN 시나리오에서는 네트워크가 다양한 이벤트에 자율적으로 대응할 수 있습니다. 링크에 장애가 발생하면 경로를 재계산하고, 의심스러운 트래픽 패턴이 나타나면 차단 규칙을 적용하거나 분석 시스템으로 리디렉션하며, 새로운 애플리케이션이 실행되면 네트워크가 자동으로 리소스를 할당합니다. 관리자의 역할은 단순히 "명령어 변경"에서 벗어나 고수준 정책을 정의하고 규정 준수를 보장하는 것으로 바뀝니다.

SDN이 조직에 제공하는 이점

SDN의 가치 제안은 기업과 서비스 제공업체에게 매우 명확한 여러 가지 이점을 제공합니다 . 그중 가장 주목할 만한 것은 중앙 집중식 관리입니다. 컨트롤러에서 전체 네트워크에 대한 액세스 정책, 보안 규칙, 트래픽 우선순위 및 서비스 프로비저닝을 정의할 수 있으므로 각 장치를 개별적으로 관리하거나 각 제조업체의 특정 인터페이스에 의존할 필요가 없습니다.

확장성 측면에서 SDN은 탁월한 민첩성을 제공합니다. 관리자는 가상 어플라이언스를 추가하거나 제거하고, 네트워크를 분할하고, 지사 또는 데이터 센터를 연결하고 , 클라우드 오케스트레이션 플랫폼과 통합하여 거의 실시간으로 경로를 조정할 수 있습니다. 이 모든 작업은 상대적으로 안정적인 기반이 되는 물리적 인프라에 미치는 영향을 최소화하면서 이루어집니다.

또 다른 중요한 장점은 네트워크 동작에 대한 포괄적인 가시성 입니다 . 컨트롤러 또는 조정된 컨트롤러 도메인에 정보를 중앙 집중화함으로써 성능, 병목 현상, 활성 흐름 및 잠재적 위협에 대한 완벽한 그림을 얻을 수 있습니다. 이러한 가시성은 일상적인 운영뿐만 아니라 용량 계획 및 문제의 조기 감지에도 도움이 됩니다.

경제적인 관점에서 SDN은 CAPEX와 OPEX 모두를 절감하는 데 도움이 됩니다. 첫째, 많은 스위치가 간단한 펌웨어 업데이트만으로 SDN 기능을 활성화할 수 있으므로 기존 하드웨어를 재사용할 수 있습니다 . 둘째, 자동화를 통해 직원이 반복적인 구성 작업에 소요하는 시간을 줄이고, 인적 오류를 감소시키며, 유지 관리 및 업그레이드를 간소화할 수 있습니다.

마지막으로 중요한 이점은 혁신과 대응 속도 와 관련이 있습니다 . 하드웨어와 소프트웨어를 분리함으로써 기업은 특정 제조업체의 제품 출시 일정에 얽매이지 않고 새로운 서비스를 개발하고, 다양한 비즈니스 모델을 실험하거나, 새로운 요구 사항(하이브리드 클라우드, IoT, 엣지 컴퓨팅, 빅데이터)에 맞춰 네트워크를 조정할 수 있습니다.

SDN 네트워크의 단점 및 과제

SDN은 만능 해결책이 아니며, 이러한 유형의 네트워크를 설계하고 운영할 때 염두에 두어야 할 과제 도 있습니다 . 가장 자주 언급되는 과제 중 하나는 컨트롤러의 잠재적 취약성입니다. 많은 로직과 의사 결정 기능이 컨트롤러에 집중되어 있기 때문에, 컨트롤러의 장애나 손상은 전체 시스템을 마비시킬 수 있는 핵심 요소가 됩니다.

이를 위해서는 고가용성, 이중화 및 장애 조치 메커니즘은 물론 매우 엄격한 접근 제어를 구축해야 합니다 . 예를 들어 컨트롤러에 대한 서비스 거부(DDoS) 공격은 네트워크가 중요한 이벤트를 감지하지 못하는 상황을 방지하기 위해 충분한 용량으로 완화해야 합니다.

또 다른 과제는 디바이스와 플로우 수가 증가함에 따라 지연 시간과 복잡성이 증가할 가능성입니다 . 컨트롤러가 데이터 플레인과의 상호 작용이 너무 많아지면 과부하가 걸릴 수 있습니다. 잘 설계된 SDN 아키텍처는 기능을 분산시키고, 필요한 경우(예: 로컬 장애 발생 시 빠른 복구) 분산된 요소에 대한 제어권을 유지하며, 컨트롤러를 수평적으로 확장할 수 있어야 합니다.

보안 측면에서 SDN은 향상된 가시성을 제공하지만, 기존 라우터, 스위치 또는 물리적 방화벽에 통합되어 있던 일부 메커니즘이 부족합니다 . 컨트롤러, 애플리케이션 및 장치 간의 통신을 보호하고, 인증 및 무결성을 보장하며, 정책이 의도대로 정확하게 적용되었는지 검증할 수 있는 강력한 정책 환경을 설계하는 것이 필수적입니다.

또한, 네트워크 포렌식을 위한 프로세스를 구축하는 것이 매우 중요합니다 . 여기에는 상세한 이벤트 로깅, 변경 사항 추적, 그리고 사고 발생 시 상황을 재구성할 수 있는 능력이 포함됩니다. 이 모든 것은 SDN의 고유한 역동성과 공존해야 하며, 보안이 병목 현상이 되는 것을 방지하는 동시에 취약점이 남지 않도록 보장해야 합니다.

SDN 생태계에서 ONF 및 기타 관련 주체의 역할

오픈 네트워킹 재단(ONF)은 SDN (소프트웨어 정의 네트워크)의 발전에 있어 핵심적인 역할을 수행합니다. ONF는 최종 사용자(통신 사업자, 대기업)가 주도하는 조직으로, 개방형 표준과 협력적인 프로세스를 통해 소프트웨어 정의 네트워크의 도입을 촉진하는 것을 목표로 합니다.

ONF는 최초로 인정받은 SDN 표준이자 여전히 많은 아키텍처의 핵심 요소 인 OpenFlow 표준을 정의, 유지 및 발전시키는 데 중요한 역할을 해왔 습니다. 하지만 ONF의 활동은 그 이상입니다. 상용 배포에 필요한 요구사항을 분석하고, 새로운 인터페이스, 데이터 모델 및 용어를 제안하며, 다양한 공급업체가 참여하는 생태계를 조성하는 워킹 그룹을 이끌고 있습니다.

이와 동시에 기술 기업과 장비 제조업체들은 자체적인 SDN 플랫폼과 하이브리드 방식을 개발해 왔습니다. 시에나의 블루 플래닛처럼 논리적으로 중앙 집중화된 컨트롤러를 기반으로 하는 솔루션들은 중앙 집중식 기능(엔드 투 엔드 가시성, 정책, 대역폭) 과 장애 복구, 로컬 모니터링 또는 보안을 위한 네트워크 요소 전반에 걸친 분산 기능을 결합합니다.

이러한 하이브리드 접근 방식은 현실적인 상황을 반영합니다. 모든 제어를 중앙 컨트롤러에 맡길 필요는 없으며, 특정 신속 대응 메커니즘은 교통 흐름에 가까이 머무르는 것이 편리하고, 보다 복잡한 지능 및 오케스트레이션은 중앙 집중식으로 프로그래밍 가능한 방식으로 관리됩니다.

SDN, 네트워크 가상화 및 실제 사용 사례

많은 조직에서 SDN은 기존 물리적 인프라 위에 오버레이 네트워크를 구축하기 위해 네트워크 가상화 기술 과 함께 도입됩니다 . 이러한 가상 네트워크는 동일한 하드웨어를 활용하여 서로 다른 환경(운영, 개발, 개별 고객)을 분리하거나, 여러 물리적 네트워크를 마치 하나의 논리적 개체처럼 상호 연결할 수 있습니다.

이러한 접근 방식은 SaaS, IaaS, PaaS와 같은 클라우드 컴퓨팅 서비스 와 통합될 때 특히 강력한 효과를 발휘합니다 . 소프트웨어 정의 네트워크는 오케스트레이션 플랫폼과 연동되어 가상 머신, 스토리지, 네트워크, 보안 등 전체 프로비저닝 주기가 API를 통해 일관되고 신속하며 자동으로 수행됩니다.

대기업과 통신 사업자는 SDN을 활용하여 본사, 데이터 센터, 퍼블릭 클라우드 간의 트래픽을 세밀하게 관리하는 더욱 스마트한 기업 WAN을 구축합니다 . 예를 들어 구글은 수년간 SDN을 사용하여 전 세계 데이터 센터를 상호 연결해 왔으며, ONF와 협력하여 OpenFlow를 뛰어넘는 새로운 제어 인터페이스를 정의해 왔습니다.

데이터 센터 환경에서 SDN은 신속하고 효율적인 확장을 달성하는 데 핵심적인 요소입니다 . 이를 통해 새로운 데이터 센터를 몇 시간 만에 가동하고 네트워크 리소스를 몇 분 만에 프로비저닝할 수 있습니다. 또한 SDN은 대규모 IoT 환경 구축을 용이하게 하여 수천 개의 분산된 장치와 센서를 복잡하지 않게 관리할 수 있도록 지원합니다.

마지막으로, SDN은 소프트웨어 정의 인프라 라는 더 광범위한 추세의 일부입니다 . 소프트웨어 정의 인프라에서는 네트워크뿐만 아니라 스토리지(SDS) 및 기타 리소스도 특정 하드웨어와 관계없이 논리적 제어 평면에서 제어됩니다. 이를 통해 조직은 더 큰 이식성과 민첩성을 확보하고 필요에 따라 클라우드와 온프레미스 간에 워크로드를 이동할 수 있습니다.

이러한 역사적, 기술적, 실용적 배경을 바탕으로 SDN은 네트워크를 이해하는 새로운 방식으로 자리매김하고 있습니다. SDN은 소프트웨어 세계에 더 가깝고 자동화 및 프로그래밍 가능성에 중점을 두며, 하드웨어나 운영 복잡성을 무한정 늘리지 않고도 트래픽 증가, 클라우드, 빅데이터 및 IoT의 과제에 대응할 수 있습니다.