MSA

MSA (Microservices Architecture)

커다란 Monolith 백엔드를 작은 서비스로 나누고 각 서비스를 독립적이고 느슨하게 결합되게 만드는 아키텍처

전 GitHub CTO, "지난 10년간 가장 큰 아키텍처 실수는 풀 마이크로서비스로 전환한 것"

Monolith

• 프론트, 백엔드 (API, DB)를 하나의 팀, 하나의 프로젝트에서 함께 만들어 수정 및 배포를 진행

• 프론트 사이드, 백엔드 사이드 일부분을 수정하더라도 적용하려면 전체 프로그램을 배포해야함

• 작은 부분을 변경해도 전체에 영향을 미치는 통합된 하나의 시스템을 의미

Frontend & Backend

• 많은 인원이 동시에 효율적으로 작업할 수 있도록 프론트엔드, 백엔드로 팀을 분리

• 나뉜 프론트와 백엔드는 API 인터페이스 기반으로 소통하며 개발하고 배포도 독립적으로 진행

"시스템을 설계하는 조직은 조직의 의사소통 구조를 빼닮은 구조의 디자인을 만들게 된다." - 콘웨이의 법칙

Frontend & Microservice Backend

• 백엔드는 백엔드 서비스를 더욱 전문적으로 고도화시킬 목적으로 마이크로서비스를 도입

• 기능적으로 나뉜 여러 백엔드 서비스들과 프론트엔드 사이의 비효율성을 개선하기 위해 BFF 와 GraphQL이 유행하게 됨

Aggregration Layer (e.g. BFF, GraphQL...)

여러 백엔드 서비스에서 오는 다양한 메시지 규격 또는 데이터 형식을 통일된 표준 형식으로 가공하고 제공해줌으로써 프론트엔드 개발자들이 일관된 데이터 구조를 다룰 수 있게 한다.

Aggregation Layer를 활용하여 점진적으로 MFA로 전환하는 방식을 고려

• BFF(Backend For Frontend) → 여러 백엔드 서비스들과 프론트엔드 사이에 낀 프론트엔드를 위한 중개 서버

  • 여러 백엔드사이드의 메시지 규격을 통일화 시켜주는 역할

  • 특정 응답값을 얻기 위해 여러 백엔드 서비스를 호출해야 하는 경우

  • 브라우저 통신에 노출 위험이 있는 데이터들을 보관 해야하는 경우

  • 프론트엔드에서 고비용의 복잡한 연산작업을 BFF에 위임하여 추상화된 인터페이스를 제공

• GraphQL→ Graphql의 schema(규격)을 제공해줌으로써 필요한 데이터만을 요청

  • 단일 엔드포인트로 모든 데이터 요청을 처리

  • 백엔드 서비스로부터 데이터를 가져오는 방법을 표준화

REST API의 단점 → 규격이 없다.

End point만 있고 규격은 개발자가 문서화해서 알려주거나 응답의 메시지를 보고 확인하는 방법 뿐

Micro Frontends

"독립적으로 제공 가능한 프론트엔드 애플리케이션이 모여 더 큰 구조로 구성되는 아키텍처 스타일"

백엔드의 Microservice 원칙을 프론트까지 확장하려는 시도가 늘어나게 되면서 Micro Frontends라는 용어가 생기게 됨

• 팀의 Mission을 완수하기 위해 여러 직군의 다양한 팀원들이 모여 업무를 처음부터 끝까지 자율적으로 수행

• 시작 지점인 기획부터 끝지점인 배포까지 모두 다하는 팀을 End-to-End 팀(목적 조직, Cross Functional Team, Chapter, Silo)이라 부른다.

• 단순한 기술의 문제뿐만 아니라 조직의 문제까지 풀어간다.

• 크고 복잡한 제품을 여러 팀이 동시에 나누어 쉽게 작업을 진행

• 이런 변화는 기술적인 부분에만 국한되지 않고 조직 체계까지 함께 변화하기 때문에 큰 비용이 발생한다.

• 마이크로 프론트엔드로 얻는 이점이 더 많을 때 마이크로 프론트엔드를 선택하는 것이 좋다.

마틴 파울러 - 소프트웨어 아키텍처의 중요성 개발자로서 좋은 아키텍처를 만들어 나가는 것이 경제적으로 중요하다는것을 확실히 인지하자. 지금 당장 어떻게든 동작하도록 만드는것이 아니라 좋은 디자인을 위해 노력해 나가는 것이 결국 새로운 기능을 추가할때 들어가는 비용과, 버그 발생이 줄어들기 때문에 사용자들에게 좋은 인상과 다른 제품들과의 경쟁력을 높힐 수 있다.