Dean Story

- 참고: https://bkjeon1614.tistory.com/27

- 참고: https://woongsin94.tistory.com/378

구조

1. Presentation Layer

- 사용자 인터페이스를 제공하는 계층이다.

- 정적 데이터를 제공하고 Web Server를 의미한다.

- Front-end라고 불린다.

- 비즈니스로직이나 데이터관리 코드를 포함하면 안 된다.

2. Application Layer

- 비즈니스 로직을 처리하는 계층이다.

- 동적 데이터를 제공하고 Web Application Server를 의미한다.

- Midleware 또는 Back-end라고 불린다.

3. Data Layer

- DB 또는 File System 데이터에 대한 접근 및 관리하는 계층이다.

- 주로 DB 서버를 의미한다.

[우아한테크세미나] 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 )

- 해석:

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

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

출처: https://engineering.linecorp.com/ko/blog/detail/319

       http://bcho.tistory.com/948

- Monolithic Architecture: 하나의 애플리케이션 내에 서비스를 담는 개발 방법론으로서, 개발, 배포, 확장을 단순화하는 장점이 있다.

1. 정의:

   하나의 애플리케이션을 서비스 단위로 구분하여 하나의 기능에 대해 여러 서비스를 조합하여 제공하며 독립적으로 개발, 배포, 확장할 수 있는 개발 방법론.

2. 장점:

   - 코드 이해와 수정이 쉬워진다.

   - 어떤 기능에서 문제가 발생하더라도 다른 기능에 영향을 주지 않아 장애 처리가 쉬워진다.

3. 단점:

   - 성능 저하

     ㄴ서비스간의 호출을 API 통신을 이용하기 때문에 값을 json이나 xml에서 프로그래밍에서 사용하는 데이타 모델 (java object등)으로 변환하는 marshalling 오버헤드가 발생하고 호출을 위해서 이 메세지들이 네트워크를 통해서 전송되기 때문에 그만한 시간이 더 추가로 소요된다.

   - 메모리 요구량 증가

     ㄴ각 서비스를 독립된 서버에 분할 배치하기 때문에, 중복되는 모듈에 대해서 그만큼 메모리 사용량이 늘어난다.

   - 테스팅이 어려워진다.

     ㄴ서비스들이 각각 분리가 되어 있고, 다른 서비스에 대한 종속성을 가지고 있기 때문에, 특정 사용자 시나리오나 기능을 테스트하고자 할 경우 여러 서비스에 걸쳐서 테스트를 진행해야 하기 때문에 테스트 환경 구축이나 문제 발생시 분리된 여러개의 시스템을 동시에 봐야 하기 때문에 테스팅의 복잡도가 올라간다.

   - 운영이 어려워진다.

     ㄴ서비스 별로 서로 다른 기술을 사용할 수 있으며, 시스템이 아주 잘게 서비스 단위로 쪼게 지기 때문에 운영을 해야할 대상 시스템의 개수가 늘어나고, 필요한 기술의 수도 늘어나게 된다.

   - 서비스 간의 트랜잭션 처리가 어려워진다.

     ㄴMonolithic Architecture에서는 RDBMS를 사용하면서 하나의 애플리케이션 내에서 트랜잭션이 문제가 있으면 쉽게 데이타베이스의 기능을 이용해서 rollback을 할 수 있었다. 여러개의 데이타베이스를 사용하더라도, 분산 트랜잭션을 지원하는 트랜잭션 코디네이터 (JTS – Java Transaction Service)등을 이용해서 쉽게 구현이 가능했는데, API 기반의 여러 서비스를 하나의 트랜잭션으로 묶는 것은 불가능 하다. 쉽게 예를 들어서 설명을 하면, 계좌에서 돈을 빼는 서비스와, 계좌에 돈을 넣는 서비스가 있다고 하자. 이 둘은 API를 expose했을 때, 계좌에서 돈을 뺀 후, 계좌에 돈을 넣기 전에 시스템이 장애가 나면, 뺀 돈은 없어지게 된다. Monolithic Architecture를 사용했을 경우에는 이러한 문제를 트랜잭션 레벨에서 롤백으로 쉽게 해결할 수 있지만 API 기반의 Microservice Architecture에서는 거의 불가능하다. 

  이러한 문제를 해결하기 위해서 몇가지 방안이 있는데,

  그 첫번째 방법으로는 아예 애플리케이션 디자인 단계에서 여러개의 API를 하나의 트랜잭션으로 묶는 분산 트랜잭션 시나리오 자체를 없애는 방안이다. 분산 트랜잭션이 아주 꼭 필요할 경우에는 차라리 모노리틱 아키텍쳐로 접근하는 것이 맞는 방법이다. 앞서도 언급했듯이 마이크로 서비스 아키텍쳐의 경우, 금융이나 제조와 같이 트랜잭션 보장이 중요한 엔터프라이즈 시스템보다는 대규모 처리가 필요한 B2C 형 서비스에 적합하기 때문에, 아키텍쳐 스타일 자체가 트랜잭션을 중요시 하는 시나리오에서는 적절하지 않다.

  그럼에도 불구하고, 트랜잭션 처리가 필요할 경우, 트랜잭션 실패시 이를 애플리케이션 적으로 처리해 줘야 하는 데, 이를 보상 트랜잭션(compensation transaction)이라고 한다. 앞의 계좌 이체 시나리오에서 돈을 뺀 후, 다른 계좌에 넣다가 에러가 났을 경우에, 명시적으로, 돈을 원래 계좌로 돌려주는 에러 처리 로직을 구현해야 한다.

  마지막 방법으로 복합 서비스 (composite service)라는 것을 만들어서 활용하는 방법이 있는데, 복합 서비스란 트랜잭션을 묶어야 하는 두개의 시스템을 트랜잭션을 지원하는 네이티브 프로토콜을 이용해서 구현한 다음 이를 API로 노출 시키는 방법이다.

두개의 데이타 베이스는 XA(eXtended Architecture)와 같은 분산 트랜잭션 프로토콜을 써서 서비스를 개발하거나 또는 SAP나 Oracle 아답터와 같이 트랜잭션을 지원하는 네이티브 아답터를 사용하는 방법이다. 기존에 SOA에서 많이 했던 접근방법이기는 하나, 복합 서비스를 사용할 경우, 복합서비스가 서로 다른 두개의 서비스에 걸쳐서 tightly coupled하게 존재하기 때문에, 마이크로 서비스 아키텍쳐의 isolation(상호 독립적)인 사상에 위배되고 서비스 변경시에 이 부분을  항상 고려해야 하기 때문에 아키텍쳐상의 유연성이 훼손되기 때문에 꼭 필요하지 않은 경우라면 사용하지 않는 것이 좋다.