Author: linh

  • Infrastructure as Code

    Infrastructure as Code

    Lời nói đầu

    Với sự phát triển manh mẽ của Cloud Computing, các ứng dụng mà đơn vị GST đang phát triển được xây dựng trên cloud như AWS ngày càng nhiều. Việc quản lý resource trên cloud cũng là một vấn đề cực kì quan trọng. Hôm nay mình sẽ giới thiệu về Infrastructure as Code(IaC) và Terraform, những công cụ giúp chúng ta quản lý resource cloud dễ dàng hơn.

    Nội dung

    Vấn đề

    Như đã nói ở phía trên, vấn đề chúng ta bàn đến chính là quản lý resouce cloud(AWS, Azure, GPC..). Tại sao lại phải quản lý? Lý do là mỗi dự án sử dụng khoảng 10-15 services, mỗi service có khoảng 1-10 resources, mỗi resource lại có nhiều config khác nhau. Vì vậy nếu không quản lý tốt, sẽ rất dễ bị miss resource, hoặc config giữa các resource khác nhau giữa các môi trường, lúc tạo môi trường mới mất nhiều thời gian để config, compare các môi trường với nhau, rủi ro khi xử lý manual là rất lớn. Vì vậy việc sử dụng tool để quản lý resource là cần thiết và vô cùng quan trọng. Infrastructure as Code đã được sinh ra để giải quyết các vấn đề đó.

    Infrastructure as Code

    Định nghĩa IaC thì mỗi ông định nghĩa 1 kiểu, sau đây mình sẽ trích dẫn định nghĩa mà mình cho là khá dễ hiểu:

    Infrastructure as code (IaC) is the process of managing and provisioning computer data centers through machine-readable definition files, rather than physical hardware configuration or interactive configuration tools. The IT infrastructure managed by this process comprises both physical equipment, such as bare-metal servers, as well as virtual machines, and associated configuration resources. The definitions may be in a version control system. It can use either scripts or declarative definitions, rather than manual processes, but the term is more often used to promote declarative approaches.

    Refer: https://docs.microsoft.com/en-us/devops/deliver/what-is-infrastructure-as-code

    Hiểu một cách đơn giản hơn thì IaC có nghĩa là chúng ta sử dụng các đoạn code theo format có sẵn(giống như 1 ngôn ngữ lập trình hoặc 1 dạng template: yaml, json..) để quản lý các resource của hệ thống. Khi cần thêm, sửa, xoá 1 resource thì update vào code và apply để thay đổi infra.

    Cụ thể IaC giải quyết vấn đề gì?

    • Giải quyết vấn đề đồng bộ giữa các môi trường, không có chuyện môi trường staging 1 kiểu, môi trường prd config lại khác, vì resource cùng sinh ra từ 1 đoạn code
    • Giảm thiểu chi phí xây dựng môi trường. Ban đầu sẽ hơi mất thời gian 1 chút để tạo các resource bằng code, tuy nhiên sau khi dựng xong 1 môi trường hoàn chỉnh, tạo các môi trường khác thì chỉ cần sử dụng lại code đã tạo cho môi trường đầu tiên. Nếu có 1,2 môi trường thì lợi ích có thể ít, nhưng mình đã làm 1 dự án có 9 môi trường, việc này tiết kiệm rất nhiều thời gian
    • Khả năng tái sử dụng: Ví dụ Project A sử dụng VPC, Subnet, EC2 server, Project B cũng sử dụng các resource như vậy, chúng ta có thể tái sử dụng lại source code infra của A, optimize lại 1 chút để sử dụng luôn cho project B
    • Automation: Việc tự động tạo, update, xoá các resource khiến cho việc thục hiện manual được ít đi rất nhiều, giảm thiểu rủi ro do ngứa tay

    Một số Iac tool phổ biến:

    Terraform

    Để dễ hình dung hơn về IaC, mình sẽ giới thiệu về Terraform, một IaC tool khá phổ biến.
    Terraform là gì?

    Terraform là một IaC tool mã nguồn mở, công cụ phần mềm mã cung cấp quy trình làm việc CLI nhất quán để quản lý hàng trăm dịch vụ đám mây. Terraform mã hóa các API đám mây thành các file khai báo cấu hình.

    Một số điểm đáng chú ý:

    • Phát triển bằng Go
    • Phát triển bời HashiCorp, công ty với mục tiêu cách mạng hóa việc quản lý trung tâm dữ liệu: phát triển, phân phối và bảo trì ứng dụng
    • Multi cloud: Support tạo resource cho nhiều cloud provider khác nhau: AWS, Azure, GPC, Oracle..
    • Cung cấp cơ sở hạ tầng trên hơn 300 đám mây và dịch vụ public bằng cách sử dụng một quy trình làm việc duy nhất

    Terraform hoạt động thế nào?

    Terraform cho phép cơ sở hạ tầng được thể hiện dưới dạng mã bằng một ngôn ngữ đơn giản, con người có thể đọc được gọi là HCL (HashiCorp Configuration Language). Nó đọc các file cấu hình và cung cấp một kế hoạch thực hiện các thay đổi, có thể được xem xét để đảm bảo an toàn, sau đó mới áp dụng các thay đổi.

    Các nhà cung cấp có thể mở rộng cho phép Terraform quản lý nhiều loại tài nguyên, bao gồm IaaS, PaaS, SaaS và các dịch vụ phần cứng.

    Ví dụ Terraform và 1 số câu lệnh đơn giản

    Syntax cơ bản của Terraform

    Khi muốn apply code lên Infra của mình, thực hiện câu lệnh

    terraform apply

    Khi muốn xem sự thay đổi của code hiện tại với trạng thái trước khi thay đổi

    terraform plan

    Kết quả sau khi apply thành công

    Export file terraform thành dạng graph sử dụng lệnh

    terraform graph | dot -Tsvg > graph.svg

    Kết quả sẽ là file svg có tên là graph.svg, dùng extension để view file, ta có kết quả như sau

    CICD với terraform

    Terraform là code, thực hiện quản lý, thay đổi tác động đến Infra của hệ thống. Vậy đã là code thì hoàn toàn có thể apply deploy tự động.

    Cơ bản CICD với Terraform cũng giống như IaC với ngôn ngữ khác, thay vì các lệnh build thì chúng ta thay bằng các command của terraform.

    Kết luận

    Bài viết này mình đã giới thiệu về Infrastructure as Code, tại sao lại cần đến nó, lợi ích khi sử dụng. Mình cũng đã giới thiệu ngắn gọn về một IaC tool khá phổ biến là Terraform. Mong rằng bài viết sẽ cho mọi người thấy được tầm quan trọng của IaC và có thể nghiên cứu apply vào dự án của mình.

  • Case study ứng dụng serverless trên AWS phục vụ Olympic Tokyo

    Case study ứng dụng serverless trên AWS phục vụ Olympic Tokyo

    Lời nói đầu

    Ở đâu đó có thể các bạn đã nghe thấy khái niệm serverless hay chạy ứng dụng không mà không cần sử dụng một server nào (non-server). Hiện nay với sự phát triển mạnh mẽ của các nền tảng public cloud như AWS, Azure, Alibaba.., khái niệm serverless đang dần trở nên thân thuộc hơn với những lập trình viên. Tuy nhiên bạn đã bao giờ tự tay xây dựng một hệ thống API mà không phải sử dụng server bao giờ chưa? Theo mình thấy thì hiện tại sự trải nghiệm của các dev với serverless thực sự chưa nhiều, một phần có lẽ do người ta vẫn tin tưởng ở server truyền thống hơn(Cái gì sờ thấy được cũng chắc chắn hơn). Ở loạt bài này, mình sẽ trình bày về một dự án team mình xây dựngAPI 100% sử dụng serverless . Mình sẽ tập trung vào kiến trúc hệ thống, giải thích các thành phần và framework hỗ trợ deploy serverless nhé!

    Nội dung

    Bối cảnh

    Khách hàng của mình đã xây dựng hệ thống trên môi trường AWS, sử dụng EC2 làm server, ngôn ngữ là Java và sử dụng framework là Struts . Hệ thống hiện tại chi phí đang quá lớn (Bao gồm cả chi phí AWS cũng như các chi phí liên quan khác), thời gian sử dụng và chạy job trong ngày là không cố định(do nghiệp vụ), nhiều khi không có người sử dụng cũng như không có job nào chạy nhưng cũng phải trả tiền cho 1 server API và 1 server Job. Khách hàng đã yêu cầu chuyển hệ thống cũ sang serverless và phát triển thêm tính năng dựa trên kiến trúc mới này. Hệ thống này mình xây dựng hoàn toàn trên Amazon Web Service, nên các dịch vụ cứ mặc định là của AWS nhé!

    Mô hình hệ thống Serverless

    Có lẽ nhiều người cũng đã nhìn qua kiến trúc serverless như thế này:



    Đúng, nó là 1 kiến trúc chung thường thấy của 1 serverless system triển khai trên AWS. Flow sẽ là:

    • App call API qua API Gateway
    • API Gateway trigger lambda
    • Lambda query data từ DB, trả về kết quả
    • API Gateway response data cho client

    Bla…Bla..

    Tuy nhiên, để ứng dụng nó vào 1 dự án cụ thể cần nhiều hơn thế này, theo dõi phần tiếp theo nhé!

    Hệ thống Serverless trong thực tế

    Mỗi hệ thống sẽ có những điểm giống và khác nhau tuỳ thuộc vào bài toán cần giải quyết. Không loằng ngoằng mình sẽ đưa ra kiến trúc mình đã xây dựng luôn (Đã lược bỏ một số chi tiết, tập trung chính vào phần serverless)

    Overview hệ thống này nhé:

    • Phần màu đỏ là hosting cho Frontend(được viết bằng Angular xxx). Phần FrontEnd sẽ bao gồm một S3 Bucket được setting làm static web, 1 Cloudfront Distribution để cache lại các resource tĩnh GLOBAL.
    • Phần màu xanh là hệ thống API serverless. Chúng ta sẽ quan tâm đến phần này nhiều hơn vì nó là trọng tâm của bài viết này. Nó bao gồm những dịch vụ gì, đi lần lượt nhé:
      • WAF: Web Application Firewall – Đây được coi là bức tường lửa đầu tiên để bảo vệ web. Nhiêm vụ của nó là bảo vệ app qua rule do người dùng thiết lập, ví dụ Whitelist IP, Blacklist IP… Quan trọng hơn là nó có thể phát hiện và chặn những request có dấu hiệu tấn công như XSS, SQL Injection….
      • API Gateway: Điểm nhận tất cả các request từ phía client. AWS cho phép route từng path của request đến những handler tương ứng.
      • Cognito: Dịch vụ này cung cấp phương thức xác thực, phân quyền và quản lý người dùng.
      • Lambda (Authenticate): Vì app của mình có tính năng authen hơi đặc biệt, do vậy mình phải dùng lambda function này để add thêm 1 số feature mà Cognito không đáp ứng đủ. Lambda function này sẽ được đính trực tiếp vào API Gateway, đóng vai trò tương tự như 1 middleware, cũng đặt trong private subnet nhé, nhưng vẽ như thế để tránh rối
      • VPC, Public subnet và private subnet: Cái này nếu ai đã làm qua với AWS và network của nó thì có thể nắm được rồi. Public subnet thì có thể internet facing, private subet là nơi đặt các server EC2, RDS, Lambda là private. Không thể truy cập trực tiếp từ internet vào các dịch vụ được đặt trong private subnet.
      • InternetGateway cho phép VPC có thể truy cập Internet, VPC Endpoint cho phép kết nối đến các dịch vụ khác của AWS mà ko qua đường truyền internet
      • Squid Proxy Server: Đóng vai trò là proxy cho phép các resource từ private subet kết nối ra ngoài Internet(Nhiều người sẽ dùng NAT Gateway hoặc NAT Instance).
      • Lambda (Đặt trong private subnet): Đây chính là linh hồn của Serverless, đóng vai trò tương tự 1 server. Mỗi path của API Gateway sẽ được xử lý bởi 1 lambda function. Lambda sẽ nhận request từ API Gateway, xử lý, trả response về API Gateway -> Response về Client
      • S3: Nếu ko có server thì file được lưu trữ ở đâu, up/down thế nào? Thông thường nếu hệ thống sử dụng autoscale thì cũng cần 1 nơi lưu trữ file chung (EFS hoặc S3 ….). Với Lambda cũng vậy, mình chọn S3 để lưu trữ file. Nhưng làm thế nào để upload và download file qua lambda nhỉ. Câu trả lời là sẽ không up/download file qua lambda, lambda chỉ là trung gian, generate Pre-signed URL để client thực hiện upload và download trực tiếp với S3.
      • DynamoDB: Đây là 1 database dạng NoSQL do AWS phát triển. Lưu data dạng Key-Value. Nếu cần thiết phải sử dụng CSDL quan hệ, mình khuyến khích dùng AWS Aurora serverless(MySQL hoặc PostgreSQL), hỗ trợ tốt nếu sử dụng serverless
      • CloudWatch: Phần này có 1 số dịch vụ nhỏ hơn. Tuy nhiên có 2 service chính là Logs và Rules. Logs là nơi xem, truy vấn log mà Lambda function đã ghi ra trong quá trình chạy, Rules được sử dụng để lập lịch cho 1 số job chạy cố định hàng ngày, khi đến thời gian nó sẽ gọi lambda function tương ứng.
      • SQS: Queue được dùng cho sử dụng cho những job muốn chạy ngay lập tức. SQS trigger đến Lambda function(Job) mỗi khi có message mới được đẩy vào queue.
      • X-Ray: Service này khá hay, nó giúp monitor ứng dụng một cách chi tiết hơn, visualize nó lên trên dashboard AWS, giúp gỡ lỗi ứng dụng, phán đoán lỗi cũng như cải tiến ứng dụng tốt hơn. Ví dụ: Thời gian query data từ DynamoDb, thời gian upload file S3…….
      • SNS: Gửi notification.

    Serverless framework

    Nếu đã từng làm việc với lambda, mọi người sẽ biết được rằng mỗi Lambda function là độc lập với nhau, source code vì vậy cũng hoàn toàn riêng biệt. Vậy với 1 project lớn bao gồm hàng trăm API, làm thế nào chúng ta quản lý source code và deploy, không thể build và upload bản build cho từng lambda function được. Vì vậy team đã quyết định sử dụng framework là serverless(https://www.serverless.com)

    Serverless framework là fw hỗ trợ nhiều cloud provider phổ biến như AWS, Azure, GPC, Alibaba… Nó cung cấp cho chúntg ta 1 công cụ để quản lý full life cycle cho ứng dụng serverless. Serverless framework cũng hỗ trợ nhiều ngôn ngữ như Java, Nodejs, Go, Python …

    Cấu hình serverless:
    Tư tưởng của framework hiểu đơn giản là chúng ta cần mapping Path của API Gateway với class, file xử lý logic cho function tương ứng.

    Đây là 1 file cấu hình sample của project serverless. Một số thành phần quan trọng bao gồm:

    • provider
      • name: Tên cloud provider(aws, gpc, azure)
      • runtime: Môi trường thực thi(java8, java11, nodejs12..)
    • package:
      • artifact: Đường dẫn trỏ đến file build
    • functions: List API của project
      • Tên lambda function:
        • handler: class xử lý logic cho API
        • events:
          • http: (nếu là HTTP thì lambda function này sẽ được trigger từ API Gateway)
            • path: Đường dẫn API
            • method: HTTP method(get, post …)

    Mình chỉ giới thiệu qua cấu hình cơ bản của serverless. Lợi ích của nó là giúp chúng ta dễ dàng quản lý life cycle của project serverless, sử dụng các architype có sẵn khi tạo project.

    Tổng kết lại

    Túm lại, để nói về 1 serverless system thì 1 bài viết là không đủ. Ở phần này mình chỉ overview hệ thống, các dịch vụ và vai trò của nó . Mong rằng qua bài viết này các bạn có thể nắm được cơ bản về kiến trúc 1 hệ thống không sử dụng server truyền thống nó như thế nào, đánh giá xem có thể apply trực tiếp vào dự án tiếp theo được không. Mong rằng sẽ có nhiều hơn dự án sử dụng serverless trong đơn vị để mọi người có thêm những trải nghiệm mới.