mixi大規模障害について - mixi engineer blog
こんにちは。システム本部技術部たんぽぽGの森本です 先日のmixi大規模障害についてのブログです。 はじめにお断りしておきますが、弊社CTOがtwitterで公開した以上の情報はまだ得られておりません。 twitterでは書ききれなかった細部を補足してみたいと思います 現状判明しているのは以下の点です memcachedに大量の接続・切断を行うとmemcachedプロセスが突然終了することがある memcachedには異常時に終了するフローもあるが、同時に出力されるはずのエラーログは出ていなかった coreも出力されていなかった テスト環境にて追試を行ったところ、なんどか再現させることができましたが、確実に発生する条件は未だ不明です。 障害時の memcachedのバージョンは1.4.4, libeventのバージョンは1.3bです memcached の起動オプションは以下のとおり ./
memcached-1.4 RCをつかってみよう - mixi engineer blog
数日前にmemcached-1.4のリリース候補が出ましたので、今日はその最新版と、それを使ったメモリ節約の運用法を紹介します。厳密にいうと、ご紹介させていただくmemcachedのメモリ節約機能は1.3のbetaから存在し、過去にこちらで取り上げました。 memcached-1.4.0-rc1 1.4 RCは基本的に1.3.* betaで発見・報告されたバグの修正やコードベースの改修が主な内容です。詳しいリリースノートはこちらになります。 http://code.google.com/p/memcached/wiki/ReleaseNotes140rc1 ダウンロードはこちらです。 http://code.google.com/p/memcached/downloads/list 新しいバージョンのmemcachedはバイナリプロトコルの導入以外に地味に生まれ変わっています。例えばコード
mixi主催OpenSocial Hackathonが開催されました! - mixi engineer blog
5月15日に、mixi&OpenSocial-Japan主催OpenSocial Hackathonが開催されましたので、ここで簡単にレポートをしたいと思います。会場は渋谷にあるGoogleの一室をお借りしました。 Hackathonはグループに分かれ、グループごとにひとつの作品を作り上げる過程で開発を体験して頂く、という趣旨で行われます。今回は総勢19名、6チームに分かれて開発を行いました。参加者の皆さんは、事前ミーティングでIdeathonと呼ばれるチーム分けやアイディア出しを行っていたため、Hackathon当日は開発作業に集中していました。とにかく時間との戦いです。今回も、Google API ExpertやGoogleのエンジニアの方、そしてミクシィからも数名がチューターとして参加しました。 では、ここで各チームの成果を見ていくことにしましょう。 宝探し - 位置&Tutoria
mixiアプリはじめました - mixi engineer blog
コードは掲載しないmilanoです。 こんにちは。 先週のことになりますが、以前紹介したOpenSocialプラットフォーム（通称：mixiアプリ）をパートナー企業向けにリリースしました。 プラットフォーム開発チームのメンバーたちに＋＋です。 同時に、mixi Developer Centerもプチリニューアルし、mixiアプリの情報を公開し始めました。 早速いくつものメディアに取り上げていただいています。 「mixiアプリ」、パートナー企業募集スタート - ITmedia News mixiアプリ、パートナー向けにベータ公開:ニュース - CNET Japan 「mixi アプリ」ベータ版が公開。今後は個人開発者にも公開予定 - BB Watch ありがとうございます。 当初はパートナー企業向けですが、そのうち個人の開発者にも公開を考えているようです。個人の方はもうちょいお待ちください。
mixi OpenIDコンテスト始まりました - mixi engineer blog
会社にも家にもグル〜ミ〜グッズが置いてある、グル〜ミ〜好きのmilanoです。 ミクコレも当然のようにグル〜ミ〜です。 こんにちは。 このたび、mixi OpenIDコンテストというものを始めました。 mixi OpenIDといえばプラットフォーム開発チームということで、私がエンジニアブログでも紹介させてもらいます。 mixi OpenIDコンテストは学生の方を対象にしたコンテストで、mixi OpenIDを使用した新しくて楽しいサービスを公募し、私たちも気づいていないソーシャルグラフの新しい活用方法を提案していただこうというものです。 審査員はエンジニアブログでもおなじみ、弊社技術顧問の小山浩之のほか、なんとmixi公認ユーザーの高橋名人も！ 見事選考を勝ち抜けば、高橋名人にプレゼンする機会に恵まれるわけです。 楽しそうですね。 果たして高橋名人はどんなサービスに興味を示すのでしょうか。
mixi Engineers’ Blog » mixiの開発チーム紹介：プラットフォーム編
雨の日の帰宅途中に大きなヒキガエルを見つけたカエル好きのmilanoです。 東京都内でもこんな大きなカエルがいるんだなぁ、と嬉しくなりました。 こんにちは。 さて、mixiというWebサービスの開発を行っているグループを「アプリケーション開発グループ」というのですが、そのアプリケーション開発グループは、担当している案件によっていくつかのチームに分かれています。 そのうちのひとつ「プラットフォーム開発チーム」について紹介したいと思います。 プラットフォーム開発チームの担当は、mixiのプラットフォーム展開に関するさまざまな開発です。 プラットフォーム展開と言ってもよくわからないかもしれないので簡単に説明すると、要するに日記やマイミクの一覧などの情報を外部のサービスから取得できるようにAPIを用意したり、デベロッパーが作成したアプリケーションをmixiの中で実行できるような環境を整えたり、とい
ロングテールな画像配信 その2 - 3,000万の画像を配信するシステム - mixi engineer blog
Squidを検索する度に最初に表示される画像検索の結果に吹き出しそうになる開発部・システム運用グループの長野です。前回のロングテールな画像配信のその2ということで、実際の画像配信システムについて書かせて頂きます。 ■プロフィール画像の配信について 前回紹介しましたが、mixiにおいてプロフィール写真を設定を設定しているユーザ数は全体の約70%、1,000万人の方が設定をされています。現在配信をしているプロフィール画像のサイズは180x180、76x76、40x40と３サイズあり、合計3,000万以上のファイル数になっています。また、もっともよく使われる76x76のサイズ1,000万件において、1日にアクセスされる画像の数は800万ファイル以上、うち97%が30回以下と非常に広範囲に渡ってアクセスされています。そのため大量の画像を配信できる仕組みが必要になります。 ■配信システムの全体像 プ
mixi Engineers’ Blog » スマートな分散で快適キャッシュライフ
今日は以前のエントリーで書くと述べたConsistent Hashingに関して語らせて頂こうかと思います。ただしConsistent Hashingはセミナーやカンファレンスなどでかなり語られていると思いますので、コンセプトに関しては深入りせず、実用性に着目したいと思います。 問題定義 分散されたキャッシュ環境において、典型的なレコードを適切なノードに格納するソリューションはkeyのハッシュ値に対しmodulo演算を行い、その結果を基にノードを選出する事です。ただし、このソリューションはいうまでもなく、ノード数が変わるとキャッシュミスの嵐が生じます。つまり実世界のソリューションとしては力不足です。 ウェブサイトのキャッシュシステムの基本はキャッシュがヒットしなかったらデータベースにリクエストを発行し、レコードが存在したらキャッシュしてクライエントに返すという流れです。ここで問題なのが一瞬
mixi Engineers’ Blog » libmemcachedで快速キャッシュ生活
みんな大好きなmemcached。今日はBrian AkerのC言語用クライエントライブラリについて書きたいと思います。日本語の情報がとても少なく、ドキュメンテーションも英語だけという事で興味はあるけど手をつけていないという方のお役に立てれたらなと思います。 本題の前に why libmemcached? 既にlibmemcacheが存在するのに何故、libmemcached？かと言うと理由の一つは最近libmemcacheの開発が止まったからです。本家ではそれが理由でlibmemcacheではなくlibmemcachedを推奨してますね。又、効率的なメモリ使用、Consistent Hashing、様々なハッシュアルゴリズム、新しいオペレータに対応している等という宣伝文句があります。apr_memcacheというライブラリも存在しますが自分は使った事がないためノーコメント。 ただ、推奨さ
mixi Engineers’ Blog » manを書こう
チャリンコ通勤もそろそろ寒くなってきたと感じる今日この頃のmikioです。今回は、manの書き方について述べてみます。 manとは UNIX系のフリーソフトウェア/オープンソースソフトウェアを世に出す場合、その使い方を示した「man」形式のマニュアルを付属させるのが一般的です。端末上で「man hoge」とやると「hoge」のマニュアルを見ることができるので大変便利で、UNIXを使っている方は日々お世話になっている機構だと思います。ちなみに「man -t hoge」とやるとPostScript形式のデータが出力されるので印刷して見ることもできるんです。 そういうわけでUNIXのソフトウェアはmanをつけて配布するのがあたりまえ的になっていて、つけてないと「なんでやねん」とお叱りをうけることもあります。Debian/GNU Linuxでは、パッケージに含まれる全てのコマンドには各々に対応する
mixi Engineers’ Blog » OAuthは熱いかも？な件に関して
お久しぶりです、最近はすっかり寒くなってきましたねー。原宿のオフィス環境に最近慣れてきたトールマエサカです。さておき、今日は認証API系のお話をしたいと思います。 OAuthとは? OAuthとは、最近注目されているウェブ上での認証プロトコルの事です。1.0プロトコルの最終ドラフトが、今月リリースされ、良い機会なのでエンジニアブログに書いてみました。 このエントリーを書いている課程で資料を検索してみたらまちゅさんが大変素晴らしい記事： WebAPI のアクセス制御に使える OAuth という仕様 OAuth の Auth は認証？認可？ (私もそう思う) を既に書かれている事に気がついたので私は軽くなめる程度にします。 で、実際にOAuthがどういう風に役に立つかというと、例えばウェブサービスAがウェブサービスBから、サービスBでのユーザの認証情報 (idとかpassword) を問わずに
mixi Engineers’ Blog » Inside Tokyo Cabinet その五
先日、MySQL Conferenceという催しに行ってきました。そこでMySQLの開発者のBrian Aker氏およびMichael Widenius氏と話をする機会があったのですが、やっぱしトップランナー達と議論するのは刺激になるなぁと思ったmikioです（その時の資料）。さて、一連の連載も今回が感動の最終回で、TCの性能上の蘊蓄をお届けいたします。 なぜdynamic hashingを使わないか Brianさん達とTCの実装についても少し議論したのですが、その際にdynamic hashingをなぜ使わないのかと問われました。その背景として、TCやQDBMではハッシュのバケット数（＝格納するレコード数を予測してその数倍に設定すべき値）をデータベース作成時に指定しなければならないという問題があります。バケット数が大きすぎると空間効率が劣化し、小さすぎると時間効率が劣化するというトレード
mixi Engineers’ Blog » OpenSSLの暗号文をJava/Perl/Rubyで開く
秘密鍵やプライベートな情報などを秘匿するためにパスワードでデータを暗号化・復号したい場合があります。このとき、暗号化と復号するアプリケーションが同じであれば簡単ですが、例えばCで暗号化してJava、Perl、Rubyで復号するといった風に異なるプラットフォームで暗号データをやりとりする場合には、いくつか気 をつけなければいけないポイントがあります。 OpenSSLによる暗号化 OpenSSLはWebサーバのSSL/TLSサポートに利用されますが、その他にも付属しているopensslコマンドから基本的な暗号アルゴリズムを利用できます。次のような簡単なコマンドで、パスワードを使ってデータを暗号化したり復号したりすることができます: $ echo 'Hello World!' | openssl enc -e -aes-128-cbc > cipher.txt enter aes-128-cbc
mixi Engineers’ Blog » Inside Tokyo Cabinet その四
涼しさに夏の終わりを感じてなんだか寂しくなるも、新しいオフィスから見えるパノラマの空の高さに癒されているmikioです。秋は気が変わりやすいこともあり、今回は唐突にDBMの並列性についての考察を記してみます。 並列性って何? 最近はマルチコアのプロセッサが当り前になってきて、そのパワーを100%引き出すために、並列性をできるだけ高めることが求められるようになってきました。それについて考える前に、まずは用語の整理をしておきましょうか。 並行性 : 二つ以上のタスクを一緒に進めること。必ずしも同時に処理を行うとは限らず、Aを少しやってからBを少しやって、それからまたAを少しやって、またBをやって...といった、いわゆるタイムシェアリングで実現してもよい雰囲気。 並列性 : 二つ以上のタスクを同時に進めること。タスクを複数のマシンに割り当てたり、複数のCPUに割り当てたり、CPU内の複数のコアに
Inside Tokyo Cabinet その参 - mixi engineer blog
この連載のように小難しい記事が続くと、読者の皆さんだけでなく執筆陣まで引いてしまうのではないかと心配しているmikioです。いやいや、いいんです。ハッキングから夜のオカズまでバラエティに富んだブログを目指すべく、私は私なりの記事を、たとえマイノリティ向けだとしても臆さず書いてゆくのです。今回はTCの実装の詳細についてお届けします。 QDBMとどう違うの? QDBMもTCと同様にDBMの一実装で、小さくて速くて使いやすいをモットーに作りはじめて、それなりに目標を達成できたと自負しているプロダクトです。しかし、今思えばいろいろと気に入らない点がいくつかありました。TCはそれを克服すべく一から書き直したものです。具体的には以下の点が違います。 空間効率の向上 : データベースファイルのサイズがもっと小さい 時間効率の向上 : 読み書きにかかる時間がもっと短い 耐障害性の向上 : データベースファ
mixi Engineers’ Blog » Inside Tokyo Cabinet その弐
予定を立てた途端にやりたくなくなる症候群に堪えて連載を続けるmikioです（こんな私でもエアーマンくらいは倒せます）。前回はDBMの基本について説明しましたが、それを忠実に実装しても実際には使いものにはならないことにも触れました。今回は、実用的なDBMに進化すべく、Tokyo Cabinet（およびその前身のQDBM）で考えた工夫についてお話します。 ハッシュ関数についてもう少し 前回の記事に関して、「ハッシュ関数はビットシフト使って実装した方が早いよ」という旨のお便りをいただきました（ありがとうございます）。まさにその通りで、乗算命令（ここではimull）より左シフト命令（ここではsall）の方が速いみたいです（Intelの資料によると、mulが15から18で、salが4とのこと）。しかし、DBMの場合はファイルI/Oにかかる時間が支配的になるというのが重要な点です。したがって、ハッシュ
Inside Tokyo Cabinet その壱 - mixi engineer blog
約半年間の沈黙を破ってOSSの世界に戻ってきつつあるmikioです。先日、Tokyo Cabinet（以下「TC」と呼びます）というデータベースライブラリをリリースしました。今回から数回に分けて、TCの設計と苦労話について連載してみます。 DBMとは TCは、いわゆるDBMの系譜のデータベースライブラリで、単純なハッシュテーブルをファイル上で永続化するだけの機能を提供します。DBMはAT&Tの古代UNIXの時代から受け継がれる伝統芸能なのですが、私はそういう枯れた技術が大好きなのです。 プログラマの皆さんは、PerlやRubyではハッシュ（連想配列）と呼ばれ、JavaやC++ではmapと呼ばれるような、何らかのキーに関連づけてなんらかの値を記録するデータ構造って実によく使いますよね。例えばmixiでは、ユーザアカウントに関連する情報（名前とかニックネームとか）は、ユーザIDをキーにしたハッ
mixi Engineers’ Blog » 開発者のこだわり：キーボード
新卒で入った会社ではキーボードを半年に一回壊していたnealです。今回はmixiのサービスとは関係ないですが、開発部のこだわりの入力デバイス、キーボードについてちょっと書いてみました。 開発部 では「マイキーボード」を持ち込む人が多く、コードを書くプロとしてそれぞれの思いがあります。魚屋さんで例えれば包丁でしょうか？包丁の切れ味が悪かったり、使いにくかったら仕事になりませんよね。それと同じで頭に浮かんだコードを文字列にするキーボードというデバイスは開発者にとって重要な道具です。 社内で一番の人気者はPFU社のHHK。マイキーボード使用者の中でも5割り近くがHHKです。心地よいクリック感と「A」の左横にコントロールがある配列、これだけでもコードを書く人間の心をワクワクさせてくれます。 究極のキーボード を追及すると必ずKINESISの名前が出てきます。タッチや配列だけではなく、独特な「Con
mixi Engineers’ Blog » Linux Programming、epollの話
お久しぶりです、初めての日本の夏に圧倒されているトールマエサカです。 今日はLinuxにおけるネットワークプログラミング関連のネタです。分散データベースサーバの開発過程で最近よくLinuxのepollというイベントハンドリング機能を使っています。これがまた優秀な機能なので紹介します。 このContextでいうイベントハンドラーはサーバがクライエントのリクエストを処理するためのメカニズムです。イベントの感知と通知は大雑把にいうと以下の三つの処理で構成されています： 一つもしくは複数のディスクリプタを監視 ディスクリプタの準備が整うまでハチ公のごとくひたすら待ち続ける 準備が整ったディスクリプタの通知 アプリケーションでの実装は一昔までselect(2)、もしくはpoll(2)というシステムコールで行われていました。二つとも役目は同じですがselect(2)の場合、kernelをいじらない限り
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
