Coordination Service(ZooKeeper，etcd ，consul) の比較
概要 最近，consul，etcd，ZooKeeper といった，いわゆる Coordination Service(この名前は ZooKeeper の論文から拝借した)の実装が頻繁に行われている．本記事では，開発が盛んな背景を踏まえた上で，オープンソース実装の Coordination Service の比較を行う． Chubby から現在まで Paxos が Google の手によって Chubby という形で実用化された後，故障検出+分散合意アルゴリズムを用いた高可用KVSという組み合わせによる Coordination Service のオープンソース実装がいくつが出てきた．そのはしりが ZooKeeper である．ZooKeeper は Hadoop ファミリではデファクトスタンダードの Coordination Service であり，Hadoop を初めとして HBase，M
Talpa memorandum
橘玲の『「読まなくてもいい本」の読書案内』を読んだので、感想とメモをまとめておく。 この本、タイトルは『「読まなくてもいい本」の読書案内』だが、実際には「読まなくていい本」はほとんど紹介されていない。紹介されているのは、当たり前の話かもしれないが読むべき本だ。他の読書案内本と異なっているのは、”こういう本は読まなくて良い”と、ばっさり切り捨てているところ。読むべきか・読まなくてもよいかの基準は、20世紀後半に爆発的に進歩した科学研究の成果に置いている。著者は、この時期に起きた科学研究の大幅な進歩を”知のビッグバン”、”知のパラダイム転換”と呼び、これ以前に書かれた本は（とりあえず）読む必要がないと言い切る。古いパラダイムで書かれた本は捨てて、新しいパラダイムで書かれた本を読もうという話だ。ちょっと乱暴な分け方ではあるが、1980年代に大学生だった私には案外納得できるものだった。学生時代に最
６W２Hでログ設計の考慮事項を考えてみた | dfour
ログの出力内容は意外と設計時に考慮不足で、コーディング時にプログラマのスキルに依存する事が良くあります。 何も問題がなければそれでもよいのですが、エラーメッセージが表示された場合に、どこで何が起きているのか？探すのにログが適切出ないと時間がかかり、利用者への迷惑だけではなく、担当者の作業時間も大きく関係してきます。 そんな背景もあり「６Ｗ２Ｈ」の観点で、設計段階で考えるログ設計の考慮事項を整理してみました。 Index ６Ｗの項目 ２Ｈ＋１Ｗの項目 まとめ ６Ｗの項目 出力日時 – [When] ・年月日時分 ・秒やミリ秒の出力は必要か検討 ・出力時間はUTCかそれとも日本時間か検討 補足: 年月日時分はログとして当たり前の項目ですね。秒・ミリ行はシステムの性質から必要可否を選ぶと思いますが、基本は出しても良いと自分は思います。 意外と見落としなのは基準時間をUTCにするのか、それとも日本
入門Ansibleを出版しました — そこはかとなく書くよん。 ドキュメント
入門Ansibleを出版しました¶ この度「 入門 Ansible 」を、Amazonにて出版致しました。 今までAnsibleに関する日本語の本はありませんでしたが、Ansibleの入門書的な位置づけとして、まずこれを読めば分かる、ということを目指して執筆しました。 本書を執筆するにあたり、レビュー頂いた方々に感謝致します。 内容はちょっと長いですが、以下の通りです。 はじめに Ansibleの特徴 Ansibleはシンプル ChefやPuppetとの違い Ansibleは "Better Shell Script" Ansibleを使ってみよう インストール inventoryファイル モジュール (module) playbookを作ってみよう YAMLの文法 playbookを書いてみる playbookの解説 task handler よく使うモジュール 複雑なplaybookを
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
An end to synchrony: performance improvements in 3.3 | RabbitMQ
Netty 4 - Intro → Changes → HTTP → Lessons learned
