AWS部署WordPress高I/O性能及冗余架构优化方案咨询

无架构改动的轻量化优化方案 #

这一类方案不需要调整现有部署结构，改动成本最低，优先尝试：

• 调整EFS本身配置：如果当前用的是通用目的性能模式，切换为最大I/O性能模式，高并发文件操作场景下性能提升幅度可达50%以上；吞吐量模式根据站点日常流量从突增型调整为预置吞吐量或弹性吞吐量，避免流量尖峰时被AWS限流导致I/O卡顿。
• 优化EFS挂载参数：修改/etc/fstab里的EFS挂载配置，新增参数tls,relatime,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2，关闭不必要的文件属性更新、调大读写缓冲区，小文件随机读写性能可提升30%左右。
• 静态资源卸载：使用WordPress静态资源同步插件，将wp-content/uploads目录下的图片、附件，以及主题、插件里的静态CSS/JS/字体文件全部自动同步到S3，访问路径直接指向S3或CDN地址，完全消除静态资源访问对EFS的读压力。

低改动成本的缓存叠加方案 #

针对WordPress读多写少的业务特性，加缓存层可以消除绝大多数EFS I/O请求：

• 新增EFS本地读缓存：每台EC2挂载一块小容量gp3类型EBS盘，部署FS-Cache模块配合EFS挂载，将高频访问的热文件缓存到本地EBS，热读请求完全不需要走EFS的网络I/O，实测缓存命中率可达90%以上，全程不需要修改站点代码。
• 拉满应用层缓存：EC2内部署Redis作为对象缓存，安装对应WordPress插件将数据库查询结果、页面片段等缓存到Redis中；同时安装静态页缓存插件，将生成的静态页面直接存储在本地EBS盘，绝大多数用户访问请求不会触发EFS读写。

架构调整的终极解决方案 #

如果要彻底解决共享存储性能问题，你担心的EBS落地问题已有成熟的低改动方案：

• 采用EBS多挂载方案：不需要每台EC2绑定独立EBS，改用io2/io2 Block Express类型EBS卷，开启多挂载功能，单个卷最多可挂载到16台同可用区的EC2实例，直接作为共享存储存储WordPress全站代码，顺序读写性能是通用型EFS的4倍以上，随机读写延迟低一个数量级，userdata里仅需添加一行挂载命令即可，不需要修改站点任何业务代码。
• 更换更高性能的共享存储：将EFS替换为FSx for OpenZFS，通过NFS协议挂载到EC2，其小文件读写性能是标准EFS的3~5倍，延迟更低，挂载方式和EFS完全一致，仅需修改挂载地址即可完成切换，适配现有部署逻辑。

内容的提问来源于stack exchange，提问作者Aurond Van Helder