Inmagine Group遷移到AWS以支持增長并提高運營效率

INMAGINE是一個全球性的創(chuàng)意生態(tài)系統(tǒng)，由設(shè)計，技術(shù)創(chuàng)新和專注于創(chuàng)意內(nèi)容和服務(wù)的企業(yè)家精神提供支持。該集團已進入市場20多年，在美國，歐洲和亞洲擁有強大的業(yè)務(wù)。

他們廣泛的SaaS業(yè)務(wù)模型包括123RF.com，Pixlr.com和Designs.ai等領(lǐng)先品牌，這些品牌使設(shè)計師和非設(shè)計師可以更聰明，更快，更輕松地進行設(shè)計。他們提供了一個創(chuàng)新的生態(tài)系統(tǒng)，使設(shè)計人員可以訪問即用型庫存內(nèi)容，從照片編輯到創(chuàng)建引人入勝的基于視頻的工作流程，以為其各自的創(chuàng)意項目制作幾乎任何類型的創(chuàng)意內(nèi)容。

不可預(yù)測的流量模式，不斷增長的需求和DDoS攻擊挑戰(zhàn)

Inmagine開始了他們的數(shù)字之旅，將他們的應(yīng)用程序托管在數(shù)據(jù)中心中。隨著時間的流逝，隨著它們在全球范圍內(nèi)的持續(xù)增長，出現(xiàn)了不可預(yù)期的消費者流量模式以及意外的分布式拒絕服務(wù)（DDoS）攻擊。當(dāng)時，他們意識到，傳統(tǒng)的預(yù)測和管理數(shù)據(jù)中心計算能力的操作模型不是可持續(xù)的模型，從而導(dǎo)致站點可靠性問題，并增加了應(yīng)用程序性能下降的事件。除此之外，管理存儲容量是另一個主要問題，因為團隊花費了無數(shù)小時來優(yōu)化和維護存儲基礎(chǔ)架構(gòu)。因此，隨著團隊在計算能力和人員上的過度投資以管理不斷增長的基礎(chǔ)架構(gòu)，這些問題導(dǎo)致了更高的運營成本。

遷移到AWS云以提高運營彈性和效率

由于迫切需要為客戶提供最佳體驗，因此，AWS云成為團隊進行探索的有吸引力的選擇，其主要考慮因素是彈性，安全性和成本效益。

Inmagine選擇在AWS Cloud上托管其Web應(yīng)用程序，內(nèi)容和搜索引擎，以利用以下優(yōu)勢：

a）AWS全球和彈性基礎(chǔ)架構(gòu)

考慮到正常運行時間是一個關(guān)鍵因素，Web應(yīng)用程序在跨多個可用區(qū)（AZ）的AWS Application Load Balancer（AWS ALB）之后進行架構(gòu)，并結(jié)合了EC2自動恢復(fù)功能，可從基礎(chǔ)硬件故障中恢復(fù)。該團隊還計劃重新構(gòu)造其Web應(yīng)用程序，以采用Predictive Scaling來管理不斷發(fā)展的消費者流量。

另一個重要的考慮因素是卸載存儲管理。使用Amazon S3，團隊無需擔(dān)心其存儲基礎(chǔ)架構(gòu)的容量，可用性或可靠性。Amazon S3的生命周期管理和庫存報告簡化了存儲管理。這些功能使團隊可以根據(jù)歷史請求模式以較少的工作量執(zhí)行家政活動，并使用S3對象類對成本進行優(yōu)化。

b）DDoS保護

花費了無數(shù)時間進行研究，以針對其數(shù)據(jù)中心中的DDoS增強其系統(tǒng)，從而導(dǎo)致購買了基于硬件的防火墻，該防火墻無法隨著消費者流量的增長而擴展。通過將其動態(tài)內(nèi)容流量遷移到Amazon Cloudfront和AWS Web Application Firewall（WAF），他們也獲得了AWS Shield，從而抵御常見的以及第3層和第4層攻擊，例如SYN/UDP泛洪和反射攻擊。此外，AWS WAF在Web層提供了針對第7層攻擊的各種保護，例如基于速率的黑名單，保護Web應(yīng)用程序免受暴力登錄嘗試，不良機器人等攻擊。該團隊依靠AWS WAF托管規(guī)則來簡化復(fù)雜的規(guī)則管理。

Inmagine如何執(zhí)行遷移

作為Inmagine風(fēng)險管理策略的一部分，遷移在明確定義的階段進行，以最大程度地減少對客戶的影響。以下描述了初始狀態(tài)和遷移階段：

初始狀態(tài)

i）初始狀態(tài)

在進行遷移之前，Inmagine的服務(wù)器托管在其數(shù)據(jù)中心中，在那里他們具有本地負(fù)載均衡器，Web應(yīng)用程序防火墻，Web服務(wù)器，數(shù)據(jù)庫，elasticsearch和為網(wǎng)站提供支持的存儲基礎(chǔ)結(jié)構(gòu)。在應(yīng)用程序方面，123rf.com是基于面向服務(wù)的體系結(jié)構(gòu)（SOA）設(shè)計的，在該體系結(jié)構(gòu)中，應(yīng)用程序已分發(fā)到服務(wù)中，例如付款，搜索，照片詳細(xì)信息，結(jié)帳等。這些服務(wù)托管在多個虛擬機上，某些服務(wù)擁有自己的數(shù)據(jù)庫，同時共享一個公共的Elasticsearch集群。第三方CDN提供程序用于將靜態(tài)內(nèi)容傳遞給使用者。Nginx用作入口控制器，用于根據(jù)業(yè)務(wù)需求管理復(fù)雜的URL重寫。

ii）評估階段

在此階段，Inmagine團隊與AWS團隊緊密合作，以制定全面的遷移計劃，其目標(biāo)是將安全性，可靠性和性能作為優(yōu)先事項，以最大程度地減少對業(yè)務(wù)運營的潛在干擾。評估的領(lǐng)域包括：

a）建立基準(zhǔn)環(huán)境，以實現(xiàn)對AWS Cloud中計費，安全性和工作負(fù)載管理的治理

b）通過彈性的高性能網(wǎng)絡(luò)連接最大程度地降低遷移期間性能下降的風(fēng)險

c）為123rf.com中的每個服務(wù)建立性能基準(zhǔn)，以快速識別應(yīng)用程序性能中的偏差

d）識別在AWS云上可能存在兼容性問題，可能導(dǎo)致應(yīng)用程序降級或停機的應(yīng)用程序服務(wù)

e）確定一種遷移方法，該方法可在遷移時減輕業(yè)務(wù)影響的風(fēng)險

Inmagine團隊有兩種選擇來進行遷移。

a）在AWS上線之前進行完全遷移：保留消費者流量到本地數(shù)據(jù)中心。在將客戶流量轉(zhuǎn)移到AWS云之前，請遷移123rf.com中的所有服務(wù)。

b）逐步遷移并立即在AWS上啟用關(guān)鍵服務(wù)：遷移選定的關(guān)鍵服務(wù)并將其部署在AWS上。使用Nginx作為入口控制器將消費者流量轉(zhuǎn)移到AWS，將請求定向到整個AWS Direct Connect或AWS上的服務(wù)。其余的本地服務(wù)將經(jīng)過測試并移至AWS。

團隊決定采用第二種選擇，即在123rf.com中的服務(wù)將在AWS云及其本地數(shù)據(jù)中心上運行，同時進行應(yīng)用程序測試和遷移工作。這種方法使團隊能夠利用生產(chǎn)流量快速測試遷移的服務(wù)，并將這些經(jīng)驗應(yīng)用于其他服務(wù)。有效地，這種方法還將解決他們與容量和DDoS攻擊有關(guān)的直接業(yè)務(wù)問題。

iii）遷移階段

為了使123rf.com同時在兩個站點上運行，需要一個高速彈性網(wǎng)絡(luò)來保持站點的性能。Inmagine已部署并徹底測試了以下AWS基礎(chǔ)架構(gòu)，以作為支持整個遷移的核心組件：

a）建立AWS Direct Connect是為了提供高網(wǎng)絡(luò)吞吐量專用線并最小化網(wǎng)絡(luò)延遲以支持兩個站點之間的實時數(shù)據(jù)庫事務(wù)。目標(biāo)是將網(wǎng)絡(luò)延遲保持在20ms以下。

b）建立了從數(shù)據(jù)中心到AWS VPC的Site to Site VPN隧道（基于pfSense構(gòu)建），以充當(dāng)AWS Direct Connect的備份。

c）實施AWS Transit Gateway是為了簡化跨多個連接點的網(wǎng)絡(luò)連接（AWS VPN，AWS Direct Connect和AWS VPC安全地結(jié)合在一起。）

d）部署了AWS Edge Services（例如Amazon Cloudfront，AWS WAF），以使其動態(tài)內(nèi)容更貼近客戶，并保護其網(wǎng)站免受網(wǎng)絡(luò)攻擊。

e）Nginx部署在AWS上作為入口控制器，具有重寫規(guī)則，該規(guī)則檢查報頭并將其添加到傳入的HTTP請求中。這些請求將定向到本地或AWS Cloud上駐留的服務(wù)

f）數(shù)據(jù)庫只讀副本已遷移到AWS以提供讀取流量，而寫入流量則通過AWS Direct Connect發(fā)送到數(shù)據(jù)中心。此策略有兩個原因。首先，123rf.com是一個內(nèi)容繁重的網(wǎng)站，因此將被大量閱讀。在AWS上擁有數(shù)據(jù)庫讀取副本將減少查看器對Web應(yīng)用程序的響應(yīng)時間。其次，通過將寫數(shù)據(jù)庫保留在本地，如果網(wǎng)絡(luò)出現(xiàn)問題，團隊可以輕松地將流量從AWS回滾到數(shù)據(jù)中心。

g）作為Inmagine的AWS云治理策略的一部分，關(guān)鍵工作負(fù)載（例如123rf.com）已部署在其自己的Amazon VPC和AWS賬戶中。

該團隊還依靠多個性能儀表板在遷移過程中對系統(tǒng)具有完全可見性：

a）NewRelic上的自定義應(yīng)用程序性能儀表板，用于基于其各自的服務(wù)級別目標(biāo)（SLO），使用不同的警報策略來監(jiān)視123rf.com中每個服務(wù)的后端應(yīng)用程序響應(yīng)時間。每個123rf.com服務(wù)都經(jīng)過檢測，以識別是否存在依賴于應(yīng)用程序的資源（如第三方API或數(shù)據(jù)存儲）的瓶頸。

b）除此之外，該團隊還使用NewRelic的實時使用監(jiān)控（RUM）監(jiān)控了消費者的瀏覽器加載時間，以全面了解服務(wù)器端和客戶端的性能。

c）Network Performance Dashboard構(gòu)建在AWS Cloudwatch上，以監(jiān)控Direct Connect鏈接的運行狀況和利用率

回滾策略：

回滾策略有兩個注意事項：

a）服務(wù)問題：

如果檢測到任何性能問題，則將更新nginx入口控制器，以將請求定向回內(nèi)部部署數(shù)據(jù)中心中運行的服務(wù)。

b）網(wǎng)絡(luò)問題：

如果跨直連和VPN鏈接的任何意外網(wǎng)絡(luò)問題導(dǎo)致停機，請對Amazon Route53進行更新以將流量轉(zhuǎn)移回內(nèi)部負(fù)載均衡器。

經(jīng)營成果

“在過去幾年中，在本地運行我們的Web應(yīng)用程序無疑是一個挑戰(zhàn)，因為我們一直處于困境，是否需要購買更多硬件來支持業(yè)務(wù)增長。

盡管我們清楚地了解了AWS Cloud的好處，但考慮到數(shù)據(jù)中心的龐大空間，決定從內(nèi)部部署環(huán)境遷移當(dāng)然并非易事。

在AWS團隊的支持下，我們能夠制定遷移策略，在遷移的同時保持網(wǎng)站24/7全天候運行?，F(xiàn)在，我們構(gòu)建了123rf.com來應(yīng)對多個可用性區(qū)域中的故障，以及AWS WAF和AWS Shield保護我們的Web應(yīng)用程序。該計劃已將應(yīng)用程序性能下降降低了34％。

不僅如此，借助AWS處理無差別的繁重工作（例如容量管理），我們已經(jīng)能夠花更多的時間為客戶優(yōu)化和創(chuàng)新新功能?？吹轿覀兊男庐a(chǎn)品（例如Designs.ai）利用AWS Cognito和AWS Polly等服務(wù)來使我們能夠更快地構(gòu)建并為我們的客戶提供新的獨特體驗，真是令人興奮。

更令人興奮的是，我們還觀察到了網(wǎng)站性能的整體提高，動態(tài)內(nèi)容頁面的加載時間縮短了25％。Amazon Cloudfront的分布式存在點不僅縮短了客戶到達(dá)AWS網(wǎng)絡(luò)的旅行距離，而且還使我們能夠從系統(tǒng)上卸載TLS握手和持久的連接，從而改善站點的內(nèi)容交付性能”想象集團的成員。

向前走

“我們一直努力保持領(lǐng)先地位，并迅速響應(yīng)客戶的需求。因此，加快我們將新功能更快地推向市場的能力將是我們的下一個目標(biāo)，并且我們相信對應(yīng)用程序進行容器化將有助于我們實現(xiàn)這一目標(biāo)。我們已經(jīng)有我們的工程團隊在Amazon ECS之上的特定用例上構(gòu)建概念證明，并且到目前為止，結(jié)果令人鼓舞。有了容器，我們已經(jīng)看到了更少的與依賴相關(guān)的問題，我們很高興看到它將我們帶到何處?！盝ack Sen說。

作者簡介

Jack Sen是Inmagine Group的集團首席技術(shù)官。他對軟件工程，算法，機器學(xué)習(xí)和創(chuàng)意產(chǎn)品充滿熱情，擁有超過20年的全棧經(jīng)驗。在業(yè)余時間，他喜歡攝影，打羽毛球和鍛煉身體。

Fabian Tan是Amazon Web Services的高級解決方案架構(gòu)師。他對數(shù)據(jù)庫，數(shù)據(jù)分析和機器學(xué)習(xí)充滿熱情，并與馬來西亞開發(fā)人員社區(qū)緊密合作，以幫助他們進行創(chuàng)新。業(yè)余時間，他喜歡與家人在戶外露營，閱讀和玩體育。