我正在为一个图像处理应用程序构建一个后端服务。用户创建的图像以20-40张图片组的形式上传到,并且需要通过GPU加速硬件进行处理,为此我计划使用亚马逊EC2,然后再返回存储以供用户应用程序下载。
每组图像都有一个“截止日期”,该日期由服务器端生成,可能在提交后8小时至72小时之间的任何地方。此元数据将存储在中,其中组将按到期日期进行索引,以便于排队。在G4ad或G4dn EC2实例中,我估计一组图像的处理时间应该少于一分钟。
我希望通过利用EC2现货价格将服务器总成本降到最低;然而,工作在“到期日”之前完成是相当关键的(例如,当下一份工作还有1小时时,我应该放弃即期价格,只支付按需价格)。我一开始并没有预料到足够的数量来证明一个专用的实例或承诺更高的使用计划。
我如何设计一种在尊重工作到期日的同时将成本降到最低的解决方案?
我已经考虑过的
1. AWS批量
AWS批处理似乎通常用于排队作业。我可以为指定要处理的图像的I的作业排队,然后作业将在运行时获取这些映像。
然而,AWS批处理似乎只支持一个近似的FIFO排序作业(而我希望他们在到期日前被订购)。我也没有看到根据队列中的时间在点播/按需实例之间切换的机制。
2.手工管理
我可以分配一个Spot实例和一个随需应变的实例,并根据下一个作业的到期日在这两个实例之间切换。我可能会在AWS、Lambda或google云上设置一个云功能,以便定期(例如5分钟)轮询Firestore中下一个到期作业的到期日:
我不确定这是否是一个好的方法,所以我愿意接受任何反馈或替代。
发布于 2021-09-27 08:25:58
我不认为只使用spot实例是一个很好的选择。是的,spot实例是非常适合批处理的,条件是您可以容忍它们不可预测的性质。它们可以在任何时候启动/终止。
由于批处理作业是time关键,所以我认为最好有按需实例(可以用保留实例保存很多),您可以一直中继这些实例,不要担心它们会在到期前终止。
作为妥协,您可以使用点船队。现场舰队允许您推出混合按需和现场实例.在您的情况下,舰队中的按需部分应该足够大,以便在没有现场容量的情况下处理整个工作负载。如果有现货容量,那就很好了,你的批次处理会提前完成,这样你就省了钱。在最坏的情况下,任何图像都是由按需实例在到期日处理的.
SQS队列执行保存器命令消息的,因此您不必担心图像被按不同的顺序处理,然后提交到队列。但是FIFO队列会给并行处理带来一些问题,因为您必须始终保持消息的顺序。为了能够并行处理消息,您必须在FIFO中使用不同的消息组。
发布于 2021-10-03 21:22:34
每个节点类型的运行时间是可变的/可控的,这使得以下操作:
Cost1 = ( node1 price per hour ) x ( running time1 )
Cost2 = ( node2 price per hour ) x ( running time2 )
...
Costn = (node n...) x ( running time n)
Total cost = sum of cost 1 + .... + cost n
Fitness = 1.0/ (total cost * normalized due date breach ratio)如果可以通过预测gpus的图像处理性能来使用总时间(到期日)约束,那么遗传算法就是一个可解决的问题。
由于您已经有gpus在手,解决它需要毫秒,如果不是秒。
即使是对静态gpu性能的错误预测,如果在整个计算过程中反复求解并动态调整服务器分配,也会收敛到解决方案。(您可以通过测量给定给每个节点的工作及其响应时间来度量它们的当前性能,并相应地为遗传算法的下一次迭代调整工作分配)
另一种方式可以是:
这可能不如解决最小化问题那么有效。
https://stackoverflow.com/questions/69341726
复制相似问题