調整雲計(jì)算(suàn)資源大(dà)小(xiǎo)時(shí)要避免的10個錯誤

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