-- Anh Tèo này, dạo này em hay làm với Fredrik, thấy hắn code sáng ghê.

-- Code như nào mà sáng?

-- README viết rất kĩ, code có design pattern rõ ràng, comment đầy đủ. Ngoài ra còn đúng chuẩn nữa.

-- Chuẩn? Chuẩn gì?

-- Ví dụ gần nhất là chuẩn RFC7396: JSON Merge Patch

Tóm tắt kiến thức

• RFC 7396 là một tiêu chuẩn của IETF (Internet Engineering Task Force) đặc biệt liên quan đến việc thay đổi các tài nguyên JSON bằng cách sử dụng các tài liệu JSON nhỏ được gọi là JSON Patch
• RFC = "Request for Comments", có nghĩa là "Yêu cầu ý kiến" hoặc "Đề nghị ý kiến." Cụ thể, trong ngữ cảnh của IETF (Internet Engineering Task Force), RFC là một loạt các tài liệu mà những người tham gia đưa ra để mô tả, đề xuất hoặc đánh giá các tiêu chuẩn, giao thức, quy trình và các vấn đề liên quan đến phát triển và quản lý Internet
• Bạn hiểu đơn giản là quy ước để update JSON
  • Mục tiêu sinh ra quy ước để có 1 cái chuẩn, cả thế giới làm theo, tránh mỗi ông mỗi kiểu.
• RFC 7396 quy ước muốn cập nhật field nào thì gửi field đó lên thôi, tránh gửi toàn bộ lên, tốn băng thông.
• Về cơ bản thì có các nguyên tắc sau:
  • Chỉ gửi field nào cần update lên
  • Nếu field nào chưa có trong object gốc ~> thêm vào
  • Nếu field nào có trong object gốc rồi ~> thay thế
  • Nếu field nào mà value là null ~> xóa field đi
  • Method là PATCH, Content-Type là application/merge-patch+json
• Danh sách đầy đủ các test cases:

ORIGINAL        PATCH            RESULT
   ------------------------------------------
   {"a":"b"}       {"a":"c"}       {"a":"c"}

   {"a":"b"}       {"b":"c"}       {"a":"b",
                                    "b":"c"}

   {"a":"b"}       {"a":null}      {}

   {"a":"b",       {"a":null}      {"b":"c"}
    "b":"c"}

   {"a":["b"]}     {"a":"c"}       {"a":"c"}

   {"a":"c"}       {"a":["b"]}     {"a":["b"]}

   {"a": {         {"a": {         {"a": {
     "b": "c"}       "b": "d",       "b": "d"
   }                 "c": null}      }
                   }               }

   {"a": [         {"a": [1]}      {"a": [1]}
     {"b":"c"}
    ]
   }

   ["a","b"]       ["c","d"]       ["c","d"]

   {"a":"b"}       ["c"]           ["c"]

   {"a":"foo"}     null            null

   {"a":"foo"}     "bar"           "bar"

   {"e":null}      {"a":1}         {"e":null,
                                    "a":1}

   [1,2]           {"a":"b",       {"a":"b"}
                    "c":null}

   {}              {"a":            {"a":
                    {"bb":           {"bb":
                     {"ccc":          {}}}
                      null}}}

Chém

-- Anh cũng chưa nghe tới cái chuẩn này bao giờ. Nghe nguy hiểm nhỉ. Mày tóm tắt trong mười lăm chữ đi xem có gì hot nào?

-- Về cơ bản, nó là chuẩn để anh update JSON.

-- Update JSON? Bình thường anh thấy đội dev gửi cả cục lên, replace là xong mà?

-- Đúng là vậy. Tuy nhiên việc gửi toàn bộ JSON lên sẽ làm tốn băng thông. JSON bé không sao, JSON to tốn cả Kb chứ chẳng chơi. Một ngày vài triệu tới vài trăm triệu request, anh có biết nó nhiều thế nào không?

-- Ừ nhỉ. Nghe mày nói, anh thấy nó cũng... to to. Thế nói rõ hơn về chuẩn đi.

-- Chuẩn JSON Merge Patch, hay còn gọi là RFC 7396, quy ước một số nguyên tắc sau khi update JSON value

• Chỉ gửi field nào cần update lên
• Nếu field nào chưa có trong object gốc ~> thêm vào
• Nếu field nào có trong object gốc rồi ~> thay thế
• Nếu field nào mà value là null ~> xóa field đi
• Method là PATCH

-- Nghe hơi lí thuyết. Anh nghĩ nên có vài ví dụ?

-- Ví dụ thế này: giả sử ban đầu, file JSON của em trông như sau:

{
     "title": "From Hang xinh gai with love",
     "author" : {
       "givenName" : "Hang",
       "familyName" : "Xinh Gai"
     },
     "tags":[ "girl_pho", "girl_thu_do" ],
     "content": "A girl, who love Go programming"
   }

Giả sử em muốn xóa familyName đi, thay content thành: "Hang xinh gai sieu cap vjp pr0" thì em sẽ gửi patch request với nội dung như sau:

PATCH /my/resource HTTP/1.1
   Host: example.org
   Content-Type: application/merge-patch+json
 
   {
     "author": {
       "familyName": null
     },
     "content": "Hang xinh gai sieu cap vjp pr0"
   }

Và kết quả nhận được cuối cùng là:

{
     "title": "From Hang xinh gai with love",
     "author" : {
       "givenName" : "Hang"
     },
     "tags":[ "girl_pho", "girl_thu_do" ],
     "content": "Hang xinh gai sieu cap vjp pr0"
   }

-- Nghe cũng đơn giản vl nhỉ?

-- Đơn giản mà. Thế ví dụ em muốn thay đổi tags thành "girl_ngoan_hien" và "1235_anh_co_danh_roi_nhip_nao_khong" thì làm thế nào?

-- Anh nghĩ chỉ cần gửi body lên với giá trị tag mới là xong?

PATCH /my/resource HTTP/1.1
   Host: example.org
   Content-Type: application/merge-patch+json
 
   {
     "tags":[ "girl_ngoan_hien", "1235_anh_co_danh_roi_nhip_nao_khong" ]
   }

-- That's right. Thế đố anh, ví dụ này thì sẽ nhận được gì? 

JSON gốc

{"a":"foo"}

Request body

PATCH /my/resource HTTP/1.1
   Host: example.org
   Content-Type: application/merge-patch+json

 null

-- ÁmụĐ, quả null khó thế

. Anh đoán là kết quả giữ nguyên {"a":"foo"}

-- Sai. Kết quả sẽ về null nhé.

-- Còn nhiều case đặc biệt không? Mày nói nốt cho anh biết nào?

-- Đầy đủ các case thì anh xem bảng sau

ORIGINAL        PATCH            RESULT
   ——————————————
   {"a":"b"}       {"a":"c"}       {"a":"c"}

   {"a":"b"}       {"b":"c"}       {"a":"b",
                                    "b":"c"}

   {"a":"b"}       {"a":null}      {}

   {"a":"b",       {"a":null}      {"b":"c"}
    "b":"c"}

   {"a":["b"]}     {"a":"c"}       {"a":"c"}

   {"a":"c"}       {"a":["b"]}     {"a":["b"]}

   {"a": {         {"a": {         {"a": {
     "b": "c"}       "b": "d",       "b": "d"
   }                 "c": null}      }
                   }               }

   {"a": [         {"a": [1]}      {"a": [1]}
     {"b":"c"}
    ]
   }

   ["a","b"]       ["c","d"]       ["c","d"]

   {"a":"b"}       ["c"]           ["c"]

   {"a":"foo"}     null            null

   {"a":"foo"}     "bar"           "bar"

   {"e":null}      {"a":1}         {"e":null,
                                    "a":1}

   [1,2]           {"a":"b",       {"a":"b"}
                    "c":null}

   {}              {"a":            {"a":
                    {"bb":           {"bb":
                     {"ccc":          {}}}
                      null}}}

-- Anh có thắc mắc gì nữa không? Em kết bài đây?

-- Hm... Anh đang nghĩ là mình có thể tự sáng tạo quy ước ra rồi code theo quy ước đấy là được nhỉ? Đỡ phải học nhiều chuẩn. Hơi...mệt.

-- Làm như anh mới là mệt. Anh đẻ ra một chuẩn mà không có nhiều người kiểm duyệt ~> rất dễ sai. Chưa kể anh tuyển người mới vào, họ lại phải đọc cái chuẩn của anh, làm learning curve tăng.

-- Ừ nhỉ. Thế đẹp nhất vẫn là lấy chuẩn quốc tế mà làm.

-- Chứ còn gì nữa..

Cảm ơn bạn, vì đã đọc bài.

Tranh thủ đầu xuân, trong lúc đọc code của một bạn đồng nghiệp thì mình nảy ra ý tưởng viết bài ~> vào việc luôn

Chúc bạn và gia đình một năm mới thật nhiều sức khỏe, đạt được các mục tiêu đặt ra trong 2024 nha ^^

Bài viết được lấy từ nguồn: Blog của mình

Kubernetes (k8s) là một hệ thống mã nguồn mở giúp quản lý và triển khai các containerized applications trên môi trường phân tán phổ biến nhất hiện nay. AWS hiện đang hỗ trợ người dùng quản lý hệ thống Kubernetes dưới dạng một dịch có tên là Elastic Kubernetes Service - EKS.

Bài viết này sẽ hướng dẫn cách xác thực với EKS thông qua Google Accounts, mang lại tính linh hoạt trong việc quản lý cụm EKS.

*Chú ý: Bài viết này tập trung vào việc hướng dẫn người dùng triển khai xác thực trên EKS thông qua Google Accounts và giả định rằng mọi người đều đã làm việc với EKS và Google Accounts rồi.

Đặt vấn đề

Đối với các doanh nghiệp hay cá nhân đang vận hành hệ thống trên các cụm EKS, việc quản lý cụm yêu cầu người dùng phải xác thực thông qua AWS, về cơ bản quản trị viên, người dùng hệ thống (cụm) EKS đều phải có tài khoản trên AWS khi muốn tương tác với cụm. Trong khi đó việc quản lý tài khoản nhân viên trong doanh nghiệp sẽ được quản lý thông qua các bên/dịch vụ khác như Google (thông qua Gsuite chẳng hạn). Nên nếu tích hợp được khâu xác thực của EKS với các công cụ quản lý tài khoản chung thì sẽ giúp ích rất nhiều cho doanh nghiệp.

Hướng giải quyết

Thật may, EKS (Kubernetes) có hỗ trợ một giao thức xác thực có tên là Open ID Connect (OIDC) và Google cũng đang hỗ trợ và triển khai giao thức này. Từ đây mở ra con đường để có thể triển khai việc quản lý cụm EKS thông qua Google Accounts.

OIDC là gì

Đầu tiên chúng ta cùng tìm hiểu sơ qua về OIDC, vậy OIDC là gì?

OIDC là viết tắt của "OpenID Connect" một giao thức xác thực được xây dựng trên OAuth 2.0. OIDC cung cấp một cách tiêu chuẩn để xác thực và quản lý danh tính người dùng trên internet. Giao thức này chủ yếu được sử dụng trong việc xác thực người dùng khi họ truy cập các ứng dụng web, ứng dụng di động và các dịch vụ trực tuyến khác.

Chuẩn bị môi trường

• Đã triển khai EKS cluster trên tài khoảng AWS
• Có account Google và có thể vào được trang quản lý (console)
• Đã cài đặt các công cụ eksctl, kubectl

Phía trên là những công cụ cần thiết để hỗ trợ việc triển khai xác thực với EKS thông qua Google Accounts, còn bây giờ chúng ta sẽ đi vào quá trình cấu hình cho từng thành phần.

Cấu hình cho Google

Để có thể tích hợp việc xác thực của Google vào cụm EKS, chúng ta cần phải tạo một Credentials cho OAuth trong Google, phía dưới là các bước cần thực hiện để tạo ứng dụng:

1. Vào console google https://console.cloud.google.com/
2. Tạo project thông qua New Project
   • Project Name: Tên của project
3. Vào tab Oauth Consent Screen
   • Điền thông tin về application và email của developer
   • Thêm scope vào consent screen
     • Scope cần có:
       • email
       • profile
       • openid
4. Vào tab Credentials
   • Chọn Create Credentials
   • Chọn Oauth Client ID
   • Chọn Web Application
     • Nhập tên ứng dụng
     • Thêm URI http://localhost:8000 tại Authorized redirect URIs
   • Chọn tạo ứng dụng
5. Lấy Oauth client bao gồm:
   1. Client ID
   2. Client secret

Cấu hình cho EKS

*Bài viết này sẽ không đi qua việc hướng dẫn tạo cụm EKS, tuy nhiên bạn có thể dễ dàng tạo cho mình một cluster EKS thông qua console hoặc eksctl.

Đối với EKS, chúng ta cần phải cấu hình liên kết OIDC identity providers (ở đây là Google) vào cụm EKS, để cho cụm EKS biết rằng có thể tin tưởng thực hiện các phương pháp trao đổi thông tin về danh tính người dùng trên cụm.

Thông qua AWS Management Console

1. Vào trang quản lý EKS tại https://console.aws.amazon.com/eks/home#/clusters
2. Chọn cluster của bạn
3. Chọn tab Configuration, và chọn tab Authentication
4. Trong trang OIDC Identity Providers, chọn Associate Identity Provider
5. Tại trang Associate OIDC Identity Provider, nhập và chọn theo các lựa chọn sau:
   • Name: nhập unique name của OIDC provider
   • Issue URL: nhập URL của provider, URL này cần phải vào được thông qua internet
   • Client ID: nhập OIDC identity provider's client ID (còn gọi là audience)
   • Username claim: nhập claim được dùng để làm username
   • Group claim: nhập claim được dùng để làm group
   • (Optional) Chọn Advanced options, nhập hoặc chọn các thông tin sau:
     • Username prefix: nhập một chuỗi, chuỗi này được sử dụng để thêm vào đầu username claims ở phía trên để tránh việc trùng lặp giữa các username đã tồn tại. Nếu không cung cấp value này và username không phải email thì mặc định prefix sẽ là Issuer URL. Bạn cũng có thể sử dụng giá trị - để tắt tính năng prefix này. Và không được chỉ định system: hay bất kỳ chuỗi nào được tạo từ nó để làm username prefix
     • Group prefix: Nhập một chuỗi, chuỗi này được sử dụng để thêm vào đầu group claims ở phía trên.
     • Required claims: chọn thêm những claims cần được lấy ra từ id token

Thông qua eksctl

1. Tạo file có tên là associate-identity-provider.yaml với nội dung sau. Replace các *example value* với giá trị của bạn

   ---
   apiVersion: eksctl.io/v1alpha5
   kind: ClusterConfig
   
   metadata:
     name: *my-cluster*
     region: *your-region-code*
   
   identityProviders:
     - name: *my-provider*
       type: oidc
       issuerUrl: *https://example.com*
       clientId: *kubernetes*
       usernameClaim: *email*
       usernamePrefix: oidc:
       groupsClaim: *my-claim*
       groupsPrefix: oidc:
       requiredClaims:
         string: *string*
       tags:
         env: *dev*
   

2. Tạo provider:

   eksctl associate identityprovider -f associate-identity-provider.yaml
   

Sau khi thực hiện các bước trên, EKS đã có thể liên kết với Google thông qua giao thức OIDC, việc của chúng ta còn lại là cần phải cấu hình để có giao diện đăng nhập với Google mà thôi.

Cài đặt kubelogin

kubelogin là một plugin của kubectl, plugin này hỗ trợ chúng ta trong khâu login với Google. Phía dưới là các câu lệnh để cài đặt kubelogin, hoặc bạn có thể xem thêm ở github.

# Homebrew (macOS and Linux)
brew install int128/kubelogin/kubelogin

# Krew (macOS, Linux, Windows and ARM)
kubectl krew install oidc-login

# Chocolatey (Windows)
choco install kubelogin

Authenticate với EKS

Sau các bước cài đặt ở trên, cuối cùng chúng ta có thể login được rồi!!!

Nếu cài đặt của chúng ta là chính xác, sau khi thực hiện câu lệnh sau thì sẽ có 1 browser tự động bật lên và dẫn đến trang đăng nhập của Google.

$ kubectl oidc-login setup \
  --oidc-issuer-url https://accounts.google.com \
  --oidc-client-id=858670347920-xxxxxxxxxxx.apps.googleusercontent.com \
  --oidc-client-secret=GOCSPX-xxxxxxxxxxx \
  --oidc-extra-scope=email \
  --oidc-extra-scope=profile

Sau khi login thành công, thông tin xác minh của bạn sẽ được hiển thị giống phía dưới:

{
  "iss": "https://accounts.google.com",
  "azp": "858670347920-xxxxxxxxxxx.apps.googleusercontent.com",
  "aud": "858670347920-xxxxxxxxxxx.apps.googleusercontent.com",
  "sub": "106150655626797293240",
  "hd": "beeketing.net",
  "email": "namnguyen1@beeketing.net",
  "email_verified": true,
  "at_hash": "KcKxEFodvK9Srkk7401q7Q",
  "nonce": "XLlgS7O8Fgekbj8mF6f8PS4gKyqExKpoygAnuR-w5Dc",
  "name": "Nam Nguyen The",
  "picture": "https://lh3.googleusercontent.com/a/ACg8ocJBZcSCxEI6BeijAG44YG3JcTZmBkvhD8H5tLL30vRK=s96-c",
  "given_name": "Nam",
  "family_name": "Nguyen The",
  "locale": "en",
  "iat": 1706784878,
  "exp": 1706788478
}

Tiếp theo là tạo config cho user OIDC trong kubeconfig thông qua câu lệnh sau:

kubectl config set-credentials oidc \
	  --exec-api-version=client.authentication.k8s.io/v1beta1 \
	  --exec-command=kubectl \
	  --exec-arg=oidc-login \
	  --exec-arg=get-token \
	  --exec-arg=--oidc-issuer-url=https://accounts.google.com \
	  --exec-arg=--oidc-client-id=858670347920-xxxxxxxxxxx.apps.googleusercontent.com \
	  --exec-arg=--oidc-client-secret=GOCSPX-xxxxxxxxxxx \
	  --exec-arg=--oidc-extra-scope=email \
	  --exec-arg=--oidc-extra-scope=profile

Thử thực hiện câu lệnh lấy danh sách nodes với user oidc này xem sao:

$ kubectl --user=oidc get nodes

Oh, có vẻ có lỗi xảy ra, câu lệnh sau khi thực hiện không lấy được danh sách nodes mà chỉ trả về lỗi:

Error from server (Forbidden): nodes is forbidden: User "namnguyen1@beeketing.net" cannot list resource "nodes" in API group "" at the cluster scope

Đừng lo lắng, chúng ta sẽ đi tìm hiểu về lỗi này ngay bây giờ đây.

Phân quyền trong EKS

Sau các bước trên chúng ta đã có thể xác thực với EKS thông qua Google, bằng chứng ở đây là EKS đã trả về lỗi với user định danh là email của chúng ta: namnguyen1@beeketing.net tiếp theo việc chúng ta cần làm là phải cấu hình thêm permission hay phân quyền cho user sau khi được xác thực bởi Google được thực hiện các hành động trên cụm EKS

$ kubectl create clusterrolebinding oidc-cluster-admin --clusterrole=cluster-admin --user='namnguyen1@beeketing.net'

Cùng thử lại command trên xem sao, và chúng ta đã lấy được thông tin các nodes trong cụm EKS thông qua token việc login bằng account Google

$ kubectl --user=oidc get nodes

NAME                                              STATUS                        ROLES    AGE     VERSION
ip-10-30-1-230.ap-southeast-1.compute.internal    Ready                         <none>   10m     v1.24.7-eks-fb459a0
ip-10-30-12-56.ap-southeast-1.compute.internal    Ready                         <none>   15m     v1.24.7-eks-fb459a0

Từ đây bạn cũng có thể chia sẻ cấu hình oidc này cho members khác, và họ cũng sẽ có thể authenticate với EKS thông qua account Google của họ.

Tổng kết

Việc tích hợp Google vào khâu xác thực EKS hay bất kỳ ứng dụng nào đem lại sự linh hoạt trong khâu quản lý, giúp tiết kiệm thời gian và công sức trong việc vận hành cụm, đặc biệt là với quy mô nhân sự lớn. Tuy nhiên trong thực tế việc tích hợp OIDC với trực tiếp Google là tương đối hiếm, bởi vì những claims

Tài liệu tham khảo

• https://github.com/int128/kubelogin
• https://docs.aws.amazon.com/eks/latest/userguide/authenticate-oidc-identity-provider.html

Trong thế kỷ 21, việc xử lý dữ liệu là một phần không thể thiếu của cuộc sống hàng ngày của chúng ta. Tuy nhiên, việc lưu trữ và truy xuất dữ liệu nhanh chóng có thể trở thành một nhiệm vụ phức tạp và đáng tốn kém. Do đó cần có những kỹ thuật tương ứng để đáp ứng được nhu cầu này, cũng là nguyên nhân sự ra đời của Bloom Filter.

Bloom Filter là gì?

Bloom Filter là một cấu trúc dữ liệu được phát triển bởi Burton H. Bloom vào năm 1970, khi ông là một nhà nghiên cứu tại Xerox Corporation's Palo Alto Research Center (PARC). Ông công bố ý tưởng về Bloom Filter trong bài báo "Space/Time Trade-offs in Hash Coding with Allowable Errors" vào năm 1970.

Một trong những điểm quan trọng của Bloom Filter là khả năng kiểm tra sự tồn tại của một phần tử trong một tập hợp lớn mà không cần lưu trữ tất cả các phần tử. Tuy nhiên, Bloom Filter có một số hạn chế quan trọng, bao gồm khả năng false positive (khi Bloom Filter báo rằng một phần tử tồn tại trong tập hợp mặc dù thực tế không có) và không thể loại bỏ phần tử đã thêm vào.

Bloom Filter hoạt động như thế nào?

Bloom Filter xuất phát từ nhu cầu tối ưu hóa việc tìm kiếm - khả năng kiểm tra sự tồn tại của một phần tử trong một tập hợp lớn mà không cần lưu trữ tất cả các phần tử. Ý tưởng về cách hoạt động của Bloom Filter có thể mô tả ngắn gọn như sau: Từ giá trị x thuộc tập X, ta tạo ra một giá trị y = h(x) thuộc tập Y, với h là một hash function. Sau đó ta có thể kiểm tra giá trị x' có thuộc X không bằng cách kiểm tra xem y' = h(x') có thuộc tập Y hay không.

Dưới đây ta sẽ giới thiệu chi tiết cách hoạt động:

Khởi tạo Bloom Filter

• Bloom Filter bao gồm một bit array với m bits ban đầu được thiết lập thành giá trị 0.
• Chọn k hash function, mỗi hash function hash một tập giá trị vào m vị trí trên bit array. Tạo nên phân phối xác suất ngẫu nhiên trên mảng.
• Hai tham số quan trọng cần xác định trước khi tạo Bloom Filter là m - kích thước bit array và k số lượng hash function là hai tham số quan trọng cần xác định trước khi tạo Bloom Filter. Hai tham số này tỉ lệ thuận với nhau và tỉ lệ thuận với số lượng phần tử trong tập.

Thêm phần tử vào Bloom Filter

• Khi một phần tử được thêm vào Bloom Filter, ta thực hiện k hash function độc lập thu được k giá trị.
• K giá trị sau khi hash sẽ nằm trong đoạn [0, m-1], tương ứng với các vị trí trên bit array.
• Với mỗi giá trị sau khi hash, ta set bit tại vị trí đó = 1

Kiểm tra sự tồn tại của phần tử

• Khi muốn kiểm tra sự tồn tại của một phần tử trong Bloom Filter, ta lặp lại các bước tương tự: thực hiện k hash function và thu được k giá trị tương ứng trong đoạn [0, m-1]
• Kiểm tra k vị trí bit này trong mảng bit. Nếu tất cả các bit ở k vị trí này đều bằng 1. Bloom Filter cho rằng phần tử có thể tồn tại trong tập hợp. (step 3.1)
• Kiểm tra k vị trí bit này trong mảng bit. Nếu ít nhất một vị trí bit là 0, Bloom Filter khẳng định phần tử không tồn tại trong tập hợp. (step 3.2)

False positive

Qua việc tìm hiểu cách hoạt động của Bloom Filter ta có thể thấy rằng. Bloom Filter có thể khẳng định chắc chắn một phần tử không tồn tại trong tập hợp (step 3.2), nhưng ở chiều ngược lại không thể khẳng định chắc chắn là phần tử này thuộc tập hợp (step 3.1). Đây cũng là nhược điểm của Bloom Filter.

• Bloom Filter có khả năng gây ra false positive. Điều này có nghĩa là Bloom Filter có thể báo nhầm rằng một phần tử tồn tại trong tập hợp mặc dù thực tế không có.
• Khả năng false positive tăng lên khi kích thước của bit array (m) nhỏ hoặc số lượng hash function (k) bé. Để giảm false positive, bạn có thể tăng kích thước mảng bit hoặc số lượng hàm băm, nhưng điều này đồng nghĩa với việc tăng sử dụng bộ nhớ và tăng độ phức tạp tính toán.

Immutable

Một trong những đặc tính và cũng là hạn chế của Bloom Filter là không thể thay đổi. Cụ thể ở đây là việc loại bỏ một phần tử ra khỏi tập hợp là không thể, qua cách hoạt động ta có thể thấy không có cách nào loại bỏ phần tử khỏi tập hợp mà vẫn đảm bảo tính chính xác của bit array. Điều này làm cho Bloom Filter thích hợp cho các ứng dụng mà tập hợp dữ liệu là cố định và không thay đổi thường xuyên.

Counting Bloom Filter

Do có những hạn chế như trên. Việc apply trực tiếp Bloom Filter vào các bài toán đặc thù gặp khó khăn, đó cũng là lý do ra đời cho các biến thể. Một trong số đó có thể kể đến là Counting Bloom Filter.

Cho một phần tử x và một tập X. Counting Bloom Filter cho phép truy vấn kiểm tra số lượt xuất hiện trong X của x: cho x và một thresh hold number k. Counting Bloom Filter trả về chắc chắn số tồn tại của x trong X bé hơn k, hoặc có thể lớn hơn hoặc bằng k.

Dễ thấy việc này có thể thực hiện đơn giản thông qua việc thay đổi cách thêm phần tử vào tập. Thay vì set bit = 1 như Bloom Filter, Counting Bloom Filter thêm 1 vào bit. Qua cơ chế trên, việc xoá phần tử ra khỏi tập ban đầu là hoàn toàn có thể. Tuy nhiên việc này cũng gây nên tăng false positive rate khi mà phần tử được xoá không tồn tại không tập ban đầu.

Ngoài ra còn một số biến thể khác của Bloom Filter cũng được sử dụng rộng rãi như:

1. Dynamic Bloom Filter: Cho phép thêm và xóa phần tử từ Bloom Filter, phù hợp cho các tình huống cần thay đổi tập dữ liệu thường xuyên.
2. Bloomier Filters: Cải tiến của Bloom Filter với khả năng trả lời câu hỏi kiểu "nếu không có dữ liệu này, thì có dữ liệu nào gần giống không?".

Ứng dụng của Bloom Filter trong các bài toán thực tế

Sau khi công bố, Bloom Filter đã tìm thấy nhiều ứng dụng trong thế giới thực và trở thành một công cụ hữu ích trong lĩnh vực xử lý dữ liệu và tối ưu hóa hiệu suất. Nó đã được sử dụng rộng rãi trong các hệ thống cơ sở dữ liệu lớn, lọc thư rác, kiểm tra sự tồn tại của dữ liệu trong bộ nhớ đệm, và nhiều ứng dụng khác.

Cache filtering

Các hệ thống CDN caching web content đến nhiều user để đảm bảo performance, latency và network bandwidth. Gần ba phần tư các URL được truy cập từ các trang web chỉ được truy cập một lần và không bao giờ được truy cập lại. Việc cache lại các content này là không cần thiết và lãng phí tài nguyên hệ thống. Một ứng dụng quan trọng của Bloom Filter là việc sử dụng chúng một cách hiệu quả để xác định content nào nên được cache. Để ngăn chặn cache các content chỉ được truy cập một lần, một Bloom Filter được sử dụng để theo dõi tất cả các URL được truy cập bởi người dùng. Content được cache chỉ khi nó đã được truy cập ít nhất một lần trước đó, tức là content chỉ được cache khi có ít nhất 2 request tới nó. Việc loại bỏ những content chỉ được truy cập một lần tiết kiệm đáng kể bộ nhớ, tăng tỉ lệ hit rate.

Kiểm tra password yếu

Ngày nay việc đặt password yếu là sẽ dẫn đến nhiều rủi ro. Attacker có thể dễ dàng brute force trên tập password hay được đặt hoặc tập password đã bị leak để chiếm tài khoản. Ý tưởng của việc này là lưu một tập dữ liệu bao gồm các password yếu và check match khi user đặt password. Việc này có thể được check nhanh chóng bằng Bloom Filter, nhanh như hash map nhưng lại tốn ít space hơn. Dễ dàng hoạt động trên tập data lớn.

Ứng Dụng trong Mạng Xã Hội và Quảng Cáo

Các công ty hoạt động trong mạng xã hội và quảng cáo có thể sử dụng Bloom Filter để kiểm tra xem một người dùng hoặc một quảng cáo đã xuất hiện trước đó hay chưa, để tránh hiển thị nội dung trùng lặp.

Nhiều công ty lớn đã áp dụng Bloom Filter để xử lý cho các bài toán của họ:

• Akamai CDN dùng Bloom Filter để loại bỏ các request một lần đến disk cache. Akamai cũng là công ty phát hiện ra rằng gần 75% request từ user đến server của họ chỉ được đọc một lần.
• Google BigTable, Apache HBase, Apache Cassandra và cả PostgreSQL đều dùng Bloom Filter để kiểm tra content có tồn tại không trước khi query vào disk. Giảm disk lookups và tăng đáng kể hiệu suất query.
• Google Chrome browser đã từn dùng Bloom Filter để check những ỦL độc hại. Tất cả URL được check ở Bloom Filter local trước khi được gọi.

Lời kết

Bloom Filter đã trở thành một công cụ mạnh mẽ trong xử lý dữ liệu và giúp giải quyết nhiều vấn đề về hiệu suất và bộ nhớ trong các ứng dụng thực tế. Các công ty lớn và tổ chức trên khắp thế giới đã sử dụng Bloom Filter để cải thiện dịch vụ và tối ưu hóa xử lý dữ liệu của họ. Hy vọng qua bài viết này bạn có thêm công cụ để giải quyết các bài toán sau của mình. (Thay vì HashMap =))

References

Giới thiệu về Ansible Role

Mô tả: Ansible role cung cấp 1 framework và cấu trúc để thiết lập các tasks, variables, handlers, metadata, templates, và các files khác. Chúng cho phép ta sử dụng lại và chia sẻ Ansible code 1 cách hiệu quả.

Bằng cách này, chúng ta có thể tham chiếu và gọi đến roles ở nhiều playbook với chỉ 1 vài dòng code trong khi chúng ta có thể sử dụng lại cùng roles trên nhiều projects mà không phải lặp đi lặp lại code.

Hiệu quả của Roles trong Ansible

Khi bắt đầu với Ansible, chúng ta thường viết nhiều playbook để tự động hóa nhiều task một cách nhanh chóng. Trong quá trình đó, kỹ năng của chúng ta sẽ lên cao dần cho tới khi đạt đến 1 giới hạn. Và do đó, Ansible roles là thứ để bức phá giới hạn này.

Tổ chức Ansible content của chúng ta vào các roles cung cấp cho chúng ta 1 cấu trúc dễ dàng quản lý hơn nhiều so với sử dụng playbooks. Điều này có thể không quá rõ ràng trong những dự án nhỏ nhưng khi số lượng playbook tăng lên, độ phức tạp quả dự án cũng theo đó phát triển.

Cuối cùng, đặt Ansible code vào những roles cho phép ta tổ chức các dự án tự động hóa của mình thành các nhóm logic và tuân theo các mối bận tâm về nguyên tắc thiết kế phân tách. Sự phối hợp và tốc độ phát triển cũng được cải thiện nhiều khi những người dùng khác nhau có thể làm việc trên nhiều roles riêng biệt song song mà không phải sửa đổi chung 1 playbook.

Cấu trúc Ansible Roles

Ansible sẽ kiểm tra các file main.yml, các biến trong vars, và nội dung liên quan trong mỗi đường dẫn con. Việc thêm vào những file YAML trong 1 vài đường dẫn là hoàn toàn có thể. Ví dụy, bạn có thể nhóm các tasks của bạn trong những file YAML riêng biệt tùy theo 1 vài đặc tính:

• defaults: Bao gồm các giá trị mặc định cho các biến của role. Ở đây chúng ta định nghĩa 1 vài biến mặc định, nhưng chúng có độ ưu tiên thấp nhất và cũng thường bị ghi đè bởi các phương thức khác để customzie role.
• files: Chứa các file tĩnh và custom mà role sử dụng để thực hiện một vài tasks nhất định.
• handlers: 1 tập hợp các handlers mà có thể kích hoạt bởi các tasks của role.
• meta: Bao gồm thông tin metadata cho role, nó có thể là các dependencies (phụ thuộc), tác giả, license, nền tảng khả dụng,…
• tasks: 1 danh sách các tasks để thực hiện bởi role. Phần này có thể hiểu tương tự như task section trong 1 playbook.
• templates: Bao gồm các file template Jinja2 sử dụng bởi các tasks của role.
• tests: Bao gồm các file cấu hình liên quan đến kiểm thử role.
• vars: Chứa các biến được định nghĩa cho role (các biến ở đây có độ ưu tiên cao hơn defaults).

Hướng dẫn cài đặt, sử dụng Ansile Role

1. Cài đặt Ansible

• Link hướng dẫn cài đặt: https://docs.ansible.com/ansible/latest/installation_guide/intro_installation.html

2. Sử dụng ansible role

• Kịch bản: Sử dụng ansible role để đẩy 1 file bash bash-hello.sh lên server và chạy bash để in dòng chữ "Hello World" ra màn hình.
• Cấu trúc của Ansible role Test

• Nội dung file main.yml

• Chạy lệnh và hiện thị kết quả ra màn hình

Command: "ansible-playbook -i ansible_hosts playbook.yml"

Rate Limiter là một bài toán cơ bản, phổ biến trong thiết kế hệ thống nhằm kiểm soát số lượng requests được thực hiện trong một khoảng thời gian nhất định, giúp cho hệ thống không bị quá tải một cách đột biến. OCG cũng đã implement một cơ chế Rate Limit ở tầng OpenResty cho ShopBase. Bạn hãy thiết kế và implement một cơ chế Rate limit với một số requirements sau:

Background

Storefront của các stores trên ShopBase rất hay bị crawl bởi nhiều thể loại bot như: Known bots (Google bot, Facebook bot, Bing bot)…hay các unkown bots (các bots nhiều bên bên tự implement để crawl dữ liệu). Thông thường, các known bot sẽ crawl theo những quy tắc nhất định như: 

• Tôn trọng thông tin trong file robots.txt
• Khi crawl thì thường theo dõi các HTTP Rate Limit header hay code HTTP 429 để điều chỉnh quá trình crawl của mình

Tuy vậy, các unknown bots lại không làm vậy dẫn đến hệ thống có thể sập do handle quá nhiều requests. 

Requirements

• Tính năng cơ bản: 
  • Xây dựng một Rate Limiter có khả năng kiểm soát số lượng requests dựa trên một số tiêu chí nhất định, chẳng hạn như số lượng requests mỗi giây, mỗi phút và mỗi ngày cho từng domain và IP nguồn.
    • Đơn vị thời gian tính toán lượng request có thể là 1s, 10s, 60s…
  • Phân loại được requests: Hỗ trợ việc phân loại requests theo loại, ví dụ: user-based rate limiting và API endpoint-based rate limiting.
    • User-based có thể là theo IP hoặc theo bot name, hoặc 1 identity nào đó truy cập vào hệ thống.
    • API endpoint-based tức là có thể set rate limit cho từng endpoint API dựa trên IP hoặc user.
      • VD: 
        • API login chỉ được access với limit 1 req/s/domain/ip
        • API get product có limit 100 req/s/domain/bot_name
  • Thiết kế mở rộng: Thiết kế hệ thống sao cho nó có khả năng mở rộng dễ dàng theo chiều ngang (nhiều máy cùng có thể chạy rate limit)
  • Quản lý trạng thái và logs: Ghi log cho mỗi request bị từ chối và duy trì thông tin về trạng thái của Rate Limiter.
    • Ví dụ: lúc đó, IP/user đã request bao nhiêu req trong 1 khoảng thời gian rồi, vì sao bị chặn truy cập
  • Code clean: Implement được codebase 1 cách clean nhất có thể và áp dụng được các design pattern cần thiết vào codebase.
• Chú ý:
  • Cần quyết định kiểu support đơn vị thời gian để thay đổi được 1 cách hợp lý.
    • Ví dụ đo theo 1s, 10s, 60s…
  • Mỗi stores có thể có nhiều domains, nên đơn vị để kiểm soát truy cập/limit là domain. 
    • Ví dụ:
      • Có thể set 20 requests/second/domain/src IP,  400 requests/minute/domain/src IP…
  • Nên có 1 hard limit cho toàn bộ hệ thống.
    • Ví dụ:
      • Khi tổng traffic vào hệ thống vượt quá ngưỡng 10000 request/s → các request sau đó sẽ bị rate limited

Gợi ý

• Để xử lý được bài toán này, bạn cần tìm hiểu các thuật toán rate limiter và chọn ra một thuật toán để có thể implements 1 cách đơn giản nhất.
  • Nếu bạn muốn thuật toán khó hơn hoặc cải tiến các thuật toán đang có, hãy cứ làm theo cách của bạn
• Đây là một bài toán về hiệu năng nên bạn nên viết sẵn các test cases, user stories để khi thiết kế/code không bị thiếu case nào
  • Cần có code/script test performance để bạn có thể tự test được. Ví dụ go test, wrk, apache bench, playwright…
• Bạn có thể sử dụng Golang hoặc Nodejs (prefer Golang) để thực hành
• Nên có thiết kế hệ thống rõ ràng trước khi bắt tay vào code
  • Nếu chưa chắc chắn, bạn hãy check với Lead hoặc @TruongBui

Output

1. 1 bản thiết kế hệ thống bao gồm:
   1. Tech docs theo format của OCG
      1. Giải thích được rõ ràng thiết kế của bạn trong đó
2. 1 user stories docs mô tả các user stories bạn sẽ giải quyết. Có thể theo format tại đây
3. Codebase trong gitlab của công ty, đặt trong tài khoản của bạn
   1. gitlab.shopbase.com/user_name/challenge_1
      1. Code base bao gồm code implement chức năng này và 1 HTTP server demo
      2. Thông tin đo đạc performance hệ thống lúc có và không áp dụng rate limiter
      3. 1 file README.md có các thông tin về những highlight của bạn về thiết kế, codebase
      4. Unit & Integration test
         1. Test Coverage > 60%
         2. Có code/script chạy test
            1. Xem hệ thống có chạy đúng rate limit theo config không

Thời hạn hoàn thành

Hết ngày 18/2/2024

Questions

Nếu có câu hỏi, hãy đừng ngần ngại chat vào channel #dev để được giải đáp

Reference

System Design Interview Volume 1 - Alex Xu

LocalStack là một framework mã nguồn mở, cho phép bạn giả lập hơn 80 dịch vụ AWS trên local. Điều này giúp việc phát triển và kiểm thử ứng dụng trở nên dễ dàng hơn, mà không cần có tài khoản AWS.

Tuy nhiên, một số dịch vụ yêu cầu phiên bản trả phí LocalStack Pro để sử dụng🙃

Các điểm nổi bật của LocalStack

1. Giả lập hơn 80 dịch vụ AWS
   LocalStack hỗ trợ mô phỏng các dịch vụ AWS quan trọng như S3, Lambda, RDS, SQS, SNN và nhiều dịch vụ khác. Bạn có thể xem và tương tác với các tài nguyên này như là khi sử dụng các dịch vụ thực tế từ AWS. Điều này rất hữu ích trong quá trình phát triển và kiểm thử ứng dụng, vì bạn có thể làm việc cục bộ mà không cần tài khoản AWS và tất nhiên là cả internet.
2. Dễ dàng cài đặt và sử dụng
   LocalStack được viết bằng Python và có thể được cài đặt thông qua pip. Sau khi cài đặt, bạn có thể chạy LocalStack bằng một dòng lệnh duy nhất. Nó cung cấp cả giao diện web UI và các API để tương tác với các dịch vụ.
3. Cấu hình linh hoạt
   LocalStack cho phép bạn cấu hình nhiều thuộc tính khác nhau, chẳng hạn như port của từng dịch vụ, thông tin đăng nhập, quyền truy cập và nhiều hơn nữa. Bạn có thể tùy chỉnh việc để phù hợp với yêu cầu của của bạn.

Hướng dẫn setup LocalStack

LocalStack hỗ trợ nhiều hệ điều hành và nhiều phương thức để cài đặt và sử dụng như nhưng ở đây tôi sẽ hướng dẫn setup localstack trên Ubuntu với pip:
1. Cài đặt LocalStack bằng pip

pip install localstask

2. Sau khi cài đặt thành công, bạn có thể chạy LocalStack bằng cách chạy lệnh

localstask start

màn hình hiện ra như sau là đã start thành công

     __                     _______ __             __
    / /   ____  _________ _/ / ___// /_____ ______/ /__
   / /   / __ \/ ___/ __ `/ /\__ \/ __/ __ `/ ___/ //_/
  / /___/ /_/ / /__/ /_/ / /___/ / /_/ /_/ / /__/ ,<
 /_____/\____/\___/\__,_/_//____/\__/\__,_/\___/_/|_|

 💻 LocalStack CLI 3.1.0
 👤 Profile: default

[11:09:15] starting LocalStack in Docker mode 🐳  
───────────────────────────────────── LocalStack Runtime Log (press CTRL-C to quit) ─────────────────────────────────────
LocalStack version: 3.0.3.dev
LocalStack Docker container id: 06bb3bfac191
LocalStack build date: 2024-01-19
LocalStack build git hash: fd8b8ace

2024-02-01T04:09:17.982  INFO --- [-functhread4] hypercorn.error            : Running on https://0.0.0.0:4566 (CTRL + C to quit)
2024-02-01T04:09:17.982  INFO --- [-functhread4] hypercorn.error            : Running on https://0.0.0.0:4566 (CTRL + C to quit)
Ready.

Kết nối với LocalStack

Chúng ta thường thao tác với các dịch vụ AWS thông qua AWS CLI hoặc từ ứng dụng thông qua AWS SDK.

AWS CLI và AWS SDK đều hỗ trợ ghi đè endpoint của AWS. Để thao tác với LocalStack thông qua AWS CLI chúng ta chỉ cần thêm param --endpointurl http://localhost:4566.

Để thao tác với LocalStack, chúng ta nên cài thêm awslocal để thuận tiện hơn cho việc sử dụng:

pip install awscli-local

Ví dụ tương tác với LocalStack

awslocal s3api create-bucket --bucket sample-bucket --region us-west-2

awslocal s3api list-buckets

awslocal s3api put-object \
  --bucket sample-bucket \
  --key image.jpg \
  --body image.jpg \
  --region us-west-2

Nếu muốn sử dụng UI thì các bạn cần có tài khoản Localstack để truy cập, bạn có thể tham khảo thêm tại đây. Tuy còn nhiều hạn chế nhưng tôi thấy đây là một công cụ rất tiện cho các bạn trong quá trình thực hành thao tác với AWS.

Modify Core VueJS để tối ưu performance

Sử dụng một framework để xây dựng sản phẩm là một công việc vừa khó, vừa dễ. Với các sản phẩm ở scale vừa và nhỏ, framework hầu như đáp ứng được mọi kỳ vọng của chúng ta, và đó cũng là cách chúng được xây dựng. Tuy nhiên, khi sản phẩm bắt đầu đạt lượng người dùng tương đối lớn, các framework thường bắt đầu lộ ra các yếu điểm của mình. Đó là cơ hội để đội ngũ phát triển có thể vọc, tìm hiểu sâu, tối ưu chúng.

Tại OCG, VueJS là framework chính để xây dựng hệ thống frontend (Code name: storefront next). Khi các tính năng sản phẩm được thêm vào nhiều để đáp ứng được nhu cầu người dùng thì bài toán tối ưu performance, xử lý lỗi trở nên rất cần thiết.

Để đạt được điểm Google Pagespeed > 90 với một hệ thống website phức tạp là điều rất khó - nhưng là điều OCG đang hướng tới. Việc này đòi hỏi phải hiểu rất sâu về cách hoạt động bên trong của Core VueJS, Composition API, VueX/Pinia…để biết được quá trình build/change DOM, node, hydration…và sau đó cần phải optimize chúng cho phù hợp với bài toán tại OCG.

Việc tối ưu performance cho Core VueJS là một công việc phức tạp và đòi hỏi nhiều kiến thức, kinh nghiệm. Nó bao gồm các khía cạnh sau:

• Tối ưu quá trình build DOM: Đây là một trong những yếu tố quan trọng nhất ảnh hưởng đến performance của VueJS. Có nhiều cách để tối ưu quá trình này, chẳng hạn như sử dụng virtual DOM, lazy loading, minify code,...
• Tối ưu quá trình change DOM: Quá trình này xảy ra khi các giá trị của các component thay đổi. Có thể tối ưu quá trình này bằng cách sử dụng các kỹ thuật như lazy render, memoization,...
• Tối ưu quá trình hydration: Hydration là quá trình chuyển đổi dữ liệu từ server sang client. Có thể tối ưu quá trình này bằng cách sử dụng các kỹ thuật như lazy hydration,...

Biến VueJS thành một emplate Engine

VueJS SSG là một kỹ thuật optimize tốc độ của các ứng dụng web sử dụng VueJS.

Về cơ bản, VueJS được xây dựng để làm framework phía client, nơi mà theo mặc định, các thành phần Vue tạo và thao tác DOM trực tiếp trong trình duyệt. Tuy nhiên, nó cũng cho phép render các thành phần tương tự thành HTML content trên máy chủ (SSR). Sau đó, HTML content này có thể được gửi trực tiếp đến trình duyệt và "hydrate" (bind event vào các nodes) để biến đổi đánh dấu tĩnh thành một ứng dụng tương tác đầy đủ trên phía client.

SSR là một kỹ thuật hiệu quả để tăng tốc độ tải trang, nhưng nó có một số hạn chế. Đầu tiên, SSR yêu cầu render lại toàn bộ ứng dụng mỗi khi có thay đổi dữ liệu. Điều này có thể gây ra độ trễ đáng kể nếu dữ liệu thay đổi thường xuyên. Thứ hai, SSR có thể làm tăng kích thước ứng dụng, vì nó cần phải chứa cả mã VueJS và HTML content đã được render.

SSG là một kỹ thuật có thể khắc phục được những hạn chế của SSR. SSG hoạt động bằng cách render ứng dụng thành HTML tĩnh trên máy chủ trước khi gửi nó đến trình duyệt. Điều này có nghĩa là ứng dụng chỉ cần render một lần, ngay cả khi dữ liệu thay đổi. Ngoài ra, SSG có thể giúp giảm kích thước ứng dụng, vì nó chỉ cần chứa mã VueJS.

Tuy nhiên, SSG cũng có một số thách thức riêng. Một thách thức là SSG yêu cầu các nhà phát triển phải suy nghĩ trước về dữ liệu mà họ sẽ cần để render ứng dụng. Điều này có thể khiến việc phát triển ứng dụng trở nên phức tạp hơn. Một thách thức khác là SSG có thể khó bảo trì, vì các nhà phát triển cần phải cập nhật HTML tĩnh khi dữ liệu thay đổi.

OCG đang nghiên cứu một giải pháp SSG cho VueJS. Giải pháp này sẽ giải quyết các thách thức của SSG bằng cách sử dụng các kỹ thuật mới. Ví dụ, giải pháp sẽ sử dụng một hệ thống quản lý dữ liệu để lưu trữ dữ liệu cần thiết cho SSG. Điều này sẽ giúp các nhà phát triển dễ dàng cập nhật dữ liệu và giảm thiểu nhu cầu suy nghĩ trước về dữ liệu cần thiết.

Giải pháp SSG của OCG vẫn đang trong quá trình phát triển, nhưng nó có tiềm năng mang lại những cải tiến đáng kể về tốc độ và hiệu suất cho các ứng dụng web sử dụng VueJS.

We all know that the most effective way to prevent SQLi is to use Prepared Statement. But to apply Prepared Statement at scale to all repositories in an organization is not as simple as imagined.

SQL Injection vulnerability

SQL injection (SQLi) is a web security vulnerability that allows an attacker to interfere with the queries that an application makes to its database.

Nguồn: portswigger

Prepared Statement

Sure! Tất cả chúng ta đều biết rằng cách hiệu quả nhất để ngăn chặn SQLi là sử dụng Prepared Statement. Prepared Statement là một tính năng của database cho phép bạn định nghĩa SQL query template với các placeholders cho tham số. SQL query template được biên dịch trước và lưu trữ trên máy chủ cơ sở dữ liệu, sau đó bạn có thể cung cấp các giá trị tham số cụ thể để thực hiện truy vấn nhiều lần mà không cần biên dịch lại.

Quá trình sử dụng Prepared Statement bao gồm 2 bước:

1. Prepare: Database nhận SQL query template và biên dịch nó vào trong execution plan, tối ưu hóa truy vấn để nâng cao hiệu suất. Các placeholder trong template đại diện các tham số sẽ được cung cấp giá trị sau đó.
2. Execute: Sau khi Prepared Statement được tạo, bạn có thể cung cấp các giá trị cho tham số để nó thực thi query. Máy chủ database sử dụng precompiled execution plan và chỉ cần thay thế giá trị tham số, làm cho việc thực thi hiệu quả hơn cách thực thi của các SQL query thông thường.

Prepared Statement có thể ngăn SQL injection vì nó tự động xử lý escape và bind param, từ đó coi tham số truyền vào SQL query là data chứ không phải là code có thể thực thi.

Squirrel

Squirrel là một thư viện Golang phổ biến cho việc xử lý SQL query giúp bạn xây dựng SQL query và đơn giản hóa tương tác với database và nâng cao hiệu xuất lập trình. Nhưng điều này không có nghĩa là sử dụng squirrel sẽ mặc định giữ cho ứng dụng của bạn an toàn khỏi SQL injection.

Phạm vi của bài viết này sẽ chỉ tập trung vào việc sử dụng squirrel, với các thư viện khác, bạn vẫn có thể áp dụng tương tự.

Bad practices

func Vul_Func(tableName string, ids []int64, name string) (string, []interface{}, error) {
	idString := make([]string, 0)

	for _, id := range ids {
		idString = append(idString, fmt.Sprintf("%d", id))
	}

	query := squirrel.Select("*").
		From(tableName).
		Where(squirrel.Expr(fmt.Sprintf("id IN (%v)", strings.Join(idString, ",")))).
		Where(squirrel.Expr(fmt.Sprintf("name LIKE '%%%v%%'", name)))

	sqlQuery, args, err := query.ToSql()
	if err != nil {
		log.Fatal(err)
	}
// Print the generated query and arguments
	fmt.Println("query:", sqlQuery)
	fmt.Println("agrs:", args)
}

Đoạn code trên sử dụng hàm fmt.Sptrintf để build query bên trong hàm squirrel.Expr. Việc xây dựng truy vấn như vậy nghĩa là bạn đang nối trực tiếp dữ liệu đầu vào từ user vào truy vấn, đây là cách làm không an toàn và khiến cho đoạn code của bạn tồn tại lỗ hổng. Nếu print query được build theo cách trên ra console thì sẽ trông như sau:

query: SELECT * FROM users WHERE id IN (1,2,3) AND name LIKE '%fuzz OR 1=1%'
args: []

Tham số args là mảng rỗng [] và user input đã được nối trực tiếp vào query.

Good practices

func Safe_Func(tableName string, ids []int64, name string) (string, []interface{}, error) {
	idString := make([]string, 0)

	for _, id := range ids {
		idString = append(idString, fmt.Sprintf("%d", id))
	}

	query := squirrel.Select("*").
		From(tableName).
		Where(squirrel.Expr("id IN ("+squirrel.Placeholders(len(idsArgs))+")", idsArgs...)).
		Where(squirrel.Expr("name LIKE ?", fmt.Sprintf("%%%v%%", name)))

	sqlQuery, args, err := query.ToSql()
	if err != nil {
		log.Fatal(err)
	}
// Print the generated query and arguments
	fmt.Println("query:", sqlQuery)
	fmt.Println("agrs:", args)
}

Để fix lỗi trên, chúng ta cần sử dụng đúng query parameter bằng việc sử dụng placeholder ? cho các tham số. Nếu print query được build theo cách này ra console thì sẽ trông như sau:

query: SELECT * FROM users WHERE id IN (?,?,?) AND name LIKE ?
args: [1 2 3 %fuzz OR 1=1%]

Như bạn có thể thấy, input không an toàn bây giờ đã được truyền vào arg thay vì nối trực tiếp vào câu truy vấn.

Detect using string builder at scale

Nếu bạn đang đảm nhận task phát hiện và fix tất cả các vị trí sử dụng string builder như ví dụ ở phần bad practices, bạn sẽ làm gì? Bạn có thể đi hỏi tất cả các Lập trình viên trong công ty để nhớ lại tất cả các vị trí mình đã sử dụng string builder để xử lý.

Nhìn chung, có nhiều cách để chúng ta làm xong task nhưng thời gian của chúng ta không nhiều. Nếu bạn tinh ý, bạn có thể thấy giải pháp cho task này thông qua 2 ví dụ mà tôi show ở trên. Giải pháp là scan tất cả query được xử lý bởi driver và nếu query thỏa mãn 2 tiêu chí sau, nó là query tồn tại lỗ hổng SQL injection:

1. query sử dụng mệnh đề where
2. Không chứa bất kỳ arguments, giá trị args là một mảng rỗng như trong ví dụ Bad practices

Logic giả mã cho phương pháp này được trình bày như sau:

sqlQuery, args, err := query.ToSql()
lenArgs = len(args)
if strings.Contains(query, "where") && lenArgs == 0 {
   // return Alert location is using string builder to build query.
}

Cảm ơn đã bạn đã đọc!

Xử lý các luồng thanh toán là một công việc phức tạp, đòi hỏi sự tỉ mỉ, cẩn thận và đặc biệt, hiểu biết sâu sắc về bảo mật. Thông tin thẻ tín dụng/ghi nợ là một trong những thông tin quan trọng nhất của chúng ta. Chắc hẳn bạn sẽ khá cân nhắc xem có nên điền thông tin thẻ của mình vào một website hay không, nhất là các website ít tên tuổi, không có chứng chỉ bảo mật.

ShopBase cung cấp giải pháp tổng thể cho việc xây dựng và vận hành một trang web thương mại điện tử, bao gồm quản lý hàng hóa, đơn hàng và phát triển cổng thanh toán. Ngoài ra, ShopBase còn cung cấp các sản phẩm liên quan đến thanh toán như ShopBase Payment, giúp người bán hàng ở các nước đang phát triển có thể sử dụng các cổng thanh toán lớn như Stripe, PayPal một cách dễ dàng.

Một vấn đề quan trọng đối với mọi công ty vận hành cổng thanh toán là bảo mật dữ liệu của khách hàng và thông tin thẻ của họ. Tại ShopBase, chúng tôi đã và đang nghiên cứu rất nhiều công nghệ và kỹ thuật để đảm bảo điều này.

Từ việc đảm bảo an toàn khi người dùng điền thông tin thẻ trên website, qua đường truyền, đến việc lưu trữ lại trong hệ thống, chúng tôi đều áp dụng các tiêu chuẩn bảo mật cao nhất. Nếu một bước nào đó bị yếu thì sẽ gây nguy hiểm cho cả hệ thống.

Ngoài ra, chúng tôi cũng xây dựng các hệ thống phát hiện và cảnh báo bảo mật một cách kỹ càng theo các tiêu chuẩn cao nhất của PCI-DSS. Các flow phát triển sản phẩm, CI/CD hay infrastructure cũng cần được xem xét một cách kỹ lưỡng tại đây.

Khi nói đến "Fully Automated CI/CD" (Continuous Integration/Continuous Deployment hoàn toàn tự động), chúng ta đang nhìn vào một quy trình tự động hóa đầy đủ từ khâu tích hợp mã nguồn (CI) đến khâu triển khai (CD), mà không cần sự can thiệp của con người.

Quá trình đó bao gồm:

• Continuous Integration (CI)
  • Tích Hợp Mã Nguồn Tự Động: Mỗi khi có sự thay đổi trong mã nguồn (commits), hệ thống CI tự động tích hợp mã nguồn từ các nhánh khác nhau. Điều này giúp đảm bảo rằng mã mới không xung đột với mã hiện có.
  • Kiểm Thử Tự Động: Sau khi tích hợp mã, hệ thống thực hiện các bài kiểm thử tự động để đảm bảo rằng mã mới không làm hỏng chức năng hiện tại. Các bài kiểm thử này có thể bao gồm kiểm tra đơn vị, kiểm tra tích hợp và kiểm tra hệ thống.
  • Báo Cáo Tự Động: Kết quả kiểm thử và trạng thái tích hợp được báo cáo tự động, cung cấp thông tin chi tiết về tình trạng của mã nguồn. Điều này giúp các nhà phát triển dễ dàng xác định các vấn đề và khắc phục chúng.
• Continuous Deployment (CD)
  • Triển Khai Tự Động: Nếu quá trình tích hợp thành công, hệ thống CD tự động triển khai mã nguồn lên môi trường thử nghiệm hoặc sản xuất mà không cần sự can thiệp của người quản trị. Điều này giúp giảm thiểu thời gian cần thiết để đưa các tính năng mới ra thị trường.
  • Quản Lý Phiên Bản: Hệ thống theo dõi và quản lý các phiên bản, giúp dễ dàng quay lại phiên bản trước đó nếu có vấn đề phát sinh. Điều này giúp đảm bảo tính ổn định của hệ thống.
  • Rollback Tự Động: Trong trường hợp xấu nhất, nếu có sự cố, quá trình triển khai tự động có thể được đảo ngược để quay về phiên bản trước đó. Điều này giúp giảm thiểu thời gian ngừng hoạt động của hệ thống.

OCG đang release sản phẩm của mình theo các chu kỳ khoảng 2 - 4 tuần/lần. Mỗi quá trình này đòi hỏi rất nhiều công từ việc build, deploy các services, test features…

OCG đang hướng tới việc xây dựng hệ thống CICD tự động hóa nhằm giảm thiểu tối đa công sức của product team và time-to-market của các features. Điều này sẽ giúp OCG:

• Tăng tốc độ phát triển sản phẩm
• Giảm thiểu lỗi
• Tăng tính ổn định của hệ thống
• Tiết kiệm chi phí

Hệ thống này đòi hỏi Devops team phải làm việc rất sâu sát với product team, trong đó có QE (Quality Engineer) team để quản lý được kết quả chạy test (kiểm thử) feature và toàn bộ sản phẩm, quản lý các phiên bản và có đầy đủ công cụ monitor hệ thống, performance, log, alert…

Để xây dựng thành công hệ thống CICD tự động hóa, OCG cần:

• Chuẩn hóa quy trình phát triển sản phẩm
• Xây dựng các công cụ và quy trình tự động hóa
• Tập huấn cho các kỹ sư

OCG tin rằng việc xây dựng hệ thống CICD tự động hóa sẽ giúp OCG nâng cao năng lực cạnh tranh và mang lại trải nghiệm tốt hơn cho người dùng.

Việc sử dụng các nền tảng cloud (AWS, GCP, Azure...) giúp đơn giản hóa rất nhiều trong việc vận hành sản phẩm. Bởi OCG xây dựng sản phẩm cho thị trường quốc tế nên chúng tôi xác định sản phẩm sẽ gắn liền với các nền tảng này. Bên cạnh đó, việc sử dụng cloud cũng mang đến khá nhiều bài toán cần tối ưu hóa chi phí và quản lý resource tốt hơn, trong đó có bài toán quản lý tài nguyên ở quy mô lớn.

Mỗi bức ảnh, hoặc file người dùng upload vào hệ thống hiện tại đều được lưu trữ và quản lý trực tiếp trên Cloud Storage và database. ShopBase hiện tại có tới hàng tỉ files được lưu trữ trên các nền tảng đó. Tuy vậy, tính năng của các hệ thống này lại khá hạn chế. Có bên chỉ cho phép xóa các files không sử dụng đến sau một khoảng thời gian xác định, có bên lại tính chi phí call API rất cao.

Để tối ưu được chi phí, và có thể lưu trữ trên multi-cloud chỉ có một cách đó là xây dựng hệ thống để manage lượng dữ liệu đó trên nền các công cụ lưu trữ đám mây. Hệ thống này sẽ cần đủ nhanh để có thể trả lại dữ liệu cho người dùng ở latency phù hợp, cần có các cơ chế quản lý để có thể xử lý được các bài toán: thêm, sửa, xóa, ghi nhận traffic, tự động tối ưu chi phí theo các rules có sẵn, thống kê, chống ddos, hot linking… mà không ảnh hưởng đến tốc độ truy xuất.

Dưới đây là một số thách thức cần giải quyết khi xây dựng hệ thống này:

• Tốc độ: Hệ thống cần có khả năng xử lý truy vấn dữ liệu nhanh chóng, đáp ứng được nhu cầu của người dùng.
• Quản lý: Hệ thống cần có các cơ chế quản lý chặt chẽ để đảm bảo an toàn dữ liệu và tối ưu hóa chi phí.
• Khả năng mở rộng: Hệ thống cần có khả năng mở rộng để đáp ứng nhu cầu tăng trưởng dữ liệu trong tương lai.

Để giải quyết những thách thức này, OCG mong muốn các bạn có hiểu biết sâu sắc về các công nghệ lưu trữ NoSQL, SQL, cũng như các kiến thức về hệ thống phân tán, big data, machine learning nhằm xây dựng được hệ thống này một cách tối ưu nhất.

Sau nhiều năm vận hành hệ thống, từ các sản phẩm Beeketing tới ShopBase, OCG đã đúc kết được một kinh nghiệm rất quan trọng đó là để đảm bảo được hệ thống ổn định, infrastructure cần được xây dựng và maintain một cách tự động.

Hệ thống hạ tầng là nền tảng cho mọi hoạt động của một doanh nghiệp. Nó bao gồm các yếu tố như máy chủ, mạng, lưu trữ, bảo mật,... Việc vận hành hệ thống hạ tầng thủ công đòi hỏi nhiều thời gian và công sức, đồng thời dễ dẫn đến sai sót.

Tự động hóa hạ tầng (Infra-as-code) là giải pháp giúp giải quyết những vấn đề này. Với Infra-as-code, các cấu hình hạ tầng được thể hiện dưới dạng code, thay vì thực hiện thủ công bằng giao diện người dùng. Điều này giúp việc xây dựng, quản lý và vận hành hệ thống hạ tầng trở nên đơn giản, hiệu quả và an toàn hơn.

Tự động hóa hạ tầng mang lại nhiều ưu điểm cho doanh nghiệp, bao gồm:

• Hiệu quả: Tự động hóa giúp tăng cường hiệu suất và giảm thời gian triển khai, giúp doanh nghiệp nhanh chóng đáp ứng các yêu cầu mới. Đặc biệt, các devops teams vận hành sẽ rất nhanh chóng: training người mới, monitor các thay đổi, quản lý resources, tối ưu chi phí…
• Minh bạch: Hệ thống tự động hóa cung cấp dữ liệu minh bạch và chi tiết, giúp theo dõi và phân tích hiệu suất hệ thống.
• Giảm sai số: Loại bỏ sai sót do con người, làm giảm nguy cơ sự cố và tăng tính ổn định của cơ sở hạ tầng.
• Tăng tính bảo mật cho hệ thống: Tự động hóa giúp giảm thiểu các lỗ hổng bảo mật do con người gây ra.

OCG đã xây dựng được một số tính năng chính cho hệ thống Infra-as-code, tuy nhiên, vẫn còn nhiều các thành phần, tính năng trong danh sách trên vẫn cần được bổ sung vào hệ thống để đơn giản hóa quá trình vận hành hơn nữa.

Người xây dựng sản phẩm Infra-as-code không chỉ đòi hỏi các kiến thức sâu về hạ tầng, tương tác với các nền tảng Cloud, mà còn phải hiểu rất sâu về cách ShopBase system hoạt động để có thể thiết kế và hoàn thiện được hệ thống Infra-as-code tại OCG.

PrintBase là một trong những sản phẩm thành công nhất của OCG và hệ sinh thái ShopBase. Hướng đến thị trường Print-On-Demand (POD), PrintBase cung cấp giải pháp đơn giản hóa nhiều bước trong việc bán hàng POD, từ xử lý mockup, artwork đến cài đặt, đăng ký cổng thanh toán, làm việc với nhà cung cấp, chăm sóc khách hàng và ship sản phẩm đến cho người mua.

Gần đây, xu hướng áp dụng AI vào sản phẩm không còn xa lạ với cộng đồng phần mềm. Tuy nhiên, để AI có thể tạo ra sản phẩm phù hợp với người dùng trong thị trường e-commerce là một điều khá khó. Nhu cầu của người sử dụng với các sản phẩm in ấn phụ thuộc vào rất nhiều yếu tố: văn hóa vùng miền, ngôn ngữ, xu hướng hiện tại của thị trường…

Bằng cách tự động hóa quá trình tạo ra thiết kế, nội dung và xác định đối tượng mục tiêu, AI có thể giúp PrintBase:

• Giảm thời gian và công sức cần thiết cho các nhà bán lẻ để bán các sản phẩm POD
• Cải thiện chất lượng sản phẩm và nội dung
• Mở rộng phạm vi tiếp cận của sản phẩm đến nhiều đối tượng hơn

Để PrintBase cung cấp dịch vụ mạnh hơn nữa, tự động hóa gần như hoàn toàn quá trình bán hàng POD, OCG dự định sẽ nghiên cứu và áp dụng các mô hình AI để tạo ra các thiết kế của sản phẩm in, tạo ra các content phù hợp, hấp dẫn để tăng tính hấp dẫn cho sản phẩm, xác định được đối tượng người mua hàng phù hợp cho merchant. OCG đã và đang áp dụng ChatGPT và Midjourney để xây dựng content cho một số sản phẩm. Tuy nhiên, khi áp dụng ở một scale lớn lại là bài toán hoàn toàn khác. Xây dựng content về hình ảnh là một trong những challenge rất khó và hấp dẫn. OCG rất hy vọng 2024 là một năm đột phá về việc áp dụng AI vào sản phẩm một cách toàn diện.

OCG tự hào là công ty xây dựng được sản phẩm trong thị trường quốc tế cực kỳ cạnh tranh. Điều đó mang đến cho chúng tôi những khó khăn và cơ hội rất lớn. Phục vụ khách hàng quốc tế ở nhiều quốc gia, đảm bảo trải nghiệm người dùng là một bài toán cực kỳ khó và tốn kém không chỉ với OCG mà với bất kỳ sản phẩm, công ty nào. Có rất nhiều challenges phải giải quyết như:

1. Phân chia được các đối tượng khách hàng riêng biệt ở từng cụm servers khác nhau, để đảm bảo trải nghiệm vận hành ổn định. Ví dụ: các website/stores mới mở sẽ được dựng ở một cụm server, các website/stores đã ổn định được đặt ở một cụm server khác.

Điều này giúp đảm bảo rằng các website/stores mới mở sẽ không ảnh hưởng đến hiệu suất của các website/stores đã ổn định. Ví dụ, nếu một website/stores mới mở nhận được lưu lượng truy cập lớn đột ngột, điều này có thể gây ra sự cố cho các website/stores khác. Bằng cách phân chia các website/stores thành các cụm riêng biệt, chúng ta có thể kiểm soát lưu lượng truy cập đến từng cụm một cách hiệu quả hơn.

2. Vận hành được ổn định ở thị trường Trung Quốc (một thị trường cực kỳ khác biệt với các sản phẩm công nghệ thông tin). Nếu ai đã deploy sản phẩm cho thị trường trung quốc chắc chắn đã gặp rất nhiều vấn đề về traffic bị chặn bởi China Great Firewall, hệ thống chứng chỉ cho website trong nội địa Trung Quốc…

Để giải quyết vấn đề này, chúng ta cần xây dựng hệ thống có thể vượt qua được các hạn chế của thị trường Trung Quốc. Ví dụ, chúng ta có thể sử dụng các công nghệ như VPN hoặc proxy để truy cập vào các website/stores từ Trung Quốc. Ngoài ra, chúng ta cũng cần đảm bảo rằng các website/stores của mình tuân thủ các quy định của thị trường Trung Quốc.

3. Các stores vận hành ở Châu Âu được thiết lập các cơ chế, chứng chỉ riêng để đảm bảo được yêu cầu khắt khe về quyền riêng tư, bảo mật của họ.

Châu Âu có các quy định về quyền riêng tư và bảo mật rất nghiêm ngặt. Để tuân thủ các quy định này, chúng ta cần xây dựng hệ thống có thể bảo vệ dữ liệu của người dùng. Ví dụ, chúng ta có thể sử dụng các công nghệ như mã hóa dữ liệu hoặc các cơ chế xác thực hai yếu tố.

Để giải quyết những challenges này, chúng tôi mong muốn xây dựng một hệ thống sản phẩm, infrastructure có thể Shard By Design. Sharding by design là một kỹ thuật phân vùng dữ liệu và dịch vụ thành các cụm nhỏ hơn, được đặt ở gần người dùng nhất có thể. Điều này giúp đảm bảo trải nghiệm người dùng tốt hơn, đồng thời giảm thiểu chi phí vận hành.

Sharding by design là một giải pháp hiệu quả để giải quyết các challenges trong việc phục vụ khách hàng quốc tế. Chúng tôi tin rằng, với hệ thống Shard by design, chúng tôi có thể mang đến trải nghiệm tốt nhất cho người dùng ở mọi nơi trên thế giới.