FAANG 14 - Tinder xây dựng API gateway thế nào

 

Hằng là một cô gái tuổi mới chừng đôi mươi. Cô làm việc cho một ngân hàng nổi tiếng ở Việt Nam. Xinh đẹp quyến rũ, cô thường xuyên gọi vốn trên Pickel Ball và khởi nghiệp bằng quẹt Tinder. Một dating application rất nổi tiếng, với hơn 6.2M suscribers và 75M monthly active users.

Để giúp người như cô có thể tìm được nửa kia của mình, kĩ sư Tinder đã phát triển Match API and Recommendation API, tính năng cho phép tìm kiếm và recommend người “best fit” với cô nhất. Bằng nhiều thuật toán phức tạp ML, Localizations, cuối cùng cô đã tìm được người mà mình thương mến, mặc dù gia đình cấm cản, cụ thể là vợ, nhưng hai người vẫn đến được với nhau. Những tưởng hai người sẽ happy ending, nhưng một ngày, người vợ bằng cách nào đó đã tìm được vị trí của 2 người, gây ra một vụ đánh ghen lớn nhất trong lịch sử cõi mạng. Điều này đã ảnh hưởng đến hình ảnh của Tinder trong việc xử lý vấn đề data privacy, vì sao API Matching tại recommend cô một người đàn ông có gia đình, có phải Tinder đã để lộ data dating của 2 người đến third party? Làm thế nào Tinder có thể public API trong khi vẫn đảm bảo security và authorization?

The Underlying Problem

Tinder được build trên kiến trúc microservice với hơn 500 microservice, giao tiếp qua lại trên nền service mesh. Ví dụn Matching serivce tìm kiếm đối tượng best fit với user dựa vào các thông tin về tuổi tác địa điểm, cô gái ở Cần Thơ thì không thể tìm người Best Fit ở Trâu Quỳ được, sau đó gửi output cho Recommendation Service để recommend user. Mà muốn vậy, Matching phải biết thông tin về Recommendation Serivce như endpoint address, communication protocol, đảm bảo data transfer giữa hai service phải bảo mật. Rồi nếu như Recommendation service gặp lỗi Matching service phải implement cơ chế retry pattern, apply SAGA pattern , giúp cho dữ liệu được consistency hoặc eventually consistency. Cuối cùng Developer bị quá sa đà vào implement vào network, security, communication và không còn tập trung vào xử lý bussiness logic của Service. Cho nên Tinder sử dụng giải pháp Service Mesh Istio để giải quyết vấn đề trên

Các Service như Matching Recommendation được đặt ở tầng Data Plane, tích hợp Envoy Proxy để thực hiện Service Discovery ( collect thông tin về service như name, endpoint…), authentication, tracing requests đến service, rate limiting… tóm lại đủ thứ

Tầng control plane quản lý microservice, tương tự như kiến trúc của K8s

Tinder API Gateway

Vấn đề microservice được giải quyết, nhưng làm sao để expose API Tinder cho người dùng như Hằng để cô tìm được nửa kia của mình mà vẫn đảm bảo strictly authorization and security. Theo kiến trúc truyền thống đó là sử dụng 3rd party API Gateway như APIM của Azure, Kong, APIgee, Krakend

Tuy nhiên Tinder có những requirement và challenging riêng khiến cho 3rd party API Gateway không thể áp dụng

Tinder build và hosted trên AWS và họ muốn centralize all external-facing services

Application team cần một tool đơn giản giúp họ tự tạo API Gateway, cho phép scale độc lập

Deploy everything trên K8s microservices

Customize middleware logic tại tầng API gateway như Bot Detection, Schema Registry

Để speed up development, Tinder muốn API Gateway design support configuration-driven API

Gateway development, CDD

Anh em nghe nhiều về khái niệm TDD (Test Driven Development) hay BDD (Behavior Drive Development) và giờ có thêm khái niệm CDD

Hiểu nhanh thế này

API Gateway như Kong, APIgee có sẵn built-in feature như rate limiting, authentication, routing rules. Thay vì implement code logic như go, java, C#, những thông tin này được chuyển thành external configuration files, bạn nào hay config nginx thì quen với config file này

Ví dụ như routing

{
  "routes": [
    { "path": "/api/v1/users", "target": "http://user-service.local" },
    { "path": "/api/v1/orders", "target": "http://order-service.local" }
  ]
}

Hay authentication

  auth:
  jwt:
    enabled: true
    secret: "your-secret-key"
    issuer: "your-app"

Những config này được gọi là Configuration Schema viết dưới dạng YAML, JSON hoặc XML lưu trong external storage hoặc database.

Hệ thống APIM trên Azure team tôi đang phát triển cũng phát triển bằng phương pháp CDD này

Việc sử dụng những API Gateway framework có sẵn gặp khó khăn trong việc tích hợp vào giải pháp Service Mesh của Tinder. Một số API việc configuration phức tạp, đòi hỏi phải tìm hiểu. Ngoài ra, Tinder muốn flexibiitly trong việc tự build plugin thay vì sử dụng những plugin có sẵn mà các framework API gateway cung cấp

Điều quan trọng là kĩ sư Tinder muốn control API Gateway ở Framework level development để có thể customize specific need cho Tinder, thay vì sử dụng 3rd party API Gateway có sẵn.

Vì thế kĩ sư Tinder quyết định tự build API Gateway gọi là Tinder Application Gateway (TAG). Truyền thống của Big Tech, như Netflix cũng tự build API gateway nhà làm tên là Zuul

Tinder Application Gateway

Bạn nào làm Java thì rất quen thuộc với Spring Framework, Spring Cloud còn cung cấp Framework Sprint Cloud Gateway để developer có thể tự phát triển API Gateway cho riêng mình

Sprint Cloud Gateway cung cấp một giải pháp mạnh mẽ để xử lý các yêu cầu HTTP, Routing, Security, giám sát, và các tính năng như rate limiting hoặc load balancing thuộc hệ sinh thái Spring.

Kĩ sư Tinder quyết định build TAG on-top của Spring Cloud Gateway, với Framework này thì Tinder có thể tự develop custom components theo ý mình

Schema Registry

Một feature của Spring Cloud Gateway rất được quan tâm đó là Schema Registry. Khái niệm này trên Google có đầy nhưng giải thích khá khó hiểu, giaosucan’s blog mô tả đơn giản thế này

Khi Hằng quẹt Tinder để tìm nửa kia, 2 Microservice Matching và Recommendation exchange data thông qua message structure. Như vậy message structure của 2 service phải theo format quy chuẩn thì 2 service mới hiểu và extract thông tin chính xác, tức là phải follow theo một schema như JSON schema, Avro or Protobuf. Vì dụ ông Matching đẩy data cho Recommendation dạng thơ tứ tuyệt thì bóp zái. Schema này được lưu trong Schema Registry và API Gateway framework sẽ validate API request payload đến service theo schema này, không đúng thì denied request

Hình dưới mô tả cơ chế validate payload giữa 2 service Producer và Consumer (A, B) communicate qua Kafka

Ông Consumer A chỉ hiểu data được định dạng theo Schema-v1 còn anh B thì hiểu theo schema-v2

Nên anh Producer gửi data ko đúng định dạng thì denied luôn

Một vài tính năng khác cần implement trong Gateway như Bot Detecting and Real Time Traffic Detection cái này dễ hiểu, đại loại là chức năng chống Bot. Mấy trang web dùng dịch CloudFlare cũng có tính năng chống bot tương tự

Dynamic Routing

Anh em ngồi code API thì nghe khái niệm routing rồi, <URI Path/Pattern> , API requests như https://matching:8081/v1/matching/** Mấy cài endpoint define tĩnh, fix cứng host:port là địa chỉ của service, mỗi lần thay đổi routing là phải build code, deploy lại API

Nhưng Tinder muốn Dynamic Routing, config routing behavior at runtime, không phải deploy lại và restart API gateway.

Chức năng này cho phép generate endpoint dynamic dựa vào thông tin request header

Ví dụ đây là chức năng Dynamic Routing của Krakend

Tự động generate API URL theo pattern đã define sẵn

{

“endpoint”: “/foo”,

“backend”:[

{

“host”: [“http://{input_headers.X-Tenant}.example.com”],

“url_pattern”: “/{input_headers.X-Route}”,

“disable_host_sanitize”: true

}

]

}

Vậy Kiến trúc TAG của Tinder như thế nào? làm sao nó giúp Hằng tìm được nửa kia, đón đọc phần sau