by
Nov 02. 2020
MSA프로젝트에서 마주하는 3가지 어려움
니땅내땅 선가르기 어렵구만
MSA 구축 프로젝트를 해보신 것으로 아는데요, MSA간 시스템을 어떻게 나눠야 좋을까요?
최근 강의에서 이런 질문을 여러차례 받았다. 아무래도 MSA환경에서의 기획은 우리에게 여전히 낯설고 어렵기도 그렇겠지만, 직접 겪어본 나로서는 저게 어떤 의미인지 안다. 총만 안들었지 으르렁대는 MSA개발자들 사이에서 이러지도 저러지도 못하는 기분, 완전 예상이 간다.
전에 다른 글에서도 말했지만 모놀리틱 환경에서 기획자는 참 상대적으로 쉬웠다. 어딘가에 데이터가 있다는 것만 안다면 그 자체가 구현가능성이었다. 그 뒤는 개발하시는 분들이 알아서 조회해서 알아서 써주는 시스템. 개발모듈이 달라도 서로 데이터 ERD만 제대로 공유되고 코드목록만 잘 정의되도 새로 만드는 것도 정합성을 맞추는 것도 기획자는 관심조차 없었다.
그런데 MSA에서 프로젝트는 전쟁이었다. 아무리 더 싸우고 덜 싸우는 분위기는 있겠지만, 이커머스처럼 데이터의 상호 의존성이 월등히 높은 곳에서는 더더욱 예민해지는 분위기였다. 게다가 프로트엔드와 백엔드조차 API로 노드 연결을 하는 요즘 구조는 정말 땅따먹기 해야할 곳이 한두군데가 아니다.
내가 프로젝트중 겪은 MSA 이커머스 시스템 구축에서 벌어졌던 대표적인 싸움상황들을 모아봤다.
1. 미루기의 이기주의
개발팀의 숙명은 '오류'다. 그 정도의 차가 있을 뿐, 오류가 발생하는 것은 지극히 당연한 과정이다. 이 간극을 좁히기 위한 QA에 전사가 다 달려드는 이유기도 하다. 하지만 오픈 후에 찾아낸 오류낸 그야말로 개발팀의 가슴을 오그라뜨린다. 현실에서 집에도 못가고 주말도 없어지고 고개를 떨궈야 하는 것이 바로 IT의 숙명이다.
그러고 보면 왜 MSA에서 서로 처리를 미루려고 난리가 나는지를 이해하지 못할 것도 없다. 항상 문제가 일어나는 부분은 '데이터 가공'에 있다.
MSA에서 마스터 데이터를 쌓는 것은 큰 싸움이 되지 않는다. 이 부분은 이름만으로도 굉장히 분명하다. 주문처리를 주문MSA에서 개발하고 회원DB가 회원 MSA에 쌓인다. 그런데 문제는 다른 한 쪽의 데이터를 가공하여 사용해야할 때다.
예를 들어서 주문할 때 회원중 '블랙고객'으로 등록된 경우 주문을 막는다는 정책이 있다고 해보자. 블랙고객이라는 회원정보는 당연히 회원 MSA에 있고, 이에 대한 주문 금지 규정은 주문MSA에서 처리해야한다.
과거의 모놀리틱 환경에서는 그냥 주문개발자가 회원DB를 조회하여 블랙고객임을 확인하면 됐다. 하지만 MSA환경에서 방법은 3가지나 된다.
방법1 : 주문 시 회원MSA에 호출하면 Y/N으로 가능여부를 받는 방법
방법2 : 주문 시 회원MSA에 호출하면 회원데이터 전체를 받는 방법
방법3 : 프론트의 회원 로그인 세션 정보나 공통으로 조회가능한 곳에 블랙고객여부를 담고 있어서 주문MSA가 조회해서 쓰는 방법
여기서 각 방법별로 입장이 달라진다. 주문 MSA개발 입장에서는 1번이 편하다. 어차피 호출해야하니 Y/N으로 받으면 코딩도 쉬워지고 만약 실수로 블랙고객의 주문이 발생한다면 그 것은 데이터를 보내준 쪽에서 수정하면 될 문제일 가능성이 높다. 반면에 회원MSA입장에서는 2번이 쉽다. 회원정보를 호출해갈 API를 1개 만들어놓고 모든 모듈에 뿌리며 돌려막기가 가능하다. 각각 API를 협의하여 만들어주는 것보다 쉽다. 이런 부분이 두 MSA가 서로 니가 하라며 박터지게 싸우는 부분이다. 종종 성격 나쁜 개발팀원이 있을 경우 상생과 협력의 정신을 벗어나게 되기도 한다.
결국 회원의 데이터를 필요로 하는 비슷한 니즈의 MSA들이 모여서 협의를 했고, 그나마 모놀리틱처럼 움직이는 3번으로 합의를 봤다. 모두에게 그나마 행복한 시나리오였다. 하지만 그 과정은 경험치가 없었기에 지옥같았다.
기획자는 이 사이에서 담당 MSA를 편들어야할 지 아니면 어찌됐든 해결이나 해오라고 할지 참 난감하다. 특히 둘 다 담당 모듈인데 싸움이 나면 어찌해야할지 어렵다. 방법은 3번으로 이야기하듯 범위와 비즈니스적 활용도로 설득해야한다.
그러려면 적어도 내가 맡은 모든 개발 로직에서 타 MSA에 데이터를 호출하는 시점을 알아야한다. 마스터 데이터가 어딨는지 알면 추론이 가능하다. 엄청난 개발로직을 코딩을 이해하란 이야기는 아니다.
2. 협의없는 API변경 후 통보
오픈 후 운영중이었다. 다음 날이 수정배포인데 테스트가 죄다 오류가 나고 있었다. 우리 MSA의 개발팀장이 씩씩대며 나타났다. 갑자기 기능이 다 안되는 이유가 데이터를 호출해서 쓰던 다른 MSA가 API를 변경하고는 어제 밤에 메일하나 보냈다는 것이었다. 내부의 정책이 바뀌어서 따라서 바뀌었다나..
MSA는 각 MSA간의 영향도가 없는 것을 큰 장점이라고 말한다. 그런데 그건 서로간에 규약은 흐틀지 않는다는 대전제가 있기 때문에 가능하다.
예를 들어, 배송유형을 받을 때 택배와 기타유형밖에 없어서 내부 코드를 각각 Y/N으로 보내주기로 협의된 API가 있었다고 해보자. 갑자기 배송유형이 늘어나서 그들만 01,02,03으로 바꾼다면 어떻게 될까?
받는 쪽도 동일한 일정으로 싱크가 맞춰져야 문제가 되지 않는다. 그런데 이런 변경사항이 기존 모놀리틱보다 잘 전해지기 어려운 구조다.
왜냐하면 보통 MSA는 중앙에서 반영배포를 통제하지 않고 devops형태로 개발한 MSA가 직접 배포하는 경우도 많기 때문이다. 사실상 파일이 겹쳐서 merge를 해야할 일이 거의 없기에 변경에 자유롭고 다른 MSA에 뒤늦게 알려지는 고통을 당하기도 쉽다. 아주 자세하게 서로의 협력관계를 검토하고 정책변경시에도 기획자도 자신의 MSA만 고려해서는 안되는 이유다.
당시 우리는 결국 수정개발이 필요하여 배포를 미룰 수밖에 없었다. 상대 MSA는 공식적으로는 사과했지만 결국 고통은 우리MSA만 당한다는 게 안타까운 팩트!!
3. 정책 지식간의 차이
2번과 연관된 이야기일 수 있는데 모듈간의 정책 지식차이가 문제가 되는 경우도 있다. 모든 온라인 서비스는 앞에서 발생한 데이터가 뒤에까지 흘러가는 구조다. 물리적으로 말하면 앞의 데이터가 복사되어 넘어가거나 뒤의 프로세스를 담당하는 MSA가 앞쪽의 MSA의 데이터를 계속 필요로 하는 구조다.
이런 상황에서 뒤쪽은 앞단의 데이터를 파악하기 위해 앞쪽 정책을 파악하게 되는 경우가 많다. 하지만 앞에서는 뒤쪽의 정책과 프로세스에 관심이 없는 상태에서 앞에 보이는 것만으로 기획과 설계를 하게된다. 뒤에서는 앞단의 정책으로 인해 한층 복잡해지는 것이다.
이런 경우는 결국 뒷쪽에서 이슈를 제기해서 앞쪽을 고치도록해야하는대 사실상 많은 시간과 커뮤니케이션 비용이 드는 일이다. 애초에 서로의 지식이 같고 서로 이해하는 범주가 넓었다면 일어나질 않을 일이 지식 격차로 인해서 일어난다. 명백한 사람의 실수다.
아무리 바쁘더라도 앞뒤의 정책에 문제가 없는지 계속 검토하고 모른다면 먼저 알려주는 것은 중요하다.
MSA 구조에서 기획하기 위한 팁
