## 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 来减少配置时间，以便更快地提供请求并减少冷却时间

* * *

* * *

* * *