AI Convergence

애플리케이션이 계속 증가하고, 작은 변경에 기민하게 대응할 수 있고, 팀별 기술셋의 다양성을 수용하는 환경에서 Micro Service 개발/운영 환경을 구축해 본다. 

Micro Service

모노리틱환경의 단점을 극복한다. (참조)

• 작은 사이즈의 번들링 및 배포
• 지속적인 애플리케이션 추가
• 점점 늘어나는 접속자의 대응

Gateway Pattern 적용

• gateway 역할
  • api gateway: micro service의 api server와 TCP로 연결한다. 또는 중간에 Queue(Redis, RabbitMQ, Kafka)등을 두어서 구성해도 된다.
  • http server: login UI부분을 gateway에서 담당하고 JWT를 사용한다.
  • reverse proxy: micro service에 대한 web bundling file에 대한 reverse proxy 역할을 한다.
  • auth server: login시 auth 역할을 한다. 
• micro service 역할
  • api server: api는 TCP로 응답한다. 
  • http server: reverse proxy의 static 파일 대응을 한다. 

가용성을 위하여 gateway를 두개를 두어 용도별로 운영할 수 있다. 

BFF 패턴

Backend For Frontend 패턴 방식으로 개발한다. 

• Server는 NodeJS 기반으로 구성한다. 
• Client/Server 개발은 TypeScript로 통일한다.
• CSR(Client Side Rendering), SSR(Server Side Rendering)을 사용한다. 

개발 폴더 구성

멀티 애플리케이션을 mono repo에서 개발할 수 있는 폴더 구조를 정의한다. 

• apps 폴더
  • 4개의 애플리케이션이 존재한다.
• libs 폴더
  • page: 애플리케이션에 단위 화면 page를 개발하는 것이 아니라. page단위 별도 구성하고, application에서 조합한다.
  • ui: 모든 애플리케이션에서 사용하는 공통 ui
  • domain: core 업무에 대한 모든 내역들, 변경에 대해 유연하게 대처하기 위해 hexagonal architect방식으로 구성한다.
  • shared: common 라이브러리를 적용한다.

application의 libs 라이브러리 참조 방식

• api: api server역할이므로 주로 none visible한 라이브러리 참조
• web: ui 애플리케이션이므로 page, ui 라이브러도 참조

운영 폴더 구성

gateway와 micro services를 배포하는 폴더 구조를 정의한다. 

• bin: start/stop shell
• config: 환경파일
• lib: server 구동 번들링 파일
• public: static, web 번들링 파일들
• logs: 서버의 로그 파일

<참조>

- 마이크로 서비스 아키텍쳐 패턴 그리고 장/단점 (강추)

https://medium.com/design-microservices-architecture-with-patterns/monolithic-to-microservices-architecture-with-patterns-best-practices-a768272797b2

- 헥사고날 아키텍쳐

https://engineering-skcc.github.io/microservice%20inner%20achitecture/inner-architecture-2/

- BFF 패턴

https://giljae.medium.com/back-end-for-front-end-pattern-bff-4b73f29858d6