Surviving AWS Failures with a Node.js and MongoDB Stack
Node+Mongo on EC2 is a very popular software stack among web services developers. There are many user guides on how to design such a system with built-in redundancy so that even coordinated failures don’t bring down the service.
The absolute minimum for a resilient service requires a MongoDB replica set behind a load-balanced node farm. However, you are not ready for an EC2 outage until you have deliberately shutdown components in your system and verified the expected behavior.
As you periodically do this, you might discover that there are gaps you did not account for. In this blog I want to share our experiences beyond the initial configuration and add some fine details on creating a Node+Mongo application that is both secure and resilient to common EC2 failures.
What you should worry about upfront:
1. Node.js single event will by default crash on an unhandled exception so you need to worry about restarting the process. Upstart or forever will do the job.
2. You also have an external process on your server making liveness checks and potentially restarting your service. Monit is a good one, it has the added benefit of emailing you when it had to restart. While upstart ensures that your process is up, monit ensures that it is responsive, and those are two different things.
3. Your application instances and your MongoDB instances are each load balanced across multiple Availability Zones. The more the better.
4. Place the node servers and the mongo servers all in a security group, which beyond ssh allows only the Mongo ports internally and your application ports externally. This is trivial to set up and protects your database from external requests.
5. If you are like us, you have the additional protection of the MongoDB authentication. Mongo’s security model has limited robustness, but having authentication in your MongoDB store is still useful even if the application and the database are inside an EC2 security group. For your data to get exposed, you will have to make multiple mistakes at the same time, which happens, but the chances are greatly reduced.
The absolute minimum for a resilient service requires a MongoDB replica set behind a load-balanced node farm. However, you are not ready for an EC2 outage until you have deliberately shutdown components in your system and verified the expected behavior.
As you periodically do this, you might discover that there are gaps you did not account for. In this blog I want to share our experiences beyond the initial configuration and add some fine details on creating a Node+Mongo application that is both secure and resilient to common EC2 failures.
What you should worry about upfront:
1. Node.js single event will by default crash on an unhandled exception so you need to worry about restarting the process. Upstart or forever will do the job.
2. You also have an external process on your server making liveness checks and potentially restarting your service. Monit is a good one, it has the added benefit of emailing you when it had to restart. While upstart ensures that your process is up, monit ensures that it is responsive, and those are two different things.
3. Your application instances and your MongoDB instances are each load balanced across multiple Availability Zones. The more the better.
4. Place the node servers and the mongo servers all in a security group, which beyond ssh allows only the Mongo ports internally and your application ports externally. This is trivial to set up and protects your database from external requests.
5. If you are like us, you have the additional protection of the MongoDB authentication. Mongo’s security model has limited robustness, but having authentication in your MongoDB store is still useful even if the application and the database are inside an EC2 security group. For your data to get exposed, you will have to make multiple mistakes at the same time, which happens, but the chances are greatly reduced.
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/301743/viewspace-734198/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- Node.js 和MongoDBNode.jsMongoDB
- node.js連線mongodbNode.jsMongoDB
- node.js連線mongodb介紹Node.jsMongoDB
- 潘凡談AWS EC2和MongoDB應用MongoDB
- node.js和MongoDB學習網址Node.jsMongoDB
- node.js操作mongodb簡單介紹Node.jsMongoDB
- 獲得 MongoDB for Node.js Developers 證書MongoDBNode.jsDeveloper
- Node.js學習之路23——Node.js利用mongoose連線mongodb資料庫Node.jsMongoDB資料庫
- 從Oracle到MongoDB:為什麼AWS不斷拋棄合作伙伴?OracleMongoDB
- STACK!
- stack
- Node.js 服務連線 MongoDB 處理最佳實踐Node.jsMongoDB
- CentOS上安裝Node.js和mongodb簡單介紹CentOSNode.jsMongoDB
- MongoDB在 AWS Marketplace 中推出即用即付產品,有力提升客戶體驗MongoDB
- Error StackError
- java stackJava
- Tech Stack
- AWS Switching to an IAM role (AWS CLI)
- AWS 高可用AWS架構方案架構
- Best Practices for failover during server failures [ID 1323472.1]AIServer
- MongoDB基本增刪改查操作-基於Node.JS驅動MongoDBNode.js
- 在node.js中利用monk訪問mongodb簡單介紹Node.jsMongoDB
- html格式郵件監控failures大於0的jobHTMLAI
- 使用Data Recovery Advisor診斷和修復failuresAI
- How to Identify Hard Parse Failures (文件 ID 1353015.1)IDEAI
- AWS學習
- Container on AWSAI
- java Stack總結Java
- Docker Stack 筆記Docker筆記
- Elastic Stack 簡介AST
- C++ STL stackC++
- Java之Stack --- 棧Java
- B. Aleksa and Stack
- Node.js 配合 express 框架、ejs 、mongodb 實現應用 && [使用 TypeScript 重構]Node.jsExpress框架MongoDBTypeScript
- 程顯峰談MongoDB和Node.js相結合的思考與實踐MongoDBNode.js
- C++ Templates (2.2 使用Stack類别範本 Use of Class Template Stack )C++
- AWS Code CommitMIT
- AWS 使用經驗