2021.06.25

마이크로서비스에서 데이터를 중앙화하면 안 되는 3가지 이유

Lee Atchison | InfoWorld
마이크로서비스 아키텍처는 최신 애플리케이션과 시스템에서 일반적으로 사용하는 개발 모델이다. 대형 애플리케이션의 비즈니스 책임을 분할해 독자적으로 개발, 관리, 운영, 확장할 수 있는 별개의 구성요소로 만드는 것이 장점이다.

마이크로서비스 아키텍처는 애플리케이션 자체를 확장하기에 효과적인 모델을 제공한다. 상대적으로 크고 분리된 팀이 대규모 애플리케이션을 함께 만들면서도 각자 부분을 독자적으로 작업할 수 있다. 일반적인 마이크로서비스 아키텍처에서는 비즈니스 로직의 구체적인 하위집합을 아우르는 개별 서비스가 생성된다. 마이크로서비스 전체를 연결하면 비즈니스 로직이 포함된 완전한 대형 애플리케이션이 된다.

이러한 모델은 코드 작성에는 매우 좋지만 데이터에는 어떨까. 특정 비즈니스 로직을 위해 개별 서비스를 만드는 경우 많은 개발자가 애플리케이션 데이터 전체를 중앙집중화해 데이터 저장소 한곳에 모아야 한다고 생각한다. 즉, 각 서비스에 필요할지 모를 데이터를 모두 이용할 수 있게 해 두자는 것이다. 이렇게 한 곳에 모인 데이터 저장소는 관리하기 쉽고 간편하다. 또한, 데이터 모델링도 애플리케이션이 사용 중인 서비스와 관계없이 전체 애플리케이션이 사용하기에 일관성을 가질 수 있다.

그러나 이런 장점에도 불구하고 이렇게 하면 안 된다. 데이터를 중앙 집중화했을 때의 문제를 3가지로 정리했다.
 

중앙집중화된 데이터는 확장하기 어렵다

전체 애플리케이션에 대한 데이터가 중앙집중화된 한 곳의 저장소에 있으면, 애플리케이션이 커질 때 애플리케이션 내의 모든 서비스의 수요를 맞추기 위해 전체 데이터저장소를 확장해야 한다. 이러한 상황은 <그림 1>의 왼쪽이다. 그러나 <그림 1>의 오른쪽을 보면 서비스마다 별도의 데이터저장소를 사용하는 것이 더 낫다는 것을 알 수 있다. 수요가 늘어난 서비스만 확장하면 되고 확장되는 데이터베이스는 비교적 작은 데이터베이스다. 결국 작은 데이터베이스를 크게 확장하는 것이 큰 데이터베이스를 더 크게 확장하기보다 훨씬 쉽다.
 
<그림 1> 서비스를 기준으로 분할된 데이터는 확장하기 더 쉽다. © IDG
 

중앙집중화된 데이터는 나중에 분할하기 어렵다

새로 앱을 만드는 개발자는 '확장에 대해서는 지금 걱정할 필요가 없고 나중에 필요해질 때 걱정하면 된다'고 생각하기 쉽다. 그러나 이러한 관점은 최악의 상황에서 확장 문제를 부닥치는 지름길이다. 애플리케이션의 인기가 높아져 늘어나는 사용자 수요를 맞추기 위해서라도 아키텍처를 신중하게 결정해야 한다.

흔히 언급되는 아키텍처 변경은 데이터 저장소를 여러 개의 작은 데이터 저장소로 분할해야 한다는 것이다. 이러한 분할 작업은 애플리케이션이 생애주기에서 나중에 생성되는 것보다 먼저 생성된 경우에 하기가 훨씬 쉽다는 점이 중요하다. 애플리케이션이 몇 년 지나고 나면 애플리케이션의 모든 부분이 데이터의 모든 부분에 접근하게 되며, 데이터 집합의 어떤 부분을 해당 데이터를 사용하는 코드를 대대적으로 다시 작성하지 않고도 별도의 데이터 저장소로 분할할 수 있을지 판단하기가 매우 어려워진다.

어떤 서비스가 프로파일 테이블을 사용하는지, 시스템 테이블과 프로젝트 테이블을 둘 다 필요로 하는 서비스가 있는지 등과 같은 간단한 문제마저도 어려워진다. 두 테이블을 다 사용해 조인을 수행하는 서비스가 있는지, 어떤 목적에 사용되는지, 코드 내 어느 부분에서 실시되는지, 그 변경사항을 어떻게 리팩터링 할 수 있는지 등의 문제는 한층 더 어렵다.

데이터 집합이 한 곳의 데이터저장소에 머무르는 기간이 길어질수록 해당 데이터 저장소를 나중에 작은 부분으로 나누는 것이 더 어려워진다. 데이터를 기능별로 별도의 데이터 저장소로 분할해 두면 나중에 연결된 테이블로부터 데이터를 분리하는 것과 관련된 문제를 피할 수 있다. 또한, 코드 내에 예상치 못한 데이터 간의 상관관계가 존재할 가능성도 줄어든다.
 

중앙집중화된 데이터는 데이터 소유권을 침해한다

데이터를 여러 서비스로 나누는 장점 가운데 하나는 애플리케이션 소유권을 분리 가능한 별도의 부분으로 나눌 수 있다는 것이다. 개별 개발팀이 애플리케이션 소유권을 갖는 것은 조직적 확장과 문제 발생 시 대응 등의 측면에서 오늘날 애플리케이션 개발의 가장 중요한 원칙 중 하나다.

이 소유권 모델은 단일팀 지향 서비스 아키텍처(STOSA) 개발 모델에서도 중요하게 거론된다. 이 모델은 다수의 개발팀이 대형 애플리케이션에 모두 기여하는 경우에 효과가 가장 좋지만 상대적으로 작은 팀이 작업하는 작은 애플리케이션에도 도움이 된다.

문제는 팀이 서비스의 소유권을 가지려면 해당 서비스의 코드와 데이터를 모두 소유해야 한다는 것이다. 한 서비스(서비스 A)가 다른 서비스(서비스 B)의 데이터에 직접 접근해서는 안 된다는 의미다. 서비스 A가 서비스 B에 저장된 데이터가 필요하면 직접 접근하는 대신 서비스 B에 대한 서비스 진입점을 호출해야 한다. 이렇게 하면 서비스 B는 데이터의 저장 방식과 유지 관리 방식 등 데이터에 대한 완전한 자율권을 갖게 된다.
 
<그림 2> 서비스 A는 서비스 B의 데이터에 직접 접근해서는 안 된다. © IDG

그렇다면 대안은 무엇인가. 서비스 지향 아키텍처(SOA)다. SOA를 구성할 때 각 서비스는 자체 데이터를 소유해야 한다. 데이터는 서비스의 일부이며 서비스 내에 포함된다.
 
<그림 3> 각 서비스가 자체 데이터를 소유해야 한다. © IDG

그런 식으로 서비스 소유자는 해당 서비스에 대한 데이터를 관리할 수 있다. 데이터에 스키마 변경이나 다른 구조 변경이 필요하면 서비스 소유자는 다른 서비스 소유자를 개입시키지 않고도 변경 작업을 할 수 있다. 애플리케이션과 관련 서비스가 커짐에 따라, 서비스 소유자는 늘어난 부하와 변경된 요건을 처리하기 위한 확장과 데이터 리팩토링에 대한 결정을 할 때 다른 서비스 소유자를 전혀 개입시키지 않고 내릴 수 있다.

애플리케이션 간에 반드시 공유되어야 하는 데이터는 어떤가 하는 문제가 자주 등장한다. 사용자 프로필 데이터 등 애플리케이션의 여러 부분에 걸쳐 흔하게 사용되는 데이터가 대표적이다. <그림 4>처럼 여러 서비스에 걸쳐 필요한 데이터만 공유하면 빠르게 해결될 수 있다. 서비스마다 각자의 데이터가 있을 수 있고 공유된 데이터에 대한 접근권도 있을 수 있다.
 
<그림 4> 서비스 간 데이터 공유는 지양하는 것이 좋다. © IDG

하지만 더 좋은 방법은 <그림 5>다. 모든 서비스에서 사용하는 새로운 서비스에 공유된 데이터를 넣는 것이다. 단, 이때 새 서비스(서비스 C)도 STOSA 요건을 따라야 한다. 특히, 서비스를 소유하기에 공유된 데이터도 소유하는 분명한 단일팀이 있어야 한다.
 
<그림 5> 공유 데이터에 접근하는 더 좋은 방법은 서비스를 이용하는 것이다. © IDG

<그림 5>에서 서비스 A 또는 서비스 B 같은 다른 서비스가 공유된 데이터에 접근해야 하는 경우에는 서비스 C가 제공하는 API를 통해야 한다. 이렇게 하면 서비스 C의 소유자가 공유된 데이터를 책임지는 유일한 팀이 되고 확장, 리팩토링, 업데이트에 관한 적절한 의사결정을 내릴 수 있다. 서비스 A와 서비스 B가 사용할 일관성 있는 API를 유지하기만 하면 서비스 C는 데이터 업데이트에 대해 필요한 어떤 의사결정도 할 수 있다.

다시 <그림 4>를 보면 정 반대 상황인 것을 알 수 있다. 서비스 A와 서비스 B가 공유된 데이터에 직접 접근한다. 이 모델에서는 어떤 한 팀도 데이터의 구조, 레이아웃, 확장, 모델링에 대한 의사 결정을 해당 데이터에 직접 접근하는 다른 모든 팀을 개입시키지 않고서는 내릴 수 없다. 따라서, 애플리케이션 개발 프로세스의 확장성이 제한된다.

정리하면, 마이크로서비스나 다른 SOA를 사용하면 대형 애플리케이션 작업을 하는 대형 개발팀을 관리하기에 매우 좋다. 그러나 서비스 아키텍처가 애플리케이션의 데이터까지 고려해야 한다. 그렇지 않으면 진정한 서비스 독립성(따라서, 진정한 개발 조직의 확장 독립성)은 불가능하다. editor@itworld.co.kr


2021.06.25

마이크로서비스에서 데이터를 중앙화하면 안 되는 3가지 이유

Lee Atchison | InfoWorld
마이크로서비스 아키텍처는 최신 애플리케이션과 시스템에서 일반적으로 사용하는 개발 모델이다. 대형 애플리케이션의 비즈니스 책임을 분할해 독자적으로 개발, 관리, 운영, 확장할 수 있는 별개의 구성요소로 만드는 것이 장점이다.

마이크로서비스 아키텍처는 애플리케이션 자체를 확장하기에 효과적인 모델을 제공한다. 상대적으로 크고 분리된 팀이 대규모 애플리케이션을 함께 만들면서도 각자 부분을 독자적으로 작업할 수 있다. 일반적인 마이크로서비스 아키텍처에서는 비즈니스 로직의 구체적인 하위집합을 아우르는 개별 서비스가 생성된다. 마이크로서비스 전체를 연결하면 비즈니스 로직이 포함된 완전한 대형 애플리케이션이 된다.

이러한 모델은 코드 작성에는 매우 좋지만 데이터에는 어떨까. 특정 비즈니스 로직을 위해 개별 서비스를 만드는 경우 많은 개발자가 애플리케이션 데이터 전체를 중앙집중화해 데이터 저장소 한곳에 모아야 한다고 생각한다. 즉, 각 서비스에 필요할지 모를 데이터를 모두 이용할 수 있게 해 두자는 것이다. 이렇게 한 곳에 모인 데이터 저장소는 관리하기 쉽고 간편하다. 또한, 데이터 모델링도 애플리케이션이 사용 중인 서비스와 관계없이 전체 애플리케이션이 사용하기에 일관성을 가질 수 있다.

그러나 이런 장점에도 불구하고 이렇게 하면 안 된다. 데이터를 중앙 집중화했을 때의 문제를 3가지로 정리했다.
 

중앙집중화된 데이터는 확장하기 어렵다

전체 애플리케이션에 대한 데이터가 중앙집중화된 한 곳의 저장소에 있으면, 애플리케이션이 커질 때 애플리케이션 내의 모든 서비스의 수요를 맞추기 위해 전체 데이터저장소를 확장해야 한다. 이러한 상황은 <그림 1>의 왼쪽이다. 그러나 <그림 1>의 오른쪽을 보면 서비스마다 별도의 데이터저장소를 사용하는 것이 더 낫다는 것을 알 수 있다. 수요가 늘어난 서비스만 확장하면 되고 확장되는 데이터베이스는 비교적 작은 데이터베이스다. 결국 작은 데이터베이스를 크게 확장하는 것이 큰 데이터베이스를 더 크게 확장하기보다 훨씬 쉽다.
 
<그림 1> 서비스를 기준으로 분할된 데이터는 확장하기 더 쉽다. © IDG
 

중앙집중화된 데이터는 나중에 분할하기 어렵다

새로 앱을 만드는 개발자는 '확장에 대해서는 지금 걱정할 필요가 없고 나중에 필요해질 때 걱정하면 된다'고 생각하기 쉽다. 그러나 이러한 관점은 최악의 상황에서 확장 문제를 부닥치는 지름길이다. 애플리케이션의 인기가 높아져 늘어나는 사용자 수요를 맞추기 위해서라도 아키텍처를 신중하게 결정해야 한다.

흔히 언급되는 아키텍처 변경은 데이터 저장소를 여러 개의 작은 데이터 저장소로 분할해야 한다는 것이다. 이러한 분할 작업은 애플리케이션이 생애주기에서 나중에 생성되는 것보다 먼저 생성된 경우에 하기가 훨씬 쉽다는 점이 중요하다. 애플리케이션이 몇 년 지나고 나면 애플리케이션의 모든 부분이 데이터의 모든 부분에 접근하게 되며, 데이터 집합의 어떤 부분을 해당 데이터를 사용하는 코드를 대대적으로 다시 작성하지 않고도 별도의 데이터 저장소로 분할할 수 있을지 판단하기가 매우 어려워진다.

어떤 서비스가 프로파일 테이블을 사용하는지, 시스템 테이블과 프로젝트 테이블을 둘 다 필요로 하는 서비스가 있는지 등과 같은 간단한 문제마저도 어려워진다. 두 테이블을 다 사용해 조인을 수행하는 서비스가 있는지, 어떤 목적에 사용되는지, 코드 내 어느 부분에서 실시되는지, 그 변경사항을 어떻게 리팩터링 할 수 있는지 등의 문제는 한층 더 어렵다.

데이터 집합이 한 곳의 데이터저장소에 머무르는 기간이 길어질수록 해당 데이터 저장소를 나중에 작은 부분으로 나누는 것이 더 어려워진다. 데이터를 기능별로 별도의 데이터 저장소로 분할해 두면 나중에 연결된 테이블로부터 데이터를 분리하는 것과 관련된 문제를 피할 수 있다. 또한, 코드 내에 예상치 못한 데이터 간의 상관관계가 존재할 가능성도 줄어든다.
 

중앙집중화된 데이터는 데이터 소유권을 침해한다

데이터를 여러 서비스로 나누는 장점 가운데 하나는 애플리케이션 소유권을 분리 가능한 별도의 부분으로 나눌 수 있다는 것이다. 개별 개발팀이 애플리케이션 소유권을 갖는 것은 조직적 확장과 문제 발생 시 대응 등의 측면에서 오늘날 애플리케이션 개발의 가장 중요한 원칙 중 하나다.

이 소유권 모델은 단일팀 지향 서비스 아키텍처(STOSA) 개발 모델에서도 중요하게 거론된다. 이 모델은 다수의 개발팀이 대형 애플리케이션에 모두 기여하는 경우에 효과가 가장 좋지만 상대적으로 작은 팀이 작업하는 작은 애플리케이션에도 도움이 된다.

문제는 팀이 서비스의 소유권을 가지려면 해당 서비스의 코드와 데이터를 모두 소유해야 한다는 것이다. 한 서비스(서비스 A)가 다른 서비스(서비스 B)의 데이터에 직접 접근해서는 안 된다는 의미다. 서비스 A가 서비스 B에 저장된 데이터가 필요하면 직접 접근하는 대신 서비스 B에 대한 서비스 진입점을 호출해야 한다. 이렇게 하면 서비스 B는 데이터의 저장 방식과 유지 관리 방식 등 데이터에 대한 완전한 자율권을 갖게 된다.
 
<그림 2> 서비스 A는 서비스 B의 데이터에 직접 접근해서는 안 된다. © IDG

그렇다면 대안은 무엇인가. 서비스 지향 아키텍처(SOA)다. SOA를 구성할 때 각 서비스는 자체 데이터를 소유해야 한다. 데이터는 서비스의 일부이며 서비스 내에 포함된다.
 
<그림 3> 각 서비스가 자체 데이터를 소유해야 한다. © IDG

그런 식으로 서비스 소유자는 해당 서비스에 대한 데이터를 관리할 수 있다. 데이터에 스키마 변경이나 다른 구조 변경이 필요하면 서비스 소유자는 다른 서비스 소유자를 개입시키지 않고도 변경 작업을 할 수 있다. 애플리케이션과 관련 서비스가 커짐에 따라, 서비스 소유자는 늘어난 부하와 변경된 요건을 처리하기 위한 확장과 데이터 리팩토링에 대한 결정을 할 때 다른 서비스 소유자를 전혀 개입시키지 않고 내릴 수 있다.

애플리케이션 간에 반드시 공유되어야 하는 데이터는 어떤가 하는 문제가 자주 등장한다. 사용자 프로필 데이터 등 애플리케이션의 여러 부분에 걸쳐 흔하게 사용되는 데이터가 대표적이다. <그림 4>처럼 여러 서비스에 걸쳐 필요한 데이터만 공유하면 빠르게 해결될 수 있다. 서비스마다 각자의 데이터가 있을 수 있고 공유된 데이터에 대한 접근권도 있을 수 있다.
 
<그림 4> 서비스 간 데이터 공유는 지양하는 것이 좋다. © IDG

하지만 더 좋은 방법은 <그림 5>다. 모든 서비스에서 사용하는 새로운 서비스에 공유된 데이터를 넣는 것이다. 단, 이때 새 서비스(서비스 C)도 STOSA 요건을 따라야 한다. 특히, 서비스를 소유하기에 공유된 데이터도 소유하는 분명한 단일팀이 있어야 한다.
 
<그림 5> 공유 데이터에 접근하는 더 좋은 방법은 서비스를 이용하는 것이다. © IDG

<그림 5>에서 서비스 A 또는 서비스 B 같은 다른 서비스가 공유된 데이터에 접근해야 하는 경우에는 서비스 C가 제공하는 API를 통해야 한다. 이렇게 하면 서비스 C의 소유자가 공유된 데이터를 책임지는 유일한 팀이 되고 확장, 리팩토링, 업데이트에 관한 적절한 의사결정을 내릴 수 있다. 서비스 A와 서비스 B가 사용할 일관성 있는 API를 유지하기만 하면 서비스 C는 데이터 업데이트에 대해 필요한 어떤 의사결정도 할 수 있다.

다시 <그림 4>를 보면 정 반대 상황인 것을 알 수 있다. 서비스 A와 서비스 B가 공유된 데이터에 직접 접근한다. 이 모델에서는 어떤 한 팀도 데이터의 구조, 레이아웃, 확장, 모델링에 대한 의사 결정을 해당 데이터에 직접 접근하는 다른 모든 팀을 개입시키지 않고서는 내릴 수 없다. 따라서, 애플리케이션 개발 프로세스의 확장성이 제한된다.

정리하면, 마이크로서비스나 다른 SOA를 사용하면 대형 애플리케이션 작업을 하는 대형 개발팀을 관리하기에 매우 좋다. 그러나 서비스 아키텍처가 애플리케이션의 데이터까지 고려해야 한다. 그렇지 않으면 진정한 서비스 독립성(따라서, 진정한 개발 조직의 확장 독립성)은 불가능하다. editor@itworld.co.kr


X