The purpose of the Windows Azure ISV blog series is to highlight some of the accomplishments from the ISVs we’ve worked with during their Windows Azure application development and deployment.  Today’s post, written by Naoki Sato, Windows Azure developer evangelist at Microsoft Japan, is about Windows Azure ISV ReedRex Co. LTD and how they’re using Windows Azure to deliver their CMS service for Facebook pages.

ReedRex recently launched a new SaaS offering called sociobridge, a Content Management System (CMS) service specifically for Facebook pages. Distributed by top Japanese Ad Company Dentsu Razorfish, sociobridge was jointly established by Dentsu and Razorfish. 

Company and ad agency staff can use sociobridge to do the following:

• Create and maintain Facebook pages
• Schedule posts
• Monitor walls, comments, and likes 

sociobridge consists of two multi-tenant web applications written in ASP.NET MVC with Facebook C# SDK . One Web Role runs a subscriber portal, which is a content management application for subscribers (customer companies and ad agencies). The other runs an application runtime, which hosts public Facebook pages for end users.

There are also Worker Role instances, which are responsible for Facebook monitoring and other background processing.

sociobridge uses Windows Azure Storage (Table and Blob) as a persistent data store. This is because Windows Azure Storage provides higher scalability with much lower cost.

Information about subscriptions (tenants), user accounts, scheduled posts, poll results, statistics and others are stored in Table Storage. There are only two tables in Windows Azure Table Storage:

• Subscription metadata
• Subscriber data

In Table Storage, tables are partitioned to support load balancing across storage nodes. A table’s entities are organized by partition. A partition is a consecutive range of entities possessing the same partition key value. 

Relational database systems, such as SQL Azure, provide transactional support, with properties often referred to as ACID:

• Atomic: Everything in a transaction succeeds, or is rolled back.
• Consistent. A transaction cannot leave the database in an inconsistent state.
• Isolated. Transactions cannot interfere with each other.
• Durable. The results of a transaction are stored permanently.

Unlike relational database system, Windows Azure Table Storage does not support multiple operations (such as Insert, Update and Delete Entity) within a transaction in general. But if all entities subject to operations as part of the transaction have the same partition key value (and belong to a same partition), you can perform these operations in a batch update known as an “entity group transaction” or EGT. More details about EGT’s may be found here. 

To leverage the schema-less data model and EGT of Table Storage, different type of data are stored in a single data table. Subscription ID is used as a partition key, so each subscription’s data are stored in different partitions, and table access is spread over many storage servers for scalability. The row key is a combination of data type and some kind of unique row ID.

Every table query from Subscriber Portal is carefully designed to specify the partition key (subscription ID), so that they query is limited to a single partition and a full table scan over many partitions never happens.

There are transactions of two or more types of data in a single subscriptions’ data, but there are no transactions of two or more subscriptions’ data. So, this table design enables atomic transactions using EGT (entity group transaction) because data in a single transaction reside in a single partition in a single table. 

Currently, Windows Azure Storage Analytics provides metrics data per storage account. With this table design, it is not possible to estimate cost of table storage per subscriber. This table design was chosen because of benefit described above and quota of number of storage accounts.

Staff in a customer company and/or an ad agency create and maintain Facebook pages in the subscriber portal. When definitions and metadata of Facebook pages are created or modified, actual web content of Facebook pages are generated in advance, and stored in Blob Storage.

A Subscriber may create multiple custom tabs in a single Facebook page. Each custom tab has its own Blob container, and web content of each tab is stored there. Permissions of Blob containers are set to public, because Facebook pages are inherently public.

At runtime:

1. An end user browses a Facebook page (included in Facebook using an HTML inline
2. frame).
3. The web browser sends a HTTP POST request to the application runtime on Web Role.
4. The application runtime accesses Table Storage to query a Blob Storage URL.
5. The application runtime returns the Blob Storage URL (using HTTP 302 Found).
6. The web browser is redirected to the web content in Blob Storage.

The purpose of this architecture is to reduce the workload of Web Role by avoiding dynamic web content generation, and to achieve much higher scalability to process huge requests from many Facebook users.

Facebook pages are required to handle HTTP POST requests. But the “Get Blob” operation in Blob Service REST API needs to be a HTTP GET request as its name suggests.  Because of this, direct access to Blob Storage does not work, and the application runtime is necessary to handle HTTP POST.

Partition Key for Blob Storage is a combination of container Name and Blob name, so access to different Facebook pages (Blobs) are spread over different partitions.

According to “Windows Azure Storage Abstractions and their Scalability Targets”, the target throughput of a single Blob is up to 60 MB/sec. Performance tests revealed that the throughput  of the sociobridge application runtime (on one Small instance) is about 200 requests/sec.

At a rough estimate, if only one Facebook page is hosted and the size of Facebook page is less than 300KB, the application runtime becomes a bottleneck. If it is greater than 300KB, Blob Storage becomes a bottleneck.  It is possible to remove these bottlenecks by adding more Web Role instances and leveraging Windows Azure CDN respectively.  Note that usually multiple Facebook pages (Blobs) are hosted, and Blob access will scale out. 

sociobridge was designed to utilize the power of Windows Azure, especially Windows Azure Storage. The sophisticated table design (with the tenant ID as a partition key) and the usage of EGT (entity group transaction) will be helpful in designing your multi-tenant application! 

For additional information about scalability of Windows Azure Storage, refer to these blog posts:

• Windows Azure Storage Architecture Overview
• Windows Azure Storage Abstractions and their Scalability Targets
• How to get most out of Windows Azure Tables 

Special thanks to Takekazu Omi, Lead Architect of sociobridge at ReedRex, for help on this post.