iT邦幫忙

2019 iT 邦幫忙鐵人賽

DAY 27
2
Everything on Azure

三十天.NET❤️Azure漸進式開發專案系列 第 27

三十天.NET與Azure漸進式開發專案(27): 簡單達到動態負載平衡,抵擋惡意流量攻擊

  隨著上線專案的流量增長,開始會遇到效能問題,雖然上線專案可以提前算好預計使用者人數,大概可以推估出平均請求數,但是會遇到以下情況來搗亂:網路爬蟲、惡意流量攻擊,其中又以惡意攻擊為最大問題。

  筆者有過經驗,惡意攻擊的怪客發警告信給公司,大意是:"請貴公司在x月x日前轉xxx金額到xxx帳號,否則將會發動流量攻擊癱瘓伺服器",該類似事件在網路公司來說可以算是常態性問題

  而在大量流量攻擊情況發生時,假如只使用在地端自主建立的伺服器,沒有做什麼特殊設定,基本上只能無助地祈禱對方能仁慈停下攻擊。就算設定IP黑名單機制,對方也可以使用浮動IP攻擊,防止效果非常有限。

  然而在 Azure Web App Service 平台上面遇到類似問題發生時,我們可以使用 相應放大 功能(備註1),動態負載平衡概念來抵擋,當流量攻擊來的時候,Azure偵測到系統資源不夠,會自動添加實體方式,當攻擊結束後自動減少,避免資源浪費,操作方式也很簡單。

備註1.Azure抵擋DDOS建議:延展性設計
延展性是指系統能夠處理負載增加的能力。 您必須將應用程式設計為可水平調整以滿足放大負載的需求,遭遇 DDoS 攻擊時尤其需要。


方式

【第一步】選擇App Service > 相應放大(App Service方案) > 啟用自動調整規模
2018-11-01.23.38.29-image.png

注意需要使用 S1 以上的方案,否則會出現以下錯誤
2018-11-01.23.35.07-image.png

【第二步】選擇好,需要的最小、最大個體數量。(個體以多出一台同樣環境的電腦分攤流量概念想理解就可以)。
2018-11-06.11.59.49-image.png

【第三步】選好增加個體數量條件,舉例:"CPU使用率達到70%以上的時候,新增1個體分攤流量"。
這邊要注意,除了選好增加個體邏輯外,一定要添加減少個體邏輯,不然系統不會自動調回原本個體數,導致浪費資源、金錢。舉例:"CPU使用率不滿70%時候,減少個體數量"
2018-11-01.23.36.55-image.png

最後保存設定就可以,Azure所有實例上都有一個Load Balancer,流量會在它們之間自動進行負載平衡。不需要虛擬機,也不需要配置任何額外的流量管理器。

而且使用方式就三個步驟,就是這麼簡單!


補充

設定Email通知

想要系統在調整實體個數時候Email通知,可以打開 相應放大 > 通知 > 勾選通知方式 :
2018-11-06.12.02.09-image.png

舉例:個體數從 2 -> 1 可以在指定信箱收到信件,如圖片
2018-11-06.12.02.23-image.png
2018-11-06.13.36.33-image.png
2018-11-06.12.03.12-image.png


測試 Session、實體變數 能否在不同實體間共用

我一開始使用WebAPP負載平衡,會有疑慮說是否跟一般負載平衡一樣,會有多台機器設備之間 Session、Static變數不共用問題

測試結果:Azure可以共用,以下是測試過程:

我寫一個asp.net core的計數器程式,將執行個體技術調為3個,接著測試是否Session、static變數在不同個體存取會得到不同答案。

public class Startup
{
    public void ConfigureServices(IServiceCollection services)
    {
        services.AddDistributedMemoryCache();
        services.AddSession();
    }

    public void Configure(IApplicationBuilder app, IHostingEnvironment env)
    {
        app.UseSession();
        int count = 1;
        app.Run(async (context) =>
        {
            var sessionCount = context.Session.GetInt32("count")==null?2: context.Session.GetInt32("count")+1;
            context.Session.SetInt32("count", (int)sessionCount);
            await context.Response.WriteAsync($"count:{++count/2} / sessionCount:{sessionCount / 2}");
        });
    }
}

經過多次測試後都是共用正確取值,如圖片:
2018-11-06.13.31.05-image.png

這真的很厲害,之前GCP玩過負載平衡踩過共用的坑,解決花費很多時間,現在Azure簡單就解決!


上一篇
三十天.NET與Azure漸進式開發專案(26): 資料庫讀寫分離,實作程式
下一篇
三十天.NET與Azure漸進式開發專案(28): DevOps Project 建立使用、示範專案CI/CD
系列文
三十天.NET❤️Azure漸進式開發專案30

尚未有邦友留言

立即登入留言