우아한 모노리스

https://www.youtube.com/watch?v=SrQeIz3gXZg&t=162s 

 

💭 MSA가 무조건 좋을까?

이 두 아키텍처가 대결구도일까? 모노리틱은 무조건 나쁘고, MSA는 무조건 좋아?

당연히 아니다. 원래 하나였던 것을 여러개로 쪼갠 것이다.

즉 원래 혼자서 해결했던 문제를, 여러 부분에서 나누어서 값을 전달해야한다.

기능이 복잡해지고 코드와 로직이 분산되어있다. ➡ 새로운 비즈니스 요구사항을 빠르게 반영하기 어렵다.

당연히 개발과 테스트는 더 많아진다. 새로운 기능 추가하려면 여러 곳을 손대야한다.

이게 한 개발자, 한 팀안에서 일어나는 일이면 그나마 괜찮다. 귀찮더라도 하면 되니까.

하지만 협업을 하는 서비스가 다른 팀의 서비스라면? 대규모 서비스라서 팀 구성이 복잡하다면?

 

실제 서비스는 시간적 여유가 넉넉하지 않다. 일단 동작하게 만들기 위해선, 개발팀이 어디를 집중해야할까?

➡ MSA의 구조는 기술부채를 가속화 시킨다. 전체를 손 보기 너무 어려우니까

하나의 기능을 추가하기 위해 모든 서비스를 손댈수는 없다. 개발팀은 나루토가 아니다.

 

📑 ?? 유명한 기업들은 다 MSA 쓴다면서요?

모든 것은 트레이드 오프이다.

아래의 MSA를 적극적으로 사용하는 기업들은, 서비스 트래픽이 어마어마하다.

기존의 모노리스로 감당하기 어려운 트래픽을 MSA로 부담을 나누고 시스템을 쉽게 확장할 수 있다.

• 변경이 일어날 때 변경의 여파가 크다.
  ➡ A 기능을 변경하면 B도 영향을 받는다. (함께 테스트 해줘야한다. 배포 & 출시가 늦어진다.)
• 단일 시스템이라서, 특정 부분의 장애가 전체 장애로 퍼질 수 있다.
• 단일 시스템이라서, 시스템을 수평 확장하기 어려운 구조이다. Scale-out이 힘들다.

마이크로 서비스는 이러한 점을 많이 해결해준다.

MSA는 각 서비스가 자율적이다. 자신의 서비스에 대해 스스로 결정하고, 책임질 수 있다.

• 각 서비스에 발생하는 장애를 격리시킬 수 있다. (전체 시스템에 전파를 막는다.)
• 느슨하게 결합되어 있기에, 각 서비스를 다른 것으로 대체할 수 있다. (특화된 기술을 별도로 사용할 수 있다.)
• 각 서비스들을 재사용하여 새로운 비즈니스를 만들 수 있다.

근데 아키텍처를 변경한다고 해서 문제가 바로 해결될까?

MSA를 언급하면 매번 나오는 말이 있다. Conway's law (콘웨이 법칙)

조직이 설계한 [시스템 디자인]은 해당 [조직의 커뮤니케이션 구조]를 따른다

참고로 Conway's law는 IT기업을 위해 작성된 논문이 아니었다.

How Do Committees Invent?(Conway) - https://www.melconway.com/Home/pdf/committees.pdf

 

현재에도 많은 기업은, '업무'를 중심으로 운영된다. 그 업무의 전문가들을 모아 한 팀으로 결성하면 더 효율이 좋아질테니까.

 

하지만 IT 기업은 이러한 구조가 좋지 않다.

소프트웨어는 한번 짓고나면 틀이 변하지 않는 빌딩이 아니다.

시장은 끊임없이 변한다. 비즈니스는 시장에 따라가며 끊임없이 변화해야한다.

 

예를 들어 '예약 시스템을 추가한다.' 라는 요구사항이 있다고 생각해보자.

1. 기획자가 예약 시스템을 기획한다.
2. 디자이너에게 필요한 그림을 요청한다. (디자이너는 이게 무엇을 위한 그림인지 모른다.)
3. 개발자에게 시스템을 요청한다. (개발자도 그냥 기획자가 시키는대로 만들 뿐이다.)
4. 테스터에게 시스템 QA를 요청한다. 

서비스를 만드는데에 있어 팀의 이해가 공유되지 않는다. 흔히말해 내가 삽질을 하는데, 건물을 짓기위함인지 땅굴을 만들기 위함인지 모른다는 것에 있다.

소프트웨어는 요구사항이 언제든지 변할 수 있다. 매번 새로운 기능을 추가할 때마다 각각의 조직에 요청하게 된다면 조직별 이해관계가 틀어지고 소통에도 문제가 생기게된다.  (아니 바쁘다고요. 그걸 언제 또 추가해요?)

 

시스템을 이해하고 변화에 쉽게 대응하려면 조직의 구조는 아래와 같아야한다.

각 분야의 팀원을 모아서 소규모로 여러 팀을 구성해야한다.

특히 MSA가 그러하다. 독립적인 마이크로 시스템을 만드는데 팀의 구조가 첫번째와 같다면 정말 많은 문제가 따를 것이다. 

조직이 설계한 [시스템 디자인]은 해당 [조직의 커뮤니케이션 구조]를 따른다

이 말은, 시스템 디자인을 하기 앞서 조직의 커뮤니케이션 구조를 함께 개선시킬 필요가 있다는 것이다.

“각 서비스 독립적으로 실행가능한 작은 서비스로 구성되고, 각 서비스는 느슨하게 결합되어야 한다.”라는 마이크로 서비스의 특징을 살려 잘 개발하기 위해서는 효율적이고 유연한 유연한 조직으로 구성되야 한다.

MSA 구조로 만들려면, 팀 또한 같은 구조로 구성되어야 한다.

독립된 서비스에 맞춰 팀을 구성하자.

---

오히려 더 복잡해진다. (이를 분산된 모노리스라고도 말한다.)

높은 응집도(Cohesion)와 낮은 결합도(Coupling)를 먼저 챙겨야한다.

소프트웨어는 원래 복잡하다. 의도치않은 복잡성을, 의도한 복잡성으로 바꿔야한다. 제어해야한다.

• 변화가 함께 일어나는 코드만 모여있으면 [응집도]가 높은 것이다.
• 어떤 객체를 변경했을 때, 관계 없는 다른 곳이 영향받는다면 [결합도]가 높은 것이다.

높은 응집도, 느슨한 결합이 좋다.

서비스를 너무 마이크로로 쪼개면 결합도가 높아지기 쉽다. 하나의 서비스를 여러 개체가 처리해야하니까.

서비스를 하나로 크게 가져가면 응집도가 낮아지기 쉽다. 관계없는 코드들이 한 서비스에 뭉쳐있으니까

트레이드 오프를 고려해야한다.

MSA를 사용하면 그만큼 시스템이 복잡해지고, 결합도가 높아지기 쉽다.

그러나 내가 만드는 서비스는 어떤가

MSA를 도입함에 있어 얻는 장점이 꼭 필요할까? 정말 전체 시스템이 뻗어버릴 정도의 트래픽이 발생할까?

 

실제로 배민, 넷플릭스같은 대기업도 모든 구조를 무지성으로 MSA로 만들지는 않는다.

적절하게 섞어서 사용한다. 트레이드 오프와 도입했을 때 얻을 수 있는 부수 효과를 고려하자.

적당히 섞어서 사용하자. 있어보이는 말로 [모듈형 모노리스]

모노리스 시스템으로 개판난 조직은, 아키텍처를 MSA로 바꿔봤자 큰 차이없다.

오히려 시스템이 더 어려워질 뿐.

MSA 구조로 만들려면, 팀 또한 같은 구조로 구성되어야 한다.

 

💭 모듈화와 아키텍처의 본질

변경을 얼마나 빠르게 수용할 수 있는가.

복잡도를 낮추는 방법. 내부를 숨기고 API로 대화하라.

어플리케이션의 핵심, 도메인을 구체적인 동작에서 분리시키는 것

외부의 구체적인 수행방식은 언제든지 변경 될 수있다.

Core = 아키텍처 (도메인 모델), 외벽 = 인터페이스

---

💭 예제를 통해 알아보자

간단한 이커머스를 통해 함께 개선시켜보자.

다파라 닷컴을 만들어 보자.

이 시스템은 [상품] [주문] [배송] 이라는 도메인이 있다.

도메인을 중심으로 응집도 높은 모듈을 구성하면 아래와 같다.

계층 (레이어)를 중심으로 모듈화하면, 시스템이 복잡해질수록 변화를 제어하기 어렵다.

독립적인 모듈을 만들려면 도메인을 중심으로 모듈화 해야한다.

또는 관심사에 따라 모듈화할 수도 있다.

예를 들어 로깅, 보안과 같이 전체에 다 범용적으로 적용되는 [수평적 관심사]

재사용성은 별로 중요하지않고, 그 비즈니스를 구현한 [수직적 관심사]

 

💭 모듈을 나눴다면 의존성을 관리하자.

의존성은 한쪽으로만 흘러야한다. - 조영호 오브젝트

 

 

💭 코드 시작

• step_1: modularization - 도메인 중심 모듈화와 모듈간 의존성 관리
• step_2: encapsulation and separately - 모듈을 보호하고, 모듈간 의존성 분리
• step_3: context boundaries - 모듈 자율성을 지키는 컨텍스트 경계
• step_4: modularizing configurations - 컨텍스트 환경 모듈화
• step_5: decomposing system and stand alone services - 시스템 분리와 독립적인 서비스로 성장

모듈은 정말 쉽게 결합 될 수 있다. 경계를 확실하게 나눠야한다.

이를 언어(컴파일러) 차원에서 막는게 가장 좋다. 

또는 한발 더 나아가서, Gradle로 의존성을 분리해버릴 수 있다.

하나의 저장소에서 모듈별로 여러 개의 프로젝트를 사용하는 것. 아예 의존성을 가질 수가 없다.

그리고 이 모듈들이 협력할 수 있는 Service (어플리케이션)를 만드는 것.

스프링 컨테이너

스프링 컨테이너처럼 만들기.

 

 

ArchUnit

Moduliths

Across Framework 등