Weitere ähnliche Inhalte Ähnlich wie Cloud principles and paradigms kimtea-2010-04-24 (20) Mehr von Kazuki Aranami (17) Kürzlich hochgeladen (11) 2. 自己紹介
• ハンドルネーム：(･∀･)キムティ♪
– 荒浪一城（アラナミカズキ）
– 1983年生まれ、静岡県島田市出身
– 丸山先生が社会人を対象としたリカレント教育を目的に東京・市ヶ谷
に設置した、稚内北星学園大学東京サテライト校を卒業
– http://twitter.com/kimtea
• はてなダイアリー
– 404 ないわー (･∀･)キムティ♪ Not Foundの日記
– http://d.hatena.ne.jp/kazuki-aranami/
わんくま同盟 東京勉強会 #46
3. アジェンダ
• はじめに
– このセッションの対象・目的、そしてスピーカーの立場
– スタンド・アローン・コンプレックス
• クラウドの原理とパラダイム
– Windows Azure Platformの概要
– クラウドの定義
– クラウドをクラウドたらしめるもの
– データセンター間の地理的レプリケーション（Geo-Replication）
– CAP定理とBASE、ACIDの呪縛
– 分散システムにおける同期（クロック）
– P2P技術を適用した分散相互排他アルゴリズム
わんくま同盟 東京勉強会 #46
5. このセッションの目的
• クラウド・コンピューティング
– あらゆる文脈で語ることができる抽象的な概念
– 尐なくともGoogleや米・NIST（国立標準技術研究所）が、
定義するクラウドは、スケーラブルな分散システムである
– スケーラブルな分散システムを実現できる、その背景には
様々な理論的な裏付けがある。
– とりあえず動かして、それから裏側の仕組みを理解するこ
とが重要！
理論的な裏付けが重要
わんくま同盟 東京勉強会 #46
6. スピーカーの立場
• Twitter
– 新しい情報ネットワークによるコミュニケーション形態のひとつ
• アニメ「攻殻機動隊」の世界観の実現
– 人間と機械 人の体が機械化したとき、自分とは何か
– 自我同一性 ルネ・デカルト「我思う、ゆえに我あり 」
– スタンド・アローン・コンプレックス
– Twitterを「ハブ電脳」と見立てる
– クラウド ＝ 分散システムである、との認識（イメージ・先入観）を、プ
ロデュースすることができるか実験中。
クラウド ＝ 分散システム
わんくま同盟 東京勉強会 #46
7. スタンド・アローン・コンプレックスとは
• アニメ「攻殻機動隊」の世界
– 攻殻機動隊の影響を映画「マトリックス」が強く受けている
– 脳の機械化という「電脳技術」により、人の脳と脳がコン
ピューターのように交信できる世界
– 新たな情報ネットワークにより、独立した個人が、結果とし
て集団的総意に基づく行動を見せる社会現象を「スタンド・
アローン・コンプレックス」と言う
– 孤立した個人、つまりスタンドアローン（単一ノード）であり
ながらも、全体（複数ノード）として集団的な行動（コンプ
レックス）をとることから、こう呼ばれる
– まさに分散合意問題！
わんくま同盟 東京勉強会 #46
8. 社会での具体的な実例
• いわゆる「模倣犯」と呼ばれるもの
– オレオレ詐欺・振り込め詐欺・連続放火
– バタフライナイフ・ダガーナイフ
• ウェルテル効果による連鎖自殺
– 有名人の死の直後に発生する後追い自殺
– 練炭自殺・硫化水素自殺
• 個人に内包されている問題意識（好奇心）を刺激する
– 情報操作や印象操作、プロパガンダ「７つの方策」
– 満州事変、トンキン湾事件、油まみれの水鳥、精密誘導兵器、ボスニア紛争、
ルワンダ内戦など
行動を誘発する
わんくま同盟 東京勉強会 #46
9. クラウドの原理とパラダイム
• クラウドの原理とパラダイム
– Windows Azure Platformの概要
– クラウドの定義と、クラウドをクラウドたらしめるもの
– データセンター間の地理的レプリケーション（Geo-
Replication）
– CAP定理とBASE、ACIDの呪縛
– 分散システムにおける同期（クロック）
– P2P技術を適用した分散相互排他アルゴリズム
わんくま同盟 東京勉強会 #46
11. ひとくちに「Azure（アジュール）」と言っても・・・
Web Role
Windows Azure Windows Azure コン
Platform ピュートサービス
Worker Role
SQL Azure データベース
サービス
Windows Azure ストレー
BLOB
ジサービス
Table
Queue
Drive
わんくま同盟 東京勉強会 #46
12. Windows Azure コンピュートサービス
– Web Role サーバー
• インターネットから直接アクセス可能
• .NET FrameworkとIISがインストールされたタイプの
Webサーバー
– Worker Role サーバー
• インターネットから基本的には直接アクセスできない
• .NET Frameworkのみがインストールされたタイプの
バッチアプリケーション向けのサーバー
わんくま同盟 東京勉強会 #46
13. SQL Azure データベースサービス
– オンプレミス型SQL Server 2008の改良版
– 従来のリレーショナルデータベースと同じ表形式
– スケーラブルなリレーショナルデータベース
– 見せてもらおうか、あずにゃんの性能とやらを。
Microsoft Tech･Days 2010 セッション資料＆ビデオ
http://www.microsoft.com/japan/events/techdays/2010/
tech Days 2010 Japanの資料一括ダウンローダ
http://techbank.jp/Community/blogs/nora/archive/2010/04/11/26227.a
spx
わんくま同盟 東京勉強会 #46
14. Windows Azure ストレージサービス
• Windows Azure BLOB ストレージ
– 映像や音声、文章、圧縮ファイルなど巨大なバイナリデータの格納に
最適、よくあるFTPプロトコルではなくHTTP RESTプロトコルを用いて
ファイルをアップロードする
• Windows Azure Table ストレージ
– 典型的なKey-Value Store（KVS）のひとつ。複数のノード間をまたぐ
ような処理を行うと著しく性能が务化するためPartitionKeyの設計が
重要
• Windows Azure Queue ストレージ
– Web Role サーバーと Worker Role サーバー間をキューにより非同
期通信を行う場合に用いる
• Windows Azure Drive ストレージ
– ローカルのストレージに比べ速度が遅いものの、アプリケーションから
NTFSドライブのように見せることで、通常のAPIでアクセスが可能
わんくま同盟 東京勉強会 #46
15. それなんてAzure？
• 単に「Azure（アジュール）」だけでは、Windows Azure
Platform全体を指しているのか、個別のサービスを指し示し
ているのか、わかりにくく混乱を招きやすい。
• 情報が錯綜する黎明期においては、「それなんてAzure？」と
無用な混乱を避けるためにも、Windows Azure用語の表記
には、その正確性について最大限の配慮をした方が良い
• 例えば、公式サイトでもWindows Azure PlatformとWindows
Azure platformと、大文字の「P」と小文字の「p」で表記が異
なる。果たして、どちらが正しいのか？こまけぇことだが気に
なるお・・・
わんくま同盟 東京勉強会 #46
17. クラウドの定義
• クラウド・コンピューティング
– コモディティ化した廉価なコンピューターリソース
– スケールアウトの技術を使って並列化し、規模の
経済性を確保
– 動的なリソースの割り当てという、プロビジョニン
グの仕組み
– 保守運用の手間を省く
• これら「クラウドの要件」が揃うことで、はじめ
て圧倒的なコスト削減が実現可能となる。
わんくま同盟 東京勉強会 #46
18. スケールアウトの技術（分散データベース）
• Google BigTable
• Amazon Dynamo / SimpleDB
• Oracle Coherence
• IBM WebSphere eXtreme Scale
• Windows Azure Table ストレージ（Microsoft）
• Yahoo! Research PNUTS/Sherpa
• Apache Cassandra（Facebook、Twitter、RackSpace）
• kumofs（えとらぼ）
• ROMA（楽天）
• Tokyo Cabinet / Tokyo Tyrant（mixi）
• Flare（グリー）
• Kai（NTT未来ねっと研究所）
わんくま同盟 東京勉強会 #46
19. クラウドをクラウドたらしめるもの
• ファブリックコントローラー（Fabric Controller）
– Windows Azure Platformでのプロビジョニングを担当
• プロビジョニング
– トラフィックの流量によって、キャパシティー（受け入れ可能
な能力）にあわせてインスタンスを動的に増減させること。
– Elastic（エラスティック）：伸縮性のある・弾力性のある
• スケールアウトの技術でコモディティ化したサーバー
を並列化できても、その運用管理が大変に。
• これらの前提条件として、「仮想化」がある！！
わんくま同盟 東京勉強会 #46
20. ファブリックコントローラーの仕組み
• ノードの配置というプロビジョニングの部分
– 分散ハッシュテーブル（DHT）
• ノードの存在をネットワーク上に通知し、分散化した
ディレクトリサービスを実現
– Decentralized Object Location and Routing (DOLR)
• P2Pクラスタ（首藤先生とか、そのあたり）に期待！
– 動的に増減させるファブリックコントローラーの謎解きが、
仮想化（自動化や効率化）の文脈において重要
– Towards a Common API for Structured Peer-to-Peer
Overlays
– http://oceanstore.cs.berkeley.edu/publications/papers/pdf/iptps03-
api.pdf
わんくま同盟 東京勉強会 #46
21. クラウドをクラウドたらしめるプロビジョニング
• AppFabric
– プロビジョニングを司るファブリックコントローラー
と、Webアプリケーション基盤である.NET
Servicesを統合したもの
– Windows Azure AppFabricとWindows Server
AppFabricの2つ
わんくま同盟 東京勉強会 #46
22. AppFabric
• Windows Azure AppFabric
– オンプレミスシステムやWindows Azure Platform上のシ
ステムに接続するための機能を提供
• Windows Server AppFabric
– Windows Server 2008 RC2向けに提供されるIIS上の
ファブリックコントローラー
• AppFabricの綴りを間違えやすいので、注意が必要。
• しかし、このようにプロビジョニングの仕組みまで兹
ね備えたプラットフォームは尐ないのが実情。
わんくま同盟 東京勉強会 #46
25. ディザスタリカバリー
• Windows Azure ストレージサービスでは、CDNサー
ビスにより北米・アジア・EUなどの各地域ごとのデー
タセンター間で「地理的レプリケーション（Geo-
Replication）」を提供している。
とあるコンサルタントのつぶやき : Part 2. Windows Azure Platform 概要 その1
http://blogs.msdn.com/nakama/archive/2010/01/14/windows-azure-platform-1.aspx
わんくま同盟 東京勉強会 #46
27. 継続企業とBCP（業務継続計画）
• 会計公準は、企業実体・継続企業・貨幣的評価の3
つ公準（前提）によって構成される
• このうち「継続企業の公準」では、企業は永遠に継続
するもの、すなわち「継続企業（ゴーイングコンサー
ン）」であると仮定している
• このような考えから、企業は事業を継続する社会的
使命と責任を帯びているとされ、いわゆる「BCP（業
務継続計画）」を策定する動きがある
わんくま同盟 東京勉強会 #46
29. CAP定理とBASE、ACIDの呪縛
• トランザクションとは、「取引」を意味し、相手とのやりとりを通
じて、最終的に「合意」に至るまでの一連のプロセス（処理単
位）を指す
• また、トランザクションは、そのプロセスがやりとりする範囲
（処理単位）が、成功または失敗のどちらか一方で終わる、と
いうオールオアナッシングの考えに基づいている
• 典型的なトランザクションは、リレーショナルデータベースにお
ける銀行口座やオークションなどの事例モデルである
• これらは、即時応答性の要求される「ACIDトランザクション
（フラットトランザクション）」と呼ばれるタイプのトランザクショ
ンである
わんくま同盟 東京勉強会 #46
30. ACIDトランザクション
• 即時応答性の要求されるACIDトランザクションは、銀行口座
やオークションなどの事例モデルでは有効だが、インターネッ
トの商取引モデルを描くには限界がある
• ショッピングサイトでの買い物も「取引」であり、最終的に商品
が消費者の手元に到着するまで数日かかるという「合意」に
至るまでの、一連のプロセスもまたトランザクションである
• Eric Brewer（エリック・ブリューワー）のCAP定理
– 数学的に証明された「定理」ではない
– Consistency（一貫性、コンシステンシー）
– Availability（可用性、アベイラビリティー）
– Partition-tolerance（分割または分散耐性、パーティショントレランス）
– ACIDな共有システムでは、上記のうち2つを選択する必要がある
わんくま同盟 東京勉強会 #46
31. BASEトランザクション
• インターネットの商取引のような事例をモデルにすると、トラン
ザクションの処理単位が数日に渡ることがある。これのような
トランザクションを「BASEトランザクション（分散トランザクショ
ン）」と呼ぶ。
• Eric Brewer（エリック・ブリューワー）のBASE
– Basically Available（ベイシカリーアベイラブル）
– Soft-state（ソフトステイト）
– Eventual Consistency（イベンチュアルコンシステンシー）
• 結果整合性、いつか整合性がとれる
– Towards Robust Distributed Systems
– http://www.cs.berkeley.edu/~brewer/cs262b-2004/PODC-keynote.pdf
わんくま同盟 東京勉強会 #46
32. トランザクションモデル
• グローバルトランザクション
– 複数のリソースにまたがるトランザクション
• ローカルトランザクション
– 単一リソース内のトランザクション
• グローバルトランザクションのさらなる分類
– 2つの異なる独立したデータベースにそれぞれサブトラン
ザクションがはしるトランザクションを「入れ子トランザク
ション」
– 同一の分散データベース内の論理的に分割不可能なサブ
トランザクションがはしるトランザクションを「分散トランザク
ション」
わんくま同盟 東京勉強会 #46
34. 分散トランザクション
• Google App Engineでの分散トランザクション
– 複数のEntity Groupをまたぐ処理、論理的に分割不可能な処理単位
– 冪等（べきとう、 idempotent）な処理
• 何度繰り返し処理を行っても結果が同じである
• ユニーク制約とトランザクションの合成
– Exactly Once
• 最大一回だけ成功する処理を無限に繰り返す、いずれ成功する
• 冪等（べきとう、 idempotent）な処理とTask Queue
– BASE Transaction
• 自分を変更後、相手の変更を確実に一度だけ適用
• read-modify-writeとExactly Onceのトランザクションを合成する
– Transaction Puzzlers（@ashigeru）
http://ashigeru.com/ajn-source/ajn4-arakawa.ppt
わんくま同盟 東京勉強会 #46
38. レスリー・ランポートの論理クロック
• コンピューターシステムにおける「時間」は、内部的
な一貫性、すなわち「同期」が保たれていれば良い
のであって、必ずしも物理クロックと同じ時を刻んで
いる必要性はない
• 分散システムにおいては、各ノード間の「同期」が本
質ではなく、メッセージをやり取りする、一連の協調
活動の「全順序性」であることを、レスリー・ランポー
トは1978年のクロック同期に関する論文で示した。
わんくま同盟 東京勉強会 #46
39. Vector Clock
• 分散システムにおける「グローバルな状態」すなわち、
内部的な一貫性を知るための「論理クロック」は、各
ノード間の因果性（結びつき）を把握できないために
「Vector Clock」が提案される
• このVector Clockのひとつである「Interval Tree
Clocks」をApache Cassandraでは実装しようと試み
ている
• 多くの分散ファイルシステムが苦手とする削除にお
いて、「廃棄（Tombstones）の有効期間」を設定し、
Gossipプロトコルにより伝播させる
わんくま同盟 東京勉強会 #46
41. P2Pと複雑ネットワーク
• Vector ClockからP2Pへ
– Vector Clockは、因果性の制約が守られている（お互いに
結びついている）ときのみに、メッセージの配信（やりとり）
ができる。このため、これらは次第に通信の問題へと変化
していき、P2Pのモデルが提起される。
• 複雑ネットワーク
– 六次の隔たり：人は自分の知り合いを6人以上介
すと世界中の人々と間接的な知り合いになれる、
という仮説。P2Pにおける「経路長」に相当
– ランダムグラフによる複雑ネットワークを応用した
理論。
わんくま同盟 東京勉強会 #46
42. 分散相互排他アルゴリズム
• 分散システムにおいて、「グローバルな状態」を知るための同
期アルゴリズムには、ブリー選任アルゴリズム、障害性に考
慮した円形状のリングアルゴリズム、そして単一障害点
（SPOF）をなくすという観点の分散相互排他アルゴリズムな
どが考案されている
• 分散相互排他アルゴリズムでは、整合性モデルとしてBASE
に基づくEventually Consistency（イベンチュアルコンシステ
ンシー、結果整合性）を適用し、遅延を許容する
• この考えを適用した、クラウド基盤ではレイテンシーが問題に
なる。このため、高速な光ファイバー、距離の近いデータセン
ター、そしてキャッシュを取り入れたCDNサービスを組み合わ
せなければ解決することはできない
• 例：Google Public DNS、Google Fiber for Communities、Akamai
わんくま同盟 東京勉強会 #46
43. P2P技術を適用した分散相互排他アルゴリズム
• Google
– Paxosプロトコル
– 分散トランザクションマネージャー「Chubby」と「Google Megastore」
– Microsoftのレスリー・ランポートがPaxosのオリジナル特許を保持
– Google App Engineで2009年9月22日にGoogle Megastoreへ移行
• Oracle Coherence
– TCMPプロトコル
• Apache Hadoopファミリー
– Zookeeper：Zabプロトコル （同一のデータセンター内に限る）
• Windows Azure
– ChordプロトコルとPastryプロトコルを掛け合わせた
– 両方向版Chordプロトコルとでも呼ぶべき改良版
わんくま同盟 東京勉強会 #46
44. 分散コンピューティングの落とし穴
（Fallacies of Distributed Computing）
• ネットワークは信頼できる（The network is reliable）
• レイテンシーはゼロである（Latency is zero）
• 帯域幅は無限である（Bandwidth is infinite）
• ネットワークはセキュアである（The network is secure）
• ネットワーク構成は変化せず一定である（Topology doesn‘t
change）
• 管理者は1人である（There is one administrator）
• トランスポートコストはゼロである（Transport cost is zero）
• ネットワークは均質である（The network is homogeneous）
分散システムは、ネットワークが課題
わんくま同盟 東京勉強会 #46
45. 参加者募集のお知らせ
• Apache CassandraのWiki翻訳中
– 金銭的な報酬とか一切ないけど、参加者募集
– 興味のある分野を翻訳ついでに勉強する感じ
– http://wiki.apache.org/cassandra/FrontPage_JP
• 同時に募集中
– nosql-ja
– http://groups.google.com/group/nosql-ja
– Hadoopユーザー会
– http://groups.google.co.jp/group/hadoop-jp
わんくま同盟 東京勉強会 #46
46. 参考文献
• とあるコンサルタントのつぶやき
– http://blogs.msdn.com/nakama/
• 財務会計論
– http://www.amazon.co.jp/dp/4495141937/
• 分散システム 原理とパラダイム
– http://www.amazon.co.jp/dp/4894714981
わんくま同盟 東京勉強会 #46
