<aside> 💡 모노리스 아키텍처 단점

  1. 의존성
    1. 서로 의존하고 있는 기능들 사이에 발생한 문제의 원인이 어디에 있는지 파악하기 힘들다
    2. 특정 기능에 추가로 개발할 때 의존성을 가지는 다른 기능에 문제가 발생할 수 있다.
  2. 비효율적인 build & 배포 프로세스
    1. 조그만 수정이 있어도 전체를 빌드하고 배포함으로써 소요되는 시간이 길어진다.
    2. 배포 전에 발생하는 conflict error가 발생
  3. 동일한 기능을 여러번 개발
    1. 여러 개의 애플리케이션에서 동일한 비지니스 로직이 추가 됨으로써 리소스가 낭비됨

<aside> 💡 프로젝트에 필요한 부분

  1. 프로젝트 및 기능별 독립적인 개발 및 배포
  2. 다른 기능에 영향받지 않는 독립적인 패키지
  3. 단일 비지니스 로직을 여러 환경에서 재사용 </aside>

</aside>

Microservice 아키텍처

마이크로서비스에 대한 공식적인 정의는 없지만 일반적으로 설명되는 것으로는 마이크로서비스란 단일 애플리케이션을 작은 규모의 서비스 조합은로 나눠 개발하는 방식을 말한다. 서비스는 자체 프로세스로 실행되며 가벼운 메커니즘으로 통신한다. 마이크로서비스는 결국 궁극적으로 넓은 범위에 걸쳐있는 크고 복잡한 시스템을 다루는 것이다.

  1. 마이크로서비스 스타일

    1. 애플리케이션 아키텍처는 주로 네트워크에 호풀할 수 있는 '서비스'로 구성된다
    2. 서비스의 크기를 고려하여 설계해야한다. 설계 요소는 런타임, 시간, 사람을 포함한다.
    3. 시스템, 조직, 일하는 방식을 전체적으로 최적화한다.

  2. 주의해야할 점

  3. 아키텍처 결정 기록(ADR)

    설계 결정을 문서화한다는 의미를 가진 도구를 말하며 명확한 결정을 내릴 수 있는 방법이다.

    1. 콘텍스트

      목표, 해결해야 하는 문제, 제약은 무엇인지에대한 요약 기록

    2. 대안

      결정을 내릴 수 있는 선택지가 없다면 좋은 결정이 아님을 알아야한다. 좋은 결정이 무엇일지 이해하는데 도움이 되어야한다.

    3. 선택

      모든 선택 사항을 문서화해야한다.

    4. 영향

      결정에 따른 결과와 중요한 내용은 문서화되어야한다. 장단점은 무엇인지, 일하는 방식이나 내려야 할 다른 결정에 어떤 영향을 미치는지에 대한 구체적인 내용이 포함되어야한다.

Micro Frontends 구현 방법

  1. Build-Time Integration

    수정사항을 반영하기 위해서 모든 패키지들을 만들어서 빌드해야하고 배포해야함

  2. Run-Time Integrations

    1. with Native WebView
      1. 시중에 많은 서비스들이 이 방식으로 운영되고 있음
      2. 모듈 개발 인력이 필요함
      3. 초기 개발 공수가 큼
    2. using iframe
      1. 가장 전통적이고 널리 알려진 방식
      2. 보안, 성능, 안정성 이슈가 있음
      3. 서로 통신할 수 있는 인터페이스를 구현해야함
      4. 링크나 라우팅에 대한 고민이 필요함
    3. Bundle(JavaScript Runtime Integratioins)
      1. 전통적인 방법(single-spa, webpack5 module federation)
      2. script 및 라우팅 처리

Webpack5 Module Federation

런타임에 통합된 각 애플리케이션들이 서로의 코드를 공유하는 방식의 기술이다. Next.js와 호환이 가능하다.