아키텍처는 정적 분석, 동적 부하 테스트 및 스키마 거버넌스를 결합한 다계층 검증 접근 방식을 요구합니다. 첫째, 실행 전 복잡도 점수(깊이 및 너비)를 계산하기 위해 GraphQL 스키마 내성 분석을 사용하여 구성 가능한 임계치를 초과하는 쿼리를 거부합니다. 둘째, k6 또는 Artillery를 사용하여 고부하 중첩 쿼리를 시뮬레이션하여 자원 소모를 탐지하는 동적 분석을 사용합니다. 셋째, 연합을 위해 CI에서 Apollo Federation 구성 검사를 사용하여 서브그래프 호환성과 게이트웨이 스티칭 로직을 검증합니다. 이러한 모든 것을 Node.js 테스트 헬스와 Jest를 사용해 커스텀 매처를 추가하여 서비스 경계를 넘어 계약이 유지되도록 보장합니다.

생활 속 상황

한 핀테크 회사가 마이크로서비스를 위해 REST에서 Apollo Federation으로 전환했습니다. 전환 후, 모바일 클라이언트가 사용자 -> 계좌 -> 거래 -> 감사 로그를 가져오는 지수적으로 복잡한 중첩 쿼리를 보낼 때 생산 환경에서 중단이 발생했습니다. PostgreSQL CPU 스파이크가 발생했습니다.

솔루션 A: 클라이언트 측 쿼리 화이트리스트

팀은 persisted queries를 사용하여 승인된 쿼리의 엄격한 허용 목록을 유지하는 것을 고려했습니다. 이 접근 방식은 미리 등록된 작업만을 허용함으로써 안전성을 보장합니다. 그러나 이는 엄격한 클라이언트 조정을 요구하고, 합법적인 내부 도구에 의한 임의의 탐색을 방해하며, 모바일 버전과 백엔드 스키마 업데이트 간의 배포 결합을 초래합니다.

솔루션 B: 깊이 제한 미들웨어

중첩을 5단계로 제한하는 간단한 깊이 제한기를 구현하는 것이 제안되었습니다(예: graphql-depth-limit 라이브러리). 경량적이고 배포하기 쉽지만, 필드 레벨 복잡도를 고려하지 못합니다. 깊이 3에서 수천 개의 레코드를 요청하는 쿼리는 단일 객체를 가진 깊이 5 쿼리보다 더 많은 자원을 소모합니다.

솔루션 C: 필드 비용 분석을 통한 복잡도 점수 매기기

선택된 솔루션은 SQL 쿼리 비용에 따라 필드에 숫자 비용 가중치를 할당하는 것이었습니다(예: 스칼라=1, 리스트=10, 재귀=50). 이 프레임워크는 실행 전에 총 쿼리 비용을 계산하고 1000 포인트를 초과하는 요청을 거부합니다. 이는 유연성과 보호를 균형 있게 유지합니다.

const { createComplexityLimitRule } = require('graphql-validation-complexity');
const rule = createComplexityLimitRule(1000, {
  onComplete: (c) => console.log(`Complexity: ${c}`)
});

선택된 솔루션

팀은 내부 분석 팀에 필요한 GraphQL 탐색의 동적 특성을 희생하지 않으면서 세밀한 제어를 제공하는 솔루션 C를 선택했습니다. 화이트리스트와는 달리 합법적인 복잡한 쿼리를 차단하지 않았고, 단순한 깊이 제한과는 달리 데이터베이스 부하를 정확히 반영했습니다. 이 접근 방식은 클라이언트 배포와 안전성 검증을 분리했습니다.

결과

이 결과는 생산 중단을 없애면서 GraphQL의 유연성을 유지하고, 피크 부하 동안 P95 대기 시간을 4.2초에서 280ms로 줄였습니다. 이 프레임워크는 이제 생산에 도달하기 전에 CI에서 악의적인 쿼리를 자동으로 거부합니다.

후보자들이 자주 놓치는 것들

GraphQL 내성 분석이 자동화 프레임워크에서 REST 스키마 검증과 어떻게 다른가요?

많은 후보자들이 GraphQL 스키마 내성 분석을 OpenAPI 검증과 혼동합니다. GraphQL 내성 분석은 서버가 __schema 쿼리를 통해 자신의 전체 타입 시스템을 노출하는 런타임 반사 기능입니다. 이를 통해 자동화 도구가 실제 배포된 스키마에 대해 쿼리를 검증할 수 있습니다. 이는 테스트 자동 생성을 가능하게 하며, 프레임워크가 스키마를 크롤링하여 모든 필드에 대한 유효한 쿼리를 자동으로 생성하도록 합니다. 이는 실제로 어떤 리졸버도 테스트되지 않도록 보장합니다. REST에서는 계약 테스트가 정적 Swagger 파일에 대해 유효성을 검증하는 반면, GraphQL 테스트는 그래프 특성을 고려해야 합니다. 비즈니스 로직을 위반하지 않는지 확인하기 위해서는 응답 페이로드 모양과 오류 확장에 대한 컨텍스트 인식 주장이 필요하며, 단순한 HTTP 상태 코드만으로는 부족합니다.

전통적인 주장 패턴이 GraphQL 변조를 테스트할 때 왜 실패하는가?

후보자들은 종종 GraphQL 변조를 데이터베이스 트랜잭션에 래핑하여 테스트 후 롤백하는 방법을 시도합니다. 이는 REST 통합 테스트를 모방하는 것입니다. 그러나 GraphQL 리졸버는 데이터베이스 롤백에도 불구하고 지속적인 비동기적인 부작용(웹훅, 메시지 큐 게시, 타사 API 호출)을 유발할 수 있습니다. 올바른 접근 방식은 각 테스트 작업자에 대해 격리된 PostgreSQL 인스턴스를 실행하기 위해 TestContainers를 사용하고, 외부 호출을 캡처하기 위해 WireMock을 사용하는 것입니다. 주장은 변조 응답뿐만 아니라 캡처된 부작용 페이로드도 검증해야 합니다. 이는 특정 상황에서의 안전성과 올바른 이벤트 발생을 보장하는 중요한 요소입니다. 트랜잭션 롤백만으로는 이벤트 기반 GraphQL 아키텍처에서 검증할 수 없습니다.

GraphQL 자동화에서 "N+1 문제"는 무엇이며 테스트 중 어떻게 탐지하나요?

N+1 문제는 리졸버가 부모 객체 목록을 가져온 다음 각 자식 필드에 대해 개별 데이터베이스 쿼리를 실행할 때 발생합니다. 후보자들은 종종 모의 데이터 로더로 단위 테스트를 수행하기 때문에 이 문제를 간과합니다. 자동화에서는 DataLoader 배치 검증을 통합해야 합니다. 테스트 실행 중 OpenTelemetry를 사용하여 SQL 쿼리를 추적하고, 100명의 사용자를 가져올 때 정확히 두 개의 쿼리(사용자에 대한 쿼리 하나와 프로필에 대한 쿼리 하나)를 생성하는지 확인해야 합니다. 쿼리 수가 1 + (액세스된 고유 엔티티 유형 수)를 초과하면 테스트 헬스가 실패하도록 구성해야 합니다. 이는 Dataloader 패턴이 연합 서브그래프에서 올바르게 구현되었는지 검증하여 실제 데이터베이스 볼륨에서만 나타나는 성능 저하를 방지합니다.