[5분 내로] MSA의 특징과 주의사항 그리고 도입 이유

안녕하세요. 팀드모네입니다.

지난시간으로 사전 설명이 끝났으니,

오늘은 본격적으로 MSA(Micro Service Architecture)가 무엇인지 알아보도록 하겠습니다.

 

👨‍💻  MSA(Micro Service Architecture)란?

- 시스템을 여러 개의 독립된 서비스로 나눠서, 이 서비스를 조합함으로서 

기능을 제공하는 아키텍쳐 디자인 패턴

 

👨‍💻 MSA의 핵심은?1. 다른 팀의 스토리지에 직접 엑세스 금지

2. 공유메모리, 백도어 금지

3. 팀 간의 커뮤니케이션은 서비스 인터페이스로만 이뤄져야한다.

4. 모든 서비스 인터페이스는 예외없이 외부에서 이용 가능해야한다.

* 오직 api나 네트워크로 각 서비스를 연결하라는 의미. 공유메모리..등 금지는 뒷문 만들지 말라는 의미. 

 

👨‍💻 MSA의 특이사항은?

 

- MAS는 서비스를 독립적으로 구축하고 배포한다는 점입니다.

- MSA는 각 서비스마다 DB를 가지고 있고 서로 API로 통신을 한다는 것이 핵심. 

* MSA의 생명은 기존 모놀리틱의 거대한 DB를 얼마나 잘 쪼개는지에 달림.

 

👨‍💻 MSA는 Cloud Native의 개념으로 구현하는 이유?

- 서버가 죽었는지 알기 힘듦.

- 문제가 있을 때 파악이 안됨.

 

* 적은 사람이 많은 MAS를 관리할 때, 일이 너무 어려워진다.

 

👨‍💻 MSA를 구축해야하는 이유?

- 기존 방식은 서버 재기동에 오랜 시간이 걸림

* 주의) MSA가 기존 모놀리틱에 비해 성능이 월등히 뛰어난 것이 아님.

 

- 책임소재가 명확 : 기능별로 서비스를 구현하고 관리한다는 것이 독특합니다. 아무튼 각자 기능들이 소규모로 제작되며 API로 호출되므로 "현업자"는 장애가 어디서 나는지 알게됩니다.

 

- 빠른 장애복구 기대 : 서비스에서 장애가 났을 때 과거와 달리 장애가 발생한 서비스만 보면 됩니다. 장애에 대한 빠른 복구가 기대되는 것이죠. 그리고 서비스가 독립적이다 보니 기본적으로 타 서비스에 미치는 영향이 적습니다. 과거에는 단순한 기능 하나를 수정해도 전체 기능에 대한 QA 즉, 기능 테스트가 필요했습니다. 버그를 수정했더니 더 심한 버그가 생산되는 일도 비일비재했는데 그런 일이 좀 줄어들 것으로 기대됩니다.

 

- 출시기간 단축 : 

각자 개발이 가능합니다. 예를 들어서, 12명의 개발자가 있으면 각자 한 개씩 서비스를 맡아서 개발을 진행할 수 있다는 것이죠. 앞사람이 하던 개발이 끝날 때까지 기다릴 필요 없이, 담당하는 시스템에 바로 투입될 수 있습니다.

 

그리고 제가 개인적으로 생각하는 마이크로 서비스의 최고의 장점은 과거와 달리 장애가 발생하더라도 전체 애플리케이션이 죽지 않는 점이네요. 시스템 유지보수 담당자님께서 토요일 새벽 3시에 전화를 받고 일어나서 회사로 뛰어가는 일은 줄어들지도 모르겠습니다.

---

reference : https://www.youtube.com/watch?v=ZfFj4hOLQKc

광고 링크 : https://ogx4.com

2023년 온라인 게임 전시회 - 온라인 게이머엑스포

---