MSA란?

1. MSA(마이크로서비스 아키텍처)는 왜 필요한가? 🌐

마이크로서비스 아키텍처(MSA)는 현대 소프트웨어 개발에서 유용하게 적용되는 아키텍처 패턴 중 하나로 많은 회사들이 MSA를 활용하고 있는데 MSA의 장점으로는 아래와 같습니다.

• 확장성 및 유연성: MSA는 각 서비스가 독립적으로 배포되고 운영될 수 있기 때문에 특정 서비스의 확장이나 업데이트가 전체 시스템에 미치는 영향이 적습니다. 모놀리스의 경우 한 곳에 모여있기에 다른 클래스의 경우 쉽게 가져다 쓸 수 있지만 이로 인해 결합도가 높아지는 경향이 있습니다.

• 빠른 개발 및 배포: 각각의 서비스는 독립적으로 개발, 테스트, 배포되므로 전체 시스템의 개발 주기가 단축되고, 신규 기능이나 수정된 기능을 빠르게 배포할 수 있습니다. 기존 모놀리스 아키텍처의 경우 한 곳만 수정해도 처음부터 다시 테스트, 배포 과정을 거쳐야 하므로 느릴수 밖에 없습니다.

• 기술 다양성 지원: 각 마이크로서비스는 독립된 기술 스택을 사용할 수 있어, 최적의 기술을 선택하여 사용할 수 있습니다.

2. 모놀리식 vs MSA 🔄

모놀리식 아키텍처:
모놀리식 아키텍처는 하나의 큰 코드베이스로 구성되어 전체 시스템을 단일한 애플리케이션으로 통합하는 아키텍처입니다. 이러한 접근 방식은 초기에는 코드의 관리가 편리하며, 작은 규모의 프로젝트에 적합합니다. 하지만 몇 가지 단점이 존재합니다.

1. 전체 시스템의 일관성 유지 어려움: 특정 기능을 수정하면 전체 시스템을 다시 빌드하고 배포해야 하므로 일관성을 유지하기 어렵습니다.

2. 단일 장애 지점: 시스템의 일부분에 장애가 발생하면 전체 시스템이 영향을 받을 수 있습니다.

3. 확장성 제약: 특정 기능을 확장하려면 전체 애플리케이션을 확장해야 하기 때문에 확장성이 제약될 수 있습니다.

MSA:
마이크로서비스 아키텍처(MSA)는 여러 작은 서비스로 시스템을 나누어 구성하는 아키텍처 패턴입니다.

1. 독립적인 배포와 확장: 각 서비스는 독립적으로 개발되고 배포되며, 서비스 간에는 통신 인터페이스를 통해 상호 작용합니다. 이는 특정 서비스의 변경이 전체 시스템에 미치는 영향을 최소화합니다.

2. 기술 다양성과 빠른 개발 주기: 각 서비스는 자체 기술 스택을 가질 수 있어 기술의 도입이 용이하며, 빠른 개발 주기를 지원합니다.

3. 장애 격리 및 확장 용이성: 특정 서비스의 장애가 다른 서비스에 미치는 영향이 적고, 필요한 부분만 확장할 수 있어 전체 시스템의 확장성이 용이합니다.

비즈니스 측면에서의 고려사항:
모놀리식의 경우 작은 기능 변경이라도 전체 시스템을 다시 배포해야 하기 때문에 빠른 변화에 대응하기 어려울 수 있습니다. 반면 MSA는 작은 팀들이 각자의 서비스를 독립적으로 개발하고 배포할 수 있어, 더 빠른 개발 주기와 기능의 빠른 출시가 가능합니다.

예를 들어, 주문 서비스가 변경되어 새로운 기능을 추가해야 하는 경우 MSA에서는 주문 서비스만 업데이트하고 배포할 수 있습니다. 반면에 모놀리식에서는 주문 서비스를 수정한 후 전체 시스템을 배포해야 합니다. 따라서, MSA는 빠른 시장응답과 더 높은 유연성을 제공할 수 있습니다.

3. MSA에서의 장점과 단점 🌟👎

장점:

1. 확장성과 유연성: MSA는 각 서비스가 독립적으로 확장 가능하므로 특정 기능에 대한 확장이 효과적입니다. 또한, 각 서비스의 독립성으로 빠른 개발 주기와 유연한 업데이트가 가능합니다.

2. 기술 다양성: 각 서비스는 자체적인 기술 스택을 가질 수 있어 최신 기술의 도입이나 특정 작업에 적합한 기술을 선택하여 사용할 수 있습니다.

3. 고가용성: 특정 서비스의 장애가 전체 시스템에 미치는 영향이 적어 고가용성이 향상됩니다.

단점:

1. 운영 및 관리 복잡성: 여러 서비스 간의 통신과 관리가 복잡해지며, 서비스 디스커버리, 로드 밸런싱 등을 고려해야 합니다.

2. 분산 시스템 복잡성: 서비스 간의 통신, 데이터 일관성 등의 문제로 분산 시스템 복잡성이 증가하고, 트랜잭션 처리 등에 대한 고려가 필요합니다.

3. 러닝 커브 존재: MSA의 적용은 초기에는 학습 곡선이 존재하며, 올바른 방식으로 마이크로서비스를 설계하고 관리하기 위해 노력이 필요합니다.

4. 트랜잭션 처리의 어려움: 분산된 환경에서 트랜잭션 처리가 복잡하며, 2PC, 보상 트랜잭션, Saga 패턴 등의 해결책을 고려해야 합니다. (그래서 최대한 트랜잭션을 사용하지 않는 방향으로 나아가는 것이 좋습니다.)

5. 서비스 디버깅 어려움: 분산된 서비스들의 통신이 증가하므로 문제 발생 시 디버깅이 어려울 수 있습니다.
   한 예로 client -> A -> B -> C 로 이루어져 있는 경우 client가 잘못된 응답을 받을 경우 해당 문제가 A에서 발생했구나라고 생각 할 수 있지만 실제로는 A,B,C 중 어느 곳에서 발생했는지 알기 어렵습니다. (B에서 잘못된 경우에도 A는 에러 응답을 낼 수 있기 때문...)

6. 모니터링 어려움: 각각의 서비스가 독립적으로 운영되기 때문에 전체 시스템의 통합 모니터링이 어려울 수 있습니다. 서비스 디버깅이 어려운것과 같은 맥락으로 이해하면 될 것 같습니다.