#1遵循提升和轉(zhuǎn)移方法
提升和轉(zhuǎn)移方法意味著組織可以將工作負(fù)載的副本移動到云平臺中，而只需進(jìn)行少量的更改。即使組織只將部署業(yè)務(wù)快速遷移到云平臺中，這種模式也很有用，但它可能導(dǎo)致資源使用不足。AWS公司承認(rèn)，通過創(chuàng)建服務(wù)來簡化遷移(CloudEndure遷移和AWS服務(wù)器遷移服務(wù))是一個(gè)困難的問題。不過，為了獲得更好的資源利用率，組織最好考慮重新構(gòu)建云計(jì)算解決方案。
組織采用提升和轉(zhuǎn)移方法，從長遠(yuǎn)來看可能會支付更多的成本，也可能會錯(cuò)過云計(jì)算提供商提供的許多好處。例如，當(dāng)選擇完全管理的AWS Aurora而不是傳統(tǒng)的Postgres實(shí)例時(shí)，組織可以獲得高達(dá)三倍的吞吐量、存儲自動擴(kuò)展和低延遲讀取副本。這可能是Aurora成為目前最受歡迎和發(fā)展最快的AWS云服務(wù)之一的原因。
#2不標(biāo)記資源
如果組織沒有足夠的數(shù)據(jù)來做出明智的決定，則很難改進(jìn)。如果無法跟蹤云計(jì)算資源的性能以及它們產(chǎn)生的成本，那么就很難優(yōu)化其利用率。
最好的做法是根據(jù)項(xiàng)目或組織單位標(biāo)記資源，以將成本正確分配給相應(yīng)的服務(wù)。
#3未能隨著時(shí)間的推移監(jiān)控資源使用情況
管理云計(jì)算結(jié)構(gòu)并不是一次性的過程。這是監(jiān)視和評估組織使用的內(nèi)容、使用方式以及原因的持續(xù)實(shí)踐。也許組織最初對特定應(yīng)用程序的增長的假設(shè)并不完全正確，而進(jìn)行更改可能會顯著地降低成本。
例如一個(gè)過度配置的Kubernetes集群，它的節(jié)點(diǎn)比需要的多很多。在這種情況下，也許轉(zhuǎn)向無服務(wù)器版本(Fargate上的EKS)更有意義。
保持“僵尸”資源不受監(jiān)控的情況并沒有人們想象的那么普遍。在規(guī)模較大的組織中，可能會發(fā)生某些項(xiàng)目由于不完整的移交過程而被放棄并且相應(yīng)的資源保持活動狀態(tài)的情況。
#4總是自己做所有的事情
軟件工程師有時(shí)可能會自己構(gòu)建定制的解決方案和服務(wù)。一種可能更好的方法是首先對現(xiàn)有資源進(jìn)行適當(dāng)?shù)难芯俊＠纾?/div>
•也許不需要在EC2上使用自托管數(shù)據(jù)庫，而是使用完全托管的RDS，這可以幫助更輕松地?cái)U(kuò)展和操作實(shí)例。
•也許不需要這個(gè)自我管理的RabbitMQ實(shí)例，而是可以使用經(jīng)過實(shí)踐檢驗(yàn)的無服務(wù)器消息隊(duì)列SQS。
通常情況下，如果有一個(gè)無服務(wù)器或完全托管的解決方案，那么至少在為自己的解決方案投入過多的時(shí)間和精力以進(jìn)行維護(hù)之前，先考慮采用這些方案是有意義的。
#5只使用自己熟悉的工具
在閱讀Reddit或博客的一些文章時(shí)，經(jīng)?？吹皆S多工程師不愿意使用無服務(wù)器或容器編排平臺，因?yàn)樗麄冎恢繣C2和人工管理的服務(wù)器。他們認(rèn)為有些新技術(shù)可能只是曇花一現(xiàn)，因此沒有必要改變自己的方式。這意味著轉(zhuǎn)移到容器編排平臺、無服務(wù)器和其他云服務(wù)是沒有價(jià)值的。這似乎是一種謹(jǐn)慎的方法。最好挑戰(zhàn)一下這種假設(shè)，用清楚的事實(shí)、成本和性能基準(zhǔn)來判斷新技術(shù)的可用性，而不是對新技術(shù)持懷疑態(tài)度。
#6沒有使用無服務(wù)器和容器編排平臺
如果要為所管理的每個(gè)服務(wù)和工具創(chuàng)建一個(gè)EC2實(shí)例，則可能會陷入維護(hù)的噩夢。但是，如果將每個(gè)服務(wù)部署到Kubernetes(EKS)或Fargate(ECS)集群的容器中，那么由于容器的動態(tài)端口映射和更緊湊的資源利用(例如共享層)，可以將更多的資源分配到單個(gè)服務(wù)器實(shí)例中。
容器編排平臺將幫助你確保實(shí)例之間的負(fù)載平衡，并使工作負(fù)載保持健康。這在某種程度上消除了猜測容量的情況。你可以指定在任何時(shí)候應(yīng)該運(yùn)行多少個(gè)容器實(shí)例，并且控制平臺將確保它發(fā)生，就像你定義的那樣。
如果可以輕松地在許多容器或無服務(wù)器資源之間實(shí)現(xiàn)負(fù)載平衡，那么不必再猜測哪種EC2或RDS實(shí)例大小適合自己的用例。
#7不考慮總擁有成本
如果只考慮硬件或服務(wù)成本，你可能最終會認(rèn)為許多資源在內(nèi)部部署設(shè)施中運(yùn)行可能更具成本效益。但是，如果加上額外的維護(hù)、升級和員工管理這些服務(wù)器的成本，那么情況就完全不同了。
#8沒有長遠(yuǎn)的思考
如果只根據(jù)當(dāng)前情況擴(kuò)展資源，則可能無法考慮到未來需求的變化。如果組織的業(yè)務(wù)和數(shù)據(jù)增長更好怎么辦?如果結(jié)果正好相反呢?你的應(yīng)用程序仍然易于更改，并適應(yīng)未知的未來情況嗎?最后，你是否能夠找到并保留足夠的員工以長期滿足這些需求?
#9過度配置 “以防萬一”
如果你要保證萬無一失，可能會過度配置所有東西，以確保為應(yīng)對使用高峰期做好準(zhǔn)備。如果你可以根據(jù)過去的使用模式來證明過度配置的合理性，則這是一個(gè)很好的策略。但是，如果是出于直覺，這樣做可能是一個(gè)錯(cuò)誤的策略。
從某種意義上說，云服務(wù)可以提供彈性，你可以在集群中添加節(jié)點(diǎn)，在更多容器之間負(fù)載均衡工作負(fù)載，或者在需要時(shí)增加CPU數(shù)量或內(nèi)存。如果配置和監(jiān)視正確，則無需過多配置。這并不是說正確調(diào)整大小很容易，但是有了良好的流程和自動化，這是可行的，并且可以顯著節(jié)省成本，尤其是在大規(guī)模運(yùn)行大量資源時(shí)。
#10選擇錯(cuò)誤的數(shù)據(jù)存儲
有時(shí)，瓶頸不是計(jì)算資源不足，而是數(shù)據(jù)存儲選擇不當(dāng)。最好考慮一下：
•你是否需要豐富的查詢語言(SQL)，還是應(yīng)用程序只需簡單的鍵值存儲即可(例如DynamoDB)。
•首先是否需要數(shù)據(jù)庫，也許一個(gè)簡單的S3數(shù)據(jù)轉(zhuǎn)儲就足夠了。
它自然取決于用例，但是數(shù)據(jù)庫通常是構(gòu)成任何可擴(kuò)展架構(gòu)的主要瓶頸。
如何解決云計(jì)算資源大小問題?
提高云計(jì)算資源利用率的一種可能的解決方案是采用自動化技術(shù)。例如，你可以使用Dashbird跟蹤資源不足和資源過剩的情況，并獲得有關(guān)它們的通知。使用結(jié)構(gòu)良好的lens儀表板時(shí)，可以發(fā)現(xiàn)，具有EC2實(shí)例類型的ECS集群在過去一小時(shí)內(nèi)的CPU利用率超過90%。
然后，可以深入到特定的時(shí)間間隔，并進(jìn)一步檢查出現(xiàn)這一使用峰值的原因。
同時(shí)，另一種容器服務(wù)可能會被超額配置，可能會浪費(fèi)成本。有了這些信息，你可以根據(jù)實(shí)際使用模式優(yōu)化資源配置。
結(jié)論
以上研究了調(diào)整云計(jì)算資源大小時(shí)的常見問題，并討論了如何避免這些問題，并真正從云計(jì)算的彈性中受益。通過使用容器編排平臺、無服務(wù)器和完全托管的解決方案，以及隨著時(shí)間的推移持續(xù)監(jiān)視使用模式，可以優(yōu)化云計(jì)算架構(gòu)的性能和成本。
版權(quán)聲明：本文為企業(yè)網(wǎng)D1Net編譯，轉(zhuǎn)載需注明出處為：企業(yè)網(wǎng)D1Net，如果不注明出處，企業(yè)網(wǎng)D1Net將保留追究其法律責(zé)任的權(quán)利。
京公網(wǎng)安備 11010502049343號