## Scalability & High Availability
- 可扩展性意味着应用程序或系统可以通过 adapting（适应）来处理更大的负载
- 有两种可扩展性：
(资料图片仅供参考)
- **Vertical Scalability**（垂直可扩展性）：
- 增加实例大小
- →
- 常见于非分布式系统（数据库）
- RDS，ElasticCache可以水平扩展
- 垂直扩展有上限（硬件限制）
- **Horizontal Scalability**（水平可扩展性）
- 增加实例数量
- 常见于分布式系统
- 在web应用/当前应用程序中很常见
- 由于云服务的存在，很容易进行水平扩展
- **High Availability**（高可用性）
- 通常与水平扩展同时使用
- 高可用性意味着至少在两个 AZ 中运行程序/系统
- 高可用性的目的是在数据丢失时可以幸存
- 高可用性可能是被动的（RDS Multi AZ）
- 也可以是活跃的（用于水平扩展）
* * *
## Scalability & High Availability for EC2
- 垂直缩放：增加实例大小（scale up/down）
- 最小从 （ RAM，1 vCPU） 到最大 （ RAM，448 vCPU）
- 水平缩放：增加实例数量（scale out/in）
- Auto Scaling Group（自动缩放组）
- Load Balancer（负载均衡器）
- 高可用性：跨 AZ 运行同一程序的多个实例
- Auto Scaling Group multi AZ
- Load Balancer multi AZ
* * *
* * *
## Load Balancer
- 负载平衡将流量转发到下游的多个服务器（例：EC2 Instance）
<br>
user1↘-------------------------------↗EC2 Instance
user2→Elastic Load Balancer→EC2 Instance
user3↗-------------------------------↘EC2 Instance
<br>
* * *
## Why use a load balancer
- 将负载分散在多个下游实例
- 将单点访问点（DNS）暴露给应用程序
- 定期对实例进行**运行状况检查**
- 为网站提供 SSL 终止（HTTPS）
- 用 cookies 强制粘性
- 跨区域高可用性
- 将公共流量与私有流量分开
* * *
## Why use an Elastic Load Balancer
- 弹性负载均衡器是一种托管负载均衡器（managed load balance）
- AWS 保证它正常工作
- AWS 负责升级，维护和高可用性
- AWS 仅提供几个配置旋钮（knobs）
- 设置自己的负载均衡器得到成本更低，但是会花费更多时间和努力
- 与多个 AWS 产品/服务继承
- EC2，EC2 自动缩放组，Amazon ECS
- AWS Certificate Manager（ACM = AWS 证书管理器），CloudWatch
- Route 53，AWS WAF，AWS Global Accelerator
* * *
## Health Check
- 运行 Health Check（**运行状况检查**）对负载均衡器至关重要
- **运行状况检查**使负载均衡器能够知道他转发的流量的实例是否可以回复请求
- 在端口和路线上进行**运行状况检查**（/health is common 健康状况常见）
- 如果响应不是 200（OK），则实例不健康
<br>
ELB→ Health Check[Protocol:HTTP, Port:4567, Endpoint:/health]→EC2 Instance
* * *
## Type of load balancer on AWS
- AWS 有 4种 托管负载均衡器
- Classic Load Balancer（经典负载均衡器）（v1 - old generation） - 2009 - CLB
- HTTP, HTTPS, TCP, SSL（secure TCP）
- Application Load Balancer（应用负载均衡器）（v2 - new generation） - 2016 - ALB
- HTTP, HTTPS, WebSocket
- Network Load Balancer（网络负载均衡器）（v2 - new generation） - 2017 - NLB
- TCP, TLS（secure TCP）, UDP
- Gateway Load Balancer（网关负载均衡器） - 2020 - GWLB
- Operates at layer 3（Network layer） - IP Protocol
- 建议使用新一代负载均衡器，有更多功能，CLB已被取消
- 一些负载均衡器可以设置为 internal（private）或 external（public）ELBs
* * *
## Load Balancer Security Groups
Users [HTTP/HTTPS from anywhere]→ Load Balancer[HTTP Restricted to load balancer] → EC2
Load Balancer Security Groups:
|Type|Protocol|Port Range|Source|Description|
|---|---|---|---|---|
|HTTP|TCP|80|/0|Allow HTTP from anyhwere|
|HTTPS|TCP|443|/0|Allow HTTPS from anywhere|
<br>
Application Security Group: Allow traffic only from Load Balancer
|Type|Protocol|Port Range|Source|Description|
|---|---|---|---|---|
|HTTP|TCP|80|sg-054vdr405dsfd(load-balancer)|Allow HTTP from anywhere|
<br>
* * *
## Classic Load Balancers（v1）
- 支持 TCP（Layer 4）, HTTP & HTTPS（Layer 7）
- Health checks（**运行状况检查**）基于 TCP 或 HTTP
- Fixed hostname（固定主机名）：
<br>
Client [Listener] → CLB [internal] → EC2
<br>
* * *
## Application Load Balancer（V2）
- 应用程序负载均衡器作用于第七层（HTTP）
- 跨机器（目标组）对多个HTTP应用程序进行负载均衡
- 对同一机器上的多个应用程序进行负载平衡（例：容器 Containers）
- 支持 HTTP/2 和 WebSocket
- 支持重定向（例：从HTTP到HTTPS）
- 将列表路由到（Routing tables）不同目标组：
- 基于URL路径（/users & /posts）
- 基于URL主机名（ & ）
- 基于查询字符串，Headers（标头）（/users?id=123&order=false）
- ALB 适合微服务和基于容器的应用（例：Docker 和 Amazon ECS）
- 具有端口映射功能，可以重定向到ECS中的动态端口
- 相比之下，每个应用程序需要多个经典负载均衡器
* * *
## Application Load Balancer（v2）HTTP Based Traffic
<br>
www [Router/user] → External Application Load Balancer [HTTP] → Target Group for User application
www [Route/search] → External Application Load Balancer [HTTP] → Target Group for Search application
<br>
* * *
## Application Load Balancer（v2） Target Groups
- EC2 实例（可由自动缩放组管理） - HTTP
- ECS 任务（由 ECS 本身管理） - HTTP
- Lambda 函数 - HTTP 请求转换为 JSON 时间
- IP 地址 - 必须是 private IP
- ALB 可以路由到多个目标组
- **运行状况检查**在目标组级别
* * *
## Application Load Balancer（v2）Query String/Parameters Routing
<br>
www ← [Request] → External Application Load Balancer(v2) ← [?Platform=Mobile] →Target Group1 ：AWS - EC2 based
-------------------------------------------------------------------------------- ↖ [?Platform=Desktop] →Target Group2 ：On-premises - Private IP routing
<br>
* * *
## Application Load Balancer（v2）Good to Know
- Fixed hostname（）
- 应用程序无法直接看到客户端的 IP 地址
- 客户端的真实 IP 被插入到标题 **X-Forwarded-For**
- 还可以得到端口（X-Forwarded-Port）和 Proto（X-Forwarded-Proto）
<br>
Client IP ←→ Connection termination ← Load Balancer IP（Private IP） → EC2 Instance
<br>
* * *
* * *
## Network Load Balancer（v2）
- 网络负载均衡器（第四层）允许：
- 转发 TCP & UDP 流量到实例
- 每秒处理百万个请求
- 更少的延迟 ~100ms（ALB为400ms）
- NLB 在每个 AZ 都有一个静态 IP，且支持分配弹性 IP（有助于将特定 IP 列入白名单）
- NLB用于极端性能，TCP 或 UDP 的流量
- 未包含在 AWS 的免费层
* * *
## Network Load Balancer（v2） TCP（Layer 4） Based Traffic
<br>
WWW ←[TCP+Rules]→External Network Load Balancer（v2）← [TCP] → Target Group for Users application
WWW ←[TCP+Rules]→--------------------------------------------------- ← [HTTP] → Target Group for search application
<br>
* * *
## Network Load Balancer - Target Groups
- EC2 实例
- IP 地址 - 必须是私有 IPs
- ALB
- 运行状况检查（支持 TCP，HTTP 和 HTTPS 协议）
<br>
- NLB 连接目标组：
- EC2 ← NLB → EC2（Target Group：EC2 Instances）
- EC2 ← NLB → （Target Group：IP Addresses）
- NLB → ALB（Target Group：Application Load Balancer）
<br>
* * *
* * *
## Gateway Load Balancer
- 在 AWS 中部署，扩展和管理第三方网络虚拟设备
- Example：
- Firewalls（防火墙）
- Instrusion Detection（入侵检测和预防系统）
- Deep Packet Inspection Systems（深层数据包检查系统）
- Payload manipulation（有效载荷操作）
- 在 Layer 3（网络层） - 运行 IP 数据包
- 结合以下功能：
- Transparent Network Gateway（透明网关） - 所有流量的单次进出
- Load Balancer（负载均衡器） - 将流量分配到虚拟设备
- 在端口 6081 上使用 **GENEVE** 协议
<br>
Users(source) → Route Table → GWLB →Target Group - 3rd Party Security Virtual Appliances → GWLB → Application(destination)
<br>
* * *
## Gateway Load Balancer - Target Groups
- EC2 实例
- IP 地址 - 必须是私有 IPs
<br>
- GWLB 连接目标组：
- EC2 ← GWLB → EC2（Target Group：EC2 Instances）
- EC2 ← GWLB → （Target Group：IP Addresses）
<br>
* * *
* * *
## Sticky Sessions（粘性会话）（Session Affinity）
- 可以实现粘性，以便同一客户端始终重定向到负载均衡器后面的同一实例
- 适用于 CLB 和 ALB
- 用于粘性的 Cookie 有可控的过期时间
- 用例：确保用户不会丢失会话数据
- 启用粘性可能会给后端 EC2 实例得到负载带来不均衡
* * *
## Sticky Sessions - Cookie Names
- Application-based Cookies（基于应用程序的 cookies）
- 自定义 cookie
- 由 target 生成
- 包含应用程序所需的任何自定义属性
- 必须为每个目标组单独指定 Cookie 名称
- 不要使用 AWSALB, AWSALBAPP 或 AWSALBTG（保留给ELB使用）
- 应用程序 cookie
- 由负载均衡器生成
- Cookie 的名称为 AWSALBAPP
- Duration-based Cookies（基于持续时间的 cookies）
- 由负载均衡器生成
- Cookie 名称：
- ALB：AWSALB
- CLB：AWSCLB
* * *
* * *
## Cross-Zone Load Balancing
- **有**跨区域负载平衡：每个负载均衡器势力在所有 AZ 的所有实例中**均匀分布**
- AZ1：10+10
- AZ2：10+10+10+10+10+10+10+10
- **没有**跨区域负载平衡：先按 AZ 均分后，再进行均匀分布
- AZ1：25+25
- AZ2：+++++++
- ALB
- 默认启用（可以在 TargetGroup 级别禁用）
- AZ 间数据不收费
- NLB & GWLB
- 默认不启用
- AZ 间数据收费
- CLB
- 默认不启用
- 启用则 AZ 间数据不收费
* * *
* * *
## SSL/TLS - Basics
- SSL 证书允许在传输过程中对客户端和负载均衡器之间的流量进行加密（in- flight encryption）
- SSL 是指 Secure Sockets Layer，用于加密连接
- TLS 是指 Transport Layer Security，这是较新的版本
- 现阶段常用 TLS 但是同样被称为SSL
- Public SSL 证书由 Certificate Authorities（CA）颁发
- Comodo, Symantec, GoDaddy, GlobalSign, Digicert, Letsencrypt, ...
- SSL 证书由到期时间（可以设置），必须被续订更新
* * *
## Load Balancer - SSL Certificates
<br>
users ← HTTPS(encrypted) → Load Balancer ← HTTP Over private VPC → EC2 Instance
<br>
- 负载均衡器使用 证书（SSL/TLS 服务器证书）
- 可以使用 ACM（AWS Certificate Manager）管理证书
- 可以创建上传自己的证书
- HTTPS listener：
- 必须指定默认证书
- 可以添加可选的证书列表来支持多个域（multiple domains）
- 客户端可以使用 SNI（Server Name Indication）来指定他们到达的主机名
- 能够制定安全策略来支持旧版本的 SSL/TLS（legacy clients）
* * *
## SSL - Server Name Indication（SNI）
- SNI解决了将多个SSL证书加载到一台Web服务器的问题（为多个网站提供服务）
- 这是一个更新协议，要求客户端在初始SSL握手时指示目标服务器的 hostname（主机名）
- 服务器将找到正确的证书，或返回默认证书
- Note：
- 仅适用于 ALB 和 NLB（新一代），Cloudfront
- 不适用于 CLB（旧一代）
<br>
Client → ALB → Use the correct SSL cert1() → ALB → Target group for
------------------ ↘ Use the correct SSL cert2() ----------↗ ----- ↘ Target group for
<br>
* * *
## ELB - SSL Certificaties
- CLB（v1）
- 仅支持一个 SSL 证书
- 必须为具有多个 SSL 证书的多个 Hostname 使用多个 CLB
- ALB（v2）
- 支持具有多个 SSL 证书的多个 Listeners（监听器）
- 使用服务器名称指示（SNI）
- NLB（v2）
- 支持具有多个 SSL 证书的多个 Listeners（监听器）
- 使用服务器名称指示（SNI）
* * *
## Connection Draining（连接耗尽）
- 功能名称：
- 连接耗尽 - 适用于 CLB
- 注销延迟 - 适用于 ALB & NLB
- 在实例注销或不健康的情况下给予完成 in-flighr requests（机上请求）的时间
- 停止向正在注销的 EC2 实例发送新请求
- 1 - 3600秒注销延迟时间（默认 300秒）
- 可以禁用（设置值为 0秒）
- 如果请求很短，应设置更小的值
* * *
* * *
## Auto Scaling Group
- 在现实生活中，网站和应用程序上的负载可能会发生变化
- 在云端，可以非常快速的创建删除服务器
- ASG（自动缩放组）的目标是：
- 扩展（添加 EC2 实例）以匹配增加的负载
- 缩放（删除 EC2 实例）以匹配减少的负载
- 确保我们有 minimum 和 maximum 的 EC2 实例正在运行
- 自动将新实例注册到负载均衡器
- 重新创建 EC2 实例，以防之前的实例被终止（例：不健康实例）
- ASG 是免费的（只需为基础 EC2 实例付费）
## Example
<br>
|Minimum Capacity|Desired Capacity|Maximum Capacity|
|---|---|---|
|EC2 EC2|EC2 EC2|EC2 EC2 EC2 EC2|
|不少于2个|需要4个|最多可扩展到8个|
<br>
* * *
## Auto Scaling Group in AWS with Load Balancer
<br>
Users → ELB （可以检查 EC2 的 Health Situation）→ ASG（N个 EC2）
<br>
* * *
## ASG Attributes（ASG 设定值）
- 启动模板（不建议使用旧的启动配置）
- AMI + Instance Type
- EC2 用户数据
- EBS卷
- Security Group
- SSH Key Pair
- EC2 实例的 IAM Roles
- Network + Subnet Information
- 负载均衡器信息
- Min Size / Max Size / Initil Capacity（初始容量）
- 缩放策略
* * *
## Auto Sacling - CloudWatch Alarms & Scaling（CloudWatch 警报与缩放）
- 可以根据 CloudWatch 警报扩展 ASG
- 警报监控指标（平均 CPU 或自定义指标）
- 为整体 ASG 实例计算平均 CPU 的那个指标
- 根据警报：
- 可以创建扩展策略（增加实例数量）
- 可以创建缩放策略（减少实例数量）
* * *
## ASG - Dynamic Scaling Policies（动态缩放策略）
- **Target Tracking Scaling**（目标跟踪缩放）
- 最简单，易于设置
- 例：保持平均 ASG CPU 在 40% 左右
- **Simple / Step Scaling**（简单 / 步进缩放）
- 当触发 CloudWatch 警报时（例：CPU>70%），添加两个 units
- 当触发 CloudWatch 警报时（例：CPU<30%），移除一个 unit
- **Scheduled Actions**（计划操作）
- 根据已知的使用模式预测缩放情况
- 例：在周五下午5点将最小容量增加到10个
* * *
## ASG - Predictive Scaling（预测缩放）
- 预测缩放：持续预测负载并提前计划缩放
* * *
## Good metrics to scale on（可以扩展的良好指标）
- CPUUtilization（CPU 利用率）：所有实例的平均 CPU 利用率
- RequestCountPerTarget（每个目标请求计数）：确保每个 EC2 实例的请求数量稳定
- Average Network In / Out（平均网络进出）（如果应用程序是绑定网络的）
- Any custom metric（任何自定义指标）（使用 CloudWatch 推送）
* * *
## ASG - Scaling Cooldowns（冷却期）
- 缩放活动发生后，处于 cooldown period（冷却期，默认 300秒）
- 在冷却期间，ASG 不会启动或终止其他实例（以允许指标稳定）
- 建议：使用现成的 AMI 来减少配置时间，以便更快地提供请求并减少冷却时间
* * *
* * *
* * *
