天涯若比邻- AWS全球数据库解决方案
天涯若比邻- AWS全球数据库解决方案
议 程
• 全球数据库的挑战
• AWS上全球数据库解决方案
• 客户案例
全球数据库的挑战
全球数据库的原因与挑战
为什么我们需要全球部署数据库?
• 为了灾备,需要将数据库跨region部署
• 为了性能,需要将数据库在多个region分布,贴近我们的用户
全球部署数据库的挑战?
• 搭建多个region内数据库之间复制环境带来的技术挑战
• 维护多个数据库环境带来的运维压力
• 未来的扩展压力
• 尽量降低secondary region与primary region数据库之间的复制延迟
AWS全球基础设施
2006-2010: 4 区域
2016–2018: 9 区域
2011-2015: 7 区域
AWS GovCloud
US-West
Montreal
OhioN. Virginia
Oregon
N. California
São Paulo
IrelandLondon Frankfurt
Paris
Mumbai
Singapore
Sydney
SeoulNingxia
Beijing
Tokyo
BahrainHong Kong
Stockholm
AWS GovCloud
US-East
22 区域
70可用区216边缘节点
Osaka
当地区域 Cape Town
计划建设
Milan
区域与可用区
Availability
Zone AAvailability
Zone B
Datacenter
Datacenter
Datacenter
ZHY Region
Availability
Zone
Availability Zone 可用区
_ 每个region区域至少有两个可用区
_ 每个可用区都由多个数据中心组成
_ 可用区之间地理与网络都是独立设计与运营
_ 可用区专为实现物理冗余而设计,具有弹性,即使
在出现断电、互联网停机、洪水和其他自然灾害的情
况下也能实现不间断的性能。
Availability
Zone C
AWS上全球数据库解决方案
Common data categories and use cases
Relational Key-value Document In-memory Graph Time-series Ledger
QLDBTimestreamNeptuneElastiCacheDocumentDBDynamoDBRDS
Aurora CommercialCommunity
Managed
Cassandra
Service
with MongDB
Compatibility
with
Cassandra
Compatibility
Wide Column
Aurora Global Database
媲美高端商业数据库的速度与可用性
媲美开源数据库的简单性与成本效益
与MySQL及PostgreSQL全面 兼容
按使用量计费的简单定价模式
以托管服务形式交付
Amazon Aurora
Amazon Aurora…以开源级成本交付的企业级数据库
Amazon Aurora: 横向扩展、分布式架构
将Log机制推送至存储层
Master Replica Replica Replica
主
共享存储卷
副 副
SQL
事务
缓存
SQL
事务
缓存
SQL
事务
缓存
不再需要妥协!
AZ1 AZ2 AZ3
写入性能
读取横向扩展
可用区+1容错机制
即时数据库重做恢复
4/6写入仲裁与本地跟踪
“可用区+1”容错机制
为什么? 在大规模集群体系中,故障总会出现
可用区故障是一种“命中注定”
AZ 1 AZ 2 AZ 3
可用区故障时的仲裁中断
2/3读取2/3 写入
AZ 1 AZ 2 AZ 3
可用区故障时仲裁仍可继续起效
3/6读取4/6写入
如何实现? 6份副本,每可用区2份
2/3仲裁无法满足需求
写入与读取吞吐量Aurora MySQL的速度可达MySQL的5倍
0
50,000
100,000
150,000
200,000
250,000
MySQL 5.6 MySQL 5.7 MySQL 8.0
Aurora 5.6 Aurora 5.7
0
100,000
200,000
300,000
400,000
500,000
600,000
700,000
800,000
MySQL 5.6 MySQL 5.7 MySQL 8.0
Aurora 5.6 Aurora 5.7
写入吞吐量 读取吞吐量
在R4.16XL实例上运行Sysbench处理250份表,每份表包含20万行
负载条件下的性能变化Amazon Aurora >一致性提升200倍
SysBench OLTP(只写)工作负载与250份表,每表20万行,采用R4.16XL实例
0
2
4
6
8
10
12
0 100 200 300 400 500 600
时间以秒为单位
写入响应时间(秒)Amazon Aurora
MySQL 5.6 on EBS
页面缓存更新Aurora 主节点
30% 读取
70% 写入
Aurora副节点
100% 新读取
共享多可用区存储
MySQL 主节点
30% 读取
70% 写入
MySQL副节点
30% 读取
70% 写入
单线程二进制日志
数据卷 数据卷
Aurora region内高可用与只读副本的实现
使用完整的变更逻辑
相同的写入工作负载
独立存储
以物理方式使用delta变更
不向副节点写入
共享存储
MYSQL 读取扩展 AMAZON AURORA 读取扩展
“在MySQL当中,我们看到复制延迟达到近12分钟。从实际应用的角度来看,这显然是种近乎荒谬的情况。利用Aurora,4个副本的最大读取延迟从未超过20毫秒。”
Binlog Replica Lag (sec.) Aurora物理复制延迟(毫秒)Aurora逻辑复制延迟(秒)
Amazon Aurora MySQL region内逻辑与物理复制延迟
Amazon Aurora cluster
Aurora single-Region failover
Application
W R
Writ
erRead
er
AWS Region
Database storage
M RRead
er
R
Amazon Aurora cluster
Aurora single-Region failover
Application
W R
Writ
er
AWS Region
Database storage
M
Read
er
RWrit
er
MRead
er
RRead
er
R
将远程的readers 提升为 master
快速的跨region灾难恢复
更方便的跨region迁移数据方法
让客户的数据分布到不同region,更贴近用户
次秒级跨region数据复制
更快的灾难恢复和数据贴近用户
快速跨Region 灾难恢复
Reade
r
Writ
er
Applicatio
n
US
East
EU
West
全局低延迟读取
US
East
EU
West
Reade
r
Writ
er
Applicatio
n
AP
Southeast
Reade
r
Reade
r
US
West
Reade
r
全局物理复制
Primary region Secondary region
1ASYNC 4/6 quorum
Continuous backup
AZ
1
Primary
instance
Amazon
S3
AZ
2
Replica
instance
AZ
3
Replica
instance
Replication
server
Replication Fleet
Storage fleet
11
4
AZ
1
Replica
instance
AZ
2
AZ
3
ASYNC 4/6 quorum
Continuous
backup
Amazon
S3
Replica
instance
Replica
instance
Replication
agent
Replication Fleet
Storage fleet
3
3
2
① 主实例将日志记录并行发送到存储节点, 只读实例和复制服务器② 复制服务器将日志流发送到secondary region的复制代理③ 复制代理将日志并行发送给存储节点和只读副本④ 复制服务器可以从存储节点拉日志记录以弥补故障造成的间隙
高吞吐: 即使高达150K writes/second的负载; 复制对性能的影响也是微乎其微低复制延迟: 高负载下依然保持次秒级跨区域复制延迟快速恢复: 区域故障后1分钟以内即可承担全面读写
逻辑复制 物理复制
0
100
200
300
400
500
600
0
50,000
100,000
150,000
200,000
250,000
se
co
nd
s
QP
S
QPS Lag
0.00
1.00
2.00
3.00
4.00
5.00
0
50,000
100,000
150,000
200,000
250,000
seco
nd
s
QP
S
QPS Lag
逻辑复制 vs. 物理复制
全局复制性能
Active-active cross-Region setup with Aurora Global
Database
Version of the application stack is set up in another Region to
recover from disasters and serve fast local reads
Application
W R
Read
erWrit
er
Read
er
Primary Region
Database storage
Application
R
Read
er
Read
er
Secondary Region
Database storage
Read
er
DNS
Failover with Aurora Global Database
Application stack can be spun up in the secondary region and traffic can begin to be
routed there (via DNS) with the promoted writer serving write requests within 1 minute
Application
W R
Read
erWrit
er
Read
er
Primary Region
Database storage
Application
W R
Read
erWrit
er
Read
er
Promoted Region
Database storage
DNS
全局数据库
Primary region (US West) Secondary region (US East)
1ASYNC 4/6 quorum
Continuous backup
Primary
instance
Amazon
S3
Replication
server
Replication Fleet
Storage fleet
1
4
Replica
instance
ASYNC 4/6 quorum
Continuous
backup
Amazon
S3
Replication
agent
Replication Fleet
Storage fleet
3
3
2
持续插入 持续读取
U S West(Writer)
U S East(Reader)
2019-11-28
07:48:15.614.1242019-11-28
07:48:15.725.479
Replication Lag ~110ms
DynamoDB Global Table
为何选择 NoSQL?
针对存储 针对计算优化
规范化/关系型 去规范化/层级型
即席查询 实例化视图
垂直扩展 水平扩展
适合 OLAP 转为大规模 OLTP 构建
SQL NoSQL
Amazon DynamoDB
键-值和文档数据结构
可扩展支持任意负载
全托管NoSQL
访问控制
事件驱动编程
快速与一致性
Table
Items
Attributes
PartitionKey
Sort Key
• Local Secondary Index
• Global Secondary Index
00 55 A954 FFAA00 FF
分区键
分区键唯一的标识了一条记录
分区键用来构建一个非排序的散列索引
使得表可以进行分区,从而满足扩展性的需求
Id = 1
Name = Jim
Hash (1) = 7B
Id = 2
Name = Andy
Dept = Eng
Hash (2) = 48
Id = 3
Name = Kim
Dept = Ops
Hash (3) = CD
Key Space
Partition 3
分区键:排序键
分区键和排序键共同唯一的标识一条记录
在一个分区键决定的散列索引里,数据按照排序键进行排列
00:0 FF:∞
Hash (2) = 48
Customer# = 2
Order# = 10
Item = Pen
Customer# = 2
Order# = 11
Item = Shoes
Customer# = 1
Order# = 10
Item = Toy
Customer# = 1
Order# = 11
Item = Boots
Hash (1) = 7B
Customer# = 3
Order# = 10
Item = Book
Customer# = 3
Order# = 11
Item = Paper
Hash (3) = CD
55 A9:∞54:∞ AAPartition 1 Partition 2
本地二级索引 - Local Secondary Index (LSI)
可以选择与表不同的排序键
每个表分区对应一个索引分区
A1
(partition)
A3
(sort)
A2
(item key)
A1
(partition)
A2
(sort)A3 A4 A5
LSIs A1
(partition)
A4
(sort)
A2
(item key)
A3
(projected)
Table
KEYS_ONLY
INCLUDE A3
A1
(partition)
A5
(sort)
A2
(item key)
A3
(projected)
A4
(projected)ALL
每个分区键可以存储最多10 GB的数据,包括表分区和索引分区的数据量。
全局二级索引 - Global Secondary Index (GSI)
可以选择与表不同的分区键以及排序键
每个索引分区会对应所有的表分区
A1
(partition)A2 A3 A4 A5
A5
(partition)
A4
(sort)
A1
(item key)
A3
(projected)INCLUDE A3
A4
(partition)
A5
(sort)
A1
(item key)
A2
(projected)
A3
(projected)ALL
A2
(partition)
A1
(itemkey)KEYS_ONLY
GSIs
TableGSI的RCUs和WCUs是独立于表的容量而单独计算的
Partitions are three-way replicated
Id = 2
Name = Andy
Dept = Engg
Id = 3
Name = Kim
Dept = Ops
Id = 1
Name = Jim
Id = 2
Name = Andy
Dept = Engg
Id = 3
Name = Kim
Dept = Ops
Id = 1
Name = Jim
Id = 2
Name = Andy
Dept = Engg
Id = 3
Name = Kim
Dept = Ops
Id = 1
Name = Jim
Replica 1
Replica 2
Replica 3
Partition 1 Partition 2 Partition N
客户选择DynamoDB的原因
个位数毫
秒性能
支持
Global
table
自动扩容,
自动分区,
弹性伸缩
架构举例:推送服务中如何应对突发大业务量
推送服务的特点:
• 业务量变化快
• 低峰与高峰数值跃动大
• 难于预测与预留资源
• 订阅关系分布不均匀
• 实时性要求高
完全托管
AWS
Lambda
Amazon
DynamoDBAmazon API
网关
Amazon
DynamoDB
Streams
Lambda
Amazon
S3
Amazon
ES
Amazon
Athena
DynamoDB
查询端在线事务处理(OLTP)端
无服务器
利用DynamoDB进行全球扩展
客户可以采用业务层判断行数据的主写区域来避免冲突
客户可以使用DynamoDB触发Lambda做缓存更新
DynamoDB流
• DynamoDB流是针对表里的数据变化的顺序记录• 在流里,针对表的变化的记录只会出现一次• 在流里的记录的顺序与表上发生修改操作的顺序是一致的• 流里的数据保存24小时,24小时以后自动删除• 可以把表的数据被更新前的值以及更新后的值都写到流里• 流里的数据通过API进行消费
访问DynamoDB流记录
• DynamoDB和DynamoDB流记录使用了不同的终端节点。
• 使用DynamoDB终端节点来访问表和索引。• 要访问DynamoDB流记录,则使用相同区域里的流
的终端节点。• DynamoDB流的终端节点的命名规则为
streams.dynamodb.<region>.amazonaws.com。• 使用DynamoDB Streams Kinesis Adapter来访问
DynamoDB流记录。同时Kinesis Adapter实现了Kinesis Data Streams接口,因此可以使用Kinesis
KCL来消费DynamoDB流的记录。• 也可以使用DynamoDB流的Low-Level的API来消费
DynamoDB流的记录。
DynamoDB流里记录的数据内容
DynamoDB流可以配置为四种写入的数据内容:
• KEYS_ONLY – 只有分区键和排序键的数据被写入流
• NEW_IMAGE – 修改后的整条记录都被写入流
• OLD_IAMGE – 修改前的整条记录都被写入流
• NEW_AND_OLD_IMAGES – 修改前和修改后的整条记录都被写入流
Partition Key
Partition Key
修改前的记录
修改后的记录
DynamoDB的流记录
DynamoDB流的应用场景
• 表之间的数据复制
• 触发器
• 容灾和多区域复制
• 数据汇总
• 数据安全和通知
DynamoDB流和AWS Lambda结合构建触发器
AWS Lambda把数据变化通知出去Amazon Kinesis
Data FirehoseAmazon Simple
Notification Service
Amazon Elasticsearch
Service
DynamoDB流和AWS Lambda触发器举例
StreamReader
多区域复制
Region
区域 1
Region
区域 3
Region
区域 2
StreamReader
StreamReader
创建Global Tables
创建Global Tables
创建Global Tables
管理Global Tables
Amazon CloudWatch metrics
• ReplicationLatency: 预计传播时间• PendingReplicationCount: 写入一个region但尚未传播到其他region的items
written 数
ElastiCache Global Datastore
Redis 概述
高速
大部分命令的时延小于1ms
开源
易学易用
高可用
复制
原子操作
支持事务
内存中的
键值存储
功能强大
200条左右的命令, Lua脚本, 地理空间
, 发布/订阅模式
不同的数据结构Strings, lists, hashes, sets, sorted sets, bitmaps, streams,以及 HyperLogLogs
备份/恢复
快照
很难伸缩难于管理 很难做到高可用
Redis 在管理方面的挑战
成本昂贵
在线伸缩可能会出
需要监控复制的性能
管理工作包括但不仅限于:
硬件部署,软件升级,配
置,以及备份
Redis集群故障会导致系
统性能受影响
需要为运维人员, 流程,
硬件和软件进行投入
Amazon ElastiCache for Redis 介绍--全托管, 兼容 Redis, 内存数据存储在云端
极致性能
内存数据存储并提供小于1ms的响
应时间
全托管
AWS管理所有的硬件以及软件的配
置和监控
易伸缩
通过副本提供读操作的伸缩通过
分片提供写操作的伸缩非中断的
伸缩
兼容 Redis
支持 Redis 5
兼容不同 Redis clients
可靠性
多可用区
深度监控
自动故障转移
安全与合规
Amazon VPC
HIPAA, PCI, FedRAMP
存储和传输中进行加密
身份认证
Redis 使用场景
游戏排行榜
聊天应用
缓存
会话存储 机器学习
实时分析 流媒体地理空间
消息队列
所有的键都在同一台节点上
VPC
Public subnet
Availability zone 1
Public subnet
Availability zone 2
Auto Scaling group
Private subnet Private subnet
Cache node
Cache node
Primary Endpoint Replica Endpoints
Keysp
ace
连接到主节点进行读写操作,连接到副本进行读操作
Elasticache Redis 禁用集群模式 (垂直伸缩)
( CW 指标: CurrItems )
VPC
Public subnet
Availability zone 1
Public subnet
Availability zone 2
Auto Scaling group
Private subnet Private subnet
Cache node
零宕机伸缩
ConfigurationEndpoint
Cache node
Cache node
Cache node
Shard 1 Slot 0 - …
Shard 2 Slot … to …
Keysp
aceShard 3 Slot … to …
Shard 4 Slot … to 16383
根据分片进行分区
Cluster Map
客 户 端 对 键 使 用CRC16 算法计算散列值,并用该散列值对16384取模
DistributionEqual | Custom
Elasticache Redis 集群 (水平伸缩)
特性 启用 禁用
配置数据在不同的分片之间进行分区(最高 15 个),每个分片有一个主节点以及最多5个副本节点
数据保存在一个主节点里,最多具有 5 个副本节点
Redis compliant 与开源的 Redis 集群 API 以及客户端生态完全兼容与开源的 Redis 集群API以及客户端生态完全兼容
集群规模 90 个节点 – 15 个主节点 + 每个分片的 0–5 个副本 6 个节点 ( 1 个主节点 + 0–5 个副本)
伸缩性和性能• 吞吐量随着分片的数量进行伸缩• 内存容量最高可到 9.5 TiB
• 吞吐量由 1 个主节点和5个副本所决定• 内存容量最高到 635 GiB
最大连接数• 主节点 (65,000 x 15 = 975,000)• 副本 (65,000 x 75 = 4,875,000)
• 主节点: 65,000• 副本: (65,000 x 5 = 325,000)
Redis 启用集群模式 vs. 禁用集群模式
Redis 启用集群模式 vs. 禁用集群模式
特性 启用 禁用
伸缩操作集群在线调整尺寸• 水平伸缩:添加或删除分片• 只读活动的伸缩:添加或删除副本
垂直伸缩• 写操作被中断• 禁止在主节点上进行读操作
故障转移 15–30 秒 (无需DNS切换) 30-45 秒 + 额外的 DNS 广播时间
故障转移风险• 部分数据集上的写操作被影响• 读操作无影响
• 整个数据集上的写操作被影响• 读操作无影响
成本
举例: 假设当前的工作负载需要140 GB的缓存
多个小机型组成
15 x cache.r4.large ($0.228hr) = $3.42 hour 184.5 GB
一个大机型组成
1 X cache.r4.8xlarge = $3.64 hr, 203.26 GB
Cache node
主节点 副本
分片
x5
x15
Cache node
异步复制
CW 指标: ReplicationLag
启用集群模式下的故障转移
Cache node
主节点 副本
分片
Cache node
异步复制
检测到故障
启用集群模式下的故障转移
Cache node
主节点 副本
分片
Cache node
异步复制
自动故障转移
(无需DNS广播)
使用故障转移 API 进行测试
SNS 事件: ElastiCache:CacheNodeReplaceComplete
SNS 事件: ElastiCache:FailoverComplete
启用集群模式下的故障转移
Global Datastore in Amazon ElastiCache for Redis
快速、可靠、安全的完全托管式跨区域数据复制
主集群在一个区域,从集群在其它区域
跨区域数据复制延迟通常小于 1 秒
为全球化应用提供低延迟的快速本地数据读取
更快的跨区域灾难恢复
把从集群提升为主集群的时间通常小于1分钟
Global Datastore in Amazon ElastiCache for Redis
• 支持1个主集群(写/读),最多2个从集群(只读)• 目前支持11个AWS区域:美国东部(弗吉尼亚北部)、美国东部
(俄亥俄)、美国西部(加利福尼亚北部)、美国西部(俄勒冈)、亚太地区(首尔)、亚太地区(新加坡)、亚太地区(悉尼)、亚太地区(东京)、欧洲(法兰克福)、欧洲(爱尔兰)和欧洲(伦敦)
• 支持Amazon ElastiCache for Redis 5.0.6 或更高版本• 支持 M5 和 R5 节点• 从集群与主集群具有相同的节点类型、引擎版本、和分片数目• 修改一个集群的本地参数组将应用于整个Global Datastore中的集群
设置 Global Datastore
• 使用现有集群作为主集群
• 或者直接创建一个新集群作为主集群
添加/删除/修改 集群
将从集群提升为主集群
• 在主集群(区域)降级的情况下,手动启动故障转移
• 从集群的故障转移和升级通常会在一分钟内完成
• 当从集群升级为主集群时,ElastiCache 会将旧的主集群(如果可访问)重新配置为从集群,并设置复制以将所有次要区域与新的主集群同步
客户案例
以 游 戏 直 播 为 核 心 业 务
致力于打造全球领先的直播平
台
虎牙
I n t r o d u c t i o n中 国 直 播 行 业 领 军 者
虎牙直播
NimoTV
YomeTV
风靡海外的移动游戏直播平台
国内领先的游戏直播平台
全球化的娱乐直播生力
军
2012YY推出游戏直播业务(虎牙直播前身) 2014
2016虎牙公司正式独立发展战略ALL in移动游戏直播 2018
成功上市NYSE:
HUYA
中国游戏直播第一股
发 展 历程
YY游戏直播正式更名虎牙直播
产 品 矩阵
应用场景:
• 2018年初,虎牙直播上线海外产品 Nimo TV,年底,月活用户已达千万级。
产品成功登陆东南亚及拉美地区,2019 年进入西语市场。
• 数据库后台,动态信息由 Amazon DynamoDB 存储,包括支付、状态、好
友关系等。相对静态的信息则存储在 Aurora 上,如用户的基础信息。
获得的收益:
• 与MySQL相比,5倍以上的性能表现。Aurora 能够自动扩容,且计算和存储
分离。数据量较大时,能够单独升级计算实例,确保性能。
• 支持故障转移。异常情况下,通常只需要几十秒就能够自动实现故障转移,终
端用户无感知。
• 利用全球数据库功能,提升本地用户体验。虎牙直播在 AWS 亚太(新加坡)
区域部署数据库,并在其它区域建立副本。
广州虎牙信息科技有限公司是一家以游戏为核心的直播平台,致力于成为受年轻人欢迎的技术驱动型娱乐社区。虎牙直播覆盖全品类游戏内容,全年直播电竞赛事超过360场。在游戏直播的成功基础上,虎牙直播已发展为包含泛娱乐、真人秀、二次元、户外等内容的综合性互动平台。2018年5月,虎牙直播成功在美国纽交所上市,一个月内涨幅超过400%,市值超过百亿美元,创造直播行业新的里程碑。
”
“
Amazon Aurora 客户案例 – 虎牙直播
https://amazonaws-china.com/cn/solutions/case-studies/huya/
• 统一业务中心
Amazon
Aurora
Amazon DynamoDB Amazon ElastiCache
Amazon
SQS
Amazon SNSAmazon
Autoscaling
关键服务
• 全球快速部署
• 自动灵活扩展
AWS助力虎牙快速出海
• 全球用户实时互
动
总 结
• 全球数据库的挑战
• AWS上全球数据库解决方案
• 客户案例
我们希望您喜欢今天的内容!也请帮助我们完成反馈问卷。
欲获取关于 AWS 的更多信息和技术内容,可以通过以下方式找到我们:
感谢参加 AWS 在线研讨会
微信订阅号:AWS 云计算(awschina)
新浪微博:https://www.weibo.com/amazonaws/
视频中心:http://aws.amazon.bokecc.com/
更多线上活动:https://aws.amazon.com/cn/about-aws/events/webinar/
微信服务号:AWS Builder 俱乐部(amazonaws)
抖音:AWS 云计算(抖音号:266052872)
博客:https://aws.amazon.com/cn/blogs/china/
AWS 中国账户注册
AWS 全球账户注册