MSA

✏️ Monolith Archtecture

• 모놀리스 아키택쳐는 MSA 와 반대되는 개념이다.
• 모놀리스 아키택쳐는 하나의 application 에 모든 서비스를 포함시키는 설계를 뜻한다.

📍 단점

• 하나의 서비스에 문제가 생길경우 모든 서비스가 마비될 수 있다.
• 특정 서비스를 업데이트하거나 유지보수 하기가 매우 까다롭다.

✏️ MSA - Micro Service Archtecture

• 각 Service 를 독립적인 Service 로 운영한다.
• 각 Service 가 필요할 때마다 필요한 Service 만 동작 시키는 방식이다.
  • 만약 특정 Service 가 실행되기 위해선 다른 Service 의 작업이 선행되야 할 경우 그 Service 에 필요한 data 를 응답받고 요청을 수행할 수 있다.

📍 장점

• 업데이트와 유지보수를 신속하게 수행할 수 있다.
  • 각 Service 는 독립적으로 운영되기 때문에 다뤄야 하는 Service 의 크기가 보다 작다.
• 각 Servcie 의 특성에 맞게 tool 들을 다르게 적용시킬 수 있다.
• 특정 Service 의 트래픽이 많다면 해당 서버의 규모만 타겟해 키워 클라우드 자원을 효율적으로 운영할 수 있다.

📍 MSA 를 위한 서포팅 툴

• Docker
  • 독립적인 다양한 Service 들을 하나의 Container 에 담아 관리할 수 있는 서비스
• Kubernetes / Docker Swarm
  • Container 가 많아질경우 많은 Container 를 한번에 관리할 수 있는 서비스
• Kafka
  • 서비스간의 메시지를 신속하게 주고 받을 수 있게해주는 서비스
• Prometheus / kiali ?
  • 각 Service 들을 모니터링 할 수 있게 해주는 서비스
• 이 외에도 서비스 배포를 자동화 하고 편리하게 하기위한 툴들도 있다.

📍 MSA 의 단점

• 규모가 커질수록 서비스의 복잡도가 매우 커진다.
  • MSA 를 채택하면 개발 복잡도는 낮출 수 있지만,
    운영 복잡도는 포기해야하는 트레이드 오프 관계이다.
  • Service 가 많을 수록 서포팅 툴을 많이 사용해야하기 때문에 서포팅 툴을 관리하는 비용이 추가된다.
• Servcie 간의 통신이 많을경우 지연시간이 길어지거나 누락되는 경우도 있다.
• 특정 Servcie 를 실행하기위해 필요한 정보를 어느 Service 에 요청해야 할지 찾기가 어렵다.
• 특정 Service 에 문제가 생길경우 어느 Service 에 원인이 있는지 찾아내기가 힘들어진다.