MSA
MSA란?
MSA(MircoService Architetcure)는 애플리케이션을 여러 개의 마이크로 서비스로 분리하여, 확장을 유연하게 할 수 있고 하나의 서비스에서 발생한 장애가 다른 서비스로 전파되지 않는 장애 격리의 이점을 가지는 구조이다.
자세한 내용은 이전에 작성했던 글을 참고하자.
Amazon의 설계 원칙
2002년 Amazon의 CEO인 Jeff Bezos는 이메일로 설계 원칙을 전직원에게 통보했다.
1.
모든 팀은 그들의 데이터나 기능을 서비스 인터페이스 형태로 외부에 제공해야 한다.
2.
팀들은 반드시 이러한 인터페이스들을 통해서만 다른 팀과 통신해야한다.
3.
공개된 인터페이스를 제외하고는, 다른 팀의 저장소나 공유메모리나 백도어 등 어떠한 형태의 접근도 허락되지 않는다.
4.
다른 팀이 어떤 기술을 사용하든지 신경쓰지말고 RESTful API로 통신해야한다.
5.
모든 서비스 인터페이스는 외부에 노출될 것을 염두에 두고 설계해야한다.
6.
이를 지키지 않는 누군가는 해고될 것이다!
20년 전의 일이지만 현재의 많은 MSA를 사용하는 애플리케이션에서는 위와 동일한 방식으로 설계하고 있다.
MicroService의 특징
MSA의 MicroService는 다음과 같은 특징을 가지고 있다.
1.
Challenges
•
MSA는 기존의 패러다임에서 상당히 변경된 형태로 구축해야한다.
2.
Small Well Chosen Deployable Units
•
독립적으로 배포 가능한 형태의 작은 서비스로 구성된다.
3.
Bounded Context
•
각각의 서비스는 서로 경계가 명확하여 잘 구분되어야 한다.
4.
RESTful
•
각 서비스들은 서로 REST API를 통해 통신하는 걸 권장한다.
5.
Configuration Management
•
각 서비스들의 환경 설정 정보들은 코드 내에 가지고 있지 않고 외부에 따로 관리해야한다.
6.
Cloud Enable
•
클라우드 네이티브 서비스를 잘 활용해서 MSA를 구축해야한다.
7.
Dynamic Scale Up And Scale Down
•
각 서비스는 동적으로 scale-up이나 scale-down을 유연하게 처리할 수 있어야 한다.
8.
CI/CD
•
각 서비스들은 분산된 형태로서 일괄적으로 배포될 수도 있고, 각 서비스만 개별적으로 배포될 수 있어야한다.
9.
Visibility
•
각 서비스들은 시각적으로 관리되어야 한다.
MSA를 적용하기 전에 고려해볼 사항
우리가 개발하던 애플리케이션이나 개발하기 위해 구상 중인 애플리케이션에 MSA를 적용하고자 한다면, 다음의 몇 가지 사항들을 먼저 고려해보자.
사전 고려사항
1.
변화의 정도 : 기존 개발 대비 비용, 시간의 투자가 얼마나 필요한가
2.
독립적인 생명 주기 : 독립적으로 생명 주기를 가질만큼 서비스 경계가 명확한가
3.
독립적인 스케일링 : 각 서비스의 독립적인 유지보수 및 확장성, 스케일링이 가능한가
4.
격리된 오류 : 오류가 발생했을 때 독립적인가(다른 서비스가 해당 오류에 영향을 최소로 받으며 우회할 수 있는 대체 서비스가 준비되어있는가)
5.
외부 종속성과 외부와의 상호작용을 단순화 : 서비스간 종속성 얼마나 최소로 하고, 서비스의 응집력을 얼마나 높일수 있는가
6.
Polyglot 기술을 지원하는가 : 각 서비스가 독립적인 개발 환경과 데이터베이스 운영환경을 선택하고 사용할 수 있는가
Two Pizza team
Amazon의 DevOps 팀은 Two Pizza team을 사용한다고 한다.
Two Pizza Team은 MSA에서 하나의 마이크로 서비스 팀 구성이 점심에 피자 두 판을 함께 나누어 먹을 수 있을 정도(4~5명)가 가장 적당하다는 말에서 생긴 용어이다.
인원의 구성을 최소로하여 커뮤니케이션 비용을 감소시키면서, 개발과 테스트, 운영, 배포를 수행할 수 있는 독립적으로 구성할 수 있는 최소 단위를 뜻한다.
어떠한 서비스 기능을 구현해야 한다고 할 때, 한달동안 얼마나 구현할 수 있을까? 기능의 규모와 사용자 요구사항에 따라 다르겠지만, 일반적으로 서비스 구축을 해낼 수 있을만큼의 인원 수가 Two Pizza team이다.
SOA vs MSA
SOA(Service-Oriented Architecture)와 MSA(MicroService Architecture)는 모두 서비스를 중심으로 두는 아키텍처로, 둘 다 서비스를 지향한다는 공통점을 가지고 있다.
SOA와 MSA의 차이점은 다음과 같다.
서비스 공유
SOA는 서비스 공유를 최소화하고, 서비스 재사용을 통해 비용 절감을 목표로 한다. 반면 MSA는 서비스 간의 결합도를 낮추어 변화에 능동적으로 대응하는 것을 목표로 한다.
기술 방식
SOA는 공통의 서비스를 ESB(Enterprise Service Bus)에 모아 공통 서비스 형식으로 제공하고, 이를 통해 클라이언트의 요청을 전달하거나 서비스에서 응답한다. MSA는 독립된 각각의 서비스가 노출된 REST API를 제공하여, 클라이언트나 다른 서비스에서 해당 API를 통해서 통신한다.
전체적인 구조
•
SOA
클라이언트에게 보여지는 UI 부분에서 처리되고, 각각의 서비스는 ESB에 모여지게 된다. 이렇게 모여진 서비스들이 외부에 공개된다. 이후 데이터를 처리하기 위한 여러 기술들을 통해 데이터베이스에 접근한다.
•
MSA
서로 분리된 서비스는 독립적인 환경을 가지고 있어, 각자 독립적인 언어와 데이터베이스, 구조 등을 가지고 있다. 자신의 데이터를 REST API로 외부에 공개한다. 데이터베이스는 Kafka와 같은 이벤트 스트림을 통해서 동기화를 수행한다.
MSA 표준 구성요소
MSA 구성도
MSA는 일반적으로 위와 같은 구성도처럼 구축되어 애플리케이션을 구성하고 있다.
•
External Gateway
클라이언트나 다른 마이크로 서비스에서 API Gateway를 통해 필요한 서비스에 요청을 보낸다.
•
Service Mesh
Gateway는 받은 요청을 어디로 보내야하는지 ServiceRouter에 물어보게 되고, ServiceDiscovery에서 등록되어 있는 서비스를 검색한다.
검색한 서비스를 받아 로드 밸런서에서 어떤 서비스로 요청을 보낼 것인지 결정하고 마이크로 서비스에 전달한다.
•
Config Store
마이크로 서비스의 환경 설정 파일들은 외부의 저장소에 별도로 관리한다.
•
CI/CD Automation
여러 마이크로 서비스들을 배포하기 위해 여러 배포 자동화 기술들을 사용한다.
•
Backing Services
각 서비스에서 연결할 필요하다면 이벤트나 메세지큐와 같은 지원 서비스를 사용하기도 한다.
•
Telemetry
모니터링과 진단 기능을 통해 각 서비스들의 상태를 확인한다.
Service Mesh Capabilities
서비스 매쉬는 MSA 애플리케이션의 내부 통신을 말하며, 서비스 매쉬를 통해서 서비스 간의 통신을 추상화하여 마이크로 서비스의 운영을 안전하고 빠르고 신뢰성 있게 만들어주는 계층을 말한다.
이러한 추상화를 통해 복잡한 내부 네트워크를 제어 및 추적하고, 내부 네트워크에 관련된 로직을 추가하여 안전성, 신뢰성, 탄력성, 표준성, 가시성, 보완성 등을 확보할 수 있다.
URI 경로나 호스트 헤더, API 버전 등 응용 프로그램의 규칙을 기반으로하는 네트워크 레이어이고, 구체적인 프록시를 통해 라우팅이나 Circuit Breaker같은 공통 기능을 설정할 수 있다. 라우팅, 인증, 로드 밸런싱, 탄력성, 서비스의 검색, 암호화 등 서비스 매쉬는 마이크로 서비스의 개발과 운영을 지원한다.
CNCF
CNCF(Cloud Native Computing Foundation)를 구축할 때, 상호 연관될 수 있는 서비스들이 있고 그렇지 못한 서비스들이 있다.
https://landscape.cncf.io
위 주소로 들어가 내가 사용하고자 하는 서비스가 서로 호환이 되는지 확인하고 MSA를 설계하자.
