An interview with Adam Miskiewicz: Software Engineer on API Infra at Airbnb
Q1. 에어비앤비는 GraphQL의 매우 초기 사용자 중 하나였습니다. GraphQL 이전에는 어떤 API를 사용했습니까? 기술적 측면에서 GraphQL로의 원활한 전환을 위해 어떤 팁이 있습니까?
•
Ruby On Rails 기반의 모놀리틱 구조에서 MSA로 이전하면서 일부 API는 RESTful이었고, 많은 다른 API들은 특정 페이지나 기능을 동작시키는 맞춤형 엔드포인트였음
•
GraphQL로 전환하는 것은 재미있는 경험이었지만 장애물이 없진 않았음
•
프론트엔드, 백엔드 양쪽에서 “GraphQL의 형태로 생각하는것”이 쉽지 않긴 했는데, 아래와 같은 이유로 전반적으로 성공했다고 생각함
◦
기존 서비스에서 “자동적으로” GraphQL API를 노출하는 접근 방식으로 취함으로써, 백엔드 엔지니어에게 많은 작업이 요구되지 않음
◦
웹과 모바일에 GraphQL의 점진적 도입을 우선했음. 한번에 모든것을 마이그레이션하는 높은 비용을 피하기 위해 한번에 하나의 기능 또는 페이지를 GraphQL로 전환했음
Q2. 이 블로그 포스팅에서 설명한것 처럼, 책에서 에어비앤비가 사용한 “여러개의 스키마를 하나의 인터페이스로 통합하는 접근 방식”을 설명했습니다. 이건 아주 실용적인 방법이라고 생각합니다. 에어비앤비에서 이 스키마를 재봉합하는(통합하는) 접근방식이 어떻게 작동했습니까? Federation을 고려해본 적이 있습니까?
•
여전히 유지되고 있으며, 모바일 기기에 배포된 API는 결코 사라지지 않기 때문에 오랫동안 지속될 것임. 언급한 대로 확실히 실용적이었고, 그렇게 하지 않았다면 오늘날 에어비앤비에서 GraphQL을 사용하고 있지 않을 것이라고 생각함.
•
이 실용적인 접근 방식의 가치는 단순히 대규모 조직 내에서 새로운 기술을 도입하는 것을 촉진시키는 것 이상이었음. API 접근 방식을 진지하게 검토하게하고, 더 지속가능한 장기적인 관점으로 우리를 이끌고 있다는 것을 알게됨.
•
Federation 의 정신에 따라, 작년말에 우리는 새로운 방식으로 일하는 것을 시작했고, 현재 에어비앤비의 모든 데이터를 위한 단일의 통합된 스키마 구축에 힘쓰고 있음. 이것은 상당히 대규모 작업이고 오랜 시간이 걸릴것으로 판단됨. 그러나, schema fragmentation, data hydration boilerplate와 같은 현재의 많은 문제를 해결하는데 많은 도움이 될 것이라고 믿음
◦
data hydration boilerplate
▪
백엔드는 프론트엔드가 필요로 하는 대로 데이터를 가공하고 조합하는 추가 처리 로직이 필요합니다. 이를 data hydration 라고 하는데, 반복적인 보일러플레이트 코드가 필요하다는 점에서 문제됨. 이로 인해 백엔드 코드의 복잡성이 증가하고, 성능상의 문제도 발생할 수 있음
▪
예)
•
서로 다른 3개 서비스에서 데이터를 받아온 후 통합된 오브젝트를 만들기
•
데이터베이스의 관계를 프론트엔드에서 필요한 평평한(denormalized) 구조로 변환하는 과정
Q3. GraphQL 스키마는 항상 Thrift 또는 다른 모델에서 생성되거나 개발자에 의해 직접 설계되나요? 수많은 개발자들 사이에서 훌륭한 API 설계를 어떻게 보장하고 있나요?
•
현재 GraphQL API 버전에서 스키마는 서비스 팀에서 유지 관리하는 Thrift definition에서 생성됨. 우리는 스키마 설계의 Best Practice가 있지만, 스키마는 본질적으로 단편화되어 있음 (the schema is, by nature, fragmented).
•
각 "presentation service"에는 고유한 스키마가 있으며 독립적으로 설계됨. 이는 변경점의 크기가 제한된다거나 훌륭한 스키마 구축을 위해 많은 팀과 엔지니어들 간의 조정이 필요없는 등 장점을 갖고 있지만, 최종 결과 스키마가 소비 개발자들에게 응집력이 없다는 아주 강한 단점이 있음.
•
더 통합된 접근 방식으로 옮겨가면서 우리는 사실상 스키마 설계의 Best Pratice나, 조직 전체에서 고품질 API를 보장하는 방법에 있어 Facebook, GitHub 및 Shopify 보다 우위에 있음. 처음에는 많은 수동 노동과 코드 검토가 필요하지만 시간이 지남에 따라... 엄청 빛을 발함.
Q4. 기술적인 면에서 에어비앤비와 같은 대규모 회사에서 GraphQL을 운영하고 유지관리하는 데 가장 어려운 것은 무엇인가요?
•
많은 수의 개발자들 사이에서 Best Practice를 유지하는 것 - 어떠한 좋은 기술이라도 부적절하게 사용할 경우 나쁜 코드, 기술 부채 및 버그/성능 문제로 이어질 수 있음. 에어비앤비에는 GraphQL만 담당하는 작은 팀이 있음. 높은 품질의 코드와 Best Practice를 유지하면서 GraphQL의 사용 방법을 가르치는 것은 아주 어려운 일이었음. 물론 이것은 GraphQL에만 국한된 내용은 아니긴 함. 아무튼 우리가 열심히 해야 할 일 중 하나임에는 분명한 사실임.
•
스키마 설계
◦
에어비앤비나 다른 곳에서 대부분의 백엔드 엔지니어는 클라이언트에 API를 노출시키기 위해 RPC 엔드포인트를 구축하는 데 익숙함. GraphQL 스키마 설계는 여러 면에서 상당히 다름. 따라서 많은 팀과 엔지니어들 사이에서 높은 품질의 API 설계를 유지하는 것은 절대 작은 일이 아님. 통합 스키마(consolidated schema)로 옮겨가면서 우리는 스키마를 잘 설계하도록 하는 데 중점을 두고 있음.
•
특히 웹 클라이언트의 성능
◦
우리는 많은 데이터를 반환하는 아주 큰 쿼리들이 많이 있음. 정규화된 캐시를 활용하면서 클라이언트에서 그 데이터를 효율적으로 처리하는 것이 .어려웠음.
◦
따라서 우리는 클라이언트 사이드의 캐싱 접근방식을 재고할 필요가 있다고 생각함
Q5. 조직들은 성능을 염두에 두고 GraphQL을 선택하는 경우가 많지만, GraphQL "실행 엔진(execution engine)"의 오버헤드와 예측 불가능성(unpredictabiity)으로 종종 놀랍니다. 에어비앤비는 성능을 어떻게 모니터링하고 GraphQL API가 성능을 유지하도록 합니까?
•
백엔드 사이드에서는 주로 "실행 오버헤드(execution overhead)" 측정에 초점을 맞춤. 우리는 이를 모니터링하고 경보를 보내며 가능한 한 낮추기 위해 노력함
◦
execution overhead: 전체 요청 기간 - 쿼리의 "임계 경로" 기간, 즉 가장 긴 다운스트림 호출 체인
•
프론트엔드 사이드에서 Chrome(CPU slowdown 포함)에서 지속적으로 프로파일링을 하고 있으며 in-house 성능 도구와 함께 real-world metric을 수집하고 있음.
•
에어비앤비에서의 GraphQL 사용이 증가함에 따라 type의 수가 증가했으며 쿼리가 훨씬 더 커졌음. 이로 인해 프론트엔드와 백엔드 모두에서 성능(특히 꼬리 지연 시간)을 향상시키기 위한 새로운 방법에 대해 생각하기 시작했으며, 곧 그것에 대한 자세한 내용을 공개적으로 공유할 수 있기를 우리도 기대하고 있음.
Q6. 조직 내에 GraphQL 플랫폼을 구축하려는 사람에게 조언을 한 가지만 해야 한다면 무엇이라고 조언하시겠습니까?
•
새로운 기술을 조직에(특히 큰 조직)에 도입하려고 할때, 많은 회의론에 부딪힐 거라고 생각함. 사실 이게 나쁜 일만은 아님. 건강한 회의론을 갖고 있다면 결국 새로운 인프라의 일부를 대폭 향상시키는데 도움이 될 것임.
•
조직 내에서 GraphQL을 추진하고 있는 사람들이 있다면, 회의론에 앞서 가라고 얘기해주고 싶음. 개발자들은 향상된 개발자 경험과 향상된 생산성에 사로잡히지만, 만약 새로운 기술/인프라가 제품의 품질을 저하시킨다면 빠르게 가혹한 비판가가 될 것임. 따라서, API와 클라이언트 사이드 양쪽다 초기에는 성능에 초점을 맞출 것을 추천드림.
•
회사에 프로덕트와 인프라가 분리되어있다면, GraphQL과 관련 도구에 흥미를 보이는 프로덕트 파트너를 먼저 찾아볼 것. 그들의 피드백은 매우 소중하고 값질 것임.