亚马逊云科技-如何迁移到亚马逊ElastiCache出海

亚马逊云科技-迁移ElastiCache出海技术讲座

关键字: [yt, ElastiCache, Migrating Workloads, Amazon Elasticache, Open-Source Engines, Migration Strategies, Operational Best Practices, Backup And Restore, Online Migration Tool, Customer Experiences, Managed Service Benefits, Redis Cluster Topologies]

本文字数: 500, 阅读完需: 2 分钟

导读

在此技术讲座中,演讲者探讨了如何将自托管的Redis和Memcached工作负载迁移至Amazon ElastiCache。具体而言,ElastiCache支持开源的Redis和Memcached引擎,并提供托管运维、高可用性和可扩展性等优势。演讲者重点阐述了ElastiCache如何实现降低运维开销、自动故障恢复和动态扩缩容等功能,让内存数据库用户能够专注于业务创新,加快创新步伐。

演讲精华

以下是小编为您整理的本次演讲的精华，共200字，阅读时间大约是1分钟。

今天的技术讲座主题是将工作负载迁移到Amazon ElastiCache。作为亚马逊云科技的解决方案架构师,Jim Gallagher主要负责帮助客户充分利用内存数据存储的强大功能。本次讲座将侧重于技术层面,包括动手操作演示和深入的逐步演练。即使是ElastiCache的新手,也请继续关注,因为将提供一些非常有价值的信息。

首先,让我们简要概述一下ElastiCache服务及其解决的问题。将从ElastiCache服务的概览开始,包括它支持的开源引擎。接下来,将探讨客户选择将托管或自托管的工作负载迁移到ElastiCache的一些常见原因。然后,将深入研究实际执行迁移的具体细节,包括操作最佳实践,并进行一些真实世界的演示。

将介绍两种迁移方法。第一种是备份和恢复方法,对当前系统进行快照,并将该快照导入到新的ElastiCache环境中。第二种方法是使用ElastiCache的在线迁移工具,该工具允许客户实时将旧环境与ElastiCache进行数据同步。之后,将分享一些客户案例,亲身体会ElastiCache为他们的业务带来的好处,相比自托管而言有何不同。最后,将提供一些有用的技巧和资源链接,如动手实验室、文档等,以帮助更好地学习ElastiCache。

现在,让我们从ElastiCache服务的概览开始。将介绍服务的基础知识、常见用例、ElastiCache如何与其他亚马逊云科技服务配合使用,以及迁移工作负载到ElastiCache时需要考虑的实际因素。

我们不断听到客户对应用程序速度的需求。难以想象一个不需要提高速度的应用程序。速度对业务也很重要。Akamai的一项独立研究发现,仅100毫秒的延迟就可能导致电子商务转化率下降7%。当今的客户期望尽可能接近实时的性能。快速是一方面,但规模也同样重要。在开发现代互联网应用程序时,需要能够处理随之而来的互联网规模流量。这种弹性正是将工作负载迁移到云端的一个关键驱动力。

从电子商务到游戏、媒体、金融服务等各种类型的应用程序,都可以从尽可能接近实时的服务中获益。同样,开发人员也期望能够使用开源技术和常见API,而不会被锁定在昂贵的商业级数据库中。当然,亚马逊云科技客户还期望灵活的按使用付费定价模式,让他们可以从小做起,然后逐步扩展。所有这些都应该在亚马逊云科技支持的所有区域中提供。这就是ElastiCache的用武之地。亚马逊云科技为不同的应用程序需求提供了多种用途构建的数据库,从关系模型到无服务器键值对、文档、图形和其他NoSQL数据库,甚至是托管的区块链。在这个家族中,ElastiCache是独一无二的,因为所有数据都是直接从内存中提供服务。传统上,数据库一直是应用程序堆栈中最慢的环节。但在内存数据库中,数据可以以RAM的速度获取。回顾上一张幻灯片,我们需要应用程序能够近乎实时响应,利用性能最佳的数据库就变得至关重要。

ElastiCache的一大优势是,它可以与亚马逊云科技提供的其他用途构建的产品配合使用,既可以作为热数据的缓存与其他后端数据存储配合,也可以作为现代微服务驱动的应用程序堆栈中的独立内存层。使用亚马逊云科技,为客户提供了选择适合工作的正确工具的灵活性。当需要卓越性能时,ElastiCache就是那个工具。稍后将看一下这些模式的一些示例架构。

让我们深入了解一下这项服务。首先需要注意的是,ElastiCache支持两种流行的开源内存数据库:Redis和Memcached。本次讲座的重点将是Redis,因为作为一种开源技术,它在迁移数据方面具有更大的能力。Memcached通常用于纯内存工作负载,它不支持诸如复制或持久化等功能。也就是说,Memcached工作负载从迁移到ElastiCache中也可以获得巨大好处,但由于数据的短暂性,这些迁移通常更简单。我们注意到客户采用Redis的趋势明显。虽然将在接下来的演示中广泛涉及Redis,但请知悉,ElastiCache与开源Redis和Memcached兼容。如果已经在自托管这些工作负载,通常可以在不更改任何代码的情况下将它们迁移过来。

当然,客户选择ElastiCache主要是因为其卓越的性能。如前几张幻灯片所述,ElastiCache的典型查询性能是以微秒而不是毫秒来衡量的。除了作为开源内存数据存储的优势之外,ElastiCache作为一项服务还提供了许多相比自托管的优势。首先,它作为托管服务,内置了安全性和可靠性,包括管理部署、补丁、维护升级,以及提供网络隔离、加密选项、内置监控等。此外,ElastiCache可以配置为跨多个可用区域自动部署,并实现自动故障转移。最后,ElastiCache能够轻松扩展工作负载,从最小的开发环境到跨多个区域的数百个节点集群,只需点击一个按钮即可。简而言之,ElastiCache极大地简化了内存数据库环境的部署、管理和可扩展性,同时保留了开发人员钟爱的开源API。事实上,连续四年,Redis都荣获StackOverflow年度开发者调查中”广受好评的数据库”奖项。客户也告诉我们,他们喜欢Redis的速度、易用性和丰富的内置数据结构。Redis的典型用例包括缓存、消息传递、实时分析、排行榜等,许多人认为Redis就像一把瑞士军刀,具有很大的灵活性。稍后将看到,这些不同的方法如何影响潜在的迁移策略。

再多说一点关于Redis的内置数据结构。然而,除了数据结构之外,它还具有一些出色的功能,可以帮助迁移数据,比如跨节点复制数据的能力,以及通过快照实现的内置持久化功能。在今天的演示中,将看到这些功能的实际应用。

与 Redis 作为内存数据存储在概念上相似的 Memcached,在实践中要简单得多。它仅支持一种数据结构——字符串,且没有 Redis 的持久化和复制选项。因此,在迁移到 ElastiCache 时,如前所述,通常只需将应用程序指向新环境,而无需担心迁移任何数据。客户青睐 Memcached 的简单性和高性能。由于与开源 Memcached 兼容,因此将 Memcached 工作负载迁移到 ElastiCache 非常简单。

通过这两种引擎,以下是 ElastiCache 的一些常见用例示例。如前所述,任何需要实时性能的应用程序都可以从内存层中获益。缓存无疑是最常见的用例,通常与其他较慢的数据存储配合使用。同样,实时分析仪表板也可以由 ElastiCache 驱动,因为它的响应时间在亚毫秒级别。如果您最近玩过某款在线游戏,其中有某种排行榜,很可能就是由 ElastiCache 提供支持。同样,如果您使用过某种打车应用或约会应用需要实时地理空间信息,那也很可能是由 ElastiCache 驱动的。此外,分布式会话存储、实时聊天、分布式队列、机器学习特征存储等也都是利用 ElastiCache 的绝佳场景。

让我们花点时间看一下缓存和会话存储的一些示例架构。我们的第一个示例架构是数据库缓存模式,这里我们展示了一种非常简单、众所周知的模式,即写入或延迟加载方式。这种模式通常只需要几行代码就可以极大提高应用程序性能。在这里,我们将 ElastiCache 与另一个后端数据存储(如 RDS)结合使用。应用程序首先查询缓存是否有所需数据。如果有,也就是缓存命中,数据将以通常在毫秒级的速度返回给应用程序,而无需查询数据库。如果缓存中没有数据,也就是缓存未命中,应用程序将从数据库查询所需数据。同时,我们还会将这些数据填充到缓存中,以备将来查询。通常,客户会为缓存数据设置生存时间(TTL),以帮助确保缓存的新鲜度。

另一种 ElastiCache 架构是将其用作会话存储。在这个示例中,ElastiCache 完全独立于其他数据存储运行。这是一种非常强大的模式,因为它解锁了在应用程序层而不是依赖粘性会话或节点缓存来实现弹性的能力。应用程序中用户的所有会话信息,如登录信息、浏览历史、购物车数据等,都存储在 ElastiCache 中。我们完全消除了在应用程序层存储有状态信息的概念。该图显示了两个 EC2 实例,但这也可以是容器或 Lambda 函数等任何类型的计算资源。

现在我们对 ElastiCache 服务有了更多了解,让我们来看看客户告诉我们的一些将自托管的 Redis 和 Memcached 工作负载迁移到 ElastiCache 的原因。

客户选择为其 Redis 和 Memcached 工作负载使用托管服务的第一个原因是,虽然这些开源引擎对开发人员来说非常易于上手和使用,但您会注意到,爱好这些数据库的是开发人员,而不是运维团队。我们的客户告诉我们,他们不希望承担管理底层服务器、软件版本、监控、配置、备份等无差别的繁重工作。他们只是希望获得性能和规模,而无需操作开销。

除了基础设施的基本要求之外,使这些开源技术高度可用也是一个挑战。检测并自动从故障中恢复需要复杂的定制开发和管理。而且,除了可用性方面,扩展也变得很麻烦。您需要监控系统,以便知道何时需要扩展。而且,实际执行扩展操作本身也可能出错。所有这些都会导致额外的开销,包括人力、操作流程和不必要的复杂性。

利用托管服务的好处包括消除这种运维开销,让您的团队能够专注于差异化业务和更快创新,从而为客户提供更好的服务。ElastiCache 不仅消除了管理 Redis 工作负载的运维负担,它还提供了一些比典型的自托管开源 Redis 更出色的增强功能。以下是我们最近对该服务所做的一些增强示例。

首先是全球数据存储,它允许客户跨区域复制环境,为世界各地的客户提供低延迟的读取访问。接下来是动态扩展 Redis 集群的能力,可实现零停机、四向扩缩容,即向内、向外、向上和向下扩展。在这里,我们可以将环境扩展到总共 500 个节点,每个节点的总数据存储容量可超过 600GB。我们还最近针对最新的 Amazon Web Services Nitro 系统进行了优化,大幅提升了网络性能。我们还优化了 Redis 引擎本身的 I/O 能力,以提供更高的网络性能。此外,我们还支持最新的 Graviton 2 系列实例,可提供高达 40% 的价格/性能改进。所有这些功能在开源 Redis 中都是无法获得的,这也是客户采用 ElastiCache 的另一个驱动力。

现在让我们来看一下在规划迁移到 ElastiCache 时需要考虑的一些因素。假设您已经确定了要从自托管迁移到 ElastiCache 的 Redis 或 Memcached 工作负载,您首先需要对一些细节进行分类。这个工作负载是短暂的还是更持久的?例如,如果您只是在进行简单的数据库缓存,使用前面展示的延迟加载模式,那么只需将应用程序指向新的 ElastiCache 端点,而无需迁移任何数据就可以了。但是,如果您的工作负载更像是主数据库或会话存储,那么您可能需要考虑一种零停机的策略。

根据您的工作负载特征和业务需求,您可以规划适当的迁移策略。

另一个需要做出的策略决定是进行在线迁移还是离线迁移。这回到之前的一点,即了解您的应用程序能够容忍多少停机时间。如果您有机会安排维护窗口,那么离线策略可能是最佳选择。如果您需要最小化停机时间,那么在线方法可能更合适,因为它可以在完全加载缓存的同时进行迁移。

您还需要考虑在切换到新环境时应用程序的行为。对于大多数应用程序而言,只需切换端点即可,但您需要制定操作计划,了解如何以及何时执行该配置更改。这取决于您的应用程序架构,超出了本次讲座的范围,但我们鼓励您与我们联系,看看我们是否可以提供帮助。

您还需要为目标ElastiCache环境做适当的规划。接下来,我们将讨论一些可帮助您根据工作负载的性能特征确定适当集群大小和拓扑的指导原则。

深入探讨可用的Redis部署拓扑是一个至关重要的考虑因素,因为它将影响哪些迁移选项对用户可用,以及用户的工作负载的未来可扩展性。集群模式启用或禁用是两种可能的Redis部署选项。在这里,集群模式是指Redis可以跨多个节点分片数据集,这些节点共同作为一个逻辑集群运行。每个分片或分区最多可以有5个副本。同样,在集群模式禁用的情况下,用户的整个数据集将驻留在一个节点上,但也可以扩展到最多5个副本。

我们不会涵盖两者之间所有的差异,稍后我们还将提供一些关于如何为用户的工作负载估算大小的参考资源。但是,需要指出的是,通常客户会为较大的数据集和/或更高性能的工作负载选择启用集群模式,因为它可以扩展到超过300TB的总内存存储,并能够处理每秒数千万次操作。但是,当我们开始从工具的角度来看迁移路径时,根据集群拓扑,有不同的方法可供选择。如果用户注意到比较中的迁移路径部分,集群模式启用支持备份和恢复方法,而集群模式禁用则可以使用在线迁移工具。让我们现在来看看这些方法。

这是我们的第一种迁移方法:备份和恢复方法。从概念上讲,这种模式非常简单。我们将利用Redis内置的能力创建当前系统数据的磁盘快照,称为RDB文件。RDB是内存中存储的数据的二进制表示形式,并进行了一些压缩。一旦有了快照,只需将快照上传到S3存储桶中,并授予ElastiCache读取RDB文件的权限即可。然后,在创建新的ElastiCache集群时,我们指定RDB文件并使用它为新集群提供数据。由于这被认为是一种离线迁移,因此我们建议在可以利用计划内维护窗口时使用此方法。总体恢复时间将取决于RDB文件的大小以及整体集群的大小。因此,我们鼓励用户尽可能提前进行测试。

让我们看看这个过程的实际操作。我们将从笔记本电脑上本地运行的Redis服务器开始,生成一些示例数据以保存RDB文件。然后,我们将它复制到S3存储桶中,授予相应权限,并使用该RDB文件创建新集群。

这里是连接到笔记本电脑上的本地服务器。首先,将启动从源代码编译的Redis服务器实例。这只是一个开源Redis的示例。现在服务器已启动并在后台运行,我们可以使用Redis CLI实用程序连接到它。

首先,我们使用KEYS命令查看系统中是否有任何数据。我们可以看到当前没有任何数据。接下来,将执行一些简单的命令来保存一些数据。我们执行SET HELLO WORLD,GET HELLO。现在我们可以看到,一个非常简单的测试键已保存在系统中。

下一步将生成RDB文件。这里将利用Redis的内置SAVE命令,就是这样。我们还可以从服务器进程本身看到一条条目,说明它已将数据库文件保存到磁盘上。

完成后,将断开与服务器的连接,看看默认名为DUMP.RDB的文件是否存在。是的,这里有。

下一步是将此文件复制到S3存储桶中。已经提前创建了一个使用默认设置的S3存储桶。接下来,只需复制文件即可。出于个人习惯,将使用命令行进行操作,但通常用户也可以通过控制台或API进行操作,使用任何最熟悉的方式。

使用Amazon CLI,将使用S3 CP命令。将传入RDB文件的位置,然后指定创建的S3存储桶的位置。就这样,文件现已上传。

将切换到浏览器,看一下情况。这是S3存储桶。点击刷新,应该就可以看到刚上传的文件了。

接下来是授予ElastiCache读取此文件的适当权限。首先,只需单击该文件本身,然后单击权限选项卡。接下来,点击编辑按钮。

下一步是滚动到”其他亚马逊云科技账户的访问权限”部分,并点击”添加账户”按钮。最简单的方法是参考ElastiCache文档,已经打开了相关文档,其中给出了ElastiCache访问存储桶所需的规范ID。如果在其他区域运行或由于其他原因默认值不起作用,文档中也有清晰的选项说明,鼓励用户查看相关内容。

现在,将复制规范ID,返回控制台,粘贴该ID,并授予相应的读取权限,然后滚动到底部并单击”保存更改”。

现在,备份文件已获得ElastiCache读取的适当权限。接下来,我们将切换到ElastiCache控制台。用户可以简单地滚动到数据库部分并单击ElastiCache进入该控制台。接下来,将点击”创建集群”下的”创建”按钮。

在这里,将为集群命名为”SEEDED”。然后,正如之前提到的,将保留大多数默认设置,因为我们没有做任何特别复杂的事情。但关键是要在”将数据导入集群”部分指定RDB文件的位置。

所以在这里,将指定S3存储桶别名和文件名。就这样,只需点击”创建”即可。也可以通过命令行或API执行此操作,但为了简单起见,在这里使用控制台。

完成后,ElastiCache将启动创建新集群并导入备份的过程。这个过程需要几分钟时间,所以我们将在研究另一种在线迁移方法时返回查看进度。

让我们来看看下一种方法:利用ElastiCache的在线迁移工具。与前一个示例是离线方法不同,在线迁移工具允许用户在保持数据集同步的情况下执行实时复制和切换到ElastiCache。该过程有一些先决条件,以允许系统成功通信。让我们来看看这些准备工作。

为了准备源和目标Redis节点进行迁移,需要确定目标ElastiCache部署,并确保可以将数据迁移到该部署。现有或新创建的ElastiCache部署应满足以下迁移要求:

• 集群模式已禁用,使用Redis 5.0.5或更高版本引擎
• 未启用传输加密或静态加密
• 已启用多可用区域并启用自动故障转移
• 使用足够内存的EC2实例类型,可容纳用户的Redis数据

您可以直接从Redis 2.8.21及更高版本迁移到Redis 5.0.5及更高版本。请确保Redis on EC2实例和ElastiCache for Redis部署的配置相互兼容。至少,目标ElastiCache部署中的以下内容应与Redis配置兼容,以便进行复制:

• Redis集群应配置为集群模式已禁用
• Redis on EC2实例上未启用Redis AUTH
• Redis CONFIG PROTECTED MODE应设置为NO
• 如果Redis配置中有BIND配置,则应更新以允许来自ElastiCache的请求
• 逻辑数据库的数量应与Redis on EC2实例上的相同,这是使用Redis配置中的DATABASES设置的
• 执行数据修改的Redis命令不应重命名,以允许数据成功复制

为了将数据从Redis集群复制到ElastiCache,请确保有足够的CPU和内存来处理此额外负载。这种负载来自Redis集群创建的RDB文件,并通过网络传输到ElastiCache节点。

确保EC2实例可以连接到ElastiCache,方法是:

• 确保EC2实例IP地址是私有的
• 在与Redis on EC2实例相同的VPC中分配或创建ElastiCache部署
• 如果VPC不同,请设置VPC对等以允许节点之间的访问
• 附加到Redis on EC2实例的安全组应允许来自ElastiCache的入站流量

注意,请确保应用程序可以在数据迁移完成后将流量定向到ElastiCache节点。

有了这些准备工作,让我们来看一个在线迁移工具的示例。与上一个示例类似,已在EC2服务器上预先配置了一个小型测试环境,符合之前列出的要求。将启动迁移,实时观察结果,然后切换过去。今天,将展示一个非常简单的示例,但对于包含更多数据的更长示例,可以通过CloudWatch监控迁移进度。

这里是连接到运行在EC2上的另一台服务器。与之前一样,第一件事是启动从源代码编译的本地Redis服务器实例。就像上次一样,得到了一些服务器本身的标准输出信息,但它正在后台运行,可以像之前一样通过命令行连接到它。

首先,将清除系统中可能存在的所有内存或键,然后设置一些测试键。执行SET,将一个键命名为ONLINE,值为MIGRATION。也许还可以创建一个集合,命名为TEAMS,并添加一些NFL球队,比如BEARS、LIONS、PACKERS。也许还可以创建一个哈希,将创建一个名为EMPLOYEES的哈希,并添加JEFF BEZOS和JASSING。

要求之一是设置一个名为CONFIG SET PROTECTED MODE NO的配置参数。PROTECTED MODE是Redis的一个安全保护功能,如果使用默认设置启动集群,默认情况下它不会允许来自外部服务的任何连接。但由于要迁移到外部服务,因此需要将此配置设置为NO。

有了这些准备,系统现在应该已准备好迁移到新的ElastiCache环境了。再次回到ElastiCache控制台,这里有一个之前创建的集群,符合先决条件。处于集群模式已禁用、具有两个节点的多可用区域故障转移配置,并且未启用传输加密。

第一步是点击”操作”按钮,然后点击”从端点迁移数据”。对于我来说,可能需要刷新屏幕。点击”从端点迁移数据”。需要传入的唯一参数是源Redis端点。这应该是运行现有Redis服务器的EC2服务器的私有IP地址。手头正好有这个IP地址,所以将输入。

就这样,所需要做的就是点击”开始迁移”。这将在后台启动迁移过程。应该会从运行在EC2上的Redis服务器看到一些信息,说明ElastiCache正在连接并开始复制过程。让我们看看会出现什么。

这里可以看到,可能有点难以辨认,但这是服务器正在复制的信息。它首先尝试进行部分重新同步,但失败了,因为之前没有同步过。然后它创建了一个新的复制,并输出了一些相当技术性的详细信息,但这只是Redis在指示迁移过程的当前状态。如果注意到,最终从服务器获得了一条输出,说它正在与副本同步,这是新的ElastiCache集群的IP地址,并且它说成功了。

有了这个,可以返回控制台,现在复制已经完成,可以再次点击”操作”菜单,然后点击”停止数据迁移”。再次回到终端,应该会看到一些信息说系统已断开连接。现在,还应该能够连接到新的ElastiCache服务器并查看已复制的数据。

就这样,现在通过命令行连接到ElastiCache。理想情况下,如果执行KEYS *,应该就可以看好的,让我继续生成剩余的内容:

到数据。这里是之前在本地系统上创建的键。可以执行GET命令,比如GET ONLINE。所以,这里是之前在本地系统上生成的数据,现在驻留在ElastiCache上。在线迁移已成功完成。

有了这个,可以清理现有的EC2服务器,现在可以自由使用ElastiCache了。

在演示的最后部分,让我们看一些客户成功迁移到ElastiCache的案例,并回顾一些后续材料。

我们有一些客户成功迁移至ElastiCache。首先是约会应用Tinder,他们最近在《福布斯》杂志上发表了一篇文章,详细介绍了他们的迁移经历。文中有以下几段引语:“在迁移至ElastiCache之前,Redis缓存节点故障是Tinder应用程序停机的最大单一来源。迁移之后,节点可靠性问题的频率大幅降低,应用程序稳定性显著提高。只需在亚马逊云科技管理控制台中点击几下,他们就可以轻松扩展集群、创建新分片和添加节点。Redis迁移在很大程度上释放了他们的运营工程师的时间和资源,并带来了监控和自动化方面的显著改进。”

同样,2018年,Airbnb也从自托管Redis迁移至ElastiCache。当时的网站可靠性工程师Julie Trias在一次亚马逊云科技再:Invent Summit上详细讲述了他们的经验。您可以在YouTube上找到她的演讲,我们在这里也链接了该视频。它提供了一个很好的深入案例,介绍了一个互联网规模应用程序将工作负载迁移至ElastiCache的实际用例和操作计划。

我们链接的最后一个案例来自国际知名的宝可梦公司,他们是备受赞誉的宝可梦系列的制作者。为了满足他们热门游戏《Pokémon Go》高达3亿玩家的需求,他们的基础设施不得不大规模扩展。在迁移至ElastiCache之前,他们在迁移开源缓存时也面临着类似的停机挑战。这次迁移是国际宝可梦公司进行的一项更大规模的托管服务迁移的一部分,他们在此发布了一份亚马逊云科技案例研究。

最后,这里我们想提供一些关于规划和运营ElastiCache迁移的其他资源链接和提示。

首先,在我们的网站上,您可以找到与今天所示内容类似的大量信息,包括操作指南和动手实验室。我们还包括了一篇最近发布的出色博客文章的链接,其中概述了为ElastiCache环境估算大小的最佳实践。鉴于我们对ElastiCache所做的增强,我们发现客户可以通过正确调整环境大小并利用服务的弹性,大幅节省内存工作负载的成本。

我们还包括了相关文档部分的链接,介绍了今天演示的备份和恢复方法以及在线迁移工具。这是我们准备本次演示时的主要参考资料,因此我们强烈建议您在执行自己的迁移时查阅这些材料。

我们还包括了一些方便的链接,指向上一张幻灯片中提到的客户参考资料,比如Tinder的《福布斯》文章、Airbnb的亚马逊云科技再:Invent Summit演讲、国际宝可梦公司的案例研究,以及其他一手ElastiCache客户体验。

最后,我们想特别指出,我们听到一些客户在利用一些开源工具辅助迁移方面有非常积极的体验。由于ElastiCache与开源Memcached和Redis兼容,客户可以利用其他开源工具来协助迁移。这些工具超出了本次演示的范围,但如果您在这方面有任何疑问,我们鼓励您与我们联系。

总之,我们再次衷心感谢您今天抽出时间。如果您对ElastiCache、Memcached、Redis或迁移至该服务有任何疑问,请随时与我们联系。我们期待与您合作。谢谢。

总结

将工作负载迁移至Amazon ElastiCache这一托管的内存数据存储服务,相比自行托管开源Redis和Memcached,可获得诸多优势。它消除了管理底层基础设施、软件版本、监控、备份和高可用性的运营开销,让团队可专注于创新和服务客户。ElastiCache通过诸如Global Data Store跨区域复制、动态在线重新分片实现零停机可扩展性,以及利用亚马逊云科技Nitro System和Graviton实例进行性能优化等功能,增强了开源引擎。

迁移过程包括将工作负载分类为临时或持久性、确定适当的部署拓扑(启用或禁用集群模式),并根据对停机时间的容忍度选择在线或离线迁移策略。备份和恢复方法涉及创建现有系统的快照、将其上传到S3,并使用该快照为新的ElastiCache集群提供种子。在线迁移工具可实现自托管Redis到ElastiCache的实时同步,同时保持数据集同步。

Tinder、Airbnb和Pokémon Company International等客户已成功迁移至ElastiCache,体验到了应用程序稳定性的提高、停机时间的减少和运营效率的提升。亚马逊云科技提供了广泛的文档、动手实验室和ElastiCache环境规模调整和运营的最佳实践指南,使客户能够优化性能和节省成本。

亚马逊云科技（Amazon Web Services）是全球云计算的开创者和引领者。提供200多类广泛而深入的云服务，服务全球245个国家和地区的数百万客户。亚马逊云科技致力于成为企业构建和应用生成式AI的首选，通过生成式AI技术栈，提供用于模型训练和推理的基础设施服务、构建生成式AI应用的大模型等工具、以及开箱即用的生成式AI应用。深耕本地、链接全球 – 在中国，亚马逊云科技通过安全、稳定、可信赖的云服务，助力中国企业加速数字化转型和创新，并深度参与全球化市场。