你好！
我团队实验室我是一名初出茅庐的工程师，2022 年应届毕业生加入。
这一次，我去AWS进行了外部培训，作为打包团队新毕业工程师培训的一部分！
这一次，我想写下培训的大纲和在那里的作业中创建的可交付成果。
什么是 AWS JumpStart for NewGrads
这是针对刚毕业的第一年工程师的为期 3 天的实践培训计划。
既然是以创造内容的概念来规划，让您顺利迈出成为未来AWS使用引领者的第一步，所以不仅仅是学习AWS服务的问题；内容重点关于考虑和设计适当架构的经验。
AWS 日本今年的活动是在网上举行的，但它变成了一场大型活动，有超过250名一年级应届毕业生工程师，包括来自网络和游戏公司的工程师。
培训大纲
培训内容包括AWS服务和架构设计讲解、小组作业、实操演练，按照以下日程安排进行。
第一天 第二天 第三天 早晨 AWS 服务介绍和架构课程 团队合作 团队合作 下午 团队合作
动手练习团队合作
动手练习结果展示 对于小组工作，我们被分成 4 到 5 人一组来检查给定问题的架构，并展示了我们在培训的最后一天创建的架构。
在动手练习中，我们使用 EC2 构建了一个可扩展的网站，构建了一个无服务器 API，等等。在这篇文章中，来自teamLab的新毕业工程师中① 歌舞伎,②荒川,③ 斋藤,④ 由纪我们将介绍我们四个人通过小组合作创建的每个小组的成果！
小组作业内容
在这个程序中，我们被要求在 [创建大规模聊天服务] 的假设下检查使用 AWS 服务的架构设计。作业中设置了聊天、数据流、基本功能等详细要求，但由于说这些要求不会公开，所以本文省略说明。希望大家能够对我们四个人的解释有所了解！
① 卡布拉木集团
首先介绍一下Kaburagi小组创建的架构！
前提
我小组中的大多数成员都没有在 AWS 上构建基础设施的经验，所以我们开始吧！甚至当任务开始时，它也是一个扑克状态。因此，我决定暂时为使用服务器的 Web 服务创建一个最低的基础设施配置，并且每次都添加必要的 AWS 服务以满足需求。
因此，我们首先考虑了聊天服务的用户故事，并将其融入到实际的屏幕转换中。
此外，本次挑战赛有各种要求，但我们将以下两个要求解释如下。
- 邮票功能→支付功能（因为图片/视频发布功能的要求是单独设置的）
- 服务区域→多区域配置（因为计划在两个国家之间提供）
此外，我们决定根据聊天服务处理的数据类型（朋友、群组、消息等）使用不同的数据库。
人工制品
此外，这里是经过详细试验和错误在 3 天内创建的架构！
其中有两个region（蓝框），两个AZ（红框），从ELB到服务器……整体来看，流量从图中最上方的用户通过路由53分布到各个region已经成为可以考虑的基本的极限配置。
建筑评论
在这里，我将在本地解释内部配置。
首先，认证功能对于服务内的账户管理是必不可少的！所以我把 Cognito 用于身份验证。如前所述，我们认为邮票的要求是添加支付功能，并且认为获取和保留用户信用卡信息会是一个沉重的负担，所以我们决定使用一个名为 Stripe 的外部支付服务。我决定至。
本来是从route 53到ELB再到EC2的流程，但是为了最后实时聊天，是否需要每秒发送Get请求获取新消息……？变成了一个故事，一个API网关也安装的很匆忙。
然后，本地图左下角ELB分发的EC2进行聊天服务的各种处理。接下来是围绕数据库的配置。
小组工作从找出可用的 DB（服务）的种类开始，目的是根据目的使用不同的 DB，但最后是这样安排的。对于服务的主要功能，聊天，设置了聊天流的要求。因此，为了处理它，我们设置了在DynamoDB中保存消息的配置，中间有DAX（DynamoDB Accelerator），并部署了Elasticsearch（OpenSearch）来实现保存消息的搜索功能。我们还为帐户和组管理功能部署了 Neptune。 Neptune 是一个完全托管的图形数据库服务，我们认为它最适合管理网络类型的数据，例如在聊天服务中可能重叠的朋友和群组，这也是本项目的目的。最后，我还放置了创建副本的 Aurora，并像 Neptune 一样放置在数据库集群中。 Aurora 的目的是存储服务所需的其他数据，例如邮票购买信息，这些数据不是由上述两种类型的 DB 处理的。
以上就是Kaburagi集团架构图的解释！
改进
如前所述，我们安装了一个API网关，可以使用WebSocket API实现实时聊天功能。我想过用这个服务实现实时双向通信，但我认为首先使用这个时无服务器配置更合适，因为不需要像EC2这样的服务器布置配置。另外，除非您需要，否则不要将其放在公共子网中！考虑到这一点，我们将所有服务器和数据库放在私有子网中，但如果我们有更多时间，我认为考虑安装 AWS WAF 等服务以采取安全措施可能是个好主意。。最后，这次我们考虑了实现满足要求的功能所需要的服务，并将它们纳入到这个架构中，似乎还有考虑的余地……！
②荒川集团
接下来介绍荒川组的架构！
前提
我们的小组继续制定一个融合当前无服务器趋势的架构的策略。
但是，包括我自己在内的所有小组成员都从未接触过无服务器 AWS 服务，因此我们度过了一段非常艰难的时期。
尽管如此，我选择 serverless 的原因是它现在是一种趋势，但它是一个学习机会，所以我不知道，但它似乎很有用。
这样做时，我假设 AppSync 和 Lambda 的配额限制会提高，并且永远不会发生此问题。人工制品
经过反复试验，这里是基于 serverless 配置的架构。
总体看法
建筑评论
无服务器和整体简单的配置。
我在这里给大家做一个更详细的介绍。页面交付是通过使用 S3 和 Amplify 交付 React 同步页面来实现的。 SNS应用读取信息的通知也是通过这个Amplify Subscription实现的。我们计划通过 AWS WAF 加强安全性。
对于用户身份验证，我们决定使用 Cognito 的外部提供程序。
这是因为它比存储密码等高度机密的信息更安全，并且与高度可靠的外部提供者捆绑更安全。我认为最好使用 Cognito。图像的上半部分是发布的数据流。
发布的数据首先存储在 DynamoDB 中。要保存的内容是
·信息
・图像、视频和图章的 URL
・阅读信息
有三种。
搜索功能是通过使用 Lambda 将存储在 Dynamo DB 中的数据传输到 Open Search 来实现的。
顺便说一下，这个 Open Search 计划是多可用区配置。图片的下半部分是用户数据流。
假设将其存储在 Dynamo DB 中一次，然后使用 Lambda 将其传输到 Aurora。
我想使用 Aurora 的原因是因为我认为使用像 Aurora 这样的 RDBMS 来获取朋友信息会很方便。
不过 Aurora 的文笔不是那么强，所以我决定先在 Dynamo DB 中存储一次，然后发送给 Lambda。
我们计划使用 Lambda 来实现搜索功能。改进
这次我说 AppSync 和 Lambda 配额限制不是问题，但我认为这是需要考虑的一点。相当困难，但是
要考虑的另一点是系统监控注意事项。以目前的架构，维护成本很低，所以我认为监控设置是必不可少的。我认为您必须考虑使用什么。
最后，我们还必须考虑成本方面的考虑。由于是 serverless 配置，所以成本很难计算，很多事情要真正运行才能确定。未来可能也需要考虑这一点。③ 齐藤集团
接下来，介绍一下斋藤参与的小组创作的成果！
前提
虽然我们小组对我们在工作中接触到的 AWS 服务有一些了解，
他们没有设计整体架构或选择正确 AWS 服务的经验。因此，在参照上机内容创建了满足要求的最低配置架构后，
我们通过复习我们想要添加的架构和功能的问题来继续研究。*供参考，下面是我第一天想到的最低配置的架构图！
此外，设想必要的要求和该聊天服务的开发团队所处的情况，该小组独立地添加了以下假设。
- 应该能够在多个国家的用户之间聊天
- 开发人员很少！
- 由于任务是“在3天内完成架构”，所以我设置了一定的约束，开发资源会很小。
在↑的前提下，在我们群里，
"即使开发人员数量很少，也能确保高可靠性、可扩展性和性能的设计"
我们决定积极使用 AWS 托管服务。人工制品
经过3天的群策群力，最终的架构图如下！
*从一开始就反复刷刷，成为第7代架构计数。
总的来说，除了一些全球共享的资源服务
通过在每个区域中复制相同的服务来实现多区域配置。
因此，它旨在满足“必须能够在多个国家/地区的用户之间聊天”的假设。以单一区域为重点，按功能大致可分为三层结构。
姓名 AWS 服务 分布/磅 CloudFront、ELB (ALB)、S3、Lambda@Edge、WAF 容器 ECS（Fargate + Auto Scaling） 数据库 DynamoDB、RDS 极光 在分发/LB层接收访问，
在容器层处理聊天服务，在DB层存储数据，
静态内容按原样从交付/LB 层交付，请求以这样的流程处理！
建筑评论
让我们仔细看看我们在架构学习过程中特别关注的部分。
1.根据数据的性质分离存储目的地
与聊天服务聊天时，不仅聊天消息，
必须可以存储和访问帐户组信息和读取管理等数据。
特别是，由于聊天消息的数量巨大，因此需要在性能和价格方面考虑合适的服务。
因此，我想通过“根据数据的性质划分存储目的地”来解决这些问题。对于聊天消息，AWS 的 NoSQL 服务“动态数据库我决定使用 .
决定性因素包括无限容量和完全托管的服务。
具体要求我就不说了，但是由于它在多个国家使用，并且由于聊天的性质，交换了大量的称为消息的相对较小的文本数据，
我认为无限容量几乎是必不可少的。对于帐户、组和读取管理，它是一个关系数据库“RDS 极光”被使用。
我们采用的策略是在保留关系的部分之前不使用 DynamoDB，而是将其留给 RDBMS。假设开发资源有限，我们没有努力使用 DynamoDB，而是采用了经过广泛验证的 RDB，
我们选择 Aurora 是因为它是 AWS 推荐的，而且我们使用下面描述的全局数据库功能。
（在群里，从建立关系和搜索的角度，我们也认为RDB更好。）作为一个症结所在，可以减少 DB 上的负载吗？在RDS和ECS之间思考ElastiCache这是包含 .
（后来查的时候，据说这样的情况，命中率低，效果很难出现。）2.多区域聊天数据共享
多地域配置，实现多国用户间聊天，
问题是如何共享聊天数据。我通过使用 AWS 提供的功能解决了这个问题。
下面我简单介绍一下！
- DynamoDB 全局表
- “完全托管的多区域、多活动全局数据库”
- 无需在区域之间复制数据即可解决更新冲突！
- RDS Aurora 全球数据库
- “跨多个 AWS 区域运行单个 Amazon Aurora 数据库”
- "在任何区域以亚秒级访问数据"
3.聊天消息搜索功能的实现
搜索存储在 DynamoDB 中的聊天消息并不简单。
正如预期的那样，不可能获取所有聊天消息，所以我们考虑了如何做到这一点。因此，亚马逊开放搜索服务决定使用DynamoDB 流通过使用 ，当 DynamoDB 数据发生变化时 Lambda 将启动，DynamoDB 中的消息数据将与 Lambda 内的 OpenSearch 同步。
通过这样做，我们认为可以实现消息自动反映到 OpenSearch 和 OpenSearch 的聊天搜索功能。改进
在此架构审查中，我们假设开发资源很少，并且旨在广泛使用托管服务。
考虑到实际操作，成本会增加，因此有必要想办法降低成本。另外，我假设消息交换将由 WebSocket 完成，我正在考虑使用 ECS 容器处理所有内容，但有些部分我无法弄清楚具体如何做。
回想起来，我认为如果我们准备一个单独的端点进行处理并采用 AWS AppSync，该架构可能会更加可靠和高性能。我认为有些监控和备份部分需要更深入的考虑。由于时间限制，我最终放置了 CloudWatch 和 AWS Backup 图标，
我认为有必要弄清楚要监控哪些项目以及如何备份它们。④ Yukki 集团
你好！ ！是优姬！ ！在本章中，我们将介绍我们小组的假设以及基于它们提出的架构！
前提
在我们的小组中，我们在考虑确保忠实于给定参数的高可用性的同时考虑了架构。下面显示了我实际上是如何考虑哪个参数的。
聊天流
似乎拥有与L○NE相同的流量。除非我们不仅准备好每秒连接数和配额，而且准备好合理大小的 DB，否则我们似乎无法处理它。
数据流
我们知道有很多，但我们不知道如何处理它。
消息保留期
我想有两种思路：“一定能存一定期限”和“一定期限后不需要存”。我不知道管理层的意图，但我们决定继续执行后一项政策。
高峰时段
据说访问集中在特定时间。能够随时间自动缩放作为触发器会很好。
服务区
与多个国家打交道似乎并不容易。对于可以依赖托管服务来简化实施的部分，我想依赖托管服务。
前端交付平台
考虑到最近Next.js（Nuxt.js）的火爆，看来这个开发也会选在这里。因此，除了简单的静态页面托管之外，可能还需要计算资源。
聊天功能，阅读管理，戳记
我们不能在 UX 中输给其他应用程序，因此似乎有必要支持实时更新。考虑通过服务器，似乎会使用WebSocket。
帐户管理
我想安全地和管理地实现它，所以我想使用现有的身份验证基础设施而不是自己实现它。
元信息管理
这次我们需要使它成为多区域，所以如果有一个数据库可以以托管方式实现该部分，我会很高兴。另外，由于元信息预计会被各种查询搜索，我想从 RDB 中选择一个 DB。
图像/视频分发
假设分发使用存储和 CDN，那么上传呢？我想统一显示的缩略图，如果我可以在分配存储之前创建缩略图，我会很高兴。
通知
我认为它可能会实现，但如果它很容易，我想享受它。如果是AWS，感觉SNS可以用。
聊天搜索
我可以自己实现它，但是由于这次的要求不包括金钱，我想使用一个高性能的服务来管理它！
人工制品
总体看法
经过3天的反复调整，同时听取了SA的建议，这就是最终的架构！
元信息API在ECS×Fargate容器中实现，聊天API在以AppSync为主的serverless中实现。更多关于下面的内容。
建筑评论元信息 API
让我们仔细看看元信息 API 的结构！
我们使用 Fargate 进行计算，使用 ALB 进行负载均衡，使用 Amazon Aurora Global Database 进行 DB。改进的点如下。
- 支持多可用区配置的 DR
- 通过使用只读副本 ElastiCache 缓存查询内容来减少对数据库的访问负载
- 通过使用 RDS 代理，来自 Fargate 的连接数增加，并且避免了数据库上的负载。
聊天 API
让我们仔细看看聊天 API！
基于带有 AppSync 的 GraphQL，我们使用 DynamoDB 全局表来存储 DB 和 S3 来存储图像。 AppSync 还支持 WebSockets，支持托管实时通信。此外，DynamoDB Streams 由聊天写入 DynamoDB 触发，写入 OpenSearch 是通过 Lambda 执行的。 OpenSearch 用于聊天搜索功能。
改进的点如下。
- 为了处理大量访问，请增加 AppSync 配额。
- 我在 AppSync 和 S3 之间有一个 Lambda，用于为上传的图像创建缩略图。此外，由于图像处理是繁重的处理，因此由 SQS 进行排队以进行负载分配。
改进
我觉得围绕价格还有讨论的余地。尤其是RDS Proxy很贵，所以我觉得在真的有必要之后再考虑引入还是不错的。
还有，这次按照我们集团的政策，我们把服务限制在AWS上，但是实际实施的时候，我觉得还是用其他公司的服务，调整一下成本和实施的难易度就好了。我是。想法
这是为期三天的培训，时间紧迫，但我能够从头开始设计服务，这是新毕业的工程师无法做到的！此外，来自不同公司的许多参与者的小组工作和演讲提供了与同代工程师交流的良好机会。此外，您可以看到每个组的各种架构，如您在本文中所见，常见要求即使各种解决方案我能够意识到有！
最后，这是一个让我学到很多东西的活动，但从现在开始，我想在我的工作中利用这次经验来进一步改进teamLab的解决方案！
原创声明：本文系作者授权爱码网发表，未经许可，不得转载;
原文地址：https://www.likecs.com/show-308629607.html