タグ

ブックマーク / frsyuki.hatenablog.com (9)

  • リトライと冪等性のデザインパターン - Blog by Sadayuki Furuhashi

    リトライを肴に一晩酒が飲める古橋です。 大規模なデータに触れることが日常茶飯事になっている今日この頃。この分野のおもしろいところは、いつまで経っても終わらないプログラムを簡単に作れてしまうことかもしれません。エラー処理、リトライそして冪等性*1の3つを抑えていないプログラムは、小規模なデータなら問題ないが、データ量が多くなると使い物にならなくなる可能性が大です。 大規模データをバッチ処理するケース以外でも、リトライは一般にプログラムの信頼性に関わる重要な問題です。 そんなわけで、リトライに関わるいくつかのデザインパターンを、連載でまとめておこうと思います*2。 では、第1回は背景から: なぜリトライが必要なのか プログラムは色々な理由で失敗する。例えば、 A) 通信先のプログラムが高負荷すぎて応答できなかった B) メモリを消費しすぎてメモリ確保に失敗した。またはOOM KIllerに殺さ

    リトライと冪等性のデザインパターン - Blog by Sadayuki Furuhashi
  • 並列データ転送ツール『Embulk』リリース! - Blog by Sadayuki Furuhashi

    こんにちは。古橋です。 先日の*1 データ転送ミドルウェア勉強会で、新しいオープンソースツール Embulk をリリースしました。 Embulk, an open-source plugin-based parallel bulk data loader from Sadayuki Furuhashi Embulk は、リアルタイムなログ収集では常識となった fluentd のバッチ版のようなツールで、ファイルやデータベースからデータを吸い出し、別のストレージやデータベースにロードするためのコンパクトなツールです。 fluentd と同様にプラグイン型のアーキテクチャを採用 しているため、RubyJavaで簡単なコードを書くことで、様々なファイルフォーマットやストレージに対応することができます。一方で fluentd とは異なり、高速性やトランザクション制御、スキーマを使ったデータのバリ

    並列データ転送ツール『Embulk』リリース! - Blog by Sadayuki Furuhashi
  • イベントログ収集ツール fluent リリース! - Blog by Sadayuki Furuhashi

    こんにちは。Treasure Data の古橋です^^; 先日の Treasure Data, Inc. 壮行会 で、イベントログ収集ツール fluent をリリースしました! Fluent event collector fluent は syslogd のようなツールで、イベントログの転送や集約をするためのコンパクトなツールです。 ただ syslogd とは異なり、ログメッセージに テキストではなく JSON オブジェクト を使います。また プラグインアーキテクチャ を採用しており、ログの入力元や出力先を簡単に追加できます。 Twitterでも話題沸騰中です:イベントログ収集ツール #fluent 周りの最近の話題 背景 「ログの解析」は、Webサービスの品質向上のために非常に重要です。Apacheのアクセスログだけに限らず、アプリケーションからユーザの性別や年齢などの詳しい情報を集め

    イベントログ収集ツール fluent リリース! - Blog by Sadayuki Furuhashi
    kenichiice
    kenichiice 2011/10/03
    「fluent は syslogd のようなツールで、イベントログの転送や集約をするためのコンパクトなツールです。」
  • mplexでソースコードレベルメタプログラミング - Blog by Sadayuki Furuhashi

    Webアプリケーションを作るとき、HTMLを生成するテンプレートエンジンをよく使いますが、これはパラメータに応じて様々なコードを生成する自動生成ツールであると言えます。 mplexは、プログラムを生成するためのテンプレートエンジンです。 実は MessagePack-RPC for C++ の実装に使っています。似たような関数をたくさんオーバーロードするために活用しています。(そろそろ可変長templateを使いたいですねぇ) 昔はeRubyを使っていたのですが、HTML用のテンプレートエンジンはソースコードがあまりに読みにくくなるので自作しました。 mplexを使うと、普通のプログラムの中にRubyのコードを埋め込むことができます: // クラスを4つ生成 %4.times do |i| class Test[%i%] { public: %if i % 2 == 0 int even;

    mplexでソースコードレベルメタプログラミング - Blog by Sadayuki Furuhashi
    kenichiice
    kenichiice 2010/12/22
    「mplexを使うと、普通のプログラムの中にRubyのコードを埋め込むことができます」
  • Introducing the MessagePack - Blog by Sadayuki Furuhashi

    高速なシリアライズライブラリ MessagePack の新しいWebサイトをオープンしました! The MessagePack Project Ruby Inside でも取り上げられたようです: MessagePack: Efficient, Cross Language Binary Object Serialization 昨今、効率を重視したシリアライズライブラリが数多く登場しています。特に、大量の処理を行う大規模な基盤システム向けに開発されていることが多いようです。 少し探してみるだけでも、次のような事例が見つかります: BERT(githubで採用:Introducing BERT and BERT-RPC) Thrift(Facebookが開発:Thrift: Scalable Cross-Language Services Implementation) Avro(Hado

    Introducing the MessagePack - Blog by Sadayuki Furuhashi
    kenichiice
    kenichiice 2010/04/22
    「不連続なバッファでも、writevシステムコールを使うと直接ファイルやソケットに書き出すことができます。」
  • 並列イベント駆動I/Oフレームワーク「mpio」リリース - Blog by Sadayuki Furuhashi

    分散KVS kumofs のコードは、全体で約2万行です*1。 そのうち、ネットワークI/Oやプロトコルに関するコードは約1万行*2で、全体の約半分を占めています。 ロジックは残りの半分*3だけで実装されています。 この実例から分かりますが、kumofsのような分散アプリケーションを開発するにはI/O周りの実装が大変で、とてつもなく大きな障壁になっています。*4 さらに今日では、性能を稼ぐためにマルチスレッド化が必須です。また、多数のクライアントを少ないリソースで効率よく相手にするには、非同期・イベント駆動型のアーキテクチャも必要になります。さらに、究極的な性能を達成すべく GC を利用しない C++ においては、実装のみならず設計も大変です。 これに加えてソケットAPIの難解な挙動に対処にしなければならないため、C言語やC++によるネットワークプログラミングは、vimの使いこなしなどと同

    並列イベント駆動I/Oフレームワーク「mpio」リリース - Blog by Sadayuki Furuhashi
  • MessagePack + Wavy で高速なRPCサーバーを書く「ccf」 - Blog by Sadayuki Furuhashi

    先日、追記型オブジェクトストレージKastorを紹介しました。そこで「C++でクラスタアプリケーションを書くためのフレームワーク(ccf; Cluster Communcation Framework)を実装中」などなど書きました。 最近C++でサーバープログラムを書くときには MessagePack(シリアライザ・デシリアライザ。プロトコルに利用)とmp::wavy(イベント駆動I/Oとスレッドプールを統合してうまく動かすライブラリ)という2つのライブラリを使うことが多い*1のですが、この2つを組み合わせるときにいつも似たようなコードを書いていたので、いっそまとめて1つのフレームワークのようにしたら便利そうだなーという動機でccfの開発を始めました。 …以下長々と書いていますが、論よりコード。このヘッダ と サーバーのサンプル と クライアントのサンプル を見れば、何ができるのかは大体分

    MessagePack + Wavy で高速なRPCサーバーを書く「ccf」 - Blog by Sadayuki Furuhashi
  • Protocol Buffersは遅い - Blog by Sadayuki Furuhashi

    Google の Protocol Buffers は、同技術と競合するバイナリシリアライズ形式である MessagePack と比べて、場合によっては 19倍 以上遅く、シリアライズ後のデータサイズは 7倍 以上になることがあります。平均的に見ると MessagePack の方が高速であり、高い性能が必要とされるなら Protocol Buffers より MessagePack を選択するべきです。 …とはいえどちらも非常に高速なので、実際にはそのAPIの違いで選んだ方が良い。Protocol Buffers と MessagePack は重視している点が異なり、使い勝手は大きく異なる。 Protocol Buffers とは何か Protocol BuffersはGoogleが開発したバイナリエンコード手法で、以下のような要素が提供されます: データフォーマットを記述するための言語(

    Protocol Buffersは遅い - Blog by Sadayuki Furuhashi
    kenichiice
    kenichiice 2008/11/19
    「どちらを使うかはむしろAPIの違いで選んだ方が良いと思います。どうも両者は思想が違うらしく、使い勝手は大きく異なります。」
  • P2P分散ストレージ「Cagra」 - Blog by Sadayuki Furuhashi

    id:nyaxt氏との共同開発の分散ストレージ「Cagra」(かぐら)のアルファ版をリリースしました。 cagra α3リリース cagra テクニカルデモ α2リリース 分散ストレージエンジンテクニカルデモ α版リリース cagraのα版試してみたよ - takumalog Cagraは以下のような特徴を持った(目指した)P2P分散ストレージです。 Zeroconf マルチマスタでレプリケーションするWrite 高速な分散Read オプションで高速な非同期Write インターネットレベルよりもLANレベルのマシン台数に特化 巨大データサポート 高速イベント駆動システムコール+軽量スレッド 超アジャ〜イルな開発体制 まだα版で全部が実装されているわけではないですが、とりあえず動きます。 Zeroconf UDPマルチキャストでノードを自動的に発見するので、一切設定ファイルを書かずに動作せる

    P2P分散ストレージ「Cagra」 - Blog by Sadayuki Furuhashi
  • 1