Menu

客户案例-江苏未迟数字技术有限公司

1. 项目介绍

1. 项目公司

江苏未迟数字技术有限公司成立于2016年3月9号，是一家江苏南京的互联网广告公司，作为Google的核心合作伙伴，利用Google AdWords强大的数字平台，以及“技术+创新”的营销概念为企业提供跨境数字营销服务。 江苏未迟数字技术有限公司为跨境出口企业提供一站式整合营销及电商运营解决方案。整合全球网络优势资源，融合海内外优秀人才，通过数据驱动、技术赋能、创意引领来推动中国品牌国际化，实现海外销量有效增长。始终用数据和效果说话, 秉承”客户第一，体验为王”的服务宗旨和“产品驱动服务，服务优化产品”的经营理念，旨在让世界任何一个角落的企业都可以把产品卖向全球。 江苏未迟汇集整合了Google、Bing、Yandex、Facebook、Linkedln、Tiktok等海外主流媒介平台资源，是一家集AdWeb建站、AdVich整合营销、Wedigital数据平台于一体的全网数字营销服务品牌。 作为中国江苏省Google一级代理商，为众多客户提供了高质量的广告推广服务，包括广告精准投放、广告优化等Google广告优质服务，背后有专业的广告投放、优化团队对客户7*24小时的支持与帮助。 为了满足以客户为中心的商业模式转型，江苏未迟将利用先进且完善的公有云IY技术提升客户应用交互体验的一体化整合，为公司及客户创造最大的价值。
此次项目与江苏未迟数字技术有限公司进行深度合作，提供专业的AWS Cloud Solutions(云解决方案)及Technical Support(技术支持)，为客户解决现阶段需求及历史遗留问题。

2. 项目背景

未迟在AWS上运行着大量的Windows EC2实例，用于运营系统的部署。用户可通过远程连接方式直接登录Windows系统进行作业，灵活自由的操作模式，使得用户获得了很好的良性增长，但随着用户的增长，Windows EC2远程连接的异常问题及性能不稳定导致了用户的流失问题开始出现。未迟希望能够在最短的时间内找到有效的解决方案彻底解决上述的问题，从而赢得用户的信任和支持。

3. 项目目标

对现阶段客户运营系统架构进行系统性分析，并设计出AWS架构解决方案，可自动化的实现性能扩展，不再需要人为的手动修改控制，为客户彻底解决远程连接不稳定及EC2实例性能问题。
实现自动化管理及安全更新，减少研发人员在底层及环境上的时间，将更多的时间用于应用层面上，提高研发生产力。

2. 项目解决方案

1. AWS架构图

架构中使用Amazon RDS for SQL Server, Amazon Systems Manager, Amazon Elastic Beanstalk三种云原生服务作为核心服务使用。
  1. 微软 IIS
Microsoft IIS作为Windows Server中最稳定的Web Server，在客户案例中为运营系统网站提供运行环境。为用户提供可访问的网站前端及数据交互。
  1. 微软 SQL 服务器
Microsoft SQL Server作为运营系统最重要的核心组件存在，目的为存储Advich运营系统后端处理的大量结构化数据，为这些数据提供一个稳定安全，读写高效的存储数据库。
  1. 微软活动目录
Microsoft Active Directory在本案例中作用于安全模块，为Windows Server操作系统提供身份验证和权限管制功能，通过创建用户与组，分配相应权限和windows资源，达到安全的身份验证和授权流程。
  1. EC2 Windows 服务器
部署Amazon EC2并使用Windows Server AMI镜像，可快速交付Windows Server操作系统，并使客户通过Session Manager或远程桌面的方式连接进行操作。
  1. 适用于 SQL Server 的 Amazon RDS
主要用于存储EPM系统的结构化数据，用于系统日常使用中的增删改查操作，为EPM系统数据提供存储。
  1. 亚马逊 Elastic Beanstalk
用于构建Windows Server Java工作负载基础架构及应用程序的部署，可通过初始化配置方式，设置所有基础设施内容，并且一键部署，快速交付工作负载。

2. API集成

1. IAM与Development

未迟开发者在本地环境进行开发作业，开发平台为IDEA，开发语言采用JAVA。部分开发作业需访问AWS API时，采用IAM临时Token的形式获取授权并进行AWS API访问。剩余则采用Secret Store提供的加密存储方法在代码中进行嵌入以实现程序运行自动解密并获取静态编程密钥，从而获取授权并进行AWS API访问。
在项目交付后，我司所使用的所有API集成方法和资源将全部删除释放，确保客户在使用运营系统时AWS API的安全。
上图为IAM用户获取临时Token并访问AWS相应资源的流程图。图中开发账户中的开发IAM用户Alice现因开发原因需对生产环境中的S3及EC2资源进行访问，在AWS IAM服务检验role正确后，将返回Alice一个临时Token，这个Token将带有Amazon S3、EC2资源的写权限赋予Alice。在Token过期前，Alice都有权访问生产账户中AWS相应资源，直至Token失效。

3.卓越运营

我司将根据AWS CloudWatch Agent示例将其安装脚本执行命令用Systems Manager服务中Run Commands功能执行至EC2 Windows Server。完成安装后并对其配置文件进行指标模型配置，当配置结束后保存并重启CloudWatch Agent。返回至CloudWatch界面并在几分钟后刷新将获取到Agent发送的指标，其中就包括CPU RAM DIsk Network指标。
对于性能瓶颈或异常情况的判断和确认，我们使用CloudWatch Alarm功能创建需要的告警规则以实现对工作负载不间断的监控。大大减少了运维人员对大量服务器及工作负载的运维压力，并且可以集中管理这些规则，也使得运维人员可以将更多的时间用来构建自动化运维体系和其他工作。
创建Alarm并选择相应的CloudWatch Agent指标项，并设置阈值及触发执行动作，以及通知形式，确保告警出发，相关人员可以及时收到通知并进行处理。
我司已对工作负载设置了所有需要的Metrics和Alarm，例如：
  1. 根据EC2的 CPU RAM Disk Network等指标的持续监控，例如EC2 CPU在大于等于80%时触发即将超负荷的CloudWatch告警，再通过SNS主题通知到相关人员。
  2. 根据ELB的 请求、连接等指标的持续监控，例如ELB 请求大于100000时触发即将达到web应用瓶颈的CloudWatch告警，再通过SNS主题通知到相关人员。
  3. 根据RDS的 CPU RAM Conncetion等指标的持续监控，例如SQL Server Query在大于等于100k时触发达到应用性能高峰阶段的CloudWatch告警，再通过SNS主题通知到相关人员。

3.1 收集和分析工作负载运行状况指标

使用上述CloudWatch服务收集工作负载Metrics及Logs数据，并使用内置DashBoard(数据面板)功能分析指标及日志数据，并且以图表等方式展现以时间序列为单位的指标数据，了解工作负载运行状况指标将变得十分轻松。
在EC2 Linux Server中使用shell脚本，导出CloudWatch Metrics指标json数据并将其传输至S3日志存储桶进行加密存储。对相应的Log Group进行Export data to Amazon S3操作，将日志内容导入S3并集中加密存储。

4. 运维赋能

我们向此项目客户交付涵盖如何监控工作负载、备份和恢复数据、修补和升级操作系统和应用程序组件，以及解决常见问题的《运维操作手册》、《常规及紧急故障处理指南》文档材料，以确保客户运维人员可以了解如何监控工作负载、备份和恢复数据、修补和升级操作系统和应用程序组件，以及解决常见问题。
将在操作移交前，我司将对客户进行为期一周的技术培训，方式为线上远程授课方式进行，内容包括但不限于持续运维方法、日常巡检及故障排除指导。
我司内部规定，在为期一周培训结束后，为期一月为客户运维技术支持窗口，尽可能的帮助客户熟悉AWS云上持续运维方法、日常巡检及故障排除等。

5. 测试与验证

通过架构师编写的CloudFomation IAC代码模版，以CloudFotmation Stack方式部署测试基础架构，并且在Stack部署完成后，对其工作负载进行测试。在工作负载及EPM系统运行正常，SQL Server存储正常，一切都得到验证后便可完成部署测试及验证。
测试与验证采用Elastic Beanstalk Blue Green Deployment(蓝绿部署)形式完成。测试环境使用蓝色表示，生产环境则为绿色。
新开发代码将由本地开发完成后进行打包作业，并通过Elastic Beanstalk控制台将软件压缩包上传，首次通过Beanstalk部署两个一模一样的架构及资源，这时所有流量都将通过蓝色测试环境，在进行完全测试并无明显故障异常后，使用切换环境功能，将流量全部切换至绿色生产环境，完成蓝色部署及测试验证作业。
采用该方法使得测试环境获得几乎完全和生产环境一致的外界流量等因素，并且在发生严重故障导致业务受影响时，可再次通过切换环境功能，快速将环境回滚至稳定版本。

6. 代码资产的版本控制

客户使用私有部署Gitlab仓库进行源码管理及版本控制（此Gitlab在客户案例之外的AWS架构中运行）。
客户开发者将在本地开发完成后，将源代码更新至Gitlab项目中，并由技术经理集中管理项目代码。
因为客户企业内部规定，不便在案例中透露代码资产及相关内容。

7. 应用和工作负载遥测

CloudWatch Agent将收集工作负载及应用程序的日志文件并且作为CloudWatch Logs Group存在。主要日志内容为应用程序在运行时的Debug级别日志，可以帮助客户有效分析出应用程序故障及错误原因。
通过CloudWatch定义的相关Alarm，可以有效的观测工作负载性能指标数据和告警临界值，并且根据图表及数据做出合理的评估。
我司会在培训中为客户技术人员进行相关讲解，例如：
在发现读取或写入数据操作缓慢是，可根据CloudWatch Agent收集的有关于IOPS, 吞吐量及读写延迟指标数据，快速发现应用程序读写异常原由。
在连接或者搜索外部数据时缓慢且卡顿，可根据CloudWatch收集的有关于Package Sent，Package Receive等网络指标，快速发现应用程序网络异常原由。
相关应用程序为客户自行开发，不在此项目考虑范围内，所以相关日志内容客户将自行理解和处理。

5.安全

1. Identity and Access Management(IAM) 身份认证与权限管理

对于身份认证与权限管理客户在阿里云中使用IDaas服务进行身份认证与权限管理作业，但是由于功能的细粒度不够，导致客户无法对一些颗粒度很小的权限上进行操作，间接导致了出现因为权限分配问题所导致的安全风险。
在AWS中，我司使用IAM服务对客户架构中身份认证与权限管理做重新设计，确保客户在日常生产中可以正常稳定并且安全的对AWS资源进行操作和管理。下面为IAM服务配置的详细过程：

1. IAM体系设计

1. 定义访问要求
为了确保身份账户的安全（Root Account），我们在建立IAM用户的基础上，不使用身份账户进行任何AWS资源创建与操作，并为身份账户配置MFA动态验证，提高身份账户的安全性。同时，我司也为特定的IAM用户配置MFA动态验证，提高IAM用户的安全性。以下为创建IAM用户的规则参考：
1. 为IAM用户配置强密码策略，采用16位全字符无规则静态密码，减少弱口令使用，所有密码打印至纸质材料封装保存，不保存在任何云上存储且不允许使用浏览器自存密码或私自保存在本地设备。定期轮换IAM用户的登录凭证；
2. 遵循最小特权授权原则，仅授权执行任务所需要的权限，最开始只授予最小权限。如有需要，向上级申报，审批之后，调整相关权限；
3. 同组人员工作性质相同并且向单独IAM用户授权不符合最小授权原则，所以授权对象为组，而不是单独IAM用户；
4. 业务系统目前部署在一个身份账户下，所有IAM设计全部基于一个账户下。
IAM设计图如图所示，因此IAM用户主要分为以下五个部分： 1. 主账户（Root Account）：作为默认账户及身份账户，在此账户上启动MFA，部署和构建IAM账户架构及用户组和用户。在AWS的日常交互中，使用其他用户凭证而不是默认主账户号；
2. 管理员组（Administrator Group）：作为账户核心组存在，目的为管理账户访问权限及AWS资源； 3. 下级管理组（Manager Group）：作为下级AWS资源管理组存在，目的为AWS建立不同用户，分散AWS资源权限；
4. 开发者组（Developer Group）：作为AWS资源使用组存在，目的为调试与开发应用；
5. 未迟组（Advich Group）：作为参与者查看AWS资源与账单成本信息，实时查看与监督我司操作AWS账户资源。
2. 最小授权体系
IAM用户仅分配需要的AWS资源，屏蔽其他非需求资源，避免维护人员误操作导致业务中断等严重问题。如表所示为最小特权授权表：
针对每一个IAM账户，在创建前都会发出账户申请表以确认该IAM账户需要哪些授权，从而对IAM账户进行最小化授权操作。在另外需要新授权时，再次根据原表添加授权申请，以供管理员评估。
如下图所示，该用户只能读取eolane-static-resources-bucket S3桶中制定目录下的文件。
3. 静态编程密钥
在架构及开发过程中，存在需要使用静态编程密钥的情况，使用Secret Store服务存储静态编程密钥，并在代码中创建相关方法解密加密数据得到授权从而进行操作，没有任何直接明文使用静态编程密钥的情况。并且，编程密钥将以生命周期的形式被轮换以确保密钥的安全性。所有编程密钥用户都严格按照最小化授权进行权限分配。
将AKSK等凭证存入Secret Store中，应用或工作负载通过IAM Role取得AKSK并操作AWS API，通过此方案可安全的调用AKSK。
使用IAM用户临时凭证的方式获取相应的AWS资源操作权限，在临时凭证生效期间均可调用具有相应权限的AWS API。
4. 合作伙伴
我司负责项目的主要技术工作和商务合作，在通过和未迟的会议沟通后，客户表示可由我们直接进行技术工作。对于项目组成员严格按照职能分工及最小化授权进行AWS IAM用户的创建与权限分配。

2. 网络安全

1.虚拟私有云（VPC ）

1. 架构
我司创建部署未迟运营系统专用VPC，并且采用多可用区不同子网部署服务以实现高可用架构，提高服务的可靠性及稳定性。负载均衡器负载流量转发，EC2实例负责应用程序的运行，数据库全部位于专用的私有子网里，通过ACL及安全组创建网络流量通信策略。
  • VPC – 专用的EPM系统VPC网络，与其他项目和网络做出隔离，有效的区分项目。
  • 可用区 – 共使用三个可用区(A, B, C)部署工作负载以实现高可用架构，可用区(A, B)作为生产环境专用区域，可用区C作为开发测试环境专用区域。
  • Internet gateway(互联网网关) – 作为公有子网的网关，负责所有进出互联网的路由流量。
  • NAT Gateway(网络地址转换网关) – 作为私有子网的“互联网网关”，负责所有不具备与公网通信的内网设备的路由流量。NAT Gateway与弹性IP绑定，作为所有内网设备在互联网上公有IP。
2. 安全组
对于网络安全组(Security Group)，我司结合客户需求对工作负载网络的进站和出站流量进行分析，最终将得到的地址和服务端口进行规整并创建网络安全组条目进行流量进出站授权。
所有必要服务端口进出站IP地址均为必要，严格按照最小化访问进行设置。通常一个服务只对单个地址提供服务，所以设置子网掩码为/32的唯一地址；如有对多台内网实例提供服务的，则设置子网掩码为/16的内网网段地址。下图所示为最小化访问安全组设置：
无特殊需要，所有网络安全组所有规则仅为必要服务，一切无必要服务条目将立即被禁用且删除，通过对网络安全组条目的添加、删除与修改事件上报CloudWatch的形式，创建告警(Alarm)来及时了解网络安全组信息变动，有助于在出现异常操作时，修复安全组的设置。
对于默认服务，例如ssh(22), SQLServer(1433))等，进行安全的变更并保密记录，在无需运维管理时，将通过Network ACL(网络访问控制列表)对SSH保持禁用。在整个架构中，所有网络访问控制列表将对默认的所有流量开启禁用，并只授权必要服务端口和地址。
通过上述方法即可最大程度提高服务对外隐蔽性，使得必要服务或不必要端口不会轻易被外界所嗅探或攻击。并且在异常状态下，管理人员会第一时间收到来自CloudWatch Alarm的消息，从而进行异常处理。
如下所示，为客户案例部分工作负载安全组及NACL配置表截图：
3. 数据传输
因未迟在AWS上托管运营系统，用户大多在浏览器访问web端并登录进行使用，所以对外提供服务传输协议为http。
我司使用ELB、ACM与KMS服务集成使用，来确保所有的AWS服务端点对外连接全部且全程采用安全套字节(SSL)方式进行数据加密，有效阻止中间人攻击等数据劫持的安全风险。
图例为未迟AWS架构SSL加密及用户访问逻辑，从图中可见用户将使用SSL加密的HTTPS流量访问负载均衡器，LB接收到请求并转发至相应web服务器，对外暴露的端点全部采用SSL加密，内部除必要服务外均为HTTP协议流量。
WAF为AWS一款Web应用防火墙，可有效对来自互联网的恶意攻击进行拦截和记录，所有互联网流量将经过WAF策略检测后，安全的流量将被转发至负载均衡器或CloudFront并进一步转发给应用程序。如被WAF策略检测并命中的流量将被拦截并返回自定义的策略结果，同时将被WAF日志所记录。对于有效拦截日志将由安全人员审计并分析，从而做出处理，进一步提高架构及网络安全性，让恶意攻击无处遁形。

2. 安全加密

我司使用Secret Store、Certificate Manager、IAM、KMS分别对未迟AWS架构中的RDS、SSL及AKSK等AWS资源进行加密存储。
  • Secret Store – 主要存储静态AKSK凭证，确保凭证在有IAM角色授权的情况下被获取，从而调用相应权限的AWS API。
  • Certificate Manager – 对SSL证书进行集中管理及操作，确保SSL证书的安全性，在未迟AWS架构中，与ELB、CloudFront结合使用，快速为服务载入SSL证书。
  • IAM – 用于为日常开发者通过STS申请临时凭证，从而调用相应权限的AWS API。
  • KMS – 主要用于S3、EBS、CloudTrail等服务的数据安全加密，多为服务默认生成的AWS托管KMS密钥负责数据加密作业。

6. Reliability

1. 自动化部署

通过lambda服务并使用aws sdk对基础架构构成IAC代码，使得在作业中可通过执行lambda函数的方式来快速稳定的部署基础设施资源及架。更重要的是，通过IAC方式自动化部署可以为后期的业务增长和系统运维提供便利，让运维人员及技术人员有更多的时间投入应用及生产力上。
代码从本地开发并由审核人上传至Elastic Beanstalk中，对其进行蓝绿部署测试与验证，Elastic Beanstalk本身就是自动化部署的利器，也可像IAC一样部署基础架构同时也具备让应用程序运行的能力。

2. Disaster Recovery(容灾措施)

任何环境在一些特殊条件成立的情况下，也会出现意外故障，导致工作负载或应用程序不能够正常运行，从而直接影响业务，这种结果是任何企业都无法接受的，往往是最致命的事件。
因此容灾措施是合规中最重要的一环，容灾标准主要为下图中的两个核心指标为基准来评估容灾是否满足需求：
  • RPO – 数据恢复点目标，主要指的是业务系统所能容忍的数据丢失量。
  • RTO – 即恢复时间目标，主要指的是所能容忍的业务停止服务的最长时间，也就是从灾难发生到业务系统恢复服务功能所需要的最短时间周期。
我司与未迟开展了关于容灾措施的专门会议，并得出了初步的容灾需求，未迟所能接受的RPO为1小时，RTO为30分钟，MTPOD(最大可容忍中断时间)为1小时。
根据客户需求，我司进行了容灾架构，经过验证和实际测试，证明此架构完全可以满足未迟的容灾需求。下图为容灾架构：
图中展示了在 Amazon RDS 上运行的 Microsoft SQL 数据库服务在但可用区部署主要SQL Server服务，并且夸可用区的部署只读副本，可以为不同区域内的工作负载提供数据库只读服务。并且在同一区域内不同可用区部署备用SQL Server副本。
SQL Server核心服务恢复流程：
如果发生计划内数据库维护或计划外服务中断，Amazon RDS 会自动失效转移到最新的辅助数据库实例。此功能可让数据库操作快速恢复，而无需人工干预。主实例和备用实例使用相同的端点，作为失效转移过程的一部分，其物理网络地址将转换为辅助副本。
发生失效转移时，Amazon RDS 通过使用Always On 可用性组来支持 Microsoft SQL Server 的多可用区部署。
图中展示了在Amazon EC2上运行的 Web服务器在单个区域中配置了Backup服务备份模型。Backup服务备份为EC2实例提供了更高的可用性、数据持久性和容错能力。如果发生计划内服务器维护或计划外服务中断，可通过Backup服务自动备份的实例快照快速恢复最近时间点正常运行的实例状态。
EC2 Windows Server Instance核心服务恢复流程：
如果发生计划内服务器维护或计划外服务中断，可通过Backup服务自动备份的实例快照快速恢复最近时间点正常运行的实例状态。
根据相关CloudWatch Alarm设置，当实例检测状态失败时，将自动触发实例重启操作，如果在从气候，服务自启动并恢复正常，将不再通过backup服务进行快照还原。
基础架构恢复流程：
当一个可用区中服务因灾难性等因素不可用时，Route 53 Appliction Recovery Control服务将触发故障转移，并将解析指向另一个区域中负载均衡器，并由该区域负载均衡器转发请求至相应工作负载中。在技术人员评估确认后，对其进行回复作业（EC2，RDS），之后由Route 53 Application Recovery Control恢复解析。
根据上述灾备架构及恢复流程，我司工程师进行了模拟测试，并得到了可观的RPO及RTO。下图为最终模拟测试报告：
容灾测试报告为未迟电子科技有限公司与我司共同进行的容灾测试后所总结的相关信息，报告中展示了关于RPO与RTO的数据：
  • 应用程序恢复 – RPO: 5min RTO: 3m 16s
  • 数据库恢复 – RPO: 15 min RTO: 8 min 02s
  • 基础设施恢复 – RPO: 30min RTO: 12m 47s
在完成容灾测试后，我司与未迟进行会议沟通，容灾方案与架构得到了客户的认可及支持，在实际部署中也用到了这些容灾方案。

3. 资源选择

1. 弹性伸缩
因运营系统特殊性，根据客户描述，每台实例的负载永远不会超过预期水平，如有需要，仅支持横向扩展方式增加实例，需要人工介入操作。
所以，弹性伸缩在此客户案例中不适用。
2. 指标分析
在POC测试中，运营系统初期运行期间，总是出现内存负载持续过高的情况，经过我司和未迟沟通得知：
操作系统在POC测试初期没有进行合理的生产环境系统优化作业，导致系统处理性能下降，耗费大量内存，最终导致应用程序卡顿，用户体验差的结果。
我司了解后，决定对POC测试的实例操作系统进行初始化生产环境优化作业，对其进行创建AMI镜像作业，重新配置Beanstalk中的操作系统AMI选择为优化后的镜像。
再次进行部署测试工作负载情况，发现优化后的操作系统使得工作负载稳定的运行，并在应用程序高峰运行时段会有较高的资源占用。
在架构中，大量使用了CloudWatch指标进行工作负载的监控，客户定期收集核心指标数据并做进一步的分析，可以从数据中得出业务增长趋势和资源使用分布、状态等。
利用精准的指标数据可以非常快速的定位性能瓶颈以及所需算力等采购资源时需考虑的重要指标，从而为客户企业最大化节省尽可能多的资源冗余带来的不必要成本支出。

7.成本 优化

1.CloudCraft​

我司使用CloudCraft绘制客户案例AWS架构图，同时在此架构中设置资源配置细节，再通过budget功能与客户沟通意见，修改budget最终得出TCO报告。下图展示了CloudCraft Budget (预算)功能截图：
将估算分析并整合后，将TCO估算交付给未迟科技有限公司进行整体架构及服务计费估算。让客户能够清晰了解项目将产生的大概成本，从而评估项目是否合适等。

2. AWS 定价计算器

我司在使用 CloudCraft 基础上使用 AWS Pricing Caculator 对于一些特殊服务进行更加细致的数据优化，从而得到更为精确的估算。下图为AWS Pricing Caculator TCO估算：
qrcode_for_gh_d83fc0dfb3b4_258(3)

Copyright © 2020 OnCloudUp AI Technology Co.,Ltd. All rights reserved | 苏ICP备16022761号-14

苏公网安备 32011102010384号

+86-18112935086

dongchunfei@advich.com

Scroll to Top

联系我们