GraphQL 페더레이션은 개발자가 여러 GraphQL 서비스(즉, 오픈 소스 쿼리 언어인 GraphQL로 작성된 서비스)에서 단일 API를 사용할 수 있도록 하는 분산 아키텍처 접근 방식입니다.
페더레이션은 스키마(백엔드와 프론트엔드 운영 간의 계약)를 더 관리하기 쉬운 구성 요소와 마이크로서비스로 나누어, 팀이 스키마의 일부를 독립적으로 구축, 배포 및 관리하면서 클라이언트가 상호 작용할 수 있는 통합 데이터 그래프를 유지할 수 있도록 합니다.
페더레이션된 GraphQL 환경에서 GraphQL 게이트웨이는 여러 스키마(서브그래프 또는 서비스라고도 함)를 단일 그래프(또는 라우터)에 통합합니다. 각 서브그래프는 전체 스키마의 일부를 정의하고 자체 유형 및 필드에 대한 비즈니스 로직 및 데이터 검색을 처리합니다. 그런 다음 게이트웨이는 독립형 서브그래프를 슈퍼그래프로 연결하여 클라이언트가 마치 단일 GraphQL 스키마와 상호 작용하는 것처럼 서비스 전반의 데이터 소스를 쿼리할 수 있도록 합니다.
페더레이션이 사용되기 전에는 서로 다른 스키마와 리졸버를 수동으로 결합하는 스키마 스티칭이 여러 GraphQL 스키마를 결합하는 주요 방법 중 하나로 사용되었습니다. 그러나 이를 사용하려면 개발자가 스키마를 병합하는 방법과 데이터를 결합하는 방법을 정의해야 했습니다. 스키마 스티칭이 GraphQL 스키마에 대한 통합 솔루션을 제공하긴 했지만, 복잡하고 오류가 발생하기 쉬워 관리하기 어려웠습니다.
제품 및 앱 엔지니어링을 위한 GraphQL 구현인 Apollo의 엔지니어들이 이러한 문제를 해결하고 스키마 스티칭 프로세스를 간소화하기 위해 Apollo 페더레이션을 개발했습니다. Apollo 페더레이션은 서로 다른 서비스의 유형 간의 연결을 정의하기 위해 'key', 'external', 'requires', 'extended' 키워드를 도입했습니다. 새로운 상호 참조 기능을 통해 개발자는 Apollo 게이트웨이를 사용하여 지나치게 복잡한 스티칭 로직에 의존하지 않고도 일관된 데이터 그래프를 구축할 수 있었습니다.
하지만 Apollo GraphQL 페더레이션은 단순한 새로운 도구 및 라이브러리 세트가 아니었습니다. 또한 아키텍처와 서비스가 분산 그래프를 형성하기 위해 통신하는 방법을 설명하는 시스템 사양이기도 했습니다. 이를 통해 다른 구현 및 도구에서 페더레이션 원칙을 채택할 수 있었고 페더레이션 GraphQL API를 구축하기 위한 표준을 설정하는 데 도움이 되었습니다.
GraphQL 페더레이션은 도입 이후 수많은 개선을 거쳤습니다. 예를 들어, 관리형 페더레이션은 수동 개입이나 시스템 다운타임 없이도 메트릭을 수집하고 서브그래프가 변경될 때 자동 게이트웨이 업데이트를 활성화할 수 있습니다.
또한, 서비스 간 스키마 병합 및 쿼리 실행을 간소화했고, 스키마 구성을 더 효과적으로 제어할 수 있도록 모듈성을 높였으며, 더 쉬운 추적 및 디버깅을 위해 오류 가시성을 개선한 혁신에 해당하는 페더레이션 21를 개발한 것도 발전에 포함됩니다.
Apollo 페더레이션은 간소화된 API 에코시스템을 구축하는 데 있어 상당한 발전을 이루었고, 아직도 페더레이션 IT 아키텍처를 배포하려는 기업을 위한 옵션으로 남아 있습니다.
그러나 Apollo 기반 페더레이션 접근 방식은 단일 공급업체 구현에 종속시키는데, 이는 Apollo 페더레이션 환경이 Apollo 또는 Apollo 호환 백엔드 기술에서 유래한 Apollo 정의 지시문 및 유형만 허용할 수 있기 때문이다. 다시 말해, Apollo 페더레이션은 새로운 기술이 등장하더라도 시스템 유연성을 제한하는 경우가 많습니다.
Apollo 페더레이션의 통합 계층 기능을 유지하면서 유연성을 최적화하려는 개발자는 개방형 페더레이션을 선호할 수 있습니다. 개방형 페더레이션 접근 방식을 통해 시스템은 비 GraphQL API를 포함하여 모든 API 공급업체 또는 유형의 데이터를 결합할 수 있습니다. IBM API Connect와 같은 도구를 사용하여 기업은 호환성 제한 없이 IT 자산을 사용자 정의하고 확장할 수 있으며, 다양한 기술 커뮤니티의 혁신을 계속 채택할 수 있습니다.
GraphQL은 리소스에 대한 과소 또는 과잉 프로비저닝 없이 고객이 필요한 데이터를 정확하게 요청할 수 있도록 지원하므로, 운영 효율성을 최적화하려는 기업에 훌륭한 옵션입니다.
GraphQL의 유연성을 감안할 때 GraphQL이 API에 대해 점점 더 널리 사용되는 쿼리 언어 및 런타임이 된 것은 놀라운 일이 아닙니다.2 그러나 웹 및 모바일 앱이 더욱 정교해짐에 따라, 단일 모놀리식 GraphQL 서버(및 모든 종속성)를 배포하는 것은 어려워질 수 있습니다. 페더레이션은 서로 다른 서브그래프가 하나의 일관된 GraphQL 서비스로 함께 작동하도록 지원함으로써 GraphQL 에코시스템을 간소화합니다.
페더레이션 GraphQL 아키텍처를 구현하는 데는 다음과 같은 핵심 프로세스가 포함됩니다.
서브그래프 스키마를 정의하려면 도메인 경계를 식별하고 이러한 경계가 상호 작용하는 방식을 결정해야 합니다.
페더레이션 아키텍처에서 각 서브그래프 스키마는 전체 데이터 그래프에서 서비스 또는 도메인에 적용되는 유형, 구성, 쿼리, 변형 및 구독 등의 특정 부분을 나타냅니다. 예를 들어 제품 서비스에는 제품 및 후기와 같은 유형을 포함하는 서브그래프 스키마가 있을 수 있고, 사용자 서비스에는 사용자 및 프로필 유형이 있을 수 있습니다.
서브그래프 스키마는 표준 GraphQL 스키마와 거의 동일한 방식으로 정의되지만, 페더레이션별 지시문이 추가됩니다. 페더레이션 지시문은 시스템이 여러 스키마에 걸쳐 엔티티를 확장하는 방법과 게이트웨이가 여러 서비스에 걸쳐 특정 필드를 해결하는 방법에 대한 지침을 제공합니다. 또한 엔티티를 참조하기 위한 키도 정의합니다.
한 가지 예로, @key 지시문은 여러 페더레이션 그래프에 걸쳐 유형을 식별하는 필드를 지정합니다. 배포될 때 이 지시문은 게이트웨이가 지정된 유형을 소유하는 서비스에서 엔티티를 검색하라는 메시지를 표시합니다. @extends 지시문은 한 서브그래프 스키마에 정의된 유형이 다른 서브그래프 스키마에서 시작된 유형을 확장하여, 다른 서비스에서 유형 확장(추가 필드 포함)을 용이하게 함을 나타냅니다.
서브그래프 서비스는 해당 서브그래프 API에 대한 비즈니스 로직을 구현하는 백엔드 서비스입니다. 각 서브그래프 서비스는 데이터 그래프의 해당 부분을 정의하고 해당 도메인과 관련된 쿼리 및 변형을 처리합니다. 서브그래프 서비스의 개별 리졸버(resolver)는 적절한 데이터 소스, 데이터베이스 또는 REST API에서 모든 관련 데이터를 가져옵니다.
또한 서브그래프 서비스는 GraphQL 엔드포인트를 페더레이션 게이트웨이에 공개하며, 페더레이션 게이트웨이는 이를 사용하여 전체 페더레이션 스키마를 구성합니다. 이러한 서비스는 프로그래밍 언어가 GraphQL을 지원한다고 가정할 때, 해당 언어로 작성할 수 있다는 점에 유의하세요.
페더레이션 게이트웨이는 스키마 구성 및 쿼리 계획을 조율합니다. 페더레이션 서버의 도움으로 게이트웨이는 개별 서브그래프 서비스를 위장하여 클라이언트에 통합 API를 제공합니다.
페더레이션 게이트웨이를 구성하기 위해 팀은 일반적으로 각 서브그래프 서비스의 위치를 지정하고 스키마 가져오기, 쿼리 계획, 실행 및 오류 처리에 필요한 인프라를 설정합니다. 배치된 게이트웨이는 서브그래프 서비스에서 스키마를 지속적으로 가져와서, 최신 버전의 페더레이션 스키마를 보유하게 됩니다.
서브그래프 서비스와 페더레이션 게이트웨이가 구성되면 관리자는 전체 시스템을 배포합니다. 여기에는 하드웨어 및 클라우드 리소스 프로비저닝, 배포 파이프라인 설정, 시스템 성능 모니터링 및 높은 리소스 가용성 보장이 포함됩니다.
일관된 실시간 모니터링이 페더레이션 GraphQL 환경의 최적화에 필수적이라는 것은 놀라운 일이 아닙니다. 철저한 모니터링을 통해 팀은 성능 병목 현상, 시스템 오류 및 계획되지 않은 다운타임이 더 큰 문제를 일으키기 전에 이를 감지하고 해결할 수 있습니다. 또한 모니터링을 통해 서브그래프 서비스 및 페더레이션 게이트웨이에 대한 상황 추적을 수행할 수 있습니다.
GraphQL 페더레이션은 대규모 분산 시스템을 위한 GraphQL API 개발의 상당한 발전을 의미합니다. 이를 통해 팀은 최종 사용자 경험을 방해하지 않으면서도, GraphQL 스키마의 여러 부분에서 독립적으로 작업하는 동시에 작업을 통합 API로 원활하게 통합할 수 있습니다.
또한 GraphQL 페더레이션은 마이크로서비스 아키텍처 배포 및 캐싱에서 제품 개발 및 운영 인사이트에 이르기까지 광범위한 사용 사례를 보유하고 있으며, Netflix, Airbnb, GitHub 및 Expedia와 같은 기업에서 도입했습니다.
GraphQL 페더레이션은 다음과 같은 이점도 제공합니다.
페더레이션 환경에서는 개발자가 특정 데이터 도메인에 대한 책임을 여러 서비스에 분산할 수 있으므로, 개별 서비스(및 해당 기능)를 더 민첩하게 조율하고 확장할 수 있습니다.
페더레이션 서비스는 독립적으로 관리할 수 있기 때문에 팀 구성원은 서로 간섭하지 않으면서 각자의 도메인에서 작업할 수 있습니다.
REST API 환경과 달리, GraphQL 페더레이션을 사용하면 클라이언트가 단일 요청으로 필요한 모든 리소스와 데이터를 가져올 수 있으므로 중복을 제거하고 리소스 배포를 최적화할 수 있습니다.
진화하는 비즈니스 요구 사항에 맞춰 조정되는 동적이고 확장 가능한 통합을 지원합니다. AI 기반의 API 주도 자동화를 만나보세요.
애플리케이션과 시스템을 연결하여 중요 데이터에 빠르고 안전하게 액세스할 수 있는 IBM 통합 솔루션을 활용해 비즈니스 잠재력을 실현하세요.
에이전틱 AI 시대에 하이브리드 클라우드의 가치를 최대한 활용하기
1 Apollo GraphQL Introduces Federation 2 to Get More Organizations to the Graph, BusinessWire, 2021년 11월 3일.
2 Why GraphQL Needs an Open Federation Approach, The New Stack, 2023년 11월 16일.