마이크로서비스로 전환하면 API 게이트웨이를 어떻게 구성할지가 고민이다. 단일 진입점을 둘지, 각 서비스가 독립적으로 API를 제공할지, 아니면 연합(federated) 게이트웨이로 통합할지. GraphQL이 등장하면서 이 선택이 더 복잡해졌다. GraphQL은 클라이언트가 원하는 데이터만 가져갈 수 있어 게이트웨이 패턴에 따라 성능 차이가 크다.
EECSI 학술대회에 발표된 연구는 모놀리식, 마이크로서비스 API 게이트웨이, 마이크로서비스 연합 게이트웨이 세 가지 아키텍처를 GraphQL API 기반 웹 애플리케이션에서 비교 분석한다.
연구는 동일한 기능을 세 가지 아키텍처로 구현하고 응답 시간, 처리량, 자원 사용량, 개발 복잡도를 측정했다. 모놀리식은 모든 기능이 단일 애플리케이션에 통합된 구조, API 게이트웨이는 단일 진입점이 하위 서비스로 요청을 라우팅하는 구조, 연합 게이트웨이는 각 서비스가 자체 GraphQL 스키마를 가지고 게이트웨이가 이를 병합하는 구조다.
핵심 결과를 보면, 응답 시간에서는 모놀리식이 가장 빨랐다. 내부 메서드 호출이 네트워크 호출보다 빠르기 때문이다. 하지만 트래픽이 집중되면 모놀리식은 전체가 영향을 받는 반면, 마이크로서비스는 특정 서비스만 부하를 받아 장애 격리가 가능했다. API 게이트웨이 패턴은 구현이 단순하지만, 모든 요청이 게이트웨이를 거쳐 병목이 발생할 위험이 있었다. 연합 게이트웨이 패턴은 복잡한 데이터 결합 쿼리에서 가장 효율적이었다. 각 서비스가 자체 스키마를 관리하므로 팀 간 독립성도 가장 높았다.
개발 복잡도 측면에서 모놀리식이 가장 낮았고, 연합 게이트웨이가 가장 높았다. 하지만 장기적으로 연합 게이트웨이는 스키마 진화와 팀 독립성에서 이점이 컸다.
이 연구의 시사점은 GraphQL과 마이크로서비스의 조합에서 게이트웨이 패턴 선택이 전체 아키텍처 성능에 결정적 영향을 미친다는 것이다. 단순한 CRUD 중심의 서비스라면 API 게이트웨이로 충분하지만, 복잡한 데이터 결합과 팀 독립성이 중요하면 연합 게이트웨이를 고려해야 한다.
한계로는 규모가 제한된 실험 환경이라 대규모 엔터프라이즈 환경에서의 검증이 필요하고, 세 패턴의 장기적 유지보수 비용 비교가 부족하다.
GraphQL 기반 마이크로서비스를 설계 중이라면 먼저 데이터 결합의 복잡도를 파악하라. 단순한 조회가 대부분이면 API 게이트웨이로 시작하고, 다중 서비스 간 데이터 결합이 빈번하면 연합 게이트웨이로 전환하는 접근이 현실적이다. Apollo Federation이나 Schema Stitching 같은 도구로 점진적 도입이 가능하다.
📖 *Comparative Analysis of Monolith, Microservice API Gateway and Microservice Federated Gateway on Web-based application using GraphQL API (학술 논문)* |
논문 원문
※ 이 기사는 학술 논문을 바탕으로 작성되었습니다. 실제 적용 시 환경에 따라 다를 수 있으니 전문가와 상담하세요.
When transitioning to microservices, a major consideration is how to structure the API gateway. Should there be a single entry point, should each service provide APIs independently, or should they be integrated via a federated gateway? The emergence of GraphQL has made this choice even more complex. Since GraphQL allows clients to fetch only the data they need, the performance difference varies significantly depending on the gateway pattern.
A study presented at the EECSI academic conference comparatively analyzes three architectures—monolithic, microservice API gateway, and microservice federated gateway—within a web application based on GraphQL APIs.
The research implemented the same functionality across the three architectures and measured response time, throughput, resource usage, and development complexity. The monolithic architecture integrates all functions into a single application; the API gateway architecture uses a single entry point to route requests to underlying services; and the federated gateway architecture allows each service to maintain its own GraphQL schema, which the gateway then merges.
Looking at the key results, the monolithic architecture was the fastest in terms of response time. This is because internal method calls are faster than network calls. However, under heavy traffic, the entire monolith is affected, whereas microservices allow for fault isolation as only specific services bear the load. The API gateway pattern is simple to implement but carries the risk of bottlenecks since all requests pass through the gateway. The federated gateway pattern was the most efficient for complex data joining queries. Because each service manages its own schema, it also offered the highest level of team independence.
In terms of development complexity, the monolithic architecture was the lowest, while the federated gateway was the highest. However, in the long run, the federated gateway offered significant advantages in schema evolution and team independence.
The implication of this study is that the choice of gateway pattern has a decisive impact on the overall architectural performance when combining GraphQL with microservices. For simple CRUD-centric services, an API gateway is sufficient, but if complex data joining and team independence are critical, a federated gateway should be considered.
Limitations include the fact that the experiment was conducted in a limited-scale environment, requiring validation in large-scale enterprise settings, and the lack of a comparison of long-term maintenance costs across the three patterns.
If you are designing GraphQL-based microservices, first assess the complexity of your data joins. If most operations are simple lookups, starting with an API gateway and transitioning to a federated gateway when frequent data joining across multiple services is required is a practical approach. Gradual adoption is possible using tools like Apollo Federation or Schema Stitching.
📖 *Comparative Analysis of Monolith, Microservice API Gateway and Microservice Federated Gateway on Web-based application using GraphQL API (Academic Paper)* | Original Paper
* This article is based on an academic paper. Actual results may vary depending on the environment, so please consult with an expert before implementation.
