Thank you Hussein. We are going to move our app from appengine to a managed VM and place it in the same network (default) as our compute engines. Until appengine and compute engine instances can communicate on the same network we'll be forced to use this work around. Please let me know how your method works!
On Thursday, May 7, 2015 at 5:33:09 PM UTC-4, Hussein Vastani wrote: > > Hi, > At my current gig we've been grappling with the same problem, and there > seems to be a solution in the 1.9.19 SDK release (finally!). > > So my context is: my java frontend instances need to hit my elasticsearch > cluster hosted on GCE. The only way to reach the cluster was via a reverse > proxy exposed through a GCE public IP address. I was using basic auth to > authenticate my App Engine frontend instances. As you would expect the > latency has been hurting. Search queries that should take 10ms, instead > come back in 150ms (10x slow). After additional processing in my frontend > request, that adds up pretty quickly to noticeable latency user-side. > > I posted about the problem some time ago in this group here > <https://groups.google.com/d/topic/google-appengine/rfRIECYud94/discussion> > and > the issue tracker here > <https://code.google.com/p/googleappengine/issues/detail?id=11679>. I got > an acknowledgement from Google and the fix appeared in the 1.9.19 release, > a bit quietly (the issue is still open). > > So the solution for me is to run a managed VM on the same network as my > elasticsearch cluster, and that way I should be able to access my cluster > "directly" using internal network addresses, without going out of the > Google network. The 1.9.19 SDK allows you to specify a network in the > configuration for your managed vm, that defaults to the default GCE network > of your project. Thus I either directly route my search requests to my > managed VM or have my front end instances talk to my managed VM over http. > > (For my particular case, I expect additional latency savings because I can > run a full elasticsearch client on the managed VM that knows the cluster > state, instead of using the naked elasticsearch REST API, as I do now, from > my front end instances. That saves me an additional network hop that is > needed to figure out which nodes in my cluster to hit.) > > I guess, the same should work for you no? > > I'll post next week about the results of migrating to a managed VM setup. > > Good luck! > H > > > On Thursday, May 7, 2015 at 1:52:39 PM UTC-4, Ian Childress wrote: >> >> We (our Go dev team) want to connect our app engine apps to our compute >> engine apps directly using internal IP address. From my understanding >> through documentation and exhaustive searching, the solution is to use a >> public IP address. This solution requires whitelisting an entire ip block >> (Google's ip block for app engine). This both increases security risk as >> well as charges additional bandwidth. The other solution is to use a >> messaging service PubSub. This is fine for submitting tasks to be performed >> by the back end app, but it prevents the app engine from receiving the >> response from the compute engine. >> >> Have I missed the solution somewhere that allows for internal >> communication between app engine and compute engine? Using a job queue or >> public IP is not a replacement for an internal socket connection. >> > -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-appengine+unsubscr...@googlegroups.com. To post to this group, send email to google-appengine@googlegroups.com. Visit this group at http://groups.google.com/group/google-appengine. To view this discussion on the web visit https://groups.google.com/d/msgid/google-appengine/3e56aad4-2ab9-438e-94e8-1761cde089a1%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
