금융IT

프라이빗 클라우드와 금융 데이터센터의 혁신… HPE가 제시한 해법은?

디지털데일리 발행일 2017-06-23 10:09:35
  • 가
  • 가
박기록
디지털데일리는 오는 25일 발간예정인 <디지털금융, 혁신과 도전 2017년판 특별호>에 수록된 주요 내용중 일부를 요약해 공개합니다.

첫 순서는 금융권 클라우드 동향과 함께, 이 분야의 글로벌 트랜드를 주도하고 있는 AWS, IBM, HPE 등 주요 IT기업들의 글로벌 사례와 전략을 제시합니다. 본 제시된 내용은 관련 기고문을 기반으로 작성됐으며, 기고 내용은 본지의 편집방향과는 관계없습니다. <편집자>

금융 IT 인프라의 혁신 방향 - 소프트웨어정의데이터센터 (Software Defined Data Center)

글 : HPE 금융산업 CTO 박종웅 이사

금융회사 CIO(최고정보화담당임원)에게 주어진 핵심 역할은 적지않다. IT 서비스의 안정적인 제공, 비즈니스 혁신과 비용 효율화를 통한 IT 부문의 혁신 등이 주요 임무다. CIO가 변화와 혁신에 초점을 맞추느냐 아니면 서비스의 안정성에 좀 더 초점을 맞추느냐는 것은 본인의 의지뿐만 아니라 금융회사의 문화에도 영향을 받는다.

최근 금융권 CIO가 관심을 갖는 혁신 아젠다는 어플리케이션 부문에선 챗봇/인공지능, 블록체인 등 핀테크와 차세대 프로젝트, 모바일 강화, 빅데이터 등 이다.

반면 인프라부문에선 어플리케이션을 통해 간접적으로 지원하는 것이므로 비용효율화가 핵심이다. IT 인프라 내에서는 서버 영역이 가장 많은 혁신을 해왔다. 과거 메인프레임을 유닉스 서버로 다운사이징 했던것처럼 이제는 고비용 유닉스 서버를 오픈 환경의 x86 서버로 전환하는 U2L이 금융권의 주된 관심사다.
스토리지와 네트워크 인프라 영역은 여전히 고비용 외장 스토리지와 인텔리전트 스위치가 주류를 이루고 있다. 외장 스토리지와 네트워크 스위치가 고비용인 이유는 컨트롤러 기능이 HW 내에 ASIC 반도체 형태로 포함되고, 기능이 발전되면서 연구개발비가 많이 투입됐기때문이다.

따라서 ‘Software Defined Storage(이하 SDS)와 ‘Software Defined Network(이하 SDN)’의 본질은 고비용 컨트롤러 기능을 저비용 x86 서버 기반의 SW로 분리하는 것이다. 이를 통해 HW 비용을 최소화하고 밴더락인(Vendor Lock-in)을 탈피해 오픈 환경으로 가자는 것이다.

Software Defined Everything (SDx)의 배경

SDS와 SDN의 개념이 새로운 것은 아니다. 오히려 초기 IT 인프라는 스토리지 컨트롤러와 네트워크 컨트롤러 기능이 서버 내의 SW로 존재했다. HW는 내장 스토리지와 단순 네트워크 스위치를 주로 사용했기때문에 ‘Software Defined’ 방식이었다.

컨트롤러 기능이 HW에 통합된 이유는 1990년대부터 대기업의 데이터센터 내 데이터 트래픽이 기하급수적으로 증가하면서 더 많은 데이터를 더 빨리 처리하기 위해 HW 가속방식이 필요했던 역사적 배경때문이다.

그리고 2010년대에 들어 다시 Software Defined 방식이 활성화됐다. 범용 x86 서버의 성능과 네트워크 대역폭이 획기적으로 향상되면서 HW 가속 방식이 아니더라도 성능을 확보하는 데 문제가 없어졌기때문이다.

결국 Software Defined Everything는 IT비용절감, 전사적 인프라 통합관리를 통한 유지보수 효율화, 밴더락인 탈피를 위한 오픈 솔루션 도입 등 3지 이유가 작용한 결과라고 할 수 있다.
서버 영역은 이미 저비용 x86 서버가 대세가 됐고, x86 가상화기술까지 보편화되면서 상당 수준 비용 효율화가 진행되고 있다. Software Defined Compute(Server)라는 용어는 이제 거의 사용되지 않는다. 굳이 정의하자면 x86 서버 기반으로 가상화 환경을 구축한 것 자체가 Software Defined 방식이다. 나아가 물리 서버(Bare-Metal) 환경도 SW로 통제하면서 펌웨어 관리와 Bare-Metal OS 프로비저닝까지 자동화하는 것을 포함하고 있다.
Software Defined Storage (SDS) - 이것의 정의를 전사적 스토리지 통합 관리에만 초점을 둔다면, 외장 스토리지를 포함한 모든 유형의 스토리지를 표준관리 SW로 통제하는 아키텍처를 제시할 수 있다. 그러나 비용 효율화에 부합하기 위해선 고비용 외장 스토리지를 저비용 내장 스토리지로 대체하는 것까지 포함해야 한다. 즉, HW 측면에서는 저비용 x86 서버와 내장 스토리지를 기반으로 하고, SW 측면에서는 이 x86 서버에 스토리지 컨트롤러 SW를 탑재함으로써 다른 서버들이 볼 때는 외장 스토리지처럼 보이게 하는 것이다.

이 아키텍처의 핵심은 스토리지 컨트롤러 SW이다. 단순히 내장 스토리지를 가상화해서 논리 볼륨이나 파일 시스템을 외부로 노출하는 기능뿐만 아니라 데이터복제와 이중화, 중복제거와 압축, 데이터 보안 등 기존 외장 스토리지 컨트롤러가 가지고 있는 부가 기능들을 포함해야 한다. 이러한 SDS아키텍처에서도 기존 외장 SAN 스토리지 기반으로 운영되고 있는 금융회사의 모든 업무를 구현할 수 있다.

그동안 금융회사의 IT기획자들부터 자주 들었던 질문은, ‘금융회사의 핵심 업무는 DB 서버의 Active-Active 이중화와 DR 구성이 필요한데 내장 스토리지 기반으로 이를 구현할 수 있는가’ 라는 것이었다.
이에 대한 답변은 SW 방식의 스토리지 컨트롤러도 기존 HW 방식의 컨트롤러와 동일한 역할을 하므로 Multi-Node Oracle RAC를 구성할 수 있고, DR 구성도 스토리지 컨트롤러 레벨의 실시간 스토리지 복제 (그림의 2안)와 서버 레벨의Changed Data Capture 방식 (그림의 1안)을 모두 적용할 수 있다는 것이다.
x86 서버 기반의 스토리지 컨트롤러 SW로는 다양한 상용 솔루션이 있다. HPE의 경우는 2008년, S DS분야의 선도 업체였던 LeftHand(레프트핸드)를 인수해 역량을 강화했다. StoreVirtual VSA가 이러한 스토리지 컨트롤러 SW이다.

최근에 VDI나 서버 가상화 용도의 인프라 대안으로 검토되고 있는 하이퍼 컨버지드 인프라도 SDS가 그 기반 기술이다. 즉, 하이퍼 컨버지드 인프라는 범용 x86 서버에 서버 가상화 SW와 스토리지 컨트롤러 SW가 사전 탑재된 어플라이언스 제품이다.

HPE가 올해 초 인수한 심플리비티(SimpliVity)솔루션은 SSD와 HDD가 장착된 범용 x86 서버 (DL380)에 VMware ESXi 하이퍼바이저와 SimpliVity 스토리지 컨트롤러 SW가 사전 설치됐으며, 이를 VMware vCenter와 통합된 SimpliVity Plug-in으로 관리하는 구조다.
모든 하이퍼 컨버지드 솔루션의 핵심 기능은 복수의 물리 서버에 실시간으로 VM을 복제하고 동기화함으로써 특정 물리 서버의 장애 시에 다른 물리 서버의 복제 VM을 사용해서 복구(Failover)를 하는 것이다.

HPE SimpliVity의 특징은 HW 가속 카드를 통해서 중복 제거와 압축을 실시간으로 수행함으로써 CPU 부하 없이 스토리지 I/O를 가속화하며, 원격지에 위치한 SimpliVity Cluster에 WAN 가속 방식의 복제를 수행함으로써 자체 기능 만으로 DR 체계를 구성할 수 있다는 것이다.
Software Defined Network (SDN) - 초기의 기업용 LAN 구조에서 네트워크 장비는 단순 패킷 전송 기능 만을 담당했고, 라우터 등 좀 더 복잡한 네트워크 기능은 범용 유닉스 서버에 탑재된 SW가 담당하는 역할 분담 체계였다. 즉, 초기의 대기업 네트워크는 Software Defined 방식이었다. 1990년대 중반 이후 데이터센터 내 트래픽의 폭발적 증가로 네트워크 스위치 기능의 고속화가 요구됐고, HW 가속 방식으로 전환되면서 오늘날의 인텔리전트 스위치처럼 L2/L3 Forwarding Table 갱신, QoS, ACL 등 네트워크 관리 기능이 모두 스위치 HW 내에 내장되게 된 것이다.
그럼 왜 다시 초기의 SDN 모델로 회귀하려는 것일까. 크게 2가지 이유다. 우선은 범용 x86 서버의 성능과 네트워크 대역폭이 획기적으로 향상됨에 따라 SW방식으로도 요구되는 성능을 제공할 수 있게 됐기때문이고, 둘째는 외부 인터넷과 달리 대기업 내부의 데이터센터 네트워크 구조는 변동성이 적어 소수의 관리자가 전체 네트워크를 중앙 집중적으로 관리 가능해졌기 때문이다.
SDN의 본질적인 목표는 오픈 지향이다. 이를 달성하기 위해서는 컨트롤 플레인과 데이터 플레인의 분리, 단순화된 스위치 적용, SW 방식의 중앙집중관리, 네트워크 자동화와 가상화, 표준 API기반의 오픈 솔루션의 적용 등 5가지 조건이 만족돼야 한다. 이를 만족하는 아키텍처가 오픈SDN이며, SDN 컨트롤러는 x86/Linux 기반의 SW로 구성돼야하고, SDN 스위치와의 인터페이스인 Southbound API는 업계 표준 오픈플로우(OpenFlow) 기반이어야 한다. SDN 컨트롤러에는 OpenFlow API 만을 지원하는 솔루션과 OpenFlow와 기존 API를 모두 지원하는 솔루션이 있다.
SDN 스위치는 OpenFlow API를 지원해야 하는데 시스코, HPE, 아리스타, 주니퍼 등의 기존 네트워크 스위치도 OpenFlow를 지원하는 제품이 많다. Open SDN의 본질적인 목표인 비용 효율화 관점에서는 화이트박스 스위치가 유력한 대안이 되는데, 이는 물리 스위치 내에 소형 x86 서버가 Bare-Metal로 내장돼 있어 오픈 기반의 네트워크OS를 원하는 대로 설치할 수 있다.

HPE의 Altoline 모델이 화이트박스 스위치의 예인데, 1G, 10G, 40G, 100G 등 다양한 대역폭의 스위치 모델을 가지고 있다. 오픈 SDN이 주로 물리 (Underlay) 네트워크를 관리한다면, SDN의 두번째 유형인 Overlay SDN은 가상화 환경의 SW스위치를 포함한 Overlay네트워크를 관리하는 방식이다. Nicira의 NVP와 Nuage의 VSP가 대표적인데, 두 솔루션 모두 하이퍼바이저 상의 SW 가상 스위치를 네트워크 컨트롤러 SW가 통합관리하는 방식이다. Northbound API를 통해 OpenStack, vCenter 등의 클라우드 플랫폼과 연계된다.
SDN의 세번째 유형은 네트워크 벤더에 특화된 API 기반의 비표준 SDN인데, 대표적인 네트워크 컨트롤러 솔루션은 시스코의 APIC과 주니퍼(Juniper)의 컨트레일(Contrail)이다.

지원하는 Southbound API는 해당 벤더의 네트워크 스위치와 연계되는 비표준 API로서, 시스코APIC은 OpFlex API를 지원하고, 주니퍼 컨트레일l은 XMPP API를 지원한다. 이러한 비표준 SDN은 해당 벤더의 네트워크 스위치를 보다 효과적으로 중앙 집중 관리할 수 있다는 장점이 있다.. 반면, 해당 벤더의 스위치에 종속됨으로써 비용 효율화와 밴더락인 탈피라는 목표를 달성하기 어렵다는 단점이 있다. 상기한 3가지 SDN 유형에 따른 주요 SDN 컨트롤러의 특징을 요약하면 아래와 같다.

프라이빗 클라우드와 Software Defined Data Center (SDDC)

금융회사 IT담당자들과 얘기해보면, 프라이빗 클라우드처럼 그 정의가 불명확하고 서로 다른 의견을 가지고 있는 경우도 드물다.

클라우드라는 용어 자체가 종량제 과금 기반의 퍼블릭 클라우드에서 출발했다. 그런데 과금 체계와 무관한 내부 데이터센터 환경에도 클라우드라는 용어를 붙이다 보니 혼동이 생긴 것 같다. 어떤 금융회사는 가상화 환경을 프라이빗 클라우드와 동일시 한다. 그런데 이것이 100% 잘못된 정의라고 말하기 어려운 측면도 있다.
그 동안의 프라이빗 클라우드 구축 경험에 따르면, 프라이빗 클라우드를 퍼블릭 클라우드나 가상화 환경과의 차이점 관점에서 아래와 같이 정의하는 것이 그나마 일관성 있는 정의로 판단된다. 즉, 프라이빗 클라우드의 본질은 서버, 스토리지, 네트워크 등 모든 IT인프라를 통합관리하고 자동화함으로써 운영효율화를 추구하는 체계인 것이다.

또 다른 빈번한 질문은 ‘프라이빗 클라우드 환경과 SDDC간의 차이가 무엇이냐’는 것이다. 솔루션 관점에서 프라이빗 클라우드 플랫폼을 얘기하라면, 오픈 소스인 오픈스택이나 상용 솔루션인 VM웨어의 vCloud, MS(마이크로소프트) AzureStack 등을 얘기할 수 있다. 이 솔루션들을 보면, SDS나 SDN이 필수 요소가 아니므로 프라이빗 클라우드가 SDDC를 전제로 하는 것이 아니라고 볼 수 있다.

반대로, SDDC의 정의가 Software Defined Compute, Storage, Network를 통합해서 운영 자동화 (Orchestration)를 하는 것까지 포함한다면, 프라이빗 클라우드 플랫폼과 같은 Orchestration Layer가 필요하다. 따라서 프라이빗 클라우드나 SDDC라는 용어 자체보다는, 각 금융사가 추구하는 핵심 목표를 명확히 정의하고, 이를 위한 달성 방안을 구체화하면서 각 사에 적합한 아키텍처를 설계하는 것이 맞는 접근방법이다. 만일 프라이빗 클라우드와 SDDC를 포괄하는 아키텍처를 구성하고자 한다면, 아래와 같은 개념 아키텍처가 참고가 될 것이다.
금융회사 IT 인프라의 혁신 방향은 비용 효율화가 핵심 목표인데, 이때 비용이란 HW와 SW 도입 비용뿐만 아니라 운영 인건비도 포함한 TCO가 되어야 한다. SDx도 이러한 TCO 절감을 전제로 하며, 어떤 방식과 솔루션을 적용할 지와 어떤 범위와 단계로 추진할 지는 각 금융사의 IT 전략과 인프라 현황에 따라 결정될 사안이다.

예를 들면, 아래와 같은 고려 사항이 검토돼야 한다.
• As-Is IT 인프라의 주요 이슈와 근본 원인은 무엇인가?
• SDx를 고려하는 핵심 목표와 방향성은 무엇인가?
• 어떤 유형의 SDx가 당사에 적합한가?
• 어떤 업무에 적용할 것이며, 어떤 우선 순위와 일정으로 추진할 것인가?
• IT 인프라 노후화에 따른 교체 주기와 SDx 적용 일정을 어떻게 연계할 것인가?
• To-Be 아키텍처와 솔루션 선정을 위한 평가 과정은 어떻게 가져갈 것인가?
• To-Be 검증을 위한 POC 또는 파일럿 적용 여부와 어프로치를 어떻게 할 것인가?
• To-Be 환경의 운영을 위한 조직과 역할 분담은 어떻게 정의할 것인가?

- 이상 끝 -

Copyright ⓒ 디지털데일리. 무단전재 및 재배포 금지
박기록
rock@ddaily.co.kr
기자의 전체기사 보기 기자의 전체기사 보기

이 기사와 관련된 기사

디지털데일리가 직접 편집한 뉴스 채널

당신이 좋아할 만한 뉴스

많이 본 기사

연재기사

실시간 추천 뉴스