栞/#system
「SSDを、メモリバッファの拡張としてとらえるか、HDDの拡張として使うかで、アプリケーションや、最適なアルゴリズムも変わることが示唆されており」
「理由は、『データセンターにサーバーを置くスペースがないから』だってさ。つまりニコニコ動画の重い原因は土地問題ｗｗｗｗｗ」
Facebookの新しい写真ストレージ、Haystackについて。
Flickr。PHP5に移行したらCPU使用率が下がったとか、GraphicsMagick使ってるとか。古いサーバーを新しいサーバーに置き換えるメリットも。
Googleのサーバー。「サーバ1台1台が、それぞれ12Vのバッテリを備えていて、メイン電源に問題がある場合には電力を供給する」HDDは日立GSTだね。
SPFに対応したsendmail、設定手順。
ヤフオク、マルチマスタ構成、オリジナルのソフトウェアロードバランサ。
ニコニコ動画開発記、日経ソフトウェアに連載されていたもの。
画像処理のサーバーにPS3（Linuxをインストール）を利用。「サーバーシステムに対してPS3を数台接続する形になる」/ id:wa-ren 了解ですー
テクニカルセミナー発表資料。「インサイド livedoor Blog」とか。
memcachedのmixiでの運用事例。
Twitterの遅延を考慮してアーキテクチャを想像してみてる。メッセージキューが各followerのタイムラインに追加される処理の遅延を想像。
システムの中のPostgreSQL。
「正確さのために無駄なロックが発生したり、インデックスを肥大化させて、速度を犠牲にしてしまう。(よくあるパターンだと思う)」「細かいことを気にしなければコンピューターの性能はもっと引き出せるはず。」
FrinedFeedがMySQLを使ってデータを管理している方法。「実体の中身は Python のディクショナリを pickle し, zlib で圧縮したもの」、インデックスの役割をするテーブルを用意して非同期にデータ書き込み。joinもプログラムで。
業務時間外の障害対応をどう行うか。
pixivインタビュー。手作りサーバーの写真も。
キー・バリュー型データストア。はてなはサーバーを。「プロセサはデスクトップPC用のCore 2 Quad、メモリーは8Gバイト、ストレージは32GバイトのSSD。インテル製のマザーボードを使っているが1台あたりの価格は7万円弱」
高速化。フロントエンド、特にJavaScript重要。
「『サービス層』をフロントエンド、バックエンドのどちら側にもっていくか、が設計において鍵になるんじゃないか」Lang-8の場合、APIの通信コストとして1リクエストあたり平均16msかかっているとのこと。
はてなの開発環境、社内フレームワークの構成。MVAC（Model/View/Application/Controlloer）。フレームワークが行うのは基本的なルーティングのみ。他サービスとの連携はAPI経由、Squidを挟むことでキャッシュを活用。
クックパッド。「一瞬で理解できるインタフェースじゃないと使われない、最大2秒以上理解するのにかかる機能はユーザは使ってくれない」「ヘルプや FAQ を読ませるのはユーザに負担を強いるし、そもそも読まれない」
はてなでのXenの使われ方とか。
キャパシティの観点からのシステム改善。
いろいろなサービスのシステム構成が載ってる記事へのリンク。
Lang-8における内部APIモデル。APIの粒度を大きくすること、APIの共通言語（レスポンスのフォーマット）を高速処理すること、キャッシュをできるだけ使うこと。
DBとのインターフェースは内部APIとしてPHPで実装。フロントのRailsからActiveResourceでアクセス。
タイムライン型の表示の問題。キャッシュしづらいしデータが増えるほどソートに時間がかかるので、データ更新時に更新を参照できるユーザー単位で更新情報を作っておいて参照時にはそれを見せる。
ちょっと認証をかけたい場合に、アプリ本体とは別にPHPでベーシック認証させる。
アメブロの画像サーバーのHDDがSeagateの不具合直撃。