no users, no permissions. nothing. there are lots of
photo processing is a good sample app.
boot in a few minutes
animoto story
simpledb was one of the hardest of the web services to learn
people are starting to look at alternatives to traditional ACID databases. too much overhead, and not scalable enough
very consistent. 100, 10,000, 1,000,000 records all had similar response time.
BASE is optimistic and accepts that the database consistency will be in a state of fluxASE is optimistic and accepts that the database consistency will be in a state of flux
With BASE, we relax the consistency constraint.
2 phase commit with acid makes stuff very hard to make available: availability is the product of the availabilities
there is a lot more to this than we have time for.
Rails in the Cloud
Ian Warshak
I am a developer @ RightScale
http://twitter.com/iwarshak
http://delicious.com/iwarshak/saruby
http://github.com/iwarshak/saruby-cloud
Pictr
• Photo website.
• Photos are uploaded by the public.
• Photos are converted asynchronously by
separate processing servers
• Very simple app, but hopefully shows some
ideas of how cloud computing apps work.
• Seriously, it’s a demonstration app.
Why Pictr?
• Disk Storage
• Bandwidth
• Offline processing
How is it built?
• Web application running on Ec2
• Database is Amazon SimpleDB
• Storage is Amazon S3
• CDN is Amazon Cloudfront
• Messaging queue is Amazon SQS
• ~200 lines of code
Why Amazon?
• Simple. Right now, they are the market
leader... But the competition is good.
• Tight integration between services
• Lots of documentation and libraries
Amazon Ec2
• Servers “on demand”.
• Pay by the hour: $0.10 - $0.80/hour
• Non persistent.
• Forces you to automate your configuration.
• RightScale helps a lot with this.
• Elastic IP can give you a static IP
• Elastic Block Store gives you persistent data
store
Amazon S3
• Oldest of the publicly available web
services
• Scalable, reliable data storage mechanism
• Bucket/object concept
• Pay for the data you are storing, as well as
bandwidth in and out
• $0.15/GB stored. $0.10/GB transferred.
$0.01/request.
CloudFront
• Similar to LimeLight, Akamai
• Low latency, high data rate
transfers
• 8 edge locations in the US
• Origin server is an S3 bucket • Ashburn, VA
• 24 hour object expiration
• Dallas/Fort Worth, TX
• Los Angeles, CA
• Miami, FL
• Very simple API • Newark, NJ
• Palo Alto, CA
• Seattle, WA
• St. Louis, MO
Amazon SimpleDB
• Simple (but powerful) database
• Non-relational. No tables, only “domains”
• No schema. Define it as you go
• All data is stored as strings
• Attributes can have up to 256 values
• Automatically indexes all your data
• Database is typically the first major
bottleneck of a web application
ACID and BASE
• Big trend away from traditional RDBMS
• They carry lots of baggage, and do not scale
horizontally very well
• ACID (Atomicity, Consistency,
Idempotency, Durability)
• BASE (Basically Available, Soft State,
Eventually Consistent)
CAP Theorem
“Choose Two”
• Given: Consistency, Availability, Partition
tolerance. Choose two.
• ACID = CA
• BASE = AP
Other Databases
• SimpleDB (written in Erlang)
• Google BigTable
• CouchDB (written in Erlang. Queries are
written in JS)
• TokyoCabinet
• Berkeley DB
What does this mean?
• I don’t worry about scaling
• Database performance is very consistent
• S3/Cloudfront handles static file serving
• Minimal upfront investment
• Only pay for what I need
• Very quick time to market
Step 1: Upload
S3
web1
redirect on (ec2 instance)
success
POST
pic.jpg
Step 2: Create SQS jobs
class ConvertJob
...
end
jobs = [
#ConvertJob.new(key, \"thumbnail\", \"100x100\"),
#ConvertJob.new(key, \"medium\", \"200\"),
ConvertJob.new(key, \"original\", \"400\"),
ConvertJob.new(key, \"paint\", \"400\", \"-paint 5\"),
ConvertJob.new(key, \"monochrome\", \"400\", \"-monochrome\")
]
# Put the jobs into the SQS queue
sqs = RightAws::SqsGen2.new
convert_queue = sqs.queue(\"convert\")
jobs.each do |job|
convert_queue.send_message job.to_json
end
0 comments
Post a comment