마이크로 서비스 아키텍처

18 August 2015

SOA, 모노리틱 아키텍처, 마이크로 서비스 아키텍처에 대하여 그냥 간략하게..

SOA (Service-Oriented Architecture)

아키텍처 구성을 위한 하나의 개념이자 사상. 애플리케이션의 기능을 비즈니스적인 의미가 있는 기능 단위로 묶고, 표준화된 호출 인터페이스를 통해 서비스라는 소프트웨어 컴포넌트 단위로 재조합한 후, 이 서비스들을 서로 조합하여 업무 기능을 구현한다.

  • 느슨하게 연결되고, 상호 조합 가능한 소프트웨어
  • 수직적 분할: 각각의 서비스가 데이터 계층, 비즈니스 로직 계층, 뷰에 대한 모듈을 모두 가지고 있어서 각 서비스 간의 의존성이 최소화됨.
  • SOA 시스템 내에서 플랫폼이나 기술에 종속되지 않음
  • 서비스 변경시 다른 서비스에 영향이 적음
  • 각 서비스를 서로 연결하여 하나의 조합된 형태의 애플리케이션을 구상할 수 있음

모노리틱 아키텍처

하나의 어플리케이션에 모든 모든 로직이 다 들어가있는 통짜 구조.

  • 배포 주기를 늘리기 어려워진다.
  • 작은 변경이여도, 전체를 다시 빌드하고 배포해야 한다.
  • 서버 확장이 필요할 경우 자원을 더 필요로 하는 부분만이 아니라 전체 Application 규모만큼 늘려야 한다.

MSA (Micro Service Architecture)

SOA가 엔터프라이즈 시스템을 중심으로 고안된 아키텍처라면, 마이크로서비스아키텍처는 SOA사상에 근간을 두고, 대용량 웹서비스 개발에 맞는 구조로 사상이 경량화되고, 대규모 개발팀의 조직 구조에 맞도록 변형된 아키텍처.

  • 대용량 웹 시스템에 맞춰 개발된 API 기반의 아키텍처 스타일.
  • 각 컴포넌트를 서비스라는 개념으로 정의.
  • 데이터부터 비즈니스로직까지 독립적으로 상호 컴포넌트간의 의존성없이 개발된 컴포넌트. (수직적 분할)
  • 각 컴포넌트 간에는 REST API 등 표준 인터페이스로 그 기능을 외부로 제공함.
  • 타 컴포넌트와의 의존성 없이 독립적으로 배포 가능.
  • 각 컴포넌트(스비스)가 독립적인 war파일로 개발되어 독립된 톰캣 인스턴스에 배치되고, 이렇게 배치된 톰캣 인스턴스는 횡적으로 스케일(인스턴스 수를 늘림)이 가능하고, 앞단에 로드밸런서를 배치하여 서비스간의 로드를 분산시킬 수 있다.
  • 애플리케이션 로직을 분리하여 여러개의 애플리케이션으로 나눠서 서비스화하고, 서비스별로 톰캣을 분산 배치한 것이 가장 큰 특징이다.
  • 독립적으로 배치, 확장 가능
  • 서로 다른 언어/프레임워크, 서로 다른 데이터베이스. 독립적 운영. - Loose coupling, High 코히젼
  • 새롭거나 혁신적인 것이 아니다. 컴포넌트 단위로 나누고 이들 간 관계 정의, 연결하는 것은 일반적인 구조임.

마이크로 서비스 아키텍처의 단점

  • 다른 컴포넌트의 데이터를 API통신을 통해서만 가지고 와야 하므로 성능상 문제가 있을 수 있음. (서비스 간 호출 비용)
  • 다른 데이터베이스간의 트랜잭션을 묶을 수 없으므로, 트랜잭션 처리 실패시 보상 트랜잭션 처리를 해줘야 한다. (트랜잭션 처리 비용)
  • 각 서비스 간 API 호출을 통해 통신하므로, JSON/XML 등을 객체로 변환하는 등의 마샬링 오버헤드가 발생.
  • 사용되는 프레임워크 등의 소스가 중복되므로 메모리 사용냥 늘어남. 톰캣 대수가 많아지므로 이에 따른 메모리도 늘어남. 하지만 현대의 인프라 환경에서는 크게 문제되지 않음.
  • 테스팅의 복잡도가 올라감.

API Gateway with MSA

마이크로서비스아키텍처에서, 서비스들의 앞단에 API 게이트웨이를 둘 수 있음.

  • 프락시서버처럼 API들 앞에서 모든 API에 대한 엔드포인트를 통합하고, 몇 가지 추가적인 기능을 제공하는 미들웨어. SOA의 버스에 비해서 경량화됨.
  • 컴포넌트간 각각 다른 엔드포인트(URL)들을 통합시킬 수 있음
  • 매시업/오케스트레이션 가능. 하지만 오케스트레이션을 API 게이트웨이 계층에서 하는 것은 게이트웨이 입장에서는 부담임. 과도한 오케스트레이션 로직을 넣어서 전체적인 성능 문제가 생길 수 있음. 높은 수준의 기술적인 이해 필요.
  • 인증, 로깅 등 공통 기능을 처리하도록 하여 다른 컴포넌트들은 비즈니스 로직에만 집중하도록 할 수 있음.
  • 프로토콜이나 메시지 포맷 변환 기능 등의 중재 기능을 제공해 줄 수 있음. 하지만 이것 또한 API게이트웨이를 가능한 최대한 가볍게 가져간다는 설계 원칙 아래에서 높은 수준의 설게와 기술적인 노하우가 필요함.

거버넌스 모델

중앙 집중형

표준 프로세스와 가이드를 기반으로 전체 팀을 운용. 전체 시스템이 같은 프로세스와 기술을 가지고 개발되므로 유지보수가 비교적 쉬우며 인원 교체가 편리. 단 기술 적용에 대한 민첩성이 떨어짐.

분산형

각 팀에 독립적인 프로세스와 기술 선택 권한을 주고, 각 서비스가 표준 API로 통신함으로서 내부적인 구현 기술 구조는 추상화. 분산형 거버넌스 모델을 수행하려면 이에 맞는 팀 구조가 필요한데, 다음과 같은 특징이 있어야 함. 크로스펑셔널 팀. 개발+인프라운영을 하나의 조직으로 => DevOps. 프로젝트 단위가 아닌 프로덕트 단위의 개발팀 구성.

Java - Enum Java 8 - Interface