Bazaarvoice đã hiện đại hóa hạ tầng Apache Kafka của họ với Amazon MSK như thế nào

Tác giả: Oleh Khoruzhenko, Aravind Marthineni, Christian Silva
Ngày phát hành: 20 JAN 2026
Chuyên mục: Advanced (300), Amazon Managed Streaming for Apache Kafka (Amazon MSK), Customer Solutions

Đây là bài đăng của khách mời bởi Oleh Khoruzhenko, Kỹ sư DevOps cấp cao tại Bazaarvoice, hợp tác với AWS.

Bazaarvoice là một công ty có trụ sở tại Austin, cung cấp nền tảng đánh giá và xếp hạng hàng đầu thế giới. Hệ thống của chúng tôi xử lý hàng tỷ tương tác của người tiêu dùng thông qua xếp hạng, đánh giá, hình ảnh và video, giúp các thương hiệu và nhà bán lẻ xây dựng niềm tin của người mua sắm và thúc đẩy doanh số bằng cách sử dụng nội dung do người dùng tạo (UGC) xác thực trong suốt hành trình của khách hàng. Bazaarvoice Trust Mark là tiêu chuẩn vàng về tính xác thực.

Apache Kafka là một trong những thành phần cốt lõi của hạ tầng của chúng tôi, cho phép truyền dữ liệu theo thời gian thực cho nền tảng đánh giá toàn cầu. Mặc dù kiến trúc phân tán của Kafka đáp ứng nhu cầu của chúng tôi về truyền tải thông lượng cao, chịu lỗi, nhưng việc tự quản lý hệ thống phức tạp này đã làm chệch hướng các nguồn lực kỹ thuật quan trọng khỏi việc phát triển sản phẩm cốt lõi của chúng tôi. Mỗi thành phần của hạ tầng Kafka của chúng tôi đòi hỏi chuyên môn đặc biệt, từ cấu hình các tham số cấp thấp đến duy trì các hệ thống phân tán phức tạp mà khách hàng của chúng tôi tin cậy. Bản chất động của môi trường của chúng tôi đòi hỏi sự chăm sóc liên tục và đầu tư vào tự động hóa. Chúng tôi nhận thấy mình liên tục quản lý các bản nâng cấp, áp dụng các bản vá bảo mật, triển khai các bản sửa lỗi và giải quyết các nhu cầu mở rộng khi khối lượng dữ liệu của chúng tôi tăng lên.

Trong bài đăng này, chúng tôi sẽ trình bày các bước chúng tôi đã thực hiện để di chuyển khối lượng công việc của mình từ Kafka tự quản lý sang Amazon Managed Streaming for Apache Kafka (Amazon MSK). Chúng tôi sẽ hướng dẫn bạn qua quy trình di chuyển của chúng tôi và nêu bật những cải tiến chúng tôi đã đạt được sau quá trình chuyển đổi này. Chúng tôi sẽ chỉ ra cách chúng tôi giảm thiểu chi phí vận hành, tăng cường tư thế bảo mật và tuân thủ, tự động hóa các quy trình chính và xây dựng một nền tảng linh hoạt hơn trong khi vẫn duy trì hiệu suất cao mà cơ sở khách hàng toàn cầu của chúng tôi mong đợi.

Nhu cầu hiện đại hóa

Khi nền tảng của chúng tôi phát triển để xử lý hàng tỷ tương tác của người tiêu dùng hàng ngày, chúng tôi cần tìm cách mở rộng các cluster Kafka của mình một cách hiệu quả trong khi vẫn duy trì một đội ngũ nhỏ để quản lý hạ tầng. Những hạn chế của các cluster Kafka tự quản lý thể hiện ở một số lĩnh vực chính:

Hoạt động mở rộng (Scaling operations) – Mặc dù việc mở rộng các cluster Kafka tự quản lý của chúng tôi không phức tạp về bản chất, nhưng nó đòi hỏi kế hoạch và thực hiện cẩn thận. Mỗi khi chúng tôi cần thêm các broker mới để xử lý khối lượng công việc tăng lên, nhóm của chúng tôi phải đối mặt với một quy trình nhiều bước bao gồm lập kế hoạch dung lượng, cung cấp hạ tầng và cập nhật cấu hình.
Độ phức tạp của cấu hình (Configuration complexity) – Kafka cung cấp hàng trăm tham số cấu hình. Mặc dù chúng tôi không chủ động quản lý tất cả, nhưng việc hiểu tác động của chúng là rất quan trọng. Các cài đặt chính như luồng I/O, bộ đệm bộ nhớ và chính sách lưu giữ cần được chú ý liên tục khi chúng tôi mở rộng. Ngay cả những điều chỉnh nhỏ cũng có thể có những tác động đáng kể, đòi hỏi nhóm của chúng tôi phải duy trì chuyên môn sâu về các tham số này và sự tương tác của chúng để đảm bảo hiệu suất và sự ổn định tối ưu.
Quản lý hạ tầng và lập kế hoạch dung lượng (Infrastructure management and capacity planning) – Việc tự quản lý Kafka yêu cầu chúng tôi quản lý nhiều khía cạnh mở rộng, bao gồm tính toán, bộ nhớ, thông lượng mạng, thông lượng lưu trữ và dung lượng lưu trữ. Chúng tôi cần lập kế hoạch dung lượng cẩn thận cho tất cả các thành phần này, thường xuyên phải đánh đổi phức tạp. Ngoài việc lập kế hoạch dung lượng, chúng tôi chịu trách nhiệm quản lý hạ tầng Kafka của mình theo thời gian thực. Điều này bao gồm việc phát hiện và giải quyết kịp thời các lỗi thành phần và vấn đề hiệu suất. Nhóm của chúng tôi cần phản ứng nhanh chóng với các cảnh báo, thường yêu cầu hành động ngay lập tức để duy trì sự ổn định của hệ thống.
Yêu cầu chuyên môn đặc biệt (Specialized expertise requirements) – Vận hành Kafka ở quy mô lớn đòi hỏi chuyên môn kỹ thuật sâu rộng trên nhiều lĩnh vực. Nhóm cần:
- Giám sát và phân tích hàng trăm số liệu hiệu suất
- Thực hiện phân tích nguyên nhân gốc rễ phức tạp cho các vấn đề hiệu suất
- Quản lý điều phối ZooKeeper ensemble
- Thực hiện các bản cập nhật cuốn chiếu (rolling updates) để nâng cấp không gián đoạn và vá lỗi bảo mật

Những thách thức này càng trở nên trầm trọng hơn trong các giai đoạn kinh doanh cao điểm, chẳng hạn như Black Friday và Cyber Monday, khi việc duy trì hiệu suất tối ưu là điều cần thiết cho các khách hàng bán lẻ của Bazaarvoice.

Lựa chọn Amazon MSK

Sau khi đánh giá nhiều lựa chọn khác nhau, chúng tôi đã chọn Amazon MSK làm giải pháp hiện đại hóa của mình. Quyết định này được thúc đẩy bởi khả năng của dịch vụ trong việc giảm thiểu chi phí vận hành, cung cấp tính sẵn sàng cao ngay lập tức với kiến trúc ba Availability Zone và tích hợp liền mạch với hạ tầng AWS hiện có của chúng tôi.

Các khả năng chính khiến Amazon MSK trở thành lựa chọn rõ ràng:

Tích hợp AWS – Chúng tôi đã sử dụng các dịch vụ AWS để xử lý và phân tích dữ liệu. Amazon MSK kết nối trực tiếp với các dịch vụ này, giảm bớt nhu cầu xây dựng và duy trì các tích hợp tùy chỉnh. Điều này có nghĩa là các pipeline dữ liệu hiện có của chúng tôi sẽ tiếp tục hoạt động với những thay đổi tối thiểu.
Quản lý hoạt động tự động – Amazon MSK đã tự động hóa các tác vụ tốn thời gian nhất của chúng tôi. Chúng tôi không còn cần phải giám sát thủ công các instance và lưu trữ để tìm lỗi hoặc tự mình phản hồi các vấn đề này.
Độ tin cậy cấp doanh nghiệp – Kiến trúc của nền tảng phù hợp với các yêu cầu về độ tin cậy của chúng tôi ngay từ đầu. Phân phối đa AZ và sao chép tích hợp đã cung cấp cho chúng tôi khả năng chịu lỗi tương tự mà chúng tôi đã cẩn thận xây dựng trong hệ thống tự quản lý của mình, giờ đây được hỗ trợ bởi các đảm bảo dịch vụ của AWS.
Quy trình nâng cấp đơn giản hóa – Trước Amazon MSK, việc nâng cấp phiên bản cho các cluster Kafka của chúng tôi đòi hỏi kế hoạch và thực hiện cẩn thận. Quy trình này phức tạp, liên quan đến nhiều bước và rủi ro. Amazon MSK đã đơn giản hóa các hoạt động nâng cấp của chúng tôi. Giờ đây, chúng tôi sử dụng các bản nâng cấp tự động cho khối lượng công việc dev và test và duy trì quyền kiểm soát đối với môi trường sản xuất. Sự thay đổi này đã giảm nhu cầu về các buổi lập kế hoạch mở rộng và nhiều kỹ sư. Kết quả là, chúng tôi luôn cập nhật các phiên bản Kafka và bản vá bảo mật mới nhất, cải thiện độ tin cậy và hiệu suất hệ thống của chúng tôi.
Kiểm soát bảo mật nâng cao – Nền tảng của chúng tôi yêu cầu tuân thủ ISO 27001, thường liên quan đến nhiều tháng tài liệu và triển khai kiểm soát bảo mật. Amazon MSK đi kèm với chứng nhận này được tích hợp sẵn, giảm bớt nhu cầu về công việc tuân thủ riêng biệt. Amazon MSK đã mã hóa dữ liệu của chúng tôi, kiểm soát quyền truy cập mạng và tích hợp với các công cụ bảo mật hiện có của chúng tôi.

Với Amazon MSK được chọn làm nền tảng mục tiêu, chúng tôi bắt đầu lập kế hoạch cho nhiệm vụ phức tạp là di chuyển hạ tầng streaming quan trọng của mình mà không làm gián đoạn hàng tỷ tương tác của người tiêu dùng đang chảy qua hệ thống của chúng tôi.

Hành trình di chuyển của Bazaarvoice

Việc di chuyển hạ tầng Kafka phức tạp của chúng tôi sang Amazon MSK đòi hỏi kế hoạch cẩn thận và thực hiện chính xác. Nền tảng của chúng tôi xử lý dữ liệu thông qua hai thành phần chính: một pipeline Apache Kafka Streams xử lý dữ liệu và tăng cường, và các ứng dụng client di chuyển dữ liệu đã được làm giàu này đến các hệ thống downstream. Với 40 TB trạng thái trên 250 topic nội bộ, quá trình di chuyển này đòi hỏi một cách tiếp cận có phương pháp.

Giai đoạn lập kế hoạch

Làm việc với các Kiến trúc sư Giải pháp của AWS đã chứng tỏ là rất quan trọng để xác thực chiến lược di chuyển của chúng tôi. Các đặc điểm độc đáo của nền tảng của chúng tôi đòi hỏi sự cân nhắc đặc biệt:

Triển khai đa Region trên khắp Hoa Kỳ và EU
Các ứng dụng stateful phức tạp với nhu cầu nhất quán dữ liệu nghiêm ngặt
Các dịch vụ kinh doanh quan trọng yêu cầu thời gian ngừng hoạt động bằng không
Hệ sinh thái người tiêu dùng đa dạng với các yêu cầu di chuyển khác nhau

Thách thức di chuyển

Trở ngại lớn nhất là di chuyển các ứng dụng Kafka Streams stateful của chúng tôi. Quá trình xử lý dữ liệu của chúng tôi chạy dưới dạng biểu đồ không chu trình có hướng (DAG) của các ứng dụng trên các Region, sử dụng tư cách thành viên nhóm tĩnh để ngăn chặn việc tái cân bằng gây gián đoạn. Điều quan trọng cần lưu ý là Kafka Streams giữ trạng thái của nó trong các topic Kafka nội bộ. Để các ứng dụng phục hồi đúng cách, việc sao chép trạng thái này một cách chính xác là rất quan trọng. Đặc điểm này của Kafka Streams đã làm tăng độ phức tạp cho quy trình di chuyển của chúng tôi. Ban đầu, chúng tôi đã xem xét MirrorMaker2, công cụ tiêu chuẩn cho các quá trình di chuyển Kafka. Tuy nhiên, hai hạn chế cơ bản đã khiến nó trở nên khó khăn:

Nguy cơ mất trạng thái hoặc sao chép trạng thái không chính xác trên các ứng dụng của chúng tôi.
Không thể chạy hai instance của ứng dụng của chúng tôi đồng thời, điều này có nghĩa là chúng tôi cần tắt ứng dụng chính và đợi nó phục hồi từ trạng thái trong cluster MSK. Với kích thước trạng thái của chúng tôi, quá trình phục hồi này đã vượt quá SLA 30 phút của chúng tôi cho thời gian ngừng hoạt động.

Giải pháp của chúng tôi

Chúng tôi quyết định triển khai một stack song song các ứng dụng Kafka Streams đọc và ghi dữ liệu từ Amazon MSK. Cách tiếp cận này đã cho chúng tôi đủ thời gian để kiểm tra và xác minh, đồng thời cho phép các ứng dụng làm đầy trạng thái của chúng trước khi chúng tôi gửi đầu ra đến kho dữ liệu của mình để phân tích. Chúng tôi đã sử dụng MirrorMaker2 để sao chép topic đầu vào, trong khi giải pháp của chúng tôi mang lại một số lợi thế:

Đơn giản hóa việc giám sát quá trình sao chép
Tránh các vấn đề nhất quán giữa các state store và các topic nội bộ
Cho phép di chuyển người tiêu dùng dần dần, có kiểm soát
Cho phép xác thực kỹ lưỡng trước khi chuyển đổi
Yêu cầu một kế hoạch chuyển đổi phối hợp cho tất cả người tiêu dùng, vì chúng tôi không thể chuyển các offset của người tiêu dùng giữa các cluster

Chiến lược di chuyển người tiêu dùng

Mỗi loại người tiêu dùng yêu cầu một cách tiếp cận được điều chỉnh cẩn thận:

Người tiêu dùng tiêu chuẩn (Standard consumers) – Đối với các ứng dụng hỗ trợ giao thức Kafka Consumer Group, chúng tôi đã triển khai một quá trình di chuyển bốn bước. Cách tiếp cận này có nguy cơ xử lý trùng lặp, nhưng các ứng dụng của chúng tôi được thiết kế để xử lý kịch bản này. Các bước như sau:
- Cấu hình người tiêu dùng với auto.offset.reset: latest.
- Dừng tất cả các DAG producer.
- Chờ các người tiêu dùng hiện có xử lý các tin nhắn còn lại.
- Chuyển đổi các ứng dụng người tiêu dùng sang Amazon MSK.
Apache Kafka Connect Sinks – Các sink connector của chúng tôi phục vụ hai cơ sở dữ liệu quan trọng:
- Một công cụ tìm kiếm và phân tích phân tán – Việc lập phiên bản tài liệu phụ thuộc vào các offset bản ghi Kafka, khiến việc di chuyển trực tiếp là không thể. Để giải quyết vấn đề này, chúng tôi đã triển khai một giải pháp liên quan đến việc xây dựng các cluster công cụ tìm kiếm mới từ đầu.
- Một cơ sở dữ liệu NoSQL hướng tài liệu – Điều này hỗ trợ di chuyển trực tiếp mà không yêu cầu các instance cơ sở dữ liệu mới, đơn giản hóa đáng kể quy trình.
Các ứng dụng Apache Spark và Flink – Những ứng dụng này đặt ra những thách thức độc đáo do cơ chế checkpointing nội bộ của chúng:
- Các offset được quản lý bên ngoài các nhóm người tiêu dùng của Kafka
- Các checkpoint không tương thích giữa các cluster nguồn và đích
- Yêu cầu xử lý lại dữ liệu hoàn toàn từ đầu

Chúng tôi đã lên lịch các quá trình di chuyển này trong giờ thấp điểm để giảm thiểu tác động.

Lợi ích và cải tiến kỹ thuật

Việc chuyển sang Amazon MSK đã thay đổi cơ bản cách chúng tôi quản lý hạ tầng Kafka của mình. Sự chuyển đổi này được minh họa rõ nhất bằng cách so sánh các tác vụ vận hành chính trước và sau quá trình di chuyển, được tóm tắt trong bảng sau.

Hoạt động	Trước: Kafka tự quản lý	Sau: Amazon MSK
Vá lỗi bảo mật	Yêu cầu thời gian của đội ngũ chuyên trách cho các bản cập nhật Kafka và OS	Hoàn toàn tự động
Phục hồi broker	Cần giám sát và can thiệp thủ công	Hoàn toàn tự động
Xác thực client	Quy trình xoay vòng mật khẩu phức tạp	AWS Identity and Access Management (IAM)
Nâng cấp phiên bản	Quy trình phức tạp đòi hỏi kế hoạch mở rộng	Hoàn toàn tự động

Chi tiết các tác vụ như sau:

Vá lỗi bảo mật (Security patching) – Trước đây, nhóm của chúng tôi đã dành 8 giờ mỗi tháng để áp dụng các bản vá bảo mật Kafka và hệ điều hành (OS) trên toàn bộ đội broker của chúng tôi. Amazon MSK hiện xử lý các bản cập nhật này tự động, duy trì tư thế bảo mật của chúng tôi mà không cần sự can thiệp của kỹ sư.
Phục hồi broker (Broker recovery) – Mặc dù Kafka tự quản lý của chúng tôi có khả năng phục hồi tự động, nhưng mỗi sự cố đều yêu cầu giám sát cẩn thận và đôi khi can thiệp thủ công. Với Amazon MSK, các lỗi node và các vấn đề suy giảm lưu trữ như giảm tốc độ của Amazon Elastic Block Store (Amazon EBS) được AWS xử lý hoàn toàn và giải quyết trong vòng vài phút mà không cần sự tham gia của chúng tôi.
Quản lý xác thực (Authentication management) – Việc triển khai tự quản lý của chúng tôi yêu cầu xoay vòng mật khẩu cho xác thực SASL/SCRAM, một quy trình mất vài ngày để hai kỹ sư phối hợp. Việc tích hợp trực tiếp giữa Amazon MSK và AWS Identity and Access Management (IAM) đã giảm thiểu chi phí này đồng thời tăng cường các kiểm soát bảo mật của chúng tôi.
Nâng cấp phiên bản (Version upgrades) – Việc nâng cấp phiên bản Kafka trong môi trường tự quản lý của chúng tôi đòi hỏi nhiều tuần lập kế hoạch và thử nghiệm cũng như các cửa sổ bảo trì cuối tuần. Amazon MSK quản lý các bản nâng cấp này tự động trong giờ thấp điểm, duy trì các SLA của chúng tôi mà không bị gián đoạn.

Những cải tiến này đã chứng tỏ đặc biệt có giá trị trong các giai đoạn lưu lượng truy cập cao như Black Friday, khi nhóm của chúng tôi trước đây cần các kế hoạch sẵn sàng vận hành mở rộng. Giờ đây, khả năng phục hồi tích hợp của Amazon MSK cung cấp cho chúng tôi các cluster Kafka đáng tin cậy, đóng vai trò là hạ tầng quan trọng cho doanh nghiệp của chúng tôi. Quá trình di chuyển đã giúp chúng tôi có thể chia các cluster nguyên khối của mình thành các cluster MSK nhỏ hơn, chuyên dụng. Điều này đã cải thiện khả năng cách ly dữ liệu, cung cấp phân bổ tài nguyên tốt hơn và tăng cường khả năng dự đoán hiệu suất cho các khối lượng công việc ưu tiên cao.

Những bài học kinh nghiệm

Quá trình di chuyển của chúng tôi sang Amazon MSK đã tiết lộ một số hiểu biết quan trọng có thể giúp các tổ chức khác hiện đại hóa hạ tầng Kafka của họ:

Xác thực của chuyên gia (Expert validation) – Làm việc với các Kiến trúc sư Giải pháp của AWS để xác thực chiến lược di chuyển của chúng tôi đã phát hiện ra một số vấn đề quan trọng từ sớm. Mặc dù nhóm của chúng tôi hiểu rõ các ứng dụng của mình, nhưng các chuyên gia Kafka bên ngoài đã xác định các vấn đề tiềm ẩn với quản lý trạng thái và xử lý offset của người tiêu dùng mà chúng tôi chưa xem xét. Việc xác thực này đã ngăn chặn những sai lầm tốn kém trong quá trình di chuyển.
Xác minh dữ liệu (Data verification) – So sánh dữ liệu giữa các cluster Kafka đã chứng tỏ là một thách thức. Chúng tôi đã xây dựng các công cụ để chụp ảnh nhanh topic ở định dạng Parquet trên Amazon Simple Storage Service (Amazon S3), cho phép so sánh nhanh chóng bằng cách sử dụng các truy vấn Amazon Athena. Cách tiếp cận này đã mang lại cho chúng tôi sự tự tin rằng dữ liệu vẫn nhất quán trong suốt quá trình di chuyển.
Bắt đầu nhỏ (Start small) – Bắt đầu với vũ trụ dữ liệu nhỏ nhất của chúng tôi trong QA đã giúp chúng tôi tinh chỉnh quy trình của mình. Mỗi lần di chuyển tiếp theo đều diễn ra suôn sẻ hơn khi chúng tôi áp dụng các bài học từ các lần lặp trước. Cách tiếp cận dần dần này đã giúp chúng tôi duy trì sự ổn định của hệ thống trong khi xây dựng sự tự tin cho nhóm.
Lập kế hoạch chi tiết (Detailed planning) – Chúng tôi đã tạo các kế hoạch di chuyển cụ thể với từng nhóm, xem xét các yêu cầu và hạn chế riêng của họ. Ví dụ, pipeline học máy của chúng tôi cần xử lý đặc biệt do các yêu cầu quản lý offset nghiêm ngặt. Việc lập kế hoạch chi tiết này đã ngăn chặn các gián đoạn downstream.
Tối ưu hóa hiệu suất (Performance optimization) – Chúng tôi nhận thấy rằng việc sử dụng thông lượng được cấp phát của Amazon MSK (Amazon MSK provisioned throughput) mang lại lợi thế chi phí rõ ràng khi thông lượng lưu trữ trở thành nút thắt cổ chai. Tính năng này đã giúp cải thiện hiệu suất cluster mà không cần mở rộng kích thước instance hoặc thêm broker, cung cấp một giải pháp hiệu quả hơn cho các thách thức về thông lượng của chúng tôi.
Tài liệu (Documentation) – Việc duy trì các runbook di chuyển chi tiết đã chứng tỏ là vô giá. Khi chúng tôi gặp các vấn đề tương tự trong các lần di chuyển khác nhau, việc có các giải pháp được ghi lại đã tiết kiệm đáng kể thời gian khắc phục sự cố.

Kết luận

Trong bài đăng này, chúng tôi đã trình bày cách chúng tôi hiện đại hóa hạ tầng Kafka của mình bằng cách di chuyển sang Amazon MSK. Chúng tôi đã đi qua quy trình ra quyết định, những thách thức gặp phải và các chiến lược được áp dụng. Hành trình của chúng tôi đã biến đổi các hoạt động Kafka từ một hạ tầng tự quản lý, tốn nhiều tài nguyên thành một dịch vụ được quản lý, tinh gọn, cải thiện hiệu quả vận hành, độ tin cậy của nền tảng và năng suất của nhóm. Đối với các doanh nghiệp quản lý hạ tầng Kafka tự quản lý, kinh nghiệm của chúng tôi cho thấy rằng việc chuyển đổi thành công có thể đạt được với kế hoạch và thực hiện đúng đắn. Khi nhu cầu streaming dữ liệu tăng lên, việc hiện đại hóa hạ tầng trở thành một yêu cầu chiến lược để duy trì lợi thế cạnh tranh.

Để biết thêm thông tin, hãy truy cập trang sản phẩm Amazon MSK, và khám phá Hướng dẫn dành cho nhà phát triển toàn diện để tìm hiểu về các tính năng có sẵn giúp bạn xây dựng các ứng dụng dữ liệu streaming có khả năng mở rộng và đáng tin cậy trên AWS.

Về tác giả

Oleh Khoruzhenko
Oleh là Kỹ sư DevOps cấp cao tại Bazaarvoice Inc, chuyên về kiến trúc và tối ưu hóa các giải pháp streaming dữ liệu thông lượng cao. Anh ấy là một chuyên gia trong hệ sinh thái Apache Kafka, sử dụng Apache Kafka Streams để xử lý sự kiện phức tạp và Apache Spark để nhập và chuyển đổi dữ liệu quy mô lớn.

Christian Silva
Christian là Kiến trúc sư Giải pháp cấp cao tại AWS có trụ sở tại Houston, TX. Anh ấy làm việc với các khách hàng nhà cung cấp phần mềm độc lập, giúp họ xây dựng và tối ưu hóa các giải pháp của mình trên AWS. Với nền tảng về kiến trúc đám mây, Christian đam mê mạng và bảo mật, hướng dẫn khách hàng triển khai các hạ tầng đám mây mạnh mẽ và hiệu quả. Ngoài công việc, anh ấy thích dành thời gian cho các con, chơi bóng đá và câu cá.

Aravind Marthineni
Aravind là Quản lý Tài khoản Kỹ thuật tại AWS có trụ sở tại Austin, TX. Anh ấy hỗ trợ các khách hàng SaaS trong lĩnh vực thương mại điện tử và phân tích mạng xã hội về các dự án di chuyển và hiện đại hóa bằng cách sử dụng kiến trúc dựa trên đám mây. Anh ấy chuyên về quản trị đám mây và đam mê giúp khách hàng vận hành hiệu quả trên đám mây bằng cách sử dụng AI tạo sinh. Khi không làm việc, anh ấy thích chơi và dạy cricket cho đứa con 2 tuổi của mình và nấu các món ăn Ấn Độ.