SAP "ERP도 인메모리DB에"…오라클 위협?

일반입력 :2012/06/29 15:51    수정: 2012/06/29 16:05

고성능 분석어플라이언스(HANA)에서 돌아가는 SAP ERP 6.0과 코어 애플리케이션을 제공할 계획이다. SAP ERP는 데이터베이스(DB)를 전통적인 관계형DB 대신 SAP HANA DB로 이전하는 2번째 SAP 제품이 될 것이다.

기업들이 조직의 중추인 ERP 시스템을 인메모리DB에 맡길 수 있을까. SAP는 최근 연내 HANA 인메모리DB 기술로 ERP를 돌릴 수 있게 만들거라 공언했다. 분명한 성능 이점에도 제한적으로 쓰여온 인메모리DB가 SAP라는 거대 기업용 소프트웨어(SW)를 통해 전사 기간계 인프라를 도맡는다면? 디스크기반 DB업계에서 독주해온 오라클의 아성을 위협하는 시나리오다.

디스크기반 DB보다 훨씬 빠른 인메모리DB가 광범위하게 쓰이지 않았던 배경은 주로 기술적 제약 때문이다. 메모리에 올라간 데이터들은 전력이 끊어지는 등 재난상황에 손실되기 쉬웠다. 그에 대비하려면 어차피 보조 저장장치를 써야 했다. 또 디스크에 비해 물리적 시스템당 저장용량을 늘리기에 한계가 있었다. 저장매체의 용량당 가격도 상대적으로 비쌌다.

SAP는 HANA 기술과 로드맵을 통해 기존 제약을 달리 볼 수 있음을 시사한다. 2분기 공개한 'SAP HANA 기술개요(Technical Overview)' 보고서에 따르면 회사는 'HANA 기반 SAP 넷위버 비즈니스웨어하우스(BW)' 출시의 후속 로드맵으로 HANA에서 돌아가는 'SAP ERP 6.0'과 코어 'SAP 비즈니스스위트 7.0' 애플리케이션도 제공한다고 예고했다. 또 SAP는 인메모리컴퓨팅기술의 모든 장점을 받아내기위해 비즈니스 애플리케이션 설계, 개발, 최적화에 새로운 과정을 밟기 시작했다고도 언급했다.

해당 보고서 작성자는 에릭 슈나이더 우수고객네트워크(PCN) 선임이사와 라가브 잔디얄라 SAP HANA플랫폼 솔루션 전문가다.

슈나이더 이사는 과거 내부 SAP프로그램 수석아키텍트로 회사 인메모리 컴퓨팅 기술을 사용해 세계 SAP 라인오브비즈니스(LOB)에 걸친 데이터와 비즈니스인텔리전스(BI) 아키텍처를 구현해온 인물로 소개됐다.

잔디얄라는 전략산업영역에 대해 SAP가 혁신을 추구하는 초기고객확보에 집중하는 SAP 고객솔루션도입(CSA) 그룹 소속이다. 그는 CSA 합류 전 SAP 뱅킹그룹 솔루션 매니저였고 당시 HANA를 위한 '고투마켓' 활동을 지원했다.

■HANA 어플라이언스와 HANA DB란 무엇인가

현재 소개에 따르면 HANA는 '실시간 분석과 애플리케이션 구동을 위한 플랫폼'이다. 이는 어플라이언스 형태로 배포되거나 클라우드를 통해 쓰일 수 있다. 여러 분절된 대용량 데이터를 기반으로 비즈니스 오퍼레이션을 분석하는 구조를 실현하는 기술이다.

전체 플랫폼은 백업, 복구, 데이터로드 서비스에 기반해 유지된다. HANA 플랫폼 안에 흔히 인메모리DB로 분류되는 'HANA DB'가 한 구성요소로 들었다. 이와 함께 HANA 스튜디오, 퍼시스턴트스토리지, SAP 엔터프라이즈 솔루션까지 4개 덩어리가 HANA 플랫폼을 이룬다.

이가운데 HANA DB는 '완전히 메인메모리에서 돌아가는 대규모 병렬 분산 데이터 관리 시스템'으로 요약된다. 행과 열 기반 저장구조 설정을 허용하며 내부적으로 멀티테넌시를 지원한다고 보고서는 묘사한다.

구체적으로 멀티코어 CPU, 대용량 메모리, 행열(Row and Column) 저장구조방식, 압축, 파티셔닝, 애그리게이션테이블과 가상 테이블인 '뷰' 구현 없음 등을 특징으로 한다. CPU와 메모리는 인메모리 특성상 디스크대비 빠른 속도와 연산 성능을 월등히 해준다. 행열저장구조는 기존 행기반보다 빠른 애그리게이션 속도가 빠른 열기반 DB의 장점을 만들어 준다. 파티셔닝은 대용량 데이터셋 분석과 복잡한 연산에 유리한 요소로 작용한다. 애그리게이션테이블과 구현되는 뷰가 없는 덕분에 데이터 중복이 없고 유연한 모델링이 가능한 장점을 보인다.

HANA DB와 디스크기반의 전통적인 DB는 어떻게 다를까.

기존 DB들은 제한된 메인메모리를 다뤄야 하는 하드웨어 특성상 그 성능을 최적화하는 데 설계 초점을 맞췄다. 이를테면 주된 병목지점인 디스크입출력(I/O) 액세스를 최적화하고 데이터를 처리중인 메인메모리에 읽히는 디스크페이지 숫자를 줄이는 게 관건이었다. 디스크기반 DB에서 데이터 갱신시 그 부분이 '잠금' 상태가 된다는 게 성능저하 요인으로 꼽힌다.

SAP HANA는 정보가 갱신되는 영역에 '입력전용 데이터레코드'를 쓰는 병렬화 기법으로 이 문제를 피했다. DB 테이블에서 새 레코드를 만드는 대신 컬럼에 저장된 기존 레코드에서 '델타'라 부르는 새 입력난을 삽입한다는 설명이다.

또 HANA DB는 열기반 데이터 저장구조를 씀에 따라 행기반의 전통적 DB에서 보기드문 압축률을 구현했다고 회사측은 강조한다. SAP가 한 고객사시스템을 분석했더니 고객사의 단일 재무DB테이블에 있는 속성가운데 10%만이 SQL구문으로 작성됐고, 전통적 관계형DB의 실제 액세스하는 데이터에 대한 스토리지 용량 35GB짜리를 열기반 저장구조로 설계시 기존 대비 2% 수준인 800MB로 줄일 수 있다는 결과를 얻었다고 보고서는 전한다.

■애플리케이션을 위한 인메모리DB

HANA 플랫폼은 기업용 애플리케이션 인프라 시장에서 SAP를 주요 업무용 DB 사업자로 키워줄 전략을 품었다. HANA DB가 돌아가는 하드웨어 인프라상의 이점, 기존 애플리케이션에 맞물릴 때 장점, 여기에 맞춰 새 애플리케이션을 만들 때 효과가 제시된다. 분산 서버 환경에서도 실행과 운영에 안전성을 보장하며 배포를 위한 현실적 어려움도 인증된 기술 파트너를 통해 지원 가능하다는 게 회사측 설명이다.

HANA DB는 우선 메모리 용량을 '충분히 쓸 수 있는 상황'을 전제로 설계됐다. 풀어 쓰면 x86 서버 64비트 시스템의 이론적인 메모리 용량 한계로 추정되는 '18엑사바이트(EB)' 또는 180억GB 공간, 그리고 하드디스크에 대한 I/O 액세스가 강제되지 않는 환경에서다. HANA는 하드디스크에 대한 I/O 액세스를 최적화하는 대신 CPU 캐시와 메모리 사이의 액세스를 최적화했다.

SAP는 HANA DB를 기업용 애플리케이션 플랫폼으로 쓸 경우 성능향상과 안정성 같은 직접적인 이득이 있음을 분명히 했다. 기술의 장점을 실현하기 위해 기업들이 치러야 할 비용도 상대적으로 크지 않다고 강조했다. 그에 따르면 HANA DB가 자랑하는 성능 향상 효과는 '오픈SQL'을 쓰는 기존 SAP 애플리케이션을 수정하지 않고도 발휘된다. 또 HANA 환경에서 개발돼 쓰이는 새 애플리케이션은 타 플랫폼에서보다 성능면에서 월등한 업무프로세스, 분석시나리오를 기대할 수 있단다.

또 HANA DB가 멀티코어 설계구조를 전제로 데이터 분산환경에 맞춘 관리 성능을 제공한다는 게 SAP의 주장이다. 데이터가 분산된 모든 코어 영역에서 수평적, 수직적 확장을 통해 메모리(RAM) '지역성'을 극대화한다는 것이다. 지역성이란 메모리에서 어떤 데이터나 명령이 처리될 때 같은 영역에 액세스가 거듭되거나(시간적 지역성) 그와 인접한 영역 데이터와 명령문을 액세스하는(공간적 지역성) 경우가 빈번함을 가리키는 현상이다.

HANA DB는 수평확장시나리오를 통해 한 클러스터에 다중 서버를 기반으로 돌아가기 때문에 단일서버 범주에 그치지 않는다. 이를 도입하는 기업들은 '라운드로빈', '해시', '레인지파티셔닝' 등을 따로 또 같이 쓰는 대규모 테이블을 다중 서버에 걸쳐 분산시킬 수 있다. 여러 서버에 걸쳐 쿼리를 실행하고 분산 트랜잭션의 안전성을 유지하는 기능도 갖췄다고 SAP는 밝혔다.

한편 SAP가 인증한 기술파트너들은 특정한 환경에 HANA를 배포할 수 있는 서버 컨피규레이션을 제공한다. 가능한 낮은 비용 조건에서 더 나은 CPU당 성능을 이루는 균형점을 위한 것이다. 이는 기업들이 데이터센터 운영비용을 낮추고 관리를 단순화시키면서 더 큰 메모리용량의 이점을 살리기 위한 것으로 요약된다.

■인메모리DB HANA, 장애 대응은 어떻게

HANA 플랫폼의 이중화 방식이나 HANA DB를 위한 백업 복구 프로세스는 어떻게 구현될까.

SAP는 HANA 구성시 동기 미러링 방식을 사용한 '핫스탠바이' 개념의 고가용성(HA) 시나리오를 제시한다. 여기에는 여분의 HANA DB 구성이 포함돼 있다. 통상적인 이중화는 실제 작동하는 메인 시스템과 평상시 쓰지 않는 '콜드스탠바이' 시스템으로 돼 있지만, HANA 플랫폼은 가동중인 시스템에 장애 발생시 자동 페일오버(작업전환)를 수행한다.

HANA DB도 전통적인 관계형DB가 지원하는 '원자성, 일관성, 독립성, 지속성(ACID)'을 충족한다. 또 갓 출시된 HANA는 단일 부서 규모의 데이터웨어하우스(DW)를 위한 온라인분석처리(OLAP) 플랫폼 정도로 이해됐지만 그 복구 기능은 OLAP뿐 아니라 온라인트랜잭션(OLTP) 환경에도 대응한다.

현재 가능한 복구 프로세스는 ▲최종 데이터 백업 복원 ▲최종 및 이전 데이터 백업 복원 ▲오류 이전 최종 상태 복원 ▲시점지정 복원이다. 앞서 언급한 SAP HANA 플랫폼 구성요소가운데 'HANA 스튜디오'가 제공하는 관리 콘솔을 통해 쓸 수 있다. 관리 콘솔은 SAP HANA와 비즈니스오브젝트(BO) 데이터서비스 모델을 위한 버전 통제 메커니즘을 구현한다. 관리자가 모델 백업과 복원에 쓰이는 XML 파일을 투입, 추출할 수 있다.

송해구 SAP코리아 전무는 단일 구성 HANA를 재가동시 인메모리 DB테이블에 남은 트랜잭션이 수행되고 전원장애가 발생한 이후라면 SSD기반 실시간백업스토리지에서 복원해내는데 약간의 로딩 지연이 생기는 정도며 성능이 민감한 시스템일 경우 HA 구성으로 (데이터 복원에 따른 로딩 지연이 줄도록) 이중화시켜 쓰면 된다고 설명했다.

HANA 초기 도입 시나리오는 시스템 재가동에 따른 데이터로드 성능 때문에 핵심업무를 돌리지 않는 경우 단일 프로덕션 구성환경에서 돌아갈 수 있다는 것이었다. 회사는 'SAP 랜드스케이프 트랜스포메이션'과 'SAP BO 데이터서비스' 환경을 기존 인프라와 나란히 쓰길 권장했다. 거대조직의 경우 SAP HANA는 표준적인 SAP 개발, 품질보증(QA)과 스테이징, 프로덕션 환경으로 돌아가야 할 필요가 있다.

여기서 SAP 랜드스케이프 트랜스포메이션은 SAP 기술과 회사측 것이 아닌 기술의 데이터소스를 테이블 수준까지 직접 실시간 통합해주는 SW다. 또다른 SW, SAP BO 데이터서비스는 SAP와 그쪽 것이 아닌 데이터소스를 거듭 다루는 모든 시나리오에 쓰인다. SAP 넷위버 BW 구성요소에서 읽어온 데이터도 포함한다. 시스템에 불러들인 데이터들은 HANA DB로 모인다.

■당장 쓸 수 있나

SAP는 HANA 플랫폼을 통해 3가지 데이터마트 타입을 제시한다. 그 DW 또는 넷위버 BW를 위한 구성을 위한 DB 활용법도 소개하고 있다. 최근 지원되기 시작한 애플리케이션 타입도 언급하고 있다. 자사 ERP 최신 릴리즈를 위한 DB 아키텍처는 한창 개발중인 모양이다. 미국서비스지만 하드웨어 구성을 통한 설치형 인프라뿐 아니라 클라우드를 통해서도 제공중이다. 내년쯤이면 코어 ERP를 HANA에 얹을 수 있게 된다.

SW어플라이언스로서의 SAP HANA는 증가하는 데이터량, 스토리지 중복, 연산속도, 정보 지연, 부가 데이터 애그리게이션 등 전통적 데이터마트 영역에 떠오른 문제에 해법을 제시한다.

실시간 운영상황 리포팅을 위한 '오퍼레이셔널 데이터마트'는 SAP 랜드스케이프 트랜스포메이션의 실시간 리플리케이션이나 SAP BO 데이터서비스의 ▲추출, 변환, 기록(ETL) 기반 운영시스템 ▲머신 생성 데이터 ▲고객 네트워크 데이터를 취한다. 기존 보유 데이터와 그 모델에 붙이기 위한 '애자일 LOB 데이터마트'는 SAP BO 데이터서비스 ETL로 SAP 넷위버 BW와 오라클, 테라데이타같은 '비SAP 전사적DW(EDW)'를 끌어온다. 기업의 EDW 계층 위에 얹히는 '아키텍티드 데이터마트'는 애자일 LOB 데이터마트와 유사한데 여러 소스 데이터를 지원한다.

이와 별개로 SAP HANA DB는 넷위버 BW에 연결시 시스템 가속에 주효하다. 이 시나리오에서 넷위버 비즈니스웨어하우스 기능의 예시는 ▲SAP 넷위버 BW 액셀러레이터 SW와 ▲새 SAP HANA '인포메이션 프로바이더'같은 애플리케이션 최적화를 꼽을 수 있다. 또 이 시나리오는 ▲넷위버용 SAP BO '계획 및 통합 애플리케이션'도 포함한다. 보고서에는 SAP 넷위버 BW 7.30 릴리즈에 딸린 지원패키지 5번에 전통적인 관계형DB에서 SAP HANA DB로 이전한 뒤 SAP 넷위버 BW 액셀러레이터의 개별 인스턴스 의존성을 제거해주는 기능이 있다고 쓰였다.

한편 SAP HANA는 '스위트 액셀러레이터'라 불리는 새 애플리케이션 종류를 지원한다. 간단히 말해 기존 디스크 기반 DB와 애플리케이션 인터페이스를 유지하면서 성능을 높이기 위한 제2의 DB로 HANA를 쓰는 것이다. 가속에 필요한 테이블 내용이 HANA DB에 복제돼 애플리케이션이 데이터를 읽을 땐 HANA DB에서 가져오게 된다. 이 방식으로 최초 공급된 SW는 SAP 'CO-PA 액셀러레이터'라고 회사측은 밝혔다.

송 전무는 특정 용도를 겨냥한 HANA 솔루션으로 ERP 병목을 없애기 위한 CO-PA 외에도 경영계획과 연결업무를 위한 HANA기반 BPC, 고객관계관리(CRM) 등 여러 제품이 이미 상용화됐다며 4TB 미만 용량으로 운영되는 국내 대부분의 DW 환경이나 ERP 단일 용도에 (HANA가) 무난하다고 말했다.

관련기사

보고서는 SAP HANA로 돌아가는 새 애플리케이션에 SAP 스마트미터 애널리틱스, SAP 다이나믹 캐시 매니지먼트, SAP 세일즈 앤드 오퍼레이션 플래닝 등을 더 소개했다.

지난주 외신들은 비샬 시카 SAP 최고기술책임자(CTO)가 HANA에 기반한 협력사들의 애플리케이션이 내년께 쏟아질 것이라며 SAP 비즈니스스위트의 코어 ERP 모듈을 (HANA 기반으로) 포팅하는 작업을 진행중인데 연내 정식판(GA)에 임박한 버전(RTC)을 계획했다는 발언을 보도한 바 있다.