node aws 内存溢出_在AWS Elastic Beanstalk上运行生产Node应用程序的现实
node aws 內存溢出
by Jared Nutt
賈里德·努特(Jared Nutt)
在AWS Elastic Beanstalk上運行生產Node應用程序的現實 (The reality of running a production Node app on AWS Elastic Beanstalk)
從在AWS的ELB平臺上運行生產Node應用程序兩年的經驗教訓 (Lessons learned from 2 years of running a production Node app on AWS’ ELB platform)
前題 (Front-Matter)
Let’s be honest, the AWS pricing calculator is confusing. Part of that is because of the a la carte method of payments AWS offers. This makes trying to give a good quote to a client difficult. Hopefully this article can provide some light on how much it costs to run an app, as well as some ways to reduce cost.
坦白地說， AWS定價計算器令人困惑。 部分原因是因為AWS提供了點菜付款方式。 這使得試圖給客戶良好的報價變得困難。 希望本文能夠提供一些有關運行應用程序的成本的信息，以及一些降低成本的方法。
運行應用程序的實際成本 (The Real Cost of Running an App)
I’ve been managing a node web-app on ELB for about two years now. The first year was great, they gave you everything for free (mostly)! After that, you have to start paying for stuff, like EC2 instances.
我已經在ELB上管理節點Web應用程序大約兩年了。 第一年很棒，他們免費為您提供了一切(主要是)！ 之后，您必須開始支付費用，例如EC2實例。
This article will focus on my specific app requirements, which is a node based express app that is hosted on Elastic Beanstalk.
本文將重點介紹我的特定應用程序需求，這是托管在Elastic Beanstalk上的基于節點的快速應用程序。
For full details about the build, see my previous article here.
有關構建完整的詳細信息，請參閱我以前的文章在這里 。
分解 (Breakdown)
This is what I’m currently running on AWS:
這是我當前在AWS上運行的內容：
Single EBS Environment (U.S. West Region):
單一EBS環境(美國西部地區)：
- 1 Classic Load Balancer 1個經典負載均衡器
- 1 t2.micro EC2 instance 1個t2.micro EC2實例
- S3 Bucket that holds images (7 GB at time of writing) S3存儲圖像的存儲桶(寫入時為7 GB)
- 1 Route 53 Hosted Zone 1 Route 53托管區
$18 (Load Balancer) + $5 (EC2 with an RI) + $0.50 (Route 53) + $0.17 (S3) + $0.21 (Data Transfer) = Roughly $25 a month.
$ 18 (負載均衡器)+ $ 5 (帶RI的EC2)+ $ 0.50 (Route 53)+ $ 0.17 (S3)+ $ 0.21 (數據傳輸)=每月大約$ 25 。
Additionally, I host a MongoDB elsewhere, so if you plan on hosting a DB on AWS, that will incur additional costs. Let’s break down the various costs.
此外，我在其他地方托管MongoDB，因此，如果您計劃在AWS上托管數據庫，則會產生額外的費用。 讓我們分解各種費用。
負載均衡器 (Load Balancer)
This is the most expensive part of the stack. It costs:
這是堆棧中最昂貴的部分。 它的成本：
- $0.025 per Classic Load Balancer-hour (or partial hour) 每個經典負載均衡器小時(或不足一小時)0.025 USD
- $0.008 per GB of data processed by a Classic Load Balancer Classic Load Balancer處理的每GB數據$ 0.008
That means, if you run your app 24 hours a day, it will cost roughly $18 + data charges, every month.
這意味著，如果您一天24小時運行您的應用，則每月將花費大約18美元+數據費用。
EC2實例 (EC2 Instance)
On-Demand EC2 instances are more expensive than they should be. To save some money here, refer to the section below about Reserved EC2 Instances. In case you were wondering, it would cost $8.40 to run the same type of EC2 instance as mentioned above, on-demand.
按需EC2實例比其應有的價格昂貴。 要在此處節省一些資金，請參閱以下有關預留的EC2實例的部分。 如果您想知道，按需運行上述類型的EC2實例將花費$ 8.40。
S3 (S3)
I have a couple S3 buckets. One for my static home page, one for holding images and one for holding the application version. As far as I know, ELB automatically creates the one for managing the application versions.
我有幾個S3水桶。 一個用于我的靜態主頁，一個用于保存圖像，一個用于保存應用程序版本。 據我所知，ELB自動創建一個用于管理應用程序版本的版本。
The S3 is pretty cheap, so I’m not too worried about trying to nickel and dime it, but there are ways to save money via their Glacier system.
S3相當便宜，所以我不太擔心嘗試鍍鎳和變角，但是有很多方法可以通過其Glacier系統省錢。
數據庫 (Database)
I host my MongoDB DB at mLab, which is going away soon. So I’ll update this when I sort out how much that is actually gonna cost once I’m forced to move over to Mongo’s Atlas.
我將我的MongoDB數據庫托管在mLab上，該數據庫即將消失。 因此，當我確定我被迫轉到Mongo的地圖集后實際要花費多少時，我將對其進行更新。
預留的EC2實例 (Reserved EC2 Instances)
Let’s talk about Reserved Instances (RI). Amazon’s convoluted billing system is the most confusing part about managing anything on AWS. Reserved Instances can alleviate some of the cost, but are way too confusing.
讓我們談談保留實例(RI)。 亞馬遜繁雜的賬單系統是有關在AWS上管理任何內容的最令人困惑的部分。 預留實例可以減輕一些開銷，但是太令人困惑了。
After a lot of reading and talking with the AWS customer service, this is what I sorta figured out.
經過大量的閱讀和與AWS客戶服務的交談之后，我才想到了這一點。
First, there are two different ways you can reserve where the RI is: Regional and Availability Zone. Regional means, it is specific to one of the main regions, eg. us-west-2 (Oregon). The availability zone (AZ) is specific to a zone within that region, e.g. us-west-2a (Oregon).
首先，您可以通過兩種不同的方式來保留RI的位置：區域和可用區。 地區性手段，它特定于主要地區之一，例如。 us-west-2(俄勒岡州)。 可用性區(AZ)是特定的某個區域，區域內，例如，美國西-2(俄勒岡州)。
I bought an RI within us-west-2 and it was automatically applied to my instance running in that area. If you buy one within the AZ, it will only apply to the specific AZ, e.g. us-west-2a, so if ELB spins up an EC2 instance in us-west2b, you’re out of luck.
我在us-west-2內購買了一個RI，它已自動應用于在該區域運行的實例。 如果您在AZ中購買一個，它將僅適用于特定的AZ，例如us-west-2a，因此，如果ELB在us-west2b中啟動EC2實例，您將不走運。
Additionally, there are “standard” and “convertible” types of RIs. I’m not 100% on what that means, but from what I understand convertible is more flexible on what you can swap it to, but more expensive.
此外，還有“標準”和“可轉換”類型的RI。 我不是100％的意思，但據我了解，敞篷車在您可以換用的東西上更靈活，但價格更高。
Finally, there are three types of payment types: No Up-front, partial Up-front, All Up-Front. This is pretty straightforward, you either pay nothing, some or all when you reserve the instance. There is no cost benefit, that I can see. However, as a new account, you most likely can’t do no up-front.
最后，有三種付款類型：無預付款，部分預付款，全部預付款。 這非常簡單，保留實例時，您無需支付任何費用或全部或全部。 我可以看到沒有成本效益。 但是，作為一個新帳戶，您很可能無法無所事事。
Per AWS Support:
每個AWS支持：
No Upfront Reserved Instances (RIs) can pose a significant billing risk to new accounts, as they’re a contractual obligation to pay monthly for the entire term of the RI. For this reason, new accounts and lightly used accounts are unable to sign up for No Upfront RIs until a successful billing history is built with us.沒有預先預留的實例(RI)會對新帳戶造成重大的計費風險，因為它們是在整個RI期內按月支付的合同義務。 因此，在與我們建立成功的帳單記錄之前，新帳戶和使用率較低的帳戶將無法注冊No Upfront RI。You may run into this error if you try and buy a no up-front.
如果您嘗試不先購買，則可能會遇到此錯誤。
Error : Your current quota does not allow you to purchase the required number of reserved instances (Service: AmazonEC2; Status Code: 400; Error Code: ReservedInstancesLimitExceeded;)錯誤：您當前的配額不允許您購買所需數量的保留實例(服務：AmazonEC2；狀態代碼：400；錯誤代碼：ReservedInstancesLimitExceeded;)Caveat: For whatever reason, it takes a bit for the the reserved instance to “kick-in” which means the first day of the month always costs more. I’m not sure why this is, but if I figure it out, I’ll update this. See graph below:
注意：無論出于何種原因，保留實例都需要花一些時間才能“啟動”，這意味著該月的第一天總是要花更多的錢。 我不確定為什么會這樣，但是如果找出來，我會進行更新。 參見下圖：
痛點 (Pain Points)
These are just some minor complaints about the overall EBS, which I figured I’d include as an addendum to my original article, in case you’re curious.
這些只是對整個EBS的一些小抱怨，我想我會把它作為我的原始文章的補充內容，以防萬一您感到好奇。
自動更新并不是那么自動 (Automatic updates aren’t really that automatic)
Node versions don’t line up from version to version.
節點版本不會在版本之間排列。
Refer to the step below on how I manage changing Linux versions when Node doesn’t work.
請參閱以下步驟，了解在Node無法正常工作時如何管理更改的Linux版本。
運行多個環境 (Running more than one environment)
Having a development environment and a production running at the same time is easy, but it’s expensive. It doubles it, in fact. Therefore, I usually destroy the dev environment as soon as I’m done with it.
同時擁有一個開發環境和一個生產運行很容易，但是卻很昂貴。 實際上，它是它的兩倍。 因此，我通常在完成開發環境后就立即銷毀它。
文檔太可怕了 (Documentation is horrendous)
AWS is too big for its own good. That is part of why I’m writing this. It was really hard to find answers to my specific needs.
AWS本身就太大了。 這就是為什么我寫這篇文章的一部分。 很難找到滿足我特定需求的答案。
我如何管理更新 (How I manage Updates)
I have two separate instances of my Git repo installed on my laptop. I have one for dev, and one for production.
我在筆記本電腦上安裝了兩個單獨的Git存儲庫實例。 我有一個用于開發，一個用于生產。
I use the dev environment to, well, develop! Pretty straightforward. I use the production folder solely for the purpose of pulling updates from Git master branch, running my webpack configuration and deploying to the production server.
我使用開發環境進行開發！ 非常簡單。 我將生產文件夾僅用于從Git master分支提取更新，運行Webpack配置并將其部署到生產服務器的目的。
The reason they are separate is because I can maintain separate elastic beanstalk configurations and not have to worry about deploying to the wrong place.
它們分開的原因是因為我可以維護單獨的彈性beantalk配置，而不必擔心部署到錯誤的位置。
不需要Linux環境更改的更新 (Updates not requiring a Linux Environment change)
For updates not requiring any changes to the linux environment, it’s as simple as running eb deploy in the terminal. It’s amazing and takes about 10 minutes to propagate.
對于不需要對Linux環境進行任何更改的更新，就像在終端中運行eb deploy一樣簡單。 令人驚奇，大約需要10分鐘才能傳播。
需要Linux環境更改的更新 (Updates requiring a Linux Environment change)
Occasionally, you will want to update the Linux environment but will be unable too because AWS is freaking dumb (I’m sure there’s a reason) and only allows certain versions of Node on each Linux build. For this, it’s a bit more complicated, but manageable.
有時，您將需要更新Linux環境，但也將無法更新，因為AWS實在太愚蠢了(我確定是有原因的)，并且每個Linux構建上僅允許使用某些版本的Node。 為此，它有點復雜，但易于管理。
Push to production config under new env. The last time I did this, I just created a new instance via eb create prod-1 . It’ll do what it needs to and deploy your app to a new environment.
推送到新環境下的生產配置。 我上一次這樣做是通過eb create prod-1創建了一個新實例。 它將完成所需的工作，并將您的應用程序部署到新環境中。
So, there you have it. How to manage your updates. Pretty easy.
所以你有它。 如何管理您的更新。 挺容易。
最后的想法 (Final Thoughts)
If you have any suggestions to make it cheaper/easier, I would love to hear them. I like the discussion about tools and options just as much as the next developer!
如果您有任何建議讓它更便宜/更容易，我很想聽聽他們。 我和下一個開發人員一樣喜歡關于工具和選項的討論！
With that, I’ll leave with this: Happy coding!
這樣，我就離開了：編碼愉快！
翻譯自: https://www.freecodecamp.org/news/the-reality-of-running-a-production-node-app-on-aws-elastic-beanstalk-55c78b5dad0b/
node aws 內存溢出
總結
以上是生活随笔為你收集整理的node aws 内存溢出_在AWS Elastic Beanstalk上运行生产Node应用程序的现实的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 做梦梦到门开着是怎么回事
- 下一篇： 微信开发者平台如何编写代码_编写超级清晰