Mercurial > hg > Papers > 2014 > nobuyasu-master

comparison slides/index.html @ 79:2e53de70f64e

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
Fixed slide
author Nobuyasu Oshiro <dimolto@cr.ie.u-ryukyu.ac.jp>
date Mon, 03 Feb 2014 10:38:28 +0900
parents 04f63b011fee
children e889fc4dc925
comparison
equal deleted inserted replaced
78:04f63b011fee 79:2e53de70f64e
205 </ul> 205 </ul>
206 <p>ロックが少なく、いつでもコピーが可能なことから、非破壊的木構造はスケーラブルなシステムに有用となる</p> 206 <p>ロックが少なく、いつでもコピーが可能なことから、非破壊的木構造はスケーラブルなシステムに有用となる</p>
207 </article> 207 </article>
208 208
209 <article> 209 <article>
210 <h3> 210 <h3>
211 Jungleの分散設計:分散版管理システム 211 Jungleの分散設計
212 </h3> 212 </h3>
213 <p>Jungleは分散設計を行うにあたってGitやMercurialといった分散版管理システムを意識している</p> 213 <p>ここまでJungleに実装されている非破壊的木構造の利点について述べた。</p>
214 <p style="margin-top:-10px;">分散版管理システムとは多人数によるソフトウェア開発において変更履歴を管理するシステム</p> 214 <p>次に、Jungleにおける分散設計について述べる。</p>
215 <p style="margin-top:-10px;">分散版管理システムは次の特徴とAPIを持つ</p> 215 <p>データ分散を行うにあたり、まず考えることはトポロジーの形成と他のノードからデータの伝搬の仕方である。</p>
216 <ul> 216 <p>Jungleはこの問題に対し、ツリートポロジーを形成し、データ編集の際に発生するcommit logを他のノードに流すことで解決する。</p>
217 <li>開発者それぞれがリポジトリのクローンしてローカルに持ち、開発はローカルのリポジトリを通すことで行われる</li> 217 </article>
218 <li>ローカルのリポジトリは独立に存在し、サーバ上にある他人のリポジトリから変更履歴をとることができる。また自身の変更履歴を伝えることもできる</li> 218
219 <li>データ更新時に先に別の更新が入っていた(衝突)場合はMergeによりデータの整合性をとる</li> 219 <article>
220 </ul> 220 <h3>
221 </article> 221 Jungleの分散設計：トポロジー形成とログによるデータ分散
222 222 </h3>
223 <article>
224 <h3>
225 Jungleの分散設計:分散版管理システム
226 </h3>
227 <p>分散版管理システムAPI</p>
228 <ul style="margin-top:-20px;">
229 <li>commit:データに変更を加えたことをリポジトリに登録</li>
230 <li>push:ローカルのリポジトリで行った変更履歴を他のリポジトリへまとめて送る</li>
231 <li>pull:他のリポジトリからの変更履歴をまとめて受け取る</li>
232 </ul>
233 <p style="text-align:center;">
234 <img style="height:200px;" src="./images/distributed_repository.png">
235 </p>
236 <small> 223 <small>
237 <p>分版版管理システムはリポジトリが壊れても別のリポジトリよりデータを復旧できることと、push/pullそれとMergeによる整合性
238 の確保で、高いスケーラビリティを持っている</p>
239 </small>
240 </article>
241
242 <article>
243 <h3>
244 Jungleの分散設計:分散版管理システム
245 </h3>
246 <p>Jungleと分散版管理システムには似通った点がある</p>
247 <li>どちらもデータのコピーが自由</li>
248 <li>データ更新しても過去のデータに影響を与えない</li>
249 <br/>
250 <p><font color="red">同じAPIを実装することで、分散版管理システムと同じく高いスケーラビリティが期待できる</font></p>
251 <p>具体的には</p>
252 <ul>
253 <li>pushやpullによる定期的なデータの更新</li>
254 <li>Mergeによる更新データ衝突の解決</li>
255 </ul>
256 </article>
257
258
259 <article>
260 <h3>
261 Jungleの分散実装
262 </h3>
263 <p>ここまでJungleの分散設計について説明した。</p>
264 <br/>
265 <p>これらのシステムを実装する為にまずはJungleのノード同士でネットワークトポロジーを
266 組み、その上でデータをやりとりする機構が必要になる。</p>
267 <p>そこで、ネットワートポロジーを組みログによるデータの分散を行う仕組みをJungleに実装した。</p>
268 <p>また、Mergeの例として掲示板プログラムにおけるMergeの実装も行った。</p>
269 </article>
270
271 <article>
272 <h3>
273 Jungleの分散実装：ログによるデータ分散
274 </h3>
275 <small>
276 <p>今回Jungleの分散実装は以下のように行った</p>
277 <table> 224 <table>
278 <tr> 225 <tr>
279 <th>ツリートポロジーを形成</th> 226 <th>ツリートポロジーを形成</th>
280 <th>commit log伝搬によるデータ分散</th> 227 <th>commit log伝搬によるデータ分散</th>
281 </tr> 228 </tr>
291 <p>サーバノード同士でツリートポロジーを形成する。データ編集をどのように行ったのかを示すログ commit log を伝搬させデータの分散を行う。</p> 238 <p>サーバノード同士でツリートポロジーを形成する。データ編集をどのように行ったのかを示すログ commit log を伝搬させデータの分散を行う。</p>
292 </small> 239 </small>
293 </article> 240 </article>
294 241
295 <article> 242 <article>
296 <h3> 243 <h3>
297 Mergeによる更新の衝突の解決 244 データ更新衝突の解決
245 </h3>
246 <p>トポロジー形成とデータ伝搬手段については述べた。</p>
247 <p>次に問題になることはデータの整合性をどのようにとるかである。</p>
248 <p>例えば、ノードの持つデータが全て同じ値にしなければならない場合は、データを持つノード全てにロックを掛けて
249 変更を加える必要がある。この方法はスケールしない。</p>
250 <p>多少古い値を読んでも問題無く、結果整合性でよいというのなら幾つかのノードに書き込むだけで良い。こちらの方法はスケールする。</p>
251 </article>
252
253 <article>
254 <h3>
255 非破壊的木構造の利点を活かした分散設計
256 </h3>
257 <p>Jungleで扱うつもりのデータは結果整合性でもよいCMSを想定していることを始めに説明した。</p>
258 <p>そこでJungleはMergeを使うことでデータの整合性をとることにした。</p>
259 <p>Mergeとは、2つ以上の変更を1つの変更にまとめることである。</p>
260 <p>分散システムにおいては、2つ以上のデータの更新が同じデータに対して行われていた場合、
261 更新を受け取って新しいデータを作ることを指す。</p>
262 <p>Mergeは自動で解決出来る場合とそうでない場合がある。</p>
263 </article>
264
265
266 <article>
267 <h3>
268 Mergeによる更新の衝突を自然に解決
298 </h3> 269 </h3>
299 <small> 270 <small>
300 <table style="font-size: 0.7em; width:100%;" > 271 <table style="font-size: 0.7em; width:100%;" >
301 <tr> 272 <tr>
302 <td><p style="margin-top:-5px; margin-bottom:-5px; text-align:center;"><img src="./images/tree_conflict.png"></p></td> 273 <td><p style="margin-top:-5px; margin-bottom:-5px; text-align:center;"><img src="./images/tree_conflict.png"></p></td>
308 <p style="margin-top:0px;">上の図は通常のデータ更新を示す</p> 279 <p style="margin-top:0px;">上の図は通常のデータ更新を示す</p>
309 <p style="margin-top:-20px;">下の図は、同じ木に対して2つのデータの更新があったが編集を無事終えるケースを示す</p> 280 <p style="margin-top:-20px;">下の図は、同じ木に対して2つのデータの更新があったが編集を無事終えるケースを示す</p>
310 </small> 281 </small>
311 </article> 282 </article>
312 283
313 <article> 284
314 <h3> 285
315 Mergeによる更新の衝突の解決ができない場合 286 <article>
287 <h3>
288 Mergeによる更新の衝突が自然に解決できない場合
316 </h3> 289 </h3>
317 <table style="font-size: 0.7em; width:100%;" > 290 <table style="font-size: 0.7em; width:100%;" >
318 <tr> 291 <tr>
319 <td><p style="margin-top:-5px; margin-bottom:-5px; text-align:center;"><img src="./images/tree_conflict2.png"></p></td> 292 <td><p style="margin-top:-5px; margin-bottom:-5px; text-align:center;"><img src="./images/tree_conflict2.png"></p></td>
320 </tr> 293 </tr>
322 <p>木の同じノードに対してデータの編集が行われた場合、どのような編集結果にすればよいかわからない。</p> 295 <p>木の同じノードに対してデータの編集が行われた場合、どのような編集結果にすればよいかわからない。</p>
323 <p>どのような木が組まれ、どのようにデータを保存するかはアプリケーション毎に変わってくる。そのため、アプリケーション毎に 296 <p>どのような木が組まれ、どのようにデータを保存するかはアプリケーション毎に変わってくる。そのため、アプリケーション毎に
324 Mergeアルゴリズムは考えなくてはならない。</p> 297 Mergeアルゴリズムは考えなくてはならない。</p>
325 298
326 </article> 299 </article>
300
301 <article>
302 <h3>
303 JungleとMergeの相性
304 </h3>
305 <p>Jungleは非破壊で過去のデータも保持しているため、更新時に過去のデータを参照して自然なMergeを行うことが可能。</p>
306 <p>自然にMergeできない場合においても、アプリケーション毎にMergeアルゴリズムを設計することで対応する。</p>
307 <p>Mergeが自動で行われるようになれば、Jungleで扱う木構造データは編集を自由に行うことができる。</p>
308 <p>木構造データが自由に行えるようになれば、Jungleはデータのリクエストに対して手元のデータを返すことができる。</p>
309 <p>古いデータを編集されたものが更新されても、いずれはMergeにより最新のデータと合わせられるから。</p>
310 <p></p>
311 </article>
312
313
314 <article>
315 <h3>
316 Jungleの分散実装
317 </h3>
318 <p>以上がJungleにおける分散設計になる。</p>
319 <br/>
320 <p>この分散設計を元にJungleのサーバノード同士でツリトポロジーを構成し、ログによるデータ分散を実装した。</p>
321 <p>また、Mergeの例として掲示板プログラムにおけるMergeの実装も行った。</p>
322 </article>
323
324
327 325
328 <article> 326 <article>
329 <h3> 327 <h3>
330 Jungleの分散実装:掲示板システムにおけるMerge 328 Jungleの分散実装:掲示板システムにおけるMerge
331 </h3> 329 </h3>
686 <img style="margin-top:-30px;" src="./images/consistency_quorum.png"> 684 <img style="margin-top:-30px;" src="./images/consistency_quorum.png">
687 </p> 685 </p>
688 </article> 686 </article>
689 687
690 688
689 <article>
690 <h3>
691 Jungleの分散設計:分散版管理システム
692 </h3>
693 <p>Jungleは分散設計を行うにあたってGitやMercurialといった分散版管理システムを意識している</p>
694 <p style="margin-top:-10px;">分散版管理システムとは多人数によるソフトウェア開発において変更履歴を管理するシステム</p>
695 <p style="margin-top:-10px;">分散版管理システムは次の特徴とAPIを持つ</p>
696 <ul>
697 <li>開発者それぞれがリポジトリのクローンしてローカルに持ち、開発はローカルのリポジトリを通すことで行われる</li>
698 <li>ローカルのリポジトリは独立に存在し、サーバ上にある他人のリポジトリから変更履歴をとることができる。また自身の変更履歴を伝えることもできる</li>
699 <li>データ更新時に先に別の更新が入っていた(衝突)場合はMergeによりデータの整合性をとる</li>
700 </ul>
701 </article>
702
703 <article>
704 <h3>
705 Jungleの分散設計:分散版管理システム
706 </h3>
707 <p>分散版管理システムAPI</p>
708 <ul style="margin-top:-20px;">
709 <li>commit:データに変更を加えたことをリポジトリに登録</li>
710 <li>push:ローカルのリポジトリで行った変更履歴を他のリポジトリへまとめて送る</li>
711 <li>pull:他のリポジトリからの変更履歴をまとめて受け取る</li>
712 </ul>
713 <p style="text-align:center;">
714 <img style="height:200px;" src="./images/distributed_repository.png">
715 </p>
716 <small>
717 <p>分版版管理システムはリポジトリが壊れても別のリポジトリよりデータを復旧できることと、push/pullそれとMergeによる整合性
718 の確保で、高いスケーラビリティを持っている</p>
719 </small>
720 </article>
721
722 <article>
723 <h3>
724 Jungleの分散設計:分散版管理システム
725 </h3>
726 <p>Jungleと分散版管理システムには似通った点がある</p>
727 <li>どちらもデータのコピーが自由</li>
728 <li>データ更新しても過去のデータに影響を与えない</li>
729 <br/>
730 <p><font color="red">同じAPIを実装することで、分散版管理システムと同じく高いスケーラビリティが期待できる</font></p>
731 <p>具体的には</p>
732 <ul>
733 <li>pushやpullによる定期的なデータの更新</li>
734 <li>Mergeによる更新データ衝突の解決</li>
735 </ul>
736 </article>
737
691 738
692 </section> 739 </section>
693 740
694 </body> 741 </body>
695 </html> 742 </html>