Figma 在不到 12 个月的时间里将其计算平台 从 AWS ECS 迁移到 Kubernetes（EKS），并做到了对客户影响最小。该公司决定采用 Kubernetes 来运行其容器化工作负载，主要是为了利用 CNCF 所支持的大型生态系统。此外，该举动也是为了节省成本、改善开发人员体验并提高弹性。
在 2023 年初，Figma 转向在容器内运行应用程序服务，并采用弹性容器服务（Elastic Container Service，ECS）作为其容器编排平台。使用 ECS 使公司能够快速推出容器化的工作负载，但从那时起，工程师们在使用 ECS 时遇到了某些局限性的问题，主要表现为缺乏对 StatefulSets、 Helm 图表的支持，或者无法轻松运行诸如 Temporal 之类 OSS 软件。
此外，该公司意识到，它错过了 CNCF 社区为 Kubernetes 提供的广泛功能，包括使用 Keda 或 Karpenter 的高级自动扩缩能力、使用 Istio/Envoy 的服务网格以及许多其他工具和功能。该组织还考虑了为满足其需求而定制 ECS 所需的大量工程工作，以及就业市场上是否有经验丰富的 Kubernetes 工程师。
Kubernetes 迁移时间表（来源：Figma 工程博客）
在决定切换到 Kubernetes（EKS）之后，团队就迁移的范围达成了一致，重点是尽量减少服务所需的更改，以避免延迟和风险。尽管限制了项目的范围，但该公司希望涵盖一些特定的改进，例如简化资源定义以改善开发人员体验，并通过将部署拆分为三个 Kubernetes 集群来提高可靠性，以避免缺陷和操作错误的影响。
Figma 的软件工程经理 Ian VonSeggern 讨论了迁移项目的成本优化目标：
在迁移过程中，我们不想处理太多复杂的成本效益工作，但有一个例外：我们决定从一开始就支持节点自动向外扩展。对于 EC2 上的 ECS 服务，我们只是过度配置了我们的服务，这样我们就有足够的机器能在部署过程中激增。但这个设置是昂贵的，所以我们决定将这个额外的成本优化范围添加到迁移中，因为我们能够以相对较少的工作量来节省大量的资金。我们使用开源 CNCF 项目 Karpenter 根据需求动态扩展和缩减节点。
为了确保项目取得成功，Figma 组建了一个人员配备齐全的团队来推动迁移工作，并与更广泛的组织接触以获得他们的支持。工程师们通过对 Kubernetes 设置进行负载测试以避免意外，使用加权 DNS 条目以实现增量切换机制，并在流程的早期将服务部署到临时 Kubernetes 集群中以解决任何问题，从而为生产部署做好准备。计算平台团队与服务所有者合作，提供了一条黄金之路，并确保了一致性和易维护性。
最初的迁移花了不到 12 个月的时间，在迁移完核心服务后，团队才开始考虑后续活动，比如引入基于 Keda 的自动扩缩能力。此外，根据用户反馈，工程师简化了开发人员工具，使其可以使用三个 Kubernetes 集群和新的细粒度 RBAC 角色。
Rafal Gancarz 是一位经验丰富的技术领导者和专家。他目前正在帮助星巴克打造具有可扩展性、弹性和成本效益的商务平台。此前，Rafal 曾为思科、埃森哲、凯德、ICE、Callsign 等公司设计和构建大规模、分布式和基于云的系统。他的兴趣涵盖了架构与设计、持续交付、可观测性和可操作性，以及软件交付的社会技术和组织方面。
原文链接：
https://www.infoq.com/news/2024/09/figma-ecs-kubernetes-eks/
声明：本文由 InfoQ 翻译，未经许可禁止转载。
剥离几百万行代码，复制核心算法去美国？TikTok 最新回应来了
C 语言老将从中作梗，Rust for Linux 项目内讧升级！核心维护者愤然离职：不受尊重、热情被消耗光
上6休3上3休2...AI大模型集体“翻车”，今年调休安排究竟有多烧脑？曝国产GPU独角兽全员被裁；阿里完成三年整改 | Q资讯
