I've been doing some server architecture design over the past few weeks and have run into an issue that I need outside help with. I'm creating a game server for a massively multiplayer game, so I need to receive constant updates on entity locations, then broadcast them out to relevant clients.
I've written servers with scale in mind before, but they were stateless servers, so it wasn't all that difficult. If I'm deploying this server on a cloud platform like Google Cloud or AWS, is it better to simple scale the instance that the server is running on, or should I opt for the reverse proxy method and deploy the server across multiple instances?
Sorry if this is a vague question. I can provide more details if necessary.
You may want to start here -
https://aws.amazon.com/gaming/
https://aws.amazon.com/gaming/game-server/
You also should consider messaging solutions such as SNS and SQS. If the app can receive push notifications then SNS might be your best option.
Related
I'm working on a SaaS application which at the moment is cloud only. It's a traditional Java web application which we deploy to AWS. We rely on AWS concepts like RDS, S3, ELB, Autoscaling and for infrastructure provisioning AMIs, Cloudformation, Ansible and CodeDeploy.
There is now more and more demand for on-premise deployments by potential clients.
Are there any common approaches to package b2b applications for on-premise deployments?
My first thought would be to containerize the app infrastructure (web server, database, etc) and assume a client would be able run images. What are you guys doing and how do you tackle HA and DR aspects which come with cloud infrastructure like AWS?
I'm tackling a similar problem at the moment and there really is no one-fits all answer. Designing software for cloud-nativity comes with a lot of architectural design decisions to use technologies on offer by the platform (as you have with S3, RDS, etc) which ultimately do not cross-over to majority of on-premise deployments.
Containerising your application estate is great for cross-cloud and some hybrid cloud portability but there is no guarantee that a client is using containerised work-loads on their on-premise data centre which makes the paradigm still a way off the target of supporting both seamlessly.
I find another issue is that the design principles behind cloud-hosted software are vastly different to those on-premise, with static resource requirements, often a lack of ability to scale etcetera (ironically some of the main reasons you would move a software solution to a cloud environment) so trying to design for both is a struggle and I'm guessing we will end up with a sub-optimal solution unless we decide to favour one and treat the other as a secondary concern.
I'm thinking maybe the best cross-breed solution is to concentrate on containerisation for cloud hosts taking into account the products and services on offer (and in the roadmap) - and then for making the same software available to clients who wish to use on-premise datacenters still.... perhaps they could be offered VM Images with the software solution packaged in... then make this available on a client portal for them with instructions on installation/configuration.
... I wish everyone would just use Kubernetes already! :)
i have to make a web application which a maximum of 10,000 concurrent users for 1h. The web server is NGINX.
The application is a simple landing page with an HTML5 player with streaming video from CDN WOWZA.
can you suggest a correct deployment on AWS?
LoadBalancer on 2 or more EC2?
If so, which EC2 sizing do you recommend? Better to use Autoscaling?
thanks
thanks for your answer. The application is 2 page PHP and the impact is minimal because in PHP code i write only 2 functions that checks user/password and token.
the video is provided by Wowza CDN because is live streaming, not on-demand.
what tool or service do you suggest about the stress test of Web Server?
I have to make a web application which a maximum of 10,000 concurrent users for 1h.
Avg 3/s, it is not so bad. Sizing is a complex topic and without more details, constraints, testing, etc. You cannot get a reasonable answer. There are many options and without more information it is not possible to say which one is the best. You just started NGINX, but not what it's doing (static sites, PHP, CGI, proxy to something else, etc.)
The application is a simple landing page with an HTML5 player with streaming video from CDN WOWZA.
I will just lay down a few common options:
Let's assume it is a single static (another assumption) web page referring an external resource (video). Then the simplest and the most scalable solution would be an S3 bucket hosting behind the CloudFront (CDN).
If you need some simple quick logic, maybe a lambda behind a load balancer could be good enough.
And you can of course host your solution on full compute (ec2, beanstalk, ecs, fargate, etc.) with different scaling options. But you will have to test out what is your feasible scaling parameters or bottleneck (io, network CPU, etc.). Please note that different instance types may have different network and storage throughput. AWS gives you an opportunity to test and find out what is good enough.
Is there a way by which we can do integration between On-Premise IBM MQ with AWS SQS/API Gateway.I checked lots of links but found that we can migrate whole IBM MQ to AWS MQ but can't call from AWS to on premise MQ. Please suggest if anyone has tried this kind of integration.
I’m assuming you have an AWS based application that integrates with SQS and an on-premise application that integrates with IBM MQ, and ultimately you want to communicate effectively between the two applications.
At a functional level IBM MQ provides a client interface and a bridge between this and the AWS SQS interface is relatively straight forward to create. One important aspect to consider is the non-functional aspects. The IBM MQ client can either communicate directly back to the on-premise MQ instance, or via an AWS MQ instance. Although it may appear to be more straight forward to communicate directly to the on-premise MQ instance there are a few considerations that may mean an MQ instance in AWS is a more sensible approach.
Applications often use IBM MQ for its assured delivery capabilities,
by building a bridge to AWS SQS which is a non-assured delivery
provider there is a risk that messages can be lost or duplicated
(depending on the implementation of the bridging logic). To minimize
the chance of this occurring you want to ensure that you have a
reliable network between MQ, the bridge and SQS instance. This
removes any fragile network links, as MQ can transfer the message
reliably from on-premise to a MQ instance deployed in AWS, overcoming
any network issues transparently.
The MQ Client is relatively chatty compared to two MQ instances exchanging messages. Due to the network latency between the on-premise and AWS data center, the chatty nature of the MQ Client can impact the overall performance of the solution.
Therefore, it is often sensible to install a lightweight instance of MQ within your AWS availability zone and allow MQ to transfer the messages from on-premise to AWS efficiently and reliably. To help get you up and running quickly, you can grab the IBM MQ developer container for free on DockerHub here.
I created a SQS Adapter in the OnPremise server and called my SQS directly from there.
I'm developing a prototype IoT application which does the following
Receive/Store data from sensors.
Web application with a web-based IDE for users to deploy simple JavaScript/Python scripts which gets executed in Docker Containers.
Data from the sensors gets streamed to these containers.
User programs can use this data to do analytics, monitoring etc.
The logs of these programs are outputted to the user on the webapp
Current Architecture and Services
Using one AWS EC2 instance. I chose EC2 because I was trying to figure out the architecture.
Stack is Node.js, RabbitMQ, Express, MySQl, MongoDB and Docker
I'm not interested in using AWS IoT services like AWS IoT and Greengrass
I've ruled out Heroku since I'm using other AWS services.
Questions and Concerns
My goal is prototype development for a Beta release to a set of 50 users
(hopefully someone else will help/work on a production release)
As far as possible, I don't want to spend a lot of time migrating between services since developing the product is key. Should I stick with EC2 or move to Beanstalk?
If I stick with EC2, what is the best way to handle small-medium traffic? Use one large EC2 machine or many small micro instances?
What is a good way to manage containers? Is it worth it use swarm and do container management? What if I have to use multiple instances?
I also have small scripts which have status of information of sensors which are needed by web app and other services. If I move to multiple instances, how can I make these scripts available to multiple machines?
The above question also holds good for servers, message buses, databases etc.
My goal is certainly not production release. I want to complete the product, show I have users who are interested and of course, show that the product works!
Any help in this regard will be really appreciated!
If you want to manage docker containers with least hassle in AWS, you can use Amazon ECS service to deploy your containers or else go with Beanstalk. Also you don't need to use Swarm in AWS, ECS will work for you.
Its always better to scale out rather scale up, using small to medium size EC2 instances. However the challenge you will face here is managing and scaling underlying EC2's as well as your docker containers. This leads you to use Large EC2 instances to keep EC2 scaling aside and focus on docker scaling(Which will add additional costs for you)
Another alternative you can use for the Web Application part is to use, AWS Lambda and API Gateway stack with Serverless Framework, which needs least operational overhead and comes with DevOps tools.
You may keep your web app on Heroku and run your IoT server in AWS EC2 or AWS Lambda. Heroku is on AWS itself, so this split setup will not affect performance. You may heal that inconvenience of "sitting on two chairs" by writing a Terraform script which provisions both EC2 instance and Heroku app and ties them together.
Alternatively, you can use Dockhero add-on to run your IoT server in a Docker container alongside your Heroku app.
ps: I'm a Dockhero maintainer
I am exploring AWS, and I'd like to implement in Java EE an EC2 app like the Online Photo Processing Service example in Getting Started with Amazon EC2 and Amazon SQS (PDF). It has a web-based client that submits jobs asynchronously to a client-facing web server app that then queues jobs for one or more worker servers to pick up, run, then post back to a results queue. The web server app monitors the results queue and pushes them back to the client. The block diagram is here.
How would you implement an app like this using Java EE, i.e., what technologies would you use for the servers in the diagram? We're using AWS because our research algorithms will require some heavy computation, so we want it to scale. I am comfortable with AWS basics (e.g., most things you can do in their management console - launch instances, etc), I know Java, I understand the Java AWS APIs, but I have little experience on the server side.
There are many possibilities to solve your problem, go with the simplest one for you. Myself, I would build a simple Java EE 6 (based on weld) web application with Amazon SQS dependency, this web application would send messages to AWS based SQS, another instance (possibly based on stateless EJB's) again with Amazon SQS dependency, which would read incoming messages and process them, you can use stateless EJBs as web service to process data synchronously, set the EJB pool size for each server instance depending on the processing load you need etc..
Most of the functionality in J2EE is way over the top for the majority of tasks. Start trying to implement this by using basic servlets. Keep the code in them as stateless as possible to assist with scaling issues. Only when servlets have some architectural flaw that prevent you completing the task would I move onto something more complex.