클라우드 네이티브 환경에서 DB는 어떻게 써야 하나

요즘 클라우드 네이티브 애플리케이션 개발에 대한 논의가 활발하다. 클라우드 친화적인 애플리케이션 구축에서 가장 큰 고민거리이면서, 가장 민감한 영역이 데이터다. 어떤 데이터베이스를 쓸 것이냐를 두고도 설왕설래 중이다. 

데이터 유형, 워크로드에 따라 단일 목적형 데이터베이스를 써야 한다는 입장과, 융합형 데이터베이스를 써야 한다는 입장으로 갈린다. 관계형 데이터베이스(RDB) 일변도였던 시대에서 다양한 DB 기술의 등장으로 딱 떨어지는 정답은 없어진 시대로 넘어오며 벌어지는 모습이다.

마이크로서비스 아키텍처의 유행에 따라 ‘폴리글랏’의 개념이 IT 시스템 전반에 빠르게 퍼졌다. 소스코드뿐 아니라 데이터도 분산해 개별로 운영하는 ‘폴리글랏 퍼시스턴스’는 MSA에서 자주 등장한다.

단일 목적형 DB는 하나 혹은 소수의 문제를 해결하기 위해 특별히 설계되고, 특정한 목적에 특화된다. 때문에 다수의 데이터베이스나 워크로드를 수용하는데 필요한 기능 절충에 타협할 필요가 없다. 목적에 적합한 편리한 데이터 메일을 활용하고 데이터 모델에 적용하기 용이한 API 채택이 가능하다. 적은 기능을 보유하므로 개발을 쉽게 시작할 수 있는 것 역시 장점이다.

이러한 단순성은 곧 단일 목적형 데이터베이스가 일부 기능은 훌륭하게 수행하지만, 다른 기능에는 취약함을 의미한다. 예를 들어, 여러 단일 목적형 데이터베이스를 사용하면 높은 확장성이라는 이점은 누릴 수 있지만, 데이터의 일관성은 매우 낮을 수 있다.

단일목적형 데이터베이스 이용 예시

반면, 융합형 데이터베이스는 모든 데이터 유형과 워크로드를 지원한다. 하나의 데이터베이스 내에서 공통 언어인 SQL과 표준 API 세트를 활용해 다양한 워크로드와 데이터 유형을 모두 뒷받침한다. 융합형 데이터베이스를 사용하는 조직은 여러 개의 시스템을 유지하거나 관리할 필요가 없으며, 서로 다른 시스템에 통합 보안을 제공하는 일을 걱정하지 않아도 된다.

데이터가 분산되지 않기 때문에 불필요한 데이터 복사본을 만들 필요도 없다. 애플리케이션 모듈과 서비스가 융합형 데이터베이스 내에서 하나의 공유 데이터를 사용하기 때문이다. 이를 통해 애플리케이션 코드가 한층 직관적으로 간단해지는 것은 덤이다. 데이터 전파로 인한 오류 또는 시간 지연에 따른 불편함도 겪지 않아도 된다.

융합형 데이터베이스의 경우 오랜 역사성을 내부에 갖고 있다. RDB에 객체지향DB,, XML, 컬럼스토어, 샤딩 등이 시간의 흐름에 따라 수용됐다. 많은 기능을 가지면서, RDB에서 가장 중요한 원자성, 일관성, 고립성, 지속성(ACID) 등을 지키도록 발전해왔다. ACID는 트랜잭션이 완전히 커밋됐거나 수행되지 않았음을 보증하고, 트랜잭션 완료 후 데이터가 업데이트될 것이란 것을 보증한다는 의미다.

한국오라클의 장성우 전무는 “RDB는 트랜잭션 커밋 후 절대 틀리지 않다는 것을 보증하고, 백업만 있으면 언제든 복원가능하게 하는 것을 기본 기능으로 한다”며 “새로운 유형 모두를 수용한다는 철학은 그런 안정성과 성능의 기반 위에서 돼야 하는 것이지, 이를 빼고 새 유형을 지원하는 건 실제 고객에게 의미없다고 판단했던 것”이라고 설명했다.

그는 “오라클의 DB는 30년간 누적된 역사를 갖고 있어 단기간에 구현할 수 없다”며 “특정 기능을 지원하는 몇가지 세트를 묶어 제공하는게 현실적 방법으로써 경쟁사나 오픈소스에서 선택한 단일목적형 DB”라고 덧붙였다.

단일 목적형과 융합형 모두 각자 일장일단을 갖고 있다. 사실 모든 환경에 맞는 정답은 없다. 각자의 특징을 정확히 이해하고 활용해야 한다는 게 전문가들의 공통된 의견이다. 일례로 비정형 데이터를 RDB보다 NoSQL이나 하둡에 담는게 낫다는 판단은 이제 매우 당연해진 얘기다.

장 전무는 “비즈니스 데이터처럼 값이 틀리거나 없어지면 비즈니스에 심대한 영향을 끼치는 데이터, 가령 계좌정보나 잔고, 고객정보, 생산정보, 통신사 콜데이터 등은 엄격한 트랜잭션 처리가 필요하다”며 “반면, 데이터가 망실되도 복구되는 백업, 여러 사용자가 공유해도 모두에게 동일하게 보이는 멀티 동시성 등이 요구되는 데이터라면 아무리 고비용이고, 많다해도 RDB에 담아야 한다”고 말했다.

그는 “반면에 웹 데이터나 센서, 로그 같이 하나하나의 중요성보다 엄청난 양이면서, 그 안에서 트렌드를 뽑아내는데 쓰는 데이터는 일부 사라져도 대세에 지장없는 저장소에 담아도 된다”며 “중요한 것은 단일 목적형이나 융합형이나 특성을 바꾸면 안 된다는 것”이라고 강조했다.

모노리식 아키텍처와 마이크로서비스 아키텍처의 데이터 구조 비교(사진: 마틴 파울러 블로그)

애플리케이션을 MSA로 설계할 때 데이터의 일관성은 업데이트 관리란 새 과제를 던진다.

마이크로서비스를 설명하는 마틴 파울러의 글에 의하면, 모노리식 아키텍처에서 많이 쓰이는 트랜잭션을 사용해 마이크로서비스의 일관성을 보장하게 되는데, 트랜잭션을 사용하면 임시적 결합을 강제하게 되고, 이 결합은 여러 서비스에 걸쳐 있는 어려운 과제다. 분산 트랜잭션은 구현하기 매우 까다로우며, MSA는 서비스 간의 트랜잭션 협조를 중요하게 본다. 영구적인 일관성만 충족시키고, 벌어지는 문제는 보상 작업으로 다룬다는 인식을 갖는다.

마틴 파울러는 “비일관성 관리를 선택하는 것은 많은 개발팀에게 새로운 도전이지만, 비지니스 현장에서는 잘 맞다”며 “종종 실무에서 오는 요구에 신속하게 반응해 모순을 하는데, 이때 오류에 대처하기 위해 어떤 역처리 방식이 있다”고 설명했다. 그는 “이러한 트레이드 오프를 통해 오류를 수정하는 비용이 일관성 하에서 사업 기회를 잃는 비용보다 더 가치가 있다”고 덧붙이고 있다.

융합형 데이터베이스 입장에서 보면 단일 목적형 데이터베이스는 SQL과 같은 ISO 표준 대신 고유한 API와 트랜잭션 모델을 활용하기 때문에, 개발 과정이 파편화되고 애플리케이션 또한 특정 DB에 종속된다. 융합형 데이터베이스는 분산된 데이터를 처리하고 이동할 필요 없이 확장된 SQL을 통해 머신러닝, 그래프, 공간 데이터, 블록체인, IoT 등 다양한 기능을 수행할 수 있다고 강조한다.

단일 목적형 데이터베이스는 프로젝트 시작 단계에서 필요한 것을 정확하게 얻을 수 있다는 점에서 만족스러운 옵션일 수 있다. 그러나, 장기적인 관점에서 단일 목적형 데이터베이스는 사용자에게 부담을 발생시키고 더욱 많은 비용을 초래할 수 있다.

프로젝트 수행 과정에서 예기치 않은 비즈니스 요구 사항은 늘 발생한다. 때문에 처음에 올바른 선택이었던 단일 목적형 데이터베이스의 효용가치는 갈수록 떨어진다는 게 융합형 데이터베이스 관점의 주장이다. 개발자는 새로운 요구 사항을 수용할 수 있는 또 다른 단일 목적형 데이터베이스를 처음부터 다시 사용할 수 있지만, 중간에 또 다른 변동 사항이 생기지 않는다는 보장은 없다. 기존의 단일 목적형 데이터베이스의 한계 내에서 해결책을 강구해낼 수도 있지만, 이러한 과정에서 최초의 애플리케이션 코드와 유지 관리가 불필요하게 복잡해진다.

조직이 처리해야 하는 데이터 형식이나 워크로드는 일반적으로 매우 방대하다. 다양한 비즈니스 애플리케이션을 모두 지원하기 위해 다수의 단일 목적형 데이터베이스를 활용할 경우, 데이터가 서로 다른 형식과 유형을 사용하는 데이터베이스에 분산되게 된다. 이는 곧 조직 내에서 여러 유형의 데이터를 관리하고, 보호하며 하나로 통합하는 일을 매우 복잡하게 만든다.

각각의 단일 목적형 데이터베이스는 별도의 관리 제어 기능, 보안 모델, 고가용성 아키텍처를 갖추고 있으며 서로 다른 데이터베이스 기술을 기반으로 한다. 공유 API가 없기 때문에 이러한 데이터베이스에서 데이터를 공유하거나 전파하는 것 역시 다소 까다롭다.

따라서, 단일 목적형 데이터베이스 접근법을 조직 전반에 걸쳐 실현하기 위해서는 험난한 통합 과정을 거쳐야 한다. 각 데이터베이스의 운영 방식을 잘 알고 있는 직원을 갖추고, 데이터베이스마다 보안 정책을 새롭게 구현해야 한다.

장성우 전무는 “클라우드 네이티브 애플리케이션의 핵심은 컨테이너와 쿠버네티스인데, 각 컨테이너가 개별 목적의 DB에 접속하는 경우가 많다”며 “이 때 쓰이는 게 샤딩이란 기술인데, 데이터가 너무 크면 한곳에 접속하는 게 비효율적이니 데이터를 쪼갠다는 개념”이라고 설명했다. 그는 “오라클도 12C부터 샤딩 기능을 통해 논리적으로 하나지만, 물리적으로 쪼개는 클라우드 네이티브 기능을 지원하고 있다”고 덧붙였다.

데이터베이스를 여러 종류로 쪼갤 경우 발생하는 또 다른 문제는 전사적 분석 요구 대응이다. 대기업의 경우 특히 자주 나타나는 요구인데, 중요한 의사결정을 위해 기업 내 모든 데이터를 모아 분석해야 하는 경우다. 업무, 부서, 파트 등마다 분산된 데이터가 언젠가는 모여야 하는 것이다.

장 전무는 “전사기준으로 보기 위해 별도 데이터 그릇을 만들어야 하는데, 엄청난 시간과 노력, 비용이 필요한 작업”이라며 “한 통에 대량의 데이터를 다 넣어도 일정 수준의 성능을 제공하는 건 현재로선 오라클밖에 대안이 없다”며 “모으는 것도 중요하지만 분석 쿼리를 날려 결과를 뽑는게 더 중요한데, 다양한 데이터를 저장하고 관리하면서 데이터 규모에 비해 빠른 쿼리 성능을 내야 하기 때문”이라고 강조했다.

융합형 DB 채택에 따른 비용 부담은 업계에 남은 인식이다. 오라클은 클라우드 서비스화를 통해 비용 장벽을 많이 허물었다는 입장이다. 예를 들어 오라클 자율운영 데이터베이스는 오라클 클라우드 프리티어(Free-Tier) 서비스의 일환으로 개발자에게 무료로 제공되며, 개발이나 사전 개발 과정에 낮은 시간당 요금으로 활용 가능하다.

그는 “오라클 같은 융합형이 모든 경우에 다 좋다는 게 아니라, RDB, NoSQL, 하둡 같은 것을 취사선택하도록 지원하고 있고, 데이터 증가에 따라 단일 DB의 장점이 커진 다는 것을 말하고 싶다”며 “오라클과 경쟁사의 전략 측면보다 데이터베이스 특성상 하나에서 할 때와 쪼갤 때 장단점이 극명히 다르다는 관점으로 봐야 한다”고 밝혔다.