彈性架構(gòu)

幾周前，我獲得了一個(gè)難得的機(jī)會(huì)，可以在基礎(chǔ)設(shè)施領(lǐng)域中沾沾自喜。 在JVM內(nèi)部的深入了解下，我每天的工作經(jīng)歷發(fā)生了有趣的變化，我想與您分享動(dòng)機(jī)和成果。 希望它可以啟發(fā)類(lèi)似的問(wèn)題類(lèi)別。

背景

我將從解釋需要解決方案的上下文開(kāi)始。 如果您知道Plumbr性能監(jiān)控的全部?jī)?nèi)容，則可以跳過(guò)此部分。 對(duì)于其他所有人，我們Plumbr都在構(gòu)建性能監(jiān)控解決方案。 我們的方法是獨(dú)特的，因?yàn)槲覀冎荚谑顾行阅軉?wèn)題都具有源代碼的根本原因。

這種問(wèn)題的較復(fù)雜類(lèi)別之一是其根源隱藏在Java內(nèi)存分配和管理中。 此類(lèi)別中的問(wèn)題包括：

• 內(nèi)存不足；
• 面臨太頻繁/太長(zhǎng)時(shí)間的GC暫停；
• 嘗試減少應(yīng)用程序的內(nèi)存占用。

我們對(duì)此類(lèi)問(wèn)題的解決方案是建立在對(duì)對(duì)象圖進(jìn)行快照并從那里公開(kāi)最需要內(nèi)存的數(shù)據(jù)結(jié)構(gòu)的基礎(chǔ)上的。 結(jié)果，您將獲得運(yùn)行時(shí)透明性，以了解JVM堆中實(shí)際發(fā)生的情況：

上面是我們監(jiān)視自己的服務(wù)時(shí)發(fā)現(xiàn)的示例。 我們可以看到，在重大GC暫停后的某個(gè)時(shí)刻，我們占據(jù)了70％以上的舊一代。 老一代的高占用率通常會(huì)導(dǎo)致長(zhǎng)時(shí)間的GC暫停，因此Plumbr捕獲了快照以顯示其中的實(shí)際內(nèi)容。

在這種特殊情況下，我們發(fā)現(xiàn)包含ProbeDataProcessingTasks的處理隊(duì)列的大小已增長(zhǎng)到近千兆字節(jié)。 了解應(yīng)歸咎于哪些數(shù)據(jù)結(jié)構(gòu)使解決該問(wèn)題變得微不足道。 結(jié)果，GC暫停的頻率和持續(xù)時(shí)間保持不變。

但是，拍攝這些快照有些昂貴。 捕獲快照所需的時(shí)間取決于堆中對(duì)象的數(shù)量以及它們之間的引用。 我們的代理商會(huì)仔細(xì)安排快照的時(shí)間，以避免自己成為性能瓶頸。

綜上所述：在我們的基礎(chǔ)架構(gòu)中，此特殊功能導(dǎo)致不可預(yù)測(cè)的內(nèi)存快照流入。 更糟糕的是，快照的大小也是不可預(yù)測(cè)的。 有時(shí)我們每小時(shí)可能只收到一個(gè)微小的快照，然后突然間，我們?cè)诤芏痰臅r(shí)間內(nèi)被許多10 + G快照轟炸：

我們最初的解決方案存在問(wèn)題

我們構(gòu)建的第一個(gè)解決方案是專(zhuān)用的微服務(wù)，用于處理快照的傳入流。 我們立即開(kāi)始面臨問(wèn)題。 首先，我們還無(wú)法估算這些快照的大小。 最初配置的4G內(nèi)存還遠(yuǎn)遠(yuǎn)不足以處理流向我們的較大快照。 要分析快照，我們需要將對(duì)象圖加載到內(nèi)存中，因此快照越大，分析所需的RAM越多。

因此，我們需要從亞馬遜購(gòu)買(mǎi)更大的計(jì)算機(jī)。 突然之間，微服務(wù)不再是微服務(wù)了。 正如我們很快發(fā)現(xiàn)的那樣，在您的每月賬單中實(shí)際上可以看到保持m4.10xlarge實(shí)例嗡嗡作響的24×7。 除了非常昂貴外，機(jī)器有99％的時(shí)間幾乎處于空閑狀態(tài)–發(fā)生的巨大堆快照很少見(jiàn)，因此經(jīng)常會(huì)超額配置10倍來(lái)處理偶爾出現(xiàn)的峰值。

此外，分析持續(xù)時(shí)間很快就成為瓶頸。 快照需要10秒鐘到數(shù)十分鐘的時(shí)間來(lái)分析每個(gè)快照，因此當(dāng)在短時(shí)間內(nèi)到達(dá)多個(gè)大型快照時(shí)，隊(duì)列等待時(shí)間成為一個(gè)問(wèn)題：

解決方案要求

了解了問(wèn)題之后，下一步就是將問(wèn)題簡(jiǎn)化為解決方案的要求：

• 分析任務(wù)不應(yīng)在隊(duì)列中等待數(shù)小時(shí)。 我們應(yīng)該能夠并行處理它們。 每當(dāng)一個(gè)巨大的快照到達(dá)并且需要很長(zhǎng)時(shí)間進(jìn)行分析時(shí)，其他快照就不應(yīng)等待它完成。
• 對(duì)于每個(gè)快照，我們可以估計(jì)執(zhí)行分析所需的堆空間。 我們希望使用盡可能多的資源，而不會(huì)過(guò)度配置基礎(chǔ)架構(gòu)。

對(duì)于以前建立過(guò)彈性環(huán)境的人來(lái)說(shuō)，解決方案的要求可能會(huì)很明顯。 對(duì)于那些還沒(méi)有的人，我將在下一部分中介紹解決方案體系結(jié)構(gòu)和實(shí)現(xiàn)的關(guān)鍵案例。

建立解決方案

這些要求有效地指示我們，我們應(yīng)該維護(hù)一個(gè)彈性的基礎(chǔ)架構(gòu)，而不是一個(gè)單獨(dú)的專(zhuān)用實(shí)例。 實(shí)例應(yīng)按需生成，實(shí)例類(lèi)型應(yīng)與接收到的快照的大小相對(duì)應(yīng)。

因此，我們繼續(xù)將快照分析代碼包裝到docker容器中，并利用AWS ECS將此類(lèi)容器用作集群中的任務(wù)。 這樣做之后，我們偶然發(fā)現(xiàn)了第一個(gè)問(wèn)題：向外擴(kuò)展并不像預(yù)期的那么瑣碎。

僅僅為每個(gè)分析生成一個(gè)適當(dāng)大小的新實(shí)例并隨后立即終止的天真的方法被證明是一個(gè)壞主意。 啟動(dòng)實(shí)例最多可能需要五分鐘，具體取決于實(shí)例類(lèi)型。 此外，AWS每小時(shí)執(zhí)行一次計(jì)費(fèi)，因此，讓一個(gè)實(shí)例運(yùn)行60分鐘比運(yùn)行十個(gè)實(shí)例每6分鐘便宜十倍。

在這種情況下，典型的方法是使用AWS 自動(dòng)擴(kuò)展組。 顯然，這不適合我們，因?yàn)锳WS無(wú)法根據(jù)ECS任務(wù)所需的內(nèi)存量自動(dòng)生成實(shí)例。 您無(wú)法將任務(wù)提交給ECS集群，除非該集群已經(jīng)有足夠的資源來(lái)容納它。

我們的解決方案是根據(jù)分析任務(wù)所需的內(nèi)存量將其劃分為多個(gè)存儲(chǔ)桶，并為每個(gè)存儲(chǔ)桶分配一個(gè)單獨(dú)的群集。 收到新快照后，我們檢查目標(biāo)群集是否有足夠的可用資源來(lái)運(yùn)行任務(wù)。 如果沒(méi)有，我們將在其自動(dòng)擴(kuò)展組中增加所需的實(shí)例數(shù)。 然后，AWS自動(dòng)啟動(dòng)一個(gè)適當(dāng)大小的新實(shí)例。 因此，從本質(zhì)上講，我們最終得到了六個(gè)存儲(chǔ)桶，每個(gè)存儲(chǔ)桶包含適當(dāng)大小的實(shí)例，可以根據(jù)需求進(jìn)行擴(kuò)展：

第二個(gè)問(wèn)題是通過(guò)擴(kuò)展來(lái)解決自身問(wèn)題。用于擴(kuò)展的標(biāo)準(zhǔn)CloudWatch警報(bào)基于集群利用不足的情況。 如果集群閑置了足夠長(zhǎng)的時(shí)間，我們會(huì)減少所需實(shí)例的數(shù)量。 “空閑”是根據(jù)群集中消耗的內(nèi)存計(jì)算的，如果在45分鐘內(nèi)內(nèi)存使用率一直低于指定的閾值，則立即擴(kuò)展并終止額外的實(shí)例。

這里也有一個(gè)警告：在自動(dòng)擴(kuò)展組中進(jìn)行擴(kuò)展時(shí)，AWS選擇一種特殊的方式來(lái)終止實(shí)例。 例如，如果一個(gè)群集有兩個(gè)實(shí)例，其中一個(gè)實(shí)例處于空閑狀態(tài)，而另一個(gè)實(shí)例正在運(yùn)行分析，則完全有可能該活動(dòng)實(shí)例將被殺死而不是空轉(zhuǎn)一個(gè)實(shí)例。

放大問(wèn)題的解決方案是，在分析期間，我們?yōu)閳?zhí)行該擴(kuò)展的特定實(shí)例設(shè)置了放大保護(hù) 。 開(kāi)始分析時(shí)，我們?cè)O(shè)置標(biāo)志，并在完成后將其刪除。 自動(dòng)縮放不會(huì)終止受保護(hù)而無(wú)法放大的實(shí)例。 最后一點(diǎn)就足夠了，從那以后我們就開(kāi)始平穩(wěn)運(yùn)行。

找到了兩個(gè)問(wèn)題的解決方案，我們得到了預(yù)期的結(jié)果。 更改后，隊(duì)列中等待的時(shí)間現(xiàn)在如下所示：

帶走

這是少數(shù)情況下的一種，您可以提高應(yīng)用程序的性能，并減少容量需求以降低成本。 在大多數(shù)情況下，您必須為提高性能付出很大的代價(jià)，因此人們可以欣賞這些時(shí)刻。 現(xiàn)在，按需計(jì)算比以往任何時(shí)候都容易，因此也許您可以以類(lèi)似的方式優(yōu)化應(yīng)用程序。

而且，如果除了彈性基礎(chǔ)架構(gòu)的有趣案例之外，該帖子還引發(fā)了人們對(duì)如何獲得應(yīng)用程序內(nèi)存使用透明性的興趣，那就繼續(xù)免費(fèi)試用Plumbr試用一下。

翻譯自: https://www.javacodegeeks.com/2016/05/elastic-infrastructure-practice.html

彈性架構(gòu)

總結(jié)

以上是生活随笔為你收集整理的弹性架构_实践中的弹性基础架构的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。