2 今 回 の 内 容 スケーラビリティや 可 用 性, 伸 縮 性 のための クラウドサービスにおける 設 計 思 想 について, Amazon Web Servicesの 実 例 を 通 して 学 ぶ

クラウドシステム 基 礎 第 5 回 : クラウドサービスの 設 計 思 想 (1) 国 立 情 報 学 研 究 所 石 川 冬 樹 f-ishikawa@nii.ac.jp

2 今 回 の 内 容 スケーラビリティや 可 用 性, 伸 縮 性 のための クラウドサービスにおける 設 計 思 想 について, Amazon Web Servicesの 実 例 を 通 して 学 ぶ

3 目 次 クラウド 概 論 (ごく 簡 単 に) 例 : Amazon Web Servicesを 用 いた 設 計 例 : Amazon Dynamo DB 内 部 版 の 設 計

4 クラウド: 定 義 ( 例 ) 計 算 資 源 へのアクセス のためのモデル On-demand self-service: 提 供 者 との 人 手 を 介 し たやりとりなく, 自 動 で 取 得 可 能 Broad network access: 様 々なプラットフォームか ら 標 準 的 な 方 法 で 利 用 可 能 Resource pooling: 詳 細 が 隠 蔽 された 形 でプール され, 複 数 の 利 用 者 に 提 供 ( 次 頁 に 続 く) [The NIST Cloud Definition (Final Ver. Sep 2011)]

5 クラウド: 定 義 ( 例 ) 計 算 資 源 へのアクセス のためのモデル ( 前 頁 からの 続 き) Rapid elasticity: 迅 速 に, 伸 縮 可 能 に 提 供 されて おり, 無 限 に 見 えるものから 必 要 な 分 だけ 取 得 Measured Service: 抽 象 的 な 指 標 での 測 定 に 基 づき, 利 用 が 可 視 化 された 形 で 制 御, 最 適 化 [The NIST Cloud Definition (Final Ver. Sep 2011)]

6 クラウド: サービスモデル SaaS (Software-as-a-Service) PaaS (Platform-as-a-Service) IaaS (Infrastructure-as-a-Service) PaaS/IaaSの 区 別 は 本 講 義 では 気 にしない それらはいずれにしても 計 算 資 源 を 提 供 する 側 それらを 利 用 するアプリケーション(やSaaS)に 提 供 される 保 証 の 内 容 や,その 実 現 アプローチを, 本 講 義 では 議 論 している

7 クラウド: 語 られる 例 (1) スケーラビリティ(scalability) 伸 縮 性 (Elasticity) Animoto: 動 画 作 成 閲 覧 サービスをFacebook ユーザが 利 用 可 能 に(2008) Amazon EC2を 利 用 3 日 後 には25 万 ユーザ( 元 々 2 万 5 千 )に 対 応 するために4000サーバ( 元 々50) ホワイトハウス:アンケートWebサイト(2009) Google App Engineを 利 用 2 日 間 で10 万 の 質 問 と 3600 万 の 返 答 ( 最 大 秒 あたり600クエリ)

8 クラウド: 語 られる 例 (2) 事 前 または 保 有 のコストをかけず 柔 軟 な 利 用 (Quick Start, No Up-front Investment, Pay-per-Use) New York Times: 100 年 分 の 新 聞 をPDFに 変 換, テキスト 抽 出 (2007) Amazon EC2 24 時 間 100 台 の 仮 想 マシンを 利 用 (1000ドル 強 ) 日 本 の 公 的 機 関 : 突 然 一 時 的 に 必 要 となるシス テムの 立 ち 上 げ( 定 額 給 付 金 管 理 )(2009) Force.com

9 クラウド: スケールメリット 多 く 買 うほど 安 い 1,000 servers 50,000 servers Network (per 1M/sec) $95 $13 Storage (per 1G) $2.2 $0.4 Management (per 1 supervisor) 140 servers 1000 servers [Above the clouds: A berkeley view of cloud computing, 2009] おまけ: 現 在,Amazonのクラウドへのトラフィック は, 本 業 のものより 多 くなっている 本 業 の 基 盤 のコスト 減 少 にもますます 効 く

10 クラウド: 伸 縮 性 の 考 え 方 固 定 数 のサーバにおける 無 駄 な 余 剰 資 源 または 機 会 損 失 [Above the clouds: A berkeley view of cloud computing, 2009]

11 クラウド: 固 有 の 設 計 思 想 今 までのシステムを, 単 にそのままクラウド 上 で 走 らせることも 考 えられる 今 まで 手 元 のサーバ 上 で 動 かしていたものを, Amazon EC2などのIaaS 上 で( 仮 想 マシンとして) 配 備, 動 作 させてもよい Webフレームワーク,RDBとトランザクションなど 一 方, 今 までのシステムとは 異 なる 特 長,そのた めの 設 計 思 想 が 注 目 されることも 多 々ある 大 規 模 分 散 ( 性 能,スケーラブル, 耐 故 障 )

12 クラウド: 固 有 の 設 計 思 想 Webスケールのデータ 量 アクセス 量 に 対 しては, どんな すごい コンピュータでも1 台 では 足 りない 安 い( 普 通 の)ハードを 大 量 に 使 う 大 量 にあると, 常 に 障 害 がどこかで 発 生 している 障 害 が 発 生 した 部 分 を(ある 程 度 の 期 間 ) 切 り 捨 てても 全 体 としては 機 能 を 維 持 できる 大 量 のデータやアクセスに 対 応 できる 設 計? + 一 部 の 障 害 による 影 響 を 受 けにくい 設 計?

13 補 足 : Scale UpとScale Out 大 量 の 処 理 (リクエストなど)をさばくには Scale Up: 強 力 なサーバを 用 いる 従 来 のオンプレミスサーバやスパコン Scale Out: 管 理 ソフトウェアツールとともに, 大 量 のサーバを 用 いる Webスケールのデータ( 例 :サーチエンジン) 落 ちているサーバが 常 にあるという 仮 定 に 基 づい た 運 用 データや 機 能 について, 並 行 実 行 障 害 復 帰 しや すい 特 定 の 形 式 を 用 いる ( 例 : Key-ValueデータストアやMap Reduce)

14 目 次 クラウド 概 論 (ごく 簡 単 に) 例 : Amazon Web Servicesを 用 いた 設 計 クラウドらしい アーキテクチャ クラウドらしい サービス: Simple DB クラウドらしい サービス: SQS 例 : Amazon Dynamo DB 内 部 版 の 設 計

15 クラウドらしい アーキテクチャ? Amazon Web Services (AWS)のドキュメントより 複 製 による 並 行 処 理 耐 故 障 化 を 容 易 にするコ ンポーネント 分 割 各 コンポーネントの 失 敗 や 遅 れが 互 いに 影 響 しな いように 疎 結 合 を 特 にバッチ 処 理 の 場 合 など, 水 平 ( 同 機 能 の)ス ケールのためには 非 同 期 アーキテクチャに [J. Varis, Architecting for The Cloud: Best Practices, 2010]

16 クラウドらしい アーキテクチャ? Amazon Web Services (AWS)のドキュメントより バッチシステムの 移 行 例 (before) スケジューラー 固 定 数 の 処 理 サーバー [J. Varis, Migrating your Existing Applications to the AWS Cloud, Oct 2010]

17 クラウドらしい アーキテクチャ? Amazon Web Services (AWS)のドキュメントより バッチシステムの 移 行 例 (after) Auto-scaling Key-Valueストア (SimpleDB) キュー(SQS) [J. Varis, Migrating your Existing Applications to the AWS Cloud, Oct 2010]

18 Amazon Web Services の 一 部 バッチシステムのafter 版 に 出 ているもの EC2 (Elastic Compute Cloud): 仮 想 マシンを 走 ら せる 計 算 資 源 サービス(いわゆるIaaS) S3: オブジェクト(ファイル)をget/putする ストレージ Simple DB: 非 リレーショナル 型 のDB (Key-Valueデータストア) SQS(Simple Queue Service): 分 散, 複 製 された キューを 提 供

19 クラウドらしい アーキテクチャ? 参 考 : Webアプリケーションの 場 合 (after) Auto-scaling 同 時 に 落 ちないとされる 領 域 への 計 算 RDBの 分 散 複 製 (availability zone) 世 界 各 地 でのキャッシン グ(CloudFront) [J. Varis, Migrating your Existing Applications to the AWS Cloud, Oct 2010]

20 クラウドらしい アーキテクチャ? 参 考 : バックエンドプロセッシングの 場 合 (after) キュー(SQS) 既 存 コンポーネン トのプロキシによ るラッピング [J. Varis, Migrating your Existing Applications to the AWS Cloud, Oct 2010]

21 目 次 クラウド 概 論 (ごく 簡 単 に) 例 : Amazon Web Servicesを 用 いた 設 計 クラウドらしい アーキテクチャ クラウドらしい サービス: Simple DB クラウドらしい サービス: SQS 例 : Amazon Dynamo DB 内 部 版 の 設 計

22 Amazon Simple DB 非 リレーショナル 型 (Key-Value 型 )データストア キーに 紐 付 くデータのget/putを 中 心 としたAPI 読 み 込 み 操 作 だけでなく, 書 き 込 み 操 作 もブロッ ク 失 敗 せず 速 い 読 み 込 み 操 作 はイベンチュアル 一 貫 性 を 保 証 す るが,オプションによりそれまでに 完 了 した 書 き 込 みを 反 映 する 読 み 込 みも 可 能 翻 訳 も 限 定 的 で, 今 はより 高 度 なDynamo DBとい うサービスが 存 在 する( 後 で 詳 しく) http://aws.amazon.com/jp/simpledb/

23 ( 前 回 より) イベンチュアル 一 貫 性 イベンチュアル 一 貫 性 (eventual consistency) 更 新 はすべてのコピーに 伝 搬 する ( 更 新 がなけ ればすべての 複 製 は 同 一 に 収 束 していく) 以 下 の 性 質 を 持 つデータストアに 適 する (DNSやWebキャッシュが 代 表 例 ) 書 き 込 み 同 士 の 衝 突 はない 読 み 込 みが 必 ずしも 最 新 でなくてもかまわない 追 記 : 性 能 やスケーラビリティの 追 求 のためにあ えて 採 用 することがクラウド 関 連 では 多 い 補 足 : Amazonでの 日 本 語 訳 は 結 果 整 合 性

24 NoSQL NoSQL: Relational DBのモデルに 従 わないス キーマレスなデータストアのモデルに 関 する 総 称 ( 分 散 )Key-Value Store(KVS): キーに 紐 付 く データ 値 の 取 得 に 特 化 したNoSQL 実 現 方 式 大 量 のノードがそれぞれ 特 定 範 囲 のキーに 対 応 するデータを 重 複 して 保 持 することで,キーに 対 する 読 み 書 き(get/put)の 高 いスケーラビリティお よび 可 用 性 を 実 現 RDBでのJOIN 演 算 に 相 当 するような 演 算 など, 仕 組 み 上 高 コストのため 扱 わない 機 能 がある

25 分 散 Key Value Store get 19104 データ 値 はスキーマレス 19104 -> "name:suzuki, age:26, entry:2007, address:chiba" 17051 -> "name:tanaka, birth:1976, entry:2005, tel:03xxxxxxx" キー19104は ノード1, 3が 保 持 分 散 ハッシュテーブルなどにより, キーに 対 応 する 保 持 ノードを 高 速 に 判 定,ノードの 負 荷 分 散 も 適 切 に 2 1 17001 -> 18210 -> 19104 -> "name:suzuki, age:26, entry:2007, address:chiba" 18210 -> 3 4 20002 -> 18210 ->

26 おまけ: DHT 分 散 ハッシュテーブル (DHT: Distributed Hash Table) 中 央 管 理 を 設 けることなく, 膨 大 なデータおよび ルーティング 情 報 を 分 散 して 持 つ 簡 単 な 例 : ノード16 個 (IDが0~15) データのハッシュを 基 にそのデータを 置 くノードを 決 める 各 ノードは 自 分 の ID + 1, 2, 4, 8 (mod 16) のIDを 持 つノードのIPアドレスだけ 覚 える ノード2からノード15へ 行 くには,+8,+4,+1と 進 む (ノード 数 nに 対 して O(log(n)) ステップ)

27 RDBとNoSQL( 大 ざっぱに) RDB 依 存 関 係 の 整 理 ( 正 規 化 )に 基 づく 設 計 例 : ID 氏 名, 会 社 名, 会 社 名 会 社 住 所 実 行 時 にSQLクエリに 応 じた 複 雑 な 処 理 が 発 生 KVS 例 : 上 記 2テーブルを 結 合 してIDから 会 社 住 所 を 予 めクエリパターンを 考 慮 することで, 実 行 時 に は 高 速 なget/putだけで 済 むように 設 計 例 : 頻 発 するなら ID 会 社 名, 会 社 住 所 DBも 会 社 住 所 ID, 氏 名 DBも 作 ればよい

28 スケーラビリティ 可 用 性 重 視 の 複 製 管 理 複 製 管 理 はどうなっている?( 詳 細 はまた 後 で) 再 : 読 み 込 み 操 作 だけでなく, 書 き 込 み 操 作 もブ ロック 失 敗 せず 速 い Quorumを 超 える 数 の 複 製 への 二 次 記 憶 領 域 書 き 込 み 確 認 を 待 たず 書 き 込 み 成 功 が 返 る? 再 : 読 み 込 み 操 作 はイベンチュアル 一 貫 性 を 保 証 するが,オプションによりそれまでに 完 了 した 書 き 込 みを 反 映 する 読 み 込 みも 可 能 書 き 込 み 結 果 はバックグラウンドで 複 製 間 同 期 さ れる?( 読 み 込 み 先 は 基 本 1 複 製 だけでオプショ ンを 付 けると 全 複 製 から 読 み 込 む?)

29 Amazon Simple DB 一 貫 性 に 関 するドキュメントより(1) 一 貫 性 オプションが 有 効 なときは 必 ず 最 新 の 値 を 読 み, 無 効 のときは 古 い 値 を 読 む 可 能 性 あり W1の 完 了 後 にリクエストが 届 いたW2の 方 が 新 しいと 把 握 することはできているということ http://docs.aws.amazon.com/ja_jp/amazonsimpledb/latest /DeveloperGuide/ConsistencySummary.html

30 Amazon Simple DB 一 貫 性 に 関 するドキュメントより(2) 書 き 込 みが 完 了 する 前 に 平 行 して 起 きる 読 み 込 みの 結 果 は, 一 貫 性 オプ ションを 付 けても 不 定 http://docs.aws.amazon.com/ja_jp/amazonsimpledb/latest /DeveloperGuide/ConsistencySummary.html

31 Amazon Simple DB 一 貫 性 に 関 するドキュメントより(3) 書 き 込 みが 完 了 したとされ る 前 に 平 行 して 書 き 込 みが 発 生 すると 結 果 は 不 定 ( 困 るならアプリ 側 でタイム スタンプなどの 制 御 を) http://docs.aws.amazon.com/ja_jp/amazonsimpledb/latest /DeveloperGuide/ConsistencySummary.html

32 目 次 クラウド 概 論 (ごく 簡 単 に) 例 : Amazon Web Servicesを 用 いた 設 計 クラウドらしい アーキテクチャ クラウドらしい サービス: Simple DB クラウドらしい サービス: SQS 例 : Amazon Dynamo DB 内 部 版 の 設 計

33 Amazon SQS 概 要 メッセージの 送 受 信 のための 分 散 キューを 提 供 キューは 複 製 され, 送 受 信 はそのどれかに 対 して 行 われる 全 てのキューが 同 じデータを 持 つ 状 態 に 収 束 し ていく(イベンチュアル 一 貫 性 ) キューを 読 み 出 したとき,その 前 に 送 られたメッ セージが 含 まれるとは 限 らない r1 r1 r4 r2 r3 r3 r2 r4 http://aws.amazon.com/jp/sqs/

34 Amazon SQS 先 に 出 したアーキテクチャより 抜 粋 Workerがキューから タスクを 取 り 出 す, キューに 結 果 を 入 れる 疎 結 合 : タスクの 送 信 元 は,Workerの 反 応 待 ち でブロックしない(Workerも, 結 果 の 受 信 先 の 反 応 待 ちでブロックしない) Workerが 実 際 いくつ 生 きているか,どれが 速 いか を 把 握 せずに, 自 在 にWorkerを 増 減 してもよい が,タスクを 取 り 出 した 後 にWorkerが 落 ちたら?

35 Amazon SQS 少 なくとも1 回 のための 仕 様 受 信 されたメッセージは, 一 時 的 に 見 えなくなる ( 受 信 されなくなる)が, 一 定 時 間 のタイムアウト の 後 に 再 びキューに 含 まれる メッセージを 受 信 しタスクを 行 うプロセスは,タスク 終 了 後 に 明 示 的 にメッセージ 削 除 を 行 う もしもそのプロセスがクラッシュしたり, 繋 がらなく なったりした 場 合, 一 定 時 間 後 にキューにメッセー ジが 現 れ, 別 のプロセスに 処 理 される メッセージは 重 複 して 受 信 される 可 能 性 がある なおFIFOではない( 分 散 キューだと 高 コスト) r1 r1 r4 r2 r3 r3 r2 r4

36 補 足 : Amazon Web Services どれだけのサービスがあるか https://aws.amazon.com/jp/documentation/ 増 え 続 けている

37 目 次 クラウド 概 論 (ごく 簡 単 に) 例 : Amazon Web Servicesを 用 いた 設 計 例 : Amazon Dynamo DB 内 部 版 の 設 計

38 Amazon Dynamo DB AmazonによるKVS(Key-Value Store) 型 データス トアサービス 当 初 はAmazonのオンライン 通 販 サイトの 実 装 の ために 構 築 活 用 (ショッピングカートなど) 一 般 利 用 のための 本 格 的 なKVSクラウドサービ スとして2012 年 頭 にリリース ディスクはSSD, 要 求 スループットを 指 定 し 自 動 ス ケーリング, 高 可 用 性,JSONサポート,

39 内 部 版 Dynamoの 設 計 当 初 のDynamoの 設 計 については2007に 論 文 公 開 されている Amazonのオンライン 通 販 サイト 実 装 のための 内 部 利 用 今 一 般 に 公 開 されているよりも,アプリ 開 発 者 が 負 う 責 任 (カスタマイズできる 余 地 )が 大 きい DeCandia et al., Dynamo: Amazon s Highly Available Key-value Store, 2007

40 内 部 版 Dynamoの 設 計 : 仮 定 と 要 求 1MB 未 満 くらいのデータの 読 み 書 き(キーに 対 す るget/put)ができればよい 複 数 のデータにまたがる 操 作 はない Amazonの 通 販 サイトの 多 くの 部 分 がこれで 動 く 可 用 性 のために 一 貫 性 をゆるめる(ACIDのC) 一 つのキーに 対 する 読 み 書 きだけ 考 えており, 一 連 操 作 の 孤 立 性 (I)のための 保 証 は 考 えない 分 布 の99.9% 以 上 に 対 し 読 み 書 き 数 百 msec 未 満 一 貫 性 や 耐 久 性 と, 性 能 などトレードオフは 設 定 可 能 に

41 内 部 版 Dynamoの 設 計 : 指 針 常 に 書 き 込 み 可 能 に 古 典 的 には, 読 み 込 みを 軽 くし, 一 貫 性 のための 調 整 コスト(ブロックや 失 敗 )は 書 き 込 みが 負 う ( 例 : 書 き 込 み 過 半 数 読 み 込 み1のQuorum) そのコストは 必 要 なら 読 み 込 みが 負 うことに 一 貫 性 のための 競 合 解 決 方 法 は,アプリ 開 発 者 が 決 める 柔 軟 性 を 残 す 物 理 時 間 で 最 新 のものを 残 す などだけではなく 少 しずつノードを 追 加 可 能 対 称 性 を 重 視 (どの ノードも 同 じ) 非 中 央 集 権 ノードは 異 種 混 合

42 内 部 版 Dynamoの 設 計 : バージョン 管 理 常 に 書 き 込 み 可 能 書 き 込 みを 受 け 付 けて 後 で 複 製 間 の 同 期 を 行 う 並 行 する 書 き 込 みや 一 時 的 なネットワーク 分 断 により, 複 数 の 最 新 値 が 存 在 しうる AとBどちらを 保 持 するのか? 3. 周 知 put x -> A 物 理 時 間 で 最 新 の 方 などと 決 めつけると 片 方 が 消 えることに 1. put x -> A 2. put x -> B

43 内 部 版 Dynamoの 設 計 : バージョン 管 理 ベクトルタイムスタンプを 使 ってバージョン 管 理 把 握 出 来 る 因 果 順 序 がある 場 合, 自 動 的 に 競 合 解 決 可 能 5. 周 知 put x -> A この 周 知 が 遅 れて 着 いても 古 い 書 き 込 み であることが 断 言 できる 2. 周 知 put x -> A 1. put x -> A 4. put x -> B 3. get x 1でデータxに 付 けたタイムスタンプが 伝 わり, それより 大 きなタイムスタンプが4で 付 く

44 内 部 版 Dynamoの 設 計 : バージョン 管 理 そうでない 場 合 は 次 の 書 き 込 み 手 に 意 味 を 考 慮 した 競 合 解 決 が 委 ねられる 3. 周 知 put x -> A 1. put x -> A 2. put x -> B 前 後 関 係 が 断 言 できなければAと B 両 方 を 保 持 4. get x 競 合 する 複 数 値 のgetに 続 く putは 競 合 を 更 新 した 最 新 値 と 見 なされる 5. put x -> C AとB(とそれらのメタデータ) を 見 てアプリ 依 存 の 適 宜 処 理

45 内 部 版 Dynamoの 設 計 : バージョン 管 理 アプリ 依 存 の 競 合 解 決 の 例 1. get x 2. put x -> [A, B] アプリプロセス ショッピングカート 内 の 商 品 リストへ 追 加 この 周 知 が3のgetより 遅 れている 5. 周 知 put x -> [A, B] 3. get x 4. put x -> [A, C] 両 バージョン 保 持 6. get x リスト 値 をマージしたものを 最 新 値 とする 7. put x -> [A, B, C] まずaddToCart(B) 次 にaddToCart(C) (カートには 商 品 Aが 追 加 済 み) なお, 同 じ 複 製 に 必 ず 処 理 させる ことの 保 証 はない

46 内 部 版 Dynamoの 設 計 : バージョン 管 理 注 : これらのスライドにおける 図 は, 論 文 におけ る 一 般 論 での 説 明 を 講 師 解 釈 でシナリオを 考 え たもの 実 際 の 内 部 設 計 と 合 致 するかは 不 明 しかも 古 い カート 内 の 商 品 リストからの 削 除 はどう 扱 う? [A,B]に 対 してCを 追 加 して[A,B,C]をput [A,B]に 対 してAを 削 除 して[B]をput マージするというだけだと[A,B,C]となりAが 復 活?

47 内 部 版 Dynamoの 設 計 : バージョン 管 理 実 測 データの 例 (ショッピングカード): getにより 複 数 バージョンのデータが 返 されること がどれだけあるか? 1つ: 99.94% 2つ: 0.0005% 3つ: 0.00047% 4つ: 0.00009% だいたいの 原 因 は 障 害 ではなく,ボットによる 並 行 書 き 込 み

48 内 部 版 Dynamoの 設 計 : 読 み 書 きの 実 装 Sloppy (だらしない) quorum 読 み 書 きリクエストを 受 け 取 ったノードは,N 個 の 複 製 に 送 信 し, 読 み 書 きそれぞれに 定 められた 一 定 数 (R,W) 以 上 の 確 認 をもって 成 功 とする 必 ず R+W>N, 2W>N にするとは 言 っていない 書 き 込 みの 周 知 が 想 定 ノードに 届 かなかった 場 合, 別 の 代 替 ノードに 送 信 代 替 ノードは 後 に 元 々の 想 定 ノードに 書 き 込 み 周 知 を 送 り, 成 功 したら 自 身 のデータは 消 す ( 一 時 的 に 担 当 するが,あくまで 一 時 的 )

49 内 部 版 Dynamoの 設 計 : 読 み 書 きの 実 装 さらに 耐 久 性 への 保 証 を 犠 牲 にして 性 能 を 上 げ る 設 定 も 可 能 基 本 的 にはメモリ 上 のバッファを 使 い,そこへの 書 き 込 み 完 了 を 持 って 確 認 を 返 信 する バックグラウンドで 随 時 二 次 記 憶 に 書 き 込 む その 前 にクラッシュするとその 複 製 では 書 き 込 み が 失 われる N 個 の 書 き 込 み 周 知 先 のうち,1つだけ 二 次 記 憶 にすぐに 書 かせることで 耐 久 性 を 少 し 向 上 確 認 を 待 つのはW 個 (Nより 小 さい)だけなので, 性 能 には 影 響 しない

50 内 部 版 Dynamoの 設 計 : 読 み 書 きの 実 装 メモリバッファの 効 果 ( 応 答 時 間 )

51 内 部 版 Dynamoの 設 計 : 読 み 書 きの 実 装 N, R, Wはデータストアインスタンスごとの 設 定 性 能, 耐 久 性, 一 貫 性, 可 用 性 の 要 求 次 第 典 型 的 には N=3,R=W=2 がよく 使 われた Wを( 過 半 数 より) 小 さくすることも 考 えている 書 き 込 みでブロックしなくなる バージョン 競 合 が 発 生 するようになる 書 き 込 み 成 功 と 通 知 したが, 書 き 込 み 結 果 が 消 え るという 可 能 性 を 発 生 させる

52 内 部 版 Dynamoの 設 計 : その 他 負 荷 の 均 一 化 ( 担 当 ノードの 決 め 方 )については 省 略 分 散 ハッシュテーブルにはしていない ルーティング 情 報 を 分 散 させる 代 わりに,ある キーの 担 当 ノードを 見 つけるまで 数 ホップかける よりも, 全 ノードがルーティング 情 報 を 保 持 内 部 運 用 でありノード 乗 っ 取 りなどは 考 えない ビザンチン 耐 故 障 性 のための 情 報 交 換 などはし ない

53 今 回 のまとめ Web 企 業 が 自 身 の 要 求 から 産 み 出 したクラウド での 技 術 は,これまでと 異 なる 設 計 思 想 に 基 づ いている スケーラビリティや 可 用 性, 伸 縮 性 のため, 一 貫 性 や 実 現 可 能 な 機 能 が 意 図 的 に 制 限 されている 開 発 者 (データストア 利 用 者 ) 側 が 留 意 すべき 制 約 が 多 くなっている 次 回 : これらの 設 計 思 想 についてより 踏 み 込 ん で 引 き 続 き 議 論 する