Các chuyên gia viết chia sẻ kiến thức – FPT CLoud

Serverless ngày càng trở thành một khái niệm quen thuộc với các tín đồ công nghệ và doanh nghiệp trong hành trình chuyển đổi số. Cùng FPT Cloud khám phá chi tiết về Serverless và cách áp dụng nền tảng này trong bài viết dưới đây! >>> Xem thêm: Cloud Compute là gì? Phân loại và cách thức hoạt động 1. Lịch sử các phương pháp triển khai Serverless Từ thời đại của hạ tầng vật lý, ứng dụng được triển khai trực tiếp lên hệ điều hành của một máy chủ ảo, mô hình này sẽ đòi hỏi nhiều tài nguyên để vận hành cũng như việc đầu tư thiết bị đắt tiền cùng hàng loạt những vấn đề mà người quản trị phải giải quyết như sao lưu/phục hồi, lãng phí tài nguyên, đảm bảo tính sẵn sàng, mở rộng và bảo mật cho ứng dụng. Hệ thống ảo hoá ra đời đã giải quyết hầu như triệt để những vấn đề của mô hình vật lý. Hàng loạt những công nghệ ảo hoá ra đời và hiện nay vẫn đang được dùng rất nhiều như VMware, KVM, Xen, HyperV… Bằng việc phân tách một máy vật lý ra thành nhiều máy ảo chạy hệ điều hành độc lập sẽ tận dụng được nhiều tài nguyên hơn. Ngoài ra, các nền tảng ảo hoá còn có nhiều tính năng như mở rộng linh hoạt, sao lưu/khôi phục, snapshot, live-migrate, khả năng HA các máy ảo trong cụm vật lý… giúp ứng dụng được triển khai một cách đáng tin cậy hơn so với mô hình vật lý. Ảo hoá ngày nay vẫn là một công nghệ đang hot, các hãng tận dụng công nghệ này và phát triển thêm hàng loạt những dịch vụ đi kèm, tổ hợp thành các Public/Private Cloud mà ta đang sử dụng ngày nay. Tuy vậy, việc triển khai ứng dụng trên VM khá cồng kềnh gồm cả OS, middle layer (thư viện, runtime,…), app gây khó khăn cho các team phát triển về việc quản lý version, môi trường triển khai, đóng gói, time-to-market. Vì vậy mà container ra đời giúp các nhà phát triển đóng gói nhanh chóng ứng dụng trong một container image, triển khai container lại vô cùng nhanh chóng đi kèm khả năng tương thích với hầu hết hệ điều hành. Với kiến trúc phức tạp và xu thế ngày nay như microservice, CI/CD, GitOps container hầu như trở thành yếu tố bắt buộc phải có. Qua phân tích trên ta thấy rằng công nghệ triển khai ứng dụng thay đổi theo từng thời kỳ đều tuân theo quy luật tiện dụng, nhanh chóng, khả năng mở rộng, chịu lỗi tốt. Chính vì thế mà container đã bùng nổ như một cơn sốt công nghệ, đạt CAGR 30.8% năm 2017-2022 và sẽ còn tiếp tục tăng trưởng những năm sắp tới, nhiều doanh nghiệp đang chuyển đổi số hoặc trong giai đoạn phát triển ứng dụng mới đều sẽ tận dụng những tiện nghi của công nghệ microservice, container để giúp sản phẩm của họ nhanh chóng được đưa đến người dùng (tối ưu time-to-market), tiết kiệm đáng kể chi phí hạ tầng và nhân sự vận hành quản trị. [caption id="attachment_35540" align="aligncenter" width="800"] Báo cáo thị trường container – Theo 451 Research[/caption] Tuy rằng có nhiều tiện ích trong việc phát triển ứng dụng nhưng chúng ta cần phải nhìn nhận rằng container nói chung hay Kubernetes nói riêng (công cụ quản trị, phân bố, tự động hoá trong triển khai container) vẫn còn nhiều điểm khó tiếp cận đến người dùng như: Vận hành quản trị: Đòi hỏi nhiều kỹ năng như network, system, develop, logging, monitoring,… Yêu cầu bảo mật cao cho ứng dụng container. Rất phức tạp cho người mới. Cần lựa chọn vendor cung cấp dịch vụ uy tín hoặc tự triển khai. Vấn đề về giải pháp lưu trữ dài hạn cho container. [caption id="attachment_35541" align="aligncenter" width="800"] Xếp hạng những khó khăn trong sử dụng Kubernetes (container) – Theo TheNewStack[/caption] >>> Xem thêm: Cloud Server là gì? Hoạt động của hệ thống máy chủ đám mây 2. Serverless – Xu thế tất yếu của điện toán đám mây Nhận định trên đưa ta đến một kết luận về sự ra đời tất yếu của nền tảng mới mà ở đó nhà phát triển ứng dụng sẽ chỉ cần tập trung vào việc coding, hoạch định bài toán kinh doanh còn lại toàn bộ hạ tầng đều được nhà cung cấp dịch vụ quản lý. Đó chính là công nghệ “Serverless”, serverless không có nghĩa là không cần máy chủ server để hoạt động, mà nó mang ý nghĩa trừu tượng về cách thức sử dụng, thực ra những máy chủ này đã được quản lý bởi nhà cung cấp dịch vụ (cloud provider) bao gồm hạ tầng, DC, network, storage, security, platform, auto-scale để người phát triển ứng dụng chỉ cần đẩy code lên để chạy, đồng thời chỉ chi trả cho những tài nguyên được tiêu thụ trong thời gian xử lý request. Việc này giúp tiết kiệm hơn rất nhiều so với mô hình cloud VM hoặc sử dụng dịch vụ Kubernetes đều phải trả chi phí hàng tháng dù tài nguyên có được sử dụng hoặc idle. Trong mô hình cung cấp dịch vụ của điện đoán đám mây, serverless được xếp vào lớp Function as a service (FaaS) – trong một số tài liệu vẫn xếp serverless vào lớp Platform as a service (PaaS) về bản chất FaaS hay PaaS đều cung cấp công cụ cho người dùng ở lớp nền tảng phát triển Application. Dịch vụ điển hình của PaaS như fully-managed kubernetes hoặc database engine cho phép người dùng sử dụng để triển khai (deploy) ứng dụng với một vài lượt nhấp hoặc kéo thả, tuy nhiên sẽ vẫn phải cần có kiến thức về DB hoặc K8S để thực hiện các task của DBA hoặc Devops khi cần triển khai ứng dụng. Còn đối với FaaS người dùng chỉ cần phát triển code để xử lý nghiệp vụ ứng dụng và hầu như không cần sự can thiệp về mặt hệ thống khi triển khai và vận hành. Bảng dưới đây so sánh sự khác nhau đặt trưng của IaaS, PaaS và FaaS: Mục IaaS PaaS FaaS Unit of development Operating System Application Functions Provides VM package with OS Dev platform Execute code on-demand Abstracts Physical server OS & middleware Programing runtime Hiện nay trên thị trường serverless có lẽ chúng ta đã quá quen với những cái tên lớn như AWS Lamda, Azure Functions, Google Cloud Functions, các nền tảng này được áp dụng rộng rãi với nhiều câu chuyện thành công được chia sẻ. Ở phân khúc mã nguồn mở của serverless, những nền tảng có cộng đồng lớn có thể kể đến như KNative, OpenFaaS, Apache OpenWhisk, Kubeless, fission. Để hiểu rõ hơn ưu thế của serverless chúng ta cùng điểm qua một số tiện tích cốt lõi của serverless mang lại: Được quản trị hoàn toàn (fully managed): Các nhà phát triển sẽ không phải bận tâm về hạ tầng nữa. Dịch vụ serverless được cloud provider quản trị toàn bộ phần hạ tầng, hệ điều hành, middleware, runtime của ngôn ngữ lập trình và các module liên quan. Kiến trúc event-driven: Một trong những yếu tố then chốt trong microservice để giải quyết bài toán decoupling và phân tán. Các nền tảng serverless đều có cơ chế để được gọi thực thi khi xảy ra sự kiện từ hệ thống (e.g AWS Lamda được trigger khi có sự kiện trên dịch vụ notification SNS). Mở rộng không giới hạn (scale-out): Tận dụng lợi thế hạ tầng sẵn có của cloud provider, giúp người dùng dễ dàng mở rộng ứng dụng ứng dụng theo lượng tải đột biết hoặc giảm về 0 khi không được sử dụng. Tính sẵn sàng cao (high availability): Bản chất của serverless được cung cấp trên nền tảng hạ tầng kế thừa của cả mức IaaS và PaaS do đó khả năng HA đã được tích hợp sẵn bên trong. Less-Ops: Một số thao tác vận hành vẫn có ở serverless như database, debugging, testing,… trong môi trường container shell. Ngoài ra, kiến trúc serverless sẽ sử dụng một số dịch vụ đi kèm của cloud như Database Engine, Message Queue Engine, Monitor/Alert, Vault Engine,… giúp hạn chế tối đa thao tác vận hành. Tối ưu hoá chi phí: Chỉ chi trả cho lượng tài nguyên xử lý khi có request hoặc event và sẽ không mất phí khi ứng dụng rảnh rỗi (idle). Việc này tối ưu hơn rất nhiều so với chúng ta chạy VM và phải trả một chi phí cố định hàng giờ. No vendor lock-in: Với cùng một mã nguồn của nhà phát triển có thể triển khai được trên nhiều dịch vụ serverless của các nhà cung cấp khác nhau. Ngoài ra, khả năng tương thích này còn giúp quá trình dịch chuyển dịch vụ một cách nhanh chóng. [caption id="attachment_35542" align="aligncenter" width="800"] Model FaaS giữ vị trí giữa PaaS và SaaS[/caption] 3. Một số dịch vụ điển hình ứng dụng công nghệ Serverless Ứng dụng web: Static website, webapps, micro frontend, common framework flask/django/spring/fastapi,… Ứng dụng backend: Backend app/service, backend mobile, IoT edge,… Xử lý dữ liệu: Real-time data processing, Map reduce, batch processing, stream processing, ML inference,… Tác vụ tự động hoá IT: policy engine, infrastructure management,… Bên cạnh những tiện ích vượt trội, không phải ứng dụng IT nào cùng có thể triển khai trên nền tảng serverless. Để xác định ứng dụng doanh nghiệp của bạn có phù hợp để triển khai serverless hay không chúng ta có thể xét qua 07 tiêu chí dưới đây: 1. Ứng dụng stateless: Những tài nguyên phát sinh trong quá trình thực hiện một request sẽ mất sau khi kết thúc request đó. Việc này cần lưu ý đối với những ứng dụng cần giữ session trong phiên giao dịch, cần có thiết kế lưu trữ ở DB hoặc cache trong dịch vụ trước khi kết thúc chu trình. 2. Tính chất ephemeral: Bản chất của serverless hoạt động trên nền container, do đó tất cả dữ liệu file được ghi trên container này sẽ bị xoá đi khi container không còn tồn tại do quá trình auto-scale. 3. Hỗ trợ ngôn ngữ: Không phải nền tảng serverless nào cũng hỗ trợ đầy đủ ngôn ngữ lập trình, nên việc lựa chọn nền tảng thống nhất để đáp ứng toàn bộ ngôn ngữ lập trình cho dự án của bạn cũng rất quan trọng. 4. Chỉ duy trì khi hoạt động: Một số nền tảng sẽ giảm số lượng container về 0 khi dịch vụ không hoạt động (idle) quá lâu. Điều này sẽ ảnh hưởng đến việc khi cần sử dụng ứng dụng sẽ mất thời gian để khởi động lại gây ảnh hưởng đến trải nghiệm. Nên thiết kế để dịch vụ luôn có ít nhất một thành phần sẵn sàng nhận request hoặc chạy keep-alive dịch vụ. 5. Cơ sở dữ liệu: Sử dụng serverless với cơ sở dữ liệu quan hệ (relational database) sẽ có nhiều hạn chế do cơ chế giới hạn concurrent connection của DB, nên việc lựa chọn NoSQL trong serverless sẽ có nhiều lợi thế hơn. 6. Không cho phép truy tập file system: Như tính chất stateless và ephemeral của serverless kể trên, việc ứng dụng sử dụng config từ file system hoặc ghi dữ liệu ra tệp tin sẽ không được hỗ trợ như sử dụng Cloud VM. 7. Logging & Monitoring: Mỗi nền tảng serverless sẽ có cơ chế lấy log cũng như khả năng giám sát giới hạn các thông tin có thể cung cấp đồng nghĩa với việc không thể tận dụng cũng như tích hợp được với các phần mềm có sẵn của người dùng. Hiện tại các nhà phát triển, doanh nghiệp đã có thể dễ dàng đăng ký cũng như sử dụng, trải nghiệm công nghệ Serverless của các nhà cung cấp cloud nước ngoài như AWS, Azure, Google Cloud. Đối với các nhà cung cấp cloud trong trước hiện tại vẫn chưa có đơn vị cung cấp dịch vụ serverless nên việc trải nghiệm sẽ còn hạn chế, thay vào đó bạn vẫn hoàn toàn có thể tự triển khai riêng cho mình một hệ thống serverless local dựa trên các dịch vụ có sẵn của nhà cung cấp trong nước. Dưới đây là một ví dụ tham khảo việc triển khai nền tảng serverless sử dụng mã nguồn OpenFaaS - mã nguồn mở cho phép triển khai hệ thống serverless với các tính năng cơ bản đáp ứng mức production ready (https://www.openfaas.com). Chuẩn bị hạ tầng: o Sử dụng Cloud Virtual Machine để tự triển khai Docker, Kubernetes bằng các công cụ như Rancher, Kuberspray, kubeadm, openshift,… tuy nhiên sẽ tương đối phức tạp cần có nhiều kiến thức để triển khai và vận hành hiệu quả. o Phương án sử dụng dịch vụ cloud có cung cấp sẵn nền tảng Managed Kubernetes – FPT Kubernetes Engine (FKE) của FPTCloud là một dịch vụ điển hình, bạn có thể tham khảo thêm tại đây. Triển khai dịch vụ Serverless: o Tham khảo hướng dẫn triển khai trên nền K8s tại đây. Cấu hình expose dịch vụ: o Đối với phương án tự triển khai trên virtual machine bước này sẽ cần bạn phải triển khai thêm dịch vụ LB trên K8s như MetalLB, Cilium,… và ingress controller như nginx, traefik, haproxy,… o Với cách sử dụng dịch vụ managed Kubernetes thì loadbalancer và ingress đã được tích hợp sẵn ở mức hạ tầng, bạn chỉ cần expose service ở tầng dịch vụ K8s, nhà cung cấp dịch vụ Cloud sẽ tự động hoá hoàn toàn các bước. Sau đó bạn chỉ cần truy cập từ domain đã khai báo ở phần cài đặt trên và trải nghiệm. [caption id="attachment_35543" align="aligncenter" width="800"] Mô hình triển khai Serverless in-house[/caption] Những bài viết liên quan: Kubernetes vs Docker: Lựa chọn nào cho doanh nghiệp Top 6 dịch vụ điện toán đám mây hàng đầu hiện nay So sánh VPS và Cloud Server chi tiết từ A đến Z Tìm hiểu chi tiết khả năng giám sát (Observability) là gì? Ngày nay, với sự bùng nổ trong nền công nghiệp 4.0, hàng loạt những công nghệ mới ra đời nhằm đáp ứng được nhu cầu ngày càng cao của con người. Xuyên suốt bài viết chúng ta đã sơ lược qua quá trình phát triển của lĩnh vực điện toán và sự xuất hiện tất yếu của nền tảng Serverless. Chúng ta cũng đã định hình được vị trí của FaaS trong mô hình cung cấp dịch vụ của điện toán đám mây cũng như đã liệt kê ra được những lợi ích và hạn thế mà nền tảng này mang lại, đồng thời đưa ra những ứng dụng cụ thể của serverless trong việc phát triển phần mềm. Vẫn còn quá sớm để có thể kết luận được serverless có thể hoàn toàn thay thế được toàn bộ workload IT trong tương lai hay không, do về cơ bản, bản thân cơ chế hoạt động, lưu trữ của serverless chưa phù hợp cho các ứng dụng đặc thù, ứng dụng cơ sở dữ liệu, ứng dụng cần tính toán lớn,… Tuy nhiên với vị trí của một công nghệ mới nổi (emerging technology) cùng với những tính chất vượt trội như tối ưu hoá chi phí hạ tầng/vận hành, tối ưu time-to-market, nhanh chóng và đảm bảo; serverless hoàn toàn có thể là một công nghệ được sử dụng nhiều nhất trong thời gian sắp tới ở thời đại của microservice, edge computing. Trần Quốc Sang – Senior Cloud Engineer, FPT Smart Cloud

Observability là gì? Khi hệ thống công nghệ ngày càng phức tạp, việc theo dõi và xử lý sự cố trở thành thách thức lớn đối với các nhóm IT và DevOps. Một hệ thống quan sát hiệu quả không chỉ giúp đảm bảo hoạt động ổn định mà còn tối ưu hóa hiệu suất vận hành. Cùng FPT Cloud tìm hiểu chi tiết qua bài viết dưới đây! >>> Xem thêm: Dịch vụ thuê máy chủ vật lý (server vật lý) chất lượng FPT Cloud 1. Observability là gì? Trong lĩnh vực Công nghệ thông tin và điện toán đám mây, Observability là khả năng đo lường trạng thái hiện tại của một hệ thống dựa trên dữ liệu mà nó tạo ra, chẳng hạn như logs, metrics và traces. Một hệ thống quá phức tạp có thể bao gồm hàng trăm, thậm chí hàng ngàn máy chủ, dịch vụ và ứng dụng. Các lỗi có thể xuất hiện ở bất kỳ đâu trong hệ thống, việc phát hiện và sửa chúng có thể là một nhiệm vụ khó khăn. Observability giải quyết vấn đề này bằng cách cung cấp các công cụ và kỹ thuật cho phép bạn quan sát hệ thống, xem xét các sự kiện trong quá khứ, theo dõi hiệu suất hiện tại, tìm kiếm, giải quyết các vấn đề kỹ thuật và dự đoán các vấn đề tiềm ẩn trong tương lai. Các tổ chức thường triển khai Observability bằng cách sử dụng kết hợp các phương pháp công cụ đo lường bao gồm các công cụ đo lường mã nguồn mở, chẳng hạn như OpenTelemetry. Nhiều tổ chức cũng áp dụng giải pháp Observability để giúp phát hiện và phân tích tầm quan trọng của các sự kiện đối với hoạt động của họ, với vòng đời phát triển phần mềm, bảo mật ứng dụng và trải nghiệm của người dùng cuối. 2. Sự khác biệt giữa monitoring và observability? Mặc dù Monitoring và Observability có liên quan đến nhau và có thể bổ sung cho nhau, nhưng thực tế chúng là hai khái niệm khác nhau. Dưới đây là những khác biệt chính: Mục Monitoring Observability Mục đích Giám sát các yếu tố của hệ thống để phát hiện lỗi, vấn đề, đưa ra cảnh báo Tập trung vào việc giúp quản trị viên và nhà phát triển hiểu rõ hơn về hoạt động của hệ thống, giúp họ phát hiện và giải quyết các vấn đề một cách nhanh chóng và hiệu quả hơn Phạm vi Tập trung vào giám sát các yếu tố định sẵn, thu thập thông tin một cách thụ động, hầu hết trong số đó lại là không quan trọng Tập trung vào việc thu thập các thông tin cần thiết, tập hợp dữ liệu từ nhiều nguồn khác nhau, giúp hiểu được mối tương quan giữa chúng, từ đó nhanh chóng xác định được vấn đề cụ thể Tính linh hoạt  Chưa linh hoạt bằng observability Linh hoạt hơn so với monitoring. Giúp tìm hiểu các thông tin về hệ thống một cách nhanh chóng và dễ dàng hơn, bất kể độ phức tạp của hệ thống. >>> Xem thêm: Kubernetes (K8s) là gì? Chức năng và cơ chế hoạt động chi tiết 3. Tại sao observability lại quan trọng? Trong môi trường doanh nghiệp, Observability giúp các nhóm hiểu và trả lời các câu hỏi cụ thể về những gì đang diễn ra trong các hệ thống phân tán. Observability cho phép bạn hiểu những gì chậm hoặc bị lỗi và những gì cần phải làm để cải thiện hiệu suất. Với một giải pháp Observability được thiết lập, các nhóm có thể nhận được cảnh báo về các vấn đề và giải quyết chúng một cách chủ động trước khi chúng ảnh hưởng đến người dùng. Với các hệ thống phân tán, việc hiểu một vấn đề hiện tại là một thách thức to lớn, phần lớn là do nó tạo ra nhiều “ẩn số chưa biết - unknown unknowns” hơn các hệ thống đơn giản hơn. Bởi vì monitoring yêu cầu “những ẩn số đã biết - known unknowns”, nên nó thường không giải quyết được các vấn đề một cách thỏa đáng trong những môi trường phức tạp này. Observability phù hợp hơn với tính không thể đoán trước của các hệ thống phân tán, chủ yếu là vì nó cho phép bạn đặt câu hỏi về hành vi của hệ thống khi có vấn đề phát sinh. “Tại sao X bị lỗi?” hoặc "Điều gì đang gây ra độ trễ?" là một số câu hỏi mà Observability có thể trả lời. Tóm lại, observability là rất quan trọng để đảm bảo các hệ thống phức tạp hoạt động tốt nhất có thể và giảm thiểu các rủi ro liên quan đến hiệu suất, bảo mật, tính sẵn sàng của hệ thống và trải nghiệm người dùng. Observability cung cấp một cái nhìn toàn diện về hành vi và hiệu suất hệ thống, giúp các nhóm nhanh chóng phát hiện, chẩn đoán và giải quyết các vấn đề để cải thiện độ tin cậy và sự hài lòng của người dùng. 3.1 Các thành phần trong observability Observability bao gồm 3 thành phần chính để giúp quản trị viên, nhà phát triển và các chuyên gia tìm hiểu về hoạt động của hệ thống. Các thành phần này bao gồm: Logs: Đây là những bản ghi văn bản có cấu trúc hoặc không có cấu trúc được ghi lại bởi hệ thống. Chúng bao gồm thông tin về các lỗi, cảnh báo, tình trạng hoạt động, các yêu cầu được xử lý và các hoạt động xảy ra tại một thời điểm cụ thể. Logs là một phần quan trọng trong observability, bởi vì chúng cho phép bạn xem xét các sự kiện trong quá khứ và tìm kiếm nguyên nhân của các vấn đề. Metrics: Đây là các số liệu đo lường về hiệu suất và hoạt động của hệ thống, bao gồm thông tin về tài nguyên sử dụng, lưu lượng truy cập, thời gian phản hồi,... Các metrics được thu thập và lưu trữ liên tục, giúp cho quản trị viên và nhà phát triển theo dõi hoạt động của hệ thống và phát hiện các vấn đề liên quan đến hiệu suất. Traces: Đây là các thông tin về quá trình xử lý các request trong hệ thống. Các traces cho phép bạn theo dõi các request được xử lý thông qua các hệ thống khác nhau trong hệ thống tổng thể. 3.2 Những lợi ích observability mang lại là gì? Các lợi ích của observability là rất đa dạng và có thể được áp dụng cho nhiều mục đích khác nhau. Dưới đây là một số lợi ích chính của observability: Phát hiện và giải quyết sự cố nhanh chóng: Observability cung cấp một cái nhìn toàn diện về hệ thống, giúp bạn nhanh chóng phát hiện và giải quyết các sự cố. Nâng cao hiệu suất hệ thống: Observability cung cấp thông tin về hiệu suất của hệ thống, giúp người dùng hiểu được tình trạng của hệ thống và đưa ra các quyết định để nâng cao hiệu suất. Gia tăng trải nghiệm người dùng: Công cụ observability giúp xác định các vấn đề có thể ảnh hưởng đến trải nghiệm người dùng và giải quyết chúng để cải thiện sự hài lòng của người dùng. Nâng cao khả năng dự báo: Dữ liệu từ logs, metrics và traces có thể được sử dụng để xác định các xu hướng và mô hình hoạt động của hệ thống. Điều này giúp bạn dự đoán các sự cố tiềm ẩn trước khi chúng xảy ra và đưa ra các biện pháp ngăn chặn trước khi vấn đề trở nên nghiêm trọng. Cải thiện chất lượng sản phẩm: Dữ liệu từ logs, metrics và traces có thể giúp developer kiểm tra, đánh giá chất lượng của mã nguồn, xác định lỗi và điều chỉnh mã nguồn để cải thiện chất lượng của ứng dụng. Cải thiện tính khả dụng của hạ tầng và dịch vụ: Với việc sử dụng observability, các vấn đề có thể được giải quyết nhanh chóng hơn, giúp giảm thời gian chết của hệ thống. Điều này cũng giúp đảm bảo hệ thống được sử dụng đúng cách và đáp ứng được các yêu cầu của người dùng. >>> Xem thêm: Lưu trữ đám mây là gì? TOP ứng dụng lưu trữ đám mây tốt nhất 4. Những thách thức của observability là gì? Mặc dù observability có nhiều lợi ích, nhưng cũng đem đến một số thách thức trong việc triển khai và sử dụng. Dưới đây là một số thách thức của observability: Khó khăn trong việc xử lý dữ liệu: Dữ liệu observability có thể được thu thập từ nhiều nguồn khác nhau và với khối lượng lớn, do đó việc xử lý dữ liệu có thể trở nên phức tạp. Sự phức tạp của hệ thống: Các hệ thống phức tạp, nhiều phần chạy song song và phụ thuộc vào nhiều dịch vụ khác nhau, điều này làm cho việc giám sát và đo lường trở nên khó khăn hơn. Độ tin cậy của dữ liệu: Để có được kết quả đáng tin cậy, dữ liệu observability phải được thu thập và lưu trữ một cách chính xác và đầy đủ. Nếu dữ liệu không chính xác hoặc thiếu, các kết quả sẽ không có giá trị. Chi phí: Việc triển khai và duy trì các công cụ observability có thể tốn kém, đặc biệt là đối với các hệ thống lớn và phức tạp. Kiến thức chuyên môn: Để triển khai và sử dụng các công cụ observability hiệu quả, người quản lý và phát triển hệ thống cần có kiến thức chuyên môn về các công nghệ, hiểu biết sâu rộng về cách hoạt động của hệ thống. 5. Làm cách nào để triển khai observability? Để triển khai observability hiệu quả, bạn cần có công cụ thích hợp cho các hệ thống và ứng dụng của mình để thu thập dữ liệu. Bạn có thể tạo một hệ thống có thể quan sát được bằng cách xây dựng các công cụ của riêng mình, sử dụng phần mềm mã nguồn mở hoặc mua giải pháp observability thương mại. Thông thường, có bốn thành phần liên quan đến việc triển khai observability: Thiết bị đo đạc (Instrumentation): Đây là những công cụ đo lường thu thập dữ liệu từ container, service, ứng dụng, máy chủ và bất kỳ thành phần nào khác trong hệ thống của bạn, cho phép hiển thị trên toàn bộ cơ sở hạ tầng của bạn. Tương quan dữ liệu (Data correlation): Dữ liệu được thu thập từ các hệ thống của bạn sẽ được xử lý và tạo mối tương quan, điều này cho phép bạn quản lý dữ liệu tự động hoặc tùy chỉnh để trực quan hóa dữ liệu. Ứng phó sự cố (Incident response): Các công nghệ tự động hóa và quản lý sự cố nhằm mục đích chuyển dữ liệu về sự cố cho đúng người và nhóm dựa trên on-call schedules và khả năng kỹ thuật. AIOps: Các mô hình Machine learning được sử dụng để tự động tổng hợp, tương quan và ưu tiên dữ liệu sự cố, cho phép bạn lọc nhiễu cảnh báo (alert noise), phát hiện các sự cố có thể ảnh hưởng đến hệ thống và tăng tốc ứng phó sự cố khi chúng xảy ra. Những bài viết liên quan: cPanel là gì? Hướng dẫn sử dụng phần mềm cPanel từ A – Z Mẹo đổi Port Remote Desktop cực nhanh chỉ trong 15s So sánh Windows Server và Linux Server chi tiết từ A đến Z Mail Server là gì? Cách thức hoạt động và tính năng của Mail Server Bài viết đã giới thiệu về các thành phần cơ bản của observability, tầm quan trọng, lợi ích của việc áp dụng observability. Chúng ta có thể kết luận rằng observability là một khái niệm quan trọng trong lĩnh vực quản lý và giám sát hệ thống. Nó cho phép chúng ta quan sát và hiểu được các hoạt động và hiệu suất của hệ thống, từ đó giúp phát hiện và giải quyết các vấn đề một cách nhanh chóng và hiệu quả hơn. Tuy nhiên, để áp dụng observability thành công, người sử dụng cần phải có kiến thức chuyên môn về hệ thống mà họ đang quan sát, hiểu về các công cụ quan sát và phân tích dữ liệu để có thể đưa ra những quyết định đúng đắn.Với sự phát triển của công nghệ và sự phổ biến của các hệ thống phân tán, observability đang trở thành một yếu tố quan trọng trong việc quản lý, đảm bảo chất lượng và sự ổn định của hệ thống phần mềm.

Tấn công ứng dụng web đang là mối đe doạ phổ biến, chiếm tới 26% tổng số vụ vi phạm dữ liệu. Nhằm trao quyền cho doanh nghiệp chủ động bảo mật và đối phó với các cuộc tấn công mạng, FPT Smart Cloud hợp tác cùng Penta Security ra mắt sản phẩm FPT Cloud WAPPLES - Nền tảng bảo vệ ứng dụng web thông minh, hứa hẹn bảo mật toàn diện và tối ưu cho mọi doanh nghiệp trên mọi môi trường đám mây. 1. Tường lửa ứng dụng web (WAF) qua các thế hệ Tường lửa ứng dụng web sở hữu các chức năng cơ bản như phát hiện và ngăn chặn các cuộc tấn công web như SQL Injection và Cross-Site Scripting, tránh các vụ rò rỉ dữ liệu nhạy cảm, truy cập trái phép và phá hoại trang web hoặc giả mạo yêu cầu chéo trang. Trải qua quá trình phát triển không ngừng, tường lửa ứng dụng web ngày càng được nâng cấp và cải thiện để đáp ứng nhu cầu bảo mật của doanh nghiệp. WAF thế hệ thứ nhất: Cơ chế hoạt động của WAF thế hệ 1 dựa trên phương pháp khớp mẫu được sử dụng trong các hệ thống ngăn chặn xâm nhập (IPS) để lập danh sách từ chối các cuộc tấn công đã biết. Tường lửa ứng dụng web thế hệ 1 thường xuyên nhầm lẫn các truy cập hợp pháp thành tấn công, dẫn đến tình trạng dương tính giả (false positive). Điều này không chỉ gây phiền hà cho người dùng mà còn khiến quản trị viên phải mất nhiều thời gian để giải quyết các báo động giả. WAF thế hệ thứ hai: Tường lửa thế hệ 2 đã có những cải tiến đáng kể so với thế hệ trước, đặc biệt là khả năng tự động xây dựng danh sách cho phép bằng cách phân tích ứng dụng web. Tuy nhiên, trước sự đa dạng và biến đổi không ngừng của các cuộc tấn công, tường lửa này vẫn chưa hoàn toàn đáp ứng được nhu cầu bảo mật của các ứng dụng web hiện đại. WAF thế hệ thứ ba: Tường lửa ứng dụng web thế hệ mới nhất giảm đáng kể kết quả dương tính giả so với hai thế hệ trước nhờ được trang bị các kỹ thuật như phát hiện danh sách từ chối, cho phép phát hiện danh sách và phân tích nội dung lưu lượng truy cập web để bảo vệ chống lại từng loại tấn công web. Hơn nữa, WAF thế hệ thứ 3 có khả năng phát hiện các biến thể tấn công mới bằng cách sử dụng logic, giảm tổng số chữ ký cần thiết trong danh sách. Điều này giúp giải quyết vấn đề phải liên tục cập nhật danh sách chữ ký, vốn là yêu cầu của hai thế hệ WAF trước đó. 2. FPT Cloud WAPPLES - Tường lửa ứng dụng web thế hệ mới nhất FPT Cloud WAPPLES là tường lửa ứng dụng web tiên tiến, tích hợp công cụ phát hiện mối đe dọa sử dụng logic thông minh dựa trên công nghệ học máy. Được thiết kế với các nguyên tắc bảo mật ứng dụng web, WAPPLES không chỉ hiệu quả trong việc chống lại các cuộc tấn công web phổ biến mà còn đóng vai trò quan trọng trong việc ngăn chặn rò rỉ dữ liệu, truy cập trái phép và giả mạo trang web - những mối đe dọa ngày càng gia tăng đối với các tổ chức hiện nay. Với công cụ phát hiện thông minh, nó cũng có khả năng phản ứng với các cuộc tấn công mới được đưa ra bởi các mối đe dọa dai dẳng nâng cao (APT). Bên cạnh đó, WAPPLES cung cấp bảo mật mạnh mẽ với khả năng phát hiện mối đe doạ chính xác vượt trội. Nó giúp duy trì trạng thái hoàn hảo của ứng dụng web liên tục thông qua tính năng tự chẩn đoán thời gian thực và kiểm tra định kỳ tự động, tất cả đều được kích hoạt bởi công nghệ học máy. Một số đặc điểm nổi bật của tường lửa thế hệ mới bao gồm: Dịch vụ bảo mật độc lập: FPT Cloud WAPPLES cung cấp khả năng áp dụng nâng cao và tăng khả năng xử lý tải nặng. Tường lửa thế hệ mới nhất này có thể được tích hợp vào môi trường đám mây của doanh nghiệp, đảm bảo tính khả dụng cao, khả năng kiểm soát được cải thiện và quản lý tích hợp. Bên cạnh đó, FPT Cloud WAPPLES còn cung cấp phiên bản chuyên dụng về mặt vật lý, cho phép lưu lượng truy cập web cao hơn. Thiết lập chuyên nghiệp: Khác với các sản phẩm tường lửa thế hệ trước, FPT Cloud WAPPLES không áp dụng các quy tắc chung cứng nhắc. Ngược lại, tường lửa thế hệ mới cho phép điều chỉnh các chính sách bảo mật phù hợp với hành vi của khách hàng và đặc điểm của ứng dụng web. Được công nhận trên toàn cầu: Không chỉ có mặt trên 148 quốc gia trên toàn thế giới, gần đây nhất, FPT Cloud WAPPLES đã nhận được giải thưởng “Công ty tường lửa ứng dụng web của năm” từ Frost & Sullivan (2023), đồng thời được Gartner công nhận là một trong những giải pháp WAAP hàng đầu. 3. Các tính năng nổi bật của FPT Cloud WAPPLES Tích hợp công cụ phát hiện thông minh COCEPTM Công cụ phát hiện COCEPTM của FPT Cloud WAPPLES được tích hợp công nghệ của Penta Security, không chỉ giúp tăng cường khả năng phát hiện các hiểm hoạ mà còn cung cấp các lợi ích bổ sung như tự chẩn đoán và báo cáo mối đe dọa. FPT Cloud WAPPLES chặn các cuộc tấn công không xác định và zero-day. Với các quy tắc được xác định và quy tắc tùy chỉnh, FPT Cloud WAPPLES bảo vệ máy chủ khỏi các cuộc tấn công web bằng cách phân tích và phát hiện theo loại tấn công. Nâng cao độ chính xác trong phát hiện mối đe doạ Các tường lửa ứng dụng web truyền thống thường gặp phải tình trạng dương tính giả (false positive). Quản trị viên bảo mật phụ trách sẽ phải tự rà soát, kiểm tra các kết quả dương tính giả và thêm chúng làm ngoại lệ cho các chính sách bảo mật. FPT Cloud WAPPLES, với khả năng phát hiện mối đe doạ chính xác, có tỷ lệ dương tính giả rất thấp, giúp giảm thiểu đáng kể thời gian và nguồn lực trong quản lý. Khả năng chẩn đoán tức thời FPT Cloud WAPPLES có khả năng tự chẩn đoán theo thời gian thực dựa trên học máy. Bằng cách đó, nó kiểm tra các vấn đề như quá tải lưu lượng, quá tải CPU/ bộ nhớ và không đủ dung lượng CSDL. Quản trị viên có thể đặt ngưỡng mong muốn và nhận cảnh báo khi vượt quá ngưỡng. Ngoài ra, FPT Cloud WAPPLES tiến hành phân tích học máy trên dữ liệu nhật ký hoạt động của nó để xác định sự hiện diện của các bất thường và ngăn ngừa các vấn đề trước. Khả năng bảo trì tự động FPT Cloud WAPPLES có khả năng tự động bảo trì thông qua các công cụ kiểm tra định kỳ. Khi một kỹ sư thực hiện kiểm tra, hệ thống sẽ tạo ra báo cáo bằng cách phân tích nhật ký phát hiện và kiểm toán cũng như dữ liệu từ tự chẩn đoán thời gian thực. Trước đây, các kỹ sư phải giải thích kết quả kiểm tra bằng lời nói, nhưng với FPT Cloud WAPPLES, các báo cáo tự động đã tóm tắt những kết quả này, giúp quản trị viên có cái nhìn tổng quan khách quan về tình trạng của WAF. Ngoài ra, FPT Cloud WAPPLES còn tự động quản lý bảo trì bằng cách cung cấp chức năng báo động dịch vụ bảo trì, giảm bớt gánh nặng cho quản trị viên. Việc bảo trì tường lửa web là vô cùng quan trọng, bởi một lỗi nhỏ trong quá trình kiểm tra cũng có thể dẫn đến những hậu quả nghiêm trọng về bảo mật. Đối với tường lửa bảo mật thế hệ trước, các kỹ sư thường phải thực hiện kiểm tra thủ công bằng cách truy cập trang web hàng tháng, hàng quý hoặc nửa năm một lần, tìm kiếm các bất thường của hệ thống như quá tải CPU. Điều này có thể dẫn đến sai sót bởi kết quả kiểm tra sẽ bị ảnh hưởng bởi phán đoán chủ quan của kỹ sư. Tuy nhiên, với tính năng bảo trì tự động, quá trình này trở nên chính xác và khách quan hơn, giảm thiểu đáng kể rủi ro bảo mật. Trong bối cảnh các cuộc tấn công vào ứng dụng web ngày càng tinh vi và phức tạp, việc trang bị một giải pháp bảo mật hiệu quả là điều cấp thiết. Với các chứng nhận uy tín như CC và GS, FPT Cloud WAPPLES hứa hẹn cung cấp bảo mật mạnh mẽ và toàn diện, khẳng định vị thế là giải pháp bảo mật đáng tin cậy cho các doanh nghiệp. Cơ hội trải nghiệm FPT Cloud WAPPLES 30 ngày hoàn toàn miễn phí. Số lượng có hạn, chương trình kéo dài đến hết ngày 13/11/2024. Đăng ký ngay tại ĐÂY

Theo Gartner, đến năm 2025, 85% doanh nghiệp sẽ áp dụng chiến lược "cloud-first", trong đó 95% khối lượng công việc số sẽ được triển khai trên nền tảng đám mây. Ngày nay, việc chuyển đổi lên đám mây (Cloud Migration) đang trở thành xu hướng, giúp doanh nghiệp tối ưu hóa quy trình vận hành, tạo ra cơ hội cạnh tranh mạnh mẽ trong thị trường số hóa. Nhưng liệu bạn đã hiểu đúng và đủ về Cloud Migration để có thể tận dụng hết sức mạnh của công nghệ này trong doanh nghiệp? 1. Dịch chuyển lên đám mây – Những lầm tưởng về tiêu chí lợi ích Khi nói về các lợi ích của việc dịch chuyển lên đám mây “Cloud Migration”. Đầu tiên các doanh nghiệp thường quan tâm tới vấn đề chi phí – các khía cạnh khác nhau của chi phí: tiết kiệm chi phí, tường minh hóa chi phí, rút ngắn vòng quay vốn, và tối ưu hóa dòng tiền. Thực tế chỉ có 8% CEO trên thế giới lựa chọn tiết kiệm chi phí là tiêu chí hàng đầu và tiêu chí này chỉ đứng thứ 6 trong số tổng cộng hơn 10 tiêu chí lợi ích khác nhau. Tiếp theo là hiện đại hóa IT chiếm đến 17%, và sau đó là cải thiện hiệu quả, tăng cường bảo mật thông tin, tăng năng suất và tăng tốc độ đổi mới sáng tạo. Doanh nghiệp luôn mong muốn tối ưu chi phí tốt nhất trong quá trình dịch chuyển lên đám mây, nhưng thực tế cho thấy điều mà nhiều doanh nghiệp nhận được còn hơn thế nữa, dễ thấy nhất chính là cơ hội cho các doanh nghiệp hiện đại hóa hệ thống và ứng dụng CNTT của họ. [caption id="attachment_49642" align="aligncenter" width="800"] Cloud Migration có nhiều lợi ích hơn là chỉ tiết kiệm chi phí.[/caption] 2. Cloud Migration – Không chỉ là câu chuyện đi thuê dịch vụ Cloud không chỉ là câu chuyện “hosting”, Cloud Migration không chỉ là thay vì đầu tư thì đi thuê dịch vụ, nó còn là câu chuyện của kinh tế chia sẻ và kinh tế quy mô. Cloud Migration giúp doanh nghiệp chuẩn hóa công nghệ, áp dụng công nghệ mới, đưa sản phẩm ra thị trường một cách nhanh nhất. Đây còn là phương pháp giúp doanh nghiệp tăng năng suất, phát triển ứng dụng, hiện đại hóa kiến trúc, chuyển đổi mô hình sản xuất và vận hành. Ngoài ra, giải pháp còn giúp cho doanh nghiệp áp dụng các phát kiến ngày càng nhanh, tối ưu chi phí và tải trọng lên hệ thống, tăng độ phủ rộng và tăng trải nghiệm của khách hàng. Cùng một phương diện kinh doanh, các doanh nghiệp tận dụng được hệ sinh thái các dịch vụ đa dạng trên Cloud sẽ có lợi thế ngắn và trung hạn. Ngay cả các doanh nghiệp đầu tư trước dưới “mặt đất”, sẽ gặp khó khăn khi gặp những đối thủ mới nổi tận dụng nền tảng mới lên Cloud và tận dụng sẵn có các dịch vụ PaaS, hệ sinh thái AI, GPU, IoT Platform, Machine Learning, Data Platform, v.v... cho các phát kiến mới, những công nghệ rất khó hoặc gần như không thể có ngay dưới mặt đất. Tuy nhiên, về mặt dài hạn, dịch chuyển lên Cloud cần đồng nghĩa với việc chuyển đổi mô hình sản xuất và phát triển ứng dụng. Những ứng dụng theo chu trình phát triển sản phẩm cũ, đứt đoạn, một lần, rồi vận hành cố định sẽ không còn phù hợp. Thay vào đó là cần ứng dụng DevSecOps thành một chu trình linh hoạt, liên tục, gần như vô tận trên Cloud, từ phát triển, kiểm tra, triển khai, giám sát đến vận hành ứng dụng. Như vậy, chuyển đổi lên Cloud là cơ hội hiện đại hóa hệ thống đồng thời cũng nâng cấp năng lực của nhân sự của các doanh nghiệp, mở ra những cơ hội trải nghiệm mới cho đội ngũ chuyên viên Cloud. 3. Chiến lược dịch chuyển lên Cloud hiệu quả cho doanh nghiệp Chiến lược Cloud Migration thường được biết đến là chiến lược 5R hoặc 6R – Rehost, Refactor, Rearchitect, Rebuild và Replace. Rehost là lift-and-ship, chuyển đổi 1-1 lên Cloud. Refactor là tinh chỉnh một số yếu tố để có thể bắt đầu tận dụng được các dịch vụ riêng có của Cloud. Rearchitect ở một mức cao hơn là chuyển đổi kiến trúc theo hướng đúng chuẩn Cloud. Rebuild là phát triển lại ứng dụng theo đúng chuẩn Cloud. Cuối cùng, Replace là sử dụng luôn phần mềm như một dịch vụ (SaaS) trên Cloud. Trên thế giới, mức độ “Cloud hóa” đã tương đối đồng đều ở các lĩnh vực, tuy nhiên ở Việt Nam, trong mỗi lĩnh vực các doanh nghiệp lại ứng dụng Cloud ở mức độ khá khác nhau. Mỗi doanh nghiệp ở Việt Nam đang có đường cong Hype Cycle – chu kỳ hào nhoáng khác nhau. Để vận dụng chiến lược “Cloud hóa” một cách hiệu quả, các doanh nghiệp cần chú ý phương án đầu tư thông minh, nhằm tăng tính cạnh tranh trước mắt cũng như cần có tầm nhìn để chiếm lĩnh vị trí tốt khi chu kỳ trên đi vào con dốc khai sáng và bình địa của sự phát triển. Các doanh nghiệp cần có một chiến lược dịch chuyển lên Cloud được chuẩn bị bài bản, bao gồm ba mảng. Đầu tiên, doanh nghiệp cần định vị vị trí hiện tại trong bản đồ trưởng thành của Cloud. Sau đó, doanh nghiệp cần kiến trúc lại hệ thống và ứng dụng theo đúng chuẩn nền tảng Cloud để ngay cả khi chưa dịch chuyển lên Cloud, những đầu tư vẫn đi đúng hướng, hạn chế đầu tư vào những hướng không thể dịch chuyển. Cuối cùng, doanh nghiệp sẽ xác định những chiến lược R nào phù hợp cho mỗi loại ứng dụng. Việc chuyển đổi lên Cloud giờ đây không chỉ là một xu hướng tạm thời mà là một bước ngoặt quan trọng trong quá trình phát triển của doanh nghiệp. Sự chuẩn bị kỹ lưỡng và chiến lược đúng đắn sẽ giúp doanh nghiệp tận dụng tối đa lợi ích của Cloud, mở ra những cơ hội mới và vững vàng tiến vào tương lai số hóa. Tại Việt Nam, con đường sử dụng Cloud Migration còn trải rộng phía trước, tất cả bắt đầu bằng tấm bản đồ chỉ đường cho chiến lược dịch chuyển Cloud hóa cần có ngay từ hôm nay. Xem thêm tại: https://www.youtube.com/watch?v=2Dgdg4gry90&t=50s Liên hệ với chúng tôi để được tư vấn chi tiết về các giải pháp, dịch vụ của FPT Cloud Hotline: 1900 638 399 Email: [email protected] Support: m.me/fptsmartcloud

FPT ArgoCD được xây dựng để khởi tạo và quản lý ArgoCD thông qua giao diện FPT Cloud Portal. ArgoCD là một công cụ mã nguồn mở dùng để triển khai các ứng dụng trên Kubernetes. Dịch vụ cho phép các nhóm phát triển quản lý và triển khai các ứng dụng mà không cần phải tìm hiểu nhiều về Kubernetes. Trong phiên bản cập nhật V1.1 của FPT AgroCD bao gồm: - Quản lý Admin Account - Tích hợp quản lý user thông qua việc cấu hình OIDC tích hợp với hệ thống SSO của người dùng. - Support version v2.8.7, v2.9.0, v2.9.1, v2.9.2, v2.9.3 - Hỗ trợ enable applications set phục vụ người dùng tạo/update multiple applications - Hỗ trợ enable và cấu hình notifications Quản lý Admin Account, Anonymous user User có thể thực hiện enable/disable admin account, anonymous user. Thực hiện thay đổi password của admin account để đăng nhập vào argocd instance Cấu hình  OIDC Scope phục vụ tích hợp SSO User có thể tích hợp OIDC với hệ thống SSO như keycloack để quản lý user đăng nhập vào ArgoCD instance. Hệ thống cho phép người dùng enable/disable chức năng cấu hình OIDC: Sau khi enable OIDC hệ thống cho phép người dùng thêm mới một OIDC config: Thực hiện chỉnh sửa cấu hình sau khi đã thêm mới: Thực hiện xoá OIDC khi không sử dụng: Thực hiên enable Applications set phục vụ tạo applications User có thể thực hiện enable/disable chức năng Applications set: Thực hiện cấu hình Notifications User có thể thực hiện cấu hình notifications để gửi thông báo khi applications có sự thay đổi. User có thể thực hiện enable/disable chức năng notifications Cấu hình channel để gửi thông báo khi có sự thay đổi tới telegram/email/slack Thực hiện thay đổi thông tin đã cấu hình Thực hiện xoá channel nếu không muốn sử dụng Upgrade Versions User có thể thực hiện tạo/upgrade version argocd instance lên một số version khác nhau bao gồm: v2.8.7, v2.9.0, v2.9.1, v2.9.2, v2.9.3

Kafka là một nền tảng distributed event streaming cho phép người dùng thu nhận và xử lý các event, message real time. Nó hoàn toàn có thể là xương sống cho ngành bán lẻ nơi mà khách hàng luôn cần thông tin và phản hồi ngay lập tức kể cả trong việc xem hàng, mua hàng hay thanh toán. Nó cũng có thể là phần hậu phương đủ lớn cho việc phân tích, xử lý data với các nền tảng IOT, big data. Vậy thì, để làm được những điều phi thường đó, kafka đã làm như thế nào? Từ đâu mà Kafka được tạo nên? Kafka được vận hành trên ý tưởng về async programing và message driven programing. Ý tưởng về async programing sinh ra nhằm giải quyết bài toán khi có nhiều services trong 1 hệ thống cùng contact lẫn nhau, services A và B cùng gọi tới service C thì cái nào sẽ được giải quyết trước? Cũng như con người, khi 2 người cùng đưa ra yêu cầu tới một nhân viên chăm sóc KH, họ giải quyết cho KH A mất thời gian quá lâu sau đó tới giờ nghỉ trưa thì KH B có thể tới ngày hôm sau mới được chăm sóc, hoặc mất luôn KH B. Để giải quyết bài toán đó có 2 cách. Cách số 1: tăng thêm nhân viên chăm sóc KH. Điều này sẽ dẫn tới phối hợp 1 – 1 và làm cho công ty không scale được khi có thêm KH. Cách số 2 cũng là cách mà async programing based trên: cho phép xử lý song song cả 2 request bởi cùng 1 người. Điều này sẽ tránh được việc blocking request. Cụ thể, async programming là cách tách biệt giữa request và response giữa các services: Service A request tới service B Service C request tới service B Service B nhận 2 request, phản hồi lại với A và C là đã nhận request Service B xử lý request A và C tùy cái nào tới trước sau đó response lại Service A và C trong lúc chờ đợi sẽ tiếp tục gửi request tới service B và cuốn chiếu tracking response trở về. Ý tưởng về asynchronous programming không phải toàn năng, nó sẽ gặp vấn đè nếu server chung (ví dụ như service B) quá tải và ngừng hoạt động. Lúc đó service C hay A sẽ phải retry gửi lại request và càng lúc càng bị đầy request lên. Vấn đề thứ 2, async giải quyết được 1 service nhận nhiều request, nhưng không tính tới tình huống 1 request gửi đi nhiều service khác nhau và track response. Đó là lúc có message driven programing ra đời. Message-driven programing là lập trình điều hướng các message. Khi có nhiều request từ nhiều services có nhu cầu gửi tới nhiều servies khác, sẽ phải có 1 cái gì đó điều phối ở giữa để đảm bảo tất cả các request đều tới đích và nhận được response phù hợp. Client và server sẽ không giao tiếp trực tiếp với nhau nữa, 2 service cũng không thông trực tiếp với nhau mà sẽ qua 1 bên điều phối thứ 3 gọi là message broker. Message broker bản thân như một môi giới trong bất kỳ ngành nghề gì, kết nối người mua - người bán một mặt hàng nào đó với nhau. Cùng 1 lúc 1 môi giới BĐS có thể đưa 10 KH khác nhau match với 10 căn nhà khác nhau thành công. Message broker cũng như vậy, tiếp nhận message từ client, từ services, từ KH, từ mọi nguồn và phân phối nó tới chỗ nó cần tới trong 1 system. Trên thị trường có rất nhiều message broker như RabbitMQ, ActiveMQ thậm chí là Redis, nhưng, Kafka Apache có những unique selling point nếu so sánh với phần đông thị trường. Không chỉ phân phối được message (như mọi loại message queue), Kafka có các lợi thế sau  nếu so sánh với các loại sản phẩm khác: Đảm bảo việc gửi nhận không bị gián đoạn Có cơ chế xử lý lỗi Performance cao High availability Scalability          Dựa trên các ý tưởng trên, Kafka được phát triển ra và khẳng định sức mạnh của mình ở khoản performance mạnh mẽ trong việc điều phối data. Tiếp theo sẽ là cách mà kafka vận hành. Các thuật ngữ trong Kafka Để hiểu cách Kafka vận hành, có 2 loại khái niệm cần phải nắm được. Loại khái niệm đâu tiên chia theo chiều đi của message: message được gửi từ đâu tới đâu. Chiều thứ 2 là kafka có những component nào để vận hành. Khái niệm theo cách thức vận hành: Topic: Là các luồng data chạy trên kafka (bản chất là 1 chuỗi các message chạy liên tục). Các topic được chia thành các partition và các message được lưu thành các offset trên partition (xem mục partition và offset). Một topic sẽ có các đặc điểm sau: Xếp hàng: Khi có event/message mới ghi vào topic, message/event đó sẽ được nối vào cuối log của topic. Bất biến: Message/event được ghi vào sẽ không thể bị chỉnh sửa. Tuần tự: Consumer (tham khảo ở dưới) sẽ đọc log bằng cách đi tìm các offset và đọc các entries ghi theo lượt tuần tự Nhân bản: mỗi topic của kafka luôn là multi-producer và multi-subscriber: tức là cùng 1 lúc 1 topic có thể có nhiều nguồn gửi data vào và nhiều nguồn hứng data trong pipeline Không giống như các hệ thống stream message khác, dữ liệu trên kafka sẽ không bị xóa đi sau khi đã truyền tới đích. Thay vào đó, kafka cho phép setup thời hạn expired data khi data đạt tới độ lớn hoặc một khoảng thời gian nhất định Offset: Message khi chảy vào 1 topic sẽ được lưu vào thành offset của 1 partition. 2 message khi chảy vào có thể ghi thày cùng 1 offset và cùng 1 offset có thể ghi ở nhiều partition khác nhau. Thứ tự của 1 offset chỉ được đảm bảo trong cùng 1 partition Ví dụ: trong cùng partition 1, message có offset = 5 chắc chắn đến sau message có offset = 4. Producer: Là nơi tạo ra data/message/event cho các topics của Kafka (write). Các “producer” sẽ kiểm soát dữ liệu nào sẽ đi vào “partition” nào trong 1 topic. Rule phân bổ là theo round-robin để cân bằng tải hoặc theo rule set stream theo event key Consumer: Là nơi hứng các data/message/event sinh ra topics của Kafka (read). Thông thường, một consumer sẽ phải đọc 1 bản ghi sinh ra 1 cách tuần tự, tuy nhiên, kafka cho phép kiểm soát thứ tự bản ghi theo từng người dùng, dẫn tới việc mỗi consumer hoàn toàn có thể nhảy cóc thứ tự đọc nhằm đảm bảo tính real time của dữ liệu VD: 1 consumer có thể tái sử dụng 1 bản ghi cũ để làm bản ghi mới hoặc có thể nhảy cóc qua các bản ghi đang sinh ra để đọc bản ghi gần nhất và ngay lập tức sử dụng bản ghi đó Một Kafka consumer có thể vào đọc và sử dụng tài nguyên mà không ảnh hưởng tới cluster của các consumer khác.       Kết luận lại: multi-producers sẽ tạo (writre) ra nhiều message/event/data đẩy vào trong topic. Data đó sẽ được lưu thành các offset. Multi-consumer/subscriber vào check offsets để đọc (read), sau đó sẽ xử lý tiếp request. Tiếp đến, kafka có các khái niệm bổ dọc theo tầng hệ thống: Partition: Các partition là các phần nằm bên trong 1 topic cho phép khi có nhiều offset cùng vào topic tại một thời điểm, các offset sẽ được chia cho nhiều partition để phân phối tới consumer. Một partition sẽ độc lập với các partition khác. Số lượng partition cho mỗi topic thì tuỳ theo nhu cầu của ứng dụng do người dùng quy định. Trong mỗi partition sẽ lưu nhiều offset, số lượng offset của mỗi partition có thể là khác nhau, tùy vào rule phân phối đã set vd theo round-robin hoặc event key rule. Broker: Message được lưu tại offset của partition, partition lưu ở trong topic. Các topic sẽ được lưu trên kafka broker Bản thân 1 broker của kafka là 1 server nằm trong cụm cluster của kafka để lưu trữ dữ liệu Thông thường theo mô hình truyền thống, 1 kafka server sẽ tương ứng với 1 cụm cluster dựng trên máy chủ vật lý. Khi server này chết thì toàn bộ dữ liệu sẽ mất cùng với nó luôn. Đây gọi là single-point failure. Cụm cluster Kafka sẽ phân tán các partition của cùng 1 topic ra nhiều broker nhất có thể để đảm bảo khi có 1 con broker chết, sẽ có con khác backup và giải quyết vấn đề không bị gián đoạn hệ thống Tuy nhiên, việc chia broker và partition vẫn chưa giải quyết được hết single point failure do nếu data store trên 2 broker và cả 2 con cùng ngừng hoạt động thì bản chất vẫn là single point. Do đó, Kafka có khái niệm thứ 3: replication. Replication: Là bản sao của topic ở trên 1 broker sang 1 broker khác VD: Có 3 topic và 3 brokers Topic A lưu ở broker 1 và 2 Topic B lưu ở broker 2 và 3 Nếu broker 1 và 2 ngừng hoạt động thì Topic A cũng sẽ ngừng hoạt động Do đó, kafka sẽ có replica topic A sang broker 3 để hệ thống vẫn stream bình thường. Tương tác với topic B rồi C Trên 1 broker sẽ có lưu 1 phần topic này và replica của topic kia để đảm bảo khi có 1 broker hoặc 1 cụm broker ngừng hoạt động thì vẫn sẽ có bản lưu ở 1 chỗ nào đó khác. Kafka vận hành ra sao Bên trên là một số các khái niệm cơ bản khi tìm hiểu về kafka. Tiếp theo, bài viết sẽ giới thiệu cụ thể cách kafka vận hành: Input data from producers Đầu vào của hệ thống nằm ở producer tạo ra (write) message gửi vào các topic trong cụm kafka cluster. Lập trình viên sẽ setup để producer write vào topic nào và dừng lại ở đó. Khi có message vào, producer tự động biết nên write vào broker nào và partition nào. Nếu ghi fail thì sẽ có cơ chế retry thành công Việc “tự động” write được vào partition nào là do cơ chế round-robin của kafka: Có 3 brokers: message đầu tiên sẽ vào broker 1, message thứ 2 vào broker 2, message thứ 3 vào broker 3, message 4 sẽ vào broker 1,… Khi write vào partition, có cơ chế acks (acknowledgment) để báo producer biết message đã gửi thành công. Ack có 3 states: Acks = 0: producer gửi message và không chờ phản hồi (có thể dẫn tới mất data) Acks = 1: producer chờ tới khi nhận được phản hồi nhưng không lưu lại message sau khi write thành công. State này dẫn tới nếu broker đó chết, message sẽ mất theo Acks = 2: producer chờ nhận phản hồi và chắc chắn phản hồi đã được lưu lại trên broker chính và toàn bộ các bản replica (sẽ có ảnh hưởng tới performance do phải chờ response write data thành công) Processing data Kafka implement message bằng cách chỉ định 1 replication bất kỳ làm leader. Cơ chế này là leader partition concept. Tại một thời điểm, mỗi partition có duy nhất 1 replication leader, các replication còn lại là ISR – In sync replica sẽ đồng bộ lại data đã ghi ở leader. Nếu replication leader ngừng hoạt động, hệ thống tự động chỉ định 1 ISR bất kỳ đứng lên làm leader. Việc chỉ định này được thông qua thuật toán của Kafka Zookeeper. Với khái niệm replication như trên, 1 partition sẽ được nhân bản (replicate) lưu trên nhiều broker khác nhau. Vậy thì, khi producer write được data vào topic, data này bản thân được lưu ở đâu, lưu vào bản replica nào, theo rule gì? Kafka Zookeeper là core dùng để quản lý metadata của kafka. Metadata này bao gồm: Toàn bộ các action phát sinh trong hệ thống: CRUD topics, crud brokers, crud partitions, status,…. Brokers nào nằm ở cụm kafka cluster nào Configuration, permissions của các topics Việc kiểm soát các metadata này cho phép zookeeper tính toán để chỉ định các replication leader và ISR cũng như điều phối để các broker hoạt động một cách bình thường. Khi các broker được điều hướng để hoạt động, các messages khi producers write xuống các topics sẽ được đảm bảo được tính tin cậy và bền vững. Các message được write thành các offset xếp theo thứ tự trên partition trong một topic lưu trên 1 broker và được replica sang các ISR khác. Tiếp theo, consumer sẽ vào để “sử dụng” các offset này. Consume messages Các consumer đọc message từ topic theo topic name. Tuy nhiên, như đã mô tả phía trên, 1 broker sẽ có các replica để store topic, vậy nên consumer sẽ đọc theo leader replication. Tiếp đến, nếu quá trình read gặp lỗi,  kafka có cơ chế tự phục hồi để đảm bảo dữ liệu tới nơi toàn vẹn. Việc đọc của consumer sẽ diễn ra tuần tự trong 1 partition, offset nào tới trước sẽ được đọc trước. Một consumer có thể đọc nhiều message trong nhiều partition khác nhau trong 1 topics. Do thứ tự message trong partition không thay đổi thứ tự nên khi read từ nhiều partition sẽ có những tình huống consumer đọc offset = 3 ở partition 1 - trước khi đọc được offset = 1 ở partition 3. Tuy nhiên, kafka cho phép xử lý multi – multi, tức là multiple message được read bởi multiple consumer. Nếu như chỉ có 1 consumer đọc toàn bộ message của toàn bộ các partition thì sẽ xảy ra tình trạng quá tải. Vậy nên, kafka giải bài toán đó thông qua consumer group. 1 consumer group sẽ nhận toàn bộ data của các partition và chia cho các consumer bên trong quản lý. Mỗi consumer trong 1 group sẽ đọc toàn bộ data của một hoặc nhiều partition để đảm bảo messasge ordering. Một consumer có thể read message từ nhiều partition nhưng 1 partition sẽ không thể gửi message cho nhiều consumer trong 1 group. Cơ chế consumer group sinh ra nhằm đảm bảo không có consumer nào bị quá tải khi nhận message từ brokers. Tổng kết lại message được sinh ra từ 1 producer, gửi topic. Topic được vận hành bởi các broker, trên các broker sẽ có replication leader của topic này và các ISR của topic khác. Việc phân phối chỉ định leader do Kafka Zookeeper phân phối. Message từ producer sẽ được ghi thành các offset trên partition trong topic. Consumer group nhận toàn bộ message từ partition và phân phối cho các consumer bên trong để sử dụng. Toàn bộ cơ chế trên chính là việc implement queue và topic trong message broker. Có 2 dạng phân phối message khi nói về message broker là queues (point-tpoint messaging) và topic (broadcast messaging) Queue: là 1 dạng phân phối message quan hệ 1 – 1 (point to point messaging) giữa client và server (hoặc giữa các services). Mỗi message chỉ có 1 đầu vào và 1 điểm tới. Bản thân queueing trong kafka chính là việc message từ 1 topic A (bất kể có bao nhiêu partition) sẽ chỉ được gửi tới 1 consumer group B (bất kể có bao nhiêu consumer) Broastcast messaging: một message được gửi tới nhiều địa chỉ, chỉ khi subscribe địa chỉ thì mới nhận được message đó. Trong kafka, khái niệm này chính là dạng 1 topic gửi message tới nhiều consumer groups. Consumer nào subscribe topic mới read được message đó. Bên trên là toàn bộ các khái niệm cũng như basic cách kafka apache vận hành. Bằng cách cung cấp service Kafka, FPT Smart Cloud đồng thời cung cấp toàn bộ những ưu điểm của kafka apache như sự ổn định, tính bền vững và khả năng scaling cũng như performance mạnh mẽ của nền tảng này. Đăng ký sử dụng thử miễn phí ngay: https://fptcloud.com/lien-he/   Nguyễn Quý Hiếu

Trong việc phát triển phần mềm kỹ thuật nói riêng và khi bàn về công nghệ nói chung, cụm từ Kafka thường hay xuất hiện như là một giải pháp truyền dữ liệu real time (thời gian thực). Hiểu một cách đơn giản là khi 1 khách hàng đang mua hàng trên 1 app di động, để họ xem được mặt hàng, gửi đơn hàng tới các bên xử lý một cách nhanh nhất thì luồng dữ liệu đi dưới hệ thống phải được thông suốt càng nhanh càng tốt mà không phải chờ đợi. Nếu chỉ có một khách hàng giao tiếp với một hệ thống thì sẽ không có chuyện gì để bàn. Nhưng khi có cả triệu khách hàng giao tiếp cùng lúc với một hệ thống, số lượng data truyền xuống từ một khách hàng là vô cùng lớn, chưa kể trong 1 hệ thống thường được cấu thành bởi vô vàn các services, các component khác nhau. Bài toán lúc này không nằm ở việc app đầy đủ thông tin hay được trang điểm đẹp đẽ, mà trở thành làm thế nào để cả triệu khách hàng cùng nhận được thông tin một cách nhanh chóng? Vào ngày 11 tháng 1 năm 2011, Kafka Apache ra đời để giải quyết bài toán trên. Vậy Kafka là gì, FPT Smart cloud cung cấp giải pháp gì liên quan tới Kafka Apache? Kafka là gì? Kafka là một nền tảng phân phối sự kiện dữ liệu (message and event) cho phép: Publish và subscribe các luồng sự kiện, message (event stream) Lưu trữ, xử lý và phân phối dữ liệu thời gian thực Để hiểu được việc phân phối dữ liệu, sự kiện (distributed event streaming) thì trước hết cần hiểu 1 sự kiện (event) là 1 bản ghi 1 action trong hệ thống. Ví dụ khi 1 khách hàng vào app thì sẽ sinh ra 1 event như sau: eventKey: “FPT_Cloud_Kafka” eventValue: “Open Application” EventTimestramp: “Aug.25.2023.13:06” Event được định nghĩa bởi: user – action – time. Việc phân phối dữ liệu, sự kiện sẽ bắt đầu từ khi bắt được các event như ví dụ trên từ nhiều nguồn khác nhau như database, app mobiles, cloud services, backend services, software application,… Một nền tảng streaming dữ liệu sẽ bắt được các event theo thứ tự và xử lý các dữ liệu này trước khi đưa vào lưu trữ tập trung một cách real time để có thể sử dụng về sau (có thể là ngay lập tức). Các event này sẽ được đưa vào các stream pipeline - các luồng đi của dữ liệu được dựng lên. Dòng chảy này sẽ có các đặc tính sau: Toàn vẹn dữ liệu: dữ liệu từ lúc tiếp nhận cho tới khi đến đích phải nguyên vẹn Thời gian thực: dữ liệu truyền đi ngay khi event được sinh ra Đúng địa chỉ: dữ liệu sẽ phải được truyền tới đúng đích đã setup. Để làm được điều này Kafka sẽ được dựng trên một cụm cluster trải dài trên nhiều trung tâm dữ liệu (datacenter) và cung cấp các chức năng của nó theo cách phân tán (distributed), khả năng mở rộng và đàn hồi cao (scalable and elastic) cũng như khả năng chịu lỗi tốt và vô cùng bảo mật. Kafka có thể được dựng trên máy chủ vật lý, trên máy trạm ảo, trên các container của K8S hoặc tối ưu nhất là trên các nền tảng cloud. >>> Xem thêm: Platform là gì? 10 mô hình platform nổi bật và linh hoạt Lợi ích khi sử dụng Kafka Sử dụng Apache Kafka mang lại nhiều lợi ích cho việc xây dựng và triển khai các hệ thống xử lý dữ liệu thời gian thực và streaming. Dưới đây là một số lợi ích chính khi sử dụng Kafka: Xử lý Dữ liệu Thời gian thực: Kafka được thiết kế để xử lý dữ liệu thời gian thực và streaming, cho phép bạn đáp ứng nhanh chóng đối với sự kiện mới xảy ra. Điều này rất hữu ích cho việc giám sát, phân tích, và ứng phó tức thì với các tình huống thay đổi. Tính Nhất quán và Độ Tin cậy Cao: Kafka giữ cho bạn tính nhất quán dữ liệu thông qua quá trình sao lưu và sao chép thông điệp giữa các broker. Điều này đảm bảo dữ liệu không bị mất mát và luôn sẵn sàng cho các ứng dụng tiêu thụ. Mở Rộng Dễ Dàng: Kafka có khả năng mở rộng dễ dàng bằng cách thêm các broker vào cluster. Điều này cho phép bạn tăng khả năng xử lý dữ liệu mà không cần thay đổi cấu trúc toàn bộ hệ thống. Dữ liệu Đa Dạng: Kafka không chỉ hỗ trợ dữ liệu thông thường mà còn có khả năng xử lý dữ liệu đa dạng như logs, trạng thái ứng dụng, sự kiện liên quan đến giao dịch tài chính, và nhiều loại dữ liệu khác. Khả năng Chia Lượng Lớn: Nhờ việc sử dụng phân vùng (partitioning), Kafka có khả năng xử lý lượng dữ liệu lớn một cách hiệu quả. Điều này làm cho nó phù hợp cho các tình huống cần xử lý hàng tỷ sự kiện mỗi ngày. Tích hợp linh hoạt: Kafka có khả năng tích hợp với nhiều công nghệ và ứng dụng khác. Bạn có thể sử dụng các ngôn ngữ lập trình khác nhau để viết các ứng dụng producer và consumer, và Kafka cũng hỗ trợ các giao thức truyền tải khác nhau. Lưu trữ Dữ liệu Lâu Dài: Ngoài việc xử lý dữ liệu thời gian thực, Kafka cũng có khả năng lưu trữ dữ liệu lâu dài. Điều này cho phép bạn lưu trữ và truy xuất lại dữ liệu sự kiện trong tương lai để phân tích và kiểm tra. Hệ Thống Log: Kafka hoạt động như một hệ thống log, cho phép bạn lưu trữ và tìm kiếm thông tin sự kiện theo thời gian. Điều này rất hữu ích cho việc gỡ lỗi, phân tích dữ liệu và theo dõi hoạt động hệ thống. Nhược điểm của Kafka Phức Tạp trong Cài Đặt Ban Đầu: Cài đặt và cấu hình ban đầu của Kafka có thể phức tạp đối với những người mới bắt đầu sử dụng. Yêu Cầu Hiểu Biết Sâu về Hệ Thống: Để triển khai và quản lý Kafka hiệu quả, cần có kiến thức về hệ thống và mạng. Yêu Cầu Tài Nguyên: Kafka yêu cầu một số lượng tài nguyên tương đối lớn để hoạt động tốt, bao gồm bộ nhớ và khả năng xử lý. Khó Để Hiểu và Sử Dụng Cho Người Mới: Với những người mới sử dụng, Kafka có thể đầy thách thức và yêu cầu thời gian để hiểu rõ về cách làm việc của nó. Không Phải Là Giải Pháp Tất Cả Các Trường Hợp Sử Dụng: Mặc dù Kafka rất mạnh mẽ, nhưng nó không phải là giải pháp phù hợp cho tất cả các tình huống. Có những trường hợp sử dụng khác có thể phù hợp hơn. Khả Năng Quản Lý Dữ Liệu Lâu Dài Hạn: Mặc dù Kafka có thể lưu trữ dữ liệu lâu dài, nhưng việc quản lý và tìm kiếm dữ liệu trong các phiên bản sau này có thể đòi hỏi công việc phức tạp và tài nguyên. >>> Xem thêm: Sandbox là gì? Cách thức thiết lập Sandbox vào ứng dụng Usecases Kafka là một nền tảng streaming dữ liệu thời gian thực. Vì thế, nó đượng ứng dụng một cách rộng rãi trong nhiều ngành nghề và tổ chức. Kafka as a messaging system Trong ngành tài chính, các khoản payment và transactions khi phát sinh sẽ yêu cầu tốc độ xử lý càng nhanh càng tốt. VD: KH có nhu cầu rút tiền, process này diễn ra chỉ trong khoảng 5 – 10s sau khi nhập hết thông tin order VD: trong chứng khoán, giá của các mã chứng khoán thay đổi trong thời gian thực và nó ảnh hưởng trực tiếp tới giá trị giao dịch của cả ngàn KH một lúc Kafka lúc này sẽ được cài đặt và tinh chỉnh để trở thành 1 hệ thống truyền các message qua lại giữa nhiều hệ thống khác nhau VD: dữ liệu giá từ sở giao dịch tới công ty chứng khoán, dữ liệu mã chứng khoán từ trung tâm lưu ký tới công ty chứng khoán và ngân hàng Nếu không có kafka, các message sẽ có độ trễ, dẫn tới việc giao dịch có thể bị mất do lúc đó giá trị giao dịch không còn chính xác. Kafka as activity tracker Trong khối ngành logistic, một bài toán đặt ra là phương tiện chuyên chở đang đi tới đâu, bao lâu nữa tới nơi. Việc di chuyển diễn ra liên tục dẫn tới nhu cầu kiểm soát đước hoạt động này trở nên khó khăn VD: Đặt 1 course taxi, người dùng sẽ muốn biết xe đang tới đâu để có thể căn thời gian chuẩn bị, di chuyển tới điểm đón. Việc căn thời gian, đường đi này cần track được đường có đang tắc ở đâu không, có vướng mắc gì trên đường đi hay không Kafka as data processing Với trending nhà thông minh, việc ứng dụng IOT (internet on things) trở nên phổ biến hơn bao giờ hết. Để vận hành được thì các vật dụng cảm biến (sensor) trong nhà sẽ cần phải thu thập ược dữ liệu, sau đó phân tích xử lý dữ liệu đó trước khi truyền tới hệ thống để có action tiếp theo. VD: Khi người dùng nói: “Bật đèn”, micro hứng trong nhà sẽ phải bắt được câu “bật đèn”, xử lý dữ liệu để dịch ra ngôn ngữ hệ thống: eventKey: “guest” eventValue: “turn on the light” EventTimestramp: “Aug.25.2023.13:06” Sau khi xử lý xong, hệ thống sẽ truyền dữ liệu này tới bộ xử lý IOT. Bộ xử lý IOT sẽ truyền action tương ứng tới hệ thống điện trong nhà để bật đèn. Kafka sẽ cho phép quá trình thu thập và xử lý data xảy ra một cách nhanh nhất trước khi truyền dữ liệu đi. Nếu không có ứng dụng này, người dùng bình thường có thể mất tới vài lần nói thật to may ra mới bật được đèn một cách tự động Trong tương lai, việc phân tích và xử lý data có thể tiến tới tầm cao mới. Ví dụ như camera nhìn thấy sắc mặt của chủ nhà để bật nhạc tùy tâm trạng. Để xử lý được khối dữ liệu khổng lồ này thì sẽ cần một nền tảng đủ mạnh như kafka. Tiến tới xa hơn thì kafka hoàn toàn có thể làm xương sống cho việc xử lý big data của các công ty với khả năng xử lý dữ liệu của mình Ngoài 3 usecase chính về streaming message real time, tracking activity và xử lý data, Kafka còn nhiều ứng dụng khác như connect và storage dữ liệu, stream processing vv. Từ khi ra đời tới nay, Kafka đã giúp thay đổi bộ mặt của nhiều ngành nghề cũng như ảnh hưởng lớn tới việc số hóa dữ liệu, quy trình và sản phẩm. Nhưng để thực sự hiểu và dựng được lên một cụm cluster kafka thì một người dùng sẽ phải quan tâm tới nhiều khía cạnh khác như tài nguyên, vận hành, cài đặt cũng như theo dõi sửa lỗi, nâng cấp. Những bài viết liên quan: Server là gì? Phân loại & Vai trò của máy chủ server Server Rack là gì? Server Rack loại nào tốt nhất? Blade Server là gì? Toàn tập kiến thức Blade Server từ A – Z Addon Domain là gì? Cách tạo & thêm addon Domain vào hosting Nắm được nhu cầu đó, FPT Smart Cloud cung cấp giải pháp Kafka as a service, đáp ứng được toàn bộ yêu cầu về mặt bảo mật, scaling, high availability, cài đặt, vận hành cũng như có nhiều tính năng bổ trợ để phân quyền, quản lý kafka dễ dàng. Giải pháp FPT Cloud Kafka as a Service sẽ giúp các Developer có thể tự động hóa hoàn toàn việc quản lý, duy trì và mở rộng các cụm Apache Kafka mà không tốn công sức triển khai, dễ dàng quản lý giúp tối ưu chi phí tài nguyên, nguồn lực. Đăng ký sử dụng thử miễn phí ngay: https://fptcloud.com/lien-he/ Nguyễn Quý Hiếu

Bà Điệp khẳng định FRT sẽ tiếp tục mở mới 400-500 cửa hàng Long Châu trong năm 2023. Sau dược phẩm, FRT có thể nhắm đến một số ngành bán lẻ vừa triển vọng lại an toàn như ăn uống, hàng tiêu dùng, mẹ và bé… "Trước khi tham gia, chúng tôi mới chỉ nhìn thấy mảng thị trường nhà thuốc còn manh mún, nhỏ lẻ, chưa thấy ai mang lại dịch vụ chuyên nghiệp cho khách hàng nhưng khi nhập cuộc, chúng tôi nhận thấy có một số thứ có thể thay đổi, góp ích cho nền dược phẩm nước nhà và đó chính là con đường dài để Long Châu tiếp bước", bà Nguyễn Bạch Điệp – Chủ tịch FPT Retail, Tổng giám đốc FPT Long Châu chia sẻ. Trong năm 2022, Long Châu đạt được những cột mốc cực kỳ ấn tượng gồm đạt mốc 1.000 cửa hàng, 5 triệu khách hàng đến mua sắm/tháng; hơn 2,5 triệu khách hàng mua sắm trên nền tảng trực tuyến/ tháng trong khi ứng dụng Nhà thuốc FPT Long Châu cũng cán mốc hơn 2 triệu người dùng sau 1 năm ra mắt. Với Long Châu nói riêng và FPT Retail nói chung, 2023 sẽ là một năm như thế nào? Tôi cho rằng khó khăn có thể tiếp tục kéo dài đến giữa năm sau, thậm chí là hết năm. Với tình hình đó, người dân sẽ thắt chặt chi tiêu, tập trung vào các mặt hàng thiết yếu hơn. Đứng trước tình hình khó khăn này, FPT Long Châu càng chú trọng mục tiêu mở rộng, đến gần hơn nữa với người dân để mang đến những sản phẩm chất lượng với giá thật rẻ. FPT Long Châu sẽ vẫn là động lực tăng trưởng của FRT trong thời gian tới. Chúng tôi sẽ tiếp tục mở rộng chuỗi, dự kiến sẽ mở thêm 400-500 cửa hàng trong năm 2023. FRT cũng sẽ tiếp tục chuyển đổi số mạnh mẽ, ứng dụng công nghệ vào hoạt động của cả 2 chuỗi FPT Shop và FPT Long Châu nhằm gia tăng trải nghiệm khách hàng. Long Châu đã bứt lên rất nhanh trong năm 2022, đâu là động lực cho điều này? FPT Retail đã nhìn ra được điều gì ở bức tranh thị trường bán lẻ dược phẩm Việt Nam? Nói về động lực, thứ nhất, việc mở mới số cửa hàng Long Châu vượt kế hoạch có thể nói là như đang ở đà tiến lên. Trong quá trình triển khai, công ty nhận được sự hỗ trợ lớn của Tập đoàn về mặt công nghệ, nhiều quy trình được tự động hoá. Khi đi vào guồng thì sự phối hợp giữa các bộ phận, phòng ban nhuần nhuyễn hơn. Vì vậy, Long Châu quyết định tăng tốc luôn. Động lực thứ hai là FPT Retail nhìn thấy tiềm năng từ thị trường. Ở Việt Nam, số lượng các nhà thuốc nhỏ lẻ lên tới gần 60.000, vì vậy dư địa để mở rộng chuỗi Long Châu còn rất lớn. Đặc biệt là ở những nơi vùng sâu, vùng xa, người dân còn ít tiếp cận với các cửa hàng thuốc đầy đủ nhóm sản phẩm. Con số 1.000 gần như chốt cho năm 2022 nhưng chúng tôi sẽ không dừng lại. Chiến lược mở rộng vẫn là chiến lược chính trong năm 2023 với dự kiến mở mới 400-500 cửa hàng. Theo số liệu của Tổng cục Thống kê, dân số Việt Nam đang già đi với tốc độ gia tăng, kết hợp với tỷ lệ sinh thấp sẽ dẫn đến tỷ lệ người già trên 65 tuổi vào năm 2055 tăng cao. Trong khi đó, Quỹ tiền tệ quốc tế IMF đã dự báo, đến năm 2025, Việt Nam sẽ vươn lên đứng thứ 3 Đông Nam Á về quy mô kinh tế, với mức GDP chỉ xếp sau Indonesia và Thái Lan, vượt qua Malaysia, Philippines và Singapore. Mức sống nâng cao và cơ cấu dân số già được dự báo sẽ khiến cho người dân ngày càng chú trọng tới việc nâng cao sức khỏe và chi tiêu nhiều hơn cho các sản phẩm thực phẩm chức năng, sản phẩm chăm sóc sức khỏe và vật tư y tế, đồng thời có khuynh hướng sử dụng các sản phẩm dược mỹ phẩm với tiêu chí an toàn cho sức khỏe. Với Long Châu, trước khi tham gia, chúng tôi mới chỉ nhìn thấy mảng thị trường nhà thuốc còn manh mún, nhỏ lẻ, chưa thấy ai mang lại dịch vụ chuyên nghiệp cho khách hàng. Còn khi nhập cuộc, chúng tôi nhận thấy có một số thứ có thể thay đổi, góp ích cho nền dược phẩm nước nhà và đó chính là con đường dài để Long Châu tiếp bước. Đầu tiên là thuốc chính hãng, được kiểm soát chất lượng, với các chuỗi có hệ thống phần mềm hỗ trợ. Thứ hai là giá thành, việc quản trị bằng phần mềm tối ưu chi phí sẽ giúp hạ giá thành sản phẩm, người dân cũng được hưởng lợi. Và một điều mà tôi nghĩ rất quan trọng là đào tạo nhân viên, tư vấn khách hàng cách uống thuốc đúng, đủ, tránh lạm dụng kháng sinh. Với FPT Shop hay F.Studio trước đây, có thể thấy tốc độ mở mới cửa hàng không quá nhanh nhưng Long Châu là một câu chuyện hoàn toàn khác? Có phải đã có một sự thay đổi trong chiến lược kinh doanh của FPT Retail? Đầu tiên cần kể đến là quyết tâm làm và phải làm được của ban lãnh đạo và sự đồng lòng của CBNV. Kế đến, có thể nói, kinh nghiệm về xây dựng và phát triển chuỗi bán lẻ FPT Shop đã đem lại rất nhiều lợi thế cho FRT khi phát triển chuỗi dược. Khi mở rộng chuỗi Long Châu thì FRT đã chuyển nguồn lực từ FPT Shop sang. Ngoài ra, FRT còn được hỗ trợ thêm nguồn lực tài chính và công nghệ từ Tập đoàn FPT. Ngoài ra, chúng tôi phân công rõ ràng nhiệm vụ từng người. Tại FRT, người nào giữ trận, người nào mở cõi đều được xác định rõ, điều này giúp Công ty duy trì và tăng trưởng ở mảng cũ cũng như mở rộng được mảng mới. Long Châu lấy gì làm lợi thế cạnh tranh với các đối thủ (cửa hàng nhỏ, các hệ thống lớn khác)? FPT Long Châu được đánh giá có định hướng và vận hành đúng với ngành bán lẻ dược phẩm, chuyên về thuốc nhất, sở hữu danh mục sản phẩm đa dạng, đầy đủ nhóm thuốc chất lượng phục vụ người dân. Điều này cho phép Long Châu đáp ứng đủ nhất nhu cầu ngày càng cao về nhu cầu thuốc điều trị bệnh, đặc biệt là thuốc theo đơn bệnh viện các loại thuốc hiếm. Thứ nữa, FPT Long Châu thừa hưởng từ Tập đoàn FPT về phần công nghệ, từ quản trị cửa hàng giúp tối ưu hoá chi phí đến công nghệ phục vụ cho trải nghiệm khách hàng. Chúng ta thấu hiểu khách hàng bao nhiêu thì họ sẽ hài lòng bấy nhiêu. Về lâu dài, Long Châu còn mong muốn chuỗi nhà thuốc sẽ đưa thêm nhiều dịch vụ chăm sóc sức khoẻ tới khách hàng chứ không chỉ là thuốc. Đó chính là khai thác phần trên thượng tầng của lĩnh vực dược phẩm giúp mang lại hiệu quả tăng trưởng lâu bền. Năm 2022, An Khang của TGDĐ đã xác định dừng mở mới ở mốc hơn 500 cửa hàng, trong khi Long Châu đã mở cửa hàng thứ 1.000, khác biệt ở đây là gì? Như đã đề cập, việc mở mới số cửa hàng Long Châu vượt kế hoạch có thể nói là như đang ở đà tiến lên. Trong quá trình triển khai, công ty nhận được sự hỗ trợ lớn của Tập đoàn về mặt công nghệ, nhiều quy trình được tự động hoá. Tất cả những ứng dụng CNTT trong quản trị vận hành đã giúp chuỗi nhà thuốc FPT Long Châu nhanh chóng mở rộng quy mô lên đến 1.000 nhà thuốc trên toàn quốc trong thời gian ngắn. Khi đi vào guồng thì sự phối hợp giữa các bộ phận, phòng ban nhuần nhuyễn hơn. Vì vậy, Long Châu quyết định tăng tốc luôn. Ngoài ra, trong năm 2022, với mục tiêu "mọi hoạt động đều hướng đến khách hàng" được FPT Long Châu vinh dự khi được trao cơ hội phục vụ hơn 5 triệu khách hàng đến chuỗi nhà thuốc mua sắm/ tháng; hơn 2,5 triệu khách hàng mua sắm trên nền tảng trực tuyến/ tháng và hơn 4,2 triệu khách hàng thân thiết luôn đồng hành, tin tưởng lựa chọn trong suốt hành trình phát triển bền vững và đột phá đạt mốc 1.000 nhà thuốc của Long Châu. Trong tháng 12, ứng dụng Nhà thuốc FPT Long Châu chính thức cán mốc hơn 2 triệu người dùng sau 1 năm ra mắt. Đây là phiên bản ứng dụng hiện đại đã được Long Châu cập nhật giúp thân thiện với người dùng, là lựa chọn tối ưu cho khách hàng có thể thực hiện mua sắm các sản phẩm chăm sóc sức khỏe trực tuyến một cách thuận tiện, nhanh chóng nhất và được miễn phí giao hàng trong 3 giờ. Với Long Châu, người ta nhắc nhiều đến "công nghệ hóa chuỗi bán lẻ", bà có thể chia sẻ cụ thể hơn về việc Long Châu đã công nghệ hóa như thế nào? Chuyển đổi số trong bối cảnh số hóa đang là xu thế tất yếu của mọi doanh nghiệp, FPT Long Châu tự hào khẳng định uy tín và chất lượng đằng sau vẻ ngoài của một nhà thuốc truyền thống đã ứng dụng công nghệ thành công với những giải pháp tiên tiến như ứng dụng bán hàng tự động tại điểm bán, hệ thống quản trị logistic giao nhận hàng hoá, hệ thống quản trị tồn kho realtime,... Cụ thể, FPT Retail chuyển đổi thần tốc hệ thống bán hàng: từ POS, SAP truyền thống sang OMS hiện đại và có tính linh hoạt cao hơn. FRT đã đưa toàn bộ hệ thống bán lẻ lên cloud trong thời gian nhanh nhất với dự án thế kỷ "phóng Công ty tỷ đô lên mây", ứng dụng AI thành công trong công thức chia hàng hóa về shop giúp giảm 50% số lượng trường hợp bị stock-out tại cửa hàng. Tất cả những ứng dụng CNTT trong quản trị vận hành đã giúp chuỗi nhà thuốc FPT Long Châu nhanh chóng mở rộng quy mô lên đến 1.000 nhà thuốc trên toàn quốc trong thời gian ngắn. Chuyển đổi số thành công không chỉ giúp tiết giảm chi phí hoạt động sản xuất kinh doanh, tối ưu hóa năng suất mà còn giúp chúng tôi nuôi dưỡng tinh thần đổi mới, sáng tạo, xây dựng nền tảng văn hóa số trong tổ chức và hình thành nguồn nhân lực tài năng - nguồn tài nguyên chiến lược để phát triển bền vững trong nền kinh tế số. Ứng dụng công nghệ số hóa vào hoạt động của chuỗi Nhà thuốc FPT Long Châu là bước tiến vượt bậc và nỗ lực của công ty FRT nói riêng và cả Tập đoàn FPT nói chung trên hành trình sứ mệnh chăm sóc sức khỏe hàng triệu người dân Việt Nam bằng dịch vụ vượt trội, nhanh chóng và tiện lợi. Theo bà, đâu là yếu tố quyết định để Long Châu bứt phá trong 2 năm qua và cả các năm tới? Để FPT Long Châu có được chỗ đứng hiện tại là sự tổng hoà của nhiều yếu tố, có 3 cái chính: Thứ nhất, đó là quyết tâm làm và phải làm được của ban lãnh đạo và sự đồng lòng của CBNV. Thứ hai, kinh nghiệm về xây dựng, vận hành và phát triển chuỗi bán lẻ FPT Shop đã được mang sang chuỗi dược. Thứ ba, nguồn lực sẵn có từ FPT Shop. Khi mở rộng chuỗi Long Châu thì FRT đã chuyển nguồn lực từ FPT Shop sang. Ngoài ra, FRT còn được hỗ trợ thêm nguồn lực tài chính và công nghệ từ Tập đoàn FPT. Với sự hậu thuẫn mạnh mẽ từ "người khổng lồ" FPT - tập đoàn công nghệ hàng đầu Việt Nam, FPT Long Châu sẽ tiếp tục bứt phá dẫn đầu trên hành trình chuyển đổi số, đưa tự động hóa vào quá trình vận hành và tiến tới tự động hóa hoàn chỉnh nhằm khai thác hiệu quả nhất nguồn lực trong lĩnh vực chuỗi bán lẻ dược phẩm nói riêng và ngành Thương mại điện tử nói chung, đáp ứng nhu cầu với chất lượng phục vụ và trải nghiệm tốt nhất cho mọi khách hàng khắp Việt Nam. Long Châu nhìn thấy những điểm đặc thù nào của thị trường bán lẻ dược phẩm Việt Nam? Tại Việt Nam, thị trường bán lẻ dược phẩm có tính phân mảnh rất cao, với gần 60.000 nhà thuốc nhưng hầu hết là cơ sở kinh doanh nhỏ lẻ. Về thói quen của khách hàng, thông thường, khi gặp phải một số triệu chứng bệnh phổ thông như ho, sốt, đau bụng nhẹ,... người tiêu dùng Việt Nam thường có xu hướng tới các nhà thuốc quen thuộc để hỏi dược sĩ và mua thuốc. Trong đó, các tiêu chí được người tiêu dùng sử dụng khi lựa chọn mua thuốc như: Vị trí địa lý nhà thuốc, chất lượng thuốc, giá cả,... Cùng với đó là một số yếu tố để giữ chân người mua như: trình độ chuyên môn của dược sĩ đứng quầy, quá trình tư vấn, chăm sóc sau mua,... Ngoài ra, sau đại dịch Covid-19, hình thức mua hàng cũng đã trở thành một trong những căn cứ quan trọng của người tiêu dùng khi lựa chọn nhà thuốc. Các hình thức đặt hàng online, giao hàng tận nhà, tư vấn online,... trở thành ưu điểm trong mắt khách hàng nhờ vào tính tiện lợi, linh động, tiết kiệm thời gian,... Một số sản phẩm "mùa vụ" trong dịp Covid như laptop, smartphone (các thiết bị phục vụ nhu cầu học tập online, kết nối), dịch vụ Internet đều gặp tình trạng khủng hoảng thừa sau Covid, bà đánh giá thế nào về thị trường thuốc - sản phẩm cũng đã tăng vọt nhu cầu trong đại dịch? Về xu thế, khi đại dịch qua đi, nhóm sản phẩm chống dịch chắc chắn bị khủng hoảng thừa. Tuy nhiên, do đã ứng dụng công nghệ AI vào việc nhập hàng, nên FPT Long Châu vẫn kiểm soát được lượng hàng vào ra hợp lý, không bị ảnh hưởng nhiều. FPT Retail từng nói sẽ mở vài ngàn nhà thuốc trong 3 năm tới, FPT Retail sẽ tiến hành việc này như thế nào? Với FRT, khi tìm được công thức thành công thì chúng tôi mới dám mở rộng. FPT Retail đang hoạt động dưới sự giám sát của Tập đoàn và nhà đầu tư trên các KPI về doanh thu và lợi nhuận. Điều đó cũng có nghĩa là công ty đang rất quan tâm và quản lý chặt chẽ hiệu quả khi mở mới nhà thuốc, luôn cân bằng giữa cam kết với cổ đông và mở rộng thị phần. Về mặt quản trị thì mở 200, 300 hay 1.000 cửa hàng đều như nhau. Một phần mềm viết ra sẽ quản lý chi tiết đến từng mật mã hàng hoá, từng loại thuốc đến từng shop... Nhờ hệ thống phần mềm đó mà có thể nhìn tổng thể bức tranh về tài chính để theo dõi các chỉ số kinh doanh một cách tốt nhất, khu vực nào ổn, khi vực nào không ổn. FPT Retail có ý định rời xa ngành bán lẻ hay không? Sau dược phẩm, đích ngắm tiếp theo của FPT Retail là gì? FPT Retail định hướng trở thành công ty Bán lẻ đa ngành, chúng tôi đặt mục tiêu sẽ cung ứng tất cả các sản phẩm phục vụ đa dạng nhu cầu của khách hàng, len lỏi vào đời sống của tất cả người dùng Việt Nam. Năng lực cốt lõi của một công ty bán lẻ là xây dựng chuỗi bán lẻ và quản trị nó. Vì vậy không quan trọng là bạn bán cái gì mà bạn có năng lực cốt lõi đó hay không. Như FPT Retail, từ công nghệ chuyển sang một lĩnh vực không liên quan là dược phẩm, ban đầu mọi người cũng lo lắng, không có chuyên thì làm sao tham gia vào thị trường y tế? Nhưng cuối cùng chúng tôi cũng đã làm được vì đã có kinh nghiệm từ xây dựng chuỗi công nghệ. Tương lai, FPT Retail chắc chắn sẽ không dừng lại ở hai ngành nghề đang có. Các lĩnh vực bán lẻ có triển vọng lớn lại vừa an toàn là những sản phẩm thiết yếu như ăn uống, đồ tiêu dùng, mẹ và bé, siêu thị, giáo dục... Đây là những nhu cầu lặp đi lặp lại mỗi ngày, thường xuyên gắn với đời sống của một gia đình nên ở thời kỳ nào cũng sẽ tăng trưởng, phát triển tốt. Theo CafeF