Andrew의 Cloud 이야기 #5

안녕하세요 앤드류 입니다.

추석 명절은 잘 보내셨는지 모르겠네요. 저도 이번에 고향에 다녀왔는데, 갈땐 9시간 올땐 5시간 정도 걸렸습니다. 쉽지 않은 길이었긴 하네요.

이번엔 어떻게든 좀 덜 고생해보려고, S통신사의 X맵 이라는 네비게이션을 사용했습니다. 통신사가 가진 강점중에 하나인 접속자 정보와 위치 정보를 기반으로 가장 정확한 안내를 해준다는 그 네비게이션을 믿고 한번 귀성길을 간것이죠. 이 네비게이션 시스템 막히기 시작하는 지점에서 다른곳으로 안내해 주더군요. 어떤때는 다른 고속도로를 태우기도 하고, 어떤때는 국도를 태우기도 하구요. 물론 그렇게 해서도 9시간이 걸렸지만 20시간정도도 걸린적이 있어본적이 있는 저로써는 약간 감탄했습니다.

그리고 차를 타고 가면서 갑자기 네트워크 생각이 나더군요. 차를 패킷또는 프레임으로 생각하고, 도로를 케이블, 각 교차로나 톨게이트를 라우터라고 생각을 해봤습니다. 보통의 경우 차량(패킷)을 운전하다가 교차로나 톨게이트(라우터)에 도착을 하면 표지판(미리 정의된 길)을 보고 다음 행선지(넥스트 홉, next hop)를 찾아 갑니다. 그리고 다음 행선지에서는 또 그다음 표지판을 보고 따라가죠. 초행길에서는 표지판만 보고 따라 가다가 길이 막히면 꼼짝없이 그자리에 몇십분 또는 몇시간을 갇혀있어야 하는 경우도 있죠.

하지만, 아는길은 어떤가요 미리 막힐 만한 곳은 아예 들어가지 않거나 우회로를 찾아서 갈수 있겠지요 그래서 좀 숙련된 운전자는 대충 길을 파악해두고 운전을 하지요. 네트워크도 마찬가지 입니다. 회선의 상태가 좋지 않거나 대역폭 확보에 문제가 있는 구간은 미리 파악을 해두고 가중치를 낮게 두어서 해당 루트로는 패킷을 보내지 않도록 하는것이죠.

허나 추석이나 설처럼 차량이 집중되는경우는 경험있는 운전자라도 어찌할 수 없는 경우가 허다 합니다. 그리고 운전자의 경험의 한계나, 지식의 공유 때문에 기존에 빨리가던 길이 갑자기 사람이 몰려서 오히려 더 막히기도 하죠. 그래서 이럴때면 공중에서 도로 상황좀 알려주면 좋겠다라는 생각을 수도 없이 하게 됩니다. 이러한 고객의 요구사항을 해당 텔레콤사의 경우 도로정보와 휴대폰 위치정보를 통해 도로의 혼잡 상태를 파악하고 휴대폰 사용자의 네비게이션을 통해서 더 좋은 길로 안내를 하는 방식으로 해결했습니다.

이렇게 중앙에서 모든 곳의 트래픽과 경로의 상태를 보면서 패킷이 가는 경로를 조절하는것을 SDN(Software Defined Network) controller라고 합니다. 그리고 SDN controller에게 보내고 받는 명령어를 표준화한게 openflow 라는 규격입니다. 그리고 openflow를 사용할 수 있게 만든 오픈소스기반의 소프트웨어 스위치가 OVS (Open Virtual Switch) 입니다.

이것을 도로 교통 시스템과 매핑시켜보면, SDN controller는 텔코사의 네비게이션 안내 서버, openflow는 데이터 망 또는 핸드폰 앱과 서버간의 통신 프로토콜, OVS는 운전자 정도 일것입니다. OVS가 패킷의 정보를 sdn 콘트롤러에게 정보를 전달하면 sdn 콘트롤러는 이것을 모든 OVS로 부터 받아서 최정의 패킷 결로를 개산한 다음에 경로에 있는 모든 OVS에게 다시 openflow라는 프로토콜을 통해서 적절한 방향을 설정하게 합니다.

OVS의 경우 자신에게 설정된 flow가 없는 새로운 패킷이 들어올때 반드시 sdn controller에 접속해서 경로를 받아와야만 패킷을 처리할 수 있습니다. 이런것은 reactive라고 합니다. 사람의 경우 각자마다 선호하는 길과 방향이 있어서 네비가 안내를 해준다고 하더라고 따라가지 않게되는데, 이런것을 OVS에서는 proactive 또는 predefined 이라고 합니다. 모든 경로 안내를 sdn콘트롤러에게 묻지 않고 자신이 알아서 차단하거나 특정 경로로 보내는것이죠.

이러한 sdn시스템을 사용할 경우 네트워크내의 장애나 쏠림등에 적절하게 대응할 수 있습니다. 다만 문제는 도로 네비게이션의 경우 속도도 느리고, 대수도 많지 않기 때문에 경로계산과 통신량이 크지 않지만, 실제 네트워크의 경우 패킷의 양이나 빈도 속도가 훨씬 빠르기 때문에 콘트롤러 자체에 큰 부담을 주게 됩니다.

그래서 sdn controller를 개발하는 곳에서는 이문제를 처리하기 위해 클러스터 형태의 콘트롤러를 개발하거나 분산 데이터 베이스를 사용해서 부하를 최대한 분산시키려고 합니다. 하지만 속도가 아직은 상용수준으로 올라오진 않고 있습니다.

두번째 문제는 openflow를 통해 패킷의 경로를 그때 그때 바꾸려고 하다보니까 실제 물리 네트워크는 터널형태로 모두 연결되어 있어야만 합니다. peer-to-peer 로 연결된 일종의 가장 사설 네트워크 (VPN)을 모든 컴퓨트노드가 맺어야만 합니다. 물론 peer-to-peer가 아닌 mulitcast 형태로 연결된 터널은 연결 수가 좀 적을 수는 있습니다만, 어찌되었던 터널 인터페이스를 통과하는 순간 속도는 엄청나게 줄어듭니다. 이유는 터널 헤더를 처리하기위해 CPU를 사용해야만하기 때문에 지연이 길어지게 됩니다. ( 물론, 특별한 하드웨어 장치를 갖춘 네트워크 카드를 사면 성능은 어느정도 보장됩니다. 하지만 가격과 관리비용이 올라갑니다.).

그래서 패킷의 경로는 자동화 할 수 있을지라도, 아직은 성능과 관리성면에서 많은 부분 개선이 필요한 분야가 sdn쪽입니다. 하지만 현재 상태가 좀 좋지 않더라도, 많은 벤더와 엔지니어가 이 문제를 해결하기 위해서 고심하고 있으니 수년내에 좀더 좋은 형태의 sdn이 나오지 않을까 싶습니다.

그렇게 되면, 네트워크 단절이나 트래픽 폭증으로 인한 장애상황들을 좀더 빠르고 능동적으로 처리할 수 있지 않을까요

이상 추석 명절에 막히는 길을 지나면서 든 생각이었습니다.

출처 : 한국데이터베이스진흥원

제공 : 데이터 전문가 지식포털 DBguide.net