🐱🏍Monolithic architecture
전통적인 웹 시스템 개발 스타일로, 하나의 애플리케이션 내에 모든 로직들이 모두 들어가 있는 구조(tomcat서버 내 war파일 내에 모든 컴포넌트, 로직이 하나의 결과물 내에 들어있는 것)이다. 이러한 특성 때문에 결합도가 높다.
특징
전체 어플리케이션을 하나로 처리하기 때문에 개발, 빌드, 배포, 테스트 등이 편리하다(한번만 수행하면 되기 때문).
이러한 점이 규모가 작은 애플리케이션에서는 큰 장점이지만, 규모가 큰 애플리케이션에서는 빌드, 배포, 서버 가동시간이 오래걸리며 자그마한 실수로도 전체 시스템의 빌드 실패를 유발하기 때문에 협업 개발이 어렵다.
결합도가 높아 부분적인 scale-out이 어려우며 서비스 변경이 어렵고, 서비스 수정 시 장애의 영향도파악이 힘들다. 또 한 프레임워크와 언어에 종속적이다.
기존 물리 서버에 서비스를 올리던 *on-prime 서버기반의 구조에서 클라우드 환경을 이용한 MSA로 많은 서비스들이 전환되었다.
*on-prime server
An on-premise server is a physical, on-site server that a company must manage and maintain individually.
- monolithic의 scaling
scale-up : 특정 한 부분만 확장불가, 확장되지 않아도 되는 부분까지 확장해야 됨
scale-out : 특정 한 부분만 n개로 확장불가, 통합서버를 많이 배포하고 로드밸런서 붙이기 등으로 가능
🐱🏍MSA(micro-service architecture)
대용량 웹 서비스가 많아짐에 따라 정의된 구조이다. 각각의 모듈로 나누고 각 모듈은 하나의 독립적인 역할을 수행한다(의존성이 낮다). 특정 서비스에 에러가 발생해도 다른 서비스에게 영향을 미치지 않는다(단일 책임 원칙).
장점
분리된 모듈들이 완전히 독립적으로 배포가 가능하다. 이때문에 프레임워크, 언어등에 자율적이고 더 빠른 배포가 가능해 개발 주기가 짧다(생산성↑). 각 서비스의 부하에 따라 개별적으로 scale-out이 용이하다(부하가 생기는 부분만 n개로 늘리기 가능).
단점
전체적인 구조가 모놀리식에 비해 상대적으로 많이 복잡하다.
각 모듈간의 통신은 API를 사용하여 통신비용 및 지연시간이 증가한다(단, 통신은 REST와 같은 가벼운 방식으로 통신되어야 함).
각 배포되어 데이터가 여러 서비스에 걸쳐 분산되므로 한번에 조회가 어렵다. 또, 분산된 서비스 마다 분산된 트랜잭션 관리가 필요하다(정합성 문제 발생가능).
단위테스트는 쉽지만, 통합 테스트, End-to-End 단위테스트는 여러 서비스의 API를 검증해야 하므로 시간과 비용이 많이 든다.
🐱🏍API Gateway
MSA는 서비스가 작게 쪼개져 있기 때문에 클라이언트에서 필요한 api들을 직접 호출하게 되면 다음과 같은 문제가 생길 수 있다.
문제점
1. 각각의 서비스 마다 인증/인가 등 공통 로직을 매번 구현해야 함
2. 다수의 API 호출을 기록/관리하기 어려움
3. 클라이언트에서 목적에 따라 다른 서비스에 호출 해야 하는 번거로움
4. 내부 비즈니스 로직이 드러나 보안에 취약해짐
이러한 단점은 API *Gateway 도입으로 해결할 수 있다. api gateway는 프록시 서버처럼 맨 앞단에서 모든 api에 대한 endpoint를 통합하고 위의 단점을 해결하는데 도움을 준다.
해결점
1. 인증/인가/로깅 등 공통 기능 처리를 도와준다.
2. api gateway는 모든 api호출 시 공통적으로 호출되므로 모든 로그를 중간에서 수집하기 좋다. 여러개로 흩어져 있는 api를 반드시 하나의 api gateway로 통과시키며 관리를 편하게 해주는 것임.
3. Orchestration(=aggregation)이 가능하여 여러 서비스를 묶어 새로운 서비스를 만들어 낼 수 있다(단 api gateway계층에서 이를 처리하는 것은 gateway에 부담이 되니 고려 후 사용해야 함).
4. 각 서비스가 사용하는 api가 노출되므로 클라이언트에서 직접적으로 사용되지 않는 api를 숨길 수 있다. api gateway가 호출하는 api만 노출되기 때문이다(라우팅가능). 같은 api 요청이라도 여러개의 endpoint를 이용해 각 클라이언트마다 라우팅이 가능하다. + 로드밸런싱도 됨
*Gateway
서로 다른 통신망, 프로토콜을 사용하는 네트워크 간 통신을 가능하게 하는 네트워크 포인트
다른 네트워크로 통신을 하기 위한 현관문, 톨게이트로 비유 가능
References
- https://www.forbes.com/sites/forbestechcouncil/2019/03/22/cloud-based-vs-on-premise-servers/?sh=3d04bef179e2
- https://kr.tmaxsoft.com/info/storyTView.do?seq=345
- https://wooaoe.tistory.com/57
- https://medium.com/@Dopedev/microservice-architecture%EB%9E%80-ca9825087050
- https://bcho.tistory.com/1005
- https://bcho.tistory.com/948
- https://velog.io/@tedigom/MSA-%EC%A0%9C%EB%8C%80%EB%A1%9C-%EC%9D%B4%ED%95%B4%ED%95%98%EA%B8%B0-3API-Gateway-nvk2kf0zbj
- https://inpa.tistory.com/entry/AWS-%F0%9F%93%9A-API-Gateway-%EA%B0%9C%EB%85%90-%EA%B8%B0%EB%B3%B8-%EC%82%AC%EC%9A%A9%EB%B2%95-%EC%A0%95%EB%A6%AC#HTTP_API_%EA%B2%8C%EC%9D%B4%ED%8A%B8%EC%9B%A8%EC%9D%B4_%EC%83%9D%EC%84%B1_
- https://bravenamme.github.io/2020/08/06/msa-transaction/ (MSA 트랜잭션 관련)
