한이음 - MSA를 공부하면서 고민했던 것들.

MSA(Microservice Architecture) 란?

출처: https://steady-coding.tistory.com

위 사진처럼 하나의 큰 애플리케이션을 여러 개의 작은 애플리케이션으로 쪼개어 변경과 조합이 가능하도록 만든 형태로 마이크로서비스는 완전히 독립적으로 배포가 가능하고, 다른 기술 스택이 사용 가능한 단일 사업 영역에 초점을 둔다. 때문에, 독립된 서비스는 API를 통해서 상호작용한다.

요약)
마이크로 서비스는 Cloud Native Architecture의 핵심
전체 서비스들을 구축하고 있는 개별적인 모듈이나 기능들을 독립적으로 개발하고 배포할 수 있도록 운영화된 서비스

MSA 특징 정리

1. 기존 모놀리스 개발 방식에서 변경할 것이 많다.
2. 독립적으로 배포 가능한 형태의 서비스로 이루어진다.
3. 각 서비스 구분을 잘 경계해야한다.
4. 서비스는 RestFul을 권장한다.
5. 환경 정보나, 설정 정보는 외부 시스템을 통해 관리한다.
6. Cloud Native 기술을 최대한 활용한다.
7. 부하 분산 처리나 Scale Up, Scale Down 등을 동적으로 처리 가능해야 한다.
8. CI/CD가 중요하다.
9. 마이크로서비스들은 시각화할 수 있는 관리도구를 같이 가지고 있어야 한다.

---

프로젝트 시작 전 MSA 개발 방식을 보면서 생긴 의문

출처: https://steady-coding.tistory.com

Monolithic Architecture 에선, 하나의 데이터베이스로 애플리케이션 모든 구성 요소가 한 프로젝트에 통합되어 있었다. 즉, JPA ORM을 활용해, 각 테이블을 객체지향적으로 연관 관계 매핑을 했다.

하지만, MSA는 각 서버마다 데이터베이스를 두기 때문에 다음과 같은 의문이 들었다.

• 기존 개발 방식에서 Join으로 데이터를 한번에 가져오던 방식과 API를 통해 가져오는 방식은 어떤 차이가 있을까?
• 기존 공통 로직은 어떻게 처리해야 할까?
• 여러 서비스에서 공통으로 부르는 모듈 부하에 대해 어떻게 해야 할까?
• 롤백은 어떻게 처리해야할까?

MSA는 정말 정답인가? 그게 아니라면 무엇을 고려해야 할까?

• 각 서비스를 운영함에 있어서 서비스 경계가 잘 만들어져 있는지, 고민해야 할 것이다.
• 독립적인 확장이 가능한가? 즉, Scale Out 환경에 적합한가?
• 오류가 난다면 해당 오류는 격리된 오류인가?
• 외부 종속성과 상호작용을 단순화 시켜야 하지 않을까?
• 여러 언어 기술을 지원할까?

Cloud Native 기술을 최대한 활용하기 위해 고려해야할 항목들은 무엇이 있을까?

• 형상관리를 위해 각 마이크로서비스들에 대한 코드를 한 곳에서 배포하자.
• 각 모듈의 독립성을 위해서 종속성을 배제하자.
• 코드 외부에서 환경 설정 작업을 제어하자.
• 백업 서비스를 분리하자.
• 코드 배포를 위해 개발 환경과 테스트 운영 환경을 분리하자.
• 각 마이크로서비스들은 실행 중인 다른 서비스와 분리된 채 독립적으로 실행할 수 있게 하자.
• 각 마이크로서비스는 포트가 있어야 한다.
• 동시성을 가지고 있어야 한다.
• 서비스 인스턴스 자체가 삭제될 수 있어야 하고 확장성 기회를 높이고, 정상적인 종료를 할 수 있어야 한다.
• 개발 단계와 프로덕션 단계를 구분할 수 있어야 한다. 즉, 종속적이지 않은 상태에서 서비스가 유지 가능해야한다.
• 로그를 출력하는 로직은 분리되어야 한다.
• 관리 도구가 있어야 한다.
• 인증과 인가는 필수이다.
• 모든 지표는 시각화되어 관리돼야할 항목이다.
• API 구축이 먼저이다. 즉, 사용자 측에서 어떻게 사용할 지 먼저 고민하자.

---

 

공통 로직

현재 MSA를 적용하고자 하는 시스템에서 분석/설계 기법으로 많이 언급되는 것이 DDD(Domain Driven Design)이다. 그리고 MSA 시스템에서 설계라 하면 분산 및 Scale Out을 위한 아키텍처를 고려한 분산 시스템 설계라 생각한다.

근데 이제 설계를 시작하다보니, 설계 전에 들었던 고민처럼, MSA 반영으로 공통 로직을 API 방식으로 여러 곳에서 호출할 기회가 많아져서 여러 서비스에서 공통으로 부르는 로직에 대한 부하를 고려해야겠다는 생각이 들었다.

예를 들어, 위 사진처럼 Scale Out 되어 서비스 호출 시, Sacle Out 하지 않은 공통 서비스에 문제가 생기면 서비스 1, 2, 3이 다운될 수 있다. 그렇다면, 공통 로직을 각각 서비스에서 재개발하는 게 낫지 않을까? 혹은 공통 로직을 가지고 있는 서비스도 Scale Out 해야 하지 않을까?

 

그렇다면, MSA 시스템에서 공통 모듈은 어디까지 공통화 시키는 것이 가장 효율적인 것일까? 먼저 공통 서비스가 많은 것은 MSA 시스템에 좋은 영향을 주지 않을 것이다. MSA 시스템을 구축하면서 공통화된 공통 모듈 때문에 MSA 도입에 대한 가장 큰 효과가 있는 독립적인 배포가 훼손되기 때문이다. 즉, 공통 기능도 어떻게 설계해야할 지 고민해야한다. 혹은 아예 없는 것이 나을 수도 있다.

 

연관 관계

Join 설계는 성능하고도 연관이 된다. 즉, 대량의 데이터를 반복문을 돌려 하나씩 API를 통해 호출한다면 그 성능은 최악일텐데, API 통신을 해야하는 분산된 서비스에서는 어떻게 해결할까?

 

MSA가 정답은 아니다.

기술 측면

• 함수 호출이 Network I/O 호출로 바뀌게 되기 때문에 서비스간 상태 동기화가 어려워진다.
• Database 분리로 인해 Join 설계가 어렵다.

운영 측면

• 관리해야 할 서비스가 많아진다.