Microservic architecture(MSA)란?

컴업·2022년 2월 22일

개념

2019년 기준 전세계 모든 인터넷 통신의 12.6%는 넷플릭스로 흘러들어가고 있습니다. (2018년 15%)

어떻게 이런 어마무식한 트래픽을 한 곳에서 감당 할 수 있는 것일까요??

답은 Microservice Architecture, MSA에 있습니다.

넷플릭스의 초창기는 여느 타 애플리케이션과 다르지 않았습니다.

데이터 센터를 만들고 자바와 오라클을 이용해 서비스를 구축했죠.

이러한 방식은 넷플릭스가 빠르게 발전함에 따라 금방 한계를 보였습니다.

그 이유는 이러한 방식이 너무 Monolithic (모놀리식) 하기 때문입니다.

Monolithic Architecture

Monolithic이란 한개의 거대한 백엔드 어플리케이션이 결제, 비디오 스트리밍, 유저 생성과 같은 서비스의 모든것을 감당 하는 구조입니다. (사실상 표준)

아직까지는 많은 소프트웨어가 Monolithic 구조를 취하고 있고 소규모 프로젝트인 경우 유지보수 차원에서 이것이 훨씬 합리적입니다.

그러나 일정 규모이상 서비스가 커짐에 따라 이러한 Monolithic 구조는 곧 한계를 마주치게 됩니다.

서비스가 커질수록 영향도 파악, 전체 시스템 구조의 파악에 어려움이있음.
빌드, 테스트, 배포시간이 기하급수적으로 늘어남
서비스를 부분적으로 Scale-out하기 어려움 (서버 증가)
부분의 장애가 전체 서비스의 다운으로 이어지는 경우가 발생함.

Microservice Architecture

MSA란 결제, 비디오 스트리밍, 유저 생성과 같은 서비스들이 각각 독립적인 서버를 갖고 그 서비스들끼리의 상호작용을 통해 전체 서비스가 만들어지는 구조입니다.

Martin Folwer는 MSA에 대해 설명할때 “스스로 돌아갈 수 있는 작은 서비스”, “독립적인 배포 가능”라는 표현을 사용했습니다.

이를 통해 MSA에서의 서비스를 정리해보자면

각 서비스는 크기가 작을 뿐, 서비스 자체는 하나의 Monolithic 구조와 유사함
각 서비스는 독립적으로 배포가 가능해야함
각 서비스는 다른 서비스에 대한 의존성이 최소화 되어야함
각 서비스는 개별 프로세스로 구동되며, REST같은 가벼운 방식으로 통신되어야함

MSA를 사용하면 Monolithic 구조가 가진 여러가지 문제점을 어느정도 해결할 수 있습니다.

배포 관점: 서비스 별 개별 배포가 가능해 각 서비스를 빠르게 배포할 수 있음.
확장 관점: 특정 서비스에 대한 확장성이 용이함. (서버 늘리기)
장애 관점: 장애가 전체 서비스로 확장되지 않음.

MSA의 구조

MSA는 크게 Inner Architecture, Outer Architecture로 나눌 수 있습니다.

Inner Architecture

애플리케이션의 서비스 단위를 어떻게 나눌 것인지, 서비스 내 api를 어떻게 설계할 것인지 등을 정하는 구조입니다.

이는 서비스마다, 시스템마다 모두 다를 수 있습니다.

Outer Architecture

Gartner는 MSA의 Outer Architecture를 총 6개 영역으로 분류하고 있습니다.

External Gateway
Service Mesh
Container Management
Backing Services
Telemetry
CI/CD Automation

External Gateway (Api Gateway)

MSA는 큰 서비스를 수십 수백개의 작은 서비스로 나누어 운영합니다.

만약 각 서비스들을 클라이언트에서 직접 호출하는 형태라면 다음과 같은 문제가 발생합니다.

각 서비스마다 인증/인가 등 공통된 로직을 구현해야함
Api 호출 기록이 어려움
클라이언트에서 여러 Microservice를 호출해야함
내부 비즈니스 로직이 드러나 보안에 취약함.

Api Gateway는 서버 앞단에서 클라이언트와 상호작용하여 이러한 문제를 해결합니다.

인증 및 인가

클라이언트 요청에 대한 인증과 인가를 처리합니다.

요청 절차의 단순화

클라이언트는 각 서비스에 요청하는 것이 아니라 Api Gateway에만 요청합니다.

라우팅 및 로드 밸런싱

요청 메세지에 따라 적절한 서비스로 라우팅합니다.

서비스 오케스트레이션

여러 Microservice를 묶어 새로운 서비스를 만드는 개념입니다.

서비스 디스커버리

서비스의 IP를 찾는 기능입니다. Legacy 환경에서는 고정IP를 갖기 때문에 문제 없지만, 클라우드 환경에서는 필요합니다.

Service Mesh

MSA는 큰 백엔드를 작은 서비스로 나누어 운영하는 구조로 SOA와 굉장히 유사한 개념입니다.

그러나 SOA는 결국 실패한 구조로 평가받고있는데요.

많은 이유중 하나로 SOA의 분산처리를 위해 도입했던 ESB의 한계를 꼽을 수 있습니다.

SOA와 MSA의 구조를 보면 SOA와 달리 Microservice에서는 각 서비스간 통신기능을 각각 구현하는데 이러한 서비스간 통신을 처리하는 것이 굉장히 난이도 있는 작업입니다.

나누어진 서비스와 인스턴스 수 만큼 관리 대상이 급격히 증가 할 뿐만아니라, 복잡한 연결 구조 때문에 장애 추적이 어렵고, 장애가 발생한 서비스로 인해 타 서비스를 호출하는 로직이 수행되지 않으면서 다른 서비스 까지 동작하지 않는 장애 전파 현상이 나타납니다.

서비스 메쉬 아키텍처는 MSA의 트래픽 문제를 보완하는 커뮤니케이션 인프라입니다.

이를 사용하여 Microservice 간 직접 통신하지 않고, 모든 통신은 애플리케이션 네트워크 기능을 제공하는 서비스 메쉬를 통해 이루어집니다.

서비스 메쉬의 핵심은 사이드카 패턴입니다.

이처럼 본서비스 인스턴스 외에 사이드카 인스턴스를 병렬로 배치해 서비스가 타 서비스를 직접 호출하는게 아니라 프록시를 통해서 호출하게 됩니다. 따라서 대규모 Microservice 환경이더라도 별도의 작업 없이 서비스 연결뿐만 아니라 로깅, 모니터링, 보안, 트래픽 제어가 가능하다는 장점이 있습니다.

넷플릭스는 스프링 프레임워크에 넷플릭스 OSS를 통합하여 Spring Cloud Netflix를 제공하여 손쉽게 마이크로 서비스를 구현할 수 있도록 했습니다.

쿠버네티스가 사실상 표준.