마이크로서비스 아키텍처(MSA)란? 쉽고 빠르게 이해하기

마이크로서비스 아키텍처란?

마이크로서비스 아키텍처(MSA)는 하나의 큰 애플리케이션을 작고 독립적인 서비스들의 집합으로 분해하여 개발하고 배포하는 방식이다. 각 서비스는 특정 기능을 담당하며, 다른 서비스와는 느슨하게 결합되어 있다.

마이크로서비스 아키텍처(출처 : 가트너)

API GateWay

서비스들을 모아서 하나의 아키텍처를 만들었다. 가트너의 예시를 보면 API Gateway를 통해서 유입이 된 다음, 서비스 라우터에서 분산해주는 구조임을 알 수 있다. API GateWay는 일종의 버스 역할을 하는 것이며 이런 구성을 Hub&Spoke 방식이라고 한다. 이렇게 되면 외부와 내부 영역을 구분하면서 유입을 단순화 할 수 있는 이점이 있다.

 

API Gateway에서 인증이나 로깅과 같은 공통기능에 대한 중복 개발을 줄이고자 Polocy Management나 인증을 진행한다.

Service Router와 Load Balancing

API Gateway를 타고 들어면 Service Router에 의해 해당 트래픽이 어느 서비스로 전달 될 지 결정이 된다. 도식에서 보면 Service Discovery라고 되어있다. Discovery라는 개념은 API Gateway가 호출할(연결 될) 서비스를 찾는 매커니즘이다. 

 

Load Balacing은  AWS에서는 3가지를 제공한다고 한다.

- Application LB

- Network LB

- Classic LB

 

로드 밸런서는 부하를 분산하는 역할이다.

Service Mesh

마이크로아키텍처에서 Router에 구분 된 요청들이 각각의 서비스로 유입 될 것이다. 실제 서비스로 들어가는 트래픽들은 위 마이크오아키텍처 처럼 일방향으로 간단하게 처리되지 않는다.

 

그렇기 때문에 서비스 매시(Service Mesh) 개념이 도입된다. 서비스 간의 통신을 제어하고 표시하고 관리 할 수 있도록 하는 마이크로 서비스에 특화 된 인프라 계층이다. 서비스 메시에서의 호출은 자체 인프라 계층의 proxy를 통해서 이루어 진다.

 

이 proxy는 서비스 내부에 존재하는 것이 아닌 각 서비스와 함께 실행되는데 sidecar 패턴의 구현체이다. 이렇게 구성하는 이유는 서비스간 통신을 하면서 발생하는 복잡성과 특정 서비스 간 통신 과정에서 발생하는 SPOF를 손쉽게 찾을 수 있다는 이점이 있다.

 

실제 서비스 메시는 아래 구조로 동작한다. 각각의 서비스와 동시에 실행되는 프록를 통해서 서비스간 통신이 가능하다. 그리고 각 프록시들도 설정이 필요할텐데 트래픽을 제어하는 정책 및 구성에 따라 그 역할을 해주는 컨트롤러가 있다. 주로 많이 사용하는 도구는 Envoy Proxy를 쓴다고 한다.

데이터 베이스

마이크로 서비스 아키텍처의 경우 서비스가 API에서부터 데이터베이스까지 분리되는 수직적 분할 원칙에 따라서 독립된 데이터 베이스를 가진다.

모니터링

서비스는 분할되어 있지만 모니터링과 관리는 중앙집중 형태가 유리한 점이 많다. 서비스 외부에서 중앙화 된 텔레메트리를 도입해서 관리하는데 사용하는 도구로는 Grafana나 Tanos 같은 부분들이 있다.

왜 마이크로서비스 아키텍처를 사용할까요?

- 유연성 : 각 서비스를 독립적으로 개발, 배포, 확장할 수 있어 시스템 전체의 유연성이 높아진다.

- 확장성 : 특정 서비스에 부하가 집중될 경우 해당 서비스만 확장하면 되므로 시스템 전체의 확장성이 뛰어난다.

- 개발 생산성 : 작은 단위의 서비스를 개발하기 때문에 개발 속도가 빨라지고, 개발자 간의 의존성이 줄어든다.

- 기술 다양성 : 각 서비스에 맞는 최적의 기술을 선택하여 사용할 수 있다.

마이크로서비스 아키텍처의 핵심 구성 요소

- 서비스 : 독립적으로 배포 가능한 작은 단위의 애플리케이션

- API 게이트웨이 : 다양한 서비스에 대한 단일 진입점을 제공

- 서비스 레지스트리 : 서비스의 위치를 관리

- 서비스 메시 : 서비스 간의 통신을 관리하고 보안을 강화

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

- 빠른 개발 및 배포 : 작은 단위로 개발하기 때문에 개발 속도가 빠르고, 새로운 기능을 빠르게 출시할 수 있다.

- 기술 다양성 : 각 서비스에 맞는 최적의 기술을 선택할 수 있어 유연성이 높다.

- 확장성 : 특정 서비스에 부하가 집중될 경우 해당 서비스만 확장하면 되므로 효율적이다.

- 복원력 : 하나의 서비스에 문제가 발생하더라도 전체 시스템에 미치는 영향을 최소화할 수 있다.

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

- 복잡성 : 다수의 서비스를 관리해야 하므로 시스템 복잡성이 증가할 수 있다.

- 네트워크 오버헤드 : 서비스 간 통신으로 인해 네트워크 오버헤드가 발생할 수 있다.

- 데이터 일관성 : 분산된 데이터 환경에서 데이터 일관성을 유지하는 것이 어려울 수 있다.

마이크로서비스 아키텍처 도입 시 고려 사항

- 도메인 모델링 : 비즈니스 도메인을 명확하게 정의하고, 각 서비스의 경계를 설정해야 한다.

- 데이터 관리 전략 : 분산 데이터 환경에서 데이터 일관성을 유지하기 위한 전략을 수립해야 한다.

- 네트워크 : 서비스 간 통신을 위한 네트워크 환경을 구축해야 한다.

- 보안 : 분산 환경에서 보안 위협에 대비해야 한다.

- 운영 : 다수의 서비스를 관리하기 위한 운영 체계를 구축해야 한다.

마이크로서비스 아키텍처 성공 사례

- 넷플릭스 : 마이크로서비스 아키텍처를 통해 전 세계 사용자에게 안정적인 스트리밍 서비스를 제공한다.

- 아마존 : 다양한 서비스를 마이크로서비스로 분리하여 빠르게 새로운 기능을 출시하고 있다.

결론

마이크로서비스 아키텍처는 클라우드 네이티브 시대에 필수적인 아키텍처 패턴입니다. 하지만 복잡성, 비용, 기술적 어려움 등을 고려해야 합니다. 신중한 계획과 준비를 통해 마이크로서비스 아키텍처를 성공적으로 도입하고, 시스템의 유연성과 확장성을 높일 수 있습니다.