支援靜態 的動態擴展。NET 架構應用程式 - AWS 規範指引
概觀成本影響成本最佳化建議其他資源

本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

支援靜態 的動態擴展。NET 架構應用程式

概觀

將雲端用於應用程式的主要優點之一是彈性，或能夠根據需求擴展運算。這可讓您僅支付所需的運算容量，而不是佈建尖峰用量。網路星期一，其中線上零售商可以快速獲得比正常多出許多倍的流量 （例如，幾分鐘內數千個百分比），這是彈性的良好範例。

如果您要將舊版 .NET Web 應用程式帶到雲端 （例如 ASP。NET 在 上執行的架構應用程式IIS），由於應用程式的狀態性質，可能很難或不可能快速擴展負載平衡伺服器陣列。使用者工作階段資料會儲存在應用程式的記憶體中，通常使用 ASP。NET 工作階段狀態或靜態變數，這些變數包含必須保留的跨請求資料。使用者工作階段親和性通常透過負載平衡器黏性工作階段來維護。

這證明在操作上具有挑戰性。當需要增加容量時，您必須刻意佈建和新增伺服器。這可能是緩慢的程序。在修補或意外故障的情況下停用節點可能會對最終使用者體驗造成問題，因此與受影響節點相關聯的所有使用者都會失去狀態。最好是，這需要使用者再次登入。

透過集中 ASP.NET 應用程式的工作階段狀態，並將自動擴展規則套用至舊版 ASP.NET 應用程式，您可以利用雲端的彈性，並在執行應用程式時可能節省成本。例如，您可以透過運算可擴展性降低成本，但您也可以從可用的不同定價模型中進行選擇，例如減少預留執行個體用量和使用 Amazon Spot 執行個體定價。

兩種常見的技術包括使用 Amazon DynamoDB 作為工作階段狀態提供者，以及使用 Amazon ElastiCache （RedisOSS） 作為 ASP.NET session Store。

下圖顯示使用 DynamoDB 作為工作階段狀態提供者的架構。

DynamoDB 作為工作階段狀態提供者

下圖顯示使用 ElastiCache （Redis OSS） 作為工作階段狀態提供者的架構。

ElastiCache （Redis OSS） 作為工作階段狀態提供者

成本影響

若要判斷生產應用程式擴展的優點，建議您建立實際需求的模型。本節會做出下列假設來建立範例應用程式的模型：

  • 從輪換中新增和移除的執行個體完全相同，不會引入執行個體大小變化。

  • 伺服器使用率絕不會降至兩個作用中伺服器以下，以維持應用程式的高可用性。

  • 伺服器數量會隨流量線性擴展 （也就是說，兩倍的流量需要兩倍的運算量）。

  • 流量會在一個月期間以 6 小時為單位進行建模，一天內的變化和一天 10 倍流量的異常流量峰值 （例如，促銷銷售）。週末流量以基本使用率建模。

  • 夜間流量以基本使用率建模，而平日流量以 4 倍使用率建模。

  • 預留執行個體定價使用一年、無預付定價。一般日間定價使用隨需定價，而爆量需求則使用 Spot 執行個體定價。

下圖說明此模型如何利用 .NET 應用程式中的彈性，而不是佈建峰值用量。這可節省約 68%。

Auto Scaling 成本圖表

如果您使用 DynamoDB 做為工作階段狀態儲存機制，請使用下列參數：

Storage: 20GB
Session Reads: 40 million
Session Writes: 20 million
Pricing Model: On demand

此服務的估計每月費用約為 35.00 美元。

如果您使用 ElastiCache （Redis OSS） 作為工作階段狀態儲存機制，請使用下列參數：

Number of Nodes: 3
Node size: cache.t4g.medium
Pricing Model: 1y reserved

此服務的估計每月費用約為 $91.00。

成本最佳化建議

第一步是在舊版 NET應用程式中實作工作階段狀態。如果您使用 ElastiCache 作為狀態儲存機制，請遵循 AWS SDK for .NET 文件中什麼是 AWS SDK for .NET的指導。如果您使用的是 DynamoDB ，請遵循 ElastiCache 作為 的指南ASP。NET 開發人員工具部落格中的工作階段存放區。 AWS

如果應用程式使用InProc工作階段開頭，請確定您計劃存放在工作階段中的所有物件都可以序列化。若要執行此操作，請使用 SerializableAttribute 屬性來裝飾執行個體會存放在工作階段中的類別。例如：

[Serializable()] 
public class TestSimpleObject { 
public string SessionProperty {get;set;}
}

此外，所有使用中的伺服器之間的 .NET MachineKey 必須相同。這通常是從常見 Amazon Machine Image （） 建立執行個體的情況AMI。例如：

<machineKey
validationKey="some long hashed value"
decryptionKey="another long hashed value"
validation="SHA1"/>

不過，請務必確保如果基礎映像變更，則會使用相同的 .NET Machine 映像進行設定 （可在 IIS或伺服器層級設定）。如需詳細資訊，請參閱 Microsoft 文件中的 SystemWebSectionGroup.MachineKey Property。

最後，您必須判斷將伺服器新增至 Auto Scaling 群組以回應擴展事件的機制。有幾種方法可以完成此操作。我們建議使用以下方法無縫部署 。NET 將應用程式架構至 Auto Scaling 群組中的EC2執行個體：

其他資源