Inmagine Group遷移到AWS以支持增長(zhǎng)并提高運(yùn)營(yíng)效率

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

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

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

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

遷移到AWS云以提高運(yùn)營(yíng)彈性和效率

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

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

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

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

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

b）DDoS保護(hù)

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

Inmagine如何執(zhí)行遷移

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

初始狀態(tài)

i）初始狀態(tài)

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

ii）評(píng)估階段

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

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

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

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

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

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

Inmagine團(tuán)隊(duì)有兩種選擇來(lái)進(jìn)行遷移。

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

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

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

iii）遷移階段

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

a）建立AWS Direct Connect是為了提供高網(wǎng)絡(luò)吞吐量專用線并最小化網(wǎng)絡(luò)延遲以支持兩個(gè)站點(diǎn)之間的實(shí)時(shí)數(shù)據(jù)庫(kù)事務(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）實(shí)施AWS Transit Gateway是為了簡(jiǎn)化跨多個(gè)連接點(diǎn)的網(wǎng)絡(luò)連接（AWS VPN，AWS Direct Connect和AWS VPC安全地結(jié)合在一起。）

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

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

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

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

該團(tuán)隊(duì)還依靠多個(gè)性能儀表板在遷移過(guò)程中對(duì)系統(tǒng)具有完全可見(jiàn)性：

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

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

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

回滾策略：

回滾策略有兩個(gè)注意事項(xiàng)：

a）服務(wù)問(wèn)題：

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

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

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

經(jīng)營(yíng)成果

“在過(guò)去幾年中，在本地運(yùn)行我們的Web應(yīng)用程序無(wú)疑是一個(gè)挑戰(zhàn)，因?yàn)槲覀円恢碧幱诶Ь常欠裥枰?gòu)買更多硬件來(lái)支持業(yè)務(wù)增長(zhǎng)。

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

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

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

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

向前走

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

作者簡(jiǎn)介

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

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