Building Scalalbe Web Sites
Chapter 1 Introduction
Chapter 2 Web Application Architecture
Chapter 3 Development Environments
Chapter 4 i18n, L10n, and Unicode
Chapter 5 Data Integrity and Security
Chapter 6 Email
Chapter 7 Remote Services
Chapter 8 Bottlenecks
Chapter 9 Scaling Web Applications
Chapter 10 Statistics, Monitoring, and Alerting
Chapter 11 APIs
Scale する Web アプリケーションの API はどうあるべきかを検討するための参考書籍として読んだ。
原書で約 320ページと (O'Reilly としては) 比較的薄いので、1日あればサクッと全体を読める。
目次を何も見ずに書籍のタイトルから、3層アーキテクチャ、ロードバランス、
DB レプリケーションやパーティショニングなどの詳細について書かれた技術書だと思っていたが、
実際に読んでみると、開発環境はどうあるべきか、ボトルネックをどのように見つけるか、
サーバの何を監視するかなど、Web アプリケーションを提供するために必要な知識を
満遍なく (広く浅く) 解説している書籍だった。
これから Web アプリを開発するぞ、というときに読むと頭が整理できると思う。
(ただし HOW-TO はあまり載っていない)
著者は Flickr のリードエンジニアだった Cal Henderson。(@iamcal)
ETech2007の会場で会ったことがあるが、
技術的に突っ込んだ話を早口 (もちろん英語) でしゃべるので、全然ついていけなかった記憶がある...
May 2006 発行の書籍なので、この業界としては古い書籍でリンク切れのリソースも散見されるが、
紹介されている個々の技術よりも、Flickr をどのような考えで開発・運用していったのかを
知ることができるのが重要だと思った。ちなみに掲載されているサンプルコードは PHP か Perl。
いまどきの開発としては、クラウドが普及してきているので、書籍に書いてある対策をせずとも、
クラウドを利用すれば解決できるケースもある。
また、当時と比べるとそもそもスケールする必要がないケースも増えているはず。
ウェブアプリケーションサーバを複数台構成とか2010年代には流行らない - kazuhoのメモ置き場
スケールアウトからスケールアップへの回帰:Kenn's Clairvoyance - CNET Japan
それでも、ほとんどは陳腐化しないような基礎的な知識の紹介なので、いま読んでも損はなかった。
そして、通読した最後にやってくる言葉が実にカッコよかった。
We've delivered a bulletproof, scalable, and well-architected application.
Now it's time to start over on a new one, and save the world all over again.
こんな事を言えるようになりたい！
以下、読書時のメモ。(他人が読んで分かるようには書いていない)
Chapter 2 Web Application Architecture
Layerd Software Architecture
English (not Canadian) trifle みたいにつくる
Flicker の写真で説明しているところは「らしい」Software Interface Design
Separate logic code from markup code
Split markup code into one file per page
Switch to a templating systemHardware platform:
Buy commodity hardware
Use a pre-build OS
Use pre-build softwareChapter 3 Development Environments
The Three Rules
Use source control
Have a one-step build
Track your bugsEditing Live -> Creating a Work Environment
Development
Personal development environments (with a single shared development environment)
Staging
Sync and then pause development
The develoment hardware and data platform may react differently (The usual suspect: database performance)
Sub-staging
Production
Step1 Develop
Step2 Commit and stage
Step3 DeployRelease Management
Reduce the amount of time the head of the main branch is in an "undeployable" state.
avoid checking in un-tested code
for complicated features: using branchesWhat Not to Automate
Database schema changes
Software and hardware configuration changesIssue Management Strategy
Microsoft "zero defects methodology": fix bugs before working on new features
like Test Driven?
CADT http://www.jwz.org/doc/cadt.htmlScaling the Development Model
Coding Standards
It's more important for people on a team to agree to a single coding style than it is to find the perfect style.
Chapter 4 i18n, L10n, and Unicode
UTF-8Chapter 5 Data Integrity and Security
Good, Valid, and InvalidChapter 6 Email
Unit Test cases are getting biggerChapter 7 Remote Services
Fig.7-3 A hybrid asynchronous callback and ticketing system
Lightweight Protocols
Rolling Your Own
a middlleware layer that dealt with file storage.
NFS -> SCP -> ownChapter 8 Bottlenecks
Premature optimization is the root of all evil (or at least most of it) in programming.
http://xdebug.org/
CPU time is not often a problem with web applications. (if so, you have a problem with basic design)
Chapter 9 Scaling Web Applications
The Scaling Myth
What Is Scalability?
The system can accommodate increased usage.
The system can accommodate an increased dataset.
The system is maintainable.
Vertical Scaling
Horizontal Scaling
increased administration costs
Redundancy
Load Balancing with Software
Perlbal, Pound, LVS
Database Partitioning (Clustering, Federation)
Caching HTTP Requests
Squid
Scaling in a Nutshell
Design components that can scale linearly by adding more hardware.
If you cant't scale linearly, figure out the return for each piece of hardware added.
Load balance requests between clusters of components.
Take into redundancy account as a percentage of your platform, rather than a fixed number.
Design you components to be fault-tolerant and easy to recover.
Federate large datasets into fixed-size chunks.Chapter 10 Statistics, Monitoring, and Alerting
The Spread Toolkit http://www.spread.org/
Ganglia
NagiosChapter 11 APIs
Data Feeds (RSS, RDF, Atom)
Mobile Content
Web Services
By providing a public API into our core services, we're not just making them available to third parties, but also more available to ourselves.
To be able to use Ajax at the frontend, we need something at the backend for it to request asynchronously.
Providing API kits... (consider outlandish languages)
REST, XML-RPC, SOAP
API Abuse
Monitoring with API Keys
Authentication
None at All
Plain Text (over HTTPS)
Message Authentication Code (MAC)
Token-Based Systems
日本のオライリーから出ている翻訳書はこちら。
O'Reilly の書籍紹介ページはこちら。
http://oreilly.com/catalog/9780596102357
http://www.oreilly.co.jp/books/4873113113/
