| Status | Authors | Coach | DRIs | Owning Stage | Created |
|---|---|---|---|---|---|
| accepted |
@grzesiek
|
@ayufan
@grzesiek
|
@dsatcher
@deuley
| devops manage | 2021-01-07 |
GraphQL API
GraphQL는 API에 대한 데이터 쿼리 및 조작 언어이자 기존 데이터로 쿼리를 채우는 런타임입니다.
GitLab에서는 넓은 커뮤니티가 신뢰할 수 있는 방식으로 GitLab과 상호 작용할 수 있도록하는 것뿐만 아니라 GraphQL을 통해 백엔드와 프론트엔드 컴포넌트 간의 통신을 모델링하여 자체 제품을 발전시키기 위해 GraphQL을 도입하고자 합니다.
최근에는 GraphQL 이관과 관련된 분기별 OKR을 정의함으로써 채택 속도를 증가시켰습니다. 이로 인해 우리는 GraphQL 개발에 더 많은 시간을 투자하고 새 API를 확장하는 데 필요한 툴링을 개선해야 한다는 필요성을 드러내었습니다.
이 문서는 우리의 개발 노력을 지원하고 GraphQL API의 대규모 사용을 지원할 안정적인 기반을 구축하기 위해 필요한 작업에 대해 설명합니다.
요약
GitLab의 GraphQL 이니셔티브는 약 3년 전에 시작되었습니다. GraphQL 생태계에 대한 대부분의 작업은 GraphQL 전문가인 자원봉사자들에 의해 이루어졌습니다.
우리의 진행 회고는 GraphQL 개발 노력을 최적화하고 성능 하락 및 잠재적인 서비스 중단 위험을 줄이기 위한 필수 메커니즘에 대한 공백과 관련된 기회를 드러내었습니다.
GraphQL 엔진 자체의 소규모 개선을 통해 우리는 팀 멤버가 우리의 GraphQL API 내부에서 무슨 일이 일어나고 있는지 이해할 수 있는 포괄적인 모니터링 대시보드를 구축하고자 합니다. 우리는 SLO를 정의하고 위반된 SLI를 진단하며 Grafana 및 Elastic을 사용하여 관련 세부 정보에 집중할 수 있도록 만들고 싶습니다. 우리는 과거 데이터를 보고 미래 사용량을 예측하고 싶습니다.
레스트 API의 발전 경험을 통해 GraphQL 개발 노력에 이 지식을 적용하여, 규모를 고려해야 합니다. 우리는 쿼리-기능 상관 메커니즘을 구축하고 확장 가능한 상태 동기화 지원을 추가하여 그것을 할 수 있습니다. 그리고 다이렉트 업로드를 지원하는 기존 기능에 GraphQL을 맞추고자 합니다.
기본적으로 GraphQL는 안전해야 합니다. 우리는 우리에게 관련된 OWASP GraphQL 권장 사항을 강제할 수 있는 메커니즘을 구축함으로써 일반적인 보안 오류를 피할 수 있습니다.
넓은 커뮤니티의 요구 사항을 이해하는 것은 우리에게 더 나은 폐기 정책을 계획하고 그들의 요구 사항에 맞는 GraphQL과 REST API 간의 동등함을 설계하는 기회가 될 것입니다.
도전과제
GraphQL에서 무슨 일이 일어나고 있는지 이해하기
프로덕션 환경에서 GraphQL의 성능을 확인할 수 있는 것은 해당 서비스의 성능과 신뢰성을 향상시키기 위한 전제 조건입니다.
우리에게는 아직 GraphQL이 어떻게 성능을 내고 최적화해야 할 병목 현상이 무엇인지에 대답할 수 있는 도구가 없습니다. 이것은 GraphQL의 채택 속도와 예상되는 규모와 결합되어 해결하기 어려운 프로덕션적 인시던트가 증가할 위험을 가중시킵니다.
우리는 GraphQL 엔드포인트의 성능에 초점을 맞춘 포괄적인 Grafana 대시보드를 구축하고자 합니다. 동시에 Elastic에서 GraphQL 쿼리를 더 잘 연관시킬 수 있는 로깅을 개선하고 성능 문제를 조기에 감지할 수 있는 방식으로 인덱싱하기 위해 로깅을 개선하고자 합니다.
- GraphQL을 위한 포괄적인 Grafana 대시보드 구축
- GraphQL 쿼리-기능 상관 메커니즘 구축
- Elastic에서 GraphQL 쿼리 로깅 개선
- 경고를 표시하기 위해 프론트엔드의 오류 처리 재설계
불안정한 GraphQL 데이터 구조 관리
우리의 GraphQL API는 시간이 지남에 따라 진화할 것입니다. GraphQL은 이러한 진화를 쉽게 할 수 있도록 설계되었습니다. GraphQL API는 GraphQL의 구성 방식 때문에 쉽게 확장할 수 있습니다. 그러나 이것은 GraphQL API 버전 관리를 필요로하지 않는 이유입니다. API의 버전을 정의하는 대신 몇 가지 필드를 폐기 표시하고 싶습니다. 그러나 우리는 폐기된 필드 및 유형의 사용 그리고 이를 시각화하는 방법을 이해할 수 있는 방법이 필요합니다. 우리는 폐기된 필드의 사용을 감지하고 제거할 계획임을 사용자에게 알릴 수 있어야 합니다.
- 우리 사용자에게 더 나은 조직을 제공할 수 있는 데이터 기반 폐기 정책 정의
- 폐기된 GraphQL 필드의 사용 빈도를 보여주는 대시보드 구축
- Service Ping에서 폐기된 필드 사용을 보내기 위한 필요한 메커니즘 구축
다른 코드베이스와 일관성 확보
GraphQL이 우리가 작업하는 유일한 것은 아니지만, 모든 제품의 거의 모든 부분에서 수집하고 처리하는 데이터를 노출하는 데 사용됩니다. 그것은 우리의 단일식 코드베이스와 긴밀하게 결합됩니다.
우리는 GraphQL을 사용하는 방식이 GitLab의 성능과 신뢰성을 개선하기 위해 설계한 다른 메커니즘과 일관성이 있는지 확인해야 합니다.
우리는 우리의 레스트 API를 발전시킬 경험을 가지고 있습니다. 이 지식을 GraphQL에 적용하여 그것을 성능 향상 및 기본적으로 안전하게 만들고자 합니다.
- GraphQL을 위한 다이렉트 업로드 설계
- GraphQL 쿼리 깊이 및 복잡성 히스토그램 구축
- 한계에 도달한 GraphQL 쿼리의 양 시각화
- 기존 기능을 위한 GraphQL ETag 지원 추가
레스트 API와의 GraphQL 호환성 설계
우리는 우리의 레스트 API를 폐기할 계획은 없습니다. 이것은 GitLab와 상호 작용하기 위한 간단한 방법입니다. 그리고 GraphQL이 전통적인 레스트 API의 완전한 대체가 될 가능성이 없을 수도 있습니다. 두 API는 함께 공존해야 합니다. 이들 간의 중복을 제거하여 코드베이스를 유지보수 가능하게 만들 필요가 있습니다. 그러나 이 공생은 백엔드에서 해결해야 할 기술적인 도전뿐만은 아닙니다. 사용자는 두 API를 교차로 사용하거나 동시에 사용할 수도 있습니다. 리소스 식별자에 대한 공통 체계를 노출함으로써 이를 상호 교환할 수 있게 만들어야 하는 것이 전제 조건입니다.
- GraphQL과 레스트 API 상호 운용 가능하게 만들기
- 두 API에 대한 공통 리소스 식별자 설계
확장 가능한 상태 동기화 메커니즘 설계
GitLab에서의 GraphQL 채택과 관련된 가장 중요한 목표 중 하나는 GitLab 백엔드와 프론트엔드 컴포넌트 간의 상호 작용을 모델링하는 데 사용하는 것입니다. 이는 이미 기존 동기화 메커니즘의 향상 및 기존 동기화 메커니즘을 연결하는 필요성을 드러냈습니다.
- 확장 가능한 상태 동기화 메커니즘 설계
- Pub/Sub 및 웹소켓을 통한 상태 동기화 평가
- GraphQL 기능 상관 및 기능 ETag을 위한 일반적인 지원 구축
- 공유 글로벌 상태를 관리하는 프론트엔드 코드 재설계