모놀리틱 아키텍쳐
웹 서비스 초기에는 제공하는 서비스가 많지 않고, 이용자가 적기 때문에 프로젝트의 규모가 작다.
이때는 프로젝트를 하나로 관리하게 되는데 이러한 형태를 모놀리틱 아키텍쳐라 부른다.
하나의 웹 애플리케이션이기 때문에 서버에 문제가 생겨 중단되면 모든 서비스가 중단된다.
마이크로 서비스 아키텍쳐
시간이 지날수록 제공하는 서비스가 많아지고, 이용자가 많아지면 자연스럽게 프로젝트의 규모도 커지게 된다.
마이크로 서비스 아키텍쳐는 이러한 큰 규모의 프로젝트를 마이크로 서비스로 나누어 프로젝트를 만들고 관리한다.
모놀리틱 아키텍쳐에 비해 좀 더 복잡한 구조를 가지지만, 각 프로젝트의 관점에서 보았을 땐 더 단순하다.
장점
마이크로 서비스 아키텍쳐의 주목할만한 이점은 다음과 같다.
- 서비스별로 기술 스택을 다르게 가져갈 수 있다.
각 서비스 제공을 위해 가장 효율적인 기술 스택을 사용할 수 있다.
예를 들어 일반적인 웹 서비스는 JAVA를 사용하고,
실시간 서비스는 퍼포먼스를 위해 Go를 사용할 수 있다. - 서비스가 나누어져 있어, 하나의 서비스가 다운되더라도 나머지 서비스가 가능하다.
- 스케일-아웃(scale-out)으로 서버를 업그레이드하기 용이하다.
스케일-업의 경우 한계가 존재하고, 스케일-아웃에 비해 비용이 높다.
고려해 볼 것
마이크로 서비스 아키텍쳐 도입을 위해서 다음과 같은 것을 고려할 필요가 있다.
- 모놀리틱 아키텍쳐에 비해 복잡한 구조를 가지기 때문에,
규모가 작은 프로젝트에서 채택할 경우 오히려 더 관리가 어려울 수 있다.
따라서 모놀리틱 아키텍쳐로 시작하고, 필요에 따라 추후에 MSA를 채택하는 것이 좋다. - 서버가 나누어져 있기 때문에 트랜젝션 처리에 대한 고려가 필요하다.
- 의존하고 있는 서비스끼리 장애가 전파되지 않도록 관리할 필요가 있다.
예를 들어 포인트 서비스에 장애가 발생할 경우 이로인해 주문 서비스도 장애가 발생할 수 있다.
포인트 서비스에 장애가 발생하더라도 주문 서비스는 정상적으로 수행될 수 있도록
서킷 브레이커 패턴을 고려한다.
프로젝트에 적용하기
Gateway
각 서비스 API 호출을 위한 진입점 역할을 한다.
게이트웨이에 요청이 들어오면 조건에 따라 각 서비스로 라우팅한다.
디스커버리를 통해 각 서비스의 상태를 확인하고 로드밸런싱을 지원한다.
게이트웨이에 장애가 발생하면 SPOF 문제가 발생하므로,
게이트웨이는 고가용성 장비를 사용한다.
Discovery
각 서비스의 주소와 상태를 관리한다.
서비스끼리 통신을 하기 위해서 사용되기도 한다.
Auth-service
인증 및 인가 서비스를 제공한다.
사용자를 인증하고, 사용자를 식별할 수 있는 정보와 인가 정보를 담아 토큰을 만들어 반환한다.
토큰은 추후 요청에 담겨 사용된다.
고민
API 요청을 위해서 인가가 반드시 필요하다.
API 요청 시 인가를 확인할 필요가 있는데, 앞서 인증 서비스에서 토큰에 인가 정보를 담았다.
따라서 토큰에서 인가 정보를 꺼내어 사용하면 되지만, 그 전에 유효한 토큰인지 확인해야 한다.
토큰 유효성 검사를 수행할 후보는 다음과 같다.
게이트웨이에서 유효성 검사
게이트웨이는 각 서비스의 가장 앞단에 있다.
따라서 각 서비스의 공통 로직을 처리하기에 최적화되어 있다.
유효성 검사 또한 마찬가지이지만, 유효성 검사를 위해 비밀키가 필요하므로
인증서비스와 게이트웨이 두 곳에서 비밀키를 관리해야 한다.
- RS 방식으로 서명을 한다면 인증서비스는 비밀키를 가지고,
게이트웨이는 공개키가지므로 조금 개선할 수 있다.
인증서비스에서 유효성 검사
인증 관련 서비스를 제공하므로 관련성 높은 코드를 모아둘 수 있다.
하지만 매 요청마다 인증서비스를 통해야므로 인증서비스의 부하가 집중될 수 있다.
