調(diào)整云計(jì)算資源大小時(shí)要避免的10個(gè)錯(cuò)誤

組織在將業(yè)務(wù)遷移到云平臺(tái)時(shí)，遇到的最常見(jiàn)的問(wèn)題之一是成本。采用云計(jì)算，組織可以將IT成本從資本支出(硬件設(shè)備和軟件許可的長(zhǎng)期投資)轉(zhuǎn)換為運(yùn)營(yíng)支出，因此選擇正確的云服務(wù)并進(jìn)行正確估算至關(guān)重要。以下將探討在調(diào)整云計(jì)算資源大小時(shí)常見(jiàn)的錯(cuò)誤和陷阱，并討論如何避免，從而真正受益于云計(jì)算的彈性。

1.遵循提升和轉(zhuǎn)移方法

 

提升和轉(zhuǎn)移方法意味著組織可以將工作負(fù)載的副本移動(dòng)到云平臺(tái)中，而只需進(jìn)行少量的更改。即使組織只將部署業(yè)務(wù)快速遷移到云平臺(tái)中，這種模式也很有用，但它可能導(dǎo)致資源使用不足。AWS公司承認(rèn)，通過(guò)創(chuàng)建服務(wù)來(lái)簡(jiǎn)化遷移(CloudEndure遷移和AWS服務(wù)器遷移服務(wù))是一個(gè)困難的問(wèn)題。不過(guò)，為了獲得更好的資源利用率，組織最好考慮重新構(gòu)建云計(jì)算解決方案。

組織采用提升和轉(zhuǎn)移方法，從長(zhǎng)遠(yuǎn)來(lái)看可能會(huì)支付更多的成本，也可能會(huì)錯(cuò)過(guò)云計(jì)算提供商提供的許多好處。例如，當(dāng)選擇完全管理的AWS Aurora而不是傳統(tǒng)的Postgres實(shí)例時(shí)，組織可以獲得高達(dá)三倍的吞吐量、存儲(chǔ)自動(dòng)擴(kuò)展和低延遲讀取副本。這可能是Aurora成為目前最受歡迎和發(fā)展最快的AWS云服務(wù)之一的原因。

2.不標(biāo)記資源

 

如果組織沒(méi)有足夠的數(shù)據(jù)來(lái)做出明智的決定，則很難改進(jìn)。如果無(wú)法跟蹤云計(jì)算資源的性能以及它們產(chǎn)生的成本，那么就很難優(yōu)化其利用率。

最好的做法是根據(jù)項(xiàng)目或組織單位標(biāo)記資源，以將成本正確分配給相應(yīng)的服務(wù)。

3.未能隨著時(shí)間的推移監(jiān)控資源使用情況

 

管理云計(jì)算結(jié)構(gòu)并不是一次性的過(guò)程。這是監(jiān)視和評(píng)估組織使用的內(nèi)容、使用方式以及原因的持續(xù)實(shí)踐。也許組織最初對(duì)特定應(yīng)用程序的增長(zhǎng)的假設(shè)并不完全正確，而進(jìn)行更改可能會(huì)顯著地降低成本。

例如一個(gè)過(guò)度配置的Kubernetes集群，它的節(jié)點(diǎn)比需要的多很多。在這種情況下，也許轉(zhuǎn)向無(wú)服務(wù)器版本(Fargate上的EKS)更有意義。

保持“僵尸”資源不受監(jiān)控的情況并沒(méi)有人們想象的那么普遍。在規(guī)模較大的組織中，可能會(huì)發(fā)生某些項(xiàng)目由于不完整的移交過(guò)程而被放棄并且相應(yīng)的資源保持活動(dòng)狀態(tài)的情況。

4.總是自己做所有的事情

 

軟件工程師有時(shí)可能會(huì)自己構(gòu)建定制的解決方案和服務(wù)。一種可能更好的方法是首先對(duì)現(xiàn)有資源進(jìn)行適當(dāng)?shù)难芯?。例如?/p> 也許不需要在EC2上使用自托管數(shù)據(jù)庫(kù)，而是使用完全托管的RDS，這可以幫助更輕松地?cái)U(kuò)展和操作實(shí)例。 也許不需要這個(gè)自我管理的RabbitMQ實(shí)例，而是可以使用經(jīng)過(guò)實(shí)踐檢驗(yàn)的無(wú)服務(wù)器消息隊(duì)列SQS。

通常情況下，如果有一個(gè)無(wú)服務(wù)器或完全托管的解決方案，那么至少在為自己的解決方案投入過(guò)多的時(shí)間和精力以進(jìn)行維護(hù)之前，先考慮采用這些方案是有意義的。

5.只使用自己熟悉的工具

 

在閱讀Reddit或博客的一些文章時(shí)，經(jīng)?？吹皆S多工程師不愿意使用無(wú)服務(wù)器或容器編排平臺(tái)，因?yàn)樗麄冎恢繣C2和人工管理的服務(wù)器。他們認(rèn)為有些新技術(shù)可能只是曇花一現(xiàn)，因此沒(méi)有必要改變自己的方式。這意味著轉(zhuǎn)移到容器編排平臺(tái)、無(wú)服務(wù)器和其他云服務(wù)是沒(méi)有價(jià)值的。這似乎是一種謹(jǐn)慎的方法。最好挑戰(zhàn)一下這種假設(shè)，用清楚的事實(shí)、成本和性能基準(zhǔn)來(lái)判斷新技術(shù)的可用性，而不是對(duì)新技術(shù)持懷疑態(tài)度。

6.沒(méi)有使用無(wú)服務(wù)器和容器編排平臺(tái)

 

如果要為所管理的每個(gè)服務(wù)和工具創(chuàng)建一個(gè)EC2實(shí)例，則可能會(huì)陷入維護(hù)的噩夢(mèng)。但是，如果將每個(gè)服務(wù)部署到Kubernetes(EKS)或Fargate(ECS)集群的容器中，那么由于容器的動(dòng)態(tài)端口映射和更緊湊的資源利用(例如共享層)，可以將更多的資源分配到單個(gè)服務(wù)器實(shí)例中。

容器編排平臺(tái)將幫助你確保實(shí)例之間的負(fù)載平衡，并使工作負(fù)載保持健康。這在某種程度上消除了猜測(cè)容量的情況。你可以指定在任何時(shí)候應(yīng)該運(yùn)行多少個(gè)容器實(shí)例，并且控制平臺(tái)將確保它發(fā)生，就像你定義的那樣。

如果可以輕松地在許多容器或無(wú)服務(wù)器資源之間實(shí)現(xiàn)負(fù)載平衡，那么不必再猜測(cè)哪種EC2或RDS實(shí)例大小適合自己的用例。

7.不考慮總擁有成本

 

如果只考慮硬件或服務(wù)成本，你可能最終會(huì)認(rèn)為許多資源在內(nèi)部部署設(shè)施中運(yùn)行可能更具成本效益。但是，如果加上額外的維護(hù)、升級(jí)和員工管理這些服務(wù)器的成本，那么情況就完全不同了。

8.沒(méi)有長(zhǎng)遠(yuǎn)的思考

 

如果只根據(jù)當(dāng)前情況擴(kuò)展資源，則可能無(wú)法考慮到未來(lái)需求的變化。如果組織的業(yè)務(wù)和數(shù)據(jù)增長(zhǎng)更好怎么辦?如果結(jié)果正好相反呢?你的應(yīng)用程序仍然易于更改，并適應(yīng)未知的未來(lái)情況嗎?最后，你是否能夠找到并保留足夠的員工以長(zhǎng)期滿足這些需求?

9.過(guò)度配置 “以防萬(wàn)一”

 

如果你要保證萬(wàn)無(wú)一失，可能會(huì)過(guò)度配置所有東西，以確保為應(yīng)對(duì)使用高峰期做好準(zhǔn)備。如果你可以根據(jù)過(guò)去的使用模式來(lái)證明過(guò)度配置的合理性，則這是一個(gè)很好的策略。但是，如果是出于直覺(jué)，這樣做可能是一個(gè)錯(cuò)誤的策略。

從某種意義上說(shuō)，云服務(wù)可以提供彈性，你可以在集群中添加節(jié)點(diǎn)，在更多容器之間負(fù)載均衡工作負(fù)載，或者在需要時(shí)增加CPU數(shù)量或內(nèi)存。如果配置和監(jiān)視正確，則無(wú)需過(guò)多配置。這并不是說(shuō)正確調(diào)整大小很容易，但是有了良好的流程和自動(dòng)化，這是可行的，并且可以顯著節(jié)省成本，尤其是在大規(guī)模運(yùn)行大量資源時(shí)。

10.選擇錯(cuò)誤的數(shù)據(jù)存儲(chǔ)

 

有時(shí)，瓶頸不是計(jì)算資源不足，而是數(shù)據(jù)存儲(chǔ)選擇不當(dāng)。最好考慮一下：

你是否需要豐富的查詢語(yǔ)言(SQL)，還是應(yīng)用程序只需簡(jiǎn)單的鍵值存儲(chǔ)即可(例如DynamoDB)。 首先是否需要數(shù)據(jù)庫(kù)，也許一個(gè)簡(jiǎn)單的S3數(shù)據(jù)轉(zhuǎn)儲(chǔ)就足夠了。

它自然取決于用例，但是數(shù)據(jù)庫(kù)通常是構(gòu)成任何可擴(kuò)展架構(gòu)的主要瓶頸。

如何解決云計(jì)算資源大小問(wèn)題?

 

提高云計(jì)算資源利用率的一種可能的解決方案是采用自動(dòng)化技術(shù)。例如，你可以使用Dashbird跟蹤資源不足和資源過(guò)剩的情況，并獲得有關(guān)它們的通知。使用結(jié)構(gòu)良好的lens儀表板時(shí)，可以發(fā)現(xiàn)，具有EC2實(shí)例類型的ECS集群在過(guò)去一小時(shí)內(nèi)的CPU利用率超過(guò)90%。

然后，可以深入到特定的時(shí)間間隔，并進(jìn)一步檢查出現(xiàn)這一使用峰值的原因。

同時(shí)，另一種容器服務(wù)可能會(huì)被超額配置，可能會(huì)浪費(fèi)成本。有了這些信息，你可以根據(jù)實(shí)際使用模式優(yōu)化資源配置。

結(jié)論

 

以上研究了調(diào)整云計(jì)算資源大小時(shí)的常見(jiàn)問(wèn)題，并討論了如何避免這些問(wèn)題，并真正從云計(jì)算的彈性中受益。通過(guò)使用容器編排平臺(tái)、無(wú)服務(wù)器和完全托管的解決方案，以及隨著時(shí)間的推移持續(xù)監(jiān)視使用模式，可以優(yōu)化云計(jì)算架構(gòu)的性能和成本。

新聞標(biāo)題：調(diào)整云計(jì)算資源大小時(shí)要避免的10個(gè)錯(cuò)誤
標(biāo)題來(lái)源：http://www.muchs.cn/news/204553.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供響應(yīng)式網(wǎng)站、商城網(wǎng)站、搜索引擎優(yōu)化、動(dòng)態(tài)網(wǎng)站、網(wǎng)站制作、ChatGPT

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)