MSA(Microservice Architecture)

MSA(Microservice Architecture)

Posted by 동식이 블로그 on July 10, 2019

MSA(Microservice Architecture)

  • MSA에 대해 궁금해진 이유
    • 영화추천페이지를 만드는 프로젝트를 진행할 당시 우리조를 제외한 나머지 조는 django를 이용해 WebServer를 구성했지만 우리조는 client server와 rest api server로 분리해서 진행했기 때문에 MSA에 대한 이해가 필요했다
    • 강사님이 지금 당장 분리하기에는 어려운 작업이 될거라는 말을 해주신건 비밀

마이크로 서비스 아키텍처 스타일은 단일 응용 프로그램을 나누어 작은 서비스의 조합으로 구축하는 방법이다

Martin Fowler

img

  • 하나의 프로젝트가 프레젠테이션, 비즈니스, 데이터베이스 계층으로 구분되던 것을 하나의 서비스가 하나의 프로젝트로서 프레젠테이션, 비즈니스, 데이터베이스 계층을 가지게 됨을 의미한다
  • 즉 각각의 서비스 별로 프로젝트가 생기게 되며, 하나의 서비스가 문제가 생긴다고 해서 다른 서비스에 영향을 주지 않는다.
Method로 호출하면 되는 걸 왜 굳이 REST 방식으로 호출하고, 잘 돌아가는 프로젝트를 굳이 시간을 들여 나누어서 얻을 수 있는 장점은 ?

1. 빌드 및 테스트 시간을 단축시킬 수 있다.

30개의 서비스를 가진 Monolithic 의 빌드 시간이 30분이었다면, MSA는 각각의 서비스를 1분 만에 빌드 할 수 있다. 이는 CI / CD를 추구하는 기업에서는 좀 더 적합한 모델이 된다. 왜냐하면 하루에도 몇 번을 빌드 및 배포를 해야 하는데 그때마다 많은 시간을 소모하게 된다면 낭비이기 때문.

CI/CD : 지속적통합 / 지속적배포

  • CI(Continuous Integration) : 개발자들이 애플리케이션에 적용한 변경 사항이 버그 테스트를 거쳐 리포지토리에 자동으로 업로드되는 것을 뜻함. 운영팀이 이 리포지토리에서 애플리케이션을 실시간 프로덕션 환경으로 배포할 수 있다. 이는 개발팀과 비즈니스팀 간의 가시성과 커뮤니케이션 부족 문제를 해결해 준다. 지속적인 제공은 최소한의 노력으로 새로운 코드를 배포하는 것을 목표로 한다.
  • CD(Continous Deployment) : 개발자의 변경 사항을 리포지토리에서 고객이 사용 가능한 프로덕션 환경까지 자동으로 릴리스하는 것을 의미. 이는 애플리케이션 제공 속도를 저해하는 수동 프로세스로 인한 운영팀의 프로세스 과부하 문제를 해결. 지속적인 배포는 파이프라인의 다음 단계를 자동화함으로써 지속적인 제공이 가진 장점을 활용한다.

참고사이트

RedHat- CI/CD란 무엇일까요?

2. 폴리글랏 아키텍처 구성이 가능하다.

상황에 맞게 기술을 유연하게 적용할 수 있다. 예를 들어 TPS(시간당 트랜잭션)가 높고, 읽기 작업이 많은 서비스에는 Node + Redis로 구현을 하고, 트랜잭션 및 안정성이 중요한 서비스에는 Spring + RDB를 적용할 수 있다.

폴리글랏(polyglot) : 여러 언어를 구사하는 것을 말한다

3. 탄력적이고 선택적인 확장이 가능하다.

MSA는 작은 단위의 작업이라서 필요한 서비스만을 선택적으로 확장할 수 있다. 만약, 주문 서비스와 이벤트 서비스의 사용률이 90 : 10 이라면 이벤트 서비스만을 선택적으로 확장(scale out) 할 수 있다.

4. 하나의 서비스가 다른 서비스에 영향을 주지 않습니다.

책을 무료로 주는 이벤트를 한다고 가정을 할 때 이벤트 서비스에 트래픽이 몰려 해당 서버가 죽더라도 다른 서비스에는 영향이 가지 않는다. 각 서버마다 서비스를 놓기 때문.

서비스를 분리함으로써 생기는 문제점

1. 성능 이슈가 있다.

Monolithic은 다른 서비스 간의 상호작용이 필요할 시에는 Method 호출을 이용한다. 즉 이러한 행위는 메모리 안에서 일어나는데, MSA와 같은 경우에는 주로 HTTP를 사용한다. 이는 Network IO를 통하여 다른 서버까지 갔다 다시 와야 됨을 의미한다. 요즘은 하드웨어나 기술이 많이 발전했고 성능보다는 유지 보수에 좀 더 무게중심을 둔다는 점을 미뤄볼 때, 개인적으로는 Client가 크게 체감하지 못할 정도면 MSA의 장점에 좀 더 손을 들어줘도 될 거 같다.

2. 트랜잭션이 불편하다.

MSA에서는 서비스 간에 Global 트랜잭션이 일어나는 상황보다는 Local 트랜잭션이 주로 이루어지게 경계를 나누고, 불가피하게 서비스 간에 트랜잭션이 필요하면 트랜잭션 로직을 추가한다.

3. 관리 포인트가 늘어난다.

Monolithic은 간단한 경우 어플리케이션서버와 DB 서버 두 개를 관리하면 되지만, MSA에서는 기본적으로 서비스 수 * 인스턴스만큼의 서버 (경우에 따라 DB)가 존재하고 서버가 늘어난 만큼 로깅, 모니터링, 배포, 테스트, 클라우드 환경에서의 관리들은 부담스럽다. 이러한 문제는 관리에 들어가는 비용을 줄이기 위해 자동화와 간단하게 모니터링할 수 있는 환경을 권장한다.

  • 위 글을 정리한 블로그가 Java / Spring에 맞춰서 설명되어 있기 때문에 Python / Django로 생각을 다시 해봐야 내것이 된다 !!

참고사이트

민수’s 기술 블로그- MSA #2 Microservice Architecture 란?