SAP HANA 란 무엇일까 - 3. 기술적 입장

안녕하세요. SAP 운영자 ST03 입니다.

오늘은 제가 기술자 여서 할 말이 많은 SAP HANA 의 기술적인 의미를 보고자 합니다.

객관적인 사실과 더불어 개인적인 의견과 사심도 가득 들어가 있으니 읽으실 때 감안 하고 보시면 좋겠습니다.

#1 새로운 Database Management System 의 등장

기존에 Oracle 을 필두로 한 DBMS 시장에서 새로운 경쟁자가 나타난 것은 기술자로서, System Architect 으로써 굉장히 즐거운 일 이라고 생각 됩니다. (안 그러신 분들도 계시겠지만요) In-Memory Database 라고 하는 알듯말듯 아리송한 컨셉으로 등장 한 SAP HANA Database 는 In-Memory Database 라는 이름값 만큼 기존 Database 와는 많이 다른 기능들을 보유하고 있습니다.

Column 형의 데이터 적재 방식과 이를 가능하게 하는 Main-Delta Area 의 운영. 이를 통합 해 주고 데이터를 압축하여 In-Memory 형태로 데이터를 관리하게 해 주기 위해 필수적인 역할을 하는 Delta Merge 등 기존의 다른 DB 운영과 다른 컨셉을 가지고 접근해야 한다는 점이 매우 흥미롭습니다.

#2 기술적 의미

In-Memory Database 라는 점으로 인해 많은 것들이 가능해진 HANA Database 는 아래와 같은 기술적인 특장점을 가지고 있습니다.

- Column 형태의 테이블. HANA 에서 Row 형태의 테이블을 가지지 못한 다는 것은 아니지만, In-Memory Database 로써 가능해진 가장 큰 기술적 특징으로 생각 됩니다. 테이블이 Row 단위로 저장되지 않고 Column 형태로 저장됨에 따라 데이터 압축의 극대화와 분석 속도 향상에 기여합니다.

- Data Replication / Transfer 의 유연함. Column 테이블은 많은 곳에서 이야기 하고 그 외의 특징들 (속도 향상, 분석 기능, 병렬 처리 등) 도 다 Column 테이블로 인해 나오는 장점들 입니다. 개인적으로 생각하기에 HANA 의 특장점은 Data 의 실시간 전송 및 전달의 효율화라고 생각 됩니다. 이는 In-Memory Database 이기 때문에 실시간으로 데이터가 변경되는 중에서도 이를 빠른 속도로 처리하고 정말 '실시간 정보 동기화' 를 만들어 냅니다. 자신의 데이터를 commit 과 함께 디스크에 쓰는 다른 Database 들과 달리 HANA Database 는 이런 점에 있어서 보다 자유롭다고 보여집니다. (그렇다고 HANA 가 디스크에 쓰지 않는다는 것은 아닙니다) 지금과 같이 월/분기/연 단위로 결산 (데이터 freezing) 을 하고 그 단위로 돌아가는 비즈니스 환경에서는 큰 의미가 없지만, 실시간으로 비즈니스 변화를 필요로 하고 향후 AI, IoT, Blockchain 과 같은 대용량 실시간 데이터의 관리가 필요하다고 하면 큰 의미를 가진다고 생각 됩니다.

거꾸로 보자면 이런 In-Memory Database 라는 태생 상의 단점도 가지고 있습니다.

- 하드웨어 장비 가격의 상승. 이전과 비교해서 IT 의 하드웨어 가격이 많이 감소 했다고는 하지만, 현재 시점에서 Database 도입의 측면만 보자면 HANA Database 가 다른 전통적인 RDBMS 에 비해 메모리 가격이 많이 나올 수 밖에 없습니다. Cloud 인프라로 옮기는 등의 방법을 취한다고 해도 다른 서비스들은 가상화의 형태로 구동할 수 있는 것에 비해 HANA 서비스는 물리서버로 밖에 구동 할 수 밖에 없는 경우가 많기 때문에 기존 처럼 하드디스크만 추가하면 계속 운영 할 수 있었던 다른 서비스들과 달리 보다 운영에 대한 고도의 방법론이 필요하게 될 것 입니다.

- 서버 자원의 경합과 이로 인한 서비스 불안정. 메모리라고 하는 영역은 모든 컴퓨터의 프로그램이 수행되기 위해 반드시 사용해야 하는 영역 입니다. HANA 이 부분에 대용량의 데이터를 올려놓고 상시 사용하는데 이는 다른 서비스들과의 경합을 유발할 수 밖에 없고 이 경합 대상이 Operation System 이 된다면 시스템 자체의 불안정성이 증가 할 수 밖에 없는 결과를 낳습니다. HANA 가 2.0 버전이 되면서 많은 안정화가 이루어졌고 아직 발전해야 할 영역이 많기 때문에 계속해서 안정화가 되겠지만, 이 부분은 앞으로도 계속하여 잠재적인 리스크로 남아 있을 수 밖에 없을 것 같습니다.

#3 앞으로 더 발전했으면 좋겠습니다만, 지금도 많은 장점을 가진 솔루션

필자는 HANA 1.0 SP10 때에 접하기 시작해서 지금은 2.0 SP03 까지 만지고 있지만 처음에 불안불안했던 모습과는 달리 빠른 속도로 발전되고 안정화가 되면서 이제는 back-end 시스템의 DB 로 쓸 수 있을 정도로 발전 한 것 같습니다.

아직은 물론 아쉬운 부분이 많습니다. ABAP 과는 달리 Thread 형태로 프로세스가 관리되다 보니 이슈가 발생 했을 때 조치나 상세한 로그가 잘 남지 않는다는 점, 이슈를 다룰 때 일정부분보다 깊게 들어가면 HANA 개발자들만의 영역으로 들어가 버리고 사용자는 그 이슈나 사유에 대해 명확하게 설명을 듣지 못 한다는 점, Tenant 형태로 운영 할 때 replication 또는 take-over 할 때 개별 tenant 별로 넘어가지 못 하고 System Tenant 가 통째로 되는 점 등...향후 개선될 여지는 있지만 여전히 아쉬운 점 들 입니다.

하지만 Docker 나 AI, IoT 등 신기술이나 Open Source 에 개방적으로 접근하고 (이전에 SAP 에서는 보지 못했던 개방적인 마인드...!) Cloud 서비스에 적극적으로 참여하면서 앞으로 더 많은 가능성을 보여주고 있어서 앞으로가 기대되는 솔루션이다.

사실 오라클을 비롯한 기존 시장의 상용 DB 들에 비해 역사가 짧은데 비해 오라클과 비교되는 것은 비즈니스용 DB 로써 어찌보면 당연하지만 어찌보면 대단한 일이라고 생각 합니다. 얼른 더 많이 개발이 되어서 비교되는 대상이 아닌, SAP 용 DB 가 아닌 하나의 Database 로써 평가받을 수 있기를 바랍니다.