Trong những năm đầu đi làm và có cơ hội làm việc các dự án Nhật, tôi được tham gia vào nhiều dự án phát triển hệ thống quản lý sản xuất.

Qua quá trình đó, tôi nhận ra cách người Nhật tổ chức tài liệu thiết kế phần mềm

— gồm Basic Design và Detail Design

— là nền tảng cốt lõi của toàn bộ quy trình phát triển. Mọi thứ được mô tả chi tiết, có quy tắc, và giúp đội dự án hiểu cùng một ngôn ngữ.

Bài viết này chia sẻ cách hiểu, cấu trúc và phương pháp viết tài liệu thiết kế phần mềm trong môi trường dự án Nhật Bản, dựa trên kinh nghiệm thực tế triển khai nhiều module sản xuất khác nhau.

(Lưu ý: các ảnh trong bài đăng được tham khảo từ nhiều nguồn kỹ thuật trang web Nhật để giúp minh họa rõ hơn cho nội dung)

1. Phân biệt Basic Design và Detail Design

Basic Design (基本設計書) là tài liệu mô tả tổng quan hệ thống: định nghĩa phạm vi, quy tắc nghiệp vụ, và luồng xử lý chính.

Đây là giai đoạn “thiết kế khung”.

Detail Design (詳細設計書) là tài liệu triển khai chi tiết, mô tả rõ cách hệ thống hoạt động bên trong: logic xử lý, cấu trúc dữ liệu, và cách các thành phần giao tiếp với nhau.

Đây là bước “thiết kế chi tiết kỹ thuật”.

Basic Design giúp toàn bộ nhóm hiểu “hệ thống cần làm gì”,

Detail Design giúp kỹ sư nắm rõ “hệ thống sẽ làm như thế nào”.

Hai giai đoạn này gắn liền với nhau và quyết định trực tiếp đến chất lượng dự án.

2. Cấu trúc của Basic Design

Trong dự án Nhật, Basic Design thường có cấu trúc tiêu chuẩn như sau:

• Tên hệ thống và module: ví dụ “生産管理システム (Production Management System)”.
• Tên màn hình hoặc chức năng: ví dụ “P_I201 – 生産指示登録画面 (Màn hình đăng ký lệnh sản xuất)”.
• Mục tiêu: mô tả mục đích nghiệp vụ của chức năng (ví dụ: đăng ký, sửa, xóa lệnh sản xuất theo mã sản phẩm).
• Luồng xử lý tổng quan: trình bày sơ đồ xử lý từ nhập dữ liệu đến lưu trữ và phản hồi.
• Dữ liệu chính: mô tả các bảng liên quan như ProductionOrder, ProductMaster, LineMaster…
• Quy tắc nghiệp vụ: mô tả ràng buộc (ví dụ: ngày chỉ thị không nhỏ hơn ngày hiện tại, số lượng > 0).

3. Cấu trúc chi tiết của Detail Design

Detail Design cụ thể hóa từng nội dung của Basic Design để lập trình viên có thể triển khai chính xác. Dưới đây là cấu trúc thông thường trong dự án Nhật:

3.1. Thông tin chung về màn hình / chức năng

Ví dụ:

Mã chức năng: P_I201

Tên chức năng: 生産指示登録画面 (Màn hình đăng ký lệnh sản xuất)

Người dùng: Bộ phận kế hoạch sản xuất

Mục tiêu: Tạo lệnh sản xuất mới hoặc chỉnh sửa lệnh đã có.

Điều kiện truy cập: Người dùng có quyền “製造指示管理”.

3.2. Mô tả các trường dữ liệu (Field Definition)

Các trường trong màn hình được mô tả chi tiết:

• Tên hiển thị: “生産指示番号 (Mã chỉ thị sản xuất)”
• Kiểu dữ liệu: String
• Bắt buộc: Có
• Giá trị mặc định: Tự sinh theo format YYYYMMDD-nnn
• Nguồn dữ liệu: Sequence từ bảng ProductionOrder
• Mô tả: Mã duy nhất của lệnh sản xuất trong hệ thống

3.3. Mapping dữ liệu (Data Mapping)

Ví dụ:

ProductionOrderNo → ProductionOrder.OrderNo

ProductCode → ProductMaster.ProductCode

PlanDate → ProductionOrder.PlanDate

3.4. Logic xử lý (Processing Logic)

Ví dụ:

Khi người dùng nhấn “登録 (Đăng ký)”

→ kiểm tra dữ liệu đầu vào

→ ghi vào bảng ProductionOrder

→ hiển thị thông báo “登録が完了しました” (Đăng ký thành công).

3.5. Xử lý lỗi và thông báo (Error Handling)

Ví dụ:

ERR201 – Ngày sản xuất nhỏ hơn ngày hiện tại → “生産日が本日より前です。”

ERR202 – Mã sản phẩm không tồn tại → “製品コードが存在しません。”

3.6. Giao diện người dùng (UI Layout) – tham khảo

Mô tả bố cục màn hình:

– Vùng nhập thông tin lệnh sản xuất (sản phẩm, ngày, số lượng)

– Bảng danh sách lệnh đã tạo

– Nút chức năng: Đăng ký / Xóa / Tìm kiếm / Reset

– Điều kiện hiển thị: chỉ bật nút Xóa khi chọn một dòng hợp lệ.

4. Mối liên hệ giữa Basic Design và Detail Design

Ví dụ:

Basic quy định “Ngày chỉ thị không nhỏ hơn ngày hiện tại”

→ Detail cụ thể hóa điều kiện kiểm tra “PlanDate < Today → ERR201”。

5. Kết luận

Việc viết tài liệu Basic Design và Detail Design là kỹ năng quan trọng giúp dự án Nhật Bản duy trì tính chính xác và khả năng bảo trì.

Một tài liệu rõ ràng, thống nhất và có cấu trúc giúp tất cả các bên

— từ kỹ sư, tester, đến quản lý

— phối hợp hiệu quả và hạn chế sai sót.

Nếu Basic Design giúp mọi người hiểu “cái gì cần làm”, thì Detail Design hướng dẫn chi tiết “làm như thế nào”.

Khi hai phần này được liên kết chặt chẽ, dự án sẽ đạt độ ổn định, chính xác và phản ánh đúng tinh thần kỹ lưỡng của kỹ sư Nhật.

The post Basic Design và Detail Design trong dự án Nhật (Giới thiệu) appeared first on Tomoshare.

Khi hệ thống xử lý theo mô hình bất đồng bộ (asynchronous) — trong đó API nhận dữ liệu, đẩy vào hàng đợi (queue), và worker chạy nền (trên EC2) xử lý dần — việc đánh giá khả năng chịu tải không chỉ là đo tốc độ phản hồi API mà là đánh giá toàn bộ chuỗi xử lý message.

Stress test giúp xác định hệ thống có thể hấp thụ và xử lý bao nhiêu message mỗi giây, khi worker EC2 thực thi song song trên nhiều thread. Đây là bài test quan trọng để tối ưu số lượng instance, cấu hình thread pool và giới hạn throughput của hàng đợi SQS.

• Đo thời gian trung bình để xử lý một lượng lớn message.
• Xác định giới hạn throughput trước khi queue backlog.
• Phát hiện điểm nghẽn (bottleneck) ở tầng API, SQS hoặc Worker.
• Đánh giá mức ổn định và khả năng phục hồi khi tải giảm.

2. Kiến trúc hạ tầng dùng để stress test

Dưới đây là kiến trúc tham chiếu của hệ thống AWS EC2 Worker & SQS trong bài test:

3. Chuẩn bị dữ liệu test

Dữ liệu test cần mô phỏng hành vi thật của hệ thống, bao gồm payload gửi vào API và cấu hình tốc độ bắn tải. Thông thường, các test case được lưu trong file Excel — mỗi sheet là một loại test (load, spike, stability…).

Ví dụ: Kết quả thực tế Case 1 (500 threads / 60 giây)

Dưới đây là kết quả kiểm thử được ghi nhận (theo file Excel và log giám sát thực tế):

Trong bài test này (Case 1), hệ thống được giả lập với 500 người dùng đồng thời trong vòng 60 giây.

Kết quả cho thấy throughput trung bình đạt khoảng 8.3 requests/giây với 100% thành công, thời gian phản hồi trung bình là 227ms và cực đại là 307ms.

Điều này cho thấy hệ thống có khả năng xử lý ổn định ở mức tải trung bình.

Jmeter

EC2

Worker

RDS

SQS

Mẫu Jmeter setting

CSV Data Set Config: Filename: data_test.csv 
Variable Names: message_id,payload 
Recycle on EOF: True 
HTTP Body: { 
  "messageId": "${message_id}",
  "payload": "${payload}",
  "timestamp": "${__time(yyyy-MM-dd'T'HH:mm:ss)}"
 }

4. Cấu hình JMeter để gửi dữ liệu lên AWS

Công cụ được sử dụng là Apache JMeter — chuyên dùng để tạo tải HTTP và kiểm tra hiệu năng API. Mỗi request được gửi tới API Gateway, sau đó dữ liệu được đẩy vào hàng đợi SQS để worker EC2 xử lý.

Thread Group:
  Number of Threads (users): 500
  Ramp-up Period: 60
  Loop Count: 1

HTTP Request Sampler:
  Method: POST
  URL: https://{api-id}.execute-api.{region}.amazonaws.com/prod/push
  Body Data:
  {
    "messageId": "${__UUID()}",
    "payload": "${__RandomString(32,ABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890)}",
    "timestamp": "${__time(yyyy-MM-dd'T'HH:mm:ss)}"
  }

HTTP Header Manager:
  Content-Type: application/json
  x-api-key: ${API_KEY}

Chạy test bằng chế độ non-GUI để tiết kiệm tài nguyên:

jmeter -n -t HTTPRequest_500_60_001.jmx -l results.csv -JAPI_KEY=xxxx

Nếu cần mô phỏng tăng tải dần, bạn có thể dùng plugin Stepping Thread Group để tăng số luồng từng giai đoạn, giúp kết quả thực tế hơn.

5. Giám sát EC2 Worker và hàng đợi SQS

Trong quá trình test, CloudWatch là công cụ chính để giám sát hệ thống. Các metric cần chú ý:

6. Phân tích kết quả và đánh giá hệ thống

Sau khi test, cần đối chiếu kết quả từ JMeter (thời gian phản hồi, throughput) với metric từ CloudWatch (queue depth, CPU, backlog). Một hệ thống tốt là khi:

• Queue depth không tăng mãi, mà dao động quanh ngưỡng ổn định.
• CPU trên EC2 được sử dụng hiệu quả (~60–80%), không nghẽn 100% liên tục.
• Throughput duy trì ổn định trong suốt thời gian test.
• Số message trong DLQ = 0 hoặc rất thấp.

7. Kết luận

Stress test trên AWS EC2 Worker và SQS giúp bạn hiểu được giới hạn chịu tải của hệ thống cũng như khả năng tự phục hồi sau khi backlog. Khi theo dõi đúng metric và xác định rõ “ngưỡng nghẽn” (bottleneck), bạn có thể điều chỉnh thread pool, số lượng EC2 instance hoặc kích thước hàng đợi để đạt hiệu suất tối ưu.

Tài liệu tham khảo

• Amazon SQS Monitoring Guide
• Amazon EC2 Monitoring
• Apache JMeter User Manual
• AWS Compute Blog

The post Stress Test with AWS Worker appeared first on Tomoshare.

1. Vì sao nên đưa Java lên serverless?

Java đã là một trong những lựa chọn hàng đầu cho ứng dụng doanh nghiệp trong hơn 25 năm, nhờ khả năng chạy đa nền tảng, hiệu suất ổn định và cộng đồng phát triển lớn. Tuy nhiên, khi nói đến kiến trúc serverless – đặc biệt với AWS Lambda – cách triển khai ứng dụng Java đã thay đổi đáng kể.

Thay vì phải duy trì JVM và máy chủ hoạt động 24/7, ứng dụng của bạn chỉ chạy khi có sự kiện được kích hoạt. Hạ tầng tự động mở rộng, và bạn chỉ trả phí cho thời gian thực thi thực tế. Mô hình này giúp giảm chi phí vận hành, đơn giản hóa hạ tầng, đồng thời cho phép bạn tập trung vào phần logic ứng dụng.

2. Java truyền thống so với AWS Lambda

Ứng dụng Java truyền thống thường chạy trên các máy chủ ứng dụng như Apache Tomcat, Jetty, JBoss hoặc WebLogic. JVM luôn hoạt động, lắng nghe request HTTP, và xử lý luồng song song.

Trong khi đó, AWS Lambda hoạt động theo mô hình hướng sự kiện (event-driven):

• Mỗi hàm chỉ xử lý một request hoặc event duy nhất.
• Không cần máy chủ HTTP riêng.
• Tự động mở rộng và dừng khi không có request.
• Giới hạn thời gian thực thi tối đa 15 phút và 10 GB RAM.

3. AWS Serverless Java Container là gì?

AWS Serverless Java Container là thư viện giúp bạn chạy các framework Java phổ biến như Spring Boot, Jakarta EE, Micronaut hoặc Jersey trên AWS Lambda mà không cần viết lại toàn bộ mã nguồn.

Thư viện hoạt động như một adapter – nó chuyển các sự kiện từ Lambda thành request/response kiểu Servlet quen thuộc. Nhờ đó, ứng dụng Java có thể hoạt động bình thường chỉ với một số thay đổi nhỏ ở phần entry point.

Phiên bản v2 (2024) mang lại nhiều cải tiến quan trọng:

• Hỗ trợ Jakarta EE 10+.
• Tương thích Spring Framework 6.x và Spring Boot 3.x.
• Cập nhật hỗ trợ Jersey 3.x.
• Tối ưu hiệu suất và giảm kích thước file JAR.

4. Ví dụ: Chuyển ứng dụng Spring Boot 3 sang Lambda

Dưới đây là ví dụ cơ bản để triển khai ứng dụng Spring Boot 3 lên AWS Lambda sử dụng Serverless Java Container v2.

Bước 1: Thêm dependency vào pom.xml

<dependency>
    <groupId>com.amazonaws.serverless</groupId>
    <artifactId>aws-serverless-java-container-springboot3</artifactId>
    <version>2.0.0</version>
</dependency>
  

Bước 2: Loại bỏ Tomcat khỏi build

Spring Boot mặc định nhúng Tomcat. Vì Lambda sử dụng API Gateway để xử lý HTTP, bạn có thể loại bỏ Tomcat để giảm kích thước package và tăng tốc khởi động.

<excludes>
    <exclude>org.apache.tomcat.embed:*</exclude>
</excludes>
  

Bước 3: Tạo handler cho Lambda

Ví dụ cơ bản:

public class StreamLambdaHandler 
        extends SpringBootRequestHandler<APIGatewayV2HTTPEvent, APIGatewayV2HTTPResponse> {
}
  

Hoặc nếu bạn cần nhiều quyền kiểm soát hơn:

public class CustomHandler implements RequestStreamHandler {

    private static final SpringDelegatingLambdaContainerHandler<
        APIGatewayV2HTTPEvent, APIGatewayV2HTTPResponse> handler;

    static {
        handler = new SpringDelegatingLambdaContainerHandler<>(Application.class);
    }

    @Override
    public void handleRequest(InputStream input, OutputStream output, Context context)
            throws IOException {
        handler.proxyStream(input, output, context);
    }
}

  

Bước 4: Cấu hình biến môi trường

Đặt biến môi trường MAIN_CLASS trỏ tới class chính có annotation @SpringBootApplication của bạn.

5. Tối ưu hiệu suất với AWS Lambda SnapStart

Một trong những thách thức lớn khi chạy Java trên Lambda là thời gian khởi động (cold start). AWS đã giới thiệu SnapStart để giải quyết vấn đề này bằng cách “chụp ảnh” trạng thái Lambda sau khi khởi tạo, rồi khôi phục lại cực nhanh cho các request tiếp theo.

Để bật SnapStart, chỉ cần thêm cấu hình vào AWS SAM hoặc CloudFormation:

SnapStart:
  ApplyOn: PublishedVersions
  AutoPublishAlias: prod
  

Kết quả là ứng dụng Java có thể khởi động nhanh hơn gấp 5–10 lần, giúp cải thiện đáng kể trải nghiệm người dùng, đặc biệt với các API có tần suất gọi thấp hoặc không liên tục.

6. Kết nối cơ sở dữ liệu hiệu quả trong môi trường Lambda

Khi làm việc với RDS hoặc Aurora, cần lưu ý:

• Dùng connection pool nhỏ (ví dụ HikariCP với 2–5 connection).
• Tận dụng cache tầng ứng dụng (Redis, DAX) để giảm truy vấn trực tiếp DB.
• Hạn chế query đồng bộ trong hot path; nên dùng async hoặc event-driven khi có thể.

7. Nhược điểm và lưu ý khi triển khai Java trên AWS Lambda

Dù AWS Serverless Java Container giúp việc chuyển ứng dụng Java lên Lambda trở nên dễ dàng hơn, developer vẫn cần hiểu rõ một số hạn chế để thiết kế và vận hành hiệu quả hơn.

Tóm lại, Java vẫn là lựa chọn mạnh mẽ trong môi trường AWS Lambda nhờ tính ổn định và hệ sinh thái lớn, nhưng để đạt hiệu năng tối ưu, cần chú trọng vào cấu trúc ứng dụng, cách đóng gói, và kỹ thuật giảm thời gian khởi động.

Tài nguyên tham khảo

• GitHub: AWS Serverless Java Container
• Tài liệu chính thức: AWS Lambda cho Java Developer
• AWS Compute Blog

The post Re-platforming Java với AWS Serverless Java Container appeared first on Tomoshare.