Như đã biết, sức mạnh của kẻ đi đầu Amazon Web Service (AWS) trong lĩnh vực Cloud Computing là rất lớn. Vì vậy, mình cũng bắt đầu vào việc tìm hiểu những dịch vụ căn bản của AWS để có thể áp dụng vào các sản phẩm trong tương lai (thực ra là bị một sếp ở Sotatek chỉ định chứ không phải tự giác đâu). Bài viết tập trung vào việc giới thiệu các kiến thức tổng quan mình thu nhập được cũng như một số kiến thức liên quan để bắt đầu sử dụng AWS dễ dàng hơn. Nói thật thì đã có rất nhiều bài viết tổng quan về AWS rồi nhưng mình vẫn muốn viết một bài cho riêng mình để luyện viết lách cũng như tự tổng hợp kiến thức, ngoài nói về AWS ra thì mình cũng có đưa vào một vài so sánh để thêm chút gia vị và cũng bớt gò bó hơn.
Một gợi ý nhỏ giúp việc theo dõi bài viết thuận lợi hơn là bạn nên có một chút kiến thức cơ bản về system design và nguồn rất tốt mình muốn giới thiệu là system design primer. Lan man thế đủ rồi, bắt đầu thôi.
Elastic Compute Cloud (EC2)
Lần tiếp cận đầu tiên của mình với dịch vụ của AWS là EC2. Công việc chỉ đơn giản là truy cập vào server bằng SSH, cài đặt môi trường và triển khai một ứng dụng. Lúc dùng thì chẳng thấy nó khác gì so với các dịch vụ Virtual Private Server (VPS) khác mình đã từng sử dụng cả, mà thấy giá lại đắt hơn nhiều. Bản thân thấy nó hơi bị hét giá cao quá cho đến khi biết EC2 thực chất là Cloud Server chứ không phải VPS. Sự khác nhau này giải thích cho mình tại sao giá cả đắt hơn và một số đặc tính vượt trội của Cloud Server như tính ổn định cao, rủi ro thấp, dễ dàng thay đổi cấu hình theo nhu cầu, v.v. Lí do tiếp theo để bắt đầu với EC2 là vai trò trụ cột của nó trong hệ sinh thái AWS, bạn sẽ chạy gần như tất cả các ứng dụng trên dịch vụ này. Nhân nói đến việc chạy ứng dụng, hay đúng hơn là triển khai thì ban đầu mình chỉ đơn giản đẩy code lên và chạy các script thôi. Nó ổn nhưng thực sự đây là cách mình thấy khá là chân tay hoặc là chỉ thích hợp với các ứng dụng đơn lẻ. Vì vậy, mình có tìm hiểu thêm cách triển khai ứng dụng với khả năng mở rộng tốt hơn dưới dạng container (cụ thể là dùng Docker), chủ yếu là để phục vụ cho việc triển khai các microservice. Nói đến đây thì chắc các bạn cũng sẽ giới thiệu cho mình Kubernetes hoặc Docker Swarm rồi. Thôi thế mình giới thiệu ECS vậy.
Elastic Container Service (ECS)
ECS là dịch vụ "soạn nhạc" (orchestration) cho container, hiện tại đang hỗ trợ Docker (mình nghĩ thế là đủ) để giúp bạn dễ dàng chạy cũng như mở rộng các ứng dụng được container hóa. Việc chạy các container thì có hai tùy chọn, nếu vẫn quen với việc quản lý server hơn thì chọn chạy trên EC2, và nếu lười như mình thì chọn Fargate (nhưng tất nhiên sẽ có những giới hạn nhé).
Để sử dụng ECS thì cũng cần đi qua một số khái niệm cơ bản. Dịch từ đây thì gồm có:
- Container Instance: thực chất là cách nói hoành tráng hơn của EC2 Instance (chắc đang ở ngữ cảnh dịch vụ container). Mỗi Container Instance có thể chứa một hoặc nhiều Docker container.
- Cluster: là một nhóm logic (logical grouping) chứa một vài Container Instance. Việc nhóm các instance cùng chạy một image giúp bạn quản lý dễ dàng hơn. Đơn cử là việc mỗi lần cập nhật image mới thì bạn chỉ cần đưa cho Cluster tự phân phối chứ không cần cập nhật cho mỗi instance một.
- Task Definition: là các cấu hình cần thiết để một instance biết mình cần chạy như thế nào, tài nguyên cần thiết hay giới hạn là bao nhiểu, chạy Docker image nào v.v.
- Task: Là các container đang chạy theo thiết lập của Task Definition vừa đề cập ở trên.
- Service: là nơi quản lý vòng đời của các container và chỉ định số lượng task chạy tương ứng với mỗi Task Definition là bao nhiêu.
- Repository: Đơn giản là một Docker Hub của riêng AWS. Hiện thì nó được đặt tên riêng là ECR.
Fargate
Kể từ năm 2017, chúng ta có thêm một tùy chọn khác bên cạnh EC2 trong việc chạy các container (hay các task). Fargate cho phép bạn chạy các container mà không cần quan tâm đến việc quản trị server và các hạ tầng bên dưới (serverless).
Lambda
Tiện việc nhắc đến serverless thì cũng đề cập đến Lambda luôn. Chắc mình không phải giới thiệu lại dịch vụ rất nổi tiếng này của AWS cũng như những lợi ích mà nó đem lại, thay vào đó mình chỉ kể xấu để bạn cân nhắc giữa việc dùng Lambda hay Fargate cho các ứng dụng serverless. Một số nhược điểm chính của Lambda như sau:
- Phải điều chỉnh code để phù hợp với Lambda, không tận dụng được code cũ.
- Mỗi lần gọi function sẽ có độ trễ nhất định, đơn giản vì nó không chạy kiểu always-on.
- Không được kiểm soát môi trường (cái đánh đổi khi dùng serverless)
- Khó theo dõi, debug và test hơn.
Elastic IP (EIP)
Đối với AWS, mỗi EC2 instance mà bạn tạo ra được cấp phát một Public IP thông thường mà không phải là IP tĩnh, dẫn đến việc bạn không thể sử dụng lại địa chỉ này nếu khởi động lại server. Nếu muốn có một IP tĩnh thì là lúc cần đến EIP. Dịch vụ này cung cấp cho bạn địa chỉ IP tĩnh để có thể gắn vào bất kỳ một instance hoặc network interface cho bất kỳ Virtual Private Cloud (VPC) nào bạn sở hữu. Thông thường, khi sử dụng các dịch vụ khác thì bạn sẽ có một địa chỉ IP tĩnh gắn liền với server để dùng luôn khá lá tiện. Nhưng việc tách biệt dịch vụ IP tĩnh của AWS cho bạn một lợi thế rất lớn khi muốn chuyển traffic từ một server này sang một server khác mà không cần thay đổi DNS. Mình cũng muốn tìm hiểu họ làm được điều đó bằng cách nào nhưng chỉ có gợi ý này thôi.
Elastic Load Balancer (ELB)
Load Balancing là một vấn đề chắc chắn bạn phải xử lý nếu muốn mở rộng hệ thống theo chiều ngang và tất nhiên nó là một vấn đề khó. Nếu bạn đang dùng EC2 và việc scale theo chiều dọc không còn hiệu quả, đó là lúc bạn nên dùng ELB để cân bằng tải. Cụ thể hơn về dịch vụ này, ta sẽ có hai tùy chọn là Classic Load Balancer (CLB) và Application Load Balancer (ALB). CLB hoạt động ở lớp 4 (Transport) trong mô hình OSI nên chỉ phân biệt được các gói tin đến dựa vào địa chỉ IP và thích hợp cho việc cân bằng tải thông thường với một số lượng server giống nhau đứng sau và CLB sẽ phân bổ traffic đều cho tất cả các server này. ALB thì hoạt động ở tầng 7 (Application) nên có thể phân tích được các thông tin cụ thể hơn trong gói tin. Một ALB có thể phục vụ các instance khác nhau và chuyển các traffic đến server thích hợp dựa vào thông tin đường dẫn được yêu cầu. Và nếu bạn tò mò về giải thuật định tuyến (Routing Algorithm) được dùng bởi ELB thì có thể tìm hiểu thêm ở đây.
Virtual Private Cloud (VPC)
Tiếp tục với một dịch vụ khác, lần này là liên quan network. VPC cho phép bạn triển khai các tài nguyên của AWS trên một mạng ảo. Việc định nghĩa mạng ảo này sẽ tương đồng với cách vận hành một mạng truyền thống mà bạn dùng cho một trung tâm dữ liệu.
Mình không có nhiều kiến thức về mạng máy tính và tài liệu liên quan đến VPC cũng khá nhiều nên bạn có thể tự tham khảo tại đây. Những khái niệm cần chú trọng là VPC CIDR Block, Subnet, Gateway, Route Table, Network Access Control List (ACL) và Security Group.
Cloud Formation
Từ đầu đến giờ mình giới thiệu tương đối nhiều dịch vụ nhưng đa số mình không dùng trực tiếp mà đều thông qua Cloud Formation. Nó cung cấp một ngôn ngữ chung để miêu tả tất cả các tài nguyên trên môi trường cloud của bạn. Hiện tại, dịch vụ này đang hỗ trợ JSON và YAML (mình thích YAML hơn) để tạo bản thiết kế. Nói mở rộng hơn thì dịch vụ này liên quan đến khái niệm Infrastructure as Code và Terraform là một lựa chọn khác nếu bạn thích mã nguồn mở cũng như muốn bản thiết kế của mình có thể chạy trên nhiều dịch vụ.
Bên trên là một ví dụ đơn giản nếu bạn muốn tạo một EC2 instance. Còn rất nhiều tài nguyên khác bạn có thể định nghĩa, hãy thử tìm hiểu nhé.
CloudWatch
Gần đây mình có làm một chức năng đơn giản sử dụng CloudWatch (cụ thể hơn là CloudWatch Log). Công việc là thêm kênh đẩy log lên CloudWatch, thêm một filter để lọc các log ghi nhận lỗi của hệ thống, nếu có thì tạo ra một Alarm gửi mail đến admin để cảnh báo (đoạn gửi mail thì mình lười chưa làm). Nói thế thì các bạn cũng đã đoán ra tác dụng của CloudWatch rồi đúng không. Chức năng chính của dịch vụ này là theo dõi các tài nguyên chạy trên AWS của bạn, từ log cho đến các thông số về CPU, RAM đang sử dụng. Điều này rất cần thiết nếu bạn cần phản ứng nhanh với lỗi ứng dụng hoặc thiết lập một luật tự động mở rộng dựa trên các thông số phần cứng đang bị tiêu thụ trên thực tế.
Simple Storage Service (S3)
Như tên gọi, một dịch vụ lưu trữ đơn giản của AWS. Nói là đơn giản, nhưng bạn có thể làm rất rất nhiều thứ hay ho với S3. Và như một thói quen, mình sẽ nêu ra một số hạn chế bạn cần cân nhắc. Đối với mình, đó là giá cả khá là chát và việc S3 có tới bốn giải pháp lưu trữ với biểu phí giá khá là phức tạp gây rối não khi mới bắt đầu. Mà nói chung dùng hàng AWS một cách hiệu quả có bao giờ dễ đâu.
Code Commit, Code Build, Code Deploy, Code Pipeline
Các dịch vụ này được sinh ra để phục vụ cho CI/CD trên nền tảng AWS. Code Commit là nơi lưu trữ mã nguồn giống như Github và Bitbucket. Code Build thì là nơi để phục vụ Continuous Integration (CI) giống TravisCI hay CircleCI. Code Deploy thì để phục vụ Continuous Delivery hay Continuous Deployment tùy mục đích (CD). Code Pipeline giúp cho bạn kết hợp các dịch vụ này lại theo trình tự mà bạn muốn. Ví dụ thường thấy nhất là khi mã nguồn trên Code Commit có sự thay đổi thì Code Build sẽ thực hiện các script được chỉ định (thường là build và test), sau khi đã qua được CI thì bắt đầu tự động chuyển mã nguồn mới lên môi trường staging để thực hiện các loại test khác và nếu "đẳng cấp" hơn thì tự đẩy mã nguồn lên production.
Bonus
Nhân tiện nói đến CI/CD thì cũng nhắc DevOps luôn nhỉ. Nếu hứng thú thì có thể xem bạn cần những gì để trở thành DevOps tại đây nhé, mình cũng đang tìm hiểu nên có thêm người học cùng thì tuyệt vời.
Kết luận
Lần đầu viết nên cách hành văn còn chưa mạch lạc nên mong các bạn thông cảm. Hi vọng bài viết sẽ giúp bạn có một cái nhìn ban đầu đủ tốt để bắt đầu làm quen với AWS dễ dàng hơn. Cảm ơn vì đã theo dõi.
