1. MSA의 정의

MSA는 소프트웨어 시스템을 여러 작은 독립적인 서비스로 분할하여 개발하고 배포하는 방식이다.

주요 특징

• 독립적으로 배포 가능해야한다.
• 서비스간 느슨히 결합돼야한다. (Loosely Coupled)
• 비즈니스 목적별로 나뉘어야한다.

흔한 오해

• 생각보다 넓은 소프트웨어 “아키텍처”의 개념이다.
• 특정 기술의 사용을 시사하거나 강제하지 않는다.
• 어차피 Microservice를 미래에 할 계획이라면 처음부터 Microservice를 하는게 좋다

1.1 MSA에 대한 생각

이론적으로 MSA는 “MSA는 소프트웨어 시스템을 여러 작은 독립적인 서비스로 분할하여 개발하고 배포하는 방식이다.”를 말하는게 맞다. 큰 무언가를 꼭 쪼개야하는 상황이 만들어지려면 프로젝트가 너무 크거나 팀이 너무 커야한다. 하지만 이 둘을 충족하는 회사는 생각보다 얼마 없다.

Monolithic Architecture 부터 MSA 사이에는 개인적으로 무수한 타협점들이 있다고 생각한다. 즉, 이 두 아키텍처는 흑백 논리로 나뉘는게 아니라 하나의 스펙트럼이 존재한다.

필요한 부분부터 전환을 하면서 천천히 변화를 만들어가면 된다. “Monolithic이니까 이렇게 해야지!”, “MSA니까 이렇게 해야지!”라는 특정 개념을 강제하는 정답은 존재하지 않는다. Monolithic 부터 시작해서 하나씩 분할 해가면서 MSA로 전향을 하는 방식이 가장 이상적인 MSA 구축 방법이다.

잊지말자. 우리는 Software Engineer다. 궁극적인 답을 찾아내는 과학을 하는 사람들이 아니라 가장 효율적으로 결과물을 만들어내는 엔지니어들이다. “효율적인 결과”를 구현하기 위해 어느 하나의 답만 존재하지 않는다

1.2 Monolithic to MSA

1.3 Monolithic Architecture

Monolithic Architecture는 애플리케이션이 하나의 덩어리로 이루어져있다. UI, 비즈니스 로직, 데이터베이스 접근 (Infrastructure) 등이 하나의 단위로 구성된다.

• 하나의 배포 유닛 : 모든 요소가 한번에 배포된다.
  • 작은 스펙 하나의 변경이 시스템 전체의 재배포를 요구한다.
  • 업데이트 크기와 관계없이 전체 배포과정을 모두 거쳐야한다 (테스트, CICD등)
• 도메인간 의존성이 강하다 : 도메인의 예제-> Auth, User, Product, Payment
  • 부분적인 업데이트 배포가 어렵다.
  • 하나의 섬세한 기술적 변경이 수많은 다른 요소들에 “큰 영향”을 끼칠 수 있다.
  • 유지 보수에 많은 리소스가 필요하고 새로운 인력 온보딩에 점점 더 많은 시간이 필요해진다.
• 확장성 : Scalability
  • 한 기능에 대한 확장만 필요하더라도 애플리케이션 전체를 확장해야한다

2. Microservice Architecture

Microservice Architecture는 애플리케이션을 작고 독립적인 서비스들을 도메인별로 나눠서 구현하는 방식이다. 각 서비스는 독립적으로 운영되고 네트워크를 통해 서로 통신하며 각각 따로 개발, 유지보수, 확장이 가능하다

• SRP : Single Responsibility Principle
  • 각 서비스가 비즈니스의 하나의 도메인을 맡아서 운영된다. 예) 인증, 사용자, 결제, 상품
  • 도메인 단위별 소스코드를 최소화 할 수 있어서 개발, 유지보수, 운영이 쉬워진다.
• 독립적인 운영
  • 서비스간 의존성이 약하다.
  • 하나의 서비스의 업데이트가 다른 서비스에대해 “큰 영향”을 미칠 가능성이 적다.
  • 각 도메인별로 팀을 꾸리고 운영하기 편리하다.
  • 탈중앙화된 데이터베이스 운영이 가능하다.
• 장애를 버티는 능력(?) : Fault Tolerance
  • 한 서비스에 “중대한” 문제가 생긴다고 해서 다른 서비스들이 모두 다운되지 않는다.
  • 예를들어 결제 서비스가 다운된다고 웹사이트 전체가 다운되지 않는다.
• 개발 난이도가 상당하다
  • MSA를 제대로 운영하기 위해 알고 있어야하는 지식이 너무 많다.
  • Monolithic보다 오히려 더 복잡해질 수 있다

2.1 Monolithic의 배포 독립성 문제

2.2 Microservice의 배포 독립성

2.3 Monolithic 배포 과정 문제

2.4 MSA 배포 과정

2.5 Monolithic 개발팀 구성

2.6 Microservice의 개발팀 구성

3. MSA의 주요 요소

MSA를 효율적으로 운영하기 위해서는 다양한 컴포넌트들이 서로 상호작용해야한다. MSA는 “개념”이기 때문에 설계하는 방법이 매우 다양하지만, 어느정도 “필수”로 생각되는 컴포넌트들이 존재한다.

API Gateway

• 모든 클라이언트 요청의 단독 엔트리 포인트 역할을 한다.
  • e.g. /user로 요청이 들어오면 user service로 라우팅을 하거나,
  • /auth로 요청이 들어오면 auth service로 라우팅을 한다.
• 공통적인 제한/로직을 담당한다. (e.g. 인증, Throttling, 캐싱, 로깅 모니터링)
• 보안 레이어 역할을한다. (e.g. 하나의 공통된 엔트리 포인트 역할을 하며 외부에 노출되는 표면면적을 줄여준다.)

Service Discovery

• 지속적으로 생성되고 삭제되는 서비스들을 쉽게 찾아낼 수 있도록 해준다.
• Health Check를 통해 장애가 있는 서비스들을 제외시킨다.

서비스간 통신 : Inter-service Communication

• 독립적으로 서비스를 개발 가능하다고 해서 서로 통신이 필요없는게 아니다.
• Sync (동기) : HTTP, gRPC
• Async (비동기) : RabbitMQ, Kafka, AWS SQS, Redis

독립 데이터베이스 : 필수사항 x

• 각 서비스별로 최적화된 데이터베이스를 사용 할 수 있다. (SQL, NoSQL등)

Distributed Logging & Monitoring

• Microservice는 너무 많은 서비스들이 분산되어 운영되기 때문에 로깅과 시스템 모니터링을 중앙화 할 필요가 있다.
• MSA가 복잡해질수록 서비스간 요청의 흐름을 파악할 필요성이 높아진다.

CI/CD Pipeline

• 서비스가 많아질수록 배포과정과 스크립트가 복잡해진다.
• 시퀀스가 정확히 짜여져있는 작업을 매번 수동으로 실행하는건 비효율적이다.
• 그렇기 때문에 MSA를 디플로이 할때 CICD는 사 실상 필수다.

Event Driven Architecture

• MSA는 서비스간 Async(비동기) 통신을 할 수 있는 시스템을 디자인하는게 중요하다.
• 모든 통신을 Sync(동기)로 진행하게되면 안정성이 부족해지고 스케일링이 복잡해진다

3.1 API Gateway

• 강력한 보안 레이어가 될 수 있다.\
• 통합된 인터페이스 제공이 가능하다.
• Single Point of Failure 또는 Bottle Neck이 될 수 있다.
• 최대한 가볍게 설계해서 리버스 프록시 역할에 충실하자

3.2 Service Discovery

• Monolithic Application은 모든 로직이 하나의 유닛으로 통합돼있으니 서비스간 통신이 필요없다.
• MSA는 각 마이크로서비스간 통신을 통해 다른 도메인에서 필요한 요소들을 불러 올 수 있다.
• 방법으론 대표적으로 Client/Server Side Service Discovery가 존재한다

3.3 Inter-Microservice Communication

• MSA는 서비스간 통신이 매우 중요하다.
• 각 서비스간 안정적이고 효율적으로 통신을 할 수 있어야하기 때문에 다양한 솔루션이 존재한다.
• 직접적인 요청/응답 형태를 다루는 Sync(동기) 형태의 통신과 Queue 방식을 사용하는 Async(비동기) 형태가 존재한다

3.4 독립된 데이터베이스

• 각각 Microservice의 완전한 독립을 위해 데이터베이스를 도메인별로 따로 구축 할 수 있다.
• 데이터베이스가 다운 됐을때 전체 시스템이 다운되지 않도록 해준다.
• 필수 사항은 아니다. MSA의 목적에 따라 앱/웹서버만 분리하고 데이터베이스는 하나 또는 공유 할 수 있다

3.5 Distributed Logging

• Monolithic Architecture가 아니기 때문에 단순히 파일에 로그를 생성하고 서버로 들어가서 볼 수 없다.
• 각 서비스에서 생성되는 로그들을 모두 통합해서 중앙화 한 후 분석해야한다.
• 로그를 기반으로 각 시스템의 현재 상태 (Health/Memory/Cpu)를 모니터링 할 수 있다

3.6 CI/CD 파이프라인

• MSA로 수많은 서비스를 수동으로 배포한다는건 말이 안된다. Human Error가 너무 많아진다.
• 개발 후 시스템적으로 문제를 파악하고 (CI 테스트등) 자동으로 빌드 및 패키징 후
  • 오케스트레이션(Kubernetes)에 배포 될 수 있도록 시스템을 구성해야 효율적으로 MSA 운영이 가능하다

3.7 Event Driven Architecture

• Microservice가 많아질수록 효율적으로 안정성을 보장하고 Scaling을 할 수 있어야한다.
• HTTP등 동기 방식으로 통신하면 Scaling이 어려워진다.
• Async 방식으로 아키텍처를 설계하면 서비스간 효율적인 decoupling이 가능해지고 설계가 효율적이다

4. 양날의 검 MSA

MSA를 “궁극적인 아키텍처”로 생각하면 절대 안된다. MSA가 전통적인 아키텍처의 많은 문제들을 해결해주지만, 동시에 많은 리소스를 필요로하고 설계 자체가 매우 난이도가 높다. 그래서 MSA를 구현함으로서 오히려 설계가 더욱 복잡해지고 개발 프로세스가 오히려 비효율적으로 변할 수 있다.

• MSA는 소프트웨어 규모가 커져서 점점 무거워지는 문제를 해결하기 위해 고안되었다.
  • Monolithic으로 설계해도 충분히 유지보수가 가능하다면 MSA를 할 필요 없다.
• MSA는 상당히 많은 기술들이 조화롭게 작동하는 상황을 요구한다.
  • MSA 자체가 ‘특정 기술’을 요구하는 아키텍처는 아니지만, 현실적으로 봤을때 많은 기술의 조화가 필요하다.
  • 즉, 다양한 기술을 능숙하게 활용 할 수 있는 기술자가 없다면 오히려 짐이 될 수 있다.
• MSA의 기본적인 인프라와 파이프라인 그리고 아키텍처를 유지하기 위해 어느정도 인력이 꼭 필요하다.
  • 물론 초 엘리트 개발 집단이라면 소수의 인원으로 구현 할 수도 있겠지만,
  • 직원들이 퇴사했을때 얼마나 효율적으로 대체하고 인수인계가 가능할지에 대한 부분도 고민 해봐야한다
• Monolithic Architecture보다 MSA를 운영할때 서버 인프라 최소 비용이 월등히 높다.

5. 오해하지 말자!

MSA는 Microservice Architecture다. 말 그대로 서비스를 작게 나눠서 독립적으로 개발 및 배포를 할 수 있으면 된다는 개념이다.

MSA가 Domain Driven Design, Clean Architecture, Onion Architecture, Hexagonal Architecture 등을 강제하지 않는다.

• 하지만 특정 아키텍처와 디자인 패턴을 사용하면 확실히 MSA 운영이 유리하고 조화가 좋아진다.
• 그렇기 때문에 큰 프로젝트에서는 다양 한 아키텍처를 함께 조합하여 사용하는 경우가 많다.
• 하지만 여건이 안된다면 MVC 패턴으로 MSA를 해도 틀린게 아니다.

고차원 아키텍처를 적용 할수록 복잡한 큰 규모의 프로젝트에서 유지보수와 개발이 편리해진다. 하지만 작은 프로젝트에서는 오히려 보일러 플레이트가 많아지고 빠르게 개발하는데 장애물이 될 수 있다.

좋은 소프트웨어 개발자는 비즈니스를 이해하는 소프트웨어 개발자다.

• 모든 개발에는 비즈니스를 위한 타협이 필요하다. 특히나 소규모 기업이라면 이 부분이 더욱더 중요하다.
• 사업의 진행을 위해 좋은 아키텍처를 무조건 포기하라는 이야기가 절대 아니다.
• 지금 당장 적용 해야하는 시점이라는 확신이 든다면 강력하게 밀고나가자.
• 하지만 “그냥 이게 좋다고 배웠기 때문에” 사용하는 개발자가 되지는 말자

물론 모르고 안쓰는것과 알고 안쓰는건 너무 다르다. 그러니 많은 지식을 습득한 후 프로젝트별로 현명한 결정을 내리길 바란다.

6. MSA 진행 개요

이 강의는 최소한의 NestJS Microservice 구현부터 시작해서 점차 기술을 붙여나가는 방식으로 진행하게 된다.

Microservice는 사용하는 것 만으로도 상당히 많은 챌린지와 문제들을 야기한다. 이 문제들을 해결하기위해 많은 개념들이 생겨났고 많은 기술들이 발명됐다. 하지만 이 모든걸 한번에 모두 적용할 필요는 없다. 소프트웨어에 무언가가 추가된다는건 유지 보수 비용이 더 많이 들고 더 많은 기술자가 필요하다는 뜻이다.

어떤 기술을 공부하고 그 기술을 꼭 실무에 사용할 수 있어야만 유용한건 아니다. 하지만 왠만하면 수강생들이 이 강의에서 배운걸 실무 에서 사용 해볼 수 있다면 좋을 것 같다. 그렇기 때문에 가장 무리하지 않는 규모로 Microservice를 진행하는 방법부터 차근차근 고도화된 기술들을 붙여가는 방식으로 강의를 진행할 계획이다.

이 강의에 나오는 모든 기술이 “MSA를 하려면 꼭 사용해야하는” 기술이라 생각할 필요없다. Docker와 Kubernetes같은 경우 사실상 사용 안하는게 더 어렵긴 하지만, DDD, Clean Architecture, Istio, CQRS, Kafka등 너무 많은 기술들이 대체 상품이 존재하고, “도입 하지 않을 용기”를 충분히 갖을만한 기술들이다.

그러니 이 강의에서 전달하는 “메세지”에 집중 했으면 좋겠다. 어떤 기술이 어떤 문제를 해결 할 수 있고, 반면에 어떤 단점이 있는지 잘 이해한다면 내 팀과 프로젝트에 가장 적당한 규모의 MSA를 할 수 있을거라 생각한다.

💡 프로젝트 기능 플로우

사용자 인증 → 주문 발행 → 상품 확인 및 가격 검증 → 결제 → 알림

6.1 구현할 Microservice Domain

6.2 구현할 Microservice Domain 구조

6.3 코드 아키텍처 발전 시키기

6.4 다양한 네트워킹 방법 배우기

6.5 컨터이너화 & 오케스트레이션

6.6 패턴 적용

6.7 모니터링과 로깅