(PT)
Estava eu no twitter e de repente lembrei-me que seria interessante escrever algumas Boas Práticas sobre a utilização do Windows Azure. Aqui estão algumas que me lembrei:
- Não crie um proxy desnecessário, saia da frente sempre que pode. Envie o cliente directamente para o blob storage para conteúdos estáticos
- Utilize Shared Access Signatures para fornecer acesso directo a conteúdo seguro. Pode ser associado a um período de tempo e revogado a pedido. Também importante será a utilização de Shared Access Policy de forma a remover informações como a data de termino do Url
- Disponibilize blobs públicos através da Windows Azure CDN. Tem menos latência e está mais próximo do cliente.
- Se está a utilizar #CDN não se esqueçam de gerir a expiração do conteúdo. Por defeito são 72 horas
- Se está a utilizar CDN utilize urls versionados para permitir actualizações imediatas. Realmente muito importante para evitar problemas de cache
- Faça cache de dados muito utilizados em memória para evitar diminuição da performance no acesso aos dados. Ex. Sessão, dados de referência. Utilizando a camada de caching irá ajudá-lo a reduzir o tempo de latência e em alguns casos também os custos
- Considere utilizar um maior numero de instâncias mais pequenas ao invés de menos instâncias maiores. Na maioria das vezes a sua performance será bem melhor
- Particione os dados com base nas necessidades de indexação. Utilize o #SQLAzure para dados altamente indexados e #Storage para o restante. Considere sériamente efectuar particionamento hibrido
- Particione horizontamente (Shard) os seus dados de #SQLAzure entre diversas bases de dados para aumentar a disponibilidade.
- Não se esqueça de fazer o tunning básico de performance das aplicações. Faça medições e monitorização da sua aplicação, optimize e crie uma base de performance
- Não se esqueça de ligar a compressão para tipos de conteúdos dinâmicos nas aplicações Web
- Não pode efectuar updates de aplicações com um número diferente de portos, por isso prepare-se, deixe algumas portas abertas
- No #Azure #AppFabric Caching prefira colocar mais objectos pequenos do que objectos grandes em cache, a sua performance melhora
- Considere o VMRole apenas quando necessita de alguma coisa instalada que demora muito tempo ou a sua instalação não é automatizável
- Utilize Startup Tasks preferencialmente em background a não ser que necessite de uma ordem específica no seu lançamento
- Utilize Padrão de Trabalho Assincrono e Filas ao invés de utilizar uma abordagem sincrona nos seus Roles
- Para dispositivos, não os ligue directamente ao #SQLAzure, obrigue-os a passar por uma camada disponível no #Azure Compute (claro, estamos numa abordagem #SOA )
- Se está a utilizar Startup Tasks não se esqueça de fazer log de tudo. Ex. commando >> %~dp0log.txt 2>> %~dp0err.txt
- Se está a utilizar Startup Tasks não se esqueça de utilizar o “/y” em todo o lado para evitar mensagens de confirmação. Ex. “copy /y origem destino”
- Para Startup Tasks utilize a disco local uma vez que é espaço garantido, e se não existir espaço suficiente a mesma não será iniciada.
- Se necessita de uma startup task que necessita de uma IIS pool já existente, então deverá utilizar o OnStart() num Role com acesso elevado – Não é problemático uma vez que um Role em modo elevado não afecta a forma como a Aplicação Web é lançada e configurada no IIS
- Processos que necessitem de ser monitorizados deverá utilizar o ProgramEntryPoint ou NetFxEntryPoint ao invés de Startup Tasks
- Defina as regras de trafefo com o NetworkTrafficRules de forma a melhor proteger o acesso interno aos seus Roles
- Se está a utilizar o Traffic Manager crie uma página para Monitorizar a Aplicação que valida se tudo está OK na sua aplicação.
- Quando utilizarem Table Storage utilize o SaveChanges com SaveChangesOptions.Batch para melhorar a performance e poupar em transacções
- A escolha do tamanho da instância é importante, deverá escolher de acordo com as necessidades de Velocidade, Memória, IO e Rede.
- Utilize Lógica capaz de efectuar a re-conexão em caso de erro para ligações de #SQLAzure e para #AppFabric Service Bus, Cache e Storage. Utilize o Transient Fault Handling Framework for SQL Azure, Windows Azure Storage, Windows Azure AppFabric Service Bus and Cache.
- Não utilize o owner para o #AppFabric Service Bus. Crie o seu próprio login e forneça-lhe apenas as permissões apropriadas. Veja este post pelo Neil Mackenzie.
- Não utilize o login de #SQLAzure criado no Management Portal na ligação à base de dados, crie o seu próprio. Isto é devido a querermos trabalhar com o minimo de privilégios possíveis e não queremos utilizar algo semelhante ao SA para fazermos a ligação.
- Quando utilizarem Queues/Filas, ao invés de utilizar o GetMessage utilizem o GetMessages(count), pois irá ajudar-vos a poupar transações e melhor a performance da solução
- Se está a utilizar Workers que são baseados em Queues/Filas (Mecanismo de Pooling), utilize um mecanismo de "acalmar" quando não existem mensagens nessa queue. Com isto irá reduzir o número de transacões que são efectuadas e melhor a performance da
- Se está a utilizar Workers que são baseados em Queues/Filas (Mecanismo de Pooling), deverá considerar utilizar notificações para re-iniciar o processo de "acalmar". O Windows Azure AppFabric Service Bus é perfeito para isto, mas não se esqueçam de efectuar os calculos para o vosso
- Crie o processo de Escalabilidade da Solução considerando todas as opções, Scale Up, Out e Down, não se esqueçam do Scale Down.
Ultima Actualização: 2011-10-20
(EN)
I was on Twitter and suddenly some remember that it would be interesting write some Best Practices about using Windows Azure. Here are some of the ones I remembered:
- Get out of the way when you can. Send client directly to blob storage for static content
- Use Shared Access Signatures to provide direct access to ACLed content. Can be time-bound and revoked on demand. Also important will be using a Shared Access Policy in order to remove information like end date from url
- Serve public blobs from the edge with the Windows Azure CDN. You have fewer hops, and be closer to the customer.
- If you're using #CDN don't forget to Manage the Content Expiration. The Default is 72 hours
- If you're using CDN use versioned urls to allow immediate refresh. Really important to avoid caching problems
- Cache hot data in memory to avoid slower data-tier access. Ex. Session State, immutable reference data. Using the Caching ties will help you reduce latency and in some cases also costs
- Consider using more smaller compute instances instead of few large one. Most times you'll get better perf
- Partition Data based on the indexing needs. Use #SQLAzure for highly indexed data, and #Storage for the rest. Really consider doing Hybrid Partitioning
- Shard your #SQLAzure data across databases to increase the workload.
- Don't forget to do the basic performance tuning to applications. Measure, optimize & create a baseline for perf
- Don't forget to enable compression for additional dynamic content types in Web Apps
- You can't update Apps with a different number of endpoints, so prepare for that upfront, leave some backdoors opened
- In #Azure #AppFabric Caching Prefer to cache more smaller objects then few larger ones, increases your perf
- Consider VMRole only when you need something installed that takes long time or is a non-automated install
- Use Startup Tasks preferably in background unless you need a specific order in their launch
- Use Asynchronous Work Pattern and Queues instead of using a Synchronous approach on your Roles
- For devices don't connect directly to #SQLAzure, proxy those in your #Azure Compute (of course #SOA approach)
- If you use Startup Tasks don't forget to log everything. Ex. command >> %~dp0log.txt 2>> %~dp0err.txt
- Don’t forget to use “/y” in everything to avoid confirmation messages. Ex. “copy /y source destination”
- For Startup Tasks use local storage since it’s a guaranteed space, and if there’s not enough space it won’t run.
- If you need to run a startup task that needs the IIS pool to exist, then you should use OnStart() in elevated Role – This isn’t a problem since running a Role in Elevated mode doesn’t affect how the Web Application will run on IIS
- Process that needs to be monitored you should use a ProgramEntryPoint or NetFxEntryPoint instead of Startup Tasks
- Define NetworkTrafficRules in order to better protected internal access to your roles
- If you’re using Traffic Manager build a AppHealth page Monitor that checks if everything is OK in your Application
- When using Table Storage use the SaveChangesOptions.Batch to improve performance and save transactions
- Choosing your VMSize is important, choose accordingly to your Speed, Memory, IO and Network needs.
- Use Retry Logic for #SQLAzure connection and for #AppFabric Service Bus, Cache and Storage. Use Transient Fault Handling Framework for SQL Azure, Windows Azure Storage, Windows Azure AppFabric Service Bus and Cache.
- Don't use owner for #AppFabric Service Bus. Create your own login and provide them the appropriate permissions. Check this post by Neil Mackenzie.
- Don't use the #SQLAzure login that you created on the Management Portal in the connection String. Create your own. This is because you need to work in the least privileges and you don’t want to use the SA for that
- When using Queues instead of using GetMessage use GetMessages(count), this will help you save transactions and improve performance of your solution
- If you're using Workers that are Queue based (Pooling Mechanism), use a back off mechanism when no messages are found in the queue. This will help reduce the number of transactions that are done and improve your solution performance
- If you're using Workers that are Queue based (Pooling Mechanism), you should consider using notifications to resume the back off mechanism. #AppFabric Service Bus will be perfect for this, but don't forget to do the cost calculation to your scenario.
- Perform your Application Scaling process considering all options, Scale Up, Out and Down, don't forget Down.
Last Updated: 2011-10-20