Kiến trúc FAANG 9 - AirBnB Microservice

Tiếp tục bài trước

AirBNB là một OTA platform rất nổi tiếng, là nơi kết nối giữa host và người thuê nhà. Hiện tại AiBnB có khoảng 150T users với hơn 1 tỉ booking. Trung bình cứ 1 giây sẽ có 6 bookings. Nếu so sánh với nền tảng như Facebook, Google thì AirBnB không so sánh được. Tuy nhiên 150T user cũng không phải nhỏ, đòi hỏi kĩ sư của AirBNB phải nghiên cứu để build được 1 hệ thống scability and avaiablity

Ngày đầu khởi nghiệp, AirBnB là monolithic viết bằng Ruby on Rails, gọi là Monorails. Tuy nhiên khi lượng user ngày càng tăng thì Monolithics gặp nhiều vấn đề về dependency giữa các module, tight coupling

AirBnB bắt đầu break kiến trúc Mono này và chuyển hướng theo service-oriented architecture (SOA). Trên môi trường production AiRBnB có hàng trăm microservice làm công việc khác nhau như tìm kiếm, listing, tính toán giá phòng, booking … AirBnB đã chọn giải pháp deploy những service này lên k8s. Hiện tại microservice này được deploy trên 36+ cluster K8s và 7K+ nodes.

Anh em nào làm K8s nhiều thì có thể đã quen thuộc deploy service dùng Helm hoặc kcustomize, đại loại là tạo ra những k8s manifest yaml và các file parameters (value file) sau đó Helm sẽ pass những value này vào k8s manifest file để execute deploy

Tuy nhiên AirBnB phát triển một internal-tool riêng dể deploy, gọi là kube-gen

Kube-gen có thể hiểu đơn giản thế này, ví dụ bạn muốn deploy service Booking lên k8s, theo cách truyền thống, bạn sẽ viết k8s yaml file hoặc helm, mô tả chi tiết nào là Deployment, service, ELB, network policy ,abc, xyz, mất khá nhiều time. Đối với Kube-gen bạn chỉ nhập thông tin về service trong file service config như tên, domain,… Kube-gen sẽ tự generate ra k8s config file và sau đó deploy lên k8s. Cách thức hoạt động gần giống như helm chart nhưng được customize dùng cho AirBnB only

Cũng tương tự như viết code, một số component common như logging monitoring được module hóa gọi là share infrastructure components được deploy kèm với pod theo dạng side-car

Service Mesh

Để buiild kiến trúc SOA, thì AirBnB sử dụng pattern Service Mesh. Đây là một pattern phổ biến trong kiến trúc Microservice. Mấy cái này trên Google có nhiều, tuy nhiên cách giải thích quá hàn lâm, đọc hiểu được khó chế mợ

Vậy giải thích theo kiểu bình dân như giaosucan’s blog là như thế này

Giả sử 1 guest vào AirBnB tìm phòng, anh ta search danh sách phòng ở Hội An, như vậy request được gửi tơi Search services, rồi chọn phòng, book ngày, request đẩy tời Booking service, Booking cần phải có thông tin được lấy từ Search như phòng nào, ở đâu, giá tiền … Rồi Booking xong thì đến Payment service, Payment lại cần thông tin về Booking như ngày book, ở bảo lâu, ai book … Tức là các service nó có tương tác qua lại lẫn nhau, mà muốn tương tác được các service phải có thông tin về như như endpoint, (service address). Tưởng tượng trong hệ thống phân tán, các service này scale lên hàng nghìn. Ngoài ra, communication giữa các service phải đảm bảo về security. Một số hệ thống thường tập trung secure giữa client vào phần backend (dùng HTTPS SSL, firewall) nhưng giữa các service thì lại bỏ qua, nên có nguy cơ bị hack nếu hacker pass qua được tầng firewall

Ngoài ra, service không phải lúc nào cũng avaible, có lúc nó lại ngỏm, thì phải implement những service pattern để re-try như Saga, circuit breaker …để service có thể self-healing, tự khởi động lại khi có lỗi

Rổi service deploy lên phải logging monitoring tracking service các kiểu, tóm lại là developer bị sa đà vào mấy cái non-business thì quên đi phần business logic của service

Vậy Service Mesh ra đời để giải quyết vấn đề này. Service Mesh giúp tách hẳn những phần non-bussiness logic này ra khỏi service được deploy dưới dạng side-car

Thay vì anh srv A phải call trực tiếp anh B thì chuyển sang cho Sidecar nó làm những việc này, các phần bảo mật, retry logic cũng do anh side car đảm nhiệm hết. Mô hình k8s thực chất hoạt động cũng giống như 1 service mesh

Nổi tiếng nhất trong Service Mesh là platform Istio, tuy nhiên truyền thống của FAANG là xài hàng nhà, AirBnB tự build một service mesh riêng, gọi là SmartStack, kết hợp giữa Service Registration (Nerve) và Service Discovery (Synapse)

Hiểu nhanh là khi một service onboard thì phải thực đăng kí thông tin với Service Registration như endpoint, name…(như đăng kí thành viên của tổ chức vậy) . Đăng ký thông tin xong rồi, thì muốn tìm kiếm thì xài Service Discovery

Nerve là một Ruby process chạy giống như là một sidecar bên cạnh microservice, và nó ghi thông tin service instance vào Zookeeper cluster

Các hoạt động của Nerve là dự vào healthcheck, service nào cũng được implement một api healthcheck, Nerve sẽ healthcheck service này, nếu service nào ngỏm thì cho de-register luôn, để tránh request được forward tới dead- service

Tại airbnb service nào cũng có endpoint healthcheck https://www.airbnb.com/health kiểu như này

Snypage thì phức tạp hơn. Giải thích tại sao AirBNB lại tạo ra Snypage

Endpoint của microservice có thể truy cập dưới dạng DNS hoặc elastic IP hoặc ELB

DNS có issue là hiện tượng https://en.wikipedia.org/wiki/Round-robin_DNS, hiểu nhanh là DNS nó hay cache, tức là bạn gắn DNS với 1 IP nào đó, nhưng sau khi update IP mới trình duyệt nó vẫn route tới IP cũ do hiện tượng caching này, hệ thống mà microservice được deploy, destroy liên tục, IP thay đổi xoành xoạch mà gặp quả caching này thì khóc ra máu

Còn xài thằng elastic IP thì bị giới hạn về số lượng trên 1 số nền tảng cloud, hai là ai mà nhờ nổi mấy con số này

Snypage tạo ra để giải quyết việc này

Snypage thì làm ngược lại, nó sẽ đọc thông tin của service từ Zookeeper registry (app-server ip:1.1.1) rồi ghi vào HAProxy config file haproxy.cfg, HAProxy sẽ route request tới đúng service tương ứng, HAProxy hoạt động giống như load balancing

Trên đây là giải pháp microservice của AirBnB, tuy nhiên khi deploy lên k8s, với số lương cluster ngay càng tăng và hơn 7K+ nodes, thì AirBNB cần tìm giải pháp scaling

Đón đọc bài sau