2017.11.14

마이크로서비스용 데이터베이스 선택하기

Jeff Carpenter | InfoWorld

지난 10년 동안 대규모 분산 시스템이 폭발적으로 증가했다. 이에 따라 데이터베이스 분야에서도 소프트웨어 산업 역사상 전례 없을 만큼 창의적 기술이 쏟아져 나왔다. 그 결과 소비자의 선택을 기다리는 다양한 플랫폼이 존재하는 건강하고 경쟁적인 데이터베이스 시장이 됐다. 하지만 도대체 어떻게 선택을 해야 할까?

여기서는 애플리케이션에 맞는 데이터베이스 모델을 선택하는 방법을 중심으로 알아보자. 물론 모델은 여러 개일 수 있다. 또한 데이터 모델 선택이 데이터 계층에 포함할 기술을 결정하는 데 어떻게 도움이 되는지에 대해서도 살펴본다.

Image Credit : GettyImagesBank

클라우드 아키텍처, NoSQL, 마이크로서비스
소프트웨어 개발자가 웹 스케일 애플리케이션을 만들기 시작하자 오랜 기간 데이터 아키텍처를 지배해 온 관계형 데이터베이스는 큰 시련에 직면했다. 엄청나게 인기 있는 소셜 애플리케이션이 개발되고 점점 더 많은 기기가 사물 인터넷(IoT)에 연결되기 시작했다. 방대한 수의 클라이언트가 데이터를 읽고 쓰면서 데이터 계층을 확장할 필요성이 생겼고, 이와 같은 높은 확장성 요구를 충족하기 위해 새로운 데이터베이스가 등장했다.

많은 경우 이런 새 데이터베이스는 "NoSQL" 또는 "비관계형"이었다. 문서, 키-값, 컬럼 지향, 심지어 그래픽 데이터베이스 등 기존의 지배적인 관계형 모델 이외의 데이터 모델을 기반으로 한 솔루션이다. 이런 데이터베이스는 강력한 일관성과 ACID 트랜잭션, 조인과 같은 관계형 데이터베이스에서 보장되는 익숙한 여러 기능을 지원하지 않는 경우가 많았다.

데이터베이스 기술의 혁신과 동시에 2000년대 초반 SOA(서비스 지향 아키텍처) 추세가 마이크로서비스 아키텍처 스타일로 성숙화되고 많은 조직이 엔터프라이즈 서비스 버스(ESB)와 같은 무거운 SOA 인프라에서 벗어나 분산된 접근 방식을 취하기 시작했다. 마이크로서비스 아키텍처의 매력은 서비스를 독립적으로 개발, 관리, 확장할 수 있다는 점이다. 이는 데이터베이스와 같은 인프라 기술을 포함한 구현 선택권 측면에서 상당한 유연성을 부여한다.

예를 들어 확장성에 대한 요구가 클 것으로 예상되는 마이크로서비스 아키텍처를 위한 대규모 개발 작업을 진행 중이라고 가정해 보자. 프로젝트가 새 애플리케이션이든 기존 애플리케이션의 리팩터링이든 새로운 데이터베이스를 선택할 수 있는 기회가 제공된다.

다언어코드 지속성(Polyglot persistence)
마이크로서비스 스타일의 한 가지 핵심적인 이점은 지속성의 캡슐화다. 즉, 각 서비스의 필요에 따라 서로 다른 지속성 기술을 자유롭게 선택할 수 있다. 각 데이터 유형의 특징에 따라 데이터 저장소를 선택하는 접근 방법을 일컬어 다언어코드 지속성이라고 한다. 마틴 파울러를 비롯한 여러 사람이 사용해 대중화된 용어다. 다언어코드 지속성은 마이크로서비스와 찰떡궁합이다.

아래 그림은 일련의 마이크로서비스와 각 서비스에 대해 어떻게 서로 다른 데이터 모델을 사용하는지에 관한 예를 보여준다. 필자는 여기서 각 데이터베이스 유형에 대한 적절한 사용 사례를 모두 나열하려는 것이 아니다. 필자의 목적은 각 데이터베이스 유형의 강점과 다언어코드 방식이 매력적인 이유를 살펴보는 데 있다.



서비스 A를 개발 중인 팀은 대규모로 코어 애플리케이션 데이터를 관리하고 있으므로 아파치 카산드라를 사용하기로 선택한다. 예를 들어 소매 애플리케이션을 위한 인벤토리 데이터는 카산드라의 테이블 형식에 아주 잘 맞을 것이다. 카산드라는 풀 스케일 ACID 트랜잭션의 대안으로 튜닝 가능한 일관성, 배치, 가벼운 트랜잭션과 같은 코디네이션 메커니즘 툴박스를 제공한다.

서비스 B는 예를 들어 제품 카탈로그를 위한 설명 데이터와 같은 잘 알려진 키로 참조 값을 조회하는 아주 간단한 구문을 지원한다. 이는 제품 ID와 같은 잘 알려진 키 값으로 데이터 블롭(blob)을 조회하는 키-값 저장소를 위한 좋은 사례다. 많은 메모리 내 캐시는 키-값 데이터 모델을 사용해서 큰 규모에서 대단히 빠른 접근 속도를 지원한다.

서비스 C는 주로 페이지 웹 사이트 양식과 같은 반구조적 콘텐츠 서비스와 관련될 수 있는데, 이 데이터에는 문서 저장소가 적합하다. 문서 저장소는 키-값 스타일과 유사점이 많지만 한 가지 중요한 차이는 데이터에 구조를 부여한다는 것이다(예를 들어 빠른 검색을 지원하기 위해 특정 특성을 인덱싱하는 기능).

서비스 D는 고객 데이터와 같은 데이터, 그리고 조직 내 다양한 부서와 고객의 접촉 내역 간 관계와 같은 복잡한 관계를 탐색하는 데 사용된다. 여기에는 다른 서비스에서 소유한 데이터 유형 간의 관계가 연관될 가능성이 있다. 이는 위에서 언급한, 서비스가 개별 데이터 유형을 소유한다는 제약을 강제하기 시작한다는 면에서 흥미로운 경우다. 서비스가 기반 테이블에 대해 읽기 전용 접근 권한을 가진 그래프를 생성한 다음 원하는 변형을 "앞문", 즉 해당 데이터 유형을 "소유"한 다른 서비스의 API에 대한 호출을 통해 이동시킬 수 있다.


마지막으로, 관계형 기술을 사용하는 레거시 시스템 또는 서비스가 있거나 볼륨이 작은 데이터를 관리하는 서비스, 또는 자주 바뀌지 않는 데이터가 있다. 이런 사용 사례에는 관계형 데이터베이스로 충분하다.

개별 서비스가 다언어코드여야 하는가?
복수의 데이터베이스 위에 위치하는 서비스를 설계하는 것도 가능하다. 예를 들어 키-값 저장소를 인덱스로 사용하고 호텔 이름과 ID를 매핑하고 호텔에 대한 설명 데이터를 카산드라의 테이블 형식에 저장하는 호텔 서비스를 생성할 수 있다.



이름-ID 매핑은 비정규화된 설계 방법을 사용하여 카산드라에서도 똑같이 구현이 가능하다. 이 경우 이름-ID 매핑을 유지하기 위해 별도의 테이블이 사용된다. 스토리지 사용량은 조금 더 높지만 별도의 키-값 저장소 관리에 따른 운영 복잡성이 없다.

이것이 일반적인 필자의 권장 사항이다. 즉, 가능하다면 주어진 마이크로서비스에서 항상 하나의 데이터 모델과 데이터베이스를 고수하는 것이다. 하나의 서비스를 두 개의 서로 다른 데이터베이스 위에 올려야겠다는 생각이 든다면 그 서비스의 범위가 너무 커지지 않을지 여부를 고려하라. 서비스를 작은 서비스로 분할하는 편이 더 바람직할 수도 있다.

다언어코드 지속성의 한계와 타협
다언어코드 지속성의 가장 큰 단점은 초기 개발과 운영, 두 가지 측면 모두에서 여러 기술을 지원하는 데 따르는 비용이다.

주 개발 비용은 각각의 새로운 데이터베이스 기술에 대한 개발자 교육 비용이다. 특히 개발자가 팀을 자주 바꾸는 유동적인 환경에서는 이 비용이 상당히 커질 수 있다.

또 다른 요소는 여러 데이터베이스를 지원하기 위한 운영 비용이다. 데이터베이스 관리가 중앙에 집중되고 팀이 여러 기술 분야에서 높은 역량을 유지해야 하는 경우 문제가 될 수 있다. 그러나 개발 팀이 프로덕션에서 선택한 데이터베이스를 지원해야 하는 진정한 데브옵스 환경에서는 별 문제가 되지 않을 수도 있다.

다중 모델 데이터베이스
데이터베이스 업체들은 다언어코드 지속성 접근 방법의 대안 또는 보완책으로 다중 모델 데이터베이스를 구축해 홍보하기 시작했다. "모델"이라는 용어는 데이터 저장소가 제공하는 기본 추상화를 나타낸다. 예를 들어 테이블 형식(관계형 및 비 관계형 모두), 컬럼 저장소, 키-값, 문서 또는 그래프 등이 있다. 다중 모델 애플리케이션은 두 가지 이상의 데이터 저장소 유형을 사용하는 애플리케이션이며 다중 모델 데이터베이스는 두 가지 이상의 추상화를 지원하는 데이터베이스라고 생각하면 된다.

데이터스택스 엔터프라이즈(DataStax Enterprise, DSE)는 카산드라의 분할된 행 저장소(테이블 형식) 모델과 이를 바탕으로 구축된 그래프 추상화를 지원하므로(DSE 그래프) 다중 모델 데이터베이스의 예다. 또한 아래 그림에서 볼 수 있듯이 코어 모델을 기반으로 자기만의 키-값과 문서 스타일 추상화를 간단히 구축할 수 있다. 이 방법을 통해 위에서 말한 다언어코드 접근 방법을 수정, 모든 서비스에 하나의 기반 데이터베이스를 활용하면서 별도의 키 공간을 사용해 다른 서비스가 소유한 데이터 사이에 명확한 경계를 유지할 수 있다.



어떻게 작동하는지 살펴보면 다음과 같다.

- 테이블 형식 : 서비스 A와 같은 주 애플리케이션은 카산드라 쿼리 언어(CQL)를 사용해 DSE 코어와 직접 상호작용할 수 있다.
- 키-값 : 카산드라의 아파치나 데이터스택스 배포판에서는 명시적인 키-값 API를 제공하지 않지만 서비스 B와 같은 서비스는 테이블 설계에서 키와 값 열만 지원하도록 강제함으로써 카산드라를 키-값 저장소로 이용할 수 있다. 예를 들면 다음과 같다.


CREATE TABLE hotel.hotels (
key uuid PRIMARY KEY,
value text); // or if you prefer, “blob”


- 문서 : 카산드라는 JSON 문서 측면에서 문서 스타일 상호 작용을 지원한다. 서비스 C와 같은 서비스에서 이를 사용할 수 있다. 카산드라는 테이블을 위한 스키마를 요구하므로 일반적으로 문서 데이터베이스의 특징인 새 컬럼을 즉석에서 정의하는 임의 JSON을 삽입할 수 없다.

- 그래프 : 서비스 D와 같이 고도로 상호 연결된 데이터를 지원하는 서비스에 적합한 DSE 그래프는 DSE 코어를 기반으로 구축된 확장 가능한 그래프 데이터베이스다. DSE 그래프는 아파치 팅커팝(TinkerPop) 프로젝트의 강력한 그렘린(Gremlin) API를 지원한다.

다중 모델 데이터베이스의 장점과 한계
다중 모델 데이터베이스에 투자할지(또는 이미 구축한 데이터베이스 다중 모델 기능을 사용할지) 여부를 고려한다면 위에 논의한 다언어코드 지속성 접근 방법과 관련된 개발 및 운영 비용을 감안해야 한다.

다중 모델 데이터베이스를 사용하면 운영의 간편함 측면에서 도움이 될 수 있다. 다양한 개발 팀이 서로 다른 API를 사용하고 서로 다른 백 엔드 데이터베이스 플랫폼과의 상호작용 모드를 사용해야 하지만 관리해야 할 플랫폼이 하나라는 측면에서 효율성을 얻게 된다.

다중 모델 데이터베이스를 선택할 때 고려해야 할 한 가지는 다양한 모델을 지원할 방법이다. 일반적인 접근 방법은 하나의 기반 네이티브 모델을 바탕으로 한 데이터베이스 엔진을 두고 그 위에 다른 모델 층을 두는 형태로 구성된다. 계층화된 데이터 모델에는 기반이 되는 주 모델의 특징이 나타나는 경향이 있다.

예를 들어 쏘우트웍스 테크놀로지 레이더 16호(ThoughtWorks Technology Radar Vol. 16)에서는 DSE 그래프가 카산드라 위에 계층화된 그래프 모델로서 나타내는 특징 및 이와 관련된 타협에 대해 다음과 같이 설명했다.

“카산드라를 기반으로 하는 DSE 그래프는 오랜 강자 Neo4j가 한계를 보이고 있는 부분인 대용량 데이터 집합에서 유용하다. 이 스케일에 따라 타협해야 하는 점도 있다. 예를 들어 런타임 스키마로부터 자유로운 Neo4j의 특징과 ACID 트랜잭션을 잃게 된다. 그러나 기반 카산드라 테이블, 분석 워크로드를 위한 스파크 통합, 강력한 팅커팝/그렘린 쿼리 언어를 감안하면 충분히 고려할 만한 옵션이다.”

웹스케일 애플리케이션에서 다양한 데이터 유형을 고려하다 보면 데이터 유형마다 일관성 요건이 다르며, 실제로 즉각적인 일관성을 요구하는 데이터 유형의 수는 비교적 적다는 사실을 발견하게 된다.

위 인용문을 보면 다중 모델에서는 다양한 모델 및 엔진 간의 통합과 상호작용, 그리고 데이터 접근을 위한 다양한 운영 및 분석 사용 사례가 중요한 고려 사항임을 알 수 있다. DSE는 분석 용도로 스파크를 통해 그래프 데이터에 접근하는 기능(DSE 애널리틱스(DSE Analytics))을 지원하며 DSE 서치(DSE Search)는 카산드라에 저장된 데이터에 대한 다양한 검색 인덱스 생성 기능을 제공한다.
 


4단계로 보는 마이크로서비스 데이터 모델
지금까지 다언어코드 및 다중 모델 접근 방법의 이점에 대해 살펴봤는데, 그렇다면 대규모 마이크로서비스 애플리케이션에 사용할 데이터 모델을 결정할 때는 어떻게 해야 할까? 다음 단계에 따르면 된다.

1. 애플리케이션의 주 데이터 유형을 파악하고 각각에 대한 서비스를 만들어 각 서비스에 서비스 자체의 지속성에 대한 통제력을 부여한다. 가능한 경우 모든 서비스에 다중 모델 데이터베이스를 활용하여 서비스에서 데이터와 상호작용할 때 다양한 모델을 선택할 수 있도록 한다.

2. 웹 수준 확장성과 가용성을 위해 테이블 형식 표현(DSE 코어)을 주 모델로 사용하고 키-값과 문서 구문을 필요에 따라 그 위에 계층으로 구성한다. 운영 및 분석 사용 사례에서 데이터에 접근하는 다양한 방법을 고려하여 분석 데이터 센터로의 복제 및 검색 인덱스와 같은 기능을 어떻게 사용할지 미리 계획한다.

3. 고도의 관계형 데이터, 특히 엔터티 간 관계의 특성 수가 엔터티 자체와 동일하거나 더 많은 경우, 또는 동일한 엔터티 간 여러 관계를 캡처해야 하는 경우 그래프 표현(DSE 그래프)을 사용한다

4. 변경할 필요가 없다면 관계형/SQL 기술에 대한 기존 투자를 보존한다. 예를 들어 사용 사례에서 큰 규모, 낮은 지연 및 고가용성이 필요 없는 경우가 해당된다.

애플리케이션에서 어떤 방법으로, 어느 부분에서 복수 모델을 지원할지, 그리고 언제 다중 모델 데이터베이스 사용을 고려해야 할지에 대해 생각할 때 이 글이 유용한 틀이 되기를 바란다.

*Jeff Carpenter는 데이터스택스(DataStax)의 기술 에반젤리스트로, 시스템 아키텍처, 마이크로서비스, 아파치 카산드라에서 쌓은 지식을 이용해 개발자와 운영 엔지니어가 분산 시스템을 구축하는 일을 돕고 있다. Cassandra: The Definitive Guide, 2nd Edition의 저자이다. editor@itworld.co.kr
2017.11.14

마이크로서비스용 데이터베이스 선택하기

Jeff Carpenter | InfoWorld

지난 10년 동안 대규모 분산 시스템이 폭발적으로 증가했다. 이에 따라 데이터베이스 분야에서도 소프트웨어 산업 역사상 전례 없을 만큼 창의적 기술이 쏟아져 나왔다. 그 결과 소비자의 선택을 기다리는 다양한 플랫폼이 존재하는 건강하고 경쟁적인 데이터베이스 시장이 됐다. 하지만 도대체 어떻게 선택을 해야 할까?

여기서는 애플리케이션에 맞는 데이터베이스 모델을 선택하는 방법을 중심으로 알아보자. 물론 모델은 여러 개일 수 있다. 또한 데이터 모델 선택이 데이터 계층에 포함할 기술을 결정하는 데 어떻게 도움이 되는지에 대해서도 살펴본다.

Image Credit : GettyImagesBank

클라우드 아키텍처, NoSQL, 마이크로서비스
소프트웨어 개발자가 웹 스케일 애플리케이션을 만들기 시작하자 오랜 기간 데이터 아키텍처를 지배해 온 관계형 데이터베이스는 큰 시련에 직면했다. 엄청나게 인기 있는 소셜 애플리케이션이 개발되고 점점 더 많은 기기가 사물 인터넷(IoT)에 연결되기 시작했다. 방대한 수의 클라이언트가 데이터를 읽고 쓰면서 데이터 계층을 확장할 필요성이 생겼고, 이와 같은 높은 확장성 요구를 충족하기 위해 새로운 데이터베이스가 등장했다.

많은 경우 이런 새 데이터베이스는 "NoSQL" 또는 "비관계형"이었다. 문서, 키-값, 컬럼 지향, 심지어 그래픽 데이터베이스 등 기존의 지배적인 관계형 모델 이외의 데이터 모델을 기반으로 한 솔루션이다. 이런 데이터베이스는 강력한 일관성과 ACID 트랜잭션, 조인과 같은 관계형 데이터베이스에서 보장되는 익숙한 여러 기능을 지원하지 않는 경우가 많았다.

데이터베이스 기술의 혁신과 동시에 2000년대 초반 SOA(서비스 지향 아키텍처) 추세가 마이크로서비스 아키텍처 스타일로 성숙화되고 많은 조직이 엔터프라이즈 서비스 버스(ESB)와 같은 무거운 SOA 인프라에서 벗어나 분산된 접근 방식을 취하기 시작했다. 마이크로서비스 아키텍처의 매력은 서비스를 독립적으로 개발, 관리, 확장할 수 있다는 점이다. 이는 데이터베이스와 같은 인프라 기술을 포함한 구현 선택권 측면에서 상당한 유연성을 부여한다.

예를 들어 확장성에 대한 요구가 클 것으로 예상되는 마이크로서비스 아키텍처를 위한 대규모 개발 작업을 진행 중이라고 가정해 보자. 프로젝트가 새 애플리케이션이든 기존 애플리케이션의 리팩터링이든 새로운 데이터베이스를 선택할 수 있는 기회가 제공된다.

다언어코드 지속성(Polyglot persistence)
마이크로서비스 스타일의 한 가지 핵심적인 이점은 지속성의 캡슐화다. 즉, 각 서비스의 필요에 따라 서로 다른 지속성 기술을 자유롭게 선택할 수 있다. 각 데이터 유형의 특징에 따라 데이터 저장소를 선택하는 접근 방법을 일컬어 다언어코드 지속성이라고 한다. 마틴 파울러를 비롯한 여러 사람이 사용해 대중화된 용어다. 다언어코드 지속성은 마이크로서비스와 찰떡궁합이다.

아래 그림은 일련의 마이크로서비스와 각 서비스에 대해 어떻게 서로 다른 데이터 모델을 사용하는지에 관한 예를 보여준다. 필자는 여기서 각 데이터베이스 유형에 대한 적절한 사용 사례를 모두 나열하려는 것이 아니다. 필자의 목적은 각 데이터베이스 유형의 강점과 다언어코드 방식이 매력적인 이유를 살펴보는 데 있다.



서비스 A를 개발 중인 팀은 대규모로 코어 애플리케이션 데이터를 관리하고 있으므로 아파치 카산드라를 사용하기로 선택한다. 예를 들어 소매 애플리케이션을 위한 인벤토리 데이터는 카산드라의 테이블 형식에 아주 잘 맞을 것이다. 카산드라는 풀 스케일 ACID 트랜잭션의 대안으로 튜닝 가능한 일관성, 배치, 가벼운 트랜잭션과 같은 코디네이션 메커니즘 툴박스를 제공한다.

서비스 B는 예를 들어 제품 카탈로그를 위한 설명 데이터와 같은 잘 알려진 키로 참조 값을 조회하는 아주 간단한 구문을 지원한다. 이는 제품 ID와 같은 잘 알려진 키 값으로 데이터 블롭(blob)을 조회하는 키-값 저장소를 위한 좋은 사례다. 많은 메모리 내 캐시는 키-값 데이터 모델을 사용해서 큰 규모에서 대단히 빠른 접근 속도를 지원한다.

서비스 C는 주로 페이지 웹 사이트 양식과 같은 반구조적 콘텐츠 서비스와 관련될 수 있는데, 이 데이터에는 문서 저장소가 적합하다. 문서 저장소는 키-값 스타일과 유사점이 많지만 한 가지 중요한 차이는 데이터에 구조를 부여한다는 것이다(예를 들어 빠른 검색을 지원하기 위해 특정 특성을 인덱싱하는 기능).

서비스 D는 고객 데이터와 같은 데이터, 그리고 조직 내 다양한 부서와 고객의 접촉 내역 간 관계와 같은 복잡한 관계를 탐색하는 데 사용된다. 여기에는 다른 서비스에서 소유한 데이터 유형 간의 관계가 연관될 가능성이 있다. 이는 위에서 언급한, 서비스가 개별 데이터 유형을 소유한다는 제약을 강제하기 시작한다는 면에서 흥미로운 경우다. 서비스가 기반 테이블에 대해 읽기 전용 접근 권한을 가진 그래프를 생성한 다음 원하는 변형을 "앞문", 즉 해당 데이터 유형을 "소유"한 다른 서비스의 API에 대한 호출을 통해 이동시킬 수 있다.


마지막으로, 관계형 기술을 사용하는 레거시 시스템 또는 서비스가 있거나 볼륨이 작은 데이터를 관리하는 서비스, 또는 자주 바뀌지 않는 데이터가 있다. 이런 사용 사례에는 관계형 데이터베이스로 충분하다.

개별 서비스가 다언어코드여야 하는가?
복수의 데이터베이스 위에 위치하는 서비스를 설계하는 것도 가능하다. 예를 들어 키-값 저장소를 인덱스로 사용하고 호텔 이름과 ID를 매핑하고 호텔에 대한 설명 데이터를 카산드라의 테이블 형식에 저장하는 호텔 서비스를 생성할 수 있다.



이름-ID 매핑은 비정규화된 설계 방법을 사용하여 카산드라에서도 똑같이 구현이 가능하다. 이 경우 이름-ID 매핑을 유지하기 위해 별도의 테이블이 사용된다. 스토리지 사용량은 조금 더 높지만 별도의 키-값 저장소 관리에 따른 운영 복잡성이 없다.

이것이 일반적인 필자의 권장 사항이다. 즉, 가능하다면 주어진 마이크로서비스에서 항상 하나의 데이터 모델과 데이터베이스를 고수하는 것이다. 하나의 서비스를 두 개의 서로 다른 데이터베이스 위에 올려야겠다는 생각이 든다면 그 서비스의 범위가 너무 커지지 않을지 여부를 고려하라. 서비스를 작은 서비스로 분할하는 편이 더 바람직할 수도 있다.

다언어코드 지속성의 한계와 타협
다언어코드 지속성의 가장 큰 단점은 초기 개발과 운영, 두 가지 측면 모두에서 여러 기술을 지원하는 데 따르는 비용이다.

주 개발 비용은 각각의 새로운 데이터베이스 기술에 대한 개발자 교육 비용이다. 특히 개발자가 팀을 자주 바꾸는 유동적인 환경에서는 이 비용이 상당히 커질 수 있다.

또 다른 요소는 여러 데이터베이스를 지원하기 위한 운영 비용이다. 데이터베이스 관리가 중앙에 집중되고 팀이 여러 기술 분야에서 높은 역량을 유지해야 하는 경우 문제가 될 수 있다. 그러나 개발 팀이 프로덕션에서 선택한 데이터베이스를 지원해야 하는 진정한 데브옵스 환경에서는 별 문제가 되지 않을 수도 있다.

다중 모델 데이터베이스
데이터베이스 업체들은 다언어코드 지속성 접근 방법의 대안 또는 보완책으로 다중 모델 데이터베이스를 구축해 홍보하기 시작했다. "모델"이라는 용어는 데이터 저장소가 제공하는 기본 추상화를 나타낸다. 예를 들어 테이블 형식(관계형 및 비 관계형 모두), 컬럼 저장소, 키-값, 문서 또는 그래프 등이 있다. 다중 모델 애플리케이션은 두 가지 이상의 데이터 저장소 유형을 사용하는 애플리케이션이며 다중 모델 데이터베이스는 두 가지 이상의 추상화를 지원하는 데이터베이스라고 생각하면 된다.

데이터스택스 엔터프라이즈(DataStax Enterprise, DSE)는 카산드라의 분할된 행 저장소(테이블 형식) 모델과 이를 바탕으로 구축된 그래프 추상화를 지원하므로(DSE 그래프) 다중 모델 데이터베이스의 예다. 또한 아래 그림에서 볼 수 있듯이 코어 모델을 기반으로 자기만의 키-값과 문서 스타일 추상화를 간단히 구축할 수 있다. 이 방법을 통해 위에서 말한 다언어코드 접근 방법을 수정, 모든 서비스에 하나의 기반 데이터베이스를 활용하면서 별도의 키 공간을 사용해 다른 서비스가 소유한 데이터 사이에 명확한 경계를 유지할 수 있다.



어떻게 작동하는지 살펴보면 다음과 같다.

- 테이블 형식 : 서비스 A와 같은 주 애플리케이션은 카산드라 쿼리 언어(CQL)를 사용해 DSE 코어와 직접 상호작용할 수 있다.
- 키-값 : 카산드라의 아파치나 데이터스택스 배포판에서는 명시적인 키-값 API를 제공하지 않지만 서비스 B와 같은 서비스는 테이블 설계에서 키와 값 열만 지원하도록 강제함으로써 카산드라를 키-값 저장소로 이용할 수 있다. 예를 들면 다음과 같다.


CREATE TABLE hotel.hotels (
key uuid PRIMARY KEY,
value text); // or if you prefer, “blob”


- 문서 : 카산드라는 JSON 문서 측면에서 문서 스타일 상호 작용을 지원한다. 서비스 C와 같은 서비스에서 이를 사용할 수 있다. 카산드라는 테이블을 위한 스키마를 요구하므로 일반적으로 문서 데이터베이스의 특징인 새 컬럼을 즉석에서 정의하는 임의 JSON을 삽입할 수 없다.

- 그래프 : 서비스 D와 같이 고도로 상호 연결된 데이터를 지원하는 서비스에 적합한 DSE 그래프는 DSE 코어를 기반으로 구축된 확장 가능한 그래프 데이터베이스다. DSE 그래프는 아파치 팅커팝(TinkerPop) 프로젝트의 강력한 그렘린(Gremlin) API를 지원한다.

다중 모델 데이터베이스의 장점과 한계
다중 모델 데이터베이스에 투자할지(또는 이미 구축한 데이터베이스 다중 모델 기능을 사용할지) 여부를 고려한다면 위에 논의한 다언어코드 지속성 접근 방법과 관련된 개발 및 운영 비용을 감안해야 한다.

다중 모델 데이터베이스를 사용하면 운영의 간편함 측면에서 도움이 될 수 있다. 다양한 개발 팀이 서로 다른 API를 사용하고 서로 다른 백 엔드 데이터베이스 플랫폼과의 상호작용 모드를 사용해야 하지만 관리해야 할 플랫폼이 하나라는 측면에서 효율성을 얻게 된다.

다중 모델 데이터베이스를 선택할 때 고려해야 할 한 가지는 다양한 모델을 지원할 방법이다. 일반적인 접근 방법은 하나의 기반 네이티브 모델을 바탕으로 한 데이터베이스 엔진을 두고 그 위에 다른 모델 층을 두는 형태로 구성된다. 계층화된 데이터 모델에는 기반이 되는 주 모델의 특징이 나타나는 경향이 있다.

예를 들어 쏘우트웍스 테크놀로지 레이더 16호(ThoughtWorks Technology Radar Vol. 16)에서는 DSE 그래프가 카산드라 위에 계층화된 그래프 모델로서 나타내는 특징 및 이와 관련된 타협에 대해 다음과 같이 설명했다.

“카산드라를 기반으로 하는 DSE 그래프는 오랜 강자 Neo4j가 한계를 보이고 있는 부분인 대용량 데이터 집합에서 유용하다. 이 스케일에 따라 타협해야 하는 점도 있다. 예를 들어 런타임 스키마로부터 자유로운 Neo4j의 특징과 ACID 트랜잭션을 잃게 된다. 그러나 기반 카산드라 테이블, 분석 워크로드를 위한 스파크 통합, 강력한 팅커팝/그렘린 쿼리 언어를 감안하면 충분히 고려할 만한 옵션이다.”

웹스케일 애플리케이션에서 다양한 데이터 유형을 고려하다 보면 데이터 유형마다 일관성 요건이 다르며, 실제로 즉각적인 일관성을 요구하는 데이터 유형의 수는 비교적 적다는 사실을 발견하게 된다.

위 인용문을 보면 다중 모델에서는 다양한 모델 및 엔진 간의 통합과 상호작용, 그리고 데이터 접근을 위한 다양한 운영 및 분석 사용 사례가 중요한 고려 사항임을 알 수 있다. DSE는 분석 용도로 스파크를 통해 그래프 데이터에 접근하는 기능(DSE 애널리틱스(DSE Analytics))을 지원하며 DSE 서치(DSE Search)는 카산드라에 저장된 데이터에 대한 다양한 검색 인덱스 생성 기능을 제공한다.
 


4단계로 보는 마이크로서비스 데이터 모델
지금까지 다언어코드 및 다중 모델 접근 방법의 이점에 대해 살펴봤는데, 그렇다면 대규모 마이크로서비스 애플리케이션에 사용할 데이터 모델을 결정할 때는 어떻게 해야 할까? 다음 단계에 따르면 된다.

1. 애플리케이션의 주 데이터 유형을 파악하고 각각에 대한 서비스를 만들어 각 서비스에 서비스 자체의 지속성에 대한 통제력을 부여한다. 가능한 경우 모든 서비스에 다중 모델 데이터베이스를 활용하여 서비스에서 데이터와 상호작용할 때 다양한 모델을 선택할 수 있도록 한다.

2. 웹 수준 확장성과 가용성을 위해 테이블 형식 표현(DSE 코어)을 주 모델로 사용하고 키-값과 문서 구문을 필요에 따라 그 위에 계층으로 구성한다. 운영 및 분석 사용 사례에서 데이터에 접근하는 다양한 방법을 고려하여 분석 데이터 센터로의 복제 및 검색 인덱스와 같은 기능을 어떻게 사용할지 미리 계획한다.

3. 고도의 관계형 데이터, 특히 엔터티 간 관계의 특성 수가 엔터티 자체와 동일하거나 더 많은 경우, 또는 동일한 엔터티 간 여러 관계를 캡처해야 하는 경우 그래프 표현(DSE 그래프)을 사용한다

4. 변경할 필요가 없다면 관계형/SQL 기술에 대한 기존 투자를 보존한다. 예를 들어 사용 사례에서 큰 규모, 낮은 지연 및 고가용성이 필요 없는 경우가 해당된다.

애플리케이션에서 어떤 방법으로, 어느 부분에서 복수 모델을 지원할지, 그리고 언제 다중 모델 데이터베이스 사용을 고려해야 할지에 대해 생각할 때 이 글이 유용한 틀이 되기를 바란다.

*Jeff Carpenter는 데이터스택스(DataStax)의 기술 에반젤리스트로, 시스템 아키텍처, 마이크로서비스, 아파치 카산드라에서 쌓은 지식을 이용해 개발자와 운영 엔지니어가 분산 시스템을 구축하는 일을 돕고 있다. Cassandra: The Definitive Guide, 2nd Edition의 저자이다. editor@itworld.co.kr
X