페더레이션 게이트웨이란 무엇인가요?

중앙 집중식 시스템에서는 단일 게이트웨이(여러 API에 연결되고 관리를 담당함)가 모든 클라이언트 쿼리를 처리합니다. 반면 게이트웨이 페더레이션을 통해서는 API 게이트웨이의 분산 네트워크를 사용할 수 있으며, 각 게이트웨이는 고유한 서비스 세트를 담당합니다.

페더레이션 게이트웨이 시스템에서 팀은 전체 시스템에 영향을 주지 않고 필요에 따라 서비스를 추가할 수 있으므로 효율적인 리소스 사용 및 트래픽 관리가 가능합니다. 별도의 부서는 서로 다른 프로토콜을 사용하여 해당 게이트웨이를 관리할 수도 있습니다. 이 프레임워크는 팀이 자체 API를 관리할 수 있는 자유를 제공하여 유연성, 운영 복원력 등을 개선합니다.

이 접근 방식은 또한 중앙 집중식 API Gateway와 관련된 트래픽 병목 현상 및 기타 문제를 방지하고 게이트웨이 기능을 최종 사용자에게 더 가깝게 배포하여 성능 이점을 제공할 수 있습니다. 게이트웨이 페더레이션 전략은 각각 장단점이 있는 REST, gRPC 및 SOAP를 비롯한 다양한 API 아키텍처 스타일 및 프로토콜에 적용할 수 있습니다.

IT 관점에서 페더레이션 게이트웨이는 DevOps 팀이 전사적 API 플랫폼 관리, 거버넌스 및 보안 정책을 준수하면서 자체 API를 개발하고 배포할 수 있기 때문에 유용합니다. 팀은 조직 전체의 표준을 유지하면서 조직 전체의 표준을 유지하면서 빠르고 독립적으로 움직여 자신의 영역에서 프로젝트를 완료할 수 있으며(혁신 촉진 및 시장 출시 속도 가속화) 팀 자율성과 중앙 집중식 감독 사이의 균형을 유지할 수 있습니다.

GraphQL 페더레이션은 통합 GraphQL API를 만드는 데 사용되는 대안적 개념 및 아키텍처 접근 방식입니다. 이 페더레이션은 단일 API 쿼리로 여러 서비스의 리소스를 정확하게 타겟팅할 수 있는 쿼리 언어인 GraphQL을 기반으로 합니다.

GraphQL 페더레이션은 각각 관리하는 데이터를 정의하는 자체 스키마가 있는 다양한 서비스(서브그래프라고 함)를 슈퍼그래프라는 통합 스키마에 연결합니다. 단일 게이트웨이는 이 슈퍼 그래프 스키마를 클라이언트 애플리케이션에 노출하고 여러 개의 기본 서비스 및 필드를 통합하고 모든 API 쿼리를 라우팅합니다. 반면, 게이트웨이 페더레이션은 중앙 컨트롤 플레인을 통해 여러 API Gateway를 연결하며, 각 게이트웨이는 자체 쿼리를 처리합니다.

페더레이션은 공통의 컨트롤 플레인을 통해 자율 구성 요소를 연결하는 시스템 관리에 대한 일반적인 접근 방식입니다.

중앙 집중식 게이트웨이 시스템에서 모든 클라이언트 요청은 라우팅, 인증, 권한 부여 및 모니터링과 같은 기능을 관리하는 단일 게이트웨이를 통과합니다. 페더레이션 아키텍처와 달리 이러한 책임은 여러 인스턴스에 분산되지 않습니다.

이 접근 방식은 이러한 각 프로세스가 게이트웨이를 통과하기 때문에 로깅, 트래픽 관리, 보안 적용 및 기타 작업을 간소화할 수 있습니다. 조직은 단일 지점에서 롤아웃을 시작할 수 있으므로 여러 게이트웨이 및 서비스에 걸쳐 업데이트 버전을 관리할 필요가 없습니다.

그러나 중앙 집중식 프레임워크를 사용하는 회사는 특히 운영 규모를 확장할 때 병목 현상이 발생할 가능성이 더 높습니다. 시스템의 단일 통과 지점인 게이트웨이는 혼잡해지기 쉽습니다. 또한 단일 장애 지점이 나타나며 오류가 발생하면 전체 시스템에 영향을 미칩니다.

중앙 집중식 시스템과 달리 페더레이션 게이트웨이 아키텍처는 여러 게이트웨이로 구성되며, 각 게이트웨이는 고유한 서비스 세트 및 관련 API를 담당합니다. 게이트웨이는 각각 중앙 컨트롤 플레인에 의해 관리되지만 독립적으로 작동합니다.

중앙 집중식 프레임워크에 비해 페더레이션 시스템은 개발 팀이 해당 도메인에 대해 더 높은 수준의 제어를 제공함으로써 유연성과 자율성을 촉진합니다. 또한 이러한 분산형 레이아웃은 중단 및 시스템 오류 발생 시 페더레이션 시스템의 복원력을 높입니다.

그러나 페더레이션 시스템은 운영이 더 복잡하여 잠재적으로 거버넌스 격차와 팀 간의 잘못된 의사소통을 초래할 수 있습니다. 각 게이트웨이를 별도로 관리하고 업데이트해야 하기 때문에 롤아웃에 더 오랜 시간이 걸리고 유지 관리 비용이 더 많이 소요될 수 있습니다.

기업이 페더레이션 게이트웨이 시스템을 선택하는 데에는 몇 가지 이유가 있습니다.

우선, 게이트웨이 페더레이션은 회사가 인수한 회사로부터 서로 다른 기술 스택과 API 관리 시스템을 상속하는 인수 합병의 경우에 일반적으로 사용됩니다. 기업은 각각 고유한 보안 프로토콜, 기술 표준 및 거버넌스 구조를 가진 여러 개의 개별 아키텍처를 개별적으로 관리하거나 인수한 시스템을 기존 엔터프라이즈 시스템으로 개조하려고 시도하는 대신 게이트웨이 페더레이션으로 전환합니다. 이 접근 방식을 통해 조직은 기존 API Gateway와 그 하위 시스템을 중앙 컨트롤 플레인에서 제공하는 상위 구조에 포함할 수 있습니다.

마찬가지로 여러 게이트웨이는 서로 다른 팀에서 구축하고 서로 다른 설정에 분산된 많은 마이크로서비스가 있는 환경에서 자주 사용됩니다. 기업은 성능 이점을 위해 페더레이션 시스템을 선택할 수도 있습니다.

예를 들어, 전 세계에 여러 사무실을 두고 각 사무실이 특정 지역을 담당하는 물류 회사를 생각해 보세요. 회사는 게이트웨이, 서버, 서비스 및 기타 리소스를 액세스하는 클라이언트와 더 가까운 곳에 배치함으로써 지연 시간 및 관련 성능 요소를 최적화할 수 있습니다.

게이트웨이 페더레이션에서 중앙 컨트롤 플레인은 관리, 모니터링 및 거버넌스를 처리하지만, 일반적으로 클라이언트는 이에 액세스할 수 없습니다. API 소비자는 페더레이션 시스템을 구성하는 게이트웨이와 직접 상호 작용하지만(관련 서비스를 담당하는 엔드포인트 쿼리) 컨트롤 플레인 자체는 쿼리하지 않습니다. 플레인은 API 호출이 이미 발생한 후에만 메타데이터와 로그를 수신합니다.

이러한 접근 방식은 운영상의 복잡성을 야기할 수 있지만, 독립성을 촉진하기도 합니다. 예를 들어 플랫폼 팀이 특정 요구 사항을 충족하도록 자체 게이트웨이와 서비스를 구성하고, 자체 프로토콜을 선택하고, 자체적으로 롤아웃을 배포할 수 있도록 지원합니다. 또한 페더레이션 아키텍처는 오류가 발생한 게이트웨이로 격리되어 네트워크의 다른 게이트웨이로 확산될 가능성이 낮기 때문에 잘못된 설정 및 보안 침해에 대한 복원력이 뛰어납니다.

한편 GraphQL 페더레이션에서는 여러 독립 서비스(서브그래프)의 스키마가 하나의 통합 슈퍼그래프 스키마로 결합됩니다. 단일 게이트웨이 또는 라우터는 클라이언트 쿼리에 대한 단일 진입점을 제공하여 통합 API 환경을 제공합니다.  

라우터는 쿼리를 더 작은 하위 요청으로 지능적으로 분할하여 여러 서브그래프에서 관련 정보를 검색하고 이를 클라이언트에 대한 응집력 있는 응답으로 컴파일합니다.

다음 대상에게 별도의 서비스를 제공하는 의료 플랫폼을 상상해 보세요.

• 환자: 환자 세부 정보, 연락처 정보 및 병력 관리
  
  
• 예약: 예정된 방문 일정 예약 및 추적
  
  
• 청구: 청구서 및 청구 알림 처리

GraphQL 페더레이션은 별도의 API 호출로 이러한 각 엔드포인트를 쿼리하는 대신 클라이언트(이 경우 의사 또는 환자에게 서비스를 제공하는 앱 또는 대시보드)가 세 개의 개별 요청이 아닌 단일 API 호출로 환자의 병력에 액세스하고, 다음 약속을 식별하고, 미결제 잔액을 확인할 수 있도록 하는 통합 인터페이스를 제공합니다.

GraphQL 페더레이션은 분산 환경에서 확장 가능한 GraphQL API를 구축하는 방법을 제공합니다. 이 프레임워크를 사용하면 클라이언트 쿼리에 대한 통합 프론트엔드를 제공하는 동시에 서비스의 독립적인 개발 및 배포가 가능합니다. 그러나 GraphQL 페더레이션은 비용 및 복잡성 문제, 보안 취약성, 정체 및 중복이 발생하기 쉽습니다.

2019년에 도입된 Apollo 페더레이션은 GraphQL 스키마 정의 언어 내에서 특수 지시문(예: @key 또는 @extends)을 사용하여 서브그래프 전체에서 서로 다른 유형 간의 관계를 정의하는 GraphQL 페더레이션의 구현입니다.

Apollo는 일반적인 솔루션이지만, 사용 가능한 유일한 GraphQL 페더레이션 옵션은 아닙니다. 일반적인 대안으로는 Hive, Mesh, Indigo 및 WunderGraph Cosmo가 있으며, 각각 다양한 수준의 사용자 정의를 제공합니다. 

리서치 기관인 Gartner에 따르면 2024년에는 5% 미만의 기업만이 GraphQL 시스템을 페더레이션했지만, 2027년에는 이 수치가 30%에 이를 것으로 예상됩니다. Amazon Web Services(AWS) 및 Microsoft Azure와 같은 주요 클라우드 제공업체뿐만 아니라 GitHub와 같은 코드 리포지토리도 관측 가능성 및 검증 도구가 내장된 GraphQL API를 지원합니다.

GraphQL 페더레이션에는 특히 클라이언트에 대한 API 액세스를 간소화하는 기능에 몇 가지 뚜렷한 이점이 있습니다. 팀은 자체 서브그래프를 배포, 관리 및 확장하여 어느 정도의 독립성을 유지할 수 있습니다.

그러나 중앙 집중식 프레임워크인 GraphQL 페더레이션은 보안 실패, 정체 문제 및 성능 비효율성에 더 취약합니다. 또한 GraphQL 스키마에 의존하는 반면 API Gateway 페더레이션은 여러 프로토콜과 호환됩니다.

API 전략을 개발할 때 조직은 GraphQL API 프레임워크를 채택할지 아니면 REST와 같은 다른 아키텍처 스타일을 사용할지 결정합니다.

최종적으로 조직은 GraphQL 페더레이션과 다른 아키텍처 스타일을 모두 시스템에 통합하여 각각 다른 기능을 처리하도록 선택할 수 있습니다. 한 가지 일반적인 구성으로 기업은 내부적으로 GraphQL을 사용하고(보안, 비용 또는 복잡성 문제를 완화하기 위한 엄격한 보호 장치를 사용) 외부 API에 대해 REST와 같은 다른 아키텍처 스타일(보다 심층적인 제어 및 더 쉬운 채택을 제공할 수 있음)을 사용합니다. 이 시나리오에서는 페더레이션된 API Gateway를 사용하여 중앙 컨트롤 플레인을 통해 이러한 이질적인 아키텍처 스타일을 통합할 수도 있습니다.

표준 API Gateway 구성에서는 단일 게이트웨이가 모든 사용자 트래픽, 라우팅 및 분석을 처리합니다. 이 접근 방식은 더 간단한 설정을 간소화하는 데 도움이 되지만, 더 복잡한 환경에서는 빠르게 병목 현상이 발생할 수 있습니다.

페더레이티드 게이트웨이는 단일 API Gateway뿐만 아니라 여러 API Gateway를 사용합니다. 각 게이트웨이는 특정 서비스 집합에 대한 API 호출을 관리하는 데 사용되며, 게이트웨이는 관리 및 거버넌스를 처리하는 컨트롤 플레인에 연결됩니다.

한편 서비스 메시는 마이크로서비스 간의 연결을 관리하지만 사용자 자신과 인터페이스하지 않기 때문에 동서 구성(east-west configuration)으로 간주됩니다. 서비스 메시는 주로 단일 환경 또는 클러스터 내에서 커뮤니케이션과 관측 가능성을 용이하게 합니다. 그러나 하이브리드 클라우드 메시로 알려진 변형은 여러 클러스터 및 환경(멀티 클라우드, 하이브리드 클라우드 및 온프레미스 환경 포함)에서 암호화, 로드 밸런싱 및 인증과 같은 기능을 수행하도록 최적화되어 있습니다. 

조직은 다양한 전략을 사용하여 페더레이션 게이트웨이의 분산 아키텍처를 활용하면서 페더레이션 시스템과 관련된 운영 복잡성 및 유지 관리 비용을 줄일 수 있습니다. 이러한 관행은 팀 자율성을 유지하는 동시에 팀 간의 열린 커뮤니케이션과 통일된 감독을 유지하는 데 도움이 됩니다.

기업은 각 팀을 명확하게 구분하여 각 구축 및 유지 관리를 담당하는 서비스의 모호성을 제거해야 합니다. 이러한 관행은 책임감을 촉진하고 팀이 실수로 동료의 작업을 복제하거나 잘못 구성하는 일을 방지합니다. 더 나아가 이 접근 방식은 팀이 목표와 책임(그리고 이에 따라 행동할 수 있는 자유)을 확고히 이해하고 있기 때문에 생산성을 높일 수 있습니다.

게이트웨이와 API에서 보안 및 규정 준수 프로토콜과 표준을 일관되게 구현하지 않으면 보안, 법률 및 평판 위험이 발생할 수 있습니다. 분산 시스템에서는 게이트웨이 전반의 로깅, 암호화, 인증 및 기타 보안 구현에 대한 표준을 유지하는 것이 우선 순위여야 합니다. 이렇게 하면 위협이 어느 도메인에서 발생했든 상관없이 중앙 컨트롤 플레인을 사용하여 사고 보고서에 효율적으로 대응하고 포괄적인 감사를 수행하며 향후 공격을 방지할 수 있습니다.

분산 시스템의 관측 가능성 격차로 인해 보안 위험과 성능 문제가 발생할 수 있습니다. 중앙 컨트롤 플레인이 팀이 시스템 건강과 성능을 확인하는 데 필요한 포괄적인 가시성을 제공하는 것이 중요합니다. 이 기능을 사용하면 문제가 발생했을 때 신속하게 해결할 수 있을 뿐만 아니라 보안 및 성능 지표를 기반으로 선제적으로 개선할 수 있습니다.

통합 개발자 포털은 개발자가 호스팅 위치나 구조 방식에 관계없이 시스템의 모든 API에 액세스하고 학습할 수 있는 중앙 집중식 허브 역할을 합니다. 이는 DevOps 팀이 API를 구축, 배포 및 유지 관리하는 방법에 대한 명확한 프레임워크를 제공하기 위해 지침, 문서 및 코딩 샘플을 제공하기 때문에 페더레이션 시스템에서 특히 중요합니다.

API 키 및 기타 액세스 제어와 함께 이러한 범용 표준은 개발자가 시스템에 API를 원활하게 추가하고 보안과 일관성을 유지하면서 자체 게이트웨이를 관리하는 데 도움이 됩니다.

각 팀은 어느 정도 자율성을 가지고 행동하기 때문에 모범 사례를 공유하고 지속 가능한 네트워크를 유지하려면 열린 커뮤니케이션 라인이 필수적입니다. 대시보드 및 기타 협업 도구는 특히 한 도메인의 변경이 관련 서비스에 영향을 미칠 수 있는 경우 팀이 공유된 목표와 절차를 중심으로 동기화하는 데 도움이 될 수 있습니다.

포괄적인 보고 메커니즘을 통해 DevOps 팀은 지연, 서비스 중단 및 기타 이상 현상을 신속하게 감지하고 해결하여 보다 원활한 사용자 경험에 기여할 수 있습니다. 성능 지표는 또한 시스템의 어느 부분이 용량에 도달하고 어떤 부분이 저조한지 식별하여 규모 효율성을 개선할 수 있습니다.

코드형 인프라(코드를 사용하여 수동 감독 및 프로비저닝이 필요한 IT 프로세스 자동화) 및 AIOps(AI를 사용하여 IT 운영 간소화)와 같은 최신 DevOps 접근 방식은 페더레이션 게이트웨이를 보다 효율적으로 운영하는 데 도움이 될 수 있습니다. 자동화 기술은 인적 오류의 가능성을 줄이고 IT 팀이 더 복잡한 문제에 집중할 수 있는 대역폭을 제공하므로 네트워크를 더욱 탄력적으로 만드는 데 도움이 됩니다.

게이트웨이 페더레이션은 분산형 아키텍처의 유연성과 사용자 정의를 중앙 집중식 거버넌스 구조와 결합하며 기존 아키텍처에 비해 몇 가지 이점을 제공할 수 있습니다.

팀은 페더레이션을 통해 자체 게이트웨이를 제어하여 런타임 구성을 조정하고, 업데이트를 관리하고, 클라이언트 및 서비스의 요구 사항에 가장 잘 맞도록 코딩 환경을 사용자 지정할 수 있습니다. 예를 들어, 중앙 집중식 시스템에서 API의 속도 제한을 조정하려면 팀은 조직의 단일 게이트웨이를 통해 요청을 제출해야 합니다. 팀은 페더레이션 시스템을 통해 네트워크의 다른 게이트웨이에 영향을 주지 않고 독립적으로 실시간으로 조정할 수 있습니다.

중앙 플레인은 여러 게이트웨이가 각자의 구성에도 불구하고 공유 호환성 및 안전 표준을 준수할 수 있도록 지원합니다. 팀은 컨트롤 플레인이 제공하는 외부 감독을 활용하면서 자율적으로 매개변수를 조정할 수 있는 유연성을 확보할 수 있습니다.

페더레이션 접근 방식은 개발팀이 자체 도메인을 개선하고 유지하는 방법에 대해 가장 잘 알고 있는 경우가 많다는 점을 인식합니다. 팀에는 문제가 발생하는 즉시 API 또는 서비스를 조정할 수 있는 자율성이 주어져 적응력과 민첩성이 향상됩니다. 

팀은 중앙 컨트롤 플레인과 서비스의 관계를 유지하면서 다양한 코딩 언어에서 작업할 수도 있습니다. 마지막으로, 부서는 변경 사항을 승인하기 위해 중앙 기관에 의존하는 대신 필요에 따라 업데이트를 출시하여 새로운 기능의 출시 시간을 단축하고 워크플로를 간소화할 수 있습니다.

페더레이션 시스템은 팀이 자체 성능을 모니터링하고 그에 따라 속도 제한과 트래픽 분배를 조정할 수 있도록 하여 보다 효율적인 리소스 프로비저닝을 제공할 수 있습니다. 조직은 추가 용량이 필요한 서비스와 기능만 확장하여 사용이 적은 서비스나 지역의 리소스를 수요가 더 높은 서비스나 지역으로 집중시킬 수 있습니다.

또한 API Gateway는 독립적이기 때문에 취약점이 한 게이트웨이에서 다른 게이트웨이로 이동하기가 더 어렵습니다. 결과적으로 페더레이션 시스템은 일반적으로 장애가 전체 시스템이 아닌 단일 게이트웨이에만 영향을 미칠 가능성이 높기 때문에 공격 및 중단에 대한 복원력이 더 높습니다.

페더레이션 시스템에서 개별 DevOps 팀은 자체 게이트웨이의 운영 및 유지 관리를 수행합니다. 더 적은 책임으로 중앙 팀은 규정 준수 규정 시행, 팀 간 교차 커뮤니케이션 촉진, 시스템 아키텍처 개선과 같은 더 높은 수준의 문제에 집중할 수 있습니다.

페더레이션된 게이트웨이가 성능을 분석하고 도메인 전체에 보호 장치를 적용할 수 있기 때문에 데이터 사일로가 발생할 가능성이 훨씬 적습니다. 교차 게이트웨이 지표는 특정 서비스가 관련 제품 및 서비스에 어떤 영향을 미치는지에 대한 보다 전체적인 보기를 제공할 수 있습니다.

분산된 소유권과 유연성은 특히 거버넌스나 관측 가능성에 장애가 있을 때 여러 가지 문제를 야기할 수 있습니다. 페더레이션 게이트웨이로 인해 발생하는 문제는 다음과 같습니다.

팀 자율성은 혁신을 주도하는 데 도움이 될 수 있지만, 시스템에 아키텍처 복잡성을 추가하여 인프라 및 컴퓨팅 비용을 증가시킵니다. 또한 페더레이션 시스템은 분산된 구조로 인해 더 많은 유지 관리 및 보안 리소스가 필요한 경향이 있습니다.

지표와 로그는 여러 API Gateway에 분산되어 있기 때문에 조직이 전체 시스템의 성능에 대한 일관된 그림을 구축하는 것이 더 어려울 수 있습니다. 데이터 소스가 단편화되고 더 넓은 네트워크와의 연결이 끊어질 수 있으므로 잠재적인 잘못된 구성을 식별하고 해결하는 것이 더 어려워질 수 있습니다. 조직은 강력한 표준화 프로토콜 및 원칙, 관측 가능성 툴을 통해 이 도전을 해결할 수 있습니다.

각 팀은 재량에 따라 업데이트할 수 있지만, 전사적 롤아웃은 중앙 집중식 환경보다 시간이 더 오래 걸릴 수 있습니다. 페더레이션 게이트웨이는 단일 중앙 코드베이스를 업데이트하는 대신 여러 도메인에 업데이트를 배포해야 하며, 각 팀은 이러한 변경 사항을 독립적으로 승인하고 통합할 책임이 있습니다.

분산 게이트웨이 전체에서 일관된 구성과 정책을 유지하는 것은 어려울 수 있습니다. 팀이 엔터프라이즈 거버넌스 표준에서 벗어난 프로토콜, 롤아웃 일정 및 데이터 형식을 채택하면 비호환성 및 보안 취약성이 발생할 수 있습니다. 반대로 표준과 거버넌스 정책이 너무 엄격해지면 기업은 실험을 억누르고 혁신 속도를 늦출 위험이 있습니다. 페더레이션 시스템에서는 균형이 매우 중요합니다.

기업이 페더레이션 시스템 하에서 성장하고 발전함에 따라 여러 팀이 의도치 않게 중복 API를 개발할 때 API 무분별한 확장과 같은 새로운 비효율성이 발생할 위험이 있습니다. 이 문제가 확대되면 게이트웨이를 관리할 수 없게 되어 중앙 플레인에서 변경 사항을 추적할 수 없게 될 수 있습니다. 이 문제는 효율적인 거버넌스를 통해 완화할 수 있습니다.