CISCO.COM CASE STUDY

PRESENTED BY

Extending Adobe AEM for High Availability, High Performance and High Scalability

ABOUT US

2

•  Akhil Aggrawal •  Distinguish Engineer & Chief

Architect Cisco.com •  linkedin.com/in/akhilaggrawal •  @akhil183

•  Anshul Chhabra •  Principal Architect, McAfee •  Previously Architect, Cisco.com •  linkedin.com/in/anshulchhabra •  @Anshul2

Cisco’s Digital Presence

355M visits to Cisco.com

11.5M social reach

3.9M paid search click-

throughs

112M organic search

referrals

40% 34%

71%

4%

10.7M mobile web

visits

1.4M social referrers to Cisco.com

3M social media

mentions

5.7M customer

app downloads

2.5M video views on

Cisco.com

Social Media Mobile Web

Video

7.5M video views on Cisco YouTube

47%

[Date Range: Q1FY14 – Q4FY14]

Q1FY14 – Q4FY14

CISCO.COM WEB EXPERIENCE MANAGEMENT - (FEB24TH & 25TH)

•  Ave 1200 hits/sec @ Edge •  1.75m visitors •  41% to Cisco Datacenter

•  28m hits @ Adobe AEM •  82m hits @ non-AEM (migration

in fy15)

•  Contains ~800K files (.html, .jpg, .gif, .pdf, .mobi and more) [35% of overall cisco.com content] •  ~1.5 TB

Source: Enterprise Operation Intelligence (Splunk) & Akamai Control Panel & Enterprise Web Analytics

•  Always on / Highly Available •  Amazing Global Performance •  Scalable to support cisco.com traffic/volume CISCO SPECIFIC REQUIREMENTS •  Cisco Visibility Needs (Entitlement) •  Personalization/Targetting •  Localization 40 languages, 85 countries •  Auto Generation of product pages as part of New Product Introduction Process •  Content Rendition via CTS : Frame à html|pdf, wordà html|pdf

EXPECTAT IONS FROM AEM ARCHITECTURE

6

WEB ARCHITECTURE

WEM PHYSICAL ARCHITECTURE (PUBLISH)

Cisco DC1 Cisco DC2

Active- Active Multiple Datacenter (Cisco MVDC) Architecture

WEM PHYSICAL ARCHITECTURE (AUTHOR)

§  Single data center presence

§  No Clustering

§  ISSUE - Can not be distributed geographically/DC

Cisco RCDN Datacenter

9

HA AND FAULT TOLERANT

HA PROBING MODEL

§  Web level probes stay at Web level

§  Web won’t go down due to app failure

§  Site Selection at Web and App Level

DC1 Webserver Cisco ACE LB

DC2 Webserver Cisco ACE LB

DC1 AppServer Cisco ACE LB

DC2 AppServer Cisco ACE LB

COMPLETE AEM APP FAILURE SCENARIO

§  All App Servers Down

§  Web still up

§  Serves cached content

§  Independent Alerting via Enterprise Monitoring

DC1 Webserver Cisco ACE LB

DC2 Webserver Cisco ACE LB

DC1 AppServer Cisco ACE LB

DC2 AppServer Cisco ACE LB

12

CACHE IS K ING! !

Dispatcher as Billboard – Proactive Caching Akamai Entitlement Caching Impact Analysis

CACHING IN WEM

Web Client Akamai

Web Server CQ Publish ACE

•  Page load : 2-5 s •  Max request time

within DC: 500ms

Leverage Apache to Stream content (via Adobe dispatcher)

App level caching of High compute objects (ehCache)

Assets + all content caching – guest, customer, etc (flexible cache ID)

Disp

atc

he

r

BROWSER: USER CLIENT CACHING. ASSETS ARE CACHED WITH MAX-AGE=8H. PAGES/DOCUMENTS ARE CACHED WITH ETAG AND MAX-AGE=0. AKAMAI: CDN. EDGE CACHING. GEO DISTRIBUTED. PROVIDES FLEXIBLE CACHE ID BY WHICH MULTIPLE VERSIONS OF AN URL/PAGE CACHEABLE. APACHE: SERVES THE FILES CACHED BY DISPATCHER WITH ETAG. REWRITES INCOMING REQUESTS SUCH THAT THE URL ENCODES VERSION OF THE PAGE AND DISPATCHER SEES DIFFERENT URL FOR DIFFERENT VERSIONS OF A PAGE. DISPATCHER: AN APACHE MODULE THAT STORES CQ RESPONSES IN A FILE UNDER APACHE DOCUMENTROOT. THE FILE IS A REPRESENTATION OF THE URL. CQ: RUNTIME PAGE ASSEMBLY. DATA OF HIGH COMPUTATIONS ARE CACHED IN IN-MEMORY CACHE FOR FAST ACCESS. URL IS RESOLVED INTO CQ NODE WHICH HAS PROPERTIES, TAGS INCLUDING CONCEPTS, DOCTYPE

Caching Layers WEM Caching

Browser

Apache/Dispatcher

CQ

ehCache

Akamai

Sling

END 2 END REQUEST FLOW & CACHING

15

With Caching comes complexity!!!

INCREMENTAL REFRESH DESIGN

Process

AuthorCQ

PublishDispatc

her

Publish CQ

Replication Node

User ActivatePage(s)

ActivationListener

replication events

StartImpact

Analysis

CQ /var[P-cd]

d=d.getParent()

Is d SeriesDoctype or

above?

L-cd=getList of Nodes tagged to

d+c no

For each Node P-cdin List L-cd

P-cd continue

Stop

yes

Note:P-cd is pages tagged to concept c and doctype d that are impacted. This is minimal impacted pages.The URLs are stored in CQ under /var/ia_impacted_pages

Refresh Job {P-cd} interval=15min

For each publish Node N{x=1..8}

GET N:4503/Pi?refresh

For each Page in Set P {i}

http://Nx:4503/Pi?refresh

On Complete

On replicationComplete

replication complete:All publish nodes received the activation

For each publish Web server VIP

V{y=1,2}

For each Page in Set P{i}

GET invalidate Pi http://Vy:80/dipatcher/invalidate.cache?CQ:Handle=Pi

Query-Action Legenddebug - debug infocachemode=refresh - remove app cache for page and rebuild page and populate the cachecachemode=nocache: build page without using app cache

Remove cached filePi.*.html & Pi.html

WEM Cache Refresh Schemefor Dispatcher and App

WEM Architecture

TeamCall /invalidateHandler

ScriptGET V:80/Pi.htmlStore file Pi.hmtlBill Board for anonymous users*

is Tag(s) changed

?

ImpactAnalysis

Stop

noc[],d

For activated Page P-cd, find Tags: Concepts c[]Doctype d

Old Concepts oc[]Old Doctype od

[previous active version]

IA

IA

c[],d

yes

oc!=null?c=change(oc)od!=null?d=od

note: change(oc) is concepts that changed

IA

current page

8 x i

for each concept in c[]

c[],d

c,d/var

/ia_impacted_pages

p1p2p1p3

CQ /var[P-cd]

read max 1000URLs in Set {P}

**

Pi

Logic for U:set property status=completeset time=currentTimemove the node under /var/ia_history

Pi

**Logic for computing Set {P}:url=nextNode()if ({P} has url) {set property status=dupset time=currentTimemove the node under /var/ia_history}elseput url in {P}

With Proactive Caching comes added complexity!!!

17

•  CONTENT TRANSFORMATION

•  MULT I TENANCY

SUPPORTED DOCUMENT TRANSFORMATIONS

Source Format Target Format

book (all file extensions that are members of book will be processed) flb pdf, epub, Mobi

fm (including chapters) html, pdf , (epub, Mobi – only for non-chapters)

doc, docx html, pdf

eps, epsi, ps, svg, tiff jpg

CONTENT RENDITION INTEGRATION

RENDITION PROCESS FLOW

21

MULT I TENANCY

SEPARATE Adobe clusters Virtualized infrastructure

SHARED Adobe Clusters Virtualized infrastructure

1. No Shared Architecture 2. 100% Sharing of Architecture

Imp

lem

en

tatio

n

Ap

pro

ac

h

More Licenses (higher license cost) Better operational insulation More Scalable More autonomy/agility among tenants

Less Licenses (lower license cost) Less operational insulation Less Scalable Less autonomy/agility among tenants

Sta

keh

old

er

Imp

ac

t IT

Imp

lica

tion

Transparent

Different approaches may be used depending on stakeholder needs and impact to existing platform

Transparent

AEM Platform

MULTI TENANCY MODEL

CQ Instance

VM

CQ Instance

VM

CQ Instance

VM

CQ Instance

VM

Tenant2

CQ Instance

CQ Instance

Tenant3

platform Framework (monitoring/instrumentation etc)

Java Code Java Code Component/Theme Code Component/Theme Code

VM VM

•  Why separate CQ Instance?

•  Independent User Store

•  Fault Isolation

•  platform Contract

•  Logical/Physical Architecture

•  CQ Upgrade

•  Product Roadmap

•  Platform framework

•  Tenant Contract

•  Manage Component deployment

•  Manage Java Code Deployment

Tenant1

24

QUEST IONS?