組織在將業務遷移到云平臺時，遇到的最常見的問題之一是成本。采用云計算，組織可以將IT成本從資本支出(硬件設備和軟件許可的長期投資)轉換為運營支出，因此選擇正確的云服務并進行正確估算至關重要。以下將探討在調整云計算資源大小時常見的錯誤和陷阱，并討論如何避免，從而真正受益于云計算的彈性。

1.遵循提升和轉移方法

 

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

組織采用提升和轉移方法，從長遠來看可能會支付更多的成本，也可能會錯過云計算提供商提供的許多好處。例如，當選擇完全管理的AWS Aurora而不是傳統的Postgres實例時，組織可以獲得高達三倍的吞吐量、存儲自動擴展和低延遲讀取副本。這可能是Aurora成為目前最受歡迎和發展最快的AWS云服務之一的原因。

2.不標記資源

 

如果組織沒有足夠的數據來做出明智的決定，則很難改進。如果無法跟蹤云計算資源的性能以及它們產生的成本，那么就很難優化其利用率。

最好的做法是根據項目或組織單位標記資源，以將成本正確分配給相應的服務。

3.未能隨著時間的推移監控資源使用情況

 

管理云計算結構并不是一次性的過程。這是監視和評估組織使用的內容、使用方式以及原因的持續實踐。也許組織最初對特定應用程序的增長的假設并不完全正確，而進行更改可能會顯著地降低成本。

例如一個過度配置的Kubernetes集群，它的節點比需要的多很多。在這種情況下，也許轉向無服務器版本(Fargate上的EKS)更有意義。

保持“僵尸”資源不受監控的情況并沒有人們想象的那么普遍。在規模較大的組織中，可能會發生某些項目由于不完整的移交過程而被放棄并且相應的資源保持活動狀態的情況。

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

 

軟件工程師有時可能會自己構建定制的解決方案和服務。一種可能更好的方法是首先對現有資源進行適當的研究。例如：

也許不需要在EC2上使用自托管數據庫，而是使用完全托管的RDS，這可以幫助更輕松地擴展和操作實例。 也許不需要這個自我管理的RabbitMQ實例，而是可以使用經過實踐檢驗的無服務器消息隊列SQS。

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

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

 

在閱讀Reddit或博客的一些文章時，經常看到許多工程師不愿意使用無服務器或容器編排平臺，因為他們只知道EC2和人工管理的服務器。他們認為有些新技術可能只是曇花一現，因此沒有必要改變自己的方式。這意味著轉移到容器編排平臺、無服務器和其他云服務是沒有價值的。這似乎是一種謹慎的方法。最好挑戰一下這種假設，用清楚的事實、成本和性能基準來判斷新技術的可用性，而不是對新技術持懷疑態度。

6.沒有使用無服務器和容器編排平臺

 

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

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

如果可以輕松地在許多容器或無服務器資源之間實現負載平衡，那么不必再猜測哪種EC2或RDS實例大小適合自己的用例。

7.不考慮總擁有成本

 

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

8.沒有長遠的思考

 

如果只根據當前情況擴展資源，則可能無法考慮到未來需求的變化。如果組織的業務和數據增長更好怎么辦?如果結果正好相反呢?你的應用程序仍然易于更改，并適應未知的未來情況嗎?最后，你是否能夠找到并保留足夠的員工以長期滿足這些需求?

9.過度配置 “以防萬一”

 

如果你要保證萬無一失，可能會過度配置所有東西，以確保為應對使用高峰期做好準備。如果你可以根據過去的使用模式來證明過度配置的合理性，則這是一個很好的策略。但是，如果是出于直覺，這樣做可能是一個錯誤的策略。

從某種意義上說，云服務可以提供彈性，你可以在集群中添加節點，在更多容器之間負載均衡工作負載，或者在需要時增加CPU數量或內存。如果配置和監視正確，則無需過多配置。這并不是說正確調整大小很容易，但是有了良好的流程和自動化，這是可行的，并且可以顯著節省成本，尤其是在大規模運行大量資源時。

10.選擇錯誤的數據存儲

 

有時，瓶頸不是計算資源不足，而是數據存儲選擇不當。最好考慮一下：

你是否需要豐富的查詢語言(SQL)，還是應用程序只需簡單的鍵值存儲即可(例如DynamoDB)。 首先是否需要數據庫，也許一個簡單的S3數據轉儲就足夠了。

它自然取決于用例，但是數據庫通常是構成任何可擴展架構的主要瓶頸。

如何解決云計算資源大小問題?

 

提高云計算資源利用率的一種可能的解決方案是采用自動化技術。例如，你可以使用Dashbird跟蹤資源不足和資源過剩的情況，并獲得有關它們的通知。使用結構良好的lens儀表板時，可以發現，具有EC2實例類型的ECS集群在過去一小時內的CPU利用率超過90%。

然后，可以深入到特定的時間間隔，并進一步檢查出現這一使用峰值的原因。

同時，另一種容器服務可能會被超額配置，可能會浪費成本。有了這些信息，你可以根據實際使用模式優化資源配置。

結論

 

以上研究了調整云計算資源大小時的常見問題，并討論了如何避免這些問題，并真正從云計算的彈性中受益。通過使用容器編排平臺、無服務器和完全托管的解決方案，以及隨著時間的推移持續監視使用模式，可以優化云計算架構的性能和成本。

網站題目：調整云計算資源大小時要避免的10個錯誤
轉載源于：http://m.newbst.com/news3/204553.html

成都網站建設公司_創新互聯，為您提供網站建設、網站導航、網站設計、網站收錄、響應式網站、網站改版

廣告

聲明：本網站發布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網站立場，如需處理請聯系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經允許不得轉載，或轉載時需注明來源： 創新互聯