cloud principles and paradigms kimtea-2010-04-24

わんくま同盟東京勉強会 #46

クラウドの原理とパラダイム- Cloud Principles and Paradigms -

クラウドDay - 2010/04/24 –

@kimtea & @normalian

マイクロソフト新宿オフィス


自己紹介

• ハンドルネーム：(･∀･)キムティ♪– 荒浪一城（アラナミカズキ）

– 1983年生まれ、静岡県島田市出身

– 丸山先生が社会人を対象としたリカレント教育を目的に東京・市ヶ谷に設置した、稚内北星学園大学東京サテライト校を卒業

– http://twitter.com/kimtea

• はてなダイアリー– 404 ないわー (･∀･)キムティ♪ Not Foundの日記

– http://d.hatena.ne.jp/kazuki-aranami/

http://twitter.com/kimtea

http://d.hatena.ne.jp/kazuki-aranami/




アジェンダ

• はじめに– このセッションの対象・目的、そしてスピーカーの立場

– スタンド・アローン・コンプレックス

• クラウドの原理とパラダイム– Windows Azure Platformの概要

– クラウドの定義

– クラウドをクラウドたらしめるもの

– データセンター間の地理的レプリケーション（Geo-Replication）

– CAP定理とBASE、ACIDの呪縛

– 分散システムにおける同期（クロック）

– P2P技術を適用した分散相互排他アルゴリズム


• クラウド・コンピューティング

– 一般のビジネス誌や経済誌で取り上げられるバズワードに関心のある方

– その実態としてレンタルサーバーや既存のサービスのラベルを張り替えたものと、どこが違うのか疑問に感じている方

このセッションの対象となる方々

ちょっと違う世界もありました！


このセッションの目的


– あらゆる文脈で語ることができる抽象的な概念

– 尐なくともGoogleや米・NIST（国立標準技術研究所）が、定義するクラウドは、スケーラブルな分散システムである

– スケーラブルな分散システムを実現できる、その背景には様々な理論的な裏付けがある。

– とりあえず動かして、それから裏側の仕組みを理解することが重要！

理論的な裏付けが重要


スピーカーの立場

• Twitter

– 新しい情報ネットワークによるコミュニケーション形態のひとつ

• アニメ「攻殻機動隊」の世界観の実現– 人間と機械人の体が機械化したとき、自分とは何か

– 自我同一性ルネ・デカルト「我思う、ゆえに我あり」

– スタンド・アローン・コンプレックス

– Twitterを「ハブ電脳」と見立てる

– クラウド＝分散システムである、との認識（イメージ・先入観）を、プロデュースすることができるか実験中。

クラウド＝分散システム


スタンド・アローン・コンプレックスとは

• アニメ「攻殻機動隊」の世界

– 攻殻機動隊の影響を映画「マトリックス」が強く受けている

– 脳の機械化という「電脳技術」により、人の脳と脳がコンピューターのように交信できる世界

– 新たな情報ネットワークにより、独立した個人が、結果として集団的総意に基づく行動を見せる社会現象を「スタンド・アローン・コンプレックス」と言う

– 孤立した個人、つまりスタンドアローン（単一ノード）でありながらも、全体（複数ノード）として集団的な行動（コンプレックス）をとることから、こう呼ばれる

– まさに分散合意問題！


社会での具体的な実例

• いわゆる「模倣犯」と呼ばれるもの– オレオレ詐欺・振り込め詐欺・連続放火

– バタフライナイフ・ダガーナイフ

• ウェルテル効果による連鎖自殺– 有名人の死の直後に発生する後追い自殺

– 練炭自殺・硫化水素自殺

• 個人に内包されている問題意識（好奇心）を刺激する– 情報操作や印象操作、プロパガンダ「７つの方策」

– 満州事変、トンキン湾事件、油まみれの水鳥、精密誘導兵器、ボスニア紛争、ルワンダ内戦など

行動を誘発する


クラウドの原理とパラダイム

• クラウドの原理とパラダイム

– Windows Azure Platformの概要

– クラウドの定義と、クラウドをクラウドたらしめるもの

– データセンター間の地理的レプリケーション（Geo-

Replication）

– CAP定理とBASE、ACIDの呪縛

– 分散システムにおける同期（クロック）

– P2P技術を適用した分散相互排他アルゴリズム


Windows Azure Platformの概要


ひとくちに「Azure（アジュール）」と言っても・・・

Windows Azure

Platform

Windows Azure コンピュートサービス

Web Role

Worker Role

SQL Azure データベースサービス

Windows Azure ストレージサービス

BLOB

Table

Queue

Drive


Windows Azure コンピュートサービス

– Web Role サーバー

• インターネットから直接アクセス可能

• .NET FrameworkとIISがインストールされたタイプのWebサーバー

– Worker Role サーバー

• インターネットから基本的には直接アクセスできない

• .NET Frameworkのみがインストールされたタイプのバッチアプリケーション向けのサーバー


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

http://www.microsoft.com/japan/events/techdays/2010/

http://techbank.jp/Community/blogs/nora/archive/2010/04/11/26227.aspx

http://techbank.jp/Community/blogs/nora/archive/2010/04/11/26227.aspx


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でアクセスが可能


それなんてAzure？

• 単に「Azure（アジュール）」だけでは、Windows Azure

Platform全体を指しているのか、個別のサービスを指し示しているのか、わかりにくく混乱を招きやすい。

• 情報が錯綜する黎明期においては、「それなんてAzure？」と無用な混乱を避けるためにも、Windows Azure用語の表記には、その正確性について最大限の配慮をした方が良い

• 例えば、公式サイトでもWindows Azure PlatformとWindows

Azure platformと、大文字の「P」と小文字の「p」で表記が異なる。果たして、どちらが正しいのか？こまけぇことだが気になるお・・・


クラウドの定義と、クラウドをクラウドたらしめるもの


クラウドの定義


– コモディティ化した廉価なコンピューターリソース

–スケールアウトの技術を使って並列化し、規模の経済性を確保

–動的なリソースの割り当てという、プロビジョニングの仕組み

–保守運用の手間を省く

• これら「クラウドの要件」が揃うことで、はじめて圧倒的なコスト削減が実現可能となる。


スケールアウトの技術（分散データベース）

• 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未来ねっと研究所）


クラウドをクラウドたらしめるもの

• ファブリックコントローラー（Fabric Controller）

– Windows Azure Platformでのプロビジョニングを担当

• プロビジョニング

– トラフィックの流量によって、キャパシティー（受け入れ可能な能力）にあわせてインスタンスを動的に増減させること。

– Elastic（エラスティック）：伸縮性のある・弾力性のある

• スケールアウトの技術でコモディティ化したサーバーを並列化できても、その運用管理が大変に。

• これらの前提条件として、「仮想化」がある！！


ファブリックコントローラーの仕組み

• ノードの配置というプロビジョニングの部分

– 分散ハッシュテーブル（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

http://oceanstore.cs.berkeley.edu/publications/papers/pdf/iptps03-api.pdf




クラウドをクラウドたらしめるプロビジョニング

• AppFabric

–プロビジョニングを司るファブリックコントローラーと、Webアプリケーション基盤である.NET

Servicesを統合したもの

– Windows Azure AppFabricとWindows Server

AppFabricの2つ


AppFabric

• Windows Azure AppFabric

– オンプレミスシステムやWindows Azure Platform上のシステムに接続するための機能を提供

• Windows Server AppFabric

– Windows Server 2008 RC2向けに提供されるIIS上のファブリックコントローラー

• AppFabricの綴りを間違えやすいので、注意が必要。

• しかし、このようにプロビジョニングの仕組みまで兹ね備えたプラットフォームは尐ないのが実情。


データセンター間の地理的レプリケーション（Geo-

Replication）


データセンター間の地理的レプリケーション（Geo-Replication）

• Windows Azure ストレージサービス

– データセンター間の地理的レプリケーション（Geo-

Replication）

– ユーザーの位置情報（Geo-Location）により実現

• 災害やテロなどの不測の事態により、事業の継続が困難に陥る可能性があり、それらの予防的措置として「ディザスタリカバリー」がある。


ディザスタリカバリー

• 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










継続企業（ゴーイングコンサーン）

• 一般的に企業は、その企業が継続するという基礎的前提の上に成り立っている

• 情報を提供された者が適切な判断と意志決定ができるように、経済活動を記録・伝達する「会計」の世界においては、これら要請とも言うべき基礎的前提を「会計公準」と呼ぶ。

• 公準＝形式的または実質的な前提


継続企業とBCP（業務継続計画）

• 会計公準は、企業実体・継続企業・貨幣的評価の3

つ公準（前提）によって構成される

• このうち「継続企業の公準」では、企業は永遠に継続するもの、すなわち「継続企業（ゴーイングコンサーン）」であると仮定している

• このような考えから、企業は事業を継続する社会的使命と責任を帯びているとされ、いわゆる「BCP（業務継続計画）」を策定する動きがある


CAP定理とBASE、ACIDの呪縛


CAP定理とBASE、ACIDの呪縛

• トランザクションとは、「取引」を意味し、相手とのやりとりを通じて、最終的に「合意」に至るまでの一連のプロセス（処理単位）を指す

• また、トランザクションは、そのプロセスがやりとりする範囲（処理単位）が、成功または失敗のどちらか一方で終わる、というオールオアナッシングの考えに基づいている

• 典型的なトランザクションは、リレーショナルデータベースにおける銀行口座やオークションなどの事例モデルである

• これらは、即時応答性の要求される「ACIDトランザクション（フラットトランザクション）」と呼ばれるタイプのトランザクションである


ACIDトランザクション

• 即時応答性の要求されるACIDトランザクションは、銀行口座やオークションなどの事例モデルでは有効だが、インターネットの商取引モデルを描くには限界がある

• ショッピングサイトでの買い物も「取引」であり、最終的に商品が消費者の手元に到着するまで数日かかるという「合意」に至るまでの、一連のプロセスもまたトランザクションである

• Eric Brewer（エリック・ブリューワー）のCAP定理– 数学的に証明された「定理」ではない

– Consistency（一貫性、コンシステンシー）

– Availability（可用性、アベイラビリティー）

– Partition-tolerance（分割または分散耐性、パーティショントレランス）

– ACIDな共有システムでは、上記のうち2つを選択する必要がある


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

http://www.cs.berkeley.edu/~brewer/cs262b-2004/PODC-keynote.pdf






トランザクションモデル

• グローバルトランザクション

– 複数のリソースにまたがるトランザクション

• ローカルトランザクション

– 単一リソース内のトランザクション

• グローバルトランザクションのさらなる分類

– 2つの異なる独立したデータベースにそれぞれサブトランザクションがはしるトランザクションを「入れ子トランザクション」

– 同一の分散データベース内の論理的に分割不可能なサブトランザクションがはしるトランザクションを「分散トランザクション」


入れ子トランザクション

• 2つの異なる独立したデータベースとは？

• 例えば、海外旅行の際に、航空機のチケットとホテルの部屋を同時に予約した場合に、航空会社のデータベースとホテル会社はそれぞれデータベースを有している

• これら個別の独立したデータベースが連携している際に、それぞれのデータベースごとに、サブトランザクションがはしることになる


分散トランザクション

• 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

http://ashigeru.com/ajn-source/ajn4-arakawa.ppt






入れ子と分散トランザクションの違い

• 入れ子トランザクションと分散トランザクションの差異は微妙であると思われがちであるが、重要である。

• 分散トランザクションの問題は、データのロック、トランザクション全体のコミット、そして分散相互排他アルゴリズムが必要となる点

• ローカルトランザクションとは、従来までのリレーショナルデータベースなどの即時応答性の要求されるACIDトランザクションのこと


分散システムにおける同期（クロック）

• 分散システムでは、各ノード（個別サーバー）間で内部的な一貫性を保ち、外部に対しては整合性を保たなければならない

• 何らかの方法でシステムが「グローバルな状態」を把握しておく必要がある。これら各ノード間の協調、すなわち「同期」の問題が生ずる


論理クロックと物理クロック

• これら同期アルゴリズムを慣習として、「論理クロック（logical clock）」と呼ぶ。

• クロックには、論理クロックと物理クロックがあり、物理クロックとは、腕時計や壁掛け時計のような日常生活で用いる「時計」のことである。


レスリー・ランポートの論理クロック

• コンピューターシステムにおける「時間」は、内部的な一貫性、すなわち「同期」が保たれていれば良いのであって、必ずしも物理クロックと同じ時を刻んでいる必要性はない

• 分散システムにおいては、各ノード間の「同期」が本質ではなく、メッセージをやり取りする、一連の協調活動の「全順序性」であることを、レスリー・ランポートは1978年のクロック同期に関する論文で示した。


Vector Clock

• 分散システムにおける「グローバルな状態」すなわち、内部的な一貫性を知るための「論理クロック」は、各ノード間の因果性（結びつき）を把握できないために「Vector Clock」が提案される

• このVector Clockのひとつである「Interval Tree

Clocks」をApache Cassandraでは実装しようと試みている

• 多くの分散ファイルシステムが苦手とする削除において、「廃棄（Tombstones）の有効期間」を設定し、Gossipプロトコルにより伝播させる


P2P技術を適用した分散相互排他アルゴリズム


P2Pと複雑ネットワーク

• Vector ClockからP2Pへ

– Vector Clockは、因果性の制約が守られている（お互いに結びついている）ときのみに、メッセージの配信（やりとり）ができる。このため、これらは次第に通信の問題へと変化していき、P2Pのモデルが提起される。

• 複雑ネットワーク

–六次の隔たり：人は自分の知り合いを6人以上介

すと世界中の人々と間接的な知り合いになれる、という仮説。P2Pにおける「経路長」に相当

– ランダムグラフによる複雑ネットワークを応用した理論。


分散相互排他アルゴリズム

• 分散システムにおいて、「グローバルな状態」を知るための同期アルゴリズムには、ブリー選任アルゴリズム、障害性に考慮した円形状のリングアルゴリズム、そして単一障害点（SPOF）をなくすという観点の分散相互排他アルゴリズムなどが考案されている

• 分散相互排他アルゴリズムでは、整合性モデルとしてBASE

に基づくEventually Consistency（イベンチュアルコンシステンシー、結果整合性）を適用し、遅延を許容する

• この考えを適用した、クラウド基盤ではレイテンシーが問題になる。このため、高速な光ファイバー、距離の近いデータセンター、そしてキャッシュを取り入れたCDNサービスを組み合わせなければ解決することはできない

• 例：Google Public DNS、Google Fiber for Communities、Akamai


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プロトコルとでも呼ぶべき改良版


分散コンピューティングの落とし穴（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）

分散システムは、ネットワークが課題


参加者募集のお知らせ

• 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

http://wiki.apache.org/cassandra/FrontPage_JP

http://groups.google.com/group/nosql-ja



http://groups.google.co.jp/group/hadoop-jp




参考文献

• とあるコンサルタントのつぶやき

– http://blogs.msdn.com/nakama/

• 財務会計論

– http://www.amazon.co.jp/dp/4495141937/

• 分散システム原理とパラダイム

– http://www.amazon.co.jp/dp/4894714981

http://blogs.msdn.com/nakama/

http://www.amazon.co.jp/dp/4495141937/

http://www.amazon.co.jp/dp/4894714981


ご静聴、Azaas!タイムラインのみんなに感謝！

http://twitter.com/kimtea/status/10012523378

http://twitter.com/kimtea/status/10012523378

cloud principles and paradigms kimtea-2010-04-24

Technology