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

Vào ngày 05/11/2025, tổ chức MITRE – một tổ chức phi lợi nhuận hàng đầu thế giới về an ninh mạng, đã chính thức công bố CVE-2025-63601 (https://www.cve.org/CVERecord?id=CVE-2025-63601) -lỗ hổng được đánh giá ở mức Critical (CVSS 9.9) do đội ngũ phát triển dịch vụ FPT AppSec, FPT Smart Cloud, Tập đoàn FPT phát hiện.  [caption id="attachment_68894" align="aligncenter" width="2056"] Thông tin chi tiết CVE-2025-63601 từ NVD[/caption] MITRE là đơn vị quản lý hệ thống CVE (Common Vulnerabilities and Exposures) – cơ sở dữ liệu toàn cầu ghi nhận và định danh các lỗ hổng bảo mật được phát hiện trên khắp thế giới. Khi một lỗ hổng được MITRE cấp mã CVE, điều đó có nghĩa là lỗ hổng ấy được công nhận chính thức, có ảnh hưởng thực tế và sẽ được các hãng công nghệ, tổ chức an ninh mạng toàn cầu theo dõi để phát hành bản vá, cập nhật hệ thống.  Trong quá trình rà soát bảo mật nội bộ với FPT AppSec, nhóm nghiên cứu của FPT Smart Cloud đã phát hiện một lỗ hổng trong chức năng khôi phục sao lưu (backup-restore) của Snipe-IT. Lỗ hổng này cho phép người dùng có quyền xác thực thực thi mã tùy ý trên hệ thống. Vấn đề đã được báo cáo có trách nhiệm tới nhà phát triển và được gán mã CVE-2025-63601 với mức độ nghiêm trọng Critical (CVSS 9.9). Ngay sau đó, nhóm dự án đã phát hành bản vá và thông báo cho người dùng để chủ động đảm bảo an toàn cho hệ thống và dữ liệu.  Trong toàn bộ quá trình này, FPT AppSec đóng vai trò quan trọng ở giai đoạn khoanh vùng và xác định phạm vi lỗ hổng. Công cụ Code Scan của FPT AppSec, kết hợp giữa phân tích tĩnh (taint tracing, data-flow tracking) và AI nhận dạng mẫu, đã giúp kỹ sư nhanh chóng tìm ra đường luồng dữ liệu dẫn tới đoạn mã dễ tổn thương, tiết kiệm đáng kể thời gian phân tích thủ công. Nhờ vậy, nhóm nghiên cứu có thể tập trung vào việc đánh giá mức độ khai thác thay vì mất thời gian lọc kết quả sai lệch.  FPT AppSec (Application Security Posture Management) là một trong những trụ cột quan trọng thuộc hệ sinh thái FPT CloudDefense Platform, được xây dựng nhằm giúp doanh nghiệp bảo đảm an toàn cho ứng dụng trong suốt toàn bộ vòng đời phát triển phần mềm (SDLC) - từ giai đoạn viết mã, xây dựng, triển khai cho đến vận hành thực tế.  Nền tảng này tích hợp đồng thời nhiều công nghệ quét bảo mật hiện đại như Code Scan (SAST) để phân tích mã nguồn, phát hiện sớm lỗi logic và lỗ hổng bảo mật; Secret Scan để tìm kiếm và cảnh báo các khóa API, token hoặc thông tin nhạy cảm bị lộ trong mã nguồn; IaC Scan nhằm rà soát các cấu hình hạ tầng dưới dạng mã như Terraform, CloudFormation hay Kubernetes YAML; Image Scan để kiểm tra container image, gói cài đặt và dependency; SCA Scan để phân tích các thành phần mã nguồn mở nhằm phát hiện lỗ hổng hoặc giấy phép không phù hợp; và DAST để quét, mô phỏng tấn công ứng dụng đang chạy, xác thực khả năng khai thác lỗ hổng trong môi trường thực tế.  Với khả năng kết hợp giữa phân tích tĩnh, phân tích động và trí tuệ nhân tạo hỗ trợ suy luận ngữ cảnh, FPT AppSec giúp doanh nghiệp phát hiện sớm rủi ro, tự động hóa quy trình đánh giá, rút ngắn thời gian xử lý cho đội ngũ kỹ sư, đồng thời nâng cao chất lượng và độ an toàn của phần mềm. Đây là bước tiến quan trọng trong hành trình giúp doanh nghiệp Việt Nam và toàn cầu đáp ứng các tiêu chuẩn bảo mật ngày càng khắt khe của thế giới số hiện nay.  Trong quá trình phát triển và nâng cấp dịch vụ, hàng trăm rule phân tích tĩnh được tinh chỉnh và bổ sung thêm yếu tố AI hỗ trợ phân tích mẫu – kết hợp với các kỹ thuật như Abstract Syntax Tree (AST), Taint tracing và Data-flow analysis – giúp hệ thống phát hiện chính xác hơn và giảm nhiễu cho người dùng kỹ thuật.  [caption id="attachment_68849" align="aligncenter" width="800"] Đội ngũ kỹ sư FSEC[/caption] Với đội ngũ kỹ sư, thành công này không chỉ là việc phát hiện một CVE, mà là cơ hội kiểm chứng năng lực “thực chiến” của dịch vụ. Mỗi rule được tinh chỉnh trong quá trình này sẽ giúp FPT AppSec hoàn thiện các tính năng, nâng cao khả năng phát hiện, đảm bảo kiểm soát truy cập linh hoạt và an toàn.  Bên cạnh đó, việc lỗ hổng CVE-2025-63601 được công bố đã thể hiện năng lực phát hiện sớm, xử lý tự động của nền tảng FPT AppSec cũng như uy tín và đóng góp của nhóm nghiên cứu vào cộng đồng bảo mật quốc tế. Thành công trong việc phát hiện CVE-2025-63601 củng cố niềm tin rằng sự kết hợp giữa nghiên cứu bảo mật chuyên sâu và AI hỗ trợ phân tích mã nguồn là hướng đi đúng đắn cho FPT AppSec.  Trong giai đoạn tiếp theo, đội ngũ phát triển sẽ mở rộng khả năng của nền tảng vượt ra ngoài phân tích tĩnh (SAST), hướng tới liên kết chặt chẽ với phân tích động (DAST) để hình thành chuỗi phát hiện – xác thực – khai thác mô phỏng thông minh.  AI sẽ đóng vai trò trung tâm trong việc tự động suy luận luồng dữ liệu, tái hiện hành vi tấn công và đề xuất bản vá phù hợp, giúp rút ngắn đáng kể thời gian phân tích thủ công cho kỹ sư bảo mật và nhà phát triển.  Bên cạnh việc mở rộng tập rule và tăng độ chính xác phát hiện, FPT AppSec cũng đặt mục tiêu xây dựng một hệ sinh thái phân tích thống nhất, nơi các module SAST, DAST, và AI phối hợp liền mạch – từ mã nguồn đến ứng dụng đang chạy – nhằm giúp doanh nghiệp chủ động hơn trong việc phòng ngừa, phát hiện và khắc phục lỗ hổng trong toàn bộ vòng đời phần mềm (SDLC).  Liên hệ với chúng tôi để được tư vấn về dịch vụ của FPT Cloud Fanpage: https://www.facebook.com/fptsmartcloud/ Email: [email protected] Hotline: 1900 638 399 

Bên lề Lễ mở ký Công ước của Liên Hợp Quốc về chống tội phạm mạng (Công ước Hà Nội), tọa đàm “Bảo vệ công dân và củng cố niềm tin số trong nỗ lực thực thi Công ước Hà Nội” đã diễn ra tại Trung tâm Hội nghị Quốc gia, do Hiệp hội An ninh mạng Quốc gia phối hợp với Doanh nghiệp xã hội Chống Lừa Đảo tổ chức. Tại sự kiện, ông Đặng Hải Sơn, Offensive Security Manager, FPT Smart Cloud (Tập đoàn FPT), chia sẻ kinh nghiệm triển khai các mô hình tấn công – phòng thủ thực chiến cho doanh nghiệp, cùng những kỹ năng mới bắt buộc trong môi trường an ninh mạng dựa trên AI và cách rèn luyện tư duy “phòng thủ chủ động” cho đội ngũ kỹ sư an ninh mạng Việt Nam.  Ông Sơn nhấn mạnh, AI Red Teaming đang trở thành năng lực cốt lõi: đội ngũ an ninh cần biết cách “đóng vai kẻ tấn công” để kiểm thử hệ thống AI từ nhiều lớp – prompt (câu lệnh), mô hình và pipeline huấn luyện/vận hành. Doanh nghiệp khi xây dựng kịch bản tấn công-phòng thủ, nên bám theo các chuẩn ngành như MITRE ATLAS/ATT&CK, STRIDE và OWASP Top 10 cho LLM nhằm bảo đảm không bỏ sót rủi ro.  [caption id="" align="alignnone" width="2165"] Ông Đặng Hải Sơn (đứng giữa) tại phiên thảo luận “Phát triển năng lực và hợp tác liên ngành về an ninh mạng” bên lề Lễ mở ký Công ước của Liên hợp quốc (LHQ) về chống tội phạm mạng (Công ước Hà Nội).[/caption]   Việc kiểm thử cần tự động hóa, đồng thời ghi nhật ký/giám sát để đo lường tỷ lệ “bẻ khóa” mô hình và tốc độ phát hiện/ứng phó sự cố. Ở chiều phòng thủ, hệ thống cần bộ bộ lọc an toàn đầu vào/đầu ra, cơ chế bảo vệ dữ liệu và mô hình, vận hành MLOps an toàn, cùng với việc áp dụng Zero Trust để xác thực mọi truy cập của AI/agent. Doanh nghiệp cũng nên tuân thủ các khung quản trị AI như NIST AI RMF và ISO/IEC 42001, cùng quy định trong nước.  Trong khuôn khổ sự kiện, FPT giới thiệu 08 nền tảng, giải pháp và dịch vụ bảo mật ứng dụng AI đã được ghi nhận bằng các giải thưởng khu vực, thể hiện năng lực công nghệ của doanh nghiệp Việt trong việc bảo vệ hạ tầng số quốc gia và thúc đẩy chuyển đổi số an toàn, bền vững.  [caption id="" align="alignnone" width="1462"] Không gian triển lãm của FPT tại sự kiện.[/caption] Công ước Hà Nội là văn kiện pháp lý quốc tế đầu tiên ở cấp độ Liên Hợp Quốc về phòng, chống tội phạm mạng, tạo cơ sở để Việt Nam thúc đẩy hợp tác, tiếp nhận hỗ trợ kỹ thuật, nâng cao năng lực điều tra số và chia sẻ thông tin với các đối tác. Sự kiện đánh dấu bước tiến quan trọng khi Việt Nam đăng cai ký kết Công ước toàn cầu đầu tiên về an ninh mạng, khẳng định vai trò chủ động, sáng tạo và có trách nhiệm của Việt Nam trong nỗ lực xây dựng không gian mạng an toàn, lành mạnh và hợp tác quốc tế vì hòa bình, thịnh vượng.  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

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. >> Xem thêm: Thuê VPS giá rẻ - Mua Cloud VPS tốc độ cao 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 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