마이크로 서비스 아키텍쳐는 간지난다

맞다. 나도 그렇고, 나와 함께 공부하며 취업 준비를 하던 개발자 친구들은 MSA를 엄청 대단하고, 멋있고, 힙한 기술이라 생각했다.

실제로 알려진 좋은 회사들의 채용 공고에도 "MSA에 대한 이해와 경험" 이라는 우대사항이 매번 존재했기 때문일 수 있다.

억마 (억지 마이크로서비스)

취준생 시절 나는 그런 킹갓 기술을 경험해보아야 한다는 생각에 User, Accoount, Order, Cart, Payment, Auth, Notification, Email 수준의 도메인으로 구성된 10개 정도의 테이블으로 설계 될 자그만한 프로젝트에 접목 시키려고 노력을 했었다.

대충 기억하기로는

User-Account(User Service)
Auth(Auth Service)
Cart-Order-Payment
Notification(Notification Service)
Email(Email Service)

요 따위 수준의 도메인을 잡아 마이크로 서비스 명을 짓고 설계를 했던것으로 기억한다.

그래서 Spring Cloud 를 사용해, API Gateway를 구축했고, Eureka로 서비스 레지스트리로 관리했고, 써킷브레이커도 달아주고(hystrix), 로드밸런서(Ribbon)도 달았었다

그리고, 각각 어플리케이션 데이터 스토리지를 별도로 구축했고 Dockerize해서 API-Gateway를 포함한 여러가지 마이크로서비스 어플리케이션을 컨테이너 단위로 배포했다.

이중 몇개의 서버 어플리케이션은 필요도 없으면서 컨테이너를 두개로 만들고 어플리케이션도 두개 띄웠다.
그러면 API-Gateway에서 name-space 기반으로 로드밸런서에의해 라운드 로빈으로 요청이 날아갔다.

이렇게 하면 뭔가 내가 설계한 아키텍쳐가 간지나고, 성능 또한 가진 팔방미인 서버 어플리케이션이 될 수 있을 것 같았다.
비록 Rest로 서비스 간 통신을 구현한게 아쉬웠지만, 매번 팀장이였던 내 설계 나름대로 서비스간 분리도 되었고, 요구사항도 모두 구현 되었다.

그때는 멋있다고 생각했다. 최신기술에, 넷플릭스가 쓰는 기술이니까

하지만 지금 현업에서 마이크로서비스를 직접 만들어나가며, 많은 경험들을 하고 되돌아 보았을때
이때 만들었던 우리의 자그만한 프로젝트에는 마이크로 서비스 아키텍쳐 따위가 필요 없었다.

우리에겐 단점만이 존재했다.

우리는 서버 인스턴스 수평 확장의 장점을 마이크로서비스의 장점으로 착각했고,
마이크로 서비스 기반으로의 설계가 잘 되었든 못되었든 우리에게는 생산성을 정말로 많이 늦추는 도구가 되었다.
또한 서비스 분리로 가져올 수 있는 이점은 단 1도 없었으며, 내가 설계한 억지 마이크로서비스로 가져올 수 있었던 것은

1.Monolithic 보다 느린 서버 레이턴시
측정은 해보진 않았고 엄청나게 큰 차이도 아니겠지만, 분명히 동일 테이블에서 join으로 Read하는것이 서비스간 REST 호출로 이용해 Aggregate 하는 작업이 느리다는 것은 확실하다. 단편적인 예로 (IO 1회 vs IO 2번 사이에 REST 요청)

2. Monolithic보다 복잡한 운영/배포 파이프 라인

• Jenkins 배포 파이프라인을 5개 구성해야한다. CI/CD는 우리 팀이 제공받는 인프라 구조상 불가능 했다.
  빌드도 5번해야한다. 한번에 모두 배포하는 파이프라인이 있겠지만, 각 서비스 개발을 담당한 개발자는 다 달랐다. 우린 회사가 아니라 팀이였기 때문에 배포 계획따윈 없어서 결국 하나씩이다.
• 배포 단위가 매우 작았기 때문에, 오히려 피로함을 느꼈다.
• 어쨋든 운영/배포에서 경우의 수가 훨씬 늘어난다. 사실 그때의 우리보다 능력이 뛰어난 개발자님들이라면 실력과 노하우로 해결할 수 있는 문제이지만 당시 우리팀의 생산성을 떨어지게 한 요인 중 하나는 맞다.

3. Monolithic보다 민감한 서비스 인터페이스 변화

• 마이크로서비스로 분리해놓고 각 서비스 개발 책임을 어느정도 팀원들에게 나누어줬다.
  개발을 하던 어느날 팀원이 갑자기 말도없이 response를 변경하고 배포했다.
  서비스가 하나 둘 먹통이 되기 시작했다.

4. 그 외 대부분의 것들에 대한 불편함과 문제들

Monolithic 은 안 좋은것이 아니다.

그래서 MSA 프로젝트를 하고있는 사람들에게 이 형님들의 말이 전달되었으면 한다.

Q. 개발 업계는 사용하는 기술로 얻어올수 있는 결과적 이점보다 사용하는 기술이 무엇인지에 더 집중하는 경향이 있습니다. 새로운 기술을 사용하기보다는 좋은 결과를 얻기 위한 수단으로 마이크로서비스를 사용해야 합니다.

마틴 파울러 : "기본 옵션은 마이크로서비스를 사용하지 않는 것"이라고 말하는 것입니다. 정말 좋은 이유가 없다면 Monolithic로 가세요.

샘 뉴먼: 정말 그렇게 말하고 싶습니다. 나는 마이크로서비스가 온-오프 스위치와 같지 않다는 말을 전하기 위해 계속 노력 할 것입니다. (중략)
다시한번 말하지만 당신이 만드는 연습용 프로젝트나, 신규 서비스에는 마이크로 서비스가 필요 없습니다. 마이크로서비스가 기본 옵션이 되어서는 안 됩니다.
마이크로 서비스 아키텍처가 도움이 될 수 있다고 생각되면 아주 간단한 Monolithic 모듈 스타일 중 하나를 사용하여 시도해보고 거기에서 더 발전하도록 하세요.

당신이 나와 같은 실수를 저지르지 않고 마이크로서비스 뽕에 빠지지 않길 바라면서,
https://martinfowler.com/microservices/ 이 글 들을 추천드립니다.