タグ

ブックマーク / developer.cybozu.co.jp (31)

  • yrmcds 1.0.0 をリリースしました - Cybozu Inside Out | サイボウズエンジニアのブログ

    @ymmt2005 こと山泰宇です。去る 7 月に yrmcds という memcached 互換な KVS を公開したことをご案内しました。それから 5 ヶ月経ちましたが、今回は安定版となるバージョン 1.0.0 をリリースをご案内します。 ダウンロードはこちらからどうぞ: https://github.com/cybozu/yrmcds/releases/tag/v1.0.0 0.9.0 からの変更点を短くまとめるとバグがなくなって、memcached より多分高速になっています。ちょっと長めの記事ですが、末尾にいいことが書いてありますので、是非ご一読ください。 yrmcds の特長 レプリケーション サーバーサイドロック No slabs その他 memcached との差異 運用実績と性能 クライアント 0.9.0 からの変更一覧 バグ報告を募集します! yrmcds の特長 y

    yrmcds 1.0.0 をリリースしました - Cybozu Inside Out | サイボウズエンジニアのブログ
    hiro_y
    hiro_y 2013/12/09
  • Kazuho@Cybozu Labs: MySQL のボトルネックを統計的に監視・解析する方法

    MySQL のチューニング、と言った場合には、サーバーパラメータの調整や EXPLAIN コマンドを利用したクエリ実行計画の最適化が話題に上ることが多いです。しかし、発行する全ての SQL について、いちいち EXPLAIN コマンドを使って確認していては、いくら時間があってもたりません。チューニングを効率的に進めるには、まず、ボトルネックとなっている SQL クエリを特定し、次にその最適化を行うべきです。 ではどのようにして、ボトルネックを特定するのか。MySQL Conference & Expo 2009 のキーノートにおいて Mark Callaghan 氏は、Google では SHOW PROCESSLIST コマンドを使った統計的アプローチを使っていると述べていらっしゃいます (参照: MySQLConf 09: Mark Callaghan, "This is Not a

    hiro_y
    hiro_y 2012/12/29
  • Kazuho@Cybozu Labs: Mycached: memcached protocol support for MySQL

    It is a well-known fact that the bottlenecks of MySQL does not exist in its storage engines, but rather in the core, for example, its parser and execution planner.  Last weekend I started to wonder how fast MySQL could be if those bottlenecks were skipped.  Not being able to stop my curiousity, I started  adding memcached proctol support to MySQL as a UDF.  And that is Mycached. From what I unders

    hiro_y
    hiro_y 2010/10/31
    「I started adding memcached proctol support to MySQL as a UDF. And that is Mycached.」
  • Kazuho@Cybozu Labs: XSSに強いウェブサイトを作る – テンプレートエンジンの選定基準とスニペットの生成手法 (第1回神泉セキュリティ勉強会発表資料)

    発表資料は以下のとおり。春山様はじめECナビの皆様、ありがとうございました。 XSSに強いウェブサイトを作る – テンプレートエンジンの選定基準とスニペットの生成手法View more presentations from kazuho.

    hiro_y
    hiro_y 2010/10/31
    型情報を保持して二重エスケープしない自動エスケープ
  • Kazuho@Cybozu Labs: 既製品の管理ツールを使わないことでウェブサービスの TCO を下げる話について hbstudy#8 で話してきた件

    昨日、hbstudy#8 で話をする機会をいただくことができたので、Nagios や Amanda といった既製品の管理ツールやバックアップツールを使わずに内製したことで「パストラック」の運用コストを下げた、という話をしてきました。 もちろん、「既製品を使わない」というのもひとつの手段にすぎませんから、それを無闇にお勧めするつもりはありません。ただ、小回りの効くツールを組み合わせる手法にも十分な競争力があるという点、あるいはその事例として参考になれば幸いです。 スライドはこちら。hbstudy 運営の皆様、話を聞いてくださった皆様、ありがとうございました。

    hiro_y
    hiro_y 2010/03/06
    管理/監視ツールを手製のもので間に合わせる。「監視とは継続的なテストである」は名言。
  • Kazuho@Cybozu Labs: blockdiff を使ったお手軽ホットバックアップ環境の構築 (Linux, MySQL, etc.)

    一昨日に開催された hbstudy #7 にバックアップの話を聞きに行ってきました。Amanda を中心にした話で、とても勉強になりました。が、設定がめんどくさそうだなぁ、とも。自分の需要にはあわない感じでした。 勉強会が終わったあとで、自作のバックアップスクリプト blockdiff に関する話を何人かの方とさせていただいたのですが、思いのほか反応が良かったので、あらためて紹介したいと思います。 blockdiff は、一言でいうと、パーティションやデータベースのデータファイルの差分バックアップツールです。rsnapshot に似ていますが、rsnapshot ではデータベースのホットバックアップ不可能です。逆に blockdiff はディレクトリ単位でのバックアップには対応していないかわり、ファイルシステムやデータベースを、一貫性を保ちつつ実質無停止で差分バックアップすることができます

    hiro_y
    hiro_y 2010/01/24
    LVM上のMySQLをホットバックアップできるblockdiffの紹介。ブロック単位でバックアップ、差分バックアップにも対応。
  • Kazuho@Cybozu Labs: crontab を使って効率的にサービス監視する方法

    監視とは継続的なテストである、という話 (もしくは cronlog とテストスクリプトを組み合わせた監視手法について)に続きます 今日ようやく、積ん読状態だった「Software Design 2010年1月号」を手に取ったのですが、特集が「今日から使えるスクリプト満載! [プロ直伝]お手軽サーバ監視術」。興味深く拝読したのですが、もっと楽ができるのにと思うところも。ちょうど、昨年末に運用しているサービス「パストラック」のサーバを移転し、crontab と perl で書かれたスクリプト群を使った監視環境を構築したところなので、そこで使っているスクリプト cronlog を紹介したいと思います。 特集の前書きにも書かれていることですが、サーバやネットワーク機器が多数ある環境なら、Nagios を始めとする、専ら監視のために作られたソフトウェアを使って、監視システムを構築すべきです。逆に小規

    hiro_y
    hiro_y 2010/01/16
    少数サーバーならcrontabで監視可能。そしてそれを効率化するPerlスクリプト群、kaztoolsの紹介。
  • URL短縮サービスtr.imのサービス終了が教えてくれたこと | 秋元@サイボウズラボ・プログラマー・ブログ

    tinyurlやbit.lyのような短縮URLサービスで、そこそこ人気も利用者もあったとされるtr.imが、サービス終了を案内しています。 既に新規の短縮化や、リダイレクトのアクセス統計サービスなどは停止しており、URLの転送も今年の年末で終了するということ。 twitterのつぶやきなど、字数の制限された書き込みで使われることが多いURL短縮サービスで、半年以上前のURLがクリックされる回数は割合的には低いのかもしれませんが、サービスがなくなってしまうとリンクを辿れなくなる、というこの手のリダイレクトサービスが持つ問題点が発動してしまうことになります。 twitter上での人気URLを集計するtweetmemeでは、twitterで使われた短縮URLサービスのシェアも集計していますが、現時点ではtwitterの公式に採用されたbit.lyが8割近いシェアを獲得して他を圧倒しています。以前

    URL短縮サービスtr.imのサービス終了が教えてくれたこと | 秋元@サイボウズラボ・プログラマー・ブログ
    hiro_y
    hiro_y 2009/08/10
    「twitterでみんながつぶやいているURLというのは、結局のところ誰もが手に入れられる情報だ」「誰でも手に入れられる情報を集計加工してみせるというビジネスは、それ自体では差別化した価値は生み出せない」
  • Kazuho@Cybozu Labs: PostgreSQL のボトルネックを統計的に監視・解析する方法

    先日書いた「MySQL のボトルネックを統計的に監視・解析する方法」について、PostgreSQL でも pg_stat_activity テーブルを使って実行中のクエリ一覧を取得できると higepon さんに教えてもらったので、やってみました。 % ppdump > ppdump.txt のようにクエリをサンプリング (デフォルトで100秒間程度) して、 % ppfilter < ppdump.txt | ppreport のようにすると、平均負荷の高いクエリから順にソートされて表示されます。詳しい使い方や考え方については、mprofile のエントリをご参照ください。 pprofile のソースコードは、/platform/postgresql/pprofile – CodeRepos::Share – Tracに置いてあります。負荷が高い PostgreSQL 環境が手元にないの

    hiro_y
    hiro_y 2009/07/27
    PostgreSQLのクエリの処理状況を定期的に採取→解析。
  • Kazuho@Cybozu Labs: MySQL のボトルネックを統計的に監視・解析する方法

    MySQL のチューニング、と言った場合には、サーバーパラメータの調整や EXPLAIN コマンドを利用したクエリ実行計画の最適化が話題に上ることが多いです。しかし、発行する全ての SQL について、いちいち EXPLAIN コマンドを使って確認していては、いくら時間があってもたりません。チューニングを効率的に進めるには、まず、ボトルネックとなっている SQL クエリを特定し、次にその最適化を行うべきです。 ではどのようにして、ボトルネックを特定するのか。MySQL Conference & Expo 2009 のキーノートにおいて Mark Callaghan 氏は、Google では SHOW PROCESSLIST コマンドを使った統計的アプローチを使っていると述べていらっしゃいます (参照: MySQLConf 09: Mark Callaghan, "This is Not a

    hiro_y
    hiro_y 2009/07/22
    show processlistの結果をモニタリングしてボトルネックを解析。
  • Kazuho@Cybozu Labs: MySQL のトリガーの実用性を確認するために InnoDB の SELECT COUNT(*) を高速化してみる

    最近 RDBMS のトリガーを色々書いているのですが、知らない人にトリガーが何かいちいち説明するのに簡単な例はないかな、というのと、MySQL の処理速度はトリガーによってどの程度変化するか、ということを確認するために、以下のような実験を行ってみました。 InnoDB はしばしば、「SELECT COUNT(*) が遅い!」と批判されます。では、トリガーを使って行数を別のテーブルにキャッシュすればいいのではないでしょうか? 以下のように、極めて小さなテーブル t1 を作り、その行数を t1_cnt にキャッシュしてみることにします。 mysql> create table t1 ( ->   id int unsigned not null primary key auto_increment, ->   v int unsigned not null -> ) engine=innodb

    hiro_y
    hiro_y 2009/07/04
    「トリガーという機能特有のオーバーヘッドは、少なくともこの場合はない」が、多数の行を更新するような場合は当然注意が必要。
  • Kazuho@Cybozu Labs: Pacific という名前の分散ストレージを作り始めた件

    大規模なウェブアプリケーションのボトルネックがデータベースであるという点については、多くの同意が得られるところだと思います。解決策としては、同じ種類のデータを複数の RDBMS に保存する「sharding」 (別名:アプリケーションレベルパーティショニング/レベル2分散注1) が一般的ですが、最近では、分散キーバリューストア (分散 KVS) を使おうとする試みもみられるようになってきています。 分散 KVS が RDBMS sharding に対して優れている要素としては、事前の分割設計が不要で、動的なノード追加(とそれにともなう負荷の再分散)が容易、といった点が挙げられると思います。一方で、Kai や Kumofs のような最近の実装では eventually consistent でこそ無くなってきているものの、ハッシュベースの分散 KVS は、レンジクエリができなかったり (例:

    hiro_y
    hiro_y 2009/06/10
    MySQLをノードとして利用した分散ストレージ。
  • Diggが広告に投票できるようDigg Adsでマネタイズを模索 | 秋元@サイボウズラボ・プログラマー・ブログ

    巨大ソーシャルニュースサイトのDiggが、新しい広告プログラムの開始を宣言した。 Diggのトップページやカテゴリページには、ユーザがdigg(投票)した今一番熱いニュース記事が並んでいるが、この中に広告だとははっきりわかるものの、他のニュースと同じようなフォーマットで、広告主の広告も出すということだ。 上のサンプルだと、上から4つめがEAのゲームの広告になっている。 通常のニュースと同じように、digg(投票)したりbury(逆投票)したりコメントしたりできて、投票が多ければ広告主の支払額も安くなるシステムだという。つまり、面白いと思わせる広告を作ろうというインセンティブが働くわけだ。 これから先、数ヶ月の試験期間を設けてユーザからのフィードバックを集めるということらしい。 ユーザが見続けている内容の中に広告を自然に、しかし広告とわかるように挟もう、という考え方は、今の民放テレビを思わせ

    Diggが広告に投票できるようDigg Adsでマネタイズを模索 | 秋元@サイボウズラボ・プログラマー・ブログ
    hiro_y
    hiro_y 2009/06/05
    Diggが広告を普通のエントリと混ぜて表示、投票によって広告支払額が変動する仕組み。
  • fav.or.it創業者による「もしtwitterを作り直すなら」 | 秋元@サイボウズラボ・プログラマー・ブログ

    コメントつきソーシャルRSSリーダーfav.or.itの創業者Nick Halsteadさんが、自分がtwitterのスケーラビリティを直すならこうする、というエントリを書いている。 twitterは今日も「データベースがロストした」とかで落ちていて、不安定さに対する不満の声をそれこそ毎日のように見かけるようになっている。 技術的な興味から、訳しながら読んでみたのだけれど、ほんとうにこれですべてた解決するのか、については僕はわかっていない。わからないものを出すのもどうかと思い数日放置してたんだけど、もっと手の長い人に読んでもらうのも意味はあるかなと思い直し、以下に公開する。 「fav.or.itはこれよりもっと複雑だ」と言ってるけれどfav.or.ittwitterほどユーザいないし(笑)。 前段では有名ブロガーのRobert Scobleさんが、技術的な理解無しにtwitterをMS

    hiro_y
    hiro_y 2008/06/09
    Twitterのようなタイムライン処理をどう実装するか。
  • GoogleがHTMLフォームの送信先もインデックスすると発表 | 秋元@サイボウズラボ・プログラマー・ブログ

    張られているリンクをより多く見つける目的で、GooglebotにHTML Formを送信させて出てきたページもクロールさせる、という発表があった。 JavascriptやFlashの中から他ページへのリンクを抽出するというのは既に実施していて、今回はそれをページ上の入力フォームにも拡大するものだということ。いわゆるディープウェブ、見えないウェブといわれる領域への進出だ。 クロールされるフォームは以下のようなものに限定されるようだ。 GETメソッドであること robot.txtなどで除外指定されていないこと passwordフィールドを持たないこと user, id, accountなどのフィールドを持たないこと これらを満たすフォームに対して、クローラはいくつか適当な文字を入れてフォームを実行し、その結果新しいリンクが現れたらその先もクロール対象にする、ということ。 この方法で見つかったリ

    hiro_y
    hiro_y 2008/04/27
    Googlebot、GETメソッドのフォームから送信した結果もクロールするように。
  • Diggスパムについて | 秋元@サイボウズラボ・プログラマー・ブログ

    徒党を組んで組織票を使って自分のストーリーを上位にしようとするようなスパムも横行しているが、そうういうのはすぐにしっぺ返しが来るので、インチキは慎むべき。 今回のFastladderのストーリーについたコメントには短文のものが多いのと、どのストーリーにも現われるいじわるなコメンテーター達への反撃が少ないことから、スパム投稿っぽく見てる人もいるのがちょっと残念だ。 ただ、Fastladderなど日語圏でも評価の高いネットサービスはぜひ海外に出て行ってほしいし、がんばってもらいたい。今回、いろいろな不利にもかかわらずある程度の日人Diggユーザが投票しているのは、そういう気持ちもあるのではと思う。 まだdiggのアカウントを持ってない方は、ぜひアカウントを取ってみてはどうだろうか。 この記事は移転前の古いURLで公開された時のものですブックマークが新旧で分散している場合があります。移転前は

    hiro_y
    hiro_y 2007/07/04
    Diggの仕組み、概要。
  • 使い方と次回予告 | 秋元@サイボウズラボ・プログラマー・ブログ

    インストールの手順だけでかなりの分量になってしまいました。この状態で、あなたがInternet Explorerで閲覧したページのURLがアレクサ社に逐一送信されています。また、ポップアップウィンドウをブロックする機能なども有効になっています。 ツールバーの細かい機能と利用法については次回に説明します。 すべての機能を把握するまではツールバーにデータを収集させたくない、という場合は、メニュー[ツール]-[ツールバー]から[Alexa Toolbar]を非表示にすると、データを送らなくなります。 または、[コントロールパネル]の[プログラムの追加と削除]から”Alexa Toolbar”を一旦削除し、連載の次回をお待ちください。 この記事は移転前の古いURLで公開された時のものですブックマークが新旧で分散している場合があります。移転前は現在とは文体が違い「である」調です。(参考)記事の内容が

    hiro_y
    hiro_y 2007/06/21
    Alexaのツールバーの使い方。
  • まとめ | 秋元@サイボウズラボ・プログラマー・ブログ

    現在のアレクサは、主にアレクサ・ツールバーを配布し、そこから収集したアクセス先やアクセス回数のデータを集計することで、各ドメインへのアクセス数や頻度の統計を作っていることがわかりました。 直感的に、インストールした人だけから集めたデータでどれだけ正確な統計になるのか、という疑問がわいてくるのではないかと思います。 また、見ているページの情報を全部他社(アレクサ)に送ってしまうという仕組みはどうなのか、と感じられた方もいるかもしれません。これについても実際に議論が起こっています。 この連載の次回以降の回で、それらの問題についても説明したいと思います。 この記事は移転前の古いURLで公開された時のものですブックマークが新旧で分散している場合があります。移転前は現在とは文体が違い「である」調です。(参考)記事の内容が古くて役に立たなくなっている、という場合にはコメントやツイッターでご指摘いただけ

    hiro_y
    hiro_y 2007/05/08
    Alexaの仕組みとか。
  • Google Mapsの建物が3D化した | 秋元@サイボウズラボ・プログラマー・ブログ

    via mashable Google Mapsで詳細レベルの表示にしたとき、Google Earthで見せているようなビルの高さや形を反映した表示がされるようになったようだ。 プルデンシャルタワー エンパイアステートビル Google Maps APIを使ったページは、まだこの表示形式に切り替わっていないようだ。 mashableによれば、この3D化は米国と日の約35都市について実施されたそうな。 [追記] Modern Syntaxで既にお昼に紹介されてた。ソースも同じ。 この記事は移転前の古いURLで公開された時のものですブックマークが新旧で分散している場合があります。移転前は現在とは文体が違い「である」調です。(参考)記事の内容が古くて役に立たなくなっている、という場合にはコメントやツイッターでご指摘いただければ幸いです。最新の状況を調べて新しい記事を書くかもしれません

    Google Mapsの建物が3D化した | 秋元@サイボウズラボ・プログラマー・ブログ
    hiro_y
    hiro_y 2007/04/17
    Google Mapsが一部3D表示に対応するように。
  • 秋元@サイボウズラボ・プログラマー・ブログ: Alexa(アレクサ)の統計情報の読みかた

    そして、最後ですが重要なデータとして、ユーザがどのサブドメインにアクセスしているのかという割合も入手することができます。 これによって、会社サイトでサービスや製品別にサブドメインを分けているような場合やポータルサイトでジャンルごとにサブドメインがわかれているような場合に、どの部分に人気があるのか、といったことが外部から推測できいます。 たとえば、mixiユーザのアクセスの100回に1回はmixiミュージックというような値を知ることができます。 今回のまとめ Alexaの詳細トラフィックに出ているデータの読み方を、ページの上から順に見て行きました。ご自身の運営するサイトのドメインや、ライバルサイトのドメインを入れて、トラフィック数の変遷のトレンドや、国別のユーザ割合などをチェックされてみてはどうでしょうか。 次回は、Alexaのデータはどうやって作られているか、ということを解説します。Ale

    hiro_y
    hiro_y 2007/04/10
    Alexaで取得できるデータについて。