MSA

개념

MSA(Micro Service Architecture) : 하나의 서비스를 여러개의 서비스로 나눠서 응집도를 높이고 결합도를 낮춘 아키텍처이다.

 

등장 배경

요구사항 변화에 따른 빠른 대처(협업, 커뮤니케이션, 확장성, 유연성, 결합도, 응집도, 빌드, 배포)를 하기 위해서 개발된 아키텍처이다. 

Cloud + 컨테이너 가상화(Docker) + 오케스트레이션(k8s) 기술 보편화로 인해 자주 사용된다. 

 

장단점

• 장점
  • 장애가 다른 서비스에 영향을 주지 않는다.
  • 필요한 서버에만 Scale-out 이 가능하여 비용면에서 효율적이다.
  • 개발/유지보수 시 고려할 요소(다른 서비스에 주는 영향)가 줄어든다.
  • 개발 시 각 서비스에 맞는 최적의 기술스텍 선택이 가능해진다.
  • 배포가 덜 부담스럽다. (유지보수 할 때마다 전체를 다시 배포할 필요가 없어진다.)
• 단점
  • 서버간 통신이 증가하여 비용이 증가한다.
  • 다른 서비스가 사용중인 서버에 배포가 불가능하다.
  • DB 서버가 분산되어 있어서 roll back을 고려한 트랜잭션 처리가 필요하다.
  • DB 서버가 분산되어 있어서 Join 연산을 고려한 데이터쿼리 처리가 필요하다.
  • 서버가 분산되어 있어서 로그, 메트릭도 분산되어 있다. 

 

가능 여부 확인

1. MSA 구조와 각 서비스의 통신에 대한 기본적인 아키텍처를 이해하고 있나요?
2. 어려워진 트러블슈팅과 모니터링 난이도를 해결하기 위한 스택(EFK, Prometheus, Elastic Search, Grafana, ... ) 들 구축을 적절하게 할 수 있는 상황인가요 ?
3. MSA/Cloud 환경에 대한 적절한 보안을 책임질 수 있는 보안 담당자가 존재하나요?
4. CI/CD 파이프라인을 위한 Devops/SRE 조직이 별도로 존재하고 트러블 슈팅을 위한 인프라 지식이 있나요?
5. 사내 엔지니어링 최고 책임자가 MSA 전환에 대한 충분한 필요성을 느끼고 공감하나요?

 

 해결법

트랜잭션

• 문제 상황 : DB 서버가 분산되어 있기 때문에 roll back시 문제가 발생한다.
• 해결 방법 : Saga(2PC(2번 commit) + 보상 트랜잭션(실패하면 보상 트랜잭션 날리기))

데이터 쿼리

• 문제 상황 : DB 서버가 분산되어 있기 때문에 Join 연산 시 문제가 발생한다.
• 해결 방법 
  • API Aggregation : API를 통해 필요한 도메인 데이터를 가져온다 -> 필요에 맞게 합친다.
  • CQRS : Command(CUD) 작업과 Query(R) Endpoint 분리 -> 원하는 포멧대로 Query 데이터 구조 만들기

모니터링

• 문제 상황 : 서버가 분산되어 있기 때문에 로그, 메트릭도 분산되어 모니터링이 어렵다.
• 해결 방법 : 중앙집중 및 필터링 가능하도록 Prometheus(데이터 수집), ES(데이터 저장), Grafana(시각화)를 사용한다.

장애 복구

• 문제 상황 : scale-out 전략 시 과부하가 걸린 서버에 트래픽을 보내는 것은 비효율적이다.
• 해결 방법 : Circuit break(서버에 장애가 발상하면 해댱 경로 차단) -> 서버가 복구 되면 다시 복구

무정지 배포

• 문제 상황 : 트래픽이 발생하는 서버는 배포가 불가능하다.
• 해결 방법 : 배포할 때 트래픽 안오게한다. -> 다 배포하면 Warm up으로 확인 -> 다시 트래픽 오게한다.