我们正在俄罗斯和邻国建立最好的借贷检测系统。 在理想的世界中，我们只会处理系统的设计和开发。 但是，遗憾的是，防-窃并不是在真空中进行的，为了使我们的用户方便，舒适地使用我们的开发成果，我们还需要开发围绕我们服务的环境。 我们的软件还不能在没有熨斗的情况下运行，用户需要提供技术支持，必须在不违反法律的情况下从用户那里收到付款等。 简而言之，例程就足够了。

本文是有关如何通过外包使我们的服务更好的一系列制作戏剧的第一篇。 我们分享真正的问题和结论。

乌云密布，金发马匹...

^{（从Internet上的某个地方，我首先在这里看到它。）}

我们系统上的负载非常不均衡：首先，白天负载变化了5次。 其次，有明显的季节性。 夏季会议结束后的每日最高支票减少10倍！ 冬季会议不是那么明亮，但也不是礼物。 另外，以后的每个夏季会议（在检查次数方面）都比上一个更重（在检查数量上），并且较难（新的搜索技术和功能）。 因此，一方面，我希望有充足的资源供应，另一方面，在活动减少期间不要付出太多。 在一个会话中，您可以部署更多服务器，并在夏季减少消耗的资源量。 显然，云提供商就是这种情况。 在本文中，我将讨论与几个云提供商（AWS，IT Grad，MCS，YC）进行交互的各个方面。 如果在某人看来这是灵魂的呐喊，那么他不会很误会。 所以走吧！

ws

我们从2013年2月在AWS中租用了第一台服务器时就开始使用云资源。 实际上，亚马逊是使用云计算的第一个也是运行时间最长的反-游经验。 然后我们从一台机器开始，现在我们在AWS中的预算比所有俄罗斯云的预算高一个数量级。 如您所知，初恋永远不会被忘记。 基于使用AWS的经验，我考虑了本文中其他云的所有问题和机遇。

没错，与亚马逊的关系也有美中不足。 以下是我们对Amazon的功能或不便之处：

1. 您无法通过浏览器访问虚拟机的控制台。 有时确实需要在这里！ 一旦我们错误地删除了网络接口，并且其中一台机器上的访问丢失了。 幸运的是，有人已经遇到了这样的问题，我们在半小时内找到并成功应用了该解决方案。 通过控制台，这样的操作可以在一分钟内完成。
2. 成本以美元计，我们以卢布计。 因此，获利能力取决于美元。
3. 俄罗斯没有数据中心，而我们开业时最接近的数据中心是爱尔兰。 这意味着由于俄罗斯法律的要求而产生了很大的威胁，并在数据存储上出现了一些限制。
4. Roskomnadzor定期阻止AWS地址。 当前，AWS中来自不同站点的服务器可用性不同。 出于未知原因，与机器的连接可能会断开。 通常，更改IP地址，VPN和代理会有所帮助。
5. 亚马逊比俄罗斯云贵得多。 没错，您可以通过灵活的备份程序和使用竞价型实例来降低成本。 而且我们正在积极地使用两者。 ，我们尚未在家用云中看到这种功能（更新：YC在2月18日的新闻稿中宣布了“中断的VM”，我们正在等待详细信息）。
6. 信息不足的问题。 从第三代机器过渡到第四或第五代机器期间，虚拟硬件发生了重大变化，尤其是驱动器的连接方法，并且机器在类型更改后根本无法启动。 实例管理界面返回了一条简洁的消息：容量不足。 有足够的限制来创建必要类型的机器，并且留有余地，并且大约六个月以来，我们以折衷的方式折磨了免费的技术支持，但未成功。 它没有帮助。 结果，他们自己在Google解决方案上进行了搜索-机器的平淡无奇的娱乐会有所帮助。
7. 几次，我们将SSD擦除掉了：磁盘只是随同所有数据一起从系统中消失了。 鉴于这些是临时磁盘 ，即 当机器停止时数据丢失，我们没有在它们上存储任何不可替代的东西。

原则上，可以克服这些缺点。 但是，恰好在Amazon最终注意到俄罗斯市场的那一刻，我们的帐户变得不太方便通过卡付款。 幸运的是，亚马逊迅速纠正了这种情况，并为我们提供了一名客户经理，该经理帮助我们从通过卡支付转为直接合同，支付账单和草拟各种协议。 总的来说，他经常来俄罗斯，当他来到我们这里时，他谈论的是优化基础设施和支付的机会。 有时，他会带一名解决方案架构师，他可以与他讨论我们解决方案的当前架构，谈论“愿望清单”和问题，并不仅通过AWS服务获得多个解决方案。 亚马逊员工宣称，他们的目标不是提供更多服务，而是确保购买的服务使企业受益。 看来这是真的。 服务的数量，服务的发展速度和相互融合的深度令人印象深刻。 AWS具有组织一切规模的高负载系统的开发流程和运营的一切功能。 到目前为止，只有一个全球性问题是昂贵的！

IT毕业生2016

2015年，我们决定是时候完全放弃自己的烙铁了。 我想把问题放在设备的可靠性上，特别是在其他方面，而更多地集中在改进我们自己的开发过程上。 根据我们的预测，到2016年，我们将拥有目前拥有的足够设备，并且我们希望为每次火灾保留储备。 我们彻底地选择了提供商，我们为我们准备了一个负载测试和一个带有重要问题的问卷，并从以下五个提供商中精心选择：ActiveCloud，Cloud4Y，CloudOne，IT Grad，Softline。

结果，我们选择了IT Grad云。 它们的优点：

1. 积极生活，对我们问题的回答很快得到了，很容易沟通。
2. 快速SSD驱动器的存在，每GB高达30 IOPS。 随机读取操作的数量对我们来说是非常重要的指标，因为高值允许我们将扫描模块放置在云中。
3. VCloud平台具有控制机器的能力，并且每台机器都有一个控制台。
4. 无需重启即可增加虚拟机资源的能力。
5. 灵活的结算方式 -付款时间是在报告期间的中间一天（每月的14日至15日）。 此外，还有一个“即用即付”选项，但是，它更昂贵，消耗的资源量的计算由每2小时的平均CPU和RAM负载完成。

在2016年，我们转到了IT Grad。 这是我们生命中不完整的三年在一起发生的事情：

1. 一旦我们遇到问题。 恰好在21:00，开始出现性能下降的奇怪现象。 系统可以执行的检查数量从每分钟150次减少到20-30次，而几个小时后，所有内容以每分钟600次检查的速度恢复并解决了。 我们在家搜索了一个星期，检查了用户，发现了僵尸程序和DDoS，但没有找到任何东西。 我们转向IT-Grad的支持，发现“哦，我们在这里进行备份”。 结果，他们给我们带来了各种磁盘系统问题的根源并开始工作。
2. 通常（在使用产品的功能上），在一个会话期间，我们的流量超过每秒100兆位。 顺便说一下，许多云提供商中的默认值通常是为非保留通道设置的。 当我们第一次越过边界时，出现了许多问题：内置的Edge无法应对位于我们设备上的入口点与位于云中的Web服务器虚拟机之间的VPN。 不出所料，他们转向支持，我们在那里增加了Edge的资源。 好的，毫无疑问，我们从小到大替换了他的配置，并且还将渠道扩展到了我们的高峰流量大小。 它没有帮助。 通常，我们找不到最佳解决方案，我不得不通过将部分产品移至其他站点来减少流量。
3. 与IT Grad站点的VPN连接有时会中断1-2分钟。 对于为什么会这样的问题，我们和技术支持都找不到答案。 到目前为止，我必须忍受这个问题。
4. 调整资源大小的机制在运行状态和关闭状态下均无法正常工作。 但是在我看来，这对平台供应商（VMware）来说是个问题。 但是，我们已经遇到了这样一个事实，即为了可靠地应用所有扩展，必须重新启动来宾计算机（Windows Server 2012 R2）。 调整大小后，机器本身没有启动几次。 在会议期间的早晨，我们的支持小组曾经将问题从2修正为4。 即使晚上也很热！
5. 在2016年，我们拥有像Everest这样的庞大整体，需要大量资源。 如此之多，有时我们需要超出为给定主机推荐的来宾计算机的最大大小。 支持人员不断要求我们将虚拟机的大小减少到至少主机大小的一半。 我们必须向IT Grad致敬-我们被提供去使用能够完全使用它的单独硬件，但是，这需要花很多钱，而且云的灵活性也因此丧失了。
6. 每月为测量消耗的资源量计费一次对我们来说是一个骗局。 从一开始，我们就直接询问是否有机会在每月的14日至15日减少资源以减少费用。 我们被直接回答说这就是它的工作方式。 在将一部分销售转移到我们的云中时，这是第一次给我们带来痛苦。 人为因素起了作用-他们试图在14日之前迅速完成所有任务，然后就表现出色。 经过将近3年的合作，我们第二次抓住这个机会，之后平均在第5、15、20天向我们收费。 然后人为因素为他们服务-通话后，事实证明他们犯了一个错误，对他们有利（重新计算是手动进行的），道歉并给了折扣。
7. 磁盘和计算机的整体性能符合声明的特性。 然而，有几次我们无法理解为什么一切运行如此缓慢，甚至接口也无情地变慢。 支持人员确保一切正常，并且设备没有问题。 那里发生的事情-当时我们的服务器已迁移到附近的主机，或者有人做了磁盘子系统的备份-这对我们来说仍然是一个谜。
8. 只能通过支持才能在计算机之间独立切换磁盘。 在开始使用时，不可能在计算机中拥有不同类型的磁盘，而必须退出（iSCSI，Samba和NFS）。 一段时间后，首先可以通过支持在一个机器上使用不同类型的磁盘，然后再单独使用（显然在vCloudDirector中完成）。 顺便说一下，定期更新虚拟化管理系统。 我们每个月会收到1-2次信件，说明虚拟机控制系统要花一两个小时进行技术工作，并且在一段时间内将不可用，此时机器本身仍在继续工作。
9. 由于设备所在数据中心的电源问题，2018年2月16日，我们位于IT Grad的部分销售收入下降。 我们实际上了解了该事件；我们无法联系技术支持。 我不得不打电话给我们的客户经理，他马上在一分钟内说了什么和如何，然后断断续续地告诉了其余的人。 令人愉快的-我们躺在VKontakte旁边。

在租住的房屋中度过一段时间后，面对上述所有问题之后，2017年，我们决定参观是不错的，但在家中会更好，并开始使用快速NVMe磁盘和完全控制所有内容的能力来制作云。 言归正传：他们将销售转移到公司客户和搜索模块的云中（总计超过90％的负载），将监视，统计和私人客户留在了IT Grad。 在2018年，每个人都再次进行计算，结果发现拆分生产更有利可图：将一部分保留在租用的云中，一部分保留在自己的云中。 这是怎么回事-我们进一步讲。

邮件云解决方案

老实说，我想像在AWS中一样，但在俄罗斯。 因此，我们开始着眼于具有类似服务集的云（我所欺骗的对象，至少与EC2和S3类似）。 搜索是短暂的-我们在MCS的手中找到了“ Russian Amazon”。 一家提供各种服务的大型公司，从种种迹象表明，他们应该能够做好准备！

相识的开始是美好的。 一位客户经理来到我们的办公室，详细介绍了一切，并介绍了当前的机会和近期的计划。 输出是一幅奇妙的图画：计算资源的价格低廉，有一个对象存储并且可以尽早退出数据库生产（类似于RDS）。 我们还获得了可靠的测试现金限额（甚至比Azure所提供的还要多）。

到那时，我们已经准备好IaC部分来通过terraform部署所有机器。 MCS具有openstack，并且得到了很好的支持！ 顺便说一下，技术支持是通过电报渠道进行的，即“实时”通信，很显然他们希望提供帮助。 有票务系统，但我们尚未使用它。 技术支持SLA是指在票证系统中创建的请求。

到2018年12月，我们已经通过terraform编写了基础架构部署脚本。 现在该出发了。 首先，我们决定将系统与私人客户一起转让，这些客户一直都住在IT Grad的设备上。 然后，一切就像一部电影：

7 (), 18:00 . , .
10 (), 10:00 – .
12 () – .
10:00 terraform. , , .
12:00 ansible'. . !
15:30 . 30 , 16:30.
15:45 . .
15:55 . : , .
16:20 , . , . , - .
17:30 , , .
18:00 . 1,5 .


所确定的具有不同格式并尝试新的问题应该不会出现，但是我们找到了它，以防万一已修复它。

17 (), .
15:30 . , .
16:00 . .
16:30 , 100%. -? !
17:00 , , , , iotop, top, ProcessExplorer, PerformanceMonitor. .
21:45 , , , 2000 .
22:00 , .


IT Grad上的旧产品很容易满足用户检查的延迟需求，这没有问题。

第二天（12月18日），我们实现了以下目标：

1. 我们不知道是什么原因使系统速度减慢。 在带状装饰之前，几乎没有负载。 是的，我们在系统内部仍然存在严重的阻塞调用，并且很可能在某处存在阻塞，但是确切地说，在我们无法提出的地方，有必要进行进一步调查。
2. 我们当前的负载测试与产品的负载曲线不匹配。 太神奇了，因为 通过此测试，我们为上一届会议做准备，确定并消除了许多瓶颈。 但这是现实-有必要根据经验重新进行测试。
3. 它具有可比的CPU和RAM资源，是IT级产品，可以轻松应对两倍的负载。

因此，我们迅速建立了一个测试，该测试可以达到与第一手看到的结果相同的结果。 我们去了MCS支持部门，以了解我们是否正在消耗CPU限制，但总的来说，这完全是我们的限制，网络环境还可以。 他们仍然没有回答第二个问题，他们在第三个问题上找到了一些建议，并建议我们对多核系统进行更改。 总的来说，我们开展了一项充满活力的活动，年底快到了，每个人都希望带着成就感去度假。

这是我们在使用MCS时最终得到的结果：

1. 即使在选择阶段，也通过磁盘向我们发送了一张具有虚拟硬件和SLA特性的表。 优点之一是，他们承诺为SSD提供50 IOPS / GB（IT等级：30 IOPS / GB）。 合同结果是不同的：“阅读：5000 IOPS，写作：2000 IOPS”，我们错过了这一点，没想到这一点。 这些表是相同的，区别只是在一个地方！ 顺便说一句，我们没有看到性能对磁盘大小的依赖性。 当我们进行测试时，甚至发现在更大的驱动器下，速度会下降。 如此小的指示符的秘密在于，MCS具有地理分布的ceph，这意味着，直到远程节点说出数据已被写入，客户端才不会被告知记录已完成。 顺便说一句，在我们与之交谈的提供商中，似乎没有人具有“开箱即用”的可靠性。 但是对我们而言，如此的可靠性只会让您大跌眼镜！ 如果发生某些情况，当出现问题时，我们需要快速转移到另一个DC，因此我们拥有自己的异步复制。 我们拥有DRP ，并且我们为在发生事故时丢失少量数据做好了准备。 我们必须向MCS表示敬意，他们加速了性能更高的本地SSD阵列的调试。
2. 至于机器的参数，它们不是任意的。 有一组特定的CPU-RAM- {SSD / HDD}（几乎与AWS中类似），并且只能通过支持才能创建其他类型的计算机。 整个过程大约需要2个小时，类型数量没有限制，主要的是内核数量应不超过虚拟机管理程序的一半〜40-48个处理器。 在计算机创建过程中，您可以自己添加光盘并在计算机之间切换。
3. 打开本地SSD后，更改计算机的参数将使其无法启动。 它们只能通过支持来启动。 他们在一个月的某个地方解决了问题。
4. 首次面临电报的技术支持。 通常，它很方便，尤其是在开始时，如果有很多问题并且需要深入研究。 但是，问题越远，解决问题的难度就越大，答复和信息内容的速度就会缓慢下降。 到了年底，当然，每个人的截止日期都到了，低速的回复让我非常恼火。 在某些时候，他们甚至询问了SLA。 这就是SLA在票证系统中而不在电报中的理解！ 在2月19日时，我们在12月24日提出的一些未解决的问题已在此频道中挂起...
5. 通过票务系统提供的技术支持未考虑我们已登录的情况，因此需要另行通知合同编号。 作为回应，他发送了一封“我们将与您联系”的信，但未注明票号或状态。

在与MCS合作时，另一个云开始并行出现。

另一个云（Yandex云）

其他的第一个是Yandex。 到2018年底，他们只有虚拟机和对象存储，自己的虚拟化系统外壳，开放的API。 terraform插件为Alpha版本，并由HashiCorp同意。 与往常一样，支持是通过电报进行的，但它的活跃程度不如MCS。 测试资金限额足够小，并且不允许我们进行常规测试。 我不得不匆忙达成协议（3个工作日）并支付测试费用。 根据测试结果，我们得到了与MCS相同的结果。 在我们看来，这里出现了两个问题：每个人的驱动器速度太慢，并且测试太严格。

IT研究生2019

总的来说，我们将搬迁的截止日期定在了12月22日，这样一来，又有一周的时间来确定和解决新住所的隐患。 MCS和YC失去了按时完成任务的希望，并对MCS和YC的大量新信息感到有些厌倦，因此我们决定IT Grad在他们的背景下还算不错。 我们甚至感到有点怀旧，并认为所有新事物都已经过时。 在IT研究生院，我们一定会做得很好-有一个先例。 加上IT Grad：莫斯科数据中心Tier III，目前仍具有100％的正常运行时间（从未失败），并且内部设备为4插槽Intel Xeon可扩展（最多42核x 3 GHz Xeon金牌6154）。 什么都不是在开玩笑，我们将再给一次机会！

28 (), 18:10 - vDC , , .
29 ( ), 17:04 , . .iso , . , . , . , .
30 (), 22:00 , .iso, . , - .
31 (), 3:15 Edge vDC vDC. , . .

, .

2 (), 15:30 .
2 (), 21:50 , Guest OS Customization .
3 (), 18:05 !

1. 现在，在撰写本文时，他们发现请求和答复的确切时间未反映在票务系统中。 而是说“大约2个月前”，确切的时间仅在工具提示中显示。 通过邮件，也很难恢复事件的顺序。 发送给邮件的消息具有非显而易见的逻辑，并且不包含操作说明。 一段时间后，代表IT Grad技术支持员工在系统中创建票证。
2. 在放假后仔细查看设备后，我们在那里看到了Xeon v2。 那不是我们所同意的。 好的，我们与客户经理一起决定了这个问题。 由于在MTS中包括了新的2019年IT Grad，因此出现了一些困难，并且在假期之后就出现了一点混乱。 从vDC上看不到莫斯科DC上的新设备，而是在新年前创建的vDC。 仅通过开放的互联网，技术支持才能使我们“移动”速度不超过1TB /天。 而且我们已经上传了7TB的数据！ 结果，他们创建了一个在星期四晚上移动的应用程序。 一天后，星期五晚上，我问您好，他们打算什么时候开始（等待将近一周！）？ 一天后，在星期六晚上，我们被告知所有汽车都已移走。 我不喜欢那2.5天没有工作进展的信息，而且对搬迁的估计太悲观了。
3. 在2018年9月，当我们开始实施IaC时，我们意识到terraform与vCloudDirector的配合非常差（更新：在撰写本文时，我们了解到出现了VMware vCloud Director Provider 2.0 ，但尚未尝试过）。 最初，我们甚至无法创建计算机，原因是vCloud本着“出错了，您有512个字符的错误136行（该行较短！）机器配置的Xml”的精神通知我们的错误。 我们要求支持。 问题被转给了工程师，最后我们被告知不支持terraform-自己解决。 至少我们发现应该由打包程序来负责，我们用它来收集机器映像，他无法应付专有的VMware配置格式。 Terraform对于vCloudDirector来说非常糟糕，所有东西都是单线程的，并且连接器已经被抛弃了很长时间并且无法开发。 没有人可以让我们访问vSphere。 如果您使用VMware，则需要通过其API查看自动化。

我们在新地点组织了一个测试台。 结果是惊人的-测试失败，症状与MCS相同。 可能是在当前争夺战中的热门产品中，某些操作系统设置已更改，这些设置可以防止系统冻结，但现在无法还原。 为了防止这种情况再次发生，我们引入了IaC。 我们进行了另外2个测试：根据当前销售操作系统的干净映像创建新机器-失败； 在现有生产机器上-成功。 因此，可以肯定的是，我们在OS或数据库中进行了一些调优，但我们不记得是哪一个。 至此，我们开发的解决方案及时出现：当在WCF中禁用可靠的会话时，束缚就停止了。

我们使用开发人员推荐的设置在MCS（2 GHz，Xeon v4）和IT Grad（3 GHz，Xeon v2）上并行运行了负载测试-内核和内存的数量相同。 在MCS上，测试通过得更快（减少了四分之一）并且更加顺利（在IT Grad上，测试进行得比较混乱，然后更快，然后更慢）。

磁盘性能比较

我们最关心用于数据库和索引的磁盘的性能，这就是为什么我们主要测试SSD的原因。 当我们需要了解云的性能时，不要严格地对测试进行判断，在habr.com上，还没有对磁盘，处理器，内存（ 一次 ， 两次 ）云提供商进行多次测试。 我们的时间有限，我们需要快速比较性能以了解性能差异。 因此，测试的要求是一项-可以在任何地点快速重复进行测试。 我们使用的机器尽可能接近已部署的参数，例如测试磁盘的性能和pgbench的性能，以评估该磁盘上数据库的性能。 作为标准，我们从当前的产品-火星（ Mars ）中进行测量（因为我们的设备以有关火星上的岩鼠的动画系列中的英雄命名）。

通常，磁盘性能取决于其大小。 我们在IT City和AWS中观察到了这种行为，但是在MCS中我们没有看到这种依赖关系，在SLA中也不存在这种依赖关系，并且测试给出了自相矛盾的（甚至可能是不准确的）结果-性能随着磁盘的增加而降低。

我们计算了HDD和SSD磁盘的iops，以及SSD磁盘上的postgres数据库的tps（每秒事务数）。 MCS中有两种类型的磁盘：常规的按地理分布的ceph SSD和HDD，以及本地（仅在一个DC中）SSD（其性能显示在括号中）。 同样在2019年1月，在MCS的邮件中，我们看到它们将磁盘性能提高了20％，测试结果也在表中（MCS 2019）。 据报道，2月份又有加速，但我们没有在这里进行测试。

结果：

测试方法

iops的计算方式为4次连续测试的平均值：
/root/fio-2.0.9/fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=test --bs=4k --iodepth=64 --size=4G --readwrite=randrw --rwmixread=75

tps ，平均运行3 pgbench：
pgbench -c 10 -j 2 -t 10000 example

展台说明

火星

Xeon v4，2 GHz ； 硬盘： ceph，3个9x 2Tb ST2000NX0253节点，副本2; SSD： ceph，2Tb NVMe Intel DC P4600上的3个节点，副本2

CPU ：4， RAM ：8GB， HDD ：32GB， SSD ：150GB; 平行生产正在旋转。

IT毕业生

Xeon v4 / v2，2 GHz ; 硬盘 ：0.1 IOPS / GB ; 固态硬盘： 30 IOPS / GB

CPU ：4， RAM ：4GB， HDD ：250GB， SSD ：200GB

麦克斯

至强v4; 硬盘：读/写：1500/1000 IOPS; 固态硬盘：读/写：5000/2000 IOPS

用于测试硬盘：CPU ：2， RAM ：4GB， HDD ：50GB

用于测试SSD，TPS ： CPU ：8， RAM ：16GB， SSD ：600GB

至强v4，2GHz

CPU ：8， RAM ：8GB， HDD ：20GB， SSD ：50GB

年度总拥有成本估算的比较

我们将TCO分为四个选项。 相对值如下表所示。 我必须说，这是针对我们特定情况的计算，对于您来说，一切可能会有所不同。

我们进行了如下计算。 这一年分为两个部分：会议（工作量增加）和其余时间。 对于每个部分，都计算了所需的CPU和RAM资源量。 由于服务的不断增长，所需的磁盘量只会随着时间而增长，因此，我们采用年初和年底之间的平均值进行评估。

使用AWS进行评估几乎没有困难，因为 内核和千兆字节的内存没有直接成本。 我们使用了3台最小的机器c5.large，r5.large和m5.large，并以MCS价格计算了成本（按比例更改了CPU内核的成本，因为MCS的频率为2 GHz）。 结果是：平均而言，简单的AWS实例的成本是MCS成本的2.5-2.8倍。 AWS发布不含增值税的价格 。 因此，对于AWS的成本，我们加上20％，年平均美元汇率为70卢布。 磁盘以EBS价格相当简单（我们使用不同类型的gp2，sc1，st1）。 在某些地方，我们需要i3系列实例的NVMe驱动器。 它们的每千兆字节价格非常简单地计算出来：i3与r4系列的类似处理器和内存实例之间的成本差除以NVMe的数量。 事实证明，在30天内，每GB容量为3.1卢布。

即使在有关预算的讨论中，我也要指出所有云提供商每个月每个内核的Windows许可证成本的差异。 在AWS上，Linux OnDemand和Windows OnDemand实例的成本除以内核数之间的差额为每月约2,800卢布。 在YC中，内核的Windows许可证便宜3倍，每月约900卢布；在MCS中，内核的Windows许可证便宜近9（！）倍，每月约300卢布。 我们仍然非常依赖Windows：现在，由于有了.net核心，我们开始使Anti-Plagiarism跨平台，包括降低维护成本。

YC的总成本还包括流量成本。

结论

穿过云层

AWS 他们说，在俄罗斯有4个优秀的云提供商：AWS，GCP，Azure和DO，但它们都不在俄罗斯。
优点：优质的服务，高质量的现代设备，EC2中的良好配置，大量的服务。
缺点：价格昂贵（加上汇率风险），而不是俄罗斯（ILV，即将出现的强大俄罗斯防火墙）。 我真的希望我们的云跟随这个例子。
功能：免费的技术支持可以解决最少的问题，但是，老实说，我们与之联系只是为了扩大使用范围。 顺便说一下，已付费用约占帐户的10％。

IT研究生 。 为企业云服务。 有基于Swift的EC2和S3类似物。
优点：良好的性能（1-2-3 GHz CPU，SSD，HDD），家用云中的新设备（在DC之一中），任意机器配置。
缺点：计费方式混乱，VMware（自动化程度低，闪存界面），技术支持方面有些混乱和混乱。
功能：在公司使用（配置一次，然后进行罕见更改）下比在高负载的公共系统（频繁更新，不断更改）下更加清晰。 自2019年以来，IaaS业务已与MTS的人员和设备一起出售，现在一切都可以朝任何方向改变。 通过票务系统和电话进行通讯，我希望得到更快的反应和有关预期截止日期的消息。

MCS 。 有类似EC2服务（有GPU），S3，ECS，RDS，EMR，它们自己的服务是：机器学习，云灾难恢复，云备份
优点：价格便宜，正在积极开发，有GPU（Tesla V100和Grid K2）。
缺点：慢速驱动，潮湿，母公司的业障。
特点：一开始的技术支持很有用，有大量员工加入，可以得到帮助，但是活动却明显减少（自12月24日以来他们什么都没回答，我什至担心这些家伙）。

YC 。 我们与该提供者合作的经验很少，很难说出任何具体的内容。 有EC2，S3，RDS，DS，SQS（alfa），ELB（alfa）的类似物 ，它们的独特服务是：SpeechKit，Translate。
优点：驱动器比MCS快。
缺点：地形提供者是潮湿的； 具有开放api的虚拟化外壳的软件对于社区来说不是很大，这意味着到目前为止，您只能依靠YC团队的优势来开发terraform的提供程序。
特点：支付流量。

经验教训

1. 我们意识到压力测试在道德上已经过时了。 他们更新了测试，发现了新的瓶颈，并将其修复，使产品更好。 我们记得负载测试应该足够，并且应该在某些配置上绝对不能通过它，以便您可以看到其适用性的极限。
2. 尽管人们普遍认为软件目前尚未优化，并且所有瓶颈都被资源淹没，但我们还是不得不弄清楚并优化我们的系统。 事实证明比以前要好，新版本的《反lag窃》需要更少的资源，并且运行更快。 已经概述了几个可以减少资源消耗的地方。
3. 我们完成了IaC，通过ansible进行部署和更新，学习了如何在近10-15分钟内从云迁移到云（具有初步的数据复制）。 如果复制了数据并配置了常规复制，那么这里就是灾难恢复计划：移动了半个小时，最近15分钟丢失了数据。

我们要从云中得到什么

1. 及时获得技术支持的答复。 不幸的是，到目前为止，我们无法像在AWS中那样使用它-可用信息太少。
2. 通过免费资金（地形）支持自动化基础架构部署。
3. 性能的可预测性。 这适用于计费，CPU性能，RAM，磁盘。
4. 现在存在功能类似物EC2，S3，RDS。 在不久的将来，我们需要支持k8和GPU计算（我们已经在AWS上使用了它）。

除了迁移到云端之外，在过去的几个月中，我们还设法触及了其他地区的耙子。 情况如何-我们稍后再讲。