Có lẽ thời gian gần đây khái niệm Serverless đã không còn xa lạ gì với những tín đồ công nghệ và cả những doanh nghiệp đang thực hiện quá trình chuyển đổi số. Thế thì Serverless thực chất là gì? Những đặc điểm nổi bật của nền tảng này? Tiện ích nền tảng mang lại là gì? Và phương pháp để các cá nhân, tổ chức có thể tiếp cận cũng như áp dụng serverless? Hãy cùng FPT Cloud phân tích thông qua bài viết này. [caption id="attachment_35539" align="aligncenter" width="2500"]  Phương pháp triển khai ứng dụng qua từng giai đoạn[/caption] Lịch sử các phương pháp triển khai, vận hành ứng dụng Trước khi đi vào phân tích về serverless. Hãy cùng nhìn lại một vài nét về quá trình phát triển của phương pháp triển khai và vận hành một ứng dụng. 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ủ, 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="1920"] 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="975"] Xếp hạng những khó khăn trong sử dụng Kubernetes (container) – Theo TheNewStack[/caption] 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: 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 [caption id="attachment_35542" align="aligncenter" width="1200"] Model FaaS giữ vị trí giữa PaaS và SaaS[/caption] 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. Một số dịch vụ điển hình ứng dụng công nghệ serverless triển khai có thể kể đến như sau: Ứ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="2403"] Mô hình triển khai Serverless in-house[/caption] Kết luận 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

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ẹnThờ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. Bản thân việc dựng được một cụm cluster Kafka không phải chuyện đơn giản do người dùng sẽ phải có kiến thức nhất định về hạ tầng và cài đặt vận hành nền tảng. Hiểu được điều này, FPT Smart Cloud cung ứng dịch vụ Kafka as a service cho phép dựng sẵn một cụm cluster kafka mà người dùng không cần có những hiểu biết nêu trên. Ngoài ra, sản phẩm còn có nhiều Ưu và nhược điểm khi sử dụng Ưu/nhược điểm của việc sử dụng Kafka là gì? 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. 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 orderVD: 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. 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/

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/

Năm 2023 đã chứng kiến sự phát triển “thần tốc” của trí tuệ nhân tạo (AI) trên thị trường công nghệ toàn cầu. Thay vì lập trình một hệ thống mã code phức tạp hoặc tìm kiếm sự hỗ trợ từ công cụ thứ ba, trí tuệ nhân tạo hiện cho phép doanh nghiệp xử lý dữ liệu trực tiếp bằng ngôn ngữ tự nhiên của con người. Nắm bắt xu thế này, Microsoft đã khẳng định vị trí ông lớn trong ngành công nghệ khi tích hợp AI chuyên sâu vào bộ giải pháp Microsoft 365. Không dừng lại ở việc phát triển một tính năng mới, Microsoft định hướng trí tuệ nhân tạo cần trở thành công cụ then chốt trong toàn bộ hệ thống vận hành và quản lý doanh nghiệp. Hiểu đơn giản, với những doanh nghiệp cần chuyên môn hoá việc phân tích dữ liệu, tính năng Analyze trong Excel chính là lựa chọn ưu tiên để tạo bước đột phá trong quy trình làm việc. Analyze trong Excel thay thế các quy trình thủ công để tự động phân tích dữ liệu chuyên sâu nhanh chóng, dễ dàng. Khi đó, điều doanh nghiệp cần làm chỉ là thu thập, đánh giá dựa trên thông tin được tổng hợp sẵn dưới dạng biểu đồ, bảng tính. Ngoài ra, tiềm năng kinh doanh sản phẩm, dịch vụ cũng dễ dàng được dự đoán nhờ bảng diễn tả xu hướng phát triển tương lai của Analyze trong Excel. Cùng khám phá cách thức phân tích dữ liệu của tính năng AI trên Excel thông qua một ví dụ về hoạt động tổng hợp, đánh giá hiệu quả kinh doanh sản phẩm. Hướng dẫn kích hoạt AI trong Excel Để sử dụng Analyze trong Excel, người dùng cần khởi động Excel và tệp dữ liệu: Bước 1: Mở ứng dụng Microsoft Excel. Bước 2: Mở tập dữ liệu cần phân tích. Bước 3: Trên thanh Ribbon, nhấp vào thẻ Home, chọn Analyze Data. Bước 4: Người dùng lựa chọn câu hỏi được đề xuất hoặc tuỳ chỉnh câu hỏi riêng phù hợp với mục đích. Bước 5: Khi đó, bảng điều khiển Analyze Data được mở ra để người dùng xem trước một số thông tin được AI phân tích hoặc đặt câu hỏi trực tiếp cho Excel. Đặt câu hỏi & Yêu cầu phân tích dữ liệu cho trước Với tính năng Analyze trong Excel, người dùng có quyền yêu cầu AI phân tích dữ liệu chuyên sâu dựa trên các thông số có sẵn, hoặc tạo ra một phân tích riêng biệt. Hãy thử bắt đầu với việc đặt câu hỏi và yêu cầu phân tích các thông tin cơ bản! Ví dụ: Nếu doanh nghiệp cần tổng hợp chi phí từng sản phẩm cho các khách hàng theo ngày, hãy đặt câu hỏi và yêu cầu cụ thể như: "Có bao nhiêu đơn vị được bán mỗi ngày? Hãy thể hiện qua một biểu đồ đường" (“How many units sold per day as a line chart”). “Tính phần trăm doanh số trên tổng số mỗi dòng sản phẩm bán ra” (Show percentage of Units Sold for each Product). Ngoài ra, AI sẽ đề xuất một số câu hỏi mẫu cho doanh nghiệp như: Giá trị trung bình bán ra mỗi ngày (Average “Units Sold” by date of ‘Date’). Nhấn Enter để hiển thị biểu đồ tương ứng và PivotTable hiển thị câu trả lời. Nhấp đúp chuột để AI tự động điền dữ liệu vào biểu đồ và PivotTable trong tệp làm việc Excel. Ngoài ra, Excel hỗ trợ tạo ra phân tích riêng để dự đoán xu hướng kinh doanh trong tương lai. Người dùng đặt câu hỏi: “Có thể hiển thị xu hướng kinh doanh sản phẩm, dịch vụ theo ngày không?” ("Are there any date trends?"). Excel sẽ hiển thị một số thông tin dự báo về xu hướng Doanh số bán ra theo ngày trong tương lai. Từ đó, Excel sẽ hiển thị các ngày có Doanh số nổi bật (ngày 3/12/2022 và 12/12/2022); đồng thời dự đoán trong 1 năm sẽ có 6 ngày đạt đỉnh cao mới. Bên cạnh các cách đặt câu hỏi như ví dụ trên, chúng ta có thể hỏi thêm AI trên Excel nhiều thông tin hơn để tạo ra báo cáo chuyên sâu và đa chiều. Kết luận Có thể thấy, AI trong Excel hiện đã hoàn thành tốt vai trò nâng cao hiệu suất và tiết kiệm thời gian làm việc cho con người. Trong tương lai, Microsoft đặt mục tiêu sẽ tích hợp thêm Copilot vào môi trường làm việc trên Microsoft 365, đồng thời trang bị GPT4 của OpenAI cho Copilot. Những thay đổi đột phá này hứa hẹn sẽ tạo bàn đạp phát triển cho các doanh nghiệp và hướng đến một môi trường làm việc hiện đại, chuyên môn hoá trong thời gian sắp tới. Liên hệ với FPT Smart Cloud để được tư vấn chi tiết thông tin về các dịch vụ. Fanpage: Microsoft For Business – FPT Smart Cloud Email: [email protected] Hotline: 1900 638 399

Khi kiến trúc hệ thống tăng về quy mô và độ phức tạp, các nhóm IT, DevOps phải đối mặt với áp lực ngày càng lớn để theo dõi và ứng phó với các sự cố. Việc có được một hệ thống quan sát tốt là rất quan trọng để đảm bảo rằng hệ thống đang hoạt động ổn định và tối ưu. Vậy Observability là gì? Tại sao nó lại quan trọng và nó có thể giúp các tổ chức đạt được những gì trong thực tế? Hãy cùng FPT Cloud phân tích thông qua bài viết này. 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. Tham khảo thêm dịch vụ của FPT đang được quan tâm nhất: Cho thuê máy chủ vật lý 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:  MonitoringObservabilityMục đíchGiá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áoTậ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ơnPhạm viTậ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ọngTậ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 observabilityLinh 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. 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. 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ể. 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. 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. 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. Kết luận 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. Liên hệ với chúng tôi để biết thêm thông tin chi tiết về dịch vụ của FPT Smart Cloud Website: https://fptcloud.com/Fanpage: https://www.facebook.com/fptsmartcloudEmail: [email protected]: 1900 638 399

Năm 2021, trong một bài viết của mình, AWS đã thông báo AWS Outpost đã có thể đặt hàng thêm tại một số quốc gia, trong đó có Việt Nam. Song song với đó, tại AWS Reinvent 2021, AWS cũng giới thiệu các tùy chọn mới về phần cứng của AWS outpost theo người viết đánh giá là rất phong phú và phù hợp với rất nhiều phân khúc khách hàng, từ dòng server 1U, 2U đến rack 42U được đóng gói sẵn. Theo hướng dẫn, khách hàng chỉ cần thêm 2 kết nối: Service link – Internet, kết nối đến AWS và private link: kết nối vào mạng private của khách hàng là đã có thể lên portal của AWS để tiến hành cấu hình và bắt đầu tạo EC2 instance. Các dịch vụ trên Outpost Rack bao gồm EC2, ECS, EBS, EKS S3, RDS, ALB, EMR, CloudEndure (Outpost server ít dịch vụ hơn). Hiện AWS đã khá đầy đủ từ VM, container, storage đến Load balancer, Data analytics cho hầu hết khách hàng. Vậy AWS outpost hay PCOP (Public cCoud on-premises - theo cách viết tắt của người viết trong bài) là gì? PCOP khác biệt gì so với các giải pháp tương tự của Azure, GCP là Azure stack, Google Anthos? Tất cả sẽ được giải đáp thông qua bài viết dưới đây. Ưu thế của PCOP (Public cloud on-premises) PCOP phong phú về mặt dịch vụ hơn các giải pháp hiện có trên thị trường (ví dụ với các dịch vụ DBaaS, Container platform như AKS, EKS...). Việc này rất phù hợp với xu hướng phát triển và nhu cầu của khách hàng, họ không đơn giản chỉ cần các dịch vụ server, ảo hóa mà cần các dịch vụ mới hơn, đáp ứng cho kiến trúc ứng dụng theo kiểu micro-service - “cloud-native”. Bên cạnh đó, PCOP cũng luôn sẵn sàng cho việc thiết lập môi trường Hybrid, thống nhất (unified) về mặt quản trị, kết nối với hệ thống trên Public để có thể được triển khai tại nhiều nơi trên thế giới, phù hợp cho các công ty đa quốc gia. Một số nhà cung cấp PCOP thường có luôn cơ chế pay-as-you-go, trả tiền theo hàng tháng, giúp doanh nghiệp linh hoạt về chi phí. Khi doanh nghiệp sử dụng các dịch vụ PCOP sẽ được vận hành và theo dõi bởi nhà cung cấp, trong khi đó các giải pháp Private cloud, HCI vận hành bởi chính khách hàng. Đây là điểm mạnh giúp không mất quá nhiều nguồn lực cho vận hành - khai thác nhưng cũng có thể là rủi ro từ việc vận hành từ xa, cần chú ý và đánh giá thêm tiêu chí này. Mặt trái của PCOP Nói về Private cloud, các giải pháp như HCI hoặc build dựa trên VMware, Openstack, Promox... là giải pháp hoàn toàn private trong khi PCOP vẫn phải kết nối với AWS region để quản trị và bảo trì (hybrid), việc này có thể vi phạm chính sách bảo mật hoặc tiêu chuẩn của một số quốc gia, doanh nghiệp. Vendor lock-in: PCOP thường đi theo phần cứng và giải pháp của nhà cung cấp, khi khách hàng muốn mở rộng hoặc thay đổi thì đây là một khó khăn lớn so với các giải pháp khác sử dụng VMware hoặc Opensource sử dụng phần cứng phổ thông. Chuyện gì xảy ra nếu sau này lượng khách hàng, tài nguyên đủ lớn AWS, Azure sẽ thay đổi chính sách, giá? Việc này đã xảy ra với nhiều sản phẩm công nghệ. Mở rộng: Khi sử dụng gần hết năng lực, tài nguyên của server/storage là lúc cần mua bổ sung phần cứng và cấu hình mở rộng. Ví dụ cần mở rộng AWS Outpost rack thì sẽ phải đặt mua rack mới? Làm sao để đấu nối 2 Rack hay sẽ là 2 hệ thống độc lập?  Có mở rộng được từng phần riêng như storage, compute, thời gian đặt hàng, tích hợp mất bao nhiêu lâu? Và lưu ý là chúng ta chỉ có thể mua được từ AWS, với Azure stack thì dễ dàng hơn, hầu hết các vendor phần cứng nổi tiếng như HP, Dell đều có thiết bị được chứng nhận. Có thể thấy đây là những miếng bánh cuối cùng của thị trường điện toán, và nó tiếp tục bị xâm chiếm bởi các nhà cung cấp lớn? Một góc nhìn khác, chúng ta có thể cũng đã nghe đến VMware on AWS, VMware on Azure, GCP. VMware on Azure, VMware cloud on AWS cùng giúp thiết lập môi trường hybrid. Tuy nhiên các giải pháp này có sự khác biệt về cách tiếp cận: Azure stack mang Public cloud service đến on-premises, trong khi Vmware cloud on AWS mang private Vmware service to public enviroment. Vmware cloud on AWS hoặc Azure tiếp cận theo hướng giảm, tối ưu hạ tầng DC, sử dụng model Pay-as-you-go. Tuy nhiên hiện mới chỉ có trên một số region của các NCC và ít hoặc hạn chế hơn trong việc tích hợp với các dịch vụ khác như DbaaS, Container platform, ECS…. Giải pháp như Azure stack cho phép application developer triển khai ứng dụng tại bản địa tuy nhiên đội ngũ kĩ sư cũng cần học hỏi kiến thức mới để có thể triển khai và vận hành, vẫn là một quá trình cần transform cả về con người, quy trình và công nghệ. [caption id="attachment_35027" align="alignleft" width="300"] 2 cách tiếp cận kiến trúc Hybrid theo Gartner.[/caption] Các giải pháp của Azure, AWS… thường tiếp cận theo hướng Outside-in, theo cách mở rộng các dịch vụ Public vào môi trường private. Một số dịch vụ đã có trên public được thiết lập sẵn trên hạ tầng hardware & software. Ngược lại, VMware on Azure/Aws là Inside-out, tùy hiện trạng từng khách hàng nên chọn chiến lược phù hợp.     So sánh cơ bản giữa AWS Outpost, Azure Stack, Google Anthos Solution AWS outposts Google Anthos Azure Stack Hub Azure Stack HCI Azure Stack ARC Description Cung cấp một số dịch vụ AWS tại local Distributed K8s cluster, Multi-cloud Focus trực tiếp dịch vụ liên quan K8s Cung cấp một số dịch vụ của Azure tại Local HCI solution cho local hardware, virtualization layer. Software cho phép quản trị, vận hành local HW, k8s cluster với Azure tool và Azure resource management, hướng tới quản trị resource anywhere, Multi-Cloud Hardware AWS provided, serviced, owned. KH đơn giản là thuê và có chỗ đặt Khách hàng chuẩn bị, quản trị và vận hành. Microsoft partner certified  cung cấp và hỗ trợ. Khách hàng sở hữu. Microsoft partner certified cung cấp và hỗ trợ. Khách hàng sở hữu. Khách hàng chuẩn bị, vận hành và sở hữu (software only) Management Software AWS system software, không thể truy cập từ local Google provided GKE Azure system software, azure portal Microsoft Azure core service, Windows admin center. Truy cập được từ Local, cần kết nối với Azure mỗi 30 ngày. Customer cung cấp system software (linux, windows), cài đặt ARC agent. Why? Cung cấp AWS service với local HW Quản trị tất cả các cụm K8s từ Anthos UI và control plan trong GCP. Extend Cloud Run và một số dịch vụ GCP khác Cung cấp Azure service từ local HW Đơn giản hóa hạ tầng với Azure management Azure quản trị và thiết lập hạ tầng local, K8s cluster Service supported Rack: EC2, ECS, EBS, EKS S3, RDS, ALB, EMR, CloudEndure GKE, Cloud Run, Cloud logging & monitoring, Anthos service mesh… Not provide VM Compute, storage, containers, databases, IoT, data analytics, KMS, marketplace Virtualization AKS, Azure App services, Data services, ML (customer choose) Fees Fees charged based on cloud services consumed Additional fees for data egress, software licenses, etc   Fees charged based on resources usage vCPU Fees charged based on cloud services consumed (vCPU, Storage, application) Fees charged based on Physical CPU.   Deployment AWS ship appliance đã cài đặt sẵn toàn bộ software Khách hàng tự cài đặt phần cứng, triển khai Anthos KH chuẩn bị phần cứng, cài đặt Azure stack lên hoặc partner triển khai. Azure edge thì đã có sẵn software Competitor Azure Stack hub Azure Arc for K8s AWS outposts HCI, SDI solutions (Nutanix, Redhat, Vmware) Google Anthos, k8s management 3rd, AWS system management Kết luận Bài viết đã tóm tắt cơ bản về giải pháp AWS Outposts, Azure Stack và Google Anthos. Các giải pháp giúp mở rộng hạ tầng từ Public cloud xuống On-premise để xây dựng model Hybrid & Multi-Cloud. Có thể thấy Google Anthos, Azure Stack Arc hướng đến mô hình Multi-Cloud bằng cách quản trị các cụm K8s "any where". Trong khi, AWS, Azure Stack (Hub, HCI) có các model phần cứng, phần mềm hướng đến mở rộng hạ tầng thay thế private cloud, Edge. Hãy tiếp tục theo dõi các bài viết mới của FPT Cloud tại ĐÂY để hiểu rõ hơn về việc xây dựng các chiến lược Cloud migration, Hybrid – Multi Cloud. Một số hình ảnh của AWS Outposts Server: Tác giả: Nguyễn Khương Duy - FPT Smart Cloud Nguồn: Viet-AWS Group (https://www.facebook.com/photo?fbid=638463360494850&set=pcb.1098411517643483) https://aws.amazon.com/blogs/aws/new-aws-outposts-servers-in-two-form-factors/?fbclid=IwAR38Fn8GZBd-w8nbu4UfdrCACgelWskE0dsji-GDnKfVChoDULLEKyzicJ0