모노리틱(Monolithic) vs 마이크로서비스(Microservices)

[우아한테크세미나] 2020123 우아한모노리스 by 박용권님

 

내용정리

- 영상: https://www.youtube.com/watch?feature=youtu.be&v=SrQeIz3gXZg&app=desktop 

- 소스: https://github.com/arawn/building-modular-monoliths-using-spring

- 슬라이드: https://www.slideshare.net/arawnkr/ss-224478403

 

<모노리틱의 주요 단점과 한계>

1. 예상치 못한 결합 => 변경에 의한 영향이 크기 때문

2. 높은 테스트 비용 => 변경에 의한 영향이 크기 때문

3. 늦은 출시 싸이클 => 변경에 의한 영향이 크기 때문

4. 부족한 장애 내성

5. 단일 확장성 => 애플리케이션의 복사로 이루어지는 수평 확장

 

 

<마이크로서비스의 주요 장점>

1. 확장성

2. 조직 부합성  =>  "콘웨이의 법칙": 소프트웨어 구조는 개발 조직의 커뮤니케이션 구조를 닮는다.

3. 회복성

4. 배포 용이성

5. 조합성

6. 기술 이기종성

7. 대체 가능성

 

=> 한마디로, "자율적"

 

 

"The goal of software delivery is to minimize the lead time to business impact. Everything else is detail."

by Dan North ( https://dannorth.net/2013/07/05/are-we-nearly-there-yet )

 

- 해석:

"소프트웨어 개발의 목적은 긍정적인 비즈니스 영향력을 사용자에게 최대한 빠르게 전달하는 것"

 

 

"응집(Cohesion)과 결합(Coupling)을 다스리는 것이 먼저다"

1. 적은 비용으로 변경할 수 있는 구조 만들기

2. 주어진 상황에 따라 적절한 도구를 선택하자

 

 

<모노리스(Monoliths)의 특징>

- 단일 프로젝트에 모든 코드가 모여있다.

- 시스템 구조가 간결하고, 빠르게 구축할 수 있다.

- 테스트 및 배포 파이프라인 구성이 간단하다.

- 인프라스트럭처 구축과 운용이 간결하다.

 

<마이크로서비스(Microservices)의 특징>

- 시스템을 조직 구조에 맞게 더 적절히 정렬할 수 있다.

- 서비스를 독립적으로 배포 또는 확장할 수 있다.

- 서비스 장애가 시스템 전체 장애로 전파되지 않는다.

- 문제 해결에 특화된 다양한 기술을 도입할 수 있다.

 

 

<모노리스의 유형>

1. 모노리스(Monoliths)

2. 분산된 모노리스(Distributed Monoliths)

3. 모듈형 모노리스(Modular Monoliths)

4. 마이크로서비스(Micreservices)

 

 

"좋은 아키텍처는 시스템이 모노리틱 구조로 태어나서 단일 파일로 배포되더라도, 이후에는 독립적으로 배포 가능한 단위들의 집합으로 성장하고, 또 독립적인 서비스나 마이크로 서비스 수준까지 성장할 수 있도록 만들어져야 한다. 또한 좋은 아키텍처라면 나중에 상황이 바뀌었을 때 이 진행 방향을 거꾸로 돌려 원래 형태인 모노리틱 구조로 되돌릴 수도 있어야 한다."

by '클린 아키텍처' 도서

 

 

* 모듈(Module): 서로 관련성이 높은 클래스 집합을 하나의 논리적인 단위로 묶는 구성요소로서, 이를 자바에서는 패키지라 부른다.

 

* 모듈화(Modularization): 소프트웨어 시스템을 분해(decomposition)하여 서브 시스템들과 컴포넌트들의 그룹으로 묶는 것이다. 주요 목적은 시스템 내에 잘 정의된 경계(Boundary)를 도입해 소프트웨어 복잡성을 다루는 것이다.

 

- 결합(Coupling)은 모듈들 사이(inter-module)의 관계에 집중한다.

- 응집(Cohesion)은 모듈 내부(intra-module)의 상태에 집중한다.

 

 

 

<변경을 수용할 수 있는 소프트웨어 아키텍처>

 

관심사의 분리를 통해 "애플리케이션 핵심을 외부 기술적인 부분들과 분리시키는 것"이 목표이다. 이렇게 분리 된 영역은 필요에 따라 어렵지 않게 변경이 가능해야 한다.

 

 

 

 

 

 

 

 

 

 

 

내부 영역은 도메인 개념을 구현한 코드가 배치되고, 외부 영역은 구현 세부사항(UI, 데이터베이스 등)과 상호작용하는 코드를 배치한다. 반드시 지켜야할 원칙은 외부에서 내부로 접근하는 의존 방향이다. 절대 그 반대로는 안 된다.

 

 

 

 

 

 

 

 

 

1. 도메인 중심으로 응집도 높은 모듈 구성하기

- 도메인을 중심으로 세부사항(DB, Web 등)이 분리된 구조를 만든다.

- 도메인 지향 모듈화와 함께 바운디드 컨텍스트(Bounded Context)를 고려한다.

  ㄴ바운디드 컨텍스트는 도메인 주도 설계(Domain-driven design)에서 전략적 설계에서 언급되는 용어로서, 의미적으로 통일한 컨텍스트의 범주를 표현하는데, 범주 내에서 소프트웨어 모델의 각 컴포넌트들은 컨텍스트에 특화되어 있으며, 컨텍스트 내에서 특정한 의미를 갖고, 특정한 일을 수행한다.

 

 

<모듈화 기법>

1. 계층 구조로 모듈화

2. 도메인 지향 모듈화 (+ 내부적으로 계층 구조를 가진)

3. 수직적 관심사(비즈니스와 응용프로그램에 특화된 기능)  => 비즈니스 로직의 구현에 초점

4. 수평적 관심사(로깅, 보안 등 공통적인 저수준 기능) => 재사용성에 초점

 

 

 

2. 의존성 관리로 느슨하게 결합된 모듈 설계하기

- 모듈관 순환적 의존 관계가 형성되지 않도록 설계한다.
- 참고: '오브젝트' 도서

- 참고:

우아한 객체지향 by 조영호님 https://www.youtube.com/watch?v=dJ5C4qRqAgA&feature=youtu.be

 

<전략적으로 시스템 통합을 돕는 컨텍스트 매핑>

컨텍스트 매핑은 둘 이상의 바운디드 컨텍스트를 통합하는 것을 말한다.

ㄴ도메인 주도 설계(DDD)에서 전략적 설계에서 언급되는 용어로서, 컨텍스트 매핑은 8가지 매핑전략을 제공하는데 상황에 따라 적절하게 전략을 선택해 활용할 수 있다.

 

 

3. 모듈 사이 경계를 넘어오지 못하게 선 긋기

 

4. 멀티프로젝트 구성을 통해 의존성 분리하기

 

5. 모듈 자율성을 지켜주는 컨텍스트 경계 구성하기

- 자율성은 모듈의 내부와 외부를 명확하게 구분하는 것으로부터 나온다. 단일 스프링 IoC 컨테이너에서는 모듈의 내부를 숨기는데 한계가 있다. 이 한계를 극복하고, 모듈의 자율성을 지켜주는 컨텍스트 경계를 구성한다.

 

 

 

<컨텍스트 계층 구조>

 

 

6. 컨텍스트 계층 구조로 모듈을 격리하기

 

 

7. 컨텍스트간 협력을 위한 공개 API 내보내기

 

<컨텍스트 설정 모듈화>

 

8. 시스템 분리와 독립적인 서비스로 성장하기

 

 

<모듈형 애플리케이션 구축을 지원하는 도구>

1. Moduliths

https://github.com/odrotbohm/moduliths

 

 

2. Across Framework

https://across.dev/

 

 

 

 

"software maintenace is not "keep it working like before."

It is "keep it being useful in a changing world" - a great art of its own

by Jessica Keer, Atomist ( https://twitter.com/jessitron/status/728270662414934016 )

 

- 해석:

소프트웨어 유지보수는 이전과 같이 계속 동작하게 하는 것이 아니라,

변화하는 세계에서 계속 유용하게 하는 것이다.