Download as PDF, PPTX
More Related Content
Similar to Cloud principles and paradigms kimtea-2010-04-24
![[日本DCの本命、大阪でWindows Azureを愛でる会] Windows Azure 概要 & 最新情報](https://cdn.slidesharecdn.com/ss_thumbnails/20140306jazosakaazure-140308012104-phpapp02-thumbnail.jpg?width=640&height=640&fit=bounds)
Cloud principles and paradigms kimtea-2010-04-24
- 1. クラウドの原理とパラダイム - Cloud Principlesand Paradigms - クラウドDay - 2010/04/24 – @kimtea & @normalian マイクロソフト 新宿オフィス わんくま同盟 東京勉強会 #46
- 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
- 4. このセッションの対象となる方々 • クラウド・コンピューティング –一般のビジネス誌や経済誌で取り上げられるバズワード に関心のある方 – その実態としてレンタルサーバーや既存のサービスのラベ ルを張り替えたものと、どこが違うのか疑問に感じている 方 ちょっと違う世界もありました！ わんくま同盟 東京勉強会 #46
- 5. このセッションの目的 • クラウド・コンピューティング –あらゆる文脈で語ることができる抽象的な概念 – 尐なくともGoogleや米・NIST（国立標準技術研究所）が、 定義するクラウドは、スケーラブルな分散システムである – スケーラブルな分散システムを実現できる、その背景には 様々な理論的な裏付けがある。 – とりあえず動かして、それから裏側の仕組みを理解するこ とが重要！ 理論的な裏付けが重要 わんくま同盟 東京勉強会 #46
- 6. スピーカーの立場 • Twitter – 新しい情報ネットワークによるコミュニケーション形態のひとつ • アニメ「攻殻機動隊」の世界観の実現 – 人間と機械 人の体が機械化したとき、自分とは何か – 自我同一性 ルネ・デカルト「我思う、ゆえに我あり 」 – スタンド・アローン・コンプレックス – Twitterを「ハブ電脳」と見立てる – クラウド ＝ 分散システムである、との認識（イメージ・先入観）を、プ ロデュースすることができるか実験中。 クラウド ＝ 分散システム わんくま同盟 東京勉強会 #46
- 7. スタンド・アローン・コンプレックスとは • アニメ「攻殻機動隊」の世界 –攻殻機動隊の影響を映画「マトリックス」が強く受けている – 脳の機械化という「電脳技術」により、人の脳と脳がコン ピューターのように交信できる世界 – 新たな情報ネットワークにより、独立した個人が、結果とし て集団的総意に基づく行動を見せる社会現象を「スタンド・ アローン・コンプレックス」と言う – 孤立した個人、つまりスタンドアローン（単一ノード）であり ながらも、全体（複数ノード）として集団的な行動（コンプ レックス）をとることから、こう呼ばれる – まさに分散合意問題！ わんくま同盟 東京勉強会 #46
- 8. 社会での具体的な実例 • いわゆる「模倣犯」と呼ばれるもの –オレオレ詐欺・振り込め詐欺・連続放火 – バタフライナイフ・ダガーナイフ • ウェルテル効果による連鎖自殺 – 有名人の死の直後に発生する後追い自殺 – 練炭自殺・硫化水素自殺 • 個人に内包されている問題意識（好奇心）を刺激する – 情報操作や印象操作、プロパガンダ「７つの方策」 – 満州事変、トンキン湾事件、油まみれの水鳥、精密誘導兵器、ボスニア紛争、 ルワンダ内戦など 行動を誘発する わんくま同盟 東京勉強会 #46
- 9. クラウドの原理とパラダイム • クラウドの原理とパラダイム –Windows Azure Platformの概要 – クラウドの定義と、クラウドをクラウドたらしめるもの – データセンター間の地理的レプリケーション（Geo- Replication） – CAP定理とBASE、ACIDの呪縛 – 分散システムにおける同期（クロック） – P2P技術を適用した分散相互排他アルゴリズム わんくま同盟 東京勉強会 #46
- 10. Windows Azure Platformの 概要 わんくま同盟 東京勉強会 #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
- 16. クラウドの定義と、クラウドを クラウドたらしめるもの わんくま同盟 東京勉強会 #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 AzureAppFabric – オンプレミスシステムやWindows Azure Platform上のシ ステムに接続するための機能を提供 • Windows Server AppFabric – Windows Server 2008 RC2向けに提供されるIIS上の ファブリックコントローラー • AppFabricの綴りを間違えやすいので、注意が必要。 • しかし、このようにプロビジョニングの仕組みまで兹 ね備えたプラットフォームは尐ないのが実情。 わんくま同盟 東京勉強会 #46
- 23. データセンター間の地理的 レプリケーション（Geo- Replication） わんくま同盟 東京勉強会 #46
- 24. データセンター間の地理的レプリケーション（Geo-Replication） • Windows Azureストレージサービス – データセンター間の地理的レプリケーション（Geo- Replication） – ユーザーの位置情報（Geo-Location）により実現 • 災害やテロなどの不測の事態により、事業の継続が 困難に陥る可能性があり、それらの予防的措置とし て「ディザスタリカバリー」がある。 わんくま同盟 東京勉強会 #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
- 26. 継続企業（ゴーイングコンサーン） • 一般的に企業は、その企業が継続するという 基礎的前提の上に成り立っている • 情報を提供された者が適切な判断と意志決 定ができるように、経済活動を記録・伝達する 「会計」の世界においては、これら要請とも言 うべき基礎的前提を「会計公準」と呼ぶ。 • 公準＝形式的または実質的な前提 わんくま同盟 東京勉強会 #46
- 27. 継続企業とBCP（業務継続計画） • 会計公準は、企業実体・継続企業・貨幣的評価の3 つ公準（前提）によって構成される • このうち「継続企業の公準」では、企業は永遠に継続 するもの、すなわち「継続企業（ゴーイングコンサー ン）」であると仮定している • このような考えから、企業は事業を継続する社会的 使命と責任を帯びているとされ、いわゆる「BCP（業 務継続計画）」を策定する動きがある わんくま同盟 東京勉強会 #46
- 28. CAP定理とBASE、ACIDの 呪縛 わんくま同盟 東京勉強会 #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
- 33. 入れ子トランザクション • 2つの異なる独立したデータベースとは？ • 例えば、海外旅行の際に、航空機のチケットとホテ ルの部屋を同時に予約した場合に、航空会社の データベースとホテル会社はそれぞれデータベース を有している • これら個別の独立したデータベースが連携している 際に、それぞれのデータベースごとに、サブトランザ クションがはしることになる わんくま同盟 東京勉強会 #46
- 34. 分散トランザクション • Google AppEngineでの分散トランザクション – 複数の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
- 35. 入れ子と分散トランザクションの違い • 入れ子トランザクションと分散トランザクションの差異 は微妙であると思われがちであるが、重要である。 • 分散トランザクションの問題は、データのロック、トラ ンザクション全体のコミット、そして分散相互排他ア ルゴリズムが必要となる点 • ローカルトランザクションとは、従来までのリレーショ ナルデータベースなどの即時応答性の要求される ACIDトランザクションのこと わんくま同盟 東京勉強会 #46
- 36. 分散システムにおける同期（クロック） • 分散システムでは、各ノード（個別サーバー）間で内 部的な一貫性を保ち、外部に対しては整合性を保た なければならない • 何らかの方法でシステムが「グローバルな状態」を把 握しておく必要がある。これら各ノード間の協調、す なわち「同期」の問題が生ずる わんくま同盟 東京勉強会 #46
- 37. 論理クロックと物理クロック • これら同期アルゴリズムを慣習として、「論理 クロック（logical clock）」と呼ぶ。 • クロックには、論理クロックと物理クロックがあ り、物理クロックとは、腕時計や壁掛け時計の ような日常生活で用いる「時計」のことである。 わんくま同盟 東京勉強会 #46
- 38. レスリー・ランポートの論理クロック • コンピューターシステムにおける「時間」は、内部的 な一貫性、すなわち「同期」が保たれていれば良い のであって、必ずしも物理クロックと同じ時を刻んで いる必要性はない • 分散システムにおいては、各ノード間の「同期」が本 質ではなく、メッセージをやり取りする、一連の協調 活動の「全順序性」であることを、レスリー・ランポー トは1978年のクロック同期に関する論文で示した。 わんくま同盟 東京勉強会 #46
- 39. Vector Clock • 分散システムにおける「グローバルな状態」すなわち、 内部的な一貫性を知るための「論理クロック」は、各 ノード間の因果性（結びつき）を把握できないために 「Vector Clock」が提案される • このVector Clockのひとつである「Interval Tree Clocks」をApache Cassandraでは実装しようと試み ている • 多くの分散ファイルシステムが苦手とする削除にお いて、「廃棄（Tombstones）の有効期間」を設定し、 Gossipプロトコルにより伝播させる わんくま同盟 東京勉強会 #46
- 40. P2P技術を適用した分散 相互排他アルゴリズム わんくま同盟 東京勉強会 #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
- 47. ご静聴、Azaas!タイムラインのみんなに感謝！ http://twitter.com/kimtea/status/10012523378 わんくま同盟 東京勉強会 #46