[기획/레드햇 오픈소스] ‘SW 정의 스토리지’를 도입하는 8가지 단계

실시간
뉴스

하드웨어

[기획/레드햇 오픈소스] ‘SW 정의 스토리지’를 도입하는 8가지 단계

디지털데일리 발행일 2017-02-21 09:59:48

백지영

URL복사

[디지털데일리 백지영기자] 최근 몇년간 시장에선 ‘소프트웨어 정의 스토리지(Software Defined Storage)’가 주목받고 있다. 기하급수적으로 증가하는 데이터의 홍수 속에서 방대한 양의 데이터를 보다 유연하게 관리할 수 있는 인프라 구축 수요와 맞물렸기 때문이다.

이미 많은 기업들은 획일적인 구식 솔루션에 의존하는 대신 퍼블릭 클라우드와 프라이빗 클라우드를 연계하는 웹 스케일 IT 아키텍처를 구축에 나서고 있다. 스토리지 관점에서는, 스토리지 하드웨어와 이를 관리하는 SW를 분리하는 ‘SW 정의 스토리지’라는 혁신적인 접근법이 각광받게 된 것이다.

현재 널리 채택되고 있지는 않지만 잠재력은 상당히 높게 평가되고 있다. 시장조사기관 가트너에 따르면, 오는 2018년까지 엔터프라이즈 시장에서 SW 정의 스토리지의 점유율은 20%를 넘을 것으로 예상된다.

하지만 역설적이게도 현재까지 SW 정의 스토리지에 대한 정의는 명확치 않다. 신기술이 새롭게 떠오를 때 흔히 나타나는 현상인 만큼, 스토리지 업체들이 자사 제품에 편향된 정의를 내세우기 때문이다. 그래서 고객 입장에선 혼선이 생길 수 밖에 없다.

다만 그 혼선의 정도가 깊지않고, 점차 정의가 수렴되는 모습을 보이고 있다. 현재는 하드웨어(HW) 불특정성과 분산 아키텍처, 융합형 스토리지 및 표준 데이터 프로토콜에 대한 기본 지원과 같이 공통적인 특성이 정착돼 가는 추세다.

즉, SW 정의 스토리지는 특정 HW 플랫폼에 종속되지 않고 모든 표준 서버 플랫폼에서 실행될 수 있어야 한다. 이것이 중요한 이유는 SW 정의 스토리지의 주요 목적 중 하나가 기존 스케일업 NAS(네트워크 연결 스토리지) 및 SAN(스토리지 영역 네트워크) 아키텍처의 한계를 극복하는 것이기 때문이다.

또 블록, 파일 및 오브젝트 데이터 서비스를 지원하는 표준 데이터 프로토콜 지원해야 하고, 스토리지 노드에서 애플리케이션 워크로드를 실행할 수 있어야 한다. 즉 컴퓨팅과 스토리지가 융합돼야 하고, 정교한 제어(관리) 플레인을 통해 데이터 접근을 간소화하고 능률화할 수 있어야 한다.

그렇다면 SW 정의 스토리지를 효율적으로 도입하기 위한 방안을 무엇일까.

오픈소스 SW 기업인 레드햇은 8가지 단계별 방안을 제시한다. 레드햇은 지난 2014년 오픈소스 기반 SW 정의 스토리지 ‘세프(Ceph)’ 공급업체인 잉크탱크를 인수하면서 관련 시장에 참여하고 있다. 이미 마드리드 지하철 공사, 인투이트, 카시오, 시스코 등이 레드햇의 스토리지 플랫폼을 도입했다.

우선 첫 번째 도입 방안은 핵심 고려 사항을 정의하는 것이다. 현재 지출하는 스토리지 비용은 얼마이며 필요한 용량과 한계 용량은 얼마인지 파악해야 한다. 비용 뿐만 아니라 유연성, 가용성, 민첩성에 대한 요구 사항을 함께 고려하는 것이 중요하다.

그 다음에는 이를 바탕으로 워크로드를 파악해야 한다. 워크로드 중 일부가 비구조적 데이터에 기반한다면 SW 정의 스토리지가 탁월한 선택이 될 수 있다는 설명이다. 하지만 워크로드가 비교적 소규모이고 구조적 데이터에 기초하는 경우 SW 정의 스토리지는 합리적인 선택이 아닐 수 있다는 조언이다.

세 번째 단계는 실행되는 애플리케이션의 수를 파악하는 것이다. 모놀리식 애플리케이션 하나를 주로 사용하는 경우 일반적으로 SW 정의 스토리지는 적합하지 않다. 그러나 다양한 애플리케이션이 혼재돼 있다면 도입할만한 가치가 있다는 설명이다.

네 번째는 비핵심 워크로드 또는 신규 애플리케이션부터 마이그레이션(전환)하는 것이다. 새로운 스토리지 플랫폼을 경험하고 확신을 얻으려면 혹시라도 모를 다운타임에 대비하기 위해 덜 중요한 애플리케이션부터 시작한다.

레드햇 측은 “최초 마이그레이션에서 가장 많은 문제점이 나타나므로, 처음에 다소 어려움이 발생하더라도 걱정할 필요는 없다”며 “마이그레이션 전략이 완벽하게 조율되고 프로세스가 표준화된 후에는 가장 중요한 애플리케이션도 훨씬 쉽게 이전할 수 있다”고 설명했다.

다섯 번째 단계는 워크로드 가상화 또는 클라우드화 여부를 결정하는 것이다. 애플리케이션을 실행할 환경이 물리적 서버, 가상화 환경, 퍼블릭 클라우드 중 어느 것인지, 이러한 구축 모델 중 두 가지 이상을 함께 사용하려는 경우 해당 모델을 지원하는 유연한 스토리지 플랫폼을 선택해야 한다. 그렇게 해야 서로 호환되지 않는 기술을 바탕으로 여러 스토리지 영역을 따로 관리하는 불편함을 피할 수 있다.

여섯 번째는 필요한 분석 체계를 판단해야 한다. 특히 회사에서 빅데이터 처리를 신속히 도입해야 하는 경우, 아파치 하둡 맵리듀스 구현과 같은 최신 데이터 분석 기술을 활용하는 SW 정의 스토리지 솔루션을 고려하는 것이 좋다. 이러한 도구를 구비하면 사일로 간에 정보 이동할 필요 없이 기존 애플리케이션의 데이터를 직접 저장 및 공유할 수 있다. 이를 통해 막대한 양의 데이터에서 보다 유용한 정보를 더욱 빠르게 추출할 수 있을 뿐 아니라, 기존 인프라의 활용 가치를 극대화해 IT 비용을 크게 절감할 수 있다.

그 다음에는 필요한 데이터 보호 및 복제 수준을 판단한다. 어떤 재해복구(DR) 시나리오를 고려해야 할지, 예상 비용과 각 시나리오에서 예상되는 결과는 무엇인지, 민감하지도, 중요하지도 않은 정보에 대한 불필요한 보안에 과잉 투자하지 않고 가장 중요한 데이터를 가장 안전하게 보호할 수 있는지 등이다.

마지막으로 데이터를 유지해야 하는 기간을 결정하는 것이다. 데이터를 실질적으로 필요한 것보다 오래 유지해야 하는 규정 요건이 없다면, 불필요해진 데이터를 삭제할 방법이 있어야 한다.

레드햇은 “SW 정의 스토리지는 협소하게 정의하더라도 기업의 환경, 비즈니스 요구 사항, 예산 등의 조건에 따라 다양한 형태를 취할 수 있다”며 “그러나 진정한 확장성을 염두에 두고 SW 정의 스토리지를 구축하려면 데이터 서비스를 내부 데이터 구조에서 분리해 보다 광범위한 워크로드에 대해 더 많은 서비스를 지원해야 한다”고 강조했다.

<백지영 기자>jyp@ddaily.co.kr