Elasticsearch is a distributed, multitenant-capable full-text search engine that we recently used to optimize our analytics. A number of queries that are quite expensive in Postgres are extremely fast in Elasticsearch, and document based storage allowed to us store all relevant data in a single index (table).
Elasticsearch (virtual?) hardware needs
However, Elasticsearch generally prefers relatively powerful hardware, as is discussed here
A machine with 64 GB of RAM is the ideal sweet spot, but 32 GB and 16 GB machines are also common. Less than 8 GB tends to be counterproductive (you end up needing many, many small machines)...
In addition, because it is distributed, its also recommended that you have multiple hosts. 2 hosts is the bare minimum for getting a green status, but its recommended to have at least 3.
Doing the math
In ec2, m3.2xlarges (30g of RAM) costs .532/hr (in US east, at the time of this writing), which comes out to $1149.12/mo, which adds up to be ~$14,000 a year!
Of course, you can save some money by purchasing reserved instances, but at $2840/yr each ($8520), its still a pretty expensive cluster.
Why spot instance?
However, because Elasticsearch is distributed, it is capable of coping with failure. If a node is lost, or goes down for some reason, the remaining nodes should have all the data to continue as if nothing has happened.This makes Elasticsearch a really good candidate for spot instances in AWS. Spot instances are ec2 instances that you bid for, and can come and go as the market price changes. So, when the market price exceeds your bid price, your instance shuts down, but when the market price is beneath your bid price, your instance comes back up.However, failure of all nodes in the cluster isn't acceptable, so we'll still need to have at least one reserved instance. The cost breakdown looks something like this:
Spot instances don't cost exactly .085/hr, but looking at the pricing history for them, it seems like a relatively reasonable estimate. This also depends on what you set your bid price at, since if it exceeds your bid price, you won't be paying for it.
What is clear, however, is that significant savings can be had by bringing spot instances into the mix.
Setting bid prices
There is definitely a way to set an optimal bid price, but to put it simply - you're better off bidding higher and paying a little more for that one hour when the market spikes. While Elasticsearch can handle failure, its still generally preferable to avoid it.
Tip: If you can, diversify you spot instances in different AZ's, and at different bid prices - this hopefully prevents multiple failures, and keeps it isolated to one price or one AZ.
Awesome, where do I start?
While in theory, there's lots of money to be saved with spot instances, the possibility that it will go down at any time means that the process for which a node is brought up needs to be automated. This means the spot instance needs to be created with installation instructions that will bring the node up, install elasticsearch, update the configuration, and add it to the cluster.
When you launch an instance in Amazon EC2, you have the option of passing user data to the instance that can be used to perform common automated configuration tasks and even run scripts after the instance starts
We'll want to set up something along these lines. At the very basic, we'll obviously need to install elasticsearch and run it, but we'll also need java. Let's create a shell script called userdata.sh:
Similarly, you can make changes to the main configuration file (/etc/elasticsearch/elasticearch.yml).For example, its usually a good idea to disable multicast detection of nodes, since you'll want to specify exactly who the other nodes are.
cd /usr/share/elasticsearch/ && ./bin/plugin -install royrusso/elasticsearch-HQ
cd /usr/share/elasticsearch/ && ./bin/plugin -install lukas-vlcek/bigdesk /etc/init.d/elasticsearch restart
Brief note on security
Its also important to remember that securing your cluster is critical. Elasticsearch doesn't have any built in security, and they strongly recommend that it be on an internal network or that you set up a firewall. Some helpful blog posts in this regard are by found and Andy BrudtkuhlFor security purposes, I won't discuss our security implementation here, but if you run into issues trying to handle it in AWS, feel free to bounce some ideas off of me at email@example.com
A cost discussion isn't completely valid without taking a look at Elasticsearch service providers: