Please enable JavaScript.

Coggle requires JavaScript to display documents.

AWS (Whizlabs) - Coggle Diagram

- - - - lưu trữ dữ liệu mà bạn truy cập thường xuyên.
      - sao lưu trên nhiều thiết bị lưu trữ và có khả năng chịu lỗi cao
    - - Dữ liệu truy cập thường xuyên => Standard
      - dữ liệu ít => Archive
    - - dữ liệu mà bạn truy cập không thường xuyên
      - vẫn cần độ tin cậy và hiệu năng cao
    - - lưu trữ dự phòng
      - chỉ được lưu trữ tại một khu vực duy nhất
    - - sử dụng cho việc lưu trữ dữ liệu lâu dài mà bạn không thường xuyên truy cập
      - có thời gian phục hồi lâu hơn khi bạn muốn truy xuất nó
      - Expedited
        
        cho phép bạn truy xuất dữ liệu nhanh chóng trong vòng vài phút
      - Standard
        
        "Standard" cho phép truy xuất dữ liệu trong vòng vài giờ
    - - lưu trữ dữ liệu cực kỳ lâu dài
      - không cần truy cập thường xuyên
      - lưu trữ các dữ liệu cực kỳ cũ và không được truy cập thường xuyên, với mức chi phí rất thấp
- - - - Biggest discount, not suitable for critical job/database
    - - reserve 1 or 3 years
      - long workloads
      - run on a server continuously for 1 year
    - - good for companies with strong compliance
      - the most expensive EC2 Purchasing Option
  - - - Archived
        
        -75%, 24h-72h recover.
      - RecycleBin
    - - same EBS volume to multiple EC2 instances in the same AZ
      - Up to 16 EC2 Instance at a time
    - - gp2, gp3, io1, io2, and Magnetic (Standard)
  - - - a critical application that uses an in-memory database
    - - deploy a High-Performance Computing (HPC) application
      - great for compute-intensive workloads requiring high-performance processors (e.g., batch processing, media transcoding, high-performance computing, scientific modeling & machine learning, and dedicated gaming servers)
    - - handle this high-frequency OLTP database
      - great for workloads requiring high, sequential read/write access to large data sets on local storage
  - - - Regional/Standard
        
        for Frequently accessed files
        
        Multi AZ
      - EFS-IA
        
        Cost saving
  - - - Vertical
        
        Increase Size of Instance
        
        Ex: t2.micro -> t2.large
        
        Limit hardware
        
        Scale Up/Down
      - Hirizontal
        
        Number of instances
        
        Scale Out/In
        
        Auto Scaling Group
        
        Load Balancer
    - - Availability Zone
      - Auto Scaling Group/Load balancer multi AZ
    - - Target Group
        
        nhóm các tài nguyên máy chủ (instances) hoặc container chạy ứng dụng vào một nhóm đơn giản để quản lý và cân bằng tải
        
        đảm bảo rằng lưu lượng truy cập từ người dùng được phân chia đều và mỗi máy chủ không bị quá tải.
      - QueryString/Parameters Routing
- - - - automatically trigger code analysis after each commit
    - - SSH keys
      - HTTPS
        
        IAM
        
        CLI Credential Helper
  - - - Setup an Cloudwatch Event rule
    - - CloudTrail
  - - - predefined configurations
        
        OneAtATime, HalfAtATime, AllAtOnce
      - ApplicationStop, DownloadBundle, BeforeInstall, Install, AfterInstall, ApplicationStart, ValidateService
  - - - speed up the build process
- - - - Binpack
        
        tối ưu hóa sử dụng tài nguyên, nhưng có thể dẫn đến sự lãng phí không gian nếu các Task có kích thước khác nhau
      - Spread
        
        Phân tán Task ra trên nhiều EC2 instance hoặc Fargate để giảm thiểu tác động nếu một EC2 instance hoặc Fargate gặp sự cố
      - Random
        
        Chọn một vị trí ngẫu nhiên cho Task
- - - - Message Deduplication ID
        
        được sử dụng để xác định và ngăn chặn tin nhắn trùng lặp trong SQS
        
        Nếu message deduplication ID của tin nhắn mới trùng với một tin nhắn đã tồn tại, SQS sẽ loại bỏ tin nhắn mới và không gửi nó vào hàng đợi
      - Message Group ID
        
        gom nhóm các tin nhắn liên quan với nhau
        
        Các tin nhắn có cùng message group ID sẽ được coi là một nhóm
        
        SQS đảm bảo rằng chỉ có một consumer duy nhất nhận và xử lý các tin nhắn trong cùng một nhóm
        
        Nếu không có message group ID hoặc các tin nhắn có message group ID khác nhau, SQS có thể gửi các tin nhắn trong cùng một hàng đợi cho các consumer khác nhau đồng thời.
  - - - SQS
      - Lambda
      - Http(s)
- - - - Là một hộp các Nodes
      - Tập hợp các quầy thu ngân trong các chi nhánh
      - Chi nhánh có một quầy thu ngân để ghi lại các đơn đặt hàng
      - QTN này được quản lý và liên kết với nhau thông qua một cluster duy nhất
    - - Quầy thu ngân
      - lưu trữ dữ liệu và xử lý các yêu cầu từ ứng dụng
      - Mỗi node có thể chứa một phần của dữ liệu
    - - Tủ đựng đơn hàng trong QTN với nhiều ngăn nhỏ bên trong
      - Khi một đơn đặt hàng mới được tạo, nhân viên thu ngân sẽ đặt nó vào một trong các ngăn trong tủ đựng
      - khi một dữ liệu mới được thêm vào Redis cluster, nó sẽ được đặt vào một shard cụ thể.
    - - quầy lễ tân tại quán cà phê
      - khách hàng muốn đặt hàng hoặc truy vấn thông tin => đến Quầy lễ tân => tìm chi nhánh và xem hộc nào để lấy thông tin
      - Cluster Endpoint để gửi yêu cầu đến Redis cluster
      - Cluster Endpoint sẽ chuyển tiếp yêu cầu đó đến các nodes hoặc shards phù hợp
      - xử lý và trả về kết quả cho ứng dụng của bạn.
    - - sao chép và đồng bộ dữ liệu từ một Redis node (primary node) sang các Redis node khác (replica nodes)
      - Khi có sự cố xảy ra với primary node, replica nodes có thể tiếp tục phục vụ yêu cầu từ ứng dụng mà không làm mất dữ liệu và giảm thiểu thời gian gián đoạn
      - tạo bản photo của thông tin đơn đặt hàng từ một quầy thu ngân sang các quầy thu ngân khác
    - - tập hợp các thiết lập (parameters) và cấu hình cho Redis cluster hoặc node Redis
      - tùy chỉnh các tham số như kích thước bộ nhớ, giới hạn dung lượng lưu trữ, số lượng kết nối tối đa, thời gian timeout,...
    - - nhóm các khu vực trong quán cà phê để tạo ra một môi trường hoạt động hiệu quả
      - quản lý và gom nhóm các subnet trong mạng
      - để triển khai và hoạt động Redis clusters hoặc nodes một cách hiệu quả
      - khu vực bàn ăn, khu vực uống, khu vực quầy thu ngân, khu vực pha chế,...
  - - - Local Secondary Index (LSI)
        
        Cùng một Partition key => LSI
        
        chọn một trường trong bảng chính làm sort key
        
        DynamoDB sẽ sử dụng partition key của bảng chính và sort key của LSI để xác định dữ liệu nằm trong phạm vi truy vấn
        
        LSI có thể hữu ích trong nhiều trường hợp, ví dụ như khi bạn muốn truy vấn và sắp xếp dữ liệu theo một trường khác nằm trong cùng một partition key
      - Global Secondary Index (GSI)
        
        truy vấn và sắp xếp dữ liệu trên toàn bộ bảng, không bị giới hạn bởi 1 partition key cụ thể nào
        
        hữu ích trong các trường hợp
        
        Truy vấn & Sắp xếp dữ liệu dựa trên trường không phải partition key
    - - Mỗi tủ đựng có một khóa chính => partition key (khóa phân vùng)
      - DynamoDB là một kho lưu trữ toàn cầu, Partition là tủ đựng dữ liệu
      - Mỗi tủ đựng đại diện cho một phần của dữ liệu
    - - cho phép bắt và xử lý các sự kiện thay đổi dữ liệu trong bảng
      - Khi dữ liệu trong bảng DynamoDB thay đổi, như added/updated/deleted dữ liệu, các sự kiện thay đổi này được ghi lại trong DynamoDB Streams
      - Dùng Lambda, Kinesis Client Library (KCL) và APIs để trigger
    - - giúp tăng tốc độ truy vấn đến dữ liệu
      - DAX hoạt động như một lớp trung gian giữa ứng dụng của bạn và DynamoDB
      - Khi bạn gửi một truy vấn đến DAX, DAX sẽ kiểm tra xem nếu dữ liệu đã được lưu trữ trong bộ nhớ cache của nó
      - DAX cũng hỗ trợ việc tự động cân bằng tải và mở rộng tự động để xử lý các tải truy vấn lớn
    - - Strong Consistency
        
        đảm bảo dữ liệu mới nhất
        
        nhưng có thể tốn thời gian hơn
      - Eventual Consistency
        
        cung cấp hiệu suất đọc cao hơn vì không cần phải đồng bộ dữ liệu ngay lập tức
        
        không đảm bảo rằng bạn nhận được dữ liệu mới nhất ngay lập tức
        
        Trạng thái hết nhất quán ngắn hạn
        
        dữ liệu được sao chép hoặc đồng bộ hóa giữa các bản sao
        
        dữ liệu có thể không nhất quán giữa các bản photo
        
        mất một khoảng thời gian để các bản sao này cập nhật và đồng bộ hoàn toàn
    - - Ví von
        
        đo lường khả năng xử lý của hệ thống
        
        là khả năng của đường cao tốc để xử lý lượng giao thông (yêu cầu) một cách hiệu quả
        
        là khả năng của đường cao tốc để xử lý lượng giao thông (yêu cầu) một cách hiệu quả
        
        Tương tự như việc điều chỉnh số lượng làn xe trên một đường cao tốc, khi lưu lượng giao thông tăng, bạn có thể tăng RCUs và WCUs để đảm bảo hệ thống có đủ năng lực để xử lý yêu cầu. Ngược lại, khi lưu lượng giảm, bạn có thể giảm RCUs và WCUs để tiết kiệm tài nguyên
      - Read Capacity Units (RCUs)
        
        Đại diện cho khả năng đọc dữ liệu từ DynamoDB
        
        thể hiện số lần đọc mà hệ thống có thể xử lý mỗi giây
        
        một RCUs có thể tương đương đọc một mục dữ liệu có kích thước 4 KB một lần trong một giây
      - Write Capacity Units (WCUs)
        
        thể hiện số lần ghi mà hệ thống có thể xử lý mỗi giây
        
        một WCUs có thể tương đương với việc ghi một mục dữ liệu có kích thước 1 KB một lần trong một giây
      - (ExceedThroughput)
        
        ProvisionedThroughputExceededException
        
        Nếu yêu cầu vượt quá năng lực xử lý hiện tại
    - - cho phép tự động điều chỉnh năng lực xử lý của DynamoDB dựa trên lưu lượng giao thông hiện tại và yêu cầu của ứng dụng
      - Auto Scaling tự động tăng/giảm khả năng xử lý của DynamoDB bằng cách tăng/giảm số lượng RCUs (và WCUs
      - giúp tiết kiệm tài nguyên và giảm chi phí cho việc duy trì DynamoDB