How to implement server binding or sticky sessions in App Engine?

My application wants to have:

  • Auto scalability

    • I want App Engine to launch new instances of my application as traffic increases.
    • When instances are idle, I want App Engine to close them.
  • The similarity of clients and servers

    • After the initial HTTP request, client-> server, I want clients to be able to connect to the same application server, so that the application server can support a bunch of client status.
    • Status can be updated frequently (to support real-time interaction), so saving memcache + data storage is not advisable.
    • The server may need to make decisions based on the status of multiple clients, such as a real-time multiplayer game

How can i do this?

+6
source share
3 answers

You can achieve these goals using App Engine servers (long-term, customizable, addressable, persistent servers):

Python implementation

  • Set up a backend for both public and dynamic

    # backends.yaml backends: - name: foo instances: 20 options: public, dynamic 
  • In addition to deploying your application in the usual way:

     appcfg.py update . 

    don't forget to expand the backend:

     appcfg.py backends . update 
  • For an initial connection, ask your client to use an improperly specific host name, for example:

     foo.your_app_id.appspot.com 

    App Engine will direct your request to an available backend instance, after optionally starting a new database instance.

  • In the request processing code on the server, use the internal API components to determine which instance is processing the request and return the specific instance URL to the client.

     from google.appengine.api import backends import webapp2 class GetPersistentUrlHandler(webapp2.RequestHandler): def get(self): """Return the current backend instance-specific URL.""" my_url = backends.get_url(instance=backends.get_instance()) self.response.write(my_url) app = webapp2.WSGIApplication([ ('/get_peristent_url', GetPersistentUrlHandler), ], debug=True) 
  • The client makes the following connections to a specific instance of the backend URL:

     http://3.foo.your_app_id.appspot.com 

    Note: when using https, be sure to replace the points of the -dot- subdomain to avoid problems with SSL certificates.

     https://3-dot-foo.your_app_id.appspot.com 

Limitations

  • Backends do not live forever and may be disconnected unexpectedly and without notice
  • The number of backends your application may have is currently limited.
+5
source

In addition to Adam, the good answer is: you don’t need an affinity for the server in GAE, because the data stored in the HTTP session is not stored in memory, but in a permanent data store. Thus, any server will find any other server previously stored in the session. See the documentation :

App Engine includes session implementations using the servlet session interface. The implementation stores session data in the Data Warehouse Engine application for storage, and also uses memcache for speed. In the form with most other servlet containers, session attributes that with session.setAttribute() are saved at the end of the request during a request.

This feature is disabled by default. To enable it, add the following: AppEngine-web.xml:

 <sessions-enabled>true</sessions-enabled> 

The implementation creates data warehouse objects of type _ah_SESSION , and memcache entries using keys with the _ahs prefix.

Note. Because App Engine stores session data in the data warehouse and memcache, all values ​​stored in the session must implement java.io.Serializable .

You can reduce the request timeout by configuring applications to asynchronously write HTTP session data to the repository:

+4
source

Auto-scalability is what makes AppEngine the best and what sets it apart from other cloud hosting providers. Both of your requirements are met without additional work on your part.

AppEngine does not have a separate server concept. You cannot think in such terms about creating a good, scalable AppEngine application. However, you can store client state between requests in Memcache or a data warehouse that is shared between all instances of the application code.

0
source

Source: https://habr.com/ru/post/916013/


All Articles