Serverless Computing Là Gì? Ưu Nhược Điểm, Chi Phí & Triển Khai

Serverless computing là mô hình kiến trúc đám mây cho phép lập trình viên chạy mã nguồn mà không cần trực tiếp vận hành hoặc quản trị hạ tầng máy chủ. Tuy nhiên, kiến trúc không máy chủ không phải là giải pháp vạn năng thay thế hoàn toàn cho máy chủ truyền thống. Nếu bạn đang phân vân giữa việc viết các hàm lambda không trạng thái hay duy trì một hệ thống máy chủ Linux chuyên dụng cho ứng dụng của mình, bài viết này sẽ phân tích chi tiết từng khía cạnh kỹ thuật, chi phí và hướng dẫn triển khai thực tế. Bạn có thể tham khảo thêm các giải pháp hạ tầng máy chủ tại InterData để lựa chọn nền tảng phù hợp nhất cho doanh nghiệp.

1. Serverless computing là gì và cơ chế hoạt động cốt lõi?

Serverless computing là mô hình thực thi trong cloud computing, nơi nhà cung cấp dịch vụ đám mây tự động quản lý việc cấp phát, co giãn tài nguyên và bảo trì máy chủ vật lý. Lập trình viên chỉ cần triển khai từng đoạn mã nghiệp vụ (function) và trả phí chính xác theo số lượng tài nguyên tính toán tiêu thụ trên từng mili-giây thực thi.

Dù mang tên là “không máy chủ”, máy chủ vật lý vẫn tồn tại ở tầng bên dưới. Sự khác biệt nằm ở việc trừu tượng hóa: nhà phát triển không cần cài đặt hệ điều hành, cấu hình web server như Nginx/Apache, cập nhật bản vá bảo mật hay thiết lập cụm cân bằng tải (load balancer). Hệ thống serverless được phân tách thành hai nhánh chính:

• FaaS (Function-as-a-Service): Trọng tâm của mô hình serverless, cho phép chạy các hàm đơn lẻ đáp ứng lại sự kiện (event-driven). Ví dụ: AWS Lambda, Google Cloud Functions, Azure Functions.
• BaaS (Backend-as-a-Service): Các dịch vụ quản lý backend sẵn có giúp ứng dụng hoạt động mà không cần tự build API, bao gồm quản lý cơ sở dữ liệu (Amazon DynamoDB, Firebase Firestore), xác thực người dùng (Auth0, AWS Cognito) hay lưu trữ đối tượng (Amazon S3).

Cơ chế vòng đời của một Serverless Function

Một hàm serverless tuân thủ chặt chẽ mô hình hướng sự kiện (event-driven) và phi trạng thái (stateless). Khi một sự kiện kích hoạt (HTTP request từ API Gateway, file mới tải lên storage, bản ghi cơ sở dữ liệu thay đổi), quy trình sau diễn ra:

1. Khởi tạo môi trường (Cold Start): Nếu chưa có container nào rảnh rỗi, nền tảng sẽ tải mã nguồn, khởi chạy container runtime (Node.js, Python, Golang) và nạp thư viện phụ thuộc.
2. Thực thi mã nguồn (Invocation): Mã của bạn tiếp nhận payload sự kiện, thực hiện tính toán và trả về kết quả.
3. Đóng băng tài nguyên (Warm State): Sau khi chạy xong, container được giữ lại trong bộ nhớ tạm thời từ 5 đến 15 phút để sẵn sàng phục vụ request tiếp theo mà không bị trễ.
4. Thu hồi hạ tầng (Teardown): Nếu không có request mới, container tự động bị hủy để giải phóng tài nguyên.

2. So sánh Serverless computing với VPS và Cloud Server

Khi thiết kế hệ thống phần mềm, quyết định lựa chọn giữa serverless, máy chủ ảo riêng VPS hay máy chủ đám mây (Cloud Server) phụ thuộc trực tiếp vào đặc thù tải công việc (workload), thời gian chạy liên tục và yêu cầu kiểm soát hệ thống.

Tiêu chí kỹ thuật	Serverless Computing (FaaS)	Máy Chủ Ảo VPS	Cloud Server Doanh Nghiệp
Cơ chế tính cước	Mili-giây thực thi + Số lượng request	Cố định theo tháng / năm	Cố định hoặc theo tài nguyên thực tế
Khả năng co giãn (Scaling)	Tự động co giãn tức thời từ 0 đến N	Thủ công theo giới hạn phần cứng	Mở rộng dọc/ngang linh hoạt theo nhu cầu
Quyền quản trị hệ thống	Không có root access, runtime cố định	Toàn quyền Root/Administrator	Toàn quyền Root/Administrator
Giới hạn thời gian chạy	Tối đa 15 phút/lần gọi (AWS Lambda)	Không giới hạn (24/7/365)	Không giới hạn (24/7/365)
Workload phù hợp nhất	Webhooks, xử lý file, cronjobs, microservices	Website, e-commerce, VPN, dev staging	Hệ thống ERP, Database, High Traffic Web

Nếu bạn đang cân nhắc giữa việc tự vận hành hệ thống container hay thuê cụm ảo hóa, bài viết so sánh Cloud Server và VPS sẽ cung cấp các tiêu chí rõ ràng hơn về kiến trúc lưu trữ SAN/Ceph so với local storage. Đối với các hệ sinh thái phức tạp gồm nhiều thành phần phân tán, quản trị cụm thông qua Kubernetes hoặc làm theo hướng dẫn cài đặt Docker trên VPS là phương án được nhiều doanh nghiệp ưu tiên để tránh tình trạng khóa chặt nhà cung cấp (vendor lock-in).

3. Thực hành triển khai serverless computing trên AWS Lambda qua AWS SAM

Để triển khai một hàm serverless computing trên AWS Lambda chuẩn production, sử dụng AWS Serverless Application Model (AWS SAM) là giải pháp tiêu chuẩn giúp quản lý tài nguyên dưới dạng mã (Infrastructure as Code).

Bước 1: Cài đặt AWS CLI và AWS SAM CLI trên Linux

Chạy các lệnh sau trên terminal của máy chủ phát triển (Ubuntu 22.04 / 24.04 LTS):

# Cài đặt AWS CLI v2
curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
unzip -q awscliv2.zip
sudo ./aws/install

# Xác minh phiên bản AWS CLI
aws --version

# Cài đặt AWS SAM CLI
wget https://github.com/aws/aws-sam-cli/releases/latest/download/aws-sam-cli-linux-x86_64.zip
unzip -q aws-sam-cli-linux-x86_64.zip -d sam-installation
sudo ./sam-installation/install

# Kiểm tra phiên bản SAM CLI
sam --version

Bước 2: Cấu hình thông tin xác thực AWS

Nhập access key và region gần nhất (khu vực Singapore: ap-southeast-1):

aws configure

Bước 3: Khởi tạo cấu trúc dự án Python Serverless

sam init \
  --runtime python3.12 \
  --name interdata-serverless-api \
  --app-template "hello-world" \
  --no-interactive

Bước 4: Định nghĩa logic hàm xử lý (app.py)

Truy cập vào thư mục interdata-serverless-api/hello_world/app.py và cập nhật mã nguồn:

import json

def lambda_handler(event, context):
    query_params = event.get("queryStringParameters") or {}
    user_name = query_params.get("name", "Developer")
    
    payload = {
        "status": "success",
        "message": f"Xin chao {user_name}, he thong Serverless hoat dong tot!",
        "requestId": context.aws_request_id
    }
    
    return {
        "statusCode": 200,
        "headers": {
            "Content-Type": "application/json",
            "Access-Control-Allow-Origin": "*"
        },
        "body": json.dumps(payload)
    }

Bước 5: Đóng gói và phát hành ứng dụng lên đám mây

cd interdata-serverless-api
# Build dependencies bên trong container hoặc môi trường local
sam build

# Deploy có điều hướng
sam deploy --guided

Bước 6: Kiểm tra hoạt động thực tế của hàm

# Gọi trực tiếp qua AWS CLI
aws lambda invoke \
  --function-name interdata-serverless-api-HelloWorldFunction-xxxx \
  --payload '{"queryStringParameters": {"name": "InterData"}}' \
  --cli-binary-format raw-in-base64-out \
  response.json

# Đọc kết quả phản hồi
cat response.json

4. Thực hành triển khai serverless computing trên Google Cloud Functions

Google Cloud Functions (2nd Gen) cung cấp môi trường serverless dựa trên công nghệ container Knative, tích hợp liền mạch với Cloud Run. Dưới đây là các bước triển khai trực tiếp bằng Node.js 20 và gcloud CLI.

Bước 1: Khởi tạo mã nguồn Node.js

mkdir -p ~/gcf-service && cd ~/gcf-service

# Khởi tạo package.json
cat << 'EOF' > package.json
{
  "name": "gcf-service",
  "version": "1.0.0",
  "main": "index.js",
  "dependencies": {
    "@google-cloud/functions-framework": "^3.3.0"
  }
}
EOF

# Tạo file thực thi index.js
cat << 'EOF' > index.js
const functions = require('@google-cloud/functions-framework');

functions.http('handleRequest', (req, res) => {
  const clientIp = req.headers['x-forwarded-for'] || req.socket.remoteAddress;
  res.status(200).json({
    timestamp: new Date().toISOString(),
    client_ip: clientIp,
    environment: 'Google Cloud Functions Gen2'
  });
});
EOF

Bước 2: Triển khai function lên Cloud Functions Gen2

gcloud functions deploy interdata-http-handler \
  --gen2 \
  --runtime=nodejs20 \
  --region=asia-southeast1 \
  --source=. \
  --entry-point=handleRequest \
  --trigger-http \
  --allow-unauthenticated \
  --memory=256MiB \
  --timeout=15s

Bước 3: Gửi HTTP Request kiểm tra endpoint

# Lấy URL endpoint
FUNCTION_URL=$(gcloud functions describe interdata-http-handler --gen2 --region=asia-southeast1 --format='value(serviceConfig.uri)')

# Gửi HTTP GET request
curl -s -i "$FUNCTION_URL"

5. Use Case 1: Xây dựng REST API không máy chủ cho ứng dụng di động

Mô hình REST API không máy chủ đặc biệt phù hợp với các ứng dụng di động có lưu lượng truy cập biến thiên mạnh theo khung giờ (ví dụ: giờ ăn trưa cho app đặt món, giờ tan tầm cho app gọi xe). Khi lưu lượng bằng không vào ban đêm, chi phí tính toán đưa về mức 0.

Sơ đồ luồng dữ liệu kiến trúc

Mô hình bao gồm 3 lớp độc lập: Amazon API Gateway (tiếp nhận HTTP, định tuyến, rate limiting) → AWS Lambda (chạy mã xác thực JWT và xử lý logic) → Amazon DynamoDB (lưu trữ NoSQL với độ trễ phản hồi dưới 10ms).

File cấu hình SAM Template (template.yaml) hoàn chỉnh

AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31
Description: Serverless REST API cho Mobile Backend

Resources:
  MobileApiGateway:
    Type: AWS::Serverless::Api
    Properties:
      StageName: prod
      Cors:
        AllowMethods: "'GET,POST,OPTIONS'"
        AllowHeaders: "'Content-Type,Authorization'"
        AllowOrigin: "'*'"

  GetUserProfileFunction:
    Type: AWS::Serverless::Function
    Properties:
      CodeUri: src/
      Handler: user.get_profile
      Runtime: python3.12
      MemorySize: 256
      Timeout: 5
      Policies:
        - DynamoDBReadPolicy:
            TableName: !Ref UsersTable
      Events:
        GetUser:
          Type: Api
          Properties:
            RestApiId: !Ref MobileApiGateway
            Path: /users/{userId}
            Method: get

  UsersTable:
    Type: AWS::DynamoDB::Table
    Properties:
      TableName: mobile_users
      BillingMode: PAY_PER_REQUEST
      AttributeDefinitions:
        - AttributeName: userId
          AttributeType: S
      KeySchema:
        - AttributeName: userId
          KeyType: HASH

6. Use Case 2: Pipeline xử lý dữ liệu và hình ảnh tự động theo sự kiện

Xử lý tệp tin đa phương tiện là bài toán kinh điển trong kiến trúc serverless. Thay vì để một worker chạy ngốn RAM liên tục trên máy chủ chuyên dụng, hàm lambda chỉ được khởi tạo khi có tệp ảnh hoặc video được tải lên bucket S3.

Triển khai hàm tối ưu hóa hình ảnh với Node.js và Sharp

const { S3Client, GetObjectCommand, PutObjectCommand } = require('@aws-sdk/client-s3');
const sharp = require('sharp');

const s3 = new S3Client();

exports.handler = async (event) => {
  for (const record of event.Records) {
    const srcBucket = record.s3.bucket.name;
    const srcKey = decodeURIComponent(record.s3.object.key.replace(/\+/g, ' '));
    const dstKey = `thumbnails/${srcKey.replace('raw/', '')}`;

    try {
      // 1. Tải ảnh gốc từ S3
      const getObjectParams = { Bucket: srcBucket, Key: srcKey };
      const response = await s3.send(new GetObjectCommand(getObjectParams));
      const streamToBuffer = (stream) => new Promise((resolve, reject) => {
        const chunks = [];
        stream.on('data', (chunk) => chunks.push(chunk));
        stream.on('error', reject);
        stream.on('end', () => resolve(Buffer.concat(chunks)));
      });
      const inputBuffer = await streamToBuffer(response.Body);

      // 2. Tối ưu và resize kích thước ảnh về chuẩn 400x400 WebP
      const outputBuffer = await sharp(inputBuffer)
        .resize({ width: 400, height: 400, fit: 'inside' })
        .webp({ quality: 80 })
        .toBuffer();

      // 3. Đẩy ảnh đã xử lý về Bucket
      await s3.send(new PutObjectCommand({
        Bucket: srcBucket,
        Key: dstKey,
        Body: outputBuffer,
        ContentType: 'image/webp'
      }));

      console.log(`Xu ly thanh cong anh: ${dstKey}`);
    } catch (error) {
      console.error(`Loi xu ly anh ${srcKey}:`, error);
      throw error;
    }
  }
};

7. Bảo mật và tối ưu hóa serverless computing trong Production

Việc chuyển dịch sang mô hình serverless không đồng nghĩa với việc bảo mật được ủy thác 100% cho nhà cung cấp đám mây. Trách nhiệm bảo mật mã nguồn, phân quyền tài nguyên và giám sát vẫn thuộc về đội ngũ kỹ sư phát triển.

Nguyên tắc phân quyền tối thiểu (Least Privilege IAM Role)

Không bao giờ gán quyền AdministratorAccess hoặc quyền wildcard * cho execution role của hàm. Luôn giới hạn chính xác Action và Resource trong tệp IAM policy:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "dynamodb:GetItem",
        "dynamodb:PutItem"
      ],
      "Resource": "arn:aws:dynamodb:ap-southeast-1:123456789012:table/mobile_users"
    },
    {
      "Effect": "Allow",
      "Action": [
        "logs:CreateLogGroup",
        "logs:CreateLogStream",
        "logs:PutLogEvents"
      ],
      "Resource": "arn:aws:logs:ap-southeast-1:123456789012:*"
    }
  ]
}

Giải pháp xử lý độ trễ khởi động nguội (Cold Start)

• Lựa chọn ngôn ngữ thông dịch nhẹ: Node.js, Python hoặc Golang có thời gian cold start dưới 200ms, trong khi Java hoặc .NET có thể mất từ 1.5s đến 3s để tải framework.
• Giảm thiểu kích thước Artifact: Loại bỏ các module không cần thiết trong node_modules hoặc dùng Webpack/esbuild để đóng gói thành 1 file JavaScript duy nhất.
• Bật Provisioned Concurrency: Giữ sẵn một số lượng container luôn ở trạng thái warm đối với các API yêu cầu SLA độ trễ khắt khe.

8. Xử lý các sự cố thường gặp khi vận hành serverless computing

Sự cố 1: Lỗi Task Timed Out After 3.00 Seconds

Dấu hiệu nhận biết: Log trên AWS CloudWatch trả về mã lỗi Task timed out after 3.00 seconds, client nhận lỗi HTTP 504 Gateway Timeout.

Nguyên nhân: Mặc định cấu hình timeout của AWS Lambda là 3 giây, trong khi tác vụ kết nối cơ sở dữ liệu ngoài vùng VPC hoặc xử lý dữ liệu nặng vượt quá mốc này.

Lệnh xử lý tức thì: Tăng thời gian chờ thực thi lên 30 giây bằng lệnh sau:

aws lambda update-function-configuration \
  --function-name interdata-serverless-api-HelloWorldFunction \
  --timeout 30 \
  --region ap-southeast-1

Sự cố 2: Tràn bộ nhớ (Process Out of Memory)

Dấu hiệu nhận biết: CloudWatch Log xuất hiện thông báo Memory Size: 128 MB Max Memory Used: 128 MB đi kèm trạng thái crash Runtime.ExitError.

Nguyên nhân: Dung lượng bộ nhớ RAM mặc định (128 MB) không đủ để xử lý tác vụ nạp thư viện hoặc buffer dữ liệu lớn vào bộ nhớ.

Lệnh xử lý tức thì: Nâng cấp RAM của hàm lên 512 MB (AWS Lambda đồng thời cấp thêm vCPU tương ứng theo tỷ lệ RAM):

aws lambda update-function-configuration \
  --function-name interdata-serverless-api-HelloWorldFunction \
  --memory-size 512 \
  --region ap-southeast-1

Sự cố 3: Lỗi cạn kiệt kết nối cơ sở dữ liệu (Database Connection Exhaustion)

Dấu hiệu nhận biết: MySQL hoặc PostgreSQL báo lỗi Too many connections khi lưu lượng request tăng đột biến trong thời gian ngắn.

Nguyên nhân: Mỗi container lambda khi khởi tạo tự mở một connection pool riêng tới database. Khi có 1,000 hàm chạy song song, hệ thống sẽ mở 1,000 kết nối đồng thời làm sập database truyền thống.

Giải pháp khắc phục: Giới hạn số lượng hàm thực thi đồng thời (Reserved Concurrency) hoặc triển khai hệ thống connection proxy trung gian (RDS Proxy):

aws lambda put-function-concurrency \
  --function-name interdata-serverless-api-HelloWorldFunction \
  --reserved-concurrent-executions 20 \
  --region ap-southeast-1

Nội dung mang tính tham khảo kỹ thuật. Lệnh, cú pháp, đường dẫn file và cấu hình SDK đám mây có thể thay đổi tùy theo phiên bản phần mềm và chính sách của nhà cung cấp dịch vụ tại thời điểm triển khai. Vui lòng kiểm thử kỹ lưỡng trên môi trường staging trước khi áp dụng vào hệ thống thực tế.