Cách Chúng Tôi Cải Thiện Hiệu Suất Của Moove Thêm 59%

Khoảng cách là phụ thuộc chậm nhất của chúng tôi

Hầu hết những người mở Moove app đang dùng mạng di động ở Nigeria và Indonesia, cách các máy chủ phản hồi họ hàng nghìn km. Trong tháng này, chúng tôi đã thay đổi cách các yêu cầu của họ đến được với chúng tôi, và thời gian đến byte đầu tiên (TTFB), tức khoảng thời gian từ lúc điện thoại gửi yêu cầu đến lúc phần đầu tiên của phản hồi tới nơi, đã giảm 59%, từ 0.74 giây xuống 0.31 giây. Chúng tôi không phải di dời bất kỳ máy chủ nào để đạt được điều đó.

Bài viết này giải thích vì sao khoảng cách khiến chúng tôi tốn kém hơn dự tính, chúng tôi đã thay đổi những gì, phần hóa ra khó hơn chính thay đổi đó, và những điều chúng tôi sẽ nói với một đội ngũ khác sắp làm điều tương tự.

Vì sao một chuyến đi dài biến thành ba

Các kỹ sư gọi độ trễ giữa lúc gửi một thứ gì đó và lúc nó đến nơi là độ trễ (latency), còn thời gian để một thông điệp tới máy chủ và phản hồi quay trở lại là thời gian khứ hồi (RTT). Từ Lagos đến các máy chủ của chúng tôi, RTT nằm trong khoảng 200 đến 300 mili giây. Chỉ riêng con số này thì vẫn chấp nhận được. Vấn đề là một yêu cầu hiếm khi đi một mình.

Trước khi một chiếc điện thoại có thể yêu cầu bất cứ thứ gì qua kết nối bảo mật, nó phải hoàn tất hai lần bắt tay (handshake), tức những trao đổi ngắn dùng để thiết lập một kết nối. Bắt tay TCP (TCP handshake) mở kết nối, rồi bắt tay TLS (TLS handshake) thỏa thuận các khóa mã hóa giữ cho kết nối riêng tư. Mỗi lần tốn một vòng khứ hồi trọn vẹn. Chỉ sau đó yêu cầu thực sự mới được gửi đi, và đó là chuyến thứ ba. Với 250 mili giây mỗi chuyến, người dùng phải chờ khoảng ba phần tư giây trước khi máy chủ của chúng tôi làm bất cứ việc gì.

Trên mạng di động, chi phí này phải trả thường xuyên hơn bạn nghĩ rất nhiều. Điện thoại chuyển giữa các trạm phát sóng, bộ thu phát đi ngủ để tiết kiệm pin, và ứng dụng bị đẩy xuống chạy nền. Mỗi sự kiện đó đều có thể làm rớt kết nối, và yêu cầu kế tiếp phải bắt đầu từ một kết nối nguội (cold connection), tức kết nối chưa thực hiện lần bắt tay nào, rồi trả lại toàn bộ chi phí thiết lập. Một kết nối ấm (warm connection), đã mở và đã được bảo mật sẵn, có thể đi thẳng vào yêu cầu.

Chúng tôi không thể đưa Lagos đến gần máy chủ hơn. Nhưng chúng tôi có thể đưa phần thiết lập đến gần Lagos hơn.

Dời lần bắt tay, không dời máy chủ

Mạng phân phối nội dung (CDN) thường được mô tả như một bộ nhớ đệm: một tập hợp các địa điểm trên khắp thế giới lưu bản sao của các tệp để có thể phục vụ từ nơi gần người dùng. Chúng tôi dùng nó vì một lý do khác. Với API của chúng tôi, giao diện mà ứng dụng dùng để thực hiện mọi việc, bộ nhớ đệm bị tắt hoàn toàn. Mọi yêu cầu vẫn đi đến máy chủ gốc (origin) của chúng tôi, tên gọi trong CDN cho các máy chủ nằm phía sau nó.

Điều thay đổi là nơi kết nối bắt đầu. Giờ đây, điện thoại mở kết nối đến điểm biên (edge location) gần nhất, còn gọi là điểm hiện diện (PoP): một trong các địa điểm của CDN trên khắp thế giới, thường chỉ cách vài chục mili giây thay vì hàng trăm. Điểm biên thực hiện kết thúc TLS (TLS termination), nghĩa là kết nối bảo mật từ điện thoại chấm dứt tại đó. Sau đó nó tái sử dụng một nhóm kết nối ấm tới máy chủ gốc của chúng tôi, được duy trì bằng keep-alive, một thiết lập giữ kết nối mở giữa các yêu cầu thay vì đóng lại. Hai chuyến thiết lập tốn kém diễn ra trên đoạn đường ngắn, và chỉ riêng yêu cầu băng qua đại dương, trên một kết nối đã ấm sẵn.

Ba chuyến đi dài trở thành một chuyến đi dài và hai chuyến đi ngắn. Toàn bộ ý tưởng chỉ có vậy.

Chúng tôi cố ý giữ phần còn lại thật đơn giản:

• Các ứng dụng khách không nhận thấy gì. Ứng dụng và trang web giữ nguyên địa chỉ, nên không cần phát hành bản ứng dụng mới và không ai phải cập nhật bất cứ thứ gì.
• Hành vi khi lỗi được giữ nguyên. Các thời hạn chờ khớp với trước đây, nên bất cứ thứ gì từng thất bại trước kia vẫn thất bại theo cùng một cách. Chúng tôi không muốn có thêm loại lỗi mới nào.
• Điểm biên đóng các kết nối nhàn rỗi trước. Mỗi kết nối có một thời gian chờ nhàn rỗi (idle timeout), tức khoảng thời gian nó có thể nằm không trước khi bị đóng. Nếu máy chủ của chúng tôi đóng một kết nối im lặng trong khi điểm biên vẫn nghĩ nó đang mở, yêu cầu kế tiếp sẽ thất bại. Đặt thời gian chờ của điểm biên ngắn hơn bảo đảm điểm biên luôn là bên bỏ cuộc trước và mở một kết nối mới.
• Các giao thức mới hơn cho điện thoại. Điện thoại có thể kết nối qua HTTP/3, phiên bản mới nhất của giao thức yêu cầu trên web. Nó chạy trên QUIC, giao thức gộp cả hai lần bắt tay vào một vòng khứ hồi duy nhất và xử lý tốt hơn tình trạng mất gói tin vốn phổ biến trên mạng di động.
• Không bỏ sót khu vực nào. Các gói rẻ hơn của mạng biên thường bỏ qua những địa điểm ở đúng các nơi trên thế giới mà người dùng của chúng tôi sinh sống, nên chúng tôi chọn phạm vi phủ sóng đầy đủ.

Những gì chúng tôi đo được

Chúng tôi đo từ Sydney, nơi có khoảng cách đến máy chủ của chúng tôi xấp xỉ Lagos, so sánh đường đi cũ với đường đi mới. Với mỗi đường, chúng tôi mở năm kết nối nguội mới, trường hợp quan trọng nhất trên mạng di động, và lấy trung vị, còn viết là p50: kết quả ở giữa, mà một nửa số yêu cầu nhanh hơn và một nửa không. Cùng dự án này cũng bật tính năng nén cho các tập lệnh của trang web, vốn trước đó được gửi ở kích thước đầy đủ. Nén thu nhỏ một tệp trước khi gửi và trình duyệt giải nén lại khi nhận; chúng tôi dùng Brotli, một định dạng nén được thiết kế cho web.

Thời gian đến byte đầu tiên là nơi con số 59% xuất phát. Một kết nối từng mất nửa giây để thiết lập nay sẵn sàng trong chưa đến một phần mười giây, và lần truy cập đầu tiên vào trang web của chúng tôi giờ tải ít hơn hai phần ba dung lượng, trên những kết nối mà nhiều người phải trả tiền cho từng megabyte.

Những con số này đến từ một thành phố, không phải một phép đo chuẩn toàn cầu. Tuy nhiên, phép tính vẫn áp dụng cho Lagos và Jakarta, và đó là nơi người dùng của chúng tôi sinh sống.

Phần khó là biết ai đang gọi

Đặt một lớp phía trước máy chủ của bạn thì dễ. Giữ cho các biện pháp bảo vệ vẫn hoạt động phía sau nó mới là nơi phần lớn công sức được bỏ ra.

Giống hầu hết các nền tảng thanh toán, Moove dùng giới hạn tốc độ (rate limiting), một mức trần về số yêu cầu mà mỗi bên gọi có thể thực hiện trong một khoảng thời gian nhất định, và các giới hạn này được gắn theo địa chỉ IP của bên gọi, con số xác định một thiết bị trên internet. Phía sau một mạng biên, mọi yêu cầu đều đến từ địa chỉ của một điểm biên thay vì địa chỉ của người dùng. Nếu không có gì khác thay đổi, mọi người ở Lagos sẽ dùng chung một hạn mức, và một buổi chiều đông đúc đã bắt đầu từ chối những người không làm gì sai.

Cách khắc phục dựa trên hai ý tưởng.

Chỉ tin đúng những lớp bạn có. CDN là một dạng proxy ngược (reverse proxy), một máy chủ đứng trước máy chủ của bạn và chuyển tiếp các yêu cầu. Mỗi proxy thêm địa chỉ mà nó nhận yêu cầu từ đó vào một tiêu đề chuẩn có tên X-Forwarded-For, nên bên gọi thật nằm cách một số bước cố định, hay bước nhảy (hop), tính ngược trong danh sách đó. Đếm sai con số này là một lỗi theo cả hai chiều. Đếm thiếu lớp thì mọi người dùng đều trông như điểm biên của họ. Đếm thừa lớp thì bạn bắt đầu tin một mục do chính bên gọi tự viết ra. Vì vậy chúng tôi biến con số này thành thuộc tính của hạ tầng thay vì của mã nguồn. Nó thay đổi đúng lúc mạng thay đổi, và dịch vụ của chúng tôi từ chối khởi động nếu giá trị vô nghĩa, thay vì đoán mò.

Để điểm biên bảo chứng cho bên gọi, và chỉ tin điểm biên. Điểm biên giờ ghi địa chỉ thật của bên gọi lên mọi yêu cầu và ghi đè lên bất cứ thứ gì bên gọi đã gửi ở vị trí đó. Các biện pháp bảo vệ của chúng tôi chỉ tin giá trị này khi có thể xác minh yêu cầu thực sự đi qua điểm biên của chúng tôi. Mọi giới hạn từng gắn theo địa chỉ mạng nay gắn theo bên gọi thật đối với lưu lượng từ điểm biên. Chúng tôi thêm các quy tắc này bên cạnh các quy tắc cũ thay vì sửa chúng, nên mỗi thay đổi trong quá trình triển khai là một bổ sung thuần túy mà bất kỳ ai cũng có thể xem xét chỉ trong một lần đọc.

Một lỗi chúng tôi bắt được trước khi phát hành

Moove Profiles có thể nằm trên tên miền riêng của người bán. Các yêu cầu đến những tên miền đó được chuyển qua trang web của chúng tôi cùng với tên miền của người bán, để trang web biết nên hiển thị hồ sơ nào.

Điểm biên mới đặt trước trang web loại bỏ loại thông tin này khỏi các yêu cầu đến, điều hoàn toàn đúng, vì khách truy cập không bao giờ được phép đặt nó. Nhưng điều đó cũng có nghĩa là khi trang web chuyển ra phía sau điểm biên, mọi tên miền của người bán sẽ lặng lẽ hiển thị trang chủ Moove thay vì hồ sơ của người bán.

Chúng tôi bắt được lỗi này trong lúc xem xét mã, chuyển đường dẫn tên miền người bán sang một tuyến riêng trước, và khiến hạ tầng của chúng tôi từ chối áp dụng thay đổi cho trang web ở bất cứ nơi nào việc chuyển đó chưa diễn ra. Một sai sót từng chỉ nằm trong đầu người xem xét nay là thứ mà quá trình xây dựng sẽ chặn lại.

Bài học chung: khi bạn thêm một lớp làm sạch dữ liệu đầu vào, hãy tìm mọi thứ phụ thuộc vào những dữ liệu đầu vào mà bạn sắp làm sạch.

Chúng tôi đã triển khai như thế nào

Hạ tầng thanh toán không thể "triển khai rồi xem sao", nên chúng tôi thay đổi môi trường staging trước và môi trường production sau, và một vài lựa chọn giúp việc chuyển đổi diễn ra êm ả. Chúng tôi hạ TTL (thời gian sống) trên các bản ghi DNS của mình, danh bạ của internet biến một tên như moove.xyz thành địa chỉ máy chủ. TTL là khoảng thời gian phần còn lại của internet được phép lưu đệm câu trả lời đó, và chúng tôi giảm nó từ một giờ xuống năm phút, trọn một giờ trước khi có bất cứ thứ gì được chuyển, để câu trả lời cũ đã hết hạn ở khắp nơi và việc quay lui có hiệu lực trong vài phút. Chúng tôi giữ các bản ghi địa chỉ ở dạng có thể chuyển đổi tại chỗ, vì xóa rồi tạo lại sẽ để lại một khoảng trống, và khoảng trống là sự cố gián đoạn. Mỗi bước rủi ro là một thay đổi nhỏ riêng, với các bước hoàn tác được ghi lại theo đúng thứ tự.

Chúng tôi sẽ nói gì với một đội ngũ khác

Nếu người dùng của bạn ở xa máy chủ, một mạng biên vẫn đáng có ngay cả khi nó không lưu đệm gì. Trước khi chuyển đổi:

• Liệt kê mọi thứ đọc địa chỉ của bên gọi, bao gồm giới hạn tốc độ, danh sách cho phép, tín hiệu gian lận, nhật ký kiểm toán và các quy tắc bảo mật. Mỗi thứ đó sẽ thấy địa chỉ của điểm biên trừ khi bạn thay đổi.
• Biến số lớp được tin cậy thành một phần của hạ tầng, và từ chối khởi động khi nó sai.
• Để điểm biên ghi lại bên gọi thật, và chỉ tin bản ghi đó trên lưu lượng mà bạn xác minh được là đến từ điểm biên của mình.
• Bảo đảm máy chủ của bạn chỉ nhận lưu lượng thông qua điểm biên, và theo dõi trước khi bạn áp dụng cưỡng chế.
• Nếu bạn lưu đệm các trang, hãy xây dựng khóa bộ nhớ đệm (cache key), tập hợp các chi tiết của yêu cầu mà bộ nhớ đệm dùng để quyết định hai yêu cầu có thể dùng chung một phản hồi đã lưu hay không, từ mọi thứ mà phản hồi thực sự thay đổi theo. Các máy chủ liệt kê những chi tiết đó trong tiêu đề Vary, nên hãy đọc nó thay vì dựa vào trí nhớ.
• Đo trước và sau, và xem riêng thời gian bắt tay và thời gian đến byte đầu tiên, để bạn phân biệt được phần thiết lập kết nối với thời gian máy chủ của bạn xử lý.

Nhìn về phía trước

Hầu hết các trang của chúng tôi được cá nhân hóa, nên bộ nhớ đệm tại điểm biên của trang web hiện phần lớn nằm không. Cải thiện về kết nối áp dụng cho mọi trang bất kể điều đó, và từng trang riêng lẻ giờ có thể chọn dùng bộ nhớ đệm khi an toàn để chia sẻ. Việc lưu đệm các phản hồi API sẽ cần một thiết kế và đợt xem xét riêng, và đó là điều tiếp theo chúng tôi muốn xem xét.

Tiền nên di chuyển với tốc độ của mạng, không phải tốc độ ánh sáng băng qua một đại dương.

Nếu bạn xây dựng trên nền tảng Moove, hãy đọc phần giới thiệu về các API và SDK thanh toán Web3 của chúng tôi và Moove Developer Program.

Được viết bởi đội ngũ kỹ sư moove.xyz.

Về moove.xyz

moove.xyz là nền tảng fintech Web3 toàn cầu được xây dựng cho sự di chuyển giá trị không cần phép và dễ dàng. Chúng tôi trao quyền cho các doanh nghiệp và người tiêu dùng ở bất kỳ đâu để gửi, nhận, staking và hoán đổi bất kỳ tiền điện tử nào trên bất kỳ blockchain nào — tất cả trong một nền tảng duy nhất.

Chúng tôi là một trong những công ty fintech Web3 đầu tiên trên toàn cầu đổi mới và xây dựng cơ sở hạ tầng thanh toán tiền điện tử và tài chính phi tập trung đầy đủ, cho phép phạm vi bao phủ tích hợp và toàn diện trên truy cập ví đa chuỗi, tên ví cá nhân hóa, hoán đổi token xuyên chuỗi, giao dịch xuyên chuỗi nhúng và mạng tài chính xã hội phi tập trung. Các sản phẩm chính của chúng tôi bao gồm Moove Profile, Moove Send, Moove Receive, Moove Stake, Moove Swap, Moove Rewards, Moove Discover và nhiều hơn nữa.

Sứ mệnh của chúng tôi rất đơn giản — tạo ra và phân phối công nghệ tài chính không cần phép và dễ dàng cho 1 tỷ người dùng Web3 tiếp theo. Chúng tôi tin tưởng cơ bản rằng tương lai của sự di chuyển tiền và giá trị sẽ không có chi phí, không có biên giới, không cần phép, không tốn công sức và được xây dựng cho tất cả mọi người — và chúng tôi đang xây dựng nền tảng fintech Web3 tối thượng để biến tương lai đó thành hiện thực.

Tiền của bạn. Bước đi của bạn.