続々・リトライと冪等性のデザインパターン - あらゆる操作を冪等にする方法 - Blog by Sadayuki Furuhashi
いつも心に冪等性。古橋です。 リトライと冪等性のデザインパターンの完結編です。 だいぶ間が空いてしまいましたが！ 最後に冪等性を実装する汎用的な実装手法についてまとめていきます。 パターン６：操作ログとリクエストIDでUPDATEを冪等にする 同じIDで識別される値がUPDATEされる場合、つまりmutableである値の管理は、一般に冪等に行うのが難しい。 例えば、ユーザーごとに「最後に購入したアイテム」を更新する操作を考えてみると： 1. ユーザーAが最後に購入したアイテムをアイテム1に変更する（UPDATE） 2. ユーザーAが最後に購入したアイテムをアイテム2に変更する（UPDATE） この操作に何の対策もなくリトライを実装した場合、後続のUPDATE処理の結果を古い内容で上書きしてしまう可能性がある： 1. ユーザーAが最後に購入したアイテムをアイテム1に変更する（UPDATE）→
MessagePackフォーマット仕様にTimestamp型を追加 - Blog by Sadayuki Furuhashi
MessagePackフォーマット仕様のPull Request #209をマージし、MessagePackにTimestamp型を追加しました。 ※この記事の英語版は XXX にあります（翻訳中） Extension型の型コード -1 として定義されているため、後方互換性が維持されています。つまり、既にExtension型に対応しているデシリアライザであれば、Timestamp型を使用して作成されたデータを、Timestamp型に対応していない古いデシリアライズで読み出すことができます。 新しいTimestamp型には timestamp 32、timestamp 64、timestamp 96 の3つのフォーマットがあり、よく使う値をより少ないバイト数で保存できるようになっています。例えば、1970年〜2106年までの時刻で、秒までの精度しか持たない時刻であれば、合計6バイトで保存でき
Embulkでやりたいことリスト（2015年7月版） - Blog by Sadayuki Furuhashi
バルクロード機能 1つの設定ファイルで複数ジョブを実行する Running multiple jobs using one config file · Issue #167 · embulk/embulk · GitHub 例えば users.csv と histories.csv の2つのファイルを、それぞれPostgreSQLにある users と histories の2つのテーブル にロードしたいというようなユースケースに対応する機能。 設定ファイルの構文はissueに書いてあるように、default: に書き並べた設定に対して、jobs: に書いた設定をマージしたものを実際の設定ファイルとして実行していく方法で良さそう。しかし、fliters: は配列なので、default: に書かれた filters: に jobs: に書かれた filters: をどうマージするか、あまり良
Re: 論理削除はなぜ「筋が悪い」か - Blog by Sadayuki Furuhashi
Kazuhoさんの論理削除はなぜ「筋が悪い」かを読んで。 UPDATEが発生しないテーブルならば、削除フラグを使った実装手法でも現在の状態と更新ログを別々に表現でき、結果として効率と過去の情報を参照できるメリットを簡潔に両立できるのではないか、という話。 大前提として全く同意なのだけども、今あるテーブルにdeleted_atを足すだけで、過去のレコードを復旧可能なようにしたい＞＜ みたいに思っちゃった僕のような人間が実際に取るべき実装手法は何か、あるいは、それを想定して今やっておくべきテーブル設計はどういうものか！？というのが最後の疑問。 まずUPDATEがなければ、immutableなマスタ、更新ログ、「現時点のビュー」の３テーブルは、例えば次のようになる（PostgreSQLの場合）： -- immutableなマスタ。 create table records ( id serial
デシリアライズ速度の比較 ByteBuffer vs DirectBuffer vs Unsafe vs C - Blog by Sadayuki Furuhashi
OpenJDK や Hotspot VM には sun.misc.Unsafe という内部APIがあり*1、これを使うと ByteBuffer.getInt や ByteBuffer.getLong よりも高速にバイト列から整数値をデコードできるという。これを駆使することで、Cで実装された拡張ライブラリに匹敵する速度を出せるらしい。 それが本当なら、データ圧縮やハッシュ関数、シリアライザ/デシリアライザなどの実装を高速化できる。例えば、lz4 や xxhash のJava実装が Unsafe API を使用している*2：jpountz/lz4-java Prestoも、中間データのシリアライズ/デシリアライズにはすべて Unsafe API を使っている*3。 そこで、実際にベンチマークしてみた。 ベンチマーク内容 10MBのランダムなバイト列を生成する 先頭から1バイト読み出す その1バ
続・リトライと冪等性のデザインパターン - リトライはいつ成功するか - Blog by Sadayuki Furuhashi
三度の飯よりエラー処理。古橋です。 大変好評をいただいた序章リトライと冪等性のデザインパターンの続編です。 前回はほぼ前置きでしたが、今回は冪等でない操作を冪等にする具体的なテクニックもまとめていきます。 パターン２：エラーを区別してDELETEを冪等にする リソースに常に一意なIDが振られていれば、Deleteを冪等にするのは難しくない。そもそも同じリソースを2度削除することはできない。 一つ注意するべきなのは、削除されたリソースのIDが再利用されるケースでは、Deleteの冪等性は保証されない。例えば、kill -KILL <pid> コマンドはDelete系のAPIと考えられるが、pidは再利用されるので、何度も繰り返すと意図しないプロセスを殺してしまう可能性がある。 一般にIDの生成は非常に難しい問題だが、Deleteに関してのみ言えば再利用されなければいいので、単調増加する整数（
リトライと冪等性のデザインパターン - Blog by Sadayuki Furuhashi
リトライを肴に一晩酒が飲める古橋です。 大規模なデータに触れることが日常茶飯事になっている今日この頃。この分野のおもしろいところは、いつまで経っても終わらないプログラムを簡単に作れてしまうことかもしれません。エラー処理、リトライそして冪等性*1の３つを抑えていないプログラムは、小規模なデータなら問題ないが、データ量が多くなると使い物にならなくなる可能性が大です。 大規模データをバッチ処理するケース以外でも、リトライは一般にプログラムの信頼性に関わる重要な問題です。 そんなわけで、リトライに関わるいくつかのデザインパターンを、連載でまとめておこうと思います*2。 では、第1回は背景から： なぜリトライが必要なのか プログラムは色々な理由で失敗する。例えば、 A) 通信先のプログラムが高負荷すぎて応答できなかった B) メモリを消費しすぎてメモリ確保に失敗した。またはOOM KIllerに殺さ
データの更新履歴をRDBMSからfluentdに流すfluent-plugin-sql - Blog by Sadayuki Furuhashi
Fluentd Advent Calendar 9日目。担当の古橋です。 Fluentd v11の情報は Fluentd Casual Talks #3 at :D でお話しすることにして、今回はFluentdの大幅な性能向上を可能にするMultiprocessプラグインを紹介…しようと思っていたら@niku4i さんに先を越されてしまったので！今回はSQL inputプラグインを紹介します。 SQL inputプラグインとは？ SQL inputプラグインは、SELECT文を定期的に実行することで、RDBMSから最近更新されたレコードや最近追加されたレコードを定期的に取り出してFluentdに流すことができるプラグインです。内部では"前回読み出したレコード"を記憶しており、前回読み出したタイミングより後になって更新/追加されたレコードを定期的に読み出します。 SQL input plug
「分散システムのためのメッセージ表現手法に関する研究」 - 筑波大学大学院を卒業しました - Blog by Sadayuki Furuhashi
このたび筑波大学大学院を卒業し、修士号を取得しました。卒業にあっては本当に多くの方々にご助力いただきました。この場を借りて御礼申し上げます。ありがとうございました。 現在は起業して、12月からアメリカに在住しています。新たな価値を生み出すべく "下から上まで" システムの設計と開発に携わっており、エキサイティングな毎日を送っています。 修論シーズンに日本にいなかったので、修士論文はメールで送って提出し、卒業式にも出席していないというありさまなので、本当に卒業できたのかどうか実感がないのですが、友人によれば「学位記はあった」らしいので、きっと大丈夫でしょう。（写真はカリフォルニア州マウンテンビューにて） さて、せっかく時間を割いて書いたので、修士論文を公開することにしました。 分散システムのためのメッセージ表現手法に関する研究と題して、バイナリ形式のシリアライズ形式である MessagePa
高速ログフォーマットと簡単な解析機能の実装 - Blog by Sadayuki Furuhashi
先日の高速ログフォーマットの提案を実際に実装してみました。 ログを MessagePack でシリアライズしてバイナリ形式で出力することで、生のバイト列をBase64などでエンコードしなくてもログに書き出せるようにし、また高速に解析できるようにしようというアイディアです。 ソースコード：logpack.tar.gz（コンパイルするにはMessagePackのC++用ヘッダとgem install msgpackが必要） twitterやコメントでいただいたアイディアを参考に、いちばんシンプルなフォーマットにしてみました： ログサイズ [アクセスログ, {"時刻": 1230415655, "URL": ["index.html"], "UA": "Mozilla/5.0 ... Firefox 3.0.5"}] ログサイズ [アクセスログ, {"時刻": 1230415656, "URL"
高速ログフォーマットの提案 - Blog by Sadayuki Furuhashi
バイナリ形式のログフォーマットが必要になったので（テキストだと生バイト列を出力できなくて困る。Base64はイヤ）、どうせならオレオレフォーマットではなく一般的に使えるフォーマットだといいなーと思いメモ。 最初の発想 改良1：定義ファイル（静的型付け） 改良2：自己記述性（動的型付け） 改良3：enum 最初の発想は、ログに出力したい内容を MessagePack でシリアライズして出力するだけ。↓こんな感じ。（表記はJSON） [アクセスログ, {"時刻": 1230415655, "URL": ["index.html"], "UA": "Mozilla/5.0 ... Firefox 3.0.5"}] [アクセスログ, {"時刻": 1230415656, "URL": ["index.html"], "UA": "Mozilla/5.0 ... Safari/525.13"}] [
MessagePack for Java ついに 0.6 リリース！ - Blog by Sadayuki Furuhashi
先日の fluent に引き続き、新しいソフトウェアのリリースです。 満を持して、MessagePack for Java 0.6 をリリースしました！ 9ヶ月ぶりのメジャーバージョンアップです。 以前のバージョン 0.5 の API をすべて見直し、互換性を維持しながらも、数多くの機能を新たに搭載しました。動的オブジェクトAPI や リフレクション機能の強化、JRubyとの連携、JSONサポート などなど。もちろん、性能も大きく向上しています。 このバージョン 0.6 のリリースによって、MessagePack の応用範囲は大きく広がります。MessagePackは、クラウドシステムからモバイルデバイスデバイスまで、多種多様なシステムの連携と統合をサポートする、新しいデータ表現形式です。 さて、新機能の詳細をご覧下さい： JSONシリアライザ･デシリアライザを統合 MessagePack
イベントログ収集ツール fluent リリース！ - Blog by Sadayuki Furuhashi
こんにちは。Treasure Data の古橋です^^; 先日の Treasure Data, Inc. 壮行会 で、イベントログ収集ツール fluent をリリースしました！ Fluent event collector fluent は syslogd のようなツールで、イベントログの転送や集約をするためのコンパクトなツールです。 ただ syslogd とは異なり、ログメッセージに テキストではなく JSON オブジェクト を使います。また プラグインアーキテクチャ を採用しており、ログの入力元や出力先を簡単に追加できます。 Twitterでも話題沸騰中です：イベントログ収集ツール #fluent 周りの最近の話題 背景 「ログの解析」は、Webサービスの品質向上のために非常に重要です。Apacheのアクセスログだけに限らず、アプリケーションからユーザの性別や年齢などの詳しい情報を集め
MessagePack-Hadoop Integration (HBase勉強会) - Blog by Sadayuki Furuhashi
Hbase勉強会（第二回）で発表したスライドを公開しました： MessagePack+Hadoop (HBase-study 2011-06-16 Japan) - Scribd MessagePackとHadoopを連携させるプロジェクトは、github の msgpack/msgpack-hadoop で進行中です。 HBase や Hive で、非構造化データを効率よく扱えるようにすることを目指しています。データはとりあえず突っ込んで、スキーマやクレンジングは後で考えたい（変更したい） というニーズにピッタリ合うハズです。 ログ収集ツールFluentも、オープンソースで公開するべく現在準備中です。 Fluent は、Facebook が開発したログ収集ツールである Scribe と似たツールです。Scribe がメッセージの表現として文字列しか使用できないのに対し、Fluent は
Webサイトをgithubで管理してpush時に自動的に同期する方法 - Blog by Sadayuki Furuhashi
Webサーバに Subversion のサーバを立てておき、HTML や CSS を commit することでWebサイトを更新する方法は、良く知られているテクニック、らしいですね*1。更新の履歴を残すことができるし、ましてチマチマとFTPやsftpでアップロードするよりずっと簡単です。 しかし SVN の代わりに git を使おうとすると、pushしてもリポートリポジトリではファイルを更新してくれません。 また、リポジトリはWebサーバ上に作るよりも、便利な管理インタフェースがある github（や噂のgitosis）に置いておきたいところです。 そこで、github の Post-Receive Hook を使うと、リポジトリに変更を push すると同時に、Webサーバにも同期させることができます*2。 Webサーバに同期する前に、Sphinxでドキュメントを整形したり、SassをC
Amazon EC2 で手元のホストとファイルを共有する - Blog by Sadayuki Furuhashi
Amazon EC2 はVMを好きなタイミングで好きなだけ使うことができるので、複数のサーバを使う分散システムの検証環境として非常に使いやすい*1。費用を計算してみても、自宅でクラスタを動かすことを考えれば、十分安く上がりそうである。 しかし、VMを起動するたびに環境を設定したり、新しいテストを実行するたびにファイルを配ったりするのは面倒なので、ファイルを共有したくなる。 通信の遅延がかなり大きいので、EC2上でssh越しにファイルを編集するのも少々つらい。 そこで、手元のホストとホームディレクトリを共有する。さらに、一度転送したデータはキャッシュさせる。 共有ホームディレクトリ環境の管理方法と組み合わせれば、便利に使えるに違いない。 戦略 ファイル共有には NFSv4 over ssh を使う。NFSv4はポート番号を１つしか使わない（portmapperも要らない）ので、ssh越しで使
共有ホームディレクトリ環境の管理方法 - Blog by Sadayuki Furuhashi
MacPorts や apt などのパッケージ管理システムでインストールできないアプリケーションやライブラリ、自分で書いたツールなどを、ホームディレクトリにインストールしたいことは良くある。 ホームディレクトリならroot権限が要らないし、rootを持っている場合でも思わぬ操作ミスや設定ミスのリスクを抑えられる利点がある。アンインストールもしやすい。gem や easy_install などのスクリプト言語の管理システムが、OS全体のパッケージ管理システムと競合してしまう問題も回避できる。 このようにホームディレクトリにアプリケーションをインストールするときに、複数のバージョンを同時にインストールしたいことがある。また、異種のOSやCPUアーキテクチャのマシンでホームディレクトリを共有したかったりする*1 *2。 以上のような要求があるときに、ホームディレクトリ環境をどうのように構築し、P
MessagePack for PHP＠Webホスティング - Blog by Sadayuki Furuhashi
先日 phpのserializeを使うより高速でサイズもコンパクトに仕上げる「MessagePack」とPHP拡張 でも紹介されている MessagePack for PHP ですが、Webホスティングサービスにも標準で組み込まれ始めているようです： Joe’sウェブホスティング、高速シリアライズライブラリ「MessagePack」のPHP拡張モジュールを全共用サーバーに提供開始 MessagePackはオープンソースで開発が進んでいるプロジェクトです。そして各言語版はそれぞれの言語のエキスパートによって実装されるという形態になっています（自然にそうなったのですが^^;）。 PHP版はadvectさんによる実装です。 実はPHP版には以前に別の実装があり、advectさんから新しい実装が送られてきたときは 2,3回くらい提案された実装を全部リジェクトした という経緯があるのですが（笑）、最
Kyoto Tycoon に MessagePack-RPC をプラグインして Java から使う - Blog by Sadayuki Furuhashi
Tokyo Cabinet を始めとする Tokyo シリーズの作者として知られる平林幹雄さんですが、Tokyo シリーズに続く新製品として、Kyoto シリーズがリリースされています。 Kyoto Tycoon（以下KT）は、ネットワーク経由で使えるデータベースサーバで、Tokyo Tyrantの後継製品に当たります*1。 KT は HTTP ベースのプロトコルで操作することができますが、別のプロトコルを追加することもできます。 実際に memcached プロトコルのプラグインが標準でバンドルされています。（memcachedプロトコルをKTにプラグインする） と言うわけで、KT を MessagePack-RPC で使えるようにするプラグインを書いてみました。github からダウンロードできます。 kt-msgpack kt-msgpack downloads MessagePac
並列メッセージングフレームワーク「MessagePack-RPC for C++」リリース - Blog by Sadayuki Furuhashi
分散KVS kumofs のコードは、全体で約2万行です。 そのうち、ネットワークI/Oやプロトコルに関するコードは約1万行で、全体の約半分を占めています。 並列イベント駆動I/Oフレームワーク「mpio」リリース ネットワークアプリケーションを実装する上で、もっとも大きな障壁は、ネットワークI/Oとプロトコルです。 では、それが両方ともフレームワークでサポートされ、コードを書く必要が無くなったらどうでしょうか？ 54行で簡単な分散KVSを実装したり、140行で分散リアルタイム検索エンジンを実装することができます。すなわち、インデックス作成サーバ、検索サーバ、DBサーバなど、多数のサーバが連携し、スケールアウトの恩恵を得ることができるネットワークアプリケーションを、１台のホスト上で動作する並列アプリケーションとほぼ同じように書くことができます。 実装上の問題から解放されれば、並列性や耐障害
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
