MSA는 서비스 병행 운영을 추구한다
MSA 기술과 적용 연구 16
<MSA에서 정합성 보장은 어떻게 하나요?>편에 이어서 씁니다.
MSA가 N-티어이든 아니든 무슨 상관이 있는가? 그게 어떤 효용성이 있나? 이렇게 질문해볼 수 있다.
사용자 이벤트의 분산 처리해온 역사
앞선 분산 시스템의 기본 아키텍처 분류를 다시 보자.
가만히 보면 키보드 앞에서 입력을 하는 사용자가 인터페이스(UI)를 통해 사용자 이벤트를 분산해서 처리해온 진화처럼 보이기도 한다. 이때의 사용자 이벤트는 앞서 설명한 DDD의 도메인 이벤트와는 다르다. 반면, 마틴 파울러 정의 수준 수준에 보면 사용자 이벤트를 도메인 이벤트의 일부라 할 수도 있다. DDD 맥락이 아니라 보편적인 이벤트를 다루자면, 외부의 이벤트를 수용하여 컴퓨터에 명령을 내리는 프로그램으로 바꿔가는 일이 프로그래머의 일상적인 작업이다.
컴퓨터에서 프로그램을 처리하는 단위를 프로세스라고 부른다. 과거에는 프로그램이라고 하면 (논리적으로) 하나의 컴퓨터(실행 환경)에서 구동했다. 그런데 컴퓨터의 역할을 나누면서 클라아언트-서버(client–server) 형태로 분산이 일어나고, 다시 웹(WWW) 환경이 발전하면서 3-티어(three-tier ), N-티어와 같은 식의 분산이 일어난다.
다수의 컴퓨터에 역할을 나누면서 성능을 늘릴 수 있다. 하나의 컴퓨터보다는 다수의 컴퓨터를 연결하는 방식으로 동시 실행을 가능하게 하는 기술의 진보다.
서비스 운영의 분산
이제 기술 문제를 넘어서서 생각해보자. 컴퓨터의 사용 주체인 사람들이 분산 컴퓨팅을 해서 무엇을 얻으려고 하는지 생각해보자. 두 개의 팀이 서로 독립성을 가지면서 동시에 시너지를 낼 수 있도록 프로그램을 분산시킨다면 어떤 모양이 될까?
<나는 애자일이 싫다>편에서 인용한 그림이 떠오른다. Bounded Context를 하나의 팀으로 구현한 자기들의 언어를 가진 팀이 함께 일하는 방식을 도식화 한 그림이다. 비즈니스 실험이 가능한 단위다. 마이크로 서비스 아키텍처가 이상으로 추구할 만한 목표 그림일 수 있다.
출처: https://www.linkedin.com/in/vaughnvernon/detail/recent-activity/이제 n-티어가 아니라 MSA인 이유를 생각해볼 수 있다. 몇 개로 프로그램을 나누느냐는 상황에 따라 다르다. 다시 말해 n의 숫자가 중요하지 않다. 서비스가 중심에 등장한다. 그보다는 3-티어로 자꾸만 커지는 거대한 서비스를 나눠서 확장할 수 있는 아키텍처를 뜻하기 때문이다.
n-티어에 비해 MSA라는 말은 사회적인 표현이다. 기술을 다루는데 있어 조직의 문제 그리고 비즈니스를 포함하는 문제에 대한 용어이다. 따라서, 순수하게 기술 문제로 국한하는 순간 적절한 판단 근거를 확보하지 못한다. 이쯤에서 지난 글에 인용한 페친님의 해학이 담긴 경고(?)가 떠오른다.
이벤트의 시작과 끝
다시 최초의 질문을 떠올려보자. MSA에서 정합성 보장은 어떻게 하나요? 정합성을 논하려면 이벤트의 시작과 끝을 생각해보야야 한다. DDD를 잠시 잊고, 응용 프로그래밍의 발전사를 살펴보자. 현대적인 프로그래밍의 시작은 대부분 사용자 입력으로 시작한다. 게다가 그것이 도메인 이벤트든 사용자 이벤트든 이벤트는 컴퓨터가 처리하는 어떤 사건이라고 하면 시작과 끝이 기대한 대로 동작해야 한다. 이를 정합성이라고 해보자.
분산 프로그램 환경에서 이러한 정합성을 어떻게 구현할까? 클라아언트-서버(client–server) 아키텍처만 하더라도 대세는 트랜젝션 처리를 사용하는 방법이었다. 위키피디아 정의를 보자.
Transaction processing is information processing in computer science that is divided into individual, indivisible operations called transactions. Each transaction must succeed or fail as a complete unit; it can never be only partially complete.
트랜젝션(Transaction)이라고 부르는 특정 연산은 일부만 처리되는 일이 없도록 다 되거나 안 되거나 전체 결과를 하나로 묶어서 처리하는 식이다. 정합성을 보장하는 대신에 하나의 트랜젝션 처리가 수행되는 동안에 이 결과에 영향을 받는 다른 처리를 대기하고 있어야 한다. 이를 트레이드 오프라고 부른다.
데이터베이스 트랜젝션의 시대
데이터베이스 트랜젝션의 시대라는 말은 없다. 내가 처음 쓴 말이다. RDBMS의 시대라는 말은 있었나? 필자가 초보 개발자이던 시절에는 아직 오라클 DBMS에 대한 불신이 있었지만 이내 오라클 DB는 기업용 프로그램에서는 필수적인 솔루션이 되었다. 그리고 오라클이라는 회사는 전세계를 대표하는 기술회사 중 하나다. 이런 현상과 맞물려 트랜젝션 처리를 DBMS에 의존하는 시간이 오랫동안 펼쳐졌다.
많은 자바 개발자들이 선택이 아니라 필수로 쓰고 있기도 한 스프링(Spring) 프레임워크도 초기 효용성은 데이터베이스 자원(connection) 관리와 데이터베이스 트랜젝션 처리를 알아서 해주는 기능이라고 해도 과언이 아니었다.
데이터베이스 트랜젝션에 대한 위키피디아 정의를 보자.
A database transaction symbolizes a unit of work performed within a database management system (or similar system) against a database, and treated in a coherent and reliable way independent of other transactions.
가짜 MSA의 등장
이 시리즈의 시작에도 페친님의 해학 넘치는 사진이 있다. 자~ MSA라고 우기려면 무엇을 갖춰야 할까? 앞서 서비스의 분산 운영이 MSA의 이상이라고 주장했다. 그렇다면 사업이 잘되고, 필연적으로 팀원이 늘고, 다뤄야 하는 데이터가 늘어갈 때 어떻게 적절한 사이즈의 서비스 여러 개로 나눠서 운영할 수 있을까?
가장 명쾌한 방법은 독립적인 다수의 DB로 나눌 수 있으면 된다. DB를 나누지 않고 같은 DB를 쓰는 여러 개의 서비스를 만든다면 이는 명백한 가짜 MSA 라고 할 수 있고, 이런 일을 하자고 주장한 개발자 몇몇을 빼고는 회사와 다수의 동료들에게 피해를 끼치는 일이 될 가능성이 매우 높다.
나눠진 DB 사이의 트랜젝션 관리를 어떻게 하나요?
다양한 방법이 있다. 나에게 질문을 했던 분이 쓴 글에도 이를 처리하는 방법 중에 하나인 Saga 패턴을 소개하고 있다. 2PC는 필자가 낡은 기술이라 제외해야 한다고 주장했던 분산 트랜젝션 기술을 말한다. Saga 패턴 말고도 다양한 방법이 존재하기 때문에 여기서는 2PC와 이들 패턴을 구현하는 방식사이의 근본적인 차이에 대해서만 쓰는 것으로 한다.
출처: https://microservices.io/patterns/data/saga.html(다시 너무 길어져 다음 글로 나눕니다.)
