Googleのデザインパターンがイメージしずらかったので、例を加えてみる
グーグルが構築した大規模システムの現実、そしてデザインパターン（4）～デザインパターン編 － Publickey
パターン：Sigle Master, 1000s of Workers
冷蔵庫から飲み物を取るのにはそれほど負荷はかからないが、冷凍倉庫から大量の冷凍食品を販売店の在庫に移すには負荷がかかるので、トラックなどの運搬会社に頼む。冷凍倉庫は問屋などの取引先となるが、つぶれたら困るので複数かけもちで在庫を確保しておく。当然運搬会社も複数に依頼して保険をかけておく。こうしておくことで大量のお客様ニーズに応えられるので良いサービスを提供できる。
パターン：Canary Requst
Canaryとはカナリアである。
いわゆる炭鉱のカナリアは、炭鉱においてしばしば発生するメタンや一酸化炭素といった窒息ガスや毒ガス早期発見のための警報として使用された。本種はつねにさえずっているので、異常発生に先駆けまずは鳴き声が止む。つまり危険の察知を目と耳で確認できる所が重宝され、毒ガス検知に用いられた。
これはイメージがわきやすい。
全国規模の量販店は、はじめにモデル地区の店舗で試して、問題や改善点などを洗い出してから、全国展開する。
パターン：Tree Distribution of Request
一人で１０００人に電話するよりも、そのなかで数十名のえらい人に電話することで全体にいきわたらせるというパターンです。
サマーウォーズでおばあちゃんが警視総監に電話してたりした描写がありましたね。
パターン：Multiple Smaller Units per Machine
クラッシュっていうと悪いことのように聞こえますが、実はマシンがクラッシュするのは当たりまえ。むしろ使っていればいつかはクラッシュします。これはホテル業で考えてみます。お部屋を宿泊客が使用すると使用済みになって、清掃が必要になりますよね。そこで、何十階もの建物で、何十人もの清掃担当者で取り掛かる場合を想定します。
フロア単位や区画単位で担当チームを分けて、チェックアウトの早いエリアから分担してリカバリしていけば無駄なくスムーズにリカバリできる。
パターン：Range Distribution of Data, not Hash
キーバリュー型データストアの詳細はこちら
分散キー・バリュー型データストアって要するに何？ - 鳥さんの独り言
http://www.shudo.net/article/Software-Design-201002-KVS/
mixiの２日間ダウンのあれ（memcached）関連です。
複数支店がある会社が、業務が滞ることなく新たな支店を追加する方法かな？ちょっとむずかしいｗ
パターン：Elastic Systems
回転すし屋のお皿は平日は少なくて済むけど、土日祝にはお客さんが多く入るので通常のキャパの２倍は用意しているってことかな。（違う気がする
パターン：One Interface, Multiple Implementations
課題を細かく分けてそれぞれを解決する。グーグル先生そのもの。
