タグ

ブックマーク / mixiengineer.hatenablog.com (15)

  • スマートフォン開発研修教材の公開について - mixi engineer blog

    クラフトワークの来日公演3-D CONCERTS 1 2 3 4 5 6 7 8を観にいったら、顔が大きいのか、3Dメガネがきつくて切なかったもりもとです。 株式会社ミクシィでは、新卒入社スタッフをはじめ、これからスマートフォンアプリ開発を行っていく全スタッフを対象に、社内で「スマートフォン開発研修」を始めています。その研修資料をこのたびgithubで公開させていただきました。 mixi-inc/iOSTraining · GitHub https://github.com/mixi-inc/iOSTraining mixi-inc/AndroidTraining · GitHub https://github.com/mixi-inc/AndroidTraining これら文書は、それぞれCC BY-SA 3.0およびApache License 2.0とCC 2.5 Attributi

    スマートフォン開発研修教材の公開について - mixi engineer blog
    ftnk
    ftnk 2013/05/28
    mixi
  • mixiのサーバOS移行のお話 - 前回補足&インストール編 - mixi engineer blog

    こんにちは。新しもの好きが集まる運用部アプリ運用グループの清水です。 前回の記事では、多くの反響をいただきました。ありがとうございます。 Twitterや、はてブのほとんどのコメントを読ませていただきました。 みなさんのOSの宗派が垣間見えた気がします。 さまざまなコメントをいただいていた中で、よくある代表的なコメントについて、改めてこの場を借りてお答えしたいと思います。 2012年12月28日追記: 以下のQAにつきまして、いわゆる"ネタ"として書きましたが、誤解を招き、不適切な表現で不快な思いをされた方々へ深くお詫び申し上げます。 また、QAの一部に関わるところですが、OS標準のパッケージを否定するつもりは全くございません。 Linuxを安心して使うことができるのは、Linuxディストリビューションに携わっているデベロッパーの方々の素晴らしい活動や成果によるもの、というのが揺るぎない事

    mixiのサーバOS移行のお話 - 前回補足&インストール編 - mixi engineer blog
    ftnk
    ftnk 2012/12/27
  • mixi大規模障害について その2 - mixi engineer blog

    こんにちは。システム技術部たんぽぽGの森です 補足を追記しました (2010/08/20 15時) 先日のmixi大規模障害についての続報です 今回は小ネタはありません はじめに まず初めにtwitter/blogなどを通じて今回の問題の解析を行っていただいたみなさんに感謝の言葉を捧げたいと思います kzk_moverさん stanakaさん mala(bulkneets)さん llameradaさん (順不同) ありがとうございました 書き漏らした人ごめんなさい memcachedはすごい 今回の件でmemcachedに対して不安感を持たれた方もおられるとお聞きしました 説明不足だったせいで誤解を与えてしまい申し訳ありません きちんと設定および監視を行っていれば通常の使用にはまったく問題はありません 弊社にて -c 30万で起動したmemcachedに対して、先のテストスクリプトに

    mixi大規模障害について その2 - mixi engineer blog
  • ロングテールな画像配信 その2 - 3,000万の画像を配信するシステム - mixi engineer blog

    Squidを検索する度に最初に表示される画像検索の結果に吹き出しそうになる開発部・システム運用グループの長野です。前回のロングテールな画像配信のその2ということで、実際の画像配信システムについて書かせて頂きます。 ■プロフィール画像の配信について 前回紹介しましたが、mixiにおいてプロフィール写真を設定を設定しているユーザ数は全体の約70%、1,000万人の方が設定をされています。現在配信をしているプロフィール画像のサイズは180x180、76x76、40x40と3サイズあり、合計3,000万以上のファイル数になっています。また、もっともよく使われる76x76のサイズ1,000万件において、1日にアクセスされる画像の数は800万ファイル以上、うち97%が30回以下と非常に広範囲に渡ってアクセスされています。そのため大量の画像を配信できる仕組みが必要になります。 ■配信システムの全体像 プ

    ロングテールな画像配信 その2 - 3,000万の画像を配信するシステム - mixi engineer blog
  • mixi Engineers’ Blog » ロングテールな画像配信 その1

    開発部・システム運用グループの長野です。最近は「サーバ/インフラを支える技術」を読みながら通勤しています。今回はmixiの画像配信について書かせて頂きたいと思います。1回目は画像配信の課題について説明させて頂きます。 ■画像配信の種類 これまで画像の配信は大きく分けて2種類あると考え、システムを構築してきました。1つは1ファイルあたりへのアクセスが非常に多くなりますが、ファイル数が少ないもの。もう一つはファイル数が膨大になる代わりに、1つのファイルへのアクセスは少ないものになります。 前者はmixiの中で使われるロゴ画像やメニューの画像等のページ部品、また広告画像や絵文字画像になり、後者はユーザがアップロードする日記やアルバムの画像にあたります。ページの部品の画像はファイル数はそれほど多くないものの、サーバへのアクセス数が最大で秒間に数万リクエストにもなります。逆にアルバムや日記の画像は全

    mixi Engineers’ Blog » ロングテールな画像配信 その1
  • mixi Engineers’ Blog » 期間限定の新機能「エコー」登場

    こんにちは。mixi開発部のyouheiです。 今回は先日8月4日にリリースした「エコー」について書きたいと思います。 エコーとは まずはエコーとはどういう機能かのご紹介ですが、プロモーションページがございますのでそちらをご覧いただければ幸いでございます。 http://mixi.jp/guide_echo.pl いくつか抜粋しますと、 あなたの"今"を一言にしてみませんか?誰かに伝えたいこと、ひとりごと等、何でもOK! 気軽な新コミュニケーション機能です。 たとえば、「今日はいい天気だな〜」という、ひとりごとから、「お腹すいたー!誰かランチにいこうよ!」というメッセージ的な使い方まで、「エコー」の楽しみ方はあなた次第! マイミクシィ同士で「エコー」を使うとホームにお互いの書きこみが表示されます。 気になった書きこみには、返信することもできちゃいます。あなたがふと書きこんだ一言に、思わぬ返

    mixi Engineers’ Blog » 期間限定の新機能「エコー」登場
  • mixi Engineers’ Blog » Introducing the Drizzle Project

    ここしばらく、水面下でBrian Akerを代表とするMySQL/SUNのエンジニアたちや、業界のオープンソースハッカーたちとMySQLをスリムダウンさせたマイクロカーネルRDBMSを開発していたのですが、日アナウンスされたので、日語でご紹介させていただきたいと思います。 Drizzleとは? Drizzleとは必要のないものは一切存在しない、最低限でパフォーマンス重視な「MySQLよりシンプルで、軽く、安定して、高速な」 MySQLのforkです。マイクロカーネルアーキテクチャを採用したので、必要のないものは後付けできる構成です。こういった目標もあり、現在、Drizzleの開発チームはMySQLをドラスティックにリファクタリングしています。 コミュニティベースのプロジェクト Drizzleで大事な事は、Drizzleはコミュニティベースのプロジェクトであるという事です。Montyのブ

    mixi Engineers’ Blog » Introducing the Drizzle Project
  • Tokyo Dystopiaの設計思想 - mixi engineer blog

    番に向けて海に行ける体作りに励まないといかんなーと思いつつも、ついついDSのスターフォックスで遊んでしまうmikioです。さて今回は、人知れずリリースされている検索エンジンTokyo Dystopiaの概要と設計思想について述べます。 Hyper Estraierとの違い Tokyo Dystopia(以下、TDと呼びます)は、新しい検索エンジンです。しかし、私が作ったもう一つの検索エンジンHyper Estraier(以下、HEと呼びます)の後継としては位置付けていません。 Hyper Estraierの製品コンセプトは、「検索システムの需要が生じる様々なシーンで手軽に導入できる」ことです。言い換えれば、「いわゆるシロウトの人でも、お高い商用システムを買えない個人や小組織でも、ちょっとの努力で自分の要求を満たすシステムを構築できる」ことです。そのために、様々なファイル形式に対応したテ

    Tokyo Dystopiaの設計思想 - mixi engineer blog
  • YAPC::Asia 2008の資料公開します - mixi engineer blog

    開発部・システム運用グループの長野です。5月15日・16日に東工大大岡山キャンパスで開催されたPerlのカンファレンス、YAPC::Asia 2008に参加してきました。2日目にはセッションの時間を2つ頂いて、発表をしてきたのでその資料を公開します。 ■memcached in mixi [pdf] memcachedはmixiのシステムでも重要なアプリケーションの1つになります。発表ではmemcachedの基から、弊社でのmemcachedの事例、そして分散方法の改善、TokyoTyrantの活用事例について説明させて頂きました。発表の最後時間が足りなくなり説明できなかったスライドも含まれていますのでご覧下さい。 memcachedについては、研究開発グループのtmaesakaによる記事が、またTokyoTyrantの活用事例については、こちらの記事にもありますので参考にして頂けたら幸

    YAPC::Asia 2008の資料公開します - mixi engineer blog
  • mixi Engineers’ Blog » Tokyo Tyrantによる耐高負荷DBの構築

    連休中はWiiのマリオカートをやりまくってやっとVR7000越えたmikioです。愛車はマッハ・バイクとインターセプターです。さて今回は、分散ハッシュデータベースサーバTokyo Tyrantでmixiの最終ログイン時刻を管理するようにした時の苦労話を書きます。 ログイン処理は負荷地獄 mixiでは、全てのユーザについて、各々の最終ログイン時刻を管理しています。「マイミクシィ一覧」や「お気に入り」などの画面で、友人が近い時間にログインしていてコミュニケーションがとりやすい状態にあるかどうか確認できるようにするためです。 mixiのほぼ全てのページはログインしないと見られないページなので、ほぼ全てのページにアクセスされるたびにログイン確認が行われます。したがって、最終ログイン時刻はほぼ全てのページにアクセスされる度に更新されることになります。mixiの中で最も重いデータベースのひとつとして「

    mixi Engineers’ Blog » Tokyo Tyrantによる耐高負荷DBの構築
  • mixi Engineers’ Blog » memcachedの最新動向

    先週アメリカに行ってMySQLカンファレンスやmemcached hackathonに参加してきました。そこで今回はmemcachedコミュニティやhackathonで行われた多くの議論に関してご報告させていただきたいと思います。 前書き ご存知の通りmemcachedはFacebookやWikipediaをはじめとする巨大ウェブサイトのコアテクノロジーの一つとして世界中で使われるまでに到達したソフトウェアです。mixiを支えるテクノロジーの一つでもあります。 hackathonをご存知ない方のために簡単に説明すると、オープンソースプロジェクトハッカーたちが実際に集まってプロジェクトの開発をしたり仕様の議論や提案などをするイベントの事です(とても楽しいです)。 今回で4回目になるmemcachedのhackathon(議事録)ですが、東京でもやったら面白いんじゃね?的な話を結構まえにした

    mixi Engineers’ Blog » memcachedの最新動向
  • mixi Engineers’ Blog » mixiのスモールワールド性の検証

    初めまして、mixi開発部のfujisawaです。 マイミクシィの友人関係を使って、mixiのスモールワールド性について調べましたので、その結果について書きたいと思います。 スモールワールド性とは スモールワールド性とは、人間関係のネットワークなどでよく見られる性質で、文字通り「世間は狭い(It's a small world!)」ということを表しています。「知り合いを6人介するだけで、世界中の人々と間接的につながることができる」という『6次の隔たり(Six Degrees of Separations)』という言葉でもよく知られています。 一般にスモールワールドは以下の特徴を持っています。 誰に対しても少ない人数を介するだけで到達できる(平均距離が小さい) 自分の友人同士が友人関係にあることが多い(クラスタ性が高い) 1の距離とは、ネットワーク中のノードをたどった回数、すなわち友人を介し

    mixi Engineers’ Blog » mixiのスモールワールド性の検証
  • Inside Tokyo Cabinet その参 - mixi engineer blog

    この連載のように小難しい記事が続くと、読者の皆さんだけでなく執筆陣まで引いてしまうのではないかと心配しているmikioです。いやいや、いいんです。ハッキングから夜のオカズまでバラエティに富んだブログを目指すべく、私は私なりの記事を、たとえマイノリティ向けだとしても臆さず書いてゆくのです。今回はTCの実装の詳細についてお届けします。 QDBMとどう違うの? QDBMもTCと同様にDBMの一実装で、小さくて速くて使いやすいをモットーに作りはじめて、それなりに目標を達成できたと自負しているプロダクトです。しかし、今思えばいろいろと気に入らない点がいくつかありました。TCはそれを克服すべく一から書き直したものです。具体的には以下の点が違います。 空間効率の向上 : データベースファイルのサイズがもっと小さい 時間効率の向上 : 読み書きにかかる時間がもっと短い 耐障害性の向上 : データベースファ

    Inside Tokyo Cabinet その参 - mixi engineer blog
  • mixi Engineers’ Blog » 最適化しよう?

    エンジニアブログを私物化していると専らの評判のmikioです。ブログを書かないと死んでしまう病に冒されているのでしかたないですね。個人ブログ時代よりもわかりやすくする努力はしているんですけどね。さて、今回はソースコードの最適化による高速化について述べます。 ベンチマークテスト TCはQDBMや他のDBMより高速であるという主張をしたいのですが、その根拠としてベンチマークテストの結果が必要となります。そこで、データベースに100万レコードを格納する処理と、そうして作ったデータベースから全てのレコードを探索する処理の時間を、各DBMで計測してみました(TCのパッケージのbrosというディレクトリにテストコードが入っています)。実行環境は、Thinkpad T60(Intel(R) Core2 CPU T7200 @ 2.00GHz)上のLinux version 2.6.16です。 ハッシュ

    mixi Engineers’ Blog » 最適化しよう?
  • mixi Engineers’ Blog » OpenSSLの暗号文をJava/Perl/Rubyで開く

    秘密鍵やプライベートな情報などを秘匿するためにパスワードでデータを暗号化・復号したい場合があります。このとき、暗号化と復号するアプリケーションが同じであれば簡単ですが、例えばCで暗号化してJavaPerlRubyで復号するといった風に異なるプラットフォームで暗号データをやりとりする場合には、いくつか気 をつけなければいけないポイントがあります。 OpenSSLによる暗号化 OpenSSLはWebサーバのSSL/TLSサポートに利用されますが、その他にも付属しているopensslコマンドから基的な暗号アルゴリズムを利用できます。次のような簡単なコマンドで、パスワードを使ってデータを暗号化したり復号したりすることができます: $ echo 'Hello World!' | openssl enc -e -aes-128-cbc > cipher.txt enter aes-128-cbc

    mixi Engineers’ Blog » OpenSSLの暗号文をJava/Perl/Rubyで開く
  • 1