A CI&T migrou vários sistemas para o Google App Engine nos últimos 3 anos, incluindo aplicações com Spring e JSF. Eles usam serviços como Cloud Storage, CloudSQL e Task Queues para armazenamento de dados, processamento assíncrono e integração com sistemas legados. A arquitetura centraliza dados corporativos em um AppEngine e permite buscas geoespaciais no CloudSQL.
6. Contexto tecnológico
● Infra-estrutura complexa e sistemas
legados
● Alto custo com manutenção da infra
● Grande parte do processamento
backoffice no Mainframe (COBOL Batch e
COBOL CICS)
7. Em 2010...
● Tornou-se cliente do Google Apps for
Business (E-Mail, Calendar, Docs, Sites)
● Decisão do Move to the Cloud por redução
de custos e complexidade de suporte
24. O Problema
● Dados corporativos, comuns a todas as
aplicações
● Rastreabilidade e consistência das
informações
25. App com serviços corporativos, centralizadora dos dados
(domínio) em todo ecossistema AppEngine
●
Domínios como consulta de CEP,
Empresas, UF, Profissão...
●
Cacheable, baixíssimo custo
(Latência de rede não é problema)
●
Gestão de volume e
permissionamento
●
Dashboard específico
28. Geocodificação dos endereços
● Endereços na base armazenados como
“Avenida Paulista, 1000, São Paulo”
● Conversão para Latitude/Longitude
● Google Geocoding API
30. Cenário
● Janeiro de 2011!
● Ferramenta promissora da Google, recém
lançada!
● Em fase Experimental!
“É o risco da inovação!”
31. Google Fusion Tables
●
Cláusulas e funções como ORDER
BY DISTANCE, CIRCLE, INTERSECTs
select local from Locais
where CIRCLE(<latlong>, <raio>)
order by distance;
32. Google Fusion Tables
● Mudanças constantes no comportamento
da API (App parada em produção)
● API foi descontinuada 6 meses depois
● Hoje ainda existe, API reestruturada
“É o risco da inovação!”
33. Migramos para o Google CloudSQL
●
É o MySQL na núvem
●
Disponível (na fase oficial) desde
Jun/2012
●
Replicação automática, síncrona ou
assíncrona, around the globe!
●
Suporte a consultas geospaciais
nativas do MySQL :)
34. How it works?!
● MySQL possui suporte a datatypes de
geometria, GEOMETRY, POINT, CURVE,
POLYGON
OpenGIS Geometry Model
● Tabelas do tipo MyISAM, InnoDB não tem
suporte!
● Índice R-Tree para consulta geométrica
CREATE SPATIAL INDEX sp_index ON mytable (g);
35. How it works?!
● O conceito permite buscas indexadas
retornando se o ponto está dentro de um
polígono (MBRWithin / MBRContains)
40. Show me the code!!
SELECT *
FROM (
SELECT *, ( 6371 * acos( cos( radians(1) ) * cos(
radians( X(LATLONG) ) ) * cos( radians( Y(LATLONG) ) radians(1.1) ) + sin( radians(1) ) * sin( radians( X
(LATLONG) ) ) ) ) AS DISTANCE
FROM MAPA_ATENDIMENTO
WHERE MBRWithin( LATLONG, Envelope( GeomFROMText(
'LineString( X Y , X Y)'))
) inner
WHERE inner.DISTANCE <= Z
41. Pontos interessantes sobre o
CloudSQL
● O CloudSQL trabalha nativamente com
replicação around the globe.
● Configurável: Síncrona ou Assíncrona
● Síncrona: Insert/Update/Delete são
replicados dentro do statement
● Assíncrona: Insert/Update/Delete são
replicados fora do statement
42. Pontos interessantes sobre o
CloudSQL
● A percepção de performance é notável,
fizemos o teste:
○ Síncrono: 10K inserts com commit de 500 em 500
10 segundos
○ Assíncrono: 10k inserts com commit de 500 em
500
5 segundos
45. Uploading files
● API de integração no AppEngine SDK
(Blobstore API)
blobstoreService.createUploadUrl("/uploaded",
UploadOptions uploadOptsWithBucketName);
blobstoreService.getUploads(request); //File info
(BlobKey)
49. AppEngine SDK não é JEE
● A SDK não implementa 100% da
especificação
● Mas calma, é quase lá…
50. O que usamos
● Spring Framework 3.2
● Hibernate 4.2 (Apenas com CloudSQL)
● JSF 2.1 + Primefaces 3.5 (Precisamos de alguns
workarounds)
● iText 2.1.7 (Adaptado)
● Objectify 3.1
51. Alguns cuidados ao usar Spring
Framework
● Tempo de warmup máximo de 60 segundos
● Evite ou reduza o uso de <component-scan>
● Evite ou reduza o uso de @AutoWire
(Principalmente by-type)
● Desabilite o XML Validation em produção
● lazy-init=”true” na declaração dos Beans
52. Nosso warmup
● 250 beans (@Component)
● Usando component-scanning = Estourou os 60 segs
com ~160 Beans
● Warmup de 38 segundos apenas removendo o
component-scanning + lazy-init
56. E o principal… CUSTO!
● Uma máquina de servidor de aplicação
tradicional (hosting):
~ US$ 30.000,00 mês
● Todas as aplicações + CloudStorage +
CloudSQL + Ambientes QA/UAT/PRD
+ Premier Support
Em média US$ 1600,00