We Built This City - Apigee Edge Architecture
Download as PPTX, PDF•6 likes•1,742 views
This document discusses the technical challenges of building and maintaining APIs at a global scale. It notes that APIs must be highly available, globally distributed with no downtime, rigorously monitored, and secure from attacks. It outlines Apigee's approach of using services like Zookeeper, Cassandra, and analytics platforms to distribute data and configurations globally, implement features like quotas and abuse detection, and manage high volumes of data and traffic with five-nines availability. The document also stresses the importance of managing the API platform itself with the same availability and reliability standards as the APIs.
We Built This City - Apigee Edge Architecture
- 1. 1 We Built This City Greg Brail, Apigee Sridhar Ragagopalan, Apigee Chris Vogel, Apigee
- 2. The State of the API Today • Every API call counts – No one wants to see timeouts, 500s, stack traces, etc. • APIs are 24x7 – Even more than the web, API users expect that there is no downtime • APIs are global – Clients and users expect low latency, around the world • Threats are global – Every API may be under attack, in some way, at any point
- 3. What does that Mean for Us? • Global distribution • Upgrades without scheduled downtime • Rigorous monitoring • Attention to detail 3©2015 Apigee. All Rights Reserved.
- 4. Our Challenge • What our customers expect: – >99.99% availability as defined by the number of transactions that complete successfully – Geographically distributed across data centers – In the Apigee Cloud or their own data centers – No maintenance windows – No regressions – Acceptable latency – All the features we have plus just one more ;-) 4
- 7. A More Jaded View 7 Clients on the Internet Apigee Our customers’ systems Inspired by Kyle Kingsbury: https://aphyr.com/
- 8. What do we Deal With? • Insecure APIs • Attacks on security • Intentional API attacks • Accidental denial of service • Buggy clients • Buggy servers • Disagreement about what HTTP means • Hard to use APIs • Slow customer systems • Lousy customer data centers • Confused developers • Plenty of our own issues 8
- 9. What Does it Look Like? 9 Clients (Apps, etc) Customers’ APIs Routing Message Processing Runtime Data Analytics Data Management
- 11. Types of Data At Apigee Type How Many Records? How Often do we Write? Storage System configuration 1000s 10s / minute Zookeeper Customer Proxy Deployments 100,000s 10s / minute Zookeeper / C* API Publishing Data (developers, apps, keys) Millions 10s / second C* OAuth Tokens & metadata Tens of millions 10,000s / second C* Counters / Quotas Millions 10,000s / second C* Distributed Cache Tens of millions 10,000s / second C* API Analytics Data Billions 10,000s / second Postgres / RedShift / S3 11
- 13. Challenge #1: Counting* • What we need: • Application X is allowed to make 10,000 API calls per hour for free – Across geographies – Less than a 0.01% error rate – Minimal latency • Application Y is allowed to make 1,000,000 API calls per hour because they paid – Warn them before they reach a million – Cut them off if they exceed it – Charge them accurately for each API call • Control the tradeoff between accuracy and latency – We’d love to be able to talk rationally about this with customers 13 * That was a joke
- 14. Counting in Distributed Systems • What we can do: • Central system that holds all counters – Would be perfectly accurate, but obviously no • Distributed consensus protocol across all servers – Too slow especially across geographies • Eventually consistent counters – Yes! But how? • Cassandra counters – Write availability in the presence of network partitions – Still too slow • Cassandra counters plus local caching – Best we can do right now 14
- 15. Challenge #3: Detecting Abuse • APIs are nice and open and easy to program • That makes them easy to exploit – Travel APIs – Retail APIs – Other open APIs • 80% of traffic on one retail customer’s retail API was from “bots” – Scraping prices, availability, etc. • 56% of all web site traffic purportedly comes from bots 15
- 16. Detecting Bad Traffic • Long-term batch analytics processing – Machine learning + data + heuristics • For instance – U.S. Retailers don’t have many customers in Romania – iPads tend not to reside inside Amazon Web Services data centers – Real people tend not to query product SKUs starting at “000000” and proceeding to “999999” – Real people don’t check on100 rooms at the same hotel and never book • Solution includes: – Batch processing to update bot scoring – Bloom filters at router layer – Lookup table and other processing for other traffic 16
- 17. Challenge #4: Management • We are largely a management system – 1000s of new API proxies deployed per day to our cloud – Each one includes customer-specific processing rules, policies and code – API calls coming in for analytics queries, to change rate limits, set up developers, etc. • Systems architects tend to give management short shrift – “It’s OK if the management system fails as long as the API calls keep working” • Need to architect management for the same SLA as everything else – So we use Cassandra and Zookeeper here too 17
- 18. Finally: Lessons from the Cloud • Hardware fails. So what? • Network fails. Bad but expected. • Management layer fails. Big problem. – See history of AWS outages 18
- 19. Thank you ©2015 Apigee. All Rights Reserved.