2017.11.13

마이크로서비스를 위한 데이터베이스 선택 방법

Jeff Carpenter | InfoWorld

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

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

Image Credit : GettyImagesBank

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

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

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

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

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

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



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

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

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


2017.11.13

마이크로서비스를 위한 데이터베이스 선택 방법

Jeff Carpenter | InfoWorld

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

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

Image Credit : GettyImagesBank

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

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

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

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

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

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



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

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

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


X