在技术选型时,我们往往会仔细考量各项成本,尤其关注实现成本,这种“斤斤计较”其实能带来直接的经济效益。那么,你是否有系统地思考过如何计算这些成本呢?本节课将通过一个日志中心的例子,带领你逐步进行成本计算。
之所以选择日志中心,主要有两点考虑:
根据流量推算存储容量及投入成本
在互联网服务中,最大的变量就是用户流量。相比普通服务,高并发系统需要同时处理更多的在线用户,因此在设计这类系统的容量时,需要根据用户请求量和同时在线人数来推算系统硬件投入的成本。
很多系统在初期会采用云服务来构建日志中心。然而当核心接口流量超过10万 QPS后,许多公司就会考虑自建机房,甚至后期会持续改进日志中心,开发一些个性化的服务。实际上,这些优化和实现的核心目的都与成本息息相关。为了让这个概念更加直观,我们来通过一个实际例子,计算一个高并发网站的日志中心所需的存储容量和成本。
假设一个高并发网站在流量高峰期,其核心 API 的 QPS 约为 30 万,我们按每天 8 小时计算,并假设每次核心接口请求会产生 1KB 的日志。由此可以计算出该网站每天的请求量和日志数据量:
你可能会疑惑,为什么这里按每天 8 小时计算?这是因为大多数网站的用户访问量都有一定规律性,有些网站流量集中在上下班时间和夜晚,有些则在工作时间。结合一般用户的日常习惯和每天约8小时的专注时间,按8小时计算会相对合理。当然这个时间只是一个参考,不同业务的访问高峰可能不同,实际情况可以根据网站用户习惯进行调整。
回到刚才的计算,我们看到,如果每次请求产生 1KB 的日志,每天将会有约 8.6TB 的日志数据需要处理、传输、整理、计算和存储。
为了方便问题追溯,我们还需设定日志的保存周期。假设日志保留30天,那么一个月的日志量将达到:
8.6TB X 30 天 = 258 TB /30 天
通过以上计算可以看出,一个高并发网站的日志存储需求十分庞大。这种分析思路不仅适用于日志中心,还可以作为其他组件容量与成本计算的参考。
从容量算硬盘的投入
在计算出日志量后,我们就可以进一步估算购买硬件所需的成本。不过需要提前说明的是,硬件价格是动态变化的,且不同商家的定价会有所差异,因此具体成本可能会有差异。这次我们主要关注计算思路,学会后你可以根据实际情况来调整。
目前,常见的服务器硬盘规格为8TB、7200转、3.5寸,单价约为2300元。考虑到实际可用容量,8TB硬盘的实际可用存储空间约为7.3TB。结合之前的每月日志量,可以计算出所需的硬盘数量,计算公式如下:
258 TB/7.3 TB = 35.34 块
由于硬盘数量必须是整数,所以需要36块硬盘。然后将数量与单价相乘,就得出硬件的总成本:
2300 元 X 36 = 82800 元
为了确保数据安全并增强查询性能,我们通常会使用分布式存储,将数据存储三份。这样一来,在分布式存储方案下,至少需要108块硬盘。此时的投入成本为:
82800 X 3 个数据副本 = 24.8W 元
如果还要保证数据的可用性,我们可以选择 RAID 5 阵列。RAID 5 会将多个硬盘组成一个阵列,其中部分硬盘提供完整存储容量,另外一部分硬盘则用于校验和冗余。虽然具体的 RAID 配比有多种方案,但为了简化计算,我们选择以下配置:每四块硬盘组成一组,其中三块提供完整容量,一块用于校验。
在 RAID 5 模式下,容量计算公式为:
单组 raid5 容量 =((n-1)/n) * 总磁盘容量,其中 n 为硬盘数
其中n n 为硬盘数量。将4块硬盘代入公式:
108 / 3 = 36 块校验盘
这表明,一组RAID 5由四块硬盘组成,其中三块提供完整的存储容量。由此可以计算出,为了满足存储需求,我们需要在108块硬盘的基础上增加四分之一的容量来存放校验数据,即:
108 / 3 = 36 块校验盘
因此,最终需要的硬盘数量为:
最终需要的硬盘数量就是 108 块 + 36 块 Raid5 校验硬盘 = 144 块硬盘,每块硬盘 2300 元,总成本是:
每块硬盘的价格为2300元,因此总成本为:
144 X 2300 元 = 331200 元
为了方便计算,我们可以取整按33万元来计算。
除了确保可用性外,还需考虑硬盘的寿命。由于硬盘是易损设备,一般在连续工作两到三年后会陆续出现损坏情况。为应对硬盘损坏和补货缓慢等问题,通常会预备大约总数三分之一的硬盘作为备件。也就是说,需常备40块硬盘用于故障替换,维护成本约为:
2300 元 X 40 = 92000 元
综上,至少需投入的硬件成本为一次性硬盘采购费用加上维护费用,即:
33+9.2=42万元
根据硬盘推算服务器投入
接下来,我们需要计算服务器的相关成本。服务器有多种规格,不同规格可以插入的硬盘数量也不同,具体如下:
在上一步中,我们已经计算出做 RAID 5 的情况下需要 144 块硬盘。若采用 2U 服务器,则需要的服务器数量为:
144块硬盘12块/台=12台服务器
假设每台服务器的费用为 3 万元,那么服务器的硬件成本为:
12 台服务器 X 3W = 36W 元
补充说明:为了提高可用性,通常将相同数据的副本分散在不同的机柜和交换机上部署。这种方式可以在机柜或网络设备出现故障时,依然保证数据的高可用性。
根据服务器托管推算维护费用
除了购买服务器,还需要考虑维护费用。将 2U 服务器托管在优质机房内,每台服务器的年托管费用约为 1 万元。前面计算得出,我们需要 12 台服务器,那么一年的托管费用为:
12台×1万元=12万元
接着,我们来计算第一年的总投入,包括硬盘采购与维护、服务器硬件成本、托管费用,以及带宽费用。具体计算如下:
第一年投入费用=42万(硬盘新购与备用)+36万(服务器一次性投入)+12万(服务器托管费)+10万(宽带费用)=100万元
后续每年维护费用包括硬盘替换(假设备用盘用完)、服务器托管费以及带宽费用,计算如下:
9.2万(备用硬盘)+12万(托管费)+10万(带宽费)=31.2万元
基于第一年投入和后续维护费用,我们可以计算三年内运转 30 万 QPS 核心服务所需的成本,具体如下:
31.2万元×2年=62.4万元+第一年投入100万元=162.4万元
当然,这里未包含大客户的硬件采购折扣、冗余容量、网络设备、适配卡等费用以及人力成本。但即便忽略这些,当你看到这样的成本支出,再想想某些场景中用 2000 台服务器来运行 ELK,相信你会深刻体会到,多写一行日志的成本究竟有多高。
服务器采购冗余
接下来,我们谈谈采购服务器时保留冗余的问题。如果没有亲身经历过,可能会容易忽略这一点。
对于核心机房的托管,服务器的采购和安装周期需要特别关注。很多核心机房往往缺乏空余的机柜位,因此,为了满足未来几年的业务增长需求,许多公司会提前多采购一些备用服务器。曾有公司按照评估结果的四倍来备货,不过不同企业的业务增长速度不同,冗余比例并没有统一标准。就我个人而言,习惯根据当前流量增长趋势,预估未来三年的服务器需求量来进行采购。
因此,回头看我们之前计算的服务器成本,实际上只是基于现有需求而已,只能算是“刚好够用”。实际操作中,做成本估算时一定要将冗余考虑在内,以免因资源不足影响业务发展。
如何节省存储成本?
一般来说,业务都有成长期,当我们业务处于飞速发展、快速迭代的阶段,推荐前期多投入硬件来支撑业务。当我们的业务形态和市场稳定后,就要开始琢磨如何在保障服务的前提下降低成本的问题。
临时应对流量方案
如果在服务器采购时没有留出冗余,而服务流量增长了,我们可以采取一些临时措施来缓解压力。可以从节省服务器存储空间和减少日志量这两个方面着手,例如:
以上这些措施能够在短期内缓解存储压力,作为应急之策。但是在控制成本时,建议不要牺牲业务服务,尤其是核心业务的稳定性。接下来,我们可以探讨一种特殊情况。
如果业务高峰期的流量激增,远超过 30W QPS,就有更多流量瞬间请求尖峰,或者出现大量故障的情况。这时甚至没有报错服务的日志中心也会被影响,开始出现异常。高峰期日志会延迟半小时,甚至是一天,最终后果就是系统报警不及时,即便排查问题,也查不到实时故障情况,这会严重影响日志中心的运转。出现上述情况,是因为日志中心普遍采用共享的多租户方式,隔离性很差。这时候个别系统的日志会疯狂报错,占用所有日志中心的资源。为了规避这种风险,一些核心服务通常会独立使用一套日志服务,和周边业务分离开,保证对核心服务的及时监控。
高并发写的存储冷热分离
为了节省成本,还可以从硬件方面入手。如果我们的服务有明显的高峰期,但平时流量并不大,采购过多服务器可能会造成资源浪费。这时可以通过采购高性能硬件来支撑高峰期流量,达到更节约的效果。
例如,单个磁盘的写性能约为 200MB/s,在 RAID 5 环境下,单盘性能减半,约为 100MB/s。假设一台服务器能装 9 块硬盘,则总写性能为:
100MB/s×9块硬盘=900MB/s
这样的磁盘吞吐量可以满足实时写入、少量读取的日志中心需求,但应对极端高峰时可能还需额外优化。为此,我们可以考虑冷热分离策略:在写入需求激增时,用 SSD 来处理高并发写入,而将冷数据存储在普通硬盘上。
假设每天产生 8TB 新日志,每个副本分布在 4 台服务器上,则每台服务器需承担 2TB 的每日存储需求。按 1TB SSD 的实际容量为 960GB,M.2 接口 SSD 单价约 1800 元、顺序写入性能在 3-5GB/s,则每台服务器需配备两块 SSD,总计 24 块 1TB SSD,计算如下:
1800元×12台服务器×2块SSD=43200元
此外,SSD 需要定期更换,其寿命约为三年,年维护费用为:
1800元×8块=14元
补充知识:SSD 不仅能提升写入性能,还能提升读取性能,并且一些分布式检索系统支持自动冷热迁移功能,使高频数据更快速响应,而冷数据则存储在更节省成本的硬盘中。
需要多少网卡更合算
通过增加 SSD 和冷热数据分离,确实可以有效缓解业务高峰时日志写入的压力。然而,即便服务器磁盘能够承受住流量压力,网络瓶颈也会随之显现。
通常情况下,内网速度不会太低,但一些小型自建机房可能配备万兆交换机而服务器仅支持千兆网卡。理论上,千兆网卡的传输速度为:
1000Mbps/8=125MB/s
实际传输速度却往往达不到这个理论值,大致在 100 MB/s 左右。当我们在内网中进行大数据文件的传输时,千兆网卡的带宽会很容易被占满。
过去,为了提高网络吞吐量,常用的方法是多网卡接入交换机并在服务器上进行 Bond 处理。随着光纤网卡的普及,万兆光口网卡成为主流,其理论传输速度为:
10000Mbps/8=1250MB/s
而实际速度大概能达到 900 MB/s(即 7200 Mbps)左右。
再回到我们之前计算的日志高峰数据吞吐量:
300,000QPS×1KB=292.96MB/s
对于千兆网卡来说,100 MB/s 的带宽速度在四台服务器分摊下勉强够用。但在更高流量的高峰期,这一带宽仍显不足,因此需要升级为万兆网卡。值得注意的是,万兆网卡还需配合性能更高的三层交换机才能完全发挥作用。近年来,万兆交换机已普及,通常包含在基础设施成本中,这里不再单独计算交换机的投入成本。
在之前的硬件成本计算中,我们提到每组服务器需要存储三个副本,因此配置三块万兆光口网卡是足够的。然而,为了确保系统的稳定性,我们不会将网卡的带宽使用率保持在满负荷状态,最佳的传输速度应保持在 300 到 500 MB/s 之间,以便预留出额外的带宽供其他服务使用或应对突发情况。
对于 12 台服务器来说,它们分为 3 组副本(每组 4 台服务器,每个副本存储一份完整数据)。在这种配置下,每台服务器的日常网络吞吐量可以计算为:
292.96MB/s (高峰期日志数据吞吐量)/4台服务器=73MB/s
在使用万兆网卡的情况下,这样的吞吐量仅占总带宽的十分之一,完全能满足日常的日志传输需求。如果使用千兆网卡,情况就不一样了。
尽管千兆网卡的理论速度为 100 MB/s,计算得出的 73 MB/s 吞吐流量似乎可以在其容量范围内,但这样做是不够的。这是因为我们在估算容量时必须留有弹性。使用千兆网卡时,实际负载接近满载,一旦出现流量波动,就可能导致网络拥堵,从而严重影响系统的稳定性。
此外,日志中心的功能不仅仅是满足基础的业务需求,它还需要承担问题排查和数据挖掘分析的任务。如果仅仅为了基础服务而建设一个如此昂贵的日志中心,确实是得不偿失的。因此,在选择网络硬件时,确保充足的带宽和冗余设计是至关重要的。
本网站的文章部分内容可能来源于网络和网友发布,仅供大家学习与参考,如有侵权,请联系站长进行删除处理,不代表本网站立场,转载者并注明出处:https://www.jmbhsh.com/zixun/34762.html