分散型NoSQLのAerospikeを触ってみようぜ！（導入編） - 多趣味なやつの雑談
今回は Speee Advent Calendar 2015 - Qiita 22日目です。 昨日の記事はTei1988さんのPebble Watchでmrubyを試す（まだ動かせて無いよ編） - Qiitaでした。 Aerospikeとは？ 前から気になってた分散型NoSQLのミドルウェアだったんですが有料版しかなかったので、なかなか試すことができない状態でした。しかし最近OSS化されたのでお手軽に試すことができるようになりました。 詳しい紹介はWEB+DB PRESS Vol.87｜技術評論社で紹介されてます ！ 特徴としてはトランザクションを備えつつ高速な処理を実現しスケールが楽にできるらしい ということでアド業界では注目されておりすでに導入している企業も多いようです スマホ広告向けソリューションツール「F.O.X」、ミドルウェア「Aerospike」を採用し、広告効果測定におけるデ
Redis 本番障害から学んだコードレビューの勘所
Redis不適切利用による問題は本番運用が始まってから顕在化することが多く、時限爆弾みたいな存在です。事前に防ぐにはコードレビュー段階で叩くしかありません。 Redisはスクリプト言語と相性が良く、適切に利用するとRDBと比較し驚くほど高速なプログラムを組むことができます。昨年尊敬する先輩にコードレビューで斧100本くらい(レビューコメント)投げられて血まみれになりつつ学んだことを、まとめて書いてます。概要は『消えても良いデータならRedis』 Redisのメモリが溢れたら... （この話は事実ではなくファンタジーです。） 深夜電話で叩き起こされました。どうやらアクセス障害みたいです。 何人かで実機確認したら、まったくゲームが遊べない。データ不整合怖いのでメンテIN。 ほどなくしてRedisが溢れメモリ不足で新規書き込みが出来なくなっていると判明。サーバのメモリ容量は64GByteでこれ以
moco(beta)'s backup: KVS性能比較 - memcached / Couchbase / MongoDB / Redis
手軽なKVSとして使えるNoSQL系データベースは沢山あるわけなのですが、単体サーバのset/getの性能に注目して性能比較を行いました。memcachedをベースラインとして、どの程度その性能に追いつくかを調べるのが主目的です。（揮発性のキャッシュでよければmemcached + Consistent Hashing 最強なのですが、永続化できるとうれしい場合があります。。。） [2014.03.21 追記] ベンチマーク系のエントリって、少ないもんだから適当に書いても検索上位にきてしまうらしい、こわい。反省している… [追記ここまで] 計測対象プロダクト memcached v1.4Couchbase v2.0 MongoDB v2.2 (*1)Redis v2.6(*1) MongoDB はRDB並にクエリが書けるくらい機能豊富で、本来こういう比較でもってくるのは不公平なのですが.
etcd総選挙を眺めてみる - Qiita
はじめに (2015/09/20追記) 初出時はv0.3.0くらいだったetcdも今の最新は2.2.0。起動時のオプションやAPIも非互換な形で変わってしまっているので、最新に合わせてお試し部分を少し修正。(@takiuchiさん、ご指摘ありがとうございます) etcdとRaft etcdはCoreOSで使われている軽量KVSで、Configurationなどの情報を複数のマシン間で共有できるようにする仕組みみたい。/etcに置かれた設定ファイルの置き換え的な意味合いで "etc" daemonなのかなと思ったが、語源を発見できず、もしかしたらぜんぜん違うかもしれない。 ともかく、etcdはKVSでありながら複数マシン間でのreplicationを実現している。まぁ、そんなKVSは沢山あるが、etcdで取っているアプローチがやや面白かったのでちょっと調べてみた。 まず、基本になる考え方が、
GoとgRPCでKVS的なものを作ってみた - 小野マトペの納豆ペペロンチーノ日記
正月で時間があったので、以前から触ってみたかったgRPCをGo言語から使い、キー・バリュー・ストアのようなものを作ってみた。 KVSといっても、GoのmapへのGet/Put/Delete/ScanをgRPC経由で叩けるようにしただけのもの。それだけだとあまり面白く無いので、gRPCらしく、Watch機能をつけてmapへの更新を監視できるようにした。 github.com 個人的には、HTTP/1.1 + JSON APIと比べた時のgRPC(HTTP/2 + ProtoBuf)のメリットや違いが気になっていたので、そのあたりを気をつけながら書いた。 開発の手順 サービス定義 まずはProtocol Buffers 3でKVSのサービスを定義する。サンプルを見ながら適当に書いた。 grpc-kvs/grpc-kvs.proto at master · matope/grpc-kvs · G
etcdの分散Key-Valuesストアを試してみる - SDN開発エンジニアを目指した活動ブログ
CoreOSが提供するetcdの動作をお手軽に試してみました。 なお、etcdとは、分散Key-Valuesストアを使い，各種設定をノード間で共有するメカニズムだそうです。 etcd is a distributed key value store that provides a reliable way to store data across a cluster of machines. It’s open-source and available on GitHub. etcd gracefully handles master elections during network partitions and will tolerate machine failure, including the master. ◼️ まずは、環境準備から ... まずは、golang環境を準備してお
kumofsはなぜ落ちないか - Blog by Sadayuki Furuhashi
前回は、kumofsはなぜスケールするかということについて紹介しました。その中で最後に、耐障害性もスケーラビリティにとって重要だーと述べました。 そこで今回は、kumofsはなぜ落ちないのか、なぜ耐障害性が高いと言えるのかーということについて紹介したいと思います。 分散システムはテストが難しいことに定評がありますが（たぶん^^;）、その中でも耐障害性の検証は最上級に困難な部類です。 耐障害性は実際のところ、アルゴリズムの設計以前に実装上のバグが大きく影響するので、設計上は耐障害性が高いと言っていても、実際に使ってみると良く止まるという話はありがちな話です。（個人で開発している場合など、開発リソースが小さい場合はなおさら） そのため耐障害性の高いシステムを実現するためには、実装しやすくバグが入り込みにくい設計も重要かなーと思います（もちろん、アルゴリズムも重要ですが）。 分散システムには複雑
Riak Core の紹介 - kuenishi's blog
Erlang アドベントカレンダー 2014の23日目の記事です。 Erlang/OTPでアプリケーションを書いていると、システムを冗長化するために複数ノードでうまく協調動作するようにさせるために、Distributed Erlangの上に構築されたFailoverやTakeoverを使う場面がいずれ出てくる。しかし、これらの仕組みは、Riakのようにシステムをスケールアウトさせたい場合には不十分だ。スケールアウトするシステムの本質は アクセスしたいモノの物理的な位置を隠蔽して論理的な位置でアクセスできるようにする 物理的な位置が故障やスケールアウトのために変化しても常に追跡できて同じ論理的な位置でアクセスする アクセスしたいモノが偏らず、ほぼ均等に分散されている の3点がサポートされていることだ。これだけだといろんなものが該当するが、 Riak風に翻訳すると アクセスしたいデータがどのノ
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
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://sesim.web.nitech.ac.jp/specialty/thesis/H23/system/system_22413534_kumazaki.pdf