タグ

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

  • 並列データ転送ツール『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
  • リトライと冪等性のデザインパターン - Blog by Sadayuki Furuhashi

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

    リトライと冪等性のデザインパターン - 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
  • 『Amebaなう』リアルタイム検索機能に Apache Solr と MessagePack を採用 - 古橋貞之の日記

    ミニブログサービス「Amebaなう」に検索機能を追加 Apache Solrのカスタマイズにより検索パフォーマンスが大幅向上 検索機能は、当社の研究開発組織「インキュベーションラボラトリー」が開発し、Apache Solrをベースに、検索インデックス作成アルゴリズムの効率化や、データを高速かつ効率的に保存できる技術仕様「MessagePack」と各種圧縮アルゴリズムを組み合わせる等の対応を行いました。 あわせて読みたい:LuceneのインデックスにStoreするデータをMessagePackで圧縮してみた - 社内NEET宣言 MessagePack と各種圧縮アルゴリズムを組み合わせることで、インデックスサイズを80%程度に圧縮することが可能になったようです。 MessagePack を使うと、配列やMapなどの構造を、非常にコンパクトに保存することができます。例えば、[1,2,3]とい

    『Amebaなう』リアルタイム検索機能に Apache Solr と MessagePack を採用 - 古橋貞之の日記
  • ニコニコ動画、分散Key-valueストア「kumofs」を導入 - Blog by Sadayuki Furuhashi

    つい先日、ニコニコ動画モバイルの一部でkumofsを導入した というお話を伺いました。 まだまだ利用は一部でしか始まっていないようですが、これからデータを取りながら運用実績を作っていきたいとのことでした。 kumofsは、バージョン0.3.3でflagsの保存に対応し、バージョン0.3.5でexpireに対応しています。バージョン0.3.4では、Javaクライアントとの互換性を改善しています。 これらの機能の改善に加えて、運用実績やノウハウの蓄積も、オープンソースソフトウェアとして重要な要素の1つと言えます。 kumofs関連資料まとめ や #kumofs@twitter にも、ぜひ注目してみてください^^; kumofsは既に、写真ストレージサービス Ficia(フィシア)での運用実績があります。(ITproニュース) ドワンゴ 研究開発ブログ 分散Key-Valueストア「kumofs

    ニコニコ動画、分散Key-valueストア「kumofs」を導入 - Blog by Sadayuki Furuhashi
  • 並列イベント駆動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
    oinume
    oinume 2010/04/15
  • 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
  • 第101回カーネル読書会 - Blog by Sadayuki Furuhashi

    先日楽天タワーで開催された第101回カーネル読書会で、分散KVS kumofs の設計と実装に関して発表しました。 少々準備不足で十分な発表ができたか不安ではありますが、懇親会で大いに議論が盛り上がったのは良かったです。 そんなわけで、発表資料を公開しました。 kumofsの実装(PDF) クリックで進むムービー版 Keynoteファイル デモ用コード デモ用のコードをいくつか用意していたので、ここに掲載します。 エラー処理などなどはテキトーですが、とりあえず動きます。 MessagePackシリアライズ(C++) kumofsで利用しているシリアライズライブラリMessagePackを使って、オブジェクトをシリアライズするコードです。 シリアライズした結果は標準出力(ファイルディスクリプタ1番)に書き出します。 #include <msgpack.hpp> #include <unist

    第101回カーネル読書会 - Blog by Sadayuki Furuhashi
  • 分散Key-Valueストア「kumofs」を公開しました! - Blog by Sadayuki Furuhashi

    分散Key-Valueストア kumofs を、日オープンソースソフトウェアとしてリリースしました! kumofs@SourceForge kumofs関連資料まとめ kumofsとは? kumofs(クモエフエス)は、実用性を重視した分散データストアです。レプリケーション機能を備え、一部のサーバーに障害が発生しても動作し続けます。単体でも高い性能を持ちながら、サーバーを追加することで読み・書き両方の性能が向上する特徴を持ち、低コストで極めて高速なストレージシステムを構築・運用できます。 kumofsの大きな特徴は、システムの構成の簡単に変更できる点です。システムを止めることなく、簡単な手順でサーバーを追加したり復旧したりできます。アプリケーションには一切影響を与えません。 またkumofsは、広く利用されている分散キャッシュシステムの「memcached」と互換性のあるプロトコルを実装

    分散Key-Valueストア「kumofs」を公開しました! - Blog by Sadayuki Furuhashi
  • memcachedバイナリプロトコルは同期プロトコルを禁止するべき - Blog by Sadayuki Furuhashi

    現状のmemcachedのバイナリプロトコルのクライアント(=libmemcached)は、リクエストの順番通りにレスポンスが返ってくることを期待しており、これはmemcachedバイナリプロトコルを「汎用的なkey-valueベースの分散ストレージのためのプロトコル」として考えると、ひどい実装である。 そのような実装は最適化の余地を大幅に制限してしまい、性能とスケーラビリティが悪化する。memcachedの仕様書は、そのようなクライアントの実装はバグであると明示するべきである。 現状のmemcachedクライアントの実装の問題点と、その解決策について述べる。 同期プロトコルと非同期プロトコル ネットワークプロトコルは以下の2つの種類に分けられる: 同期プロトコル リクエストの順番通りにレスポンスを返す(リクエストの順番とレスポンスの順番が同期している) 非同期プロトコル リクエストした順

    memcachedバイナリプロトコルは同期プロトコルを禁止するべき - Blog by Sadayuki Furuhashi
  • 開発環境としてのMac OS X Leopard - Blog by Sadayuki Furuhashi

    なかなかrootにならせてくれない、ハードウェアを選ばせてくれない、設定ファイルをviでいじらせてくれないなど、不自由なUNIX : Mac OS Xですが、それ故の自由が何物にも代え難い今日この頃。Leopardになってcron+pdumpfsの仕事まで持って行かれてしまいました。 前回のTiger版カスタマイズメモに引き続いて、Mac OS Xのカスタマイズを書いておこうと思います。 Terminal.app タブ機能が実装されたりssh-agentがKeychainと統合されたりと、Leopardで驚異的なアップデートが行われたターミナル周りですが、まだまだ改善できる余地があります。問題は以下の3点。 HomeキーとEndキーが使えない 色が見にくい ショートカットキーが使いにくい まずHomeキーやEndキーですが、これは環境設定で変更できます。Terminal.appの環境設定の

    開発環境としてのMac OS X Leopard - Blog by Sadayuki Furuhashi
  • VIVER日記 - スケールアウトする分散ファイルシステム

    DSAS開発者の部屋で、いかにして多重化+負荷分散されたシステムを構築しているかという仕組みが公開されました。必見(+必聴)です。 「DSASのあれこれ」の資料を公開します VIVER的に重要なのは、dsas.conf。ネットワークブートすると、すべてのマシンの構成がまったく同じになってしまう。VIVERではRUNES(Role-based Unified Network Extension System)というplaggableなアプリケーションを開発することで解決しています。 RUNESの問題は、いちいちプラグインが無いと使えない点。要するに使いにくい。拡張性と使いやすさの両立は難しい…。これは根的に解決する計画があるので、向こう1年以内には解決します。(どうにも開発者リソースが少なくてスパンの長い話になってしまいがち) 資料の中にもありますが、やはり難しいのは、永続的なストレージの

    VIVER日記 - スケールアウトする分散ファイルシステム
    oinume
    oinume 2007/04/24
    なんかすごい
  • 1