1. 마이크로서비스

서비스가 점점 커질경우 하나의 프로젝트로 함께 묶는것이 점점 버거워지고 복잡해진다.

1.1 기존 1개 서버의 문제점

1. 소스코드 전체를 빌드/배포하려면 오래 걸림
   • e.g. 게시판 API가 바뀌면 게시판 폴더만 다시 배포
2. 에러나서 서버 죽으면 모든 API 사용 불가능
   • 게시판 죽어도 상품, 로그인 등 나머지는 모두 사용 가능
3. 특정 개발언어의 개발자만 뽑아야 됨
   • 게시판은 NestJS, 상품은 Django, 로그인은 Spring 등 다양한 개발자 채용 가능

이를 해결하기 위해 나온 것이 마이크로서비스 아키텍처(Microservice Architecture)다

• 큰 서비스를 작게 나누는 것 = Microservice
• NestJS 폴더 나누기 (DB도 같이 나눠야 함)
• e.g. 로그인(auth), 게시판(board) 파일 업로드, 결제 등 필요한 역할별로 개발을 하고,
  • 개발이 완료되면 하나로 묶어서 배포
• 작은 기능 하나 수정해도 그 수정한 부분만 빌드-배포하면, 빠름

1.2 MSA의 필요성

모든 서비스에 적용하는 것이 좋을까? 필수가 아님!!!

• 마이크로서비스 아키텍쳐를 적용했을 때에는 전체적인 기술 복잡도가 증가 할 수 있으므로,
• 이를 잘 판단하여 서비스의 구조를 결정해야 한다.

1.3 API-Gateway

모든 API 요청을 받는 서버인 API-Gateway를 두고,

• API-Gateway와 연결된 기능1 서버를 만들고,
• API-Gateway와 연결된 기능2 서버를 만들고,
• 하는 식으로 모든 서버를 한 군데로 모으는 서버를 API-Gateway라고 하며,
• 이로 인해 프론트엔드에서는 Gateway로만 요청을 보내면 된다.

cf. https://www.nginx.com/blog/introduction-to-microservices/

1.4 NginX (엔진X)

다른 프레임워크 다른 API 쿼리 언어를 사용할 떄,

• NginX를 이전에 배웠던 API-Gateway 용도로 사용하면 된다.
• 비슷한 도구들 e.g. Nginx, Kong, HAProxy, … etc.

Nginx는 마이크로서비스 뿐만 아니라, 다른 용도로도 많이 사용돼서 백엔드 개발자가 필수적으로 알아야 한다.