--- title: "Yahoo! Japan 的母公司正在将 164 个 OpenStack 集群整合为一个" type: "News" locale: "zh-CN" url: "https://longbridge.com/zh-CN/news/281823738.md" description: "LY Corporation 是由 Yahoo! Japan 和 LINE 合并而成的公司，正在通过用一个名为 “Flava” 的统一系统替换其定制的 OpenStack 云来整合其云基础设施。这个新云将运行在一个拥有超过 9,000 个虚拟机和 500 个主机的单一 OpenStack 集群上，显著降低复杂性并改善升级能力。该公司旨在通过应用驱动的可用性和更快的恢复方法来增强可靠性。LY Corporation 还专注于自动化和可观察性，以管理硬件故障并在过去的数据泄露后改善安全性" datetime: "2026-04-07T03:25:44.000Z" locales: - [zh-CN](https://longbridge.com/zh-CN/news/281823738.md) - [en](https://longbridge.com/en/news/281823738.md) - [zh-HK](https://longbridge.com/zh-HK/news/281823738.md) --- # Yahoo! Japan 的母公司正在将 164 个 OpenStack 集群整合为一个 LY Corporation，这家在许多亚洲国家主导消息传递、电子商务和支付的日本网络巨头，已透露将用一种更常规的开源云堆栈替换其高度定制的 OpenStack 云，并在此过程中进行大规模整合。 LY Corp 成立于 2023 年，当时 Yahoo _!_ Japan 与韩国消息传递巨头 LINE 合并，LY Corp 正试图将其基础设施整合到一个名为 “Flava” 的新统一云中，以支持其服务。该云需要在显著规模上运行，因为其服务如 LINE 消息应用和 Yahoo 门户网站每月有约 3 亿用户。 上周晚些时候，该公司透露 LINE 的内部云 “Verda” 由 130,000 个虚拟机（VM）组成，分布在 11,000 个主机上，跨越四个 OpenStack 集群。Yahoo _!_ Japan 的 “YNW” 云运行在 27,000 台服务器上，超过 160 个 OpenStack 集群上运行着超过 160,000 个虚拟机。 该公司对新 “Flava” 云的计划要求 500 个或更多主机，9,000 多个虚拟机，以及一个单一的 OpenStack 集群。该公司还使用开源的 Envoy 代理、Linux 以及扩展的伯克利数据包过滤器（eBPF）和快速数据路径（XDP）、FRRouting（FRR）和 Ceph。 - Yahoo Japan 致力于实现通用的无密码认证 - 这是你最糟糕的噩梦：电子零售商在勒索软件攻击后只能在 45 天后恢复部分销售 - Yahoo _!_ Japan 在发现欺诈点击后将放弃 1.89 亿美元的广告收入 - 数据合规性不严导致日本政府停止使用 LINE 消息应用 “在传统云中，对 OpenStack 的过多自定义修改使得升级变得困难，” LY 云基础设施部门负责人井上龙太郎表示。“Flava 采用与上游 OpenStack 保持一致的架构。我们将自定义补丁保持在最低限度，当需要功能更改时，我们主动将其贡献给上游，以便合并到主项目中。” “通过消除升级障碍，我们能够实现定期更新，并持续保持安全性和最新功能的可用性，” 他补充道。 井上表示，LY 还旨在 “避免在基础设施层面过度投资于可用性保证”，而是假设故障始终是可能的。他表示，Flava 的设计试图通过以下三个 “支柱” 来覆盖这一点： - 追求无状态性 - 我们将存储在虚拟机（VM）根磁盘（临时磁盘）上的数据定义为临时数据。我们将持久数据移动到外部存储，以最小化实例故障时对服务的影响。 - 应用驱动的可用性 - 我们通过将基础设施与应用侧架构相结合，确保可靠性，而不是仅通过基础设施提供完美的可用性，从而减少不必要的基础设施复杂性。 - 更快的恢复 - 在事件发生时，优先考虑的不是恢复到完全相同的先前状态，而是保持服务运行。我们建议采用一种操作方法，快速重建环境，使用基础设施即代码（IaC），而不是首先花费大量时间进行根本原因分析。 该公司还非常重视可观察性。井上表示，他的团队使用 Prometheus、Grafana 和内部仪表板 “持续监控整体云健康和趋势，以捕捉异常的早期迹象。” 如果这些工具显示出问题的迹象，“我们会深入分析内核级跟踪和数据包捕获等深层信号，以确定原因。” 井上表示，LY 每天都会经历 “某处的硬件故障”，手动处理所有故障是不可能的。“今天，我们已经自动化了大部分流程，从故障检测到请求现场数据中心工作，再到将更换的硬件重新整合回集群，” 他写道。“也就是说，一些任务和不规则的故障模式仍然需要人工工程响应。展望未来，我们还计划在这些决策密集型工作流程中使用大型语言模型，进一步推进自动化。” LY 需要这一切正常运作，因为它曾面临严重的信息安全问题，暴露了用户数据，导致日本政府下令对其技术栈进行改进，以提高安全性和隐私。® ### 相关股票 - [4689.JP](https://longbridge.com/zh-CN/quote/4689.JP.md) ## 相关资讯与研究 - [中国银河证券：具身智能行业具备强阿尔法属性 主机&关键零部件环节看龙头](https://longbridge.com/zh-CN/news/289261590.md) - [欧盟通过铁路运力管理新规 助力跨境铁路运输与单一市场效率提升](https://longbridge.com/zh-CN/news/289304863.md) - [新股消息 | 米多多再次递表港交所 开发及提供综合技术驱动营销、销售及运营支持服务](https://longbridge.com/zh-CN/news/289662120.md) - [Anthropic 最新博客：生物学 Agent 的瓶颈不在模型，而在数据基础设施](https://longbridge.com/zh-CN/news/289140007.md) - [导致 Spark on Kubernetes 发生 OOM 故障的两个配置错误](https://longbridge.com/zh-CN/news/289169935.md)