第12回 複数のプロセスにおける協調動作のための仕組み─コーディネーション | gihyo.jp
はじめに 前回は、分散システム技術を基本とする耐障害性のための仕組みとして、レプリケーションとロギングについて述べました。今回は、分散システムにおいて複数のプロセスが協調して動作するための仕組みであるコーディネーションについて、その概要を説明します。 コーディネーションとは 並列データ処理系におけるコーディネーションは、複数のプロセス間において、協調して動作をする、または、同意を取るための技術です。すなわち、コーディネーションを行うことにより、並列データ処理系における複数のプロセスが同じ目的（もしくは値）を共有し、各々がその目的のもとで何らかの処理を実行できるようになります。当該技術は、たとえば、複数のプロセスにおける状態やレプリカ間の値の一貫性を保つために用いられます。 コーディネーションにおいては、多くの場合、次のことを前提として議論されるため、特に明示的に言及しない限り、本連載におい
Cephがスケールできる理由、単一障害点を排除する仕組み、負荷を減らす実装
Cephがスケールできる理由、単一障害点を排除する仕組み、負荷を減らす実装：Ceph/RADOS入門（4）（1/4 ページ） Ceph／RADOS が採用しているCRUSH、Paxosといった、分散したデータから正しく応答するための仕組みを支えるアルゴリズムの概要を学びながら、挙動を見ていきます。 連載バックナンバー 本連載では、オープンソースの分散オブジェクトストレージであるCeph/RADOSの技術詳細、実装について見ていきます。第1回ではCephの概要を、第2回ではCeph/RADOSを構成する要素を、第3回では実際にインストールして動作させるところまでを見てきました。 第4回である今回は、Ceph/RADOSの動作する仕組みについて、採用している分散アルゴリズムや単一障害点をなくす仕組み、メタデータ削減の方法などを見ていきます。 Ceph/RADOSのアーキテクチャ概要 Ceph/
CAP定理を見直す。“CAPの3つから2つを選ぶ”という説明はミスリーディングだった
分散システムにおいては以下の3つの要素のうち2つしか同時に満たすことができない、というCAP定理を提唱したのは、Eric Brewer氏でした。 C：Consistency（一貫性） A：Availability（可用性） P：Tolerance to network Paritions（ネットワーク分断への耐性） 一般にリレーショナルデータベースでは、一貫性（C）と可用性（A）をできるだけ保証する代わりに、ネットワーク分断への耐性（P）を犠牲にしています。ネットワークが途中で切れたり大きく遅延した場合、動作が保証されなくなってしまうわけです。 一方でNoSQLでは一貫性（C）よりも可用性（A）とネットワーク分断への耐性（P）を優先させるものが多く、分散システムでの動作に向いていると説明されます。このようにNoSQLの説明にこのCAP定理がしばしば引用されることになり、NoSQLの普及とと
今更CAP定理で分散データストアの勉強を始めてみた - As a Futurist...
長くなったので三行でまとめると CAP 定理を素人なりに調べてみた 分散データストアを CAP 定理で俯瞰してみた どのデータストア使うかの決定因子は CAP 定理的な視点の方がインタフェースとかより先 異論は認めるというか、専門知識ゼロなのでもっと正しい理解があればぜひ教えてくださいませ。 はじめに 僕は MySQL 厨なんですが、最近はやれ「MongoDB がいい」だの「HBase 最高」だのとよく聞きます。これら多種多様なデータストアを語る上で、「RDBMS VS NoSQL」みたいに問い合わせ言語の方式やデータ保存形式の違いで語るのは宗教論かなぁと僕は思ってます。単体プロセスのデータストアとしての特徴とか性能とかは正直なんでもいいかなぁと。 思うに、本質的に重要なのは MySQL の master-slave&sharding という Web で今までスタンダードに使われてきた分散
次世代アーキテクチャ - 急がば回れ、選ぶなら近道
次世代アーキテクチャについての考えをまとめておく。 まずは、Hbaseの勉強会のお話。 某界隈では割と話題になったので、 細かいブログやサイトは結構、紹介されている。 ので特に詳細は省く。 一応tatsuyaさんのSlideshareは Tokyo HBase Meetup - Realtime Big Data at Facebook with Hadoop and HB… slideを見ているだけでは、よくわからないと思うが Jonathanとの会話では、FBはバックエンドの部分を含めて バッチ処理は別のHadoopクラスターで行っている。 相当バリバリ使っているようだ。 したがって、割と話題になっているHbase上でHadoopMRはどうよ？ っていう話は「分ける」ってのが正解に近く、 フロント処理とバック処理は明快にわけることが基本になるようだ。 その上での印象で、 自分の思ったこ
Webアプリケーションにおける Job Queue システムの構成例と Worker を作る際に気をつけること - blog.nomadscafe.jp
Webアプリケーション内で処理を直列に実行せずにJob Queueに回して非同期に実行することが多くなって来て久しいと思いますが、そのおすすめ構成と気をつけることについてつらつらと。 1) 既存のデータベースをキューとして使う構成例 １つ目はMySQLなどのデータベースをキューとして用いる例。既にアプリケーションで利用しているデータベースにキュー用のテーブルを作成して利用します。データベースを利用したキュー管理の仕組みとしてJonk、Qudo、TheSchwartzなどがPerlでは有名どころです。 依存するミドルウェアが増えないので最もシンプルな構成になると思います。 上記の図ではWorkerはアプリケーション内で実行することで冗長性を確保しますが、キューを格納するデータベースはSPOFになります。しかし、、データベースに障害があった場合キューだけでなくすべてのサービスが停止すると思われ
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
分散Key-Valueストア「kumofs」を公開しました！ - Blog by Sadayuki Furuhashi
分散Key-Valueストア kumofs を、本日オープンソースソフトウェアとしてリリースしました！ kumofs@SourceForge kumofs関連資料まとめ kumofsとは？ kumofs（クモエフエス）は、実用性を重視した分散データストアです。レプリケーション機能を備え、一部のサーバーに障害が発生しても動作し続けます。単体でも高い性能を持ちながら、サーバーを追加することで読み・書き両方の性能が向上する特徴を持ち、低コストで極めて高速なストレージシステムを構築・運用できます。 kumofsの大きな特徴は、システムの構成の簡単に変更できる点です。システムを止めることなく、簡単な手順でサーバーを追加したり復旧したりできます。アプリケーションには一切影響を与えません。 またkumofsは、広く利用されている分散キャッシュシステムの「memcached」と互換性のあるプロトコルを実装
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
分散アーキテクチャにおいて一貫性と交換でスケーラビリティを手に入れる