MSA에서 정합성 보장은 어떻게 하나요?
MSA 기술과 적용 연구 15
<분산 트랜젝션 대신에 도메인 이벤트 MSA 패턴>편을 올리고 나서 페메로 받은 질문이다.
먼저 당장 도움이 될만한 답은 개발자인 베터코드 동료의 글을 알려주는 것이다: MSA에서 메시징 트랜잭션 처리하기
MSA는 정말 필요한가? 누구에게 필요한가?
한편 질문을 받은 시점과 비슷한 시기에 페북에서 아래 글을 보았다. 페친의 의도를 정확히 알 수는 없지만, MSA가 시간 낭비를 초래할 수 있다는 말에 동의한다. (후발주자의 시간 낭비를 위해 고안한 것이라 생각하지 않지만)
내가 동의하고 웃겨요를 누른 이유는 재미있는 풀이라고 글을 해학으로 받아들여서다. MSA 구조를 고안한 팀은 최초에 이런 형태로 시스템을 구성했을 때는 그에 합당한 이유가 있었을 것이다. 당연하게도 그 이전에는 존재하지도 않았던 MSA 적용이 목적이 아니었을 것이다. 부르는 이름도 없었을 것 아닌가?
아무튼 그렇게 구조가 만들어지고 난 후를 생각해보자. 서비스를 만든 기업과 여기 참여한 개발자는 이해(interest)와 욕망이 다르다. 쉽게 말해 개발자는 자랑을 하고 싶고, 어쩌면 자신이 만든 프로그램을 더 잘 다듬고 싶어진다. 어떤 형태로 펼쳐지던 MSA를 탄생(?)시킨 개발자는 그에 대한 믿음(혹은 집착)을 버리기 어렵다.
실제로 나는 자신이 만든 프로그램 구조를 전파하기 위해 컨설팅 회사를 차리거나 책을 쓰거나 오픈소스를 만드는 서양 개발자들을 여럿 보아왔다. 그런 이들이 MSA라는 이름을 만들고 매력적으로 만들고 있을 가능성이 매우 높다. 대표적인 인물이 바로 microservices.io를 운영하는 Chris Richardson 아닌가?
그는 MSA로 돈을 번다. 하지만, MSA를 따라한다고 해서 우리가 돈을 버는 것은 아니다. 따라서 우리 회사나 개발자 자신에게 MSA가 왜 필요한지 물어봐야 한다. 그에 앞서 회사와 나와 동료들은 (팀워크가 갖춰졌다고 하더라도) 서로 입장 차이가 있음을 알 수 있어야 한다. :)
정합성을 고려한 이벤트 처리 구조에 대한 사고법
다시 질문으로 돌아가서 나는 메시지를 읽는데 아래 빨간 색으로 표기한 표현들이 불편하게 읽혔다.
정확하지 않는 사고의 흔적인 듯해서 그런 듯하다. 왜 그렇게 생각했는지 설명해본다.
먼저, 이벤트 구조라는 말이 모호했다. 이벤트의 정의는 지난 글에 인용한 내용들이 있다. 하지만 이벤트 구조란 말은 모호한 표현이다.
글의 맥락을 보고 짐작하기에는 이벤트를 처리하는 구조를 뜻하는 듯하다. 질문한 분은 아마 오류없이 정합성을 보장하는 방법을 질문한 듯하다.
두 번째로 메인 이벤트라는 표현이다. 메인은 서브를 암시하는 말로 계층 구조를 전제한다. 설계자가 그렇게 이벤트 계층을 만들 수 있지만 도메인 드리븐 즉, 우리 상황에 맞춰야 한다는 점을 떠올려보자. 시작할 때부터 계층 구조를 고려하는 일은 바람직하지 않다고 생각한다. 따라서 '메인'이나 '서브'와 같은 말은 그 의미가 분명해야 한다. ( <나는 애자일이 싫다>에서 설명한 Bounded Context 개념이 이에 대한 근거다.)
아마 질문자가 메인이라고 한 말은 선행 이벤트 정도의 의미가 아니었을까 생각한다. 이벤트 처리 구조는 기본적으로 선행과 후속 프로그램이 정합성을 갖출 수 있느냐의 문제니까. 정합성에 대해서는 뒤에 더 구체적으로 다뤄보자.
마지막으로 영구적으로 라는 표현 역시 모호하다. 오류가 일상인 현실의 서비스를 생각해보면 굉징히 비현실적인 부사이다. 그리고 Persistence를 의미하는 저장장치 사용여부가 I/O 효율과 관련이 있어서 번역어에서 말하는 영구(persistence)와 의미가 섞이면 더욱 혼란스럽다. 따라서, 아예 저런 표현은 삼가는 것이 좋다.
MSA와 분산 시스템
MSA라고 하지 않고 분산 프로그램이라고 쓴다. 무슨 차이가 있을까? MSA라고 말할 때 자칫 그 방법을 따라가는 함정에 빠질 수 있다. 실제로 무턱대고 그렇게 따라하는 사람들이 많다. 개발자들이야 따라하면서 자기 기술을 늘릴 수 있을지 몰라도 사회적으로는 낭비를 초래할 수 있다. 적합하지 않는 방법을 도입하는 일이 될 수도 있고, 불필요한 일로 동료나 조직에 갈등을 초래할 수도 있다.
MSA는 결국 분산 프로그램 구축의 필요성에 따라 택한 수단(아키텍처)이 되어야 한다. 위키피디아의 정의는 다음과 같다.
A distributed system is a system whose components are located on different networked computers, which communicate and coordinate their actions by passing messages to one another from any system.
분산 프로그램을 다루는 분야를 분산 컴퓨팅(Distributed Computing)이라고 한다. 위키피디아에서 분산 컴퓨팅 아키텍처 설명을 보면 MSA 를 따로 다루지 않고, 다음 4가지를 기본 아키텍처로 제시한다.
MSA는 이들 기본 아키텍처와 무슨 관련이 있을까? 명확하게 규정되어 있지는 않지만 위키피디아 기록을 통해 생각해볼 수는 있다. 먼저 N-티어(n-tier) 아키텍처 정의를 보자.
n-tier: architectures that refer typically to web applications which further forward their requests to other enterprise services. This type of application is the one most responsible for the success of application servers.
웹 응용 프로그램이 자신에게 온 요청을 다른 enterprise services로 전달하는 일이 전형이라 말한다. enterprise는 반드시 기업용일 필요는 없기에 해당 영역에서 먼저 정의에 나섰기 때문이라고 추정할 수 있다. 아무튼 MSA는 기본 아키텍처 분류에 따르면 N-티어 분산 아키텍처이다.
(내용이 길어져서 글을 나눕니다.)
