Thiết kế tính năng Feature Toggle và Feature Rollout

Feature Toggle (hay Feature Flags) và Feature Rollout là một kĩ thuật phổ biến giúp bạn có thể quản lý được hành vi của phần mềm của mình mà không cần phải đổi code & deploy lại.

Trong bài viết này mình sẽ đi qua 1 vài tính năng từ cơ bản đến nâng cao, đồng thời chia sẽ cách tiếp cận để design và implement một hệ thống Feature Toggle/Feature Rollout nhỏ.

Một vài ứng dụng trong thực tế của chuyện này như:

  • Feature Control: Tắt/bật tính năng cho toàn bộ hệ thống, hoặc một vài khách hàng cụ thể
  • Feature rollout một tính năng từ từ cho tập user của mình, có thể trước mắt cho 1 vài user cụ thể, rồi sau đó user trong một nước/region nào đó.

Bật/tắt toàn cục

Trường hợp cơ bản nhất của Feature Toggle là giúp bạn turn on/off 1 feature mà không cần deploy lại code. Ví dụ lấy tính năng XYZ:

if FeatureToggle.check('xyz')
  # feature xyz is turned on, do what you need here
end
# code minh hoạ bằng Ruby
class FeatureToggle
  def self.check (feature_key) 
    feature = FeatureToggle.get(feature_key)
    return feature&.toggled == true
  end
end

Lúc này, bạn có thể code & deploy tính năng xyz đó trước, sau đó chọn thời điểm thích hợp để bật nó lên cho toàn bộ hệ thống. Hoặc ngược lại, khi bạn phát hiện ra lỗi, hoặc hệ thống quá tải, bạn có thể tắt bớt 1 vài tính năng phụ chỉ với 1 vài click chuột.

Thiết kế đằng sau đơn giản là một database table chứa các tính năng của bạn, cùng với 1 flag on/off:

CREATE TABLE feature_toggles (
  feature_key VARCHAR(255) PRIMARY KEY,
  toggled BOOLEAN DEFAULT FALSE
);

Bật/tắt cho khách hàng cụ thể

Ok great, bây giờ mình thảo luận trường hợp phức tạp hơn, khi mà bạn:

  1. chỉ muốn bật feature cho 1 vài khách hàng thử nghiệm (hoặc là khách hàng cao cấp)
  2. enable cho toàn bộ hệ thống, nhưng disable cho 1 vài khách hàng đặc biệt (khách hàng chưa chịu trả tiền chẳng hạn:P )
if FeatureToggle.check('xyz', current_customer_id)
  # feature xyz is turned on for this customer
end

Có thể nhận ra rằng 2 trường hợp trên giống như 2 mệnh đề đảo ngược nhau, lúc đó, bạn có thể cải thiện hệ thống bằng cách thêm vào 1 cột exception_list để chứa tập khách hàng đặt biệt này:

CREATE TABLE feature_toggles (
  feature_key VARCHAR(255) PRIMARY KEY,
  toggled BOOLEAN DEFAULT FALSE,
  exception_list JSONB DEFAULT '[]'
);

Lúc này thì:

  • toggled = false, exception_list = [1, 2]: tắt toàn bộ, vào bật cho khách hàng ID 1 và 2.
  • toggled = true, exception_list = [1, 2]: enable cho toàn bộ khách hàng, chỉ tắt cho khách hàng ID 1 và 2.

alt text

Trong ảnh: UI features toggles của Holistics (dựa trên nền ActiveAdmin).

Toggle cho % tập người dùng (hay là Feature Rollout)

Giả sử bây giờ, bạn vừa deploy 1 feature mới và muốn release thử nghiệm cho 5% tập users của mình thôi, thì mình phải thiết kế như thế nào?

Một cách đơn giản là thêm vào 1 cột rollout_percent, và dùng nó để check:

CREATE TABLE feature_toggles (
  feature_key VARCHAR(255) PRIMARY KEY,
  exception_list JSONB DEFAULT '[]',
  rollout_percent SMALLINT CHECK (rollout_percent >= 0 AND rollout_percent <= 100)
);

Lúc đó, với mỗi user_id, ta sẽ apply 1 hàm hash để đẩy user vào 1 tập từ 1-100, và check với giá trị rollout_percent của mình...

# trong ví dụ này ta dùng hàm hash CRC32 và mod 100
require 'zlib'
def check(feature_key, customer_id)
  ...
  hash_number = Zlib::crc32(customer_id) % 100 + 1
  return hash_number <= rollout_percent
end

Nâng cao: conditional feature rollout

Như trường hợp bạn muốn rollout % cho 1 tập người dùng thoả mãn điều kiện cụ thể, thì design sẽ không giải quyết được trường hợp này, ví dụ như:

  • 0% người dùng ở Mỹ, 10% người dùng ở UK, còn lại thì tắt hết
  • 20% người dùng Android, còn lại thì tắt hết
  • Chỉ rollout % cho người dùng trả phí, còn người dùng free thì không có
  • ...và nhiều trường hợp khác tuỳ yêu cầu của hệ thống

Phần này mình xin phép mở ra cho các bạn độc giải cho ý kiến xem có những cách design như thế nào là hợp lý. Các bạn có thể comment bên dưới về ý kiến của bạn nhé.

Lúc nào thì làm gì?

Nếu để ý kĩ các ví dụ trên, thì không phải lúc nào bạn cũng cần hết những tính năng nói trên:

  • Trường hợp bật/tắt cho khách hàng cụ thể sẽ phù hợp với các ứng dụng B2B (ví dụ: Intercom, Hubspot), khi mà người xài thuộc các company account khác nhau.
  • Trường hợp rollout theo % của user sẽ phù hợp hơn với các ứng dụng B2C (ví dụ Quora, Facebook, Kipalog) khi mỗi người xài là 1 user độc lập.

Nói vậy để thấy là tuy cũng chỉ là cơ chế feature toggle, feature rollout, nhưng mỗi doanh nghiệp khi thiết kế sẽ có nhiều bài toán con khác nhau, ảnh hưởng đến cách bạn thiết kế tính năng này.

Cải thiện tốc độ (Performance Improvement)

Ở trên ta dùng database để lưu các toggles, như vậy mỗi lần call hệ thống phải query vào database. Với những hệ thống có nhiều traffic, chuyện này sẽ làm chậm hệ thống lại rất nhiều và trở nên không thực tế.

Nhận thấy việc dữ liệu toggles ở trên không thường xuyên thay đổi nhiều (chỉ đổi khi admin vào sửa nội dung), nên ta có thể dùng caching (như Redis, hoặc lưu thẳng vào memory) để tránh việc phải có nhiều database calls. Và ta chỉ cần refresh cache khi mà ai đó vào admin để update lại toggle settings.

Một cách triển khai khác là ta hoàn toàn có thể implement trực tiếp bằng Redis mà không cần phải thông qua SQL database. Lúc này ta phải coi như dữ liệu trong Redis của bạn là persistent data và có cơ chế backup thích hợp.

Kết luận

Ở trên mình đã giới thiệu các bạn hướng tiếp cận và giải quyết bài toán Feature Toggle / Feature Rollout. Tuy nhìn đơn giản nhưng khi đi sâu vào nó có những yêu cầu đặc thù khác nhau, cho nên mỗi công ty sẽ có cách tiếp cận/thực thi khác nhau.

Kì tới mình sẽ chia sẻ thêm cách mở rộng hệ thống Feature Rollout ở trên để làm A/B Testing. Til next time, merry christmas :)!


5p quảng cáo: nếu bạn là engineer & hứng thú với những bài toán như trên, team mình (Holistics), một Startup chuyên phát triển Analytics Platform cho các tech companies như Grab, Traveloka, AhaMove,... đang cần tìm kiếm Junior Fullstack Engineer làm việc ở HCM chung với team.

Team nhỏ & trẻ (7 engineers), môi trường hòa đồng & bựa, code đến đâu test & refactor đến đó, đã deploy thì integration tests phải pass hết mới deploy còn deadline thì tính sau....Tìm hiểu thêm a

Bình luận


White
{{ comment.user.name }}
Bỏ hay Hay
{{comment.like_count}}
Male avatar
{{ comment_error }}
Hủy
   

Hiển thị thử

Chỉnh sửa

White

Huy Nguyen

2 bài viết.
37 người follow
Kipalog
{{userFollowed ? 'Following' : 'Follow'}}
Cùng một tác giả
White
31 6
(Ảnh) Khi thiết kế các ứng dụng web, đặc biệt là đối với các ứng dụng cần xử lý các tác vụ có thời gian thực thi dài như: resize ảnh, phân tích wo...
Huy Nguyen viết 5 ngày trước
31 6
Bài viết liên quan
White
14 1
Con đường phát triển sự nghiệp (Career path) cho developer Các bạn sinh viên còn đang học hoặc mới ra trường sẽ khó hình dung được về những vị trí...
Huy Hoàng Phạm viết hơn 2 năm trước
14 1
{{like_count}}

kipalog

{{ comment_count }}

bình luận

{{liked ? "Đã kipalog" : "Kipalog"}}


White
{{userFollowed ? 'Following' : 'Follow'}}
2 bài viết.
37 người follow

 Đầu mục bài viết

Vẫn còn nữa! x

Kipalog vẫn còn rất nhiều bài viết hay và chủ đề thú vị chờ bạn khám phá!