24.12.02 TIL MSA

1. MSA란?

Microservices Architecture(마이크로서비스 아키텍처)는 애플리케이션을 독립적으로 개발, 배포, 운영할 수 있는 작은 서비스 단위로 나누는 설계 방법입니다.
각 서비스는 특정 비즈니스 기능을 담당하며, 독립적으로 확장 및 유지보수가 가능합니다.

---

2. MSA의 주요 특징

1. 서비스 단위 분리

   • 각 서비스는 독립적으로 개발, 배포, 운영됩니다.
   • 예: 사용자 관리 서비스, 결제 서비스, 알림 서비스

2. 독립 배포 가능

   • 다른 서비스에 영향을 주지 않고 개별적으로 배포 가능합니다.

3. 분산 시스템

   • 모든 서비스가 서로 다른 네트워크 위치에서 통신하며 협력합니다.

4. 폴리글랏 프로그래밍

   • 각 서비스는 적합한 언어와 데이터베이스를 자유롭게 선택할 수 있습니다.

5. 경량화된 통신

   • 서비스 간 통신은 주로 REST API, gRPC 또는 메시지 큐(Kafka, RabbitMQ) 등을 사용합니다.

---

3. MSA의 장점

• 확장성: 트래픽이 많은 서비스만 별도로 확장 가능
• 유지보수성: 코드가 분리되어 있어 특정 서비스의 변경이 다른 서비스에 영향을 미치지 않음
• 팀 분리: 각 서비스가 독립적이므로, 팀을 서비스별로 나눠 개발 속도 증가
• 유연성: 각 서비스별로 적합한 기술 스택과 데이터 저장소 선택 가능
• 장애 격리: 특정 서비스에 장애가 발생해도 다른 서비스는 정상 작동 가능

---

4. MSA의 단점

• 복잡성 증가: 서비스가 많아질수록 관리와 배포가 어려워짐
• 네트워크 비용: 서비스 간 통신이 빈번해 네트워크 비용 및 지연 시간 증가
• 분산 데이터 관리: 각 서비스가 독립적인 데이터베이스를 가질 경우, 데이터 동기화가 어려움
• 테스트 어려움: 여러 서비스가 협력하는 경우, 통합 테스트가 복잡해짐
• 배포 자동화 필요: CI/CD 파이프라인 없이는 배포 작업이 매우 번거로워짐

---

5. MSA와 Monolithic 비교

특성	Monolithic	MSA
구조	단일 애플리케이션	독립적인 여러 서비스
배포	전체 코드 기반	개별 서비스 단위로 배포
확장성	수평 확장 어려움	특정 서비스만 확장 가능
기술 스택	단일 기술 사용	다양한 기술 사용 가능
장애 영향	전체 시스템 다운 가능	부분 장애로 격리 가능

---

6. MSA 설계 시 고려사항

1. 서비스 경계 정의

   • 각 서비스가 어떤 책임을 질지 명확히 정의
   • 비즈니스 도메인별로 서비스 나누기(Domain-Driven Design)

2. 통신 방식

   • RESTful API, gRPC, 메시지 큐 사용 여부 결정

3. 데이터베이스 설계

   • 각 서비스별 독립적인 데이터베이스를 사용(분산 데이터 관리)

4. 서비스 레지스트리

   • Eureka, Consul 같은 툴로 서비스 검색 및 관리

5. 장애 복구 및 로깅

   • 장애 복구를 위한 Circuit Breaker 패턴 사용
   • 서비스 간 호출 로그를 남기기 위해 분산 로깅 시스템 도입(Logstash, ELK Stack).

6. 배포 및 관리

   • Docker와 Kubernetes 같은 컨테이너 및 오케스트레이션 툴 활용
   • CI/CD 파이프라인 구축으로 자동 배포 시스템 구현

---

7. 마무리

• MSA 도입 초기 어려움: 서비스 경계를 정의하고, 데이터 모델을 분리하는 것이 쉽지 않습니다.
• CI/CD의 중요성 실감: 여러 서비스를 동시에 배포하기 위해 Jenkins와 Docker를 활용한 경험이 유용합니다.
• 모니터링의 필요성: Prometheus와 Grafana를 사용해 실시간으로 서비스 상태를 체크하는 것이 중요하다 생각 했습니다.
• 장애 대응력 향상: Circuit Breaker와 메시지 큐를 도입해 장애가 발생해도 시스템 전체가 멈추지 않도록 설계해야 하는 것을 알았습니다.