apereo oae - architectural overview
DESCRIPTION
This session provides an overview of the Apereo OAE architecture and the major additions in the past 12 months. The Apereo Open Academic Environment is built from the ground up as a multi-tenant platform designed to host many organizations on a shared infrastructure in the cloud. This session introduces the following architectural components: - Node.js - Apache Cassandra - ElasticSearch - RabbitMQ - Redis - Nginx and the following concepts: - Push notifications - Email aggregation - Performance testing - Production environment - Development to deployment - Responsive UITRANSCRIPT
APEREO OAEArchitectural Overview, Miami 2014
TOPICS 1. OAE Project
2. Hilary System Architecture
3. Push Notifications
4. Email Aggregation
5. Performance Testing
6. OAE Production Environment
7. Development to Deployment
8. UI Architecture
PROJECT GOALS
• Multi-tenant platform
• Cloud-ready
• SaaS
• Used at large scale
• Cross-institutional
INTEGRATION
• Integrate OAE with other systems
• Integrate other systems with OAE
MULTI-TENANCY• Support multiple institutions on same installation
• Easily created, maintained and configured
• Each institution has its own URL, branding, skinning and users
• Share infrastructure
• Institutions can share and collaborate with other institutions
TOPICS 1. OAE Project
2. Hilary System Architecture
3. Push Notifications
4. Email Aggregation
5. Performance Testing
6. OAE Production Environment
7. Development to Deployment
8. UI Architecture
OAE ARCHITECTUREThe Apereo OAE project is made up of 2 distinct source code platforms:
• “Hilary”
• Server-side RESTful web platform that exposes the OAE services
• Written entirely using server-side JavaScript in Node.js
• “3akai-ux”
• A client-side / browser platform that provides the HTML, JavaScript and CSS that make up the UI of the application
OAE ARCHITECTURE
APPLICATION SERVERS• Written in server-side JavaScript, run in Node.js
• Light-Weight
• Single-Threaded
• Event-Driven
• Non-Blocking
• Uses callbacks/promises and an event queue to stash work to be done after I/O or other heavy processes complete
• App servers can be configured into functional specialization:
• User Request Processor
• Activity Processor
• Search Indexer
• Preview Processor
APACHE CASSANDRA• Authoritative data source
• Provides high-availability and fault-tolerance without trading away performance
• Regarding CAP theorem, Cassandra favours Availability and Partition Tolerance over Consistency, however consistency is tunable on the connection-level (we always use “quorum”)
• Uses a ring topology to shard data across nodes, with configurable replication levels
• Used by: Netflix, eBay, Twitter
ELASTICSEARCH• Lucene-backed search platform
• Built for incremental scaling and high-availability
• Exposes HTTP RESTful APIs for indexing and querying documents
• RESTful query interface uses JSON-based Query DSL
• Powers all of Hilary search functions (Library Search, Members / Memberships Search)
• Used by: GitHub, FourSquare, StackOverflow, WordPress
RABBITMQ• Light-weight message queue platform written in
Erlang
• Used for distributing tasks to specialized application server instances
• Supports active-active queue mirroring for high availability
• Used by: Joyent
REDIS• REmote DIctionary Server
• Fills a variety of functionality in OAE:
• Broadcast messaging (could move to RabbitMQ)
• Locking
• Caching of basic user profiles
• Holds volatile activity aggregation data
• Comes with no managed clustering solution (yet), but has slave replication for active fail-over
• Some clients manage master-slave switching, and distributed reads for you
• Used by: Twitter, Instagram, StackOverflow, Flickr
ETHERPAD• Open Source collaborative editing application written
in Node.js
• Originally developed by Google and Mozilla
• Licensed under Apache License v2
• Powers collaborative document editing in OAE
• Collaborative documents sharded by ID to dedicated Etherpad instances
NGINX
• HTTP and reverse-proxy server
• Used to distribute load to application servers, etherpad servers and stream file downloads
• Useful rate-limiting features based on source IP
• Proxy web socket connections to Hilary and Etherpad
• Used by: Netflix, WordPress.com
TOPICS 1. OAE Project
2. Hilary System Architecture
3. Push Notifications
4. Email Aggregation
5. Performance Testing
6. OAE Production Environment
7. Development to Deployment
8. UI Architecture
PUSH NOTIFICATIONS• Built on top of activity routing infrastructure
• Subscribe to an activity feed using a persistent websocket connection
• Routed activities fed back into RabbitMQ
• Hilary servers subscribe and pass on to persistent HTTP connections
EMAIL AGGREGATION• Built on top of activity aggregation infrastructure
• Schedules email to be sent for a user based on email preference and timezone (“immediate”, daily, weekly)
• When delivered, collects activity in an aggregated “email” activity stream
• Builds HTML email based on activities available
NEW INFRASTRUCTURE
TOPICS 1. OAE Project
2. Hilary System Architecture
3. Push Notifications
4. Email Aggregation
5. Performance Testing
6. OAE Production Environment
7. Development to Deployment
8. UI Architecture
PERFORMANCE TESTING
TOPICS 1. OAE Project
2. Hilary System Architecture
3. Push Notifications
4. Email Aggregation
5. Performance Testing
6. OAE Production Environment
7. Development to Deployment
8. UI Architecture
PRODUCTION ENVIRONMENT• 3 x Cassandra
• 2 x ElasticSearch
• 4 x Application (Hilary)
• 3 x Activity (Hilary)
• 3 x Preview Processor (Hilary)
• 3 x Etherpad
• 2 x Application Cache (Redis)
• 2 x Activity Cache (Redis)
• 1 x HAProxy
• 2 x RabbitMQ
• 2 x Nginx
• 1 x Monitoring
• 1 x Syslog
• 1 x Bastion
• 1 x Puppet Master
PRODUCTION ENVIRONMENTVM Specs (RAM / # CPUs)
• Cassandra (8GB / 8)
• ElasticSearch (4GB / 2)
• App / Activity (512MB / 1)
• Preview Processor (1GB / 2)
• Etherpad (1GB / 1)
• Redis (512MB / 1)
• HAProxy (512MB / 1)
• RabbitMQ (512MB / 1)
• Nginx (1GB / 2)
• Monitoring (4GB / 2)
• Syslog (512MB / 1)
• Bastion (512MB / 1)
• Puppet Master (4GB / 2)
TOPICS 1. OAE Project
2. Hilary System Architecture
3. Push Notifications
4. Email Aggregation
5. Performance Testing
6. OAE Production Environment
7. Development to Deployment
8. Responsive Design
FROM DEVELOPMENT TO PRODUCTION
• Github
• Pull-Request, review, iterate, merge
• Travis-CI
• Unit tests, build release artifact, upload to Amazon S3
• Code coverage analysis
• On every commit
FROM DEVELOPMENT TO PRODUCTION
• 2 manual steps
• Update version in puppet manifests
• Roll new version out with single Fabric command
TOPICS 1. OAE Project
2. Hilary System Architecture
3. Push Notifications
4. Email Aggregation
5. Performance Testing
6. OAE Production Environment
7. Development to Deployment
8. UI Architecture
UI ARCHITECTURE
UI ARCHITECTURE
• In essence
• HTML • CSS • JavaScript
• Talks to Hilary via REST APIs
RESPONSIVE UI
• Upgraded to Bootstrap 3
• Fully responsive CSS framework
• New grid system
• A lot of work
RESPONSIVE UI
Get in touch:
E-mail list: [email protected]
Website: http://www.oaeproject.org/
Demo server : http://oae.oae-qa0.oaeproject.org/
