소프트웨어 아키텍처 - 마이크로서비스 아키텍처(Microservice architecture)

SeungTaek·2022년 2월 7일
0
post-thumbnail

분산

  • 서비스는 자체 프로세스로 실행되며, 원래는 물리적인 컴퓨터를 의미했지만 이제는 가상 머신과 컨테이너로 빠르게 진화했다.
    • 최근 가상화 기술이 발전하면서 마이크로서비스 아키텍처 구현이 전보다 쉬워졌다.
  • 뭔가 공유함으로써 불거지는 문제들은 각 서비스를 자체 프로세스로 분리하면 모두 자연스럽게 해소된다.
  • 마이크로서비스의 분산 속성 탓에 성능은 다소 부정적이다. 네트워크 호출은 메서드 호출보다 오래 걸리고 엔드포인트마다 보안 검증 절차를 거치면 그만큼 처리 시간이 소요되므로 시스템을 설계하는 아키텍트는 서비스 세분도에 대해 심사숙고해야 한다.
  • 각 서비스를 분산시키는게 핵심이므로, 개발자가 서비스 경계를 넘나드는 트랜잭션을 사용하지 않도록 주의해야 한다.

데이터 격리

주의 사항

  • 마이크로서비스는 경계 콘텍스트 개념에 따라 데이터를 격리해야 한다.
  • 대부분의 다른 아키텍처는 데이터를 단일 데이터베이스에 저장하지만, 마이크로서비스 아키텍처는 통합 지점으로 사용되는 공유 스키마, 데이터베이스 등 모든 종류의 커플링을 없애려고 한다.
  • 때문에 서비스를 단순히 데이터베이스에 있는 엔티티와 비슷하게 모델링해서는 안된다.

이점

  • 데이터 격리를 함으로써 얻는 장점이 있다. 각 서비스마다 단가, 스토리지 종류, 그 밖에 여러 요소들을 저울질하여 가장 적합한 도구를 선택할 수 있다.
  • 또 고도로 분리된 시스템에서 다른 팀에 영향을 끼치지 않고 그때그때 상황에 맞게 더 적잡한 데이터베이스(또는 의존성)을 선택할 수 있고 구현체 세부에 얽매이지 않는 것도 이점이다.

운영 재사용

  • 전통적인 서비스 지향 아키텍처의 철학은 가급적 많은 기능을 재사용하는 것이 좋다.
  • 마이크로서비스에서는 사이드카 패턴(sidecar pattern)을 사용하여 공통 운영 관심사를 별도의 컴포넌트로 둔다.
    • 예를 들어 로깅, 보안, 모니터링 등에 사용된다.
  • 또한 서비스 디스커버리(service discovery)를 사용할 수 있다.
    • 어느 하나의 서비스를 직접 호출하는 게 아니라, 모든 요청이 서비스 디스커버리를 거치도록 하면 요청 수와 빈도를 모니터링 할 수 있고 필요시 서비스 인스턴스를 늘려 확장성/탄력성을 줄 수 있다.

프런트 엔드

  • 마이크로서비스는 디커플링을 선호한다. 따라서 유저 인터페이스와 백엔드 역시 분리되는 모습이 이상적이다.
  • 프런트 엔드는 2가지 스타일을 가지는데, 모놀리식으로 단일 유저 인터페이스를 사용하는 방법과 마이크로프런트엔드로 컴포넌트를 나누어 개발하는 방식이다.
  • 특히 마이크로프런트엔드는 리액트(react) 같은 컴포넌트 기반 웹 프레임워크를 사용할 수 있다.

통신

  • 일반적으로 마이크로서비스 아키텍처는 '프로토콜 인지 이종 간 상호 운용성(protocol-aware heterogeneous interoperability)'을 활용한다.
    • 프로토콜 인지: 중앙 통합 허브를 갖고 있지 않기 때문에 각 서비스는 다른 서비스를 호출할 때 어떤 프로토콜을 사용할지 알아야 한다.
    • 이종: 분산 아키텍처이기 때문에 각 서비스마다 구현 기술 스택이 다를 수 있다. 서비스마다 사용하는 플랫폼이 저마다 다른 환경을 완벽하게 지원한다.
    • 상호 운용성: 여러 서비스가 서로 호출한다. 서비스는 네트워크를 통해 다른 서비스를 호출하여 정보를 주고받으면서 협력해야 한다.

Reference

소프트웨어 아키텍처 101 (마크 리처즈, 닐포드, 한빛미디어)
이미지

profile
I Think So!

0개의 댓글