avatar Published on Apr 05, 2024

AWS Basic Structure

AWS là nhà cung cấp dịch vụ cloud phổ biến nhất hiện nay. Tất cả những gì bạn cần ở một ứng dụng web bạn đều có thể tìm thấy trên AWS. Thay vì phải xây dựng hệ thống máy chủ vật lý phức tạp, AWS có thể cung cấp mọi tài nguyên mà bạn cần trên cloud. Tài nguyên trên AWS được ảo hoá nhưng chúng vẫn tuân theo kiến trúc của các hệ thống vật lý thông thường.

alt text

Region

Region trong là một khu vực địa lý cụ thể, bao gồm nhiều Availability Zone (AZ). Mỗi Region có cơ sở hạ tầng riêng biệt, bao gồm các trung tâm dữ liệu, nguồn điện, mạng và hệ thống kết nối. Region được thiết kế để hoạt động độc lập, giảm độ trễ khi truy cập mạng trong cùng region. Tuân thủ các quy định về bảo mật dữ liệu khác nhau.

Availability Zone

Nằm trong một region, mỗi AZ bao gồm một hoặc nhiều trung dữ liệu được kết nối với nhau.

alt text

Một hệ thống nên được đặt trên nhiều AZ khác nhau để luôn đảm bảo tính sẵn sàng. Khi có thiên tai làm ảnh hưởng đến một AZ thì dữ liệu nằm ở AZ khác sẽ không bị ảnh hưởng.

VPC

Viết tắt của Virtual Private Cloud, là một mạng riêng ảo riêng biệt trên aws. VPC có thể cross nhiều AZ hoặc region khác nhau.

alt text

VPC giúp cô lập tất cả các tài nguyên trong hệ thống với internet, kiểm soát toàn bộ môi trường trong mạng từ dải địa chỉ IP, truy cập ra vào mạng…

IGW

Internet Gateway là một thành phần của VPC hoạt động giống như một router, kết nối VPC với internet. Một VPC chỉ có một IGW và một IGW cũng chỉ được attach vào một VPC.

Subnet

VPC có thể kiểm soát truy cập ra vào mạng nhưng không thể quản lý truy cập diễn ra trong nội bộ mạng. Khi có nhiều resources trong mạng, việc cần làm là nhóm các thành phần có tính chất tương tự ra một mạng riêng.

Giống như trong một công ty, các nhân viên thuộc cùng một phòng ban sẽ thường ngồi cùng một khu. Mỗi phòng ban sẽ có những quy định, nội duy riêng.

alt text

Subnet trong AWS cũng vậy, nó được sử dụng để chia VPC thành các mạng nhỏ hơn. Từ đó dễ dàng kiểm soát truy cập, áp dụng các biện pháp bảo mật phù hợp với từng mạng. Các resource trong một subnet phải cùng nằm trong một AZ. Có hai loại subnet là Public subnet và Private subnet. Public subnet là subnet có có route table trỏ đến IGW.

Route table

Là một danh sách các rule để kiểm soát truy cập ra vào của một mạng. Nó xác định đường đi cho một gói tin, giữa các subnet trong cùng một VPC, giữa các VPC khác nhau, hoặc giữa VPC và các nguồn tài nguyên bên ngoài như Internet.

alt text

NAT

Viết tắt của Network Address Translation. Cho phép các resources bên trong private subnet có thể truy cập internet bằng việc dịch private IP sang public IP.

alt text

Có hai loại NAT:

  • NAT Instance: Là một EC2 trong một public subnet, được attached Elastic IP.
  • NAT Gateway: Là một thành phần của VPC, được AWS quản lý.

NACL

Là viết tắt của Network Access Controller List, làm việc ở tầng subnet. Đóng vai trò như một firewall, kiểm soát truy cập thông qua các rule xác định giao thức, port, địa chỉ IP được phép hay không được phép ra vào subnet.

alt text

Security Group

Có chức năng tương tự như NACL nhưng hoạt động ở tầng instance. Security Group kiểm soát truy cập ra vào instance nên có tính bảo mật cao hơn.

alt text

Security Group có thể kiểm soát một nhóm instance thuộc các subnet khác nhau.

alt text

Load Balancer

Trong AWS, Load Balancer được sử dụng để cân bằng lưu lượng truy cập đến các ứng dụng.

alt text

Dựa vào phạm vi hoạt động, người ta chia Load Balancer thành các loại:

  • Network Load Balancer (NLB): Dùng để chuyển hướng request dựa theo IP address với độ trễ thấp.
  • Application Load Balancer (ALB): Dùng để chuyển hướng request đến từng cụm target. Thích hợp với ứng dụng microservice.
  • Gateway Load Balancer: Cân bằng tải lưu lượng truy cập đến các thiết bị ảo của bên thứ ba.

Auto Scale Group

Đây là một dịch vụ quản lý tài nguyên của AWS, đảm bảo ứng dụng luôn sẵn sàng. Nó cho phép bạn định nghĩa các điều kiện để tăng hoặc giảm số lượng resources trong một group. Dựa các yếu tố như lưu lượng truy cập, phần trăm RAM, GPU sử dụng…

alt text

Ngoài ra, ASG còn giúp tiết kiệm tài nguyên, tối hoá ưu chi phí.

Conclusion

Trên đây là các thành phần cơ bản của một VPC. Nắm được bức tranh tổng quan, hiểu được vị trí của các thành phần trong mạng sẽ giúp bạn dễ dàng hơn trong việc đi sâu tìm hiểu thêm những services khác trong AWS.

AWS

Read more

AWS CDK

Overview And Key Techniques In CDK

AWS Cloud Development Kit (CDK) là một framework mạnh mẽ cho phép sử dụng ngôn ngữ lập trình thông dụng như TypeScript, Python, Go… để định nghĩa và triển khai hạ tầng trên AWS. CDK giúp chúng ta dễ dàng quản lý resources bằng cách chuyển đổi từ mã nguồn sang mô hình hạ tầng dưới dạng CloudFormation. Để tìm hiểu kỹ hơn về CDK bạn có thể đọc qua bài viết IaC With AWS CDK. Dưới đây là tổng hợp các khía cạnh quan trọng khác mà bạn cần nắm vững để sử dụng CDK một cách hiệu quả. Phases CDK hoạt động theo ba phase chính: synth time, deploy time, và runtime. Mỗi phase có vai trò khác nhau trong việc xây dựng và quản lý hạ tầng trên AWS. Synth Time Ở giai đoạn này, CDK tổng hợp (synthesize) mã nguồn của bạn thành một tập hợp các tệp JSON dưới dạng CloudFormation Template. Không có resource nào được tạo trong giai đoạn này, nó chỉ đơn thuần là việc tạo ra mô tả hạ tầng. Khi bạn chạy lệnh cdk synth, CDK sẽ tạo ra template CloudFormation mô tả toàn bộ hạ tầng của bạn. Deploy Time Đây là giai đoạn triển khai (deploy) thực sự. Các template CloudFormation được gửi lên AWS và triển khai resources theo mô tả trong template. Lệnh cdk deploy sẽ triển khai các thay đổi của bạn lên tài khoản AWS. Trong quá trình này, AWS sẽ tạo, cập nhật hoặc xóa resource. Runtime Đây là giai đoạn khi các resource của bạn đang hoạt động trên AWS sau khi đã được triển khai. Các dịch vụ như Lambda, EC2, S3 sẽ hoạt động theo logic đã định nghĩa và bạn có thể bắt đầu tương tác với chúng. Resources Mỗi resource trong AWS được định nghĩa thông qua Construct. Tập hợp nhiều constructs tạo nên một Stack. Ví dụ về construct: new s3.Bucket(this, 's3-bucket', { versioned: false, autoDeleteObjects: true, removalPolicy: cdk.RemovalPolicy.RETAIN, }); Ví dụ về stack: import * as cdk from 'aws-cdk-lib'; import * as s3 from 'aws-cdk-lib/aws-s3'; import * as iam from 'aws-cdk-lib/aws-iam'; import { Construct } from 'constructs'; interface S3Props extends cdk.StackProps { allowPolicies: Array<iam.Policy>; } export class S3Stack extends cdk.Stack { constructor(scope: Construct, id: string, props: S3Props) { super(scope, id, props); const bucket = new s3.Bucket(this, 's3-bucket', { versioned: false, autoDeleteObjects: true, removalPolicy: cdk.RemovalPolicy.RETAIN, }); props.allowPolicies.forEach((policy) => { bucket.grantReadWrite(policy); }); } } Bất cứ resource nào trong CDK sẽ luôn được xác định dựa vào scope và ID. Trong một scope không được phép xuất hiện 2 resources có cùng ID. Khi thay đổi scope hoặc ID của một resource, CDK sẽ xoá resource cũ và replace nó bằng một resource mới. Vì vậy với những resource như S3, RDS, Elasticache… việc thay đổi trên có thể làm mất dữ liệu. Do đó bạn cần quản lý chúng thông qua removalPolicy một cách cẩn thận. Stack References Trong một project CDK, bạn cần nhóm những resources có liên quan vào trong một stack, điều này giúp bạn quản lý resources tốt hơn. Lý tưởng nhất là khi các stacks hoạt động độc lập, sự thay đổi trong stack này không ảnh hưởng đến các stacks khác. Việc có quá nhiều resources trong một stack sẽ phát sinh vấn đề khi deploy. Nếu có bất kỳ lỗi nào xảy ra trong quá trình này thì toàn bộ stack sẽ bị rollback. Đôi khi điều này sẽ làm tốn khá nhiều thời gian của bạn. Nhưng nếu thiết kế một stack có ít resources hơn thì bạn sẽ cần tạo ra nhiều stacks hơn, các stacks cũng sẽ ràng buộc với nhau phức tạp hơn. Vì vậy việc thiết kế stack là rất quan trọng. Trong trường hợp không tránh khỏi việc ràng buộc giữa các stacks, bạn có thể sử dụng những cách dưới đây để truyền thông tin giữa chúng. Sử dụng Properties Đây là cách đơn giản nhất, bạn chỉ cần truyền properties từ stack này sang stack kia thông qua stack props: const vpcStack = new VpcStack(scope, 'vpc-stack', { env: props.env }); const webStack = new WebStack(scope, 'web-stack', { env: props.env, vpc: vpcStack.vpc, }); new S3Stack(scope, 's3-stack', { env: props.env, allowPolicies: [webStack.policy] }); Trong ví dụ trên web-stack nhận vào vpc được tạo từ vpc-stack. Policy được tạo ra trong web-stack sau đó được truyền vào s3-stack để thực hiện grant bucket cho policy này. cdk.CfnOutput và cdk.Fn.importValue Bạn có thể sử dụng cdk.CfnOutput để export thông tin trong một stack. Các stack khác có thể sử dụng cdk.Fn.importValue để import những thông tin cần thiết. Quay lại ví dụ trên, ở vpc-stack sẽ thực hiện export vpcId : import * as cdk from 'aws-cdk-lib'; import * as ec2 from 'aws-cdk-lib/aws-ec2'; import { Construct } from 'constructs'; export class VpcStack extends cdk.Stack { constructor(scope: Construct, id: string, props: cdk.StackProps) { super(scope, id, props); const vpc = new ec2.Vpc(this, 'main-vpc'); new cdk.CfnOutput(this, 'mainVpcId', { value: vpc.vpcId, exportName: 'mainVpcId', }); } } web-stack sẽ import giá trị này vào để sử dụng: import * as cdk from 'aws-cdk-lib'; import * as ec2 from 'aws-cdk-lib/aws-ec2'; import { Construct } from 'constructs'; export class WebStack extends cdk.Stack { constructor(scope: Construct, id: string, props: cdk.StackProps) { super(scope, id, props); const vpcId = cdk.Fn.importValue('mainVpcId'); const vpc = ec2.Vpc.fromVpcAttributes(this, 'vpc', { availabilityZones: ['ap-northeast-1a', 'ap-northeast-1c'], vpcId: vpcId, }); } } Với cách này, việc chia sẻ thông tin giữa các stack trở nên linh hoạt hơn, bạn không cần phải truyền trực tiếp thông tin từ stack này sang stack kia. Tuy nhiên nó không giải quyết được vấn đề ràng buộc giữa các stack. Nếu không quản lý tốt, bạn có thể gặp phải tình huống hai stacks bị phụ thuộc vào tham số export từ stack còn lại dẫn đến việc lock lẫn nhau. Bạn sẽ không thể thực hiện update hay delete một trong hai stack. Sử dụng SSM Parameter Store SSM Parameter Store được sử dụng để lưu trữ các tham số, như các thông tin cấu hình, secret key. Chúng có thể được truy xuất bằng API hoặc SDK từ các dịch vụ AWS hay các ứng dụng khác. Bạn cũng có thể dùng nó để chia sẻ thông tin giữa các stack nằm trong các dự án cdk khác nhau. Với SSM chúng ta sẽ viết lại vpc-stack như sau: import * as cdk from 'aws-cdk-lib'; import * as ec2 from 'aws-cdk-lib/aws-ec2'; import * as ssm from 'aws-cdk-lib/aws-ssm'; import { Construct } from 'constructs'; export class VpcStack extends cdk.Stack { constructor(scope: Construct, id: string, props: cdk.StackProps) { super(scope, id, props); const vpc = new ec2.Vpc(this, 'main-vpc'); new ssm.StringParameter(this, 'main-vpc-id', { parameterName: '/main-vpc/id', stringValue: vpc.vpcId, }); } } Tương tự, web-stack sẽ lockup parameter main-vpc-id để sử dụng: import * as cdk from 'aws-cdk-lib'; import * as ec2 from 'aws-cdk-lib/aws-ec2'; import * as ssm from 'aws-cdk-lib/aws-ssm'; import { Construct } from 'constructs'; export class WebStack extends cdk.Stack { constructor(scope: Construct, id: string, props: cdk.StackProps) { super(scope, id, props); const vpcId = ssm.StringParameter.valueFromLookup(this, '/main-vpc/id'); const vpc = ec2.Vpc.fromLookup(this, 'vpc', { vpcId }); } } Như vậy web-stack không còn phụ thuộc vào vpc-stack nữa, nó sẽ chỉ phụ thuộc vào parameter store. Cách làm này thích hợp khi có nhiều dự án cùng sử dụng chung một resource ví dụ như RDS, ALB… Lúc này bạn có thể lưu thông tin như ID, ARN của các resources này lên store, dự án khác muốn dùng chỉ cần lookup các thông tin cần thiết để import vào. Conclusion Sử dụng AWS CDK đòi hỏi sự hiểu biết về các phase hoạt động cũng như cách quản lý resource thông qua stack và chia sẻ thông tin giữa các stack với nhau. Bằng cách nắm vững các kỹ thuật này bạn sẽ có thể xây dựng và quản lý hạ tầng trên AWS một cách hiệu quả và tối ưu hơn.
Sep 15, 2024
Vue

SPA With Vue And Rails

Ứng dụng SPA đang ngày càng trở nên phổ biến bởi những ưu điểm mà nó mang lại. Có thể kể đến như tốc độ tải trang nhanh, trải nghiệm mượt mà, tách biệt logic frontend và backend, giúp chuyên môn hoá từng bộ phận trong dự án. Khó khăn khi phát triển ứng dụng SPA nằm ở việc kết nối giữa và đảm bảo tính đồng bộ giữa hai server frontend và backend. Đây là những vấn đề mà bạn không bao giờ gặp ở một ứng dụng SSR. Chưa kể việc tạo ra nhiều server có thể gây lãng phí vì thực tế chỉ có server backend chịu tải chính, server frontend sẽ chỉ lưu các tài nguyên như html, css, js… Có một hướng tiếp cận đơn giản hơn giúp bạn sử dụng SPA cho dự án của mình mà không phải lo lắng đến các vấn đề trên. Bài viết này sẽ giúp bạn thực hiện điều đó với Vue và Rails.
Aug 20, 2024
Back to top Go to bottom